[Group.of.nepali.translators] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)

[Christian Ehrhardt ]

** Changed in: keepalived (Ubuntu Xenial)
 Assignee: (unassigned) => Athos Ribeiro (athos-ribeiro)

** Changed in: keepalived (Ubuntu Bionic)
 Assignee: (unassigned) => Athos Ribeiro (athos-ribeiro)

** No longer affects: keepalived (Ubuntu Xenial)

** Changed in: keepalived (Ubuntu Focal)
 Assignee: (unassigned) => Athos Ribeiro (athos-ribeiro)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1815101

Title:
  [master] Restarting systemd-networkd breaks keepalived, heartbeat,
  corosync, pacemaker (interface aliases are restarted)

Status in netplan:
  Triaged
Status in heartbeat package in Ubuntu:
  Won't Fix
Status in keepalived package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Won't Fix
Status in keepalived source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released
Status in keepalived source package in Focal:
  Confirmed
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  - ALL related HA software has a small problem if interfaces are being
  managed by systemd-networkd: nic restarts/reconfigs are always going
  to wipe all interfaces aliases when HA software is not expecting it to
  (no coordination between them.

  - keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
  smarter in this case because it has a service monitor that will
  restart the virtual IP resource, in affected node & nic, before
  considering a real failure, but other HA service might consider a real
  failure when it is not.

  [test case]

  - comment #14 is a full test case: to have 3 node pacemaker, in that
  example, and cause a networkd service restart: it will trigger a
  failure for the virtual IP resource monitor.

  - other example is given in the original description for keepalived.
  both suffer from the same issue (and other HA softwares as well).

  [regression potential]

  - this backports KeepConfiguration parameter, which adds some
  significant complexity to networkd's configuration and behavior, which
  could lead to regressions in correctly configuring the network at
  networkd start, or incorrectly maintaining configuration at networkd
  restart, or losing network state at networkd stop.

  - Any regressions are most likely to occur during networkd start,
  restart, or stop, and most likely to involve missing or incorrect ip
  address(es).

  - the change is based in upstream patches adding the exact feature we
  needed to fix this issue & it will be integrated with a netplan change
  to add the needed stanza to systemd nic configuration file
  (KeepConfiguration=)

  [other info]

  original description:
  ---

  Configure netplan for interfaces, for example (a working config with
  IP addresses obfuscated)

  network:
  ethernets:
  eth0:
  addresses: [192.168.0.5/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth2:
  addresses:
    - 12.13.14.18/29
    - 12.13.14.19/29
  gateway4: 12.13.14.17
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth3:
  addresses: [10.22.11.6/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth4:
  addresses: [10.22.14.6/24]
  dhcp4: false
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  eth7:
  addresses: [9.5.17.34/29]
  dhcp4: false
  optional: true
  nameservers:
    search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
    addresses: [10.22.11.1]
  version: 2

  Configure keepalived (again, a working config with IP addresses
  obfuscated)

  global_defs   # Block id
  {
  notification_email {
  sysadm...@blah.com
  }
  notification_email_from keepali...@system3.hq.blah.com
  smtp_server 10.22.11.7 # IP
  smtp_connect_timeout 30  # integer, seconds
  router_id system3  # string identifying the machine,
   # (doesn't have to be hostname).
  

[Group.of.nepali.translators] [Bug 1662345] Re: smbios parameter settings not visible in guest

[Christian Ehrhardt ]

Hi Louis,
I doubt you (or anyone) will still fix it for Xenial.
Feel free to update if that isn't true.

** Changed in: qemu (Ubuntu Xenial)
 Assignee: Louis Bouchard (louis) => (unassigned)

** Changed in: qemu (Ubuntu)
 Assignee: Louis Bouchard (louis) => (unassigned)

** Changed in: qemu (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1662345

Title:
  smbios parameter settings not visible in guest

Status in qemu package in Ubuntu:
  Confirmed
Status in qemu source package in Xenial:
  Won't Fix
Status in qemu source package in Bionic:
  Fix Released

Bug description:
  qemu-system-aarch64 supports -smbios parameters to export values into the DMI 
tables.
  These values are viewable via /sys/class/dmi/id/* or via dmidecode (V3 
tables).

  Passing in custom values for things like -smbios
  type=1,manufacturer="Foobar" should result in that value being
  viewable in-guest via dmidecode or /sys/class/dmi/id/*

  Testing with a Xenial qemu-system-arm and Xenial cloud-image shows
  that these smbios parameters aren't being modified.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: qemu-system-arm 1:2.5+dfsg-5ubuntu10.7
  ProcVersionSignature: User Name 4.4.0-59.80-generic 4.4.35
  Uname: Linux 4.4.0-59-generic aarch64
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: arm64
  Date: Mon Feb  6 16:09:03 2017
  KvmCmdLine:
   COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
   kvm_arch_timer  S<   0 063 2  0.0 [kvm_arch_timer]
   kvm-irqfd-clean S<   0 064 2  0.0 [kvm-irqfd-clean]
  Lsusb: Error: command ['lsusb'] failed with exit code 1:
  ProcEnviron:
   LANGUAGE=en_US:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US
   SHELL=/bin/bash
  ProcKernelCmdLine: console=ttyS0,115200n8 ro
  SourcePackage: qemu
  UpgradeStatus: No upgrade log present (probably fresh install)

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1570997] Re: fail if HOME environment variable is not set

[Christian Ehrhardt ]

Hi Scott and Dustin, long time no see :-)
I guess none of you bothers about this being fixed in Xenial anymore, let me 
update the assignments and status to reflect that.

** Changed in: ssh-import-id (Ubuntu Xenial)
   Status: Triaged => Won't Fix

** Changed in: ssh-import-id (Ubuntu Xenial)
 Assignee: Scott Moser (smoser) => (unassigned)

** Changed in: ssh-import-id (Ubuntu)
 Assignee: Dustin Kirkland  (kirkland) => (unassigned)

** Changed in: ssh-import-id
 Assignee: Dustin Kirkland  (kirkland) => (unassigned)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1570997

Title:
  fail if HOME environment variable is not set

Status in ssh-import-id:
  Fix Released
Status in ssh-import-id package in Ubuntu:
  Fix Released
Status in ssh-import-id source package in Xenial:
  Won't Fix
Status in ssh-import-id source package in Bionic:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  Running ssh-import-id without environment variable HOME set
  will fail and print an error message like:

   TypeError: join() argument must be str or bytes, not 'NoneType'

  [Test Case]
  $ name="my-x"
  $ ud=$(printf '%s\n%s\n' '#!/bin/sh' 'ssh-import-id smoser')
  $ lxc launch ubuntu-daily:xenial "$name" "--config=user.user-data=$ud"

  To see failure, you can then just:
  $ lxc exec "$name" -- cat /run/cloud-init/result.json
  {
   "v1": {
    "datasource": "DataSourceHetzner",
    "errors": [
     "('scripts-user', RuntimeError('Runparts: 1 failures in 1 attempted 
commands',))"
    ]
   }
  }

  $ lxc exec "$name" -- grep "ssh-import-id lp:smoser" 
/root/.ssh/authorized_keys &&
  echo GOOD || echo FAIL

  [Regression Potential]
  Regression is unlikely.  The code only does anything if HOME is not present.
  This has been in Artful and Bionic since 2016-09-16.

  [Other Info]
  Upstream merge proposal:
   
https://code.launchpad.net/~smoser/ssh-import-id/trunk.lp1570997/+merge/326692

  === End SRU Template ===

  I've modified /usr/bin/ssh-import-id to show a stack trace rather than 
unhelpful message:
   TypeError: join() argument must be str or bytes, not 'NoneType'

  Then, running:
  $ env -u HOME ssh-import-id smoser
  Traceback (most recent call last):
    File "/usr/bin/ssh-import-id", line 62, in 
  main()
    File "/usr/bin/ssh-import-id", line 45, in main
  k = import_keys(proto, username, parser.options.useragent)
    File "/usr/lib/python3/dist-packages/ssh_import_id/__init__.py", line 204, 
in import_keys
  local_keys = key_list(read_keyfile())
    File "/usr/lib/python3/dist-packages/ssh_import_id/__init__.py", line 135, 
in read_keyfile
  output_file = parser.options.output or os.path.join(os.getenv("HOME"), 
".ssh", "authorized_keys")
    File "/usr/lib/python3.5/posixpath.py", line 89, in join
  genericpath._check_arg_types('join', a, *p)
    File "/usr/lib/python3.5/genericpath.py", line 143, in _check_arg_types
  (funcname, s.__class__.__name__)) from None
  TypeError: join() argument must be str or bytes, not 'NoneType'

  I came to find this by trying to  launch an instance with:

  $ ec2metadata --user-data
  #!/bin/sh
  exec >/my.log 2>&1
  cat /proc/uptime
  date -R
  ssh-import-id smoser

  The basic issue is that the environment that cloud-init runs in does
  not have HOME set.

  I suggest using os.path.expanduser
  def authorized_key_file():
  return os.path.join(os.path.expanduser("~"), ".ssh", 
"authorized_keys")

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ssh-import-id 5.5-0ubuntu1 [modified: usr/bin/ssh-import-id]
  ProcVersionSignature: User Name 4.4.0-18.34-generic 4.4.6
  Uname: Linux 4.4.0-18-generic x86_64
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  Date: Fri Apr 15 17:36:09 2016
  Ec2AMI: ami-929f8cf8
  Ec2AMIManifest: 
ubuntu-us-east-1/images-testing/hvm-instance/ubuntu-xenial-daily-amd64-server-20160412.manifest.xml
  Ec2AvailabilityZone: us-east-1c
  Ec2InstanceType: m3.medium
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: ssh-import-id
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ssh-import-id/+bug/1570997/+subscriptions


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1581864] Re: nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument

[Christian Ehrhardt ]

Thanks Athos for flagging this,
you are right if we do not fix it now for Bionic it won't be fixed at all.
But OTOH no one except internal people have revisited this for ages, and being 
only cosmetic (the service is up and running fine) this won't make the last 
minute (in the release lifecycle) SRU acceptance especially given the 
discussions around how it was resolved.

Upstream isn't very happy with the resolution [1] and I'd more lean to
even challenge/reconsider if we might drop this in new versions - this
is 3 years old maybe it is a non issue nowadays.

If someone thinks this is a wrong assumptions please speak up, outline why it 
is important to be fixed in Bionic in a way that will most likely also convince 
the SRU team to accept the risk.
Otherwise I'd call this a win't fix for Bionic too.

[1]: https://trac.nginx.org/nginx/ticket/1897

** Tags removed: server-triage-discuss

** Changed in: nginx (Ubuntu Bionic)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1581864

Title:
  nginx.service: Failed to read PID from file /run/nginx.pid: Invalid
  argument

Status in nginx package in Ubuntu:
  Fix Released
Status in nginx source package in Xenial:
  Won't Fix
Status in nginx source package in Bionic:
  Won't Fix
Status in nginx source package in Cosmic:
  Won't Fix
Status in nginx source package in Disco:
  Won't Fix
Status in nginx source package in Eoan:
  Fix Released
Status in nginx package in Debian:
  Fix Released

Bug description:
  [Description]

  Nginx logs an error when started on a machine with a single CPU:

  systemctl start nginx
  systemctl status nginx
  ● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: 
enabled)
     Active: active (running) since Sat 2016-05-14 19:35:03 UTC; 2s ago
    Process: 1303 ExecStop=/sbin/start-stop-daemon --quiet --stop --retry 
QUIT/5 --pidfile /run/nginx.pid (code=exited, status=0/SUCCESS)
    Process: 1307 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; 
(code=exited, status=0/SUCCESS)
    Process: 1306 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; 
master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 1308 (nginx)
  Tasks: 5 (limit: 512)
     Memory: 3.1M
    CPU: 81ms
     CGroup: /system.slice/nginx.service
     ├─1308 nginx: master process /usr/sbin/nginx -g daemon on; 
master_process on
     ├─1309 nginx: worker process
     ├─1310 nginx: worker process
     ├─1311 nginx: worker process
     └─1312 nginx: worker process

  May 14 19:35:03 ngx systemd[1]: Starting A high performance web server and a 
reverse proxy server...
  May 14 19:35:03 ngx systemd[1]: nginx.service: Failed to read PID from file 
/run/nginx.pid: Invalid argument
  May 14 19:35:03 ngx systemd[1]: Started A high performance web server and a 
reverse proxy server.

  Bumping the number of CPU available makes the error disappear. This is
  reproducible on VMs and containers.

  Lastly, the PID file is properly created and matches the PID of the
  master process.

  [Workaround]

    sudo mkdir /etc/systemd/system/nginx.service.d
    printf "[Service]\nExecStartPost=/bin/sleep 0.1\n" | \
  sudo tee /etc/systemd/system/nginx.service.d/override.conf
    sudo systemctl daemon-reload
sudo systemctl restart nginx

  [Additional information]

  # lsb_release -rd
  Description:  Ubuntu 16.04 LTS
  Release:  16.04

  # apt-cache policy nginx-core
  nginx-core:
    Installed: 1.10.0-0ubuntu0.16.04.1
    Candidate: 1.10.0-0ubuntu0.16.04.1
    Version table:
   *** 1.10.0-0ubuntu0.16.04.1 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   1.9.15-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: nginx-core 1.10.0-0ubuntu0.16.04.1
  ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8
  Uname: Linux 4.4.0-22-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  Date: Sat May 14 19:35:21 2016
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
  SourcePackage: nginx
  UpgradeStatus: No upgrade log present (probably fresh install)

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1576588] Re: google-authenticator with openvpn fails on 16.04

[Christian Ehrhardt ]

Thank you all for your reports, but sadly there was no further engagement here.
Andreas and Rafael have asked for more details, config files and such to be 
able to recreate this.

Therefore this can not be acted on as is - in addition Xenial is now in
ESM and no more getting normal SRU updates.

On the other hand the feedback on the case also stopped as there were no
further people chiming in with new updates.

Therefore, sorry, but I'll have to set it to Won't Fix for the Xenial
task.

If you have information how to recreate this (in later releases) please
comment here to give this case some new life.

** Changed in: openvpn (Ubuntu Xenial)
   Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1576588

Title:
  google-authenticator with openvpn fails on 16.04

Status in openvpn package in Ubuntu:
  Fix Released
Status in openvpn source package in Xenial:
  Won't Fix
Status in openvpn source package in Bionic:
  Fix Released

Bug description:
  We are using a standard https://openvpn.net/ community server, with
  2-factor authentication via Google Authenticator enabled

  This has worked with latest version of openvpn in 14.04 (all through
  only via the terminal)

  When doing a fresh install of 16.04, and initiating the vpn from the
  terminal with: openvpnvpn client-config.ovpn it ends with this error:

  Fri Apr 29 10:12:27 2016 SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' 
(status=1)
  Fri Apr 29 10:12:27 2016 AUTH: Received control message: AUTH_FAILED,Google 
Authenticator Code must be a number
  Fri Apr 29 10:12:27 2016 SIGTERM[soft,auth-failure] received, process exiting

  We have noticed that the user/password + google authenticator dialog
  has changed from the old one

  Enter Auth Username: 
  Enter Auth Password: 
  CHALLENGE: Enter Google Authenticator Code
  Response: **

  All info is now hidden with asterisks, where only the password was in
  the old version

  We suspect something wrongly happens when parsing the google-
  authenticator response

  Thank you

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1736940] Re: Ubuntu 16.04 LTS: SMBStatus shows wrong information

[Christian Ehrhardt ]

Hi,
I come by trying to close or revive some old bugs that were dormant for way too 
long.

In regard to smb-v1 / smb-v3.11
In this case Ubuntu Bionic and later (currently on 
2:4.7.6+dfsg~ubuntu-0ubuntu2) recognize samba 3.11 (This was referred to in 
[1], but was only true for Xenial, anything later - and bionic existed at the 
time - was ok).

The smbstatus in xenial isn't fixed and we've somewhere dropped the ball
on it not further guiding Loic to get hit patch landed or at least
discussed :-/

But by everything later being fixed and Xenial nowadays only being in
extended security maintenance [2] it is sad but unlikely that this will
be changed in Xenial.

*sigh* for dropping the ball on a patch on a plate :-/

@Andreas let me know if you disagree and still want to try changing
Xenial

[1]: https://github.com/sonicnkt/wpkg-gp/issues/2#issuecomment-451407880
[2]. https://ubuntu.com/security/esm

** Also affects: samba4 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: samba4 (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: samba4 (Ubuntu)
 Assignee: Andreas Hasenack (ahasenack) => (unassigned)

** Changed in: samba4 (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: samba4 (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: samba4 (Ubuntu Xenial)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1736940

Title:
  Ubuntu 16.04 LTS: SMBStatus shows wrong  information

Status in samba4 package in Ubuntu:
  Fix Released
Status in samba4 source package in Xenial:
  Won't Fix

Bug description:
  This bug affects Samba 4.3.11 as provided in Ubuntu 16.04 LTS.

  Smbstatus does not display correct information for users connected to
  my server.

  This information is known to Samba as it is indeed correctly logged in
  samba audit module, which I have enabled and the log does show the
  correct username, group and host.

  Here is an example of wrong smbstatus output:

  Samba version 4.3.11-Ubuntu
  PID Username  Group MachineProtocol Version
  --

  21001 nobodynogroup   192.168.11.88
  (ipv4:192.168.11.88:53625) Unknown (0x0311)

  And here is what it would normally look like:

  31691 fsmith   marketing 192.168.11.88
  (ipv4:192.168.11.88:52582) SMB2_10

  If I read the issue correctly, this has already been patched and fixed
  upstream in in Samba 4.4.0 and higher

  https://bugzilla.samba.org/show_bug.cgi?id=11472

  Please provide feedback and a possible fix as we use smbstatus all the
  time to track open files and who they are opened by and for a quick
  view at opened samba shares.

  Thank you.

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1888000] Re: Bionic/Xenial minimal cloud image: failed to apply load kernel module

[Christian Ehrhardt ]

Hi,
I'm coming by cleaning old open bugs to ensure nothing gets forgotten for too 
long and or clutters the view to the remaining issues.

This case here - as Paride outlined almost two years ago - is already
covered and discussed in bug 1833586 . We won't/can't SRU it and there
was no further input/discussion here.

Setting Bionic to Won't Fix - and from latter releases it is already
fine.

** Changed in: open-iscsi (Ubuntu Bionic)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1888000

Title:
  Bionic/Xenial minimal cloud image: failed to apply load kernel module

Status in linux package in Ubuntu:
  Confirmed
Status in open-iscsi package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  Won't Fix
Status in linux source package in Bionic:
  New
Status in open-iscsi source package in Bionic:
  Won't Fix

Bug description:
  Overview
  ---
  It appears the Bionic and Xenial minimal images have always shipped with a 
failing systemd unit: "systemd-modules-load.service" with the error "Failed to 
find module 'ib_iser'"

  Expected results
  ---
  $ sudo systemctl list-units --failed --no-legend
  # Return no failed units

  Actual results
  ---
  $ sudo systemctl list-units --failed --no-legend
  systemd-sysctl.service loaded failed failed Apply Kernel Variables
  # cloud-config.service may show up failing to setup the timezone...

  From the journal:
  Jul 17 17:48:27 ubuntu systemd-modules-load[98]: Module 'iscsi_tcp' is builtin
  Jul 17 17:48:27 ubuntu systemd-modules-load[98]: Failed to find module 
'ib_iser'
  Jul 17 17:48:27 ubuntu systemd-sysctl[106]: Couldn't write '176' to 
'kernel/sysrq', ignoring: No such file or directory
  Jul 17 17:48:27 ubuntu systemd-sysctl[106]: Couldn't write 'fq_codel' to 
'net/core/default_qdisc', ignoring: No such file or directory

  Steps to reproduce
  ---
  $ wget 
https://cloud-images.ubuntu.com/daily/server/minimal/releases/bionic/release/ubuntu-18.04-minimal-cloudimg-amd64.img
  $ multipass launch file:///$(pwd)/ubuntu-18.04-minimal-cloudimg-amd64.img 
--name=bionic-minimal
  $ multipass exec bionic-minimal -- sudo systemctl list-units --failed 
--no-legend

  
  ---
  ProblemType: Bug
  AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 
2: ls: cannot access '/dev/snd/': No such file or directory
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.15
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse: Error: [Errno 2] No such file or directory: 'fuser': 
'fuser'
  CRDA: N/A
  DistroRelease: Ubuntu 18.04
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lspci: Error: [Errno 2] No such file or directory: 'lspci': 'lspci'
  Lsusb: Error: [Errno 2] No such file or directory: 'lsusb': 'lsusb'
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  Package: linux (not installed)
  PciMultimedia:

  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcFB: Error: [Errno 2] No such file or directory: '/proc/fb'
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1069-kvm 
root=PARTUUID=ffb7214d-c783-45ed-b736-278d4ee0cac0 ro console=tty1 console=ttyS0
  ProcVersionSignature: User Name 4.15.0-1069.70-kvm 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-1069-kvm N/A
   linux-backports-modules-4.15.0-1069-kvm  N/A
   linux-firmware   N/A
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic uec-images
  Uname: Linux 4.15.0-1069-kvm x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm audio cdrom dialout dip floppy lxd netdev plugdev sudo video
  _MarkForUpload: True
  dmi.bios.date: 04/01/2014
  dmi.bios.vendor: SeaBIOS
  dmi.bios.version: 1.10.2-1ubuntu1
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-i440fx-bionic
  dmi.modalias: 
dmi:bvnSeaBIOS:bvr1.10.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-bionic:cvnQEMU:ct1:cvrpc-i440fx-bionic:
  dmi.product.name: Standard PC (i440FX + PIIX, 1996)
  dmi.product.version: pc-i440fx-bionic
  dmi.sys.vendor: QEMU

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1652269] Re: udev script shortcuts ifup-scripts

[Christian Ehrhardt ]

We are - as always - trying to clean and recheck old bugs.
This - sadly - clearly is one of them.
The situation is still correct, but with the full switch to networkd and 
netplan as well as the demotion of ifupdown in later versions of Ubuntu this 
has become even less important. And it didn#t even find enough 
importance/attendence before :-/

I'm retagging this as a Xenial/Bionic issue, because later releases
would just work totally different anyway.

** Also affects: bridge-utils (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: bridge-utils (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: bridge-utils (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: bridge-utils (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Changed in: bridge-utils (Ubuntu Focal)
   Status: New => Invalid

** Changed in: bridge-utils (Ubuntu Jammy)
   Status: New => Invalid

** Changed in: bridge-utils (Ubuntu Bionic)
   Status: New => Confirmed

** Changed in: bridge-utils (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: bridge-utils (Ubuntu)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1652269

Title:
  udev script shortcuts ifup-scripts

Status in bridge-utils package in Ubuntu:
  Invalid
Status in bridge-utils source package in Xenial:
  Confirmed
Status in bridge-utils source package in Bionic:
  Confirmed
Status in bridge-utils source package in Focal:
  Invalid
Status in bridge-utils source package in Jammy:
  Invalid

Bug description:
  Hi,

  I just ran into a problem. I've configured a bridge as a virtual lan
  (for lxc, lxd, and these things), but also configured an USB Ethernet
  dongle to be part of the bridge.

  If the dongle is present at boot time or if the dongle is put in while
  the bridge is down, then

  
  /lib/udev/bridge-network-interface  

  
  tries to take the bridge up. Nice. 

  But it does not call ifup, instead it directly calls

  IFACE=$port /etc/network/if-pre-up.d/vlan

  
  This ifup is not aware that the interface is up and still thinks it would be 
down, and all the other settings (up/down-scripts ...) are not executed. Breaks 
functionality (and can be a security problem, since firewall settings my be 
skipped.)

  ProblemType: Bug
  DistroRelease: Ubuntu 16.10
  Package: bridge-utils 1.5-9ubuntu2
  ProcVersionSignature: Ubuntu 4.8.0-32.34-generic 4.8.11
  Uname: Linux 4.8.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.3-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Fri Dec 23 11:31:43 2016
  Dependencies:
   gcc-6-base 6.2.0-5ubuntu12
   libc6 2.24-3ubuntu2
   libgcc1 1:6.2.0-5ubuntu12
  InstallationDate: Installed on 2016-04-22 (244 days ago)
  InstallationMedia: Lubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420)
  SourcePackage: bridge-utils
  UpgradeStatus: Upgraded to yakkety on 2016-10-17 (67 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bridge-utils/+bug/1652269/+subscriptions


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1585168] Re: SMB Client bug. Can't connect to smb shares on OSX Elcaptain

[Christian Ehrhardt ]

Hi,
I'm trying to clear a few old bugs and this sadly never came up again - neither 
via prio/people chiming in here nor in other places. Nowadays the server team 
has an improved triage process in place which would better catch the hint to 
the fix and probably create SRU uploads for this in time. But for Xenial/Trusty 
that is now - in 2021 - too late as they are in extended security maintenance 
now which this does not qualify for :-/.

** Also affects: samba (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: samba (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: samba (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: samba (Ubuntu Trusty)
   Status: New => Won't Fix

** Changed in: samba (Ubuntu Xenial)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1585168

Title:
  SMB Client bug. Can't connect to smb shares on OSX Elcaptain

Status in samba package in Ubuntu:
  Fix Released
Status in samba source package in Trusty:
  Won't Fix
Status in samba source package in Xenial:
  Won't Fix

Bug description:
  Can't connect to smb shares on OSX Elcaptain

  smbclient -L //osxhost/smbshare -U user
  after proper creditenials:

  session setup failed: NT_STATUS_INVALID_SIGNATURE

  this happened after update

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: samba 2:4.3.9+dfsg-0ubuntu0.14.04.1
  ProcVersionSignature: Ubuntu 3.13.0-86.131-generic 3.13.11-ckt39
  Uname: Linux 3.13.0-86-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.20
  Architecture: amd64
  Date: Tue May 24 12:17:09 2016
  SambaClientRegression: Yes
  SourcePackage: samba
  UpgradeStatus: Upgraded to trusty on 2014-10-01 (600 days ago)

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1608302] Re: IKEv1/XAuth connection to Dell SonicWall appliance fails

[Christian Ehrhardt ]

Hi,
I come by cleaning up some old bugs and this one is a sad one to see.
It wasn't able to be acted on when I looked at is last time. Then Joseph was so 
kind to offer his help, but neither myself nor anyone else in the Team saw 
that. Therefore this was not brought back onto anyone's todo-list and 
essentially died by inactivity :-/

Nowadays the answer is simple in that Xenial is in ESM and an non-security 
issue like this won't be fixed anymore. It also lacked further activity / more 
bug reports of the same kind to make it more important/seen.
Hmm, all that sounds like excuses, we missed the update and I have to beg your 
pardon.
Still from today's POV Won't Fix is the only right status to set this to.

P.S. FYI Nowadays we have an improved triage process for server bugs in
place and such an update will no more be missed. And gladly on cleanup
only very few old cases look like that. Still feeling bad about this one
...

** Changed in: strongswan (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

** Changed in: strongswan (Ubuntu Yakkety)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1608302

Title:
  IKEv1/XAuth connection to Dell SonicWall appliance fails

Status in strongswan package in Ubuntu:
  Fix Released
Status in strongswan source package in Xenial:
  Won't Fix
Status in strongswan source package in Yakkety:
  Won't Fix

Bug description:
  https://wiki.strongswan.org/issues/1434

  This already been fixed upstream in 5.5.0
  https://wiki.strongswan.org/versions/62

  Description:Ubuntu 16.04.1 LTS
  Release:16.04

  strongswan:
Installed: 5.3.5-1ubuntu3
Candidate: 5.3.5-1ubuntu3
Version table:
   *** 5.3.5-1ubuntu3 500
  500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages
  100 /var/lib/dpkg/status

  I expected connection to complete.

  Connection terminated instead. See
  https://wiki.strongswan.org/issues/1434 for more details.

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1686324] Re: usb hostdev passthrough generates the wrong apparmor rules

[Christian Ehrhardt ]

While clearing old bugs I found this one and priority for Xenila/Zesty
backports never was important to anyone. Nowadays those are on ESM
support and since there is a workaround (rule overrides) and this isn't
a security issue I'll set Won't Fix for those.

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: libvirt (Ubuntu Zesty)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1686324

Title:
  usb hostdev passthrough generates the wrong apparmor rules

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Won't Fix
Status in libvirt source package in Zesty:
  Won't Fix
Status in libvirt source package in Artful:
  Fix Released

Bug description:
  [Impact]

   * USB Host devices fail to add statically

   * The reason is that libvirt has not yet initialized usb devices

   * Fix by back-porting small upstream change

  [Test Case]

   * Create a VM Guest (e.g. via uvtool)
   * Shut down the guest
   * virsh edit 
   * Add a usb hostdev from your System (check lsusb for IDs)
   * See the original description below for XML examples
   * Starting the guest will create a wrong rule
   "/dev/bus/usb/000/000" rw,
 And due to that fails to start.

  [Regression Potential]

   * The change is small and only makes certain values available to
  libvirt

   * The only thing I could think of regressing is if that 
 virHostdevFindUSBDevice would crash on some systems, but then it would 
 fail later on in the lifecycle even without the patch - so we should be 
 safe IMHO.

  [Other Info]
   
   * I waited to be accepted upstream to be more confident which is 
 partially why this took so long but provides some extra confidence.

  
  ---

  
  Libvirt-aa-helper seems to have a bug when adding usb passthrough devices 
statically.

  On hotplug with:
  $ cat sandisk-usb.xml
  
  
  
  
  
  
  

  $ virsh attach-device z-test1 sandisk-usb.xml

  It generates correctly:
  "/dev/bus/usb/003/003" rw,

  But if adding the same XML part to the guest xml itself it generates:
  "/dev/bus/usb/000/000" rw,

  And as a follow on issue the guest start fails with:
  libusb: error [_get_usbfs_fd] libusb couldn't open USB device 
/dev/bus/usb/003/003: Permission denied
  Due to:
  apparmor="DENIED" operation="open" 
profile="libvirt-adc578cb-905f-41fc-9be2-9fb81f6a6073" 
name="/dev/bus/usb/003/003" pid=22879 comm="qemu-system-x86" 
requested_mask="wr" denied_mask="wr" fsuid=123 ouid=123

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1689488] Re: vnc console accepts only 8 characters

[Christian Ehrhardt ]

** No longer affects: qemu (Ubuntu Bionic)

** No longer affects: novnc (Ubuntu Bionic)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1689488

Title:
  vnc console accepts only 8 characters

Status in novnc package in Ubuntu:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in novnc source package in Xenial:
  New
Status in qemu source package in Xenial:
  Incomplete
Status in qemu source package in Yakkety:
  Won't Fix

Bug description:
  We have an issue when send message via vnc console. The vnc accepts
  only the first 8 characters.

  The issue happens on ubuntu 15.05/15.10/16.04/16.10, but does not
  exist in ubuntu 14.04 and ubuntu 17.04.

  After investigation, I found the issue is caused by commit
  
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2deb4acc7c7ee770a0e0e75fd321effd916ca7df

  and fixed by commit (it is already included in qemu v2.7.0, and ubuntu 
17.04/qemu-2.8)
  
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c5ce83334465ee5acb6789a2f22d125273761c9e

  Can we include the fix in next minor release of qemu-2.5 for ubuntu
  16.04 ?

  Thanks.

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


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1916485] Re: test -x fails inside shell scripts in containers

[Christian Ehrhardt ]

** Changed in: docker.io (Ubuntu)
   Status: New => Invalid

** Tags removed: server-next

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1916485

Title:
  test -x fails inside shell scripts in containers

Status in Ubuntu on IBM z Systems:
  New
Status in docker.io package in Ubuntu:
  Invalid
Status in glibc package in Ubuntu:
  Opinion
Status in libseccomp package in Ubuntu:
  Fix Committed
Status in runc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in docker.io source package in Xenial:
  New
Status in libseccomp source package in Xenial:
  New
Status in runc source package in Xenial:
  New
Status in systemd source package in Xenial:
  Invalid
Status in docker.io source package in Bionic:
  New
Status in libseccomp source package in Bionic:
  New
Status in runc source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in docker.io source package in Focal:
  New
Status in libseccomp source package in Focal:
  New
Status in runc source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in docker.io source package in Groovy:
  Won't Fix
Status in libseccomp source package in Groovy:
  Won't Fix
Status in runc source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in docker.io source package in Hirsute:
  New
Status in libseccomp source package in Hirsute:
  Fix Committed
Status in runc source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  (SRU template for systemd)

  [impact]

  bash (and some other shells) builtin test command -x operation fails

  [test case]

  on any affected host system, start nspawn container, e.g.:

  $ sudo apt install systemd-container
  $ wget 
https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz
  $ mkdir h
  $ cd h
  $ sudo tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz
  $ sudo systemd-nspawn

  Then from a bash shell, verify if test -x works:

  root@h:~# ls -l /usr/bin/gpg
  -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg
  root@h:~# test -x /usr/bin/gpg || echo "fail"
  fail

  [regression potential]

  any regression would likely occur during a syscall, most likely
  faccessat2(), or during other syscalls.

  [scope]

  this is needed for b/f

  this is fixed upstream by commit
  bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so
  this is fixed in h

  this was pulled into Debian at version 246.2 in commit
  e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g

  in x, the entire systemd seccomp code is completely different and the
  patch doesn't apply, nor does it appear to be needed, as the problem
  doesn't reproduce in a h container under x.

  [other info]

  this needs fixing in libseccomp as well

  [original description]

  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/#

  root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail

  The -f flag works, as does /usr/bin/test:
  # bash -c "test -f /usr/bin/gpg  || echo Fail"
  # bash -c "/usr/bin/test -x /usr/bin/gpg  || echo Fail"
  #

  [Original bug report]
  root@84b750e443f8:/# lsb_release -rd
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04
  root@84b750e443f8:/# dpkg -l gnupg apt
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name   Version Architecture Description
  
+++-==-===--==
  ii  apt2.1.20  amd64commandline package manager
  ii  gnupg  2.2.20-1ubuntu2 all  GNU privacy guard - a free 
PGP replacement

  Hi,
  for 3 days our CI pipelines to recreate Docker images fails for the Hirsute 
images. From comparison this seems to be caused by apt 2.1.20.

  The build fails with:

  0E: gnupg, gnupg2 and 

[Group.of.nepali.translators] [Bug 1903978] Re: New upstream microreleases 9.5.24 10.15, 12.5 and 13.1

[Christian Ehrhardt ]

Hmm these got updated through -security already.
Missed the bug update due to changelogs.
Setting them to released manually now.

** Changed in: postgresql-10 (Ubuntu Bionic)
   Status: Triaged => Fix Released

** Changed in: postgresql-12 (Ubuntu Focal)
   Status: Triaged => Fix Released

** Changed in: postgresql-13 (Ubuntu Hirsute)
   Status: In Progress => Fix Released

** Changed in: postgresql-9.5 (Ubuntu Xenial)
   Status: Triaged => Fix Released

** No longer affects: postgresql-12 (Ubuntu Hirsute)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1903978

Title:
  New upstream microreleases 9.5.24 10.15, 12.5 and 13.1

Status in postgresql-9.5 source package in Xenial:
  Fix Released
Status in postgresql-10 source package in Bionic:
  Fix Released
Status in postgresql-12 source package in Focal:
  Fix Released
Status in postgresql-12 source package in Groovy:
  Won't Fix
Status in postgresql-13 source package in Hirsute:
  Fix Released

Bug description:
  [Impact]

   * MRE for latest stable fixes of Postgres release on August 13th.

  [Test Case]

   * The Postgres MREs traditionally rely on the large set of autopkgtests
     to run for verification. In a PPA those are all already pre-checked to
     be good for this upload.

  [Regression Potential]

   * Upstreams tests are usually great and in additon in the Archive there
     are plenty of autopkgtests that in the past catched issues before being
     released.
     But never the less there always is a risk for something to break. Since
     these are general stable releases I can't pinpoint them to a most-likely
     area.
     - usually this works smoothly except a few test hickups (flaky) that need 
to be
   clarified to be sure. Pre-checks will catch those to be discussed 
upfront (as last time)

  [Other Info]

   * This is a reoccurring MRE, see below and all the references
   * This includes a fix for CVEs:
     CVE-2020-25694
     CVE-2020-25695
     CVE-2020-25696

  ---

  Current versions in supported releases:
   postgresql-9.5 | 9.5.23-0ubuntu0.16.04.1 | xenial-updates
   postgresql-10 | 10.14-0ubuntu0.18.04.1 | bionic-updates
   postgresql-12 | 12.4-0ubuntu0.20.04.1 | focal-updates
   postgresql-12 | 12.4-1| groovy
   postgresql-13 | 13.0-6build1 | hirsute-proposed/universe

  Special cases:
  - Hirsute will as usual be synced from Debian.
     I already see
     postgresql-13 | 13.1-1| unstable| source, amd64, arm64, 
armhf, i386, ppc64el, s390x
  - 21.04 also has a postgresql-12 and while that is on the way to be
    removed and fulyl replaced by 13 that is too far out. Therefore we will
    upload 12.5 to Hirsute as well.
  - I have checked with Debian (they are affected by the same FTFBS and test
    fails of bug 1903573) but they will just remove postgresql-12 from
    testing. We can't do that yet on hirsute without breaking too much

  Last relevant related stable updates: 9.5.23, 10.14 and 12.4
  You'll see that the last update was missed, so I'll combined them.

  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  - pad.lv/1815665
  - pad.lv/1828012
  - pad.lv/1833211
  - pad.lv/1839058
  - pad.lv/1863108
  - pad.lv/1892335

  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.

  ---

  Interim test state

  Xenial
  https://bileto.ubuntu.com/excuses/4331/xenial.html
  Good except the following which are all masked in hints-ubuntu
   bareos/14.2.6-3
   libreoffice/1:5.1.6~rc2-0ubuntu1~xenial10
   pdns/4.0.0~alpha2-3build1: amd64
   pgpool2/3.4.3-1: amd64

  Bionic
  https://bileto.ubuntu.com/excuses/4332/bionic.html
  Good except the following which are all masked in hints-ubuntu
   pdns/4.1.1-1
   pglogical/2.1.1-1
   postgresql-multicorn/1.3.4-1

  Focal
  https://bileto.ubuntu.com/excuses/4333/focal.html
  Many i386 dependency issues - all masked in hints-ubuntu
  Good except the following which are all masked in hints-ubuntu
   postgresql-multicorn/1.3.4-31-g9ff7875-3
   diaspora-installer/0.7.6.1+debian1

  Groovy
  https://bileto.ubuntu.com/excuses/4334/groovy.html
  Many i386 dependency issues - all masked in hints-ubuntu
  The rest are the usual suspects which are ok
   pdns/4.3.0-4build2
   pglogical/2.3.2-1
   pglogical-ticker/1.4.0-2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/xenial/+source/postgresql-9.5/+bug/1903978/+subscriptions


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help 

[Group.of.nepali.translators] [Bug 1931243] Re: FTBFS in Impish on s390x

[Christian Ehrhardt ]

** Changed in: gdisk (Ubuntu Bionic)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1931243

Title:
  FTBFS in Impish on s390x

Status in Release Notes for Ubuntu:
  New
Status in Ubuntu on IBM z Systems:
  In Progress
Status in gdisk package in Ubuntu:
  Fix Released
Status in gdisk source package in Xenial:
  Invalid
Status in gdisk source package in Bionic:
  Invalid
Status in gdisk source package in Focal:
  Invalid
Status in gdisk source package in Groovy:
  Invalid
Status in gdisk source package in Hirsute:
  Invalid
Status in gdisk source package in Impish:
  Fix Released
Status in gdisk package in Debian:
  New

Bug description:
  The bug here is mostly for tracking and the update-excuse tag.
  I've reported it to Debian already at:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989589

  And at upstream:
  
https://sourceforge.net/p/gptfdisk/mailman/gptfdisk-general/thread/CAATJJ0LdpVeVGMMaYUe995%3DZFtuJu6tW5VjQ%3DONbpwci_fezZw%40mail.gmail.com/#msg37298406

  See update details there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1931243/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1931243] Re: FTBFS in Impish on s390x

[Christian Ehrhardt ]

This got inot Debian experimental and synced from there

 gdisk | 1.0.8-1  | impish   | source, amd64,
arm64, armhf, i386, ppc64el, riscv64, s390x


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

** Changed in: gdisk (Ubuntu Xenial)
   Status: Incomplete => Invalid

** Changed in: gdisk (Ubuntu Focal)
   Status: Incomplete => Invalid

** Changed in: gdisk (Ubuntu Hirsute)
   Status: Incomplete => Invalid

** Changed in: gdisk (Ubuntu Groovy)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1931243

Title:
  FTBFS in Impish on s390x

Status in Ubuntu on IBM z Systems:
  In Progress
Status in gdisk package in Ubuntu:
  Fix Released
Status in gdisk source package in Xenial:
  Invalid
Status in gdisk source package in Bionic:
  Incomplete
Status in gdisk source package in Focal:
  Invalid
Status in gdisk source package in Groovy:
  Invalid
Status in gdisk source package in Hirsute:
  Invalid
Status in gdisk source package in Impish:
  Fix Released
Status in gdisk package in Debian:
  New

Bug description:
  The bug here is mostly for tracking and the update-excuse tag.
  I've reported it to Debian already at:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989589

  And at upstream:
  
https://sourceforge.net/p/gptfdisk/mailman/gptfdisk-general/thread/CAATJJ0LdpVeVGMMaYUe995%3DZFtuJu6tW5VjQ%3DONbpwci_fezZw%40mail.gmail.com/#msg37298406

  See update details there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931243/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1931243] Re: FTBFS in Impish on s390x

[Christian Ehrhardt ]

Fix in https://sourceforge.net/p/gptfdisk/code/merge-requests/26/

** Bug watch added: Debian Bug tracker #989589
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989589

** Also affects: gdisk (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989589
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1931243

Title:
  FTBFS in Impish on s390x

Status in Ubuntu on IBM z Systems:
  New
Status in gdisk package in Ubuntu:
  In Progress
Status in gdisk source package in Xenial:
  Incomplete
Status in gdisk source package in Bionic:
  Incomplete
Status in gdisk source package in Focal:
  Incomplete
Status in gdisk source package in Groovy:
  Incomplete
Status in gdisk source package in Hirsute:
  Incomplete
Status in gdisk source package in Impish:
  In Progress
Status in gdisk package in Debian:
  Unknown

Bug description:
  The bug here is mostly for tracking and the update-excuse tag.
  I've reported it to Debian already at:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989589

  And at upstream:
  
https://sourceforge.net/p/gptfdisk/mailman/gptfdisk-general/thread/CAATJJ0LdpVeVGMMaYUe995%3DZFtuJu6tW5VjQ%3DONbpwci_fezZw%40mail.gmail.com/#msg37298406

  See update details there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931243/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1871321] Re: ) [sssd] [talloc_log_fn] (0x0010): Bad talloc magic value - unknown value

[Christian Ehrhardt ]

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

Hi Luis,
I can derive from your info in [2] that you are on Xenial, so I'll mark that 
for now.
Do you happen to know if it also occurs on other releases?


Two things will commonly be needed to get any further on this.
1. your setup details, how did you setup sssd and your authentication exactly. 
Are there particular actions to trigger this bug or is it just time/logins that 
have to pass? If possible the best usually is if you are able to outline the 
steps needed to set up a clean new VM with Ubuntu to reach the bad state
2. Since it reports a crash is there any crash that you could report [1] ?


[1]: https://help.ubuntu.com/community/ReportingBugs#Reporting_a_crash
[2]: https://answers.launchpad.net/ubuntu/+question/689804

The message somehow felt familiar, but I couldn't find a case I touched that 
seemed like a full match. Looking further I found the old case I had in mind ...
=> https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1883614

I think I can mark this a dup and if you want you can chime in on the
other bug that is already a few steps further in the debug-process but
fell dead back then.


** Also affects: sssd (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** No longer affects: sssd (Ubuntu Bionic)

** Also affects: sssd (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** This bug has been marked a duplicate of bug 1883614
   sssd  got killed due to segfault in ubuntu 16.04

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1871321

Title:
  ) [sssd] [talloc_log_fn] (0x0010): Bad talloc magic value - unknown
  value

Status in sssd package in Ubuntu:
  New
Status in sssd source package in Xenial:
  New

Bug description:
  Once a month the server OS crashes and when users are trying to log in
  it will deny access. After reboot the problem resolves itself.

  Error
   [sssd] [talloc_log_fn] (0x0010): Bad talloc magic value - unknown value

  Kernel
  4.4.0-31-generic

  Updates available
  377 packages can be updated.
  227 updates are security updates.
  New release '18.04.4 LTS' available.

  
  - Is there a way to know the risks to update to a newer version of sssd? 
  - Can you please advise us on how to tackle this usse?

  Kr,
  Luis Gomez

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1915254] Re: New upstream microreleases 9.5.25 10.16 12.6 13.2

[Christian Ehrhardt ]

Complete in Hirsute as well
 postgresql-13 | 13.2-1 | hirsute | source, amd64, arm64, armhf, i386, ppc64el, 
riscv64, s390x


** Changed in: postgresql-13 (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1915254

Title:
  New upstream microreleases 9.5.25 10.16 12.6 13.2

Status in postgresql-13 package in Ubuntu:
  Fix Released
Status in postgresql-9.5 source package in Xenial:
  Fix Committed
Status in postgresql-10 source package in Bionic:
  Fix Committed
Status in postgresql-12 source package in Focal:
  Fix Released
Status in postgresql-12 source package in Groovy:
  Fix Released

Bug description:
  [Impact]

   * MRE for latest stable fixes of Postgres released on February 11th

  [Test Case]

   * The Postgres MREs traditionally rely on the large set of autopkgtests
     to run for verification. In a PPA those are all already pre-checked to
     be good for this upload.

  [Regression Potential]

   * Upstreams tests are usually great and in additon in the Archive there
     are plenty of autopkgtests that in the past catched issues before being
     released.
     But never the less there always is a risk for something to break. Since
     these are general stable releases I can't pinpoint them to a most-likely
     area.
     - usually this works smoothly except a few test hickups (flaky) that need 
to be
   clarified to be sure. Pre-checks will catch those to be discussed 
upfront (as last time)

  [Other Info]

   * This is a reoccurring MRE, see below and all the references
   * This includes a fix for one CVE:
  CVE-2021-3393 - only v12 for on Focal/Groovy

  ---

  Current versions in supported releases:
   postgresql-12 | 12.5-0ubuntu0.20.10.1 | groovy-security | source, amd64, 
arm64, armhf, i386, ppc64el, riscv64, s390x
   postgresql-12 | 12.5-0ubuntu0.20.04.1 | focal-security  | source, amd64, 
arm64, armhf, i386, ppc64el, riscv64, s390x
   postgresql-10 | 10.15-0ubuntu0.18.04.1 | bionic-security | source, amd64, 
arm64, armhf, i386, ppc64el, s390x
   postgresql-9.5 | 9.5.24-0ubuntu0.16.04.1 | xenial-security | source, amd64, 
arm64, armhf, i386, powerpc, ppc64el, s390x

  Special cases:
  - Hirsute will as usual be synced from Debian.
   Currently on 13.1 still
   postgresql-13 | 13.1-1build1 | hirsute | source, amd64, arm64, armhf, i386, 
ppc64el, riscv64, s390x

  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  - pad.lv/1815665
  - pad.lv/1828012
  - pad.lv/1833211
  - pad.lv/1839058
  - pad.lv/1863108
  - pad.lv/1892335

  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-13/+bug/1915254/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1677398] Re: Apparmor prevents using storage pools and hostdev networks

[Christian Ehrhardt ]

This now has a related upstream issue
https://gitlab.com/libvirt/libvirt/-/issues/135

** Bug watch added: gitlab.com/libvirt/libvirt/-/issues #135
   https://gitlab.com/libvirt/libvirt/-/issues/135

** Also affects: libvirt via
   https://gitlab.com/libvirt/libvirt/-/issues/135
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1677398

Title:
  Apparmor prevents using storage pools and hostdev networks

Status in libvirt:
  Unknown
Status in libvirt package in Ubuntu:
  Triaged
Status in libvirt source package in Xenial:
  Won't Fix
Status in libvirt source package in Yakkety:
  Won't Fix
Status in libvirt source package in Zesty:
  Won't Fix

Bug description:
  Apparmor prevents qemu-kvm guests from using ZFS volumes.

  [Impact]
  * storage pools are not usable.
    Examples with zfs and LVM pools

  [Test Case 1]
  # Prep ZFS
  1) Create a zpool
   $ for i in $(seq 1 3); do dd if=/dev/zero of=/tmp/fdisk${i} bs=1M 
count=1024; done
   $ sudo zpool create internal /tmp/fdisk*
  2) Create a ZFS storage pool and volume (named like your zpool, "internal" 
here)
    $ virsh pool-define-as internal zfs
    $ virsh pool-start internal
    $ virsh vol-create-as internal foo 2G

  # prep LVM
  4) prepare a (fake) LVM
    $ for i in $(seq 1 3); do dd if=/dev/zero of=/tmp/lvdisk${i} bs=1M 
count=1024; done
    $ sync
    $ DISKS=$(for i in $(seq 1 3); do sudo losetup -f --show /tmp/lvdisk${i}; 
done)
    $ sudo pvcreate --verbose $DISKS
    $ sudo vgcreate --verbose testvg $DISKS
  5) Create LVM Pool and volume
   $ virsh pool-define-as testvg logical
   $ virsh pool-start testvg
   $ virsh vol-create-as testvg guest1 2G

  # Prep Guest and use Pools
  6) Create a KVM guest e.g. via uvtool
   $ uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=xenial
   $ ssh-keygen
   $ uvt-kvm create --password=ubuntu testguest release=xenial arch=amd64 
label=daily
  7) Edit the guest's XML profile to use the ZFS and LVM volumes (zvol)
  
    
    
    
  
  
    
    
    
  
  8) Start the guest

  The guest refuses to start:

    # virsh start nms
    error: Failed to start domain foo
    error: internal error: process exited while connecting to monitor: 
2017-03-29T22:07:31.507017Z qemu-system-x86_64: -drive 
file=/dev/zvol/internal/foo,format=raw,if=none,id=drive-virtio-disk0,cache=none:
 Could not open '/dev/zvol/internal/foo': Permission denied

  dmesg reveals the culprit:

  apparmor="DENIED" operation="open" 
profile="libvirt-988a8c25-5190-4762-8170-55dc75fc66ca" name="/dev/zd224" 
pid=23052 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=109 
ouid=109
  apparmor="DENIED" operation="open" 
profile="libvirt-988a8c25-5190-4762-8170-55dc75fc66ca" name="/dev/zd224" 
pid=23052 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=109 
ouid=109

  Checking /etc/apparmor.d/libvirt/libvirt-$UUID.files shows that no
  "/dev/zdXX" has been added.

  [Additional info]

  # lsb_release -rd
  Description:  Ubuntu 16.04.2 LTS
  Release:  16.04

  # apt-cache policy libvirt-bin apparmor linux-image-generic
  libvirt-bin:
    Installed: 1.3.1-1ubuntu10.8
    Candidate: 1.3.1-1ubuntu10.8
    Version table:
   *** 1.3.1-1ubuntu10.8 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   1.3.1-1ubuntu10 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  apparmor:
    Installed: 2.10.95-0ubuntu2.5
    Candidate: 2.10.95-0ubuntu2.5
    Version table:
   *** 2.10.95-0ubuntu2.5 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.10.95-0ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  linux-image-generic:
    Installed: 4.4.0.70.76
    Candidate: 4.4.0.70.76
    Version table:
   *** 4.4.0.70.76 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   4.4.0.21.22 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: libvirt-bin 1.3.1-1ubuntu10.8
  ProcVersionSignature: Ubuntu 4.4.0-70.91-generic 4.4.49
  Uname: Linux 4.4.0-70-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  Date: Wed Mar 29 17:48:06 2017
  SourcePackage: libvirt
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.default.libvirt-guests: [modified]
  

[Group.of.nepali.translators] [Bug 1915811] Re: Empty NUMA topology in machines with high number of CPUs

[Christian Ehrhardt ]

** Also affects: libvirt (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Groovy)
   Importance: Undecided
   Status: New

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

** Tags added: server-next

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1915811

Title:
  Empty NUMA topology in machines with high number of CPUs

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  New
Status in libvirt source package in Bionic:
  New
Status in libvirt source package in Focal:
  New
Status in libvirt source package in Groovy:
  New

Bug description:
  [impact]

  libvirt fails to populate its NUMA topology when the machine has a
  large number of CPUs assigned to a single node. This happens when the
  number of CPUs fills the bitmask (all to one), hitting a workaround
  introduced to build the NUMA topology on machines that have non
  contiguous node ids. This has been already fixed upstream in the
  commits listed below.

  [scope]

  The fix is needed for Xenial, Bionic, Focal and Groovy.

  It's fixed upstream with commits 24d7d85208 and 551fb778f5 which are
  included in v6.8, so both are already in hirsute.

  [test case]

  On a machine like the EPYC 7702P, after setting the NUMA config to
  NPS1 (single node per processor), or just a VM with 128 CPUs, "virsh
  capabilities" does not show the NUMA topology:

  # virsh capabilities | xmllint --xpath '/capabilities/host/topology' -

  


  

  When it should show (edited to shorten the description):

  

  
5027820
1256955
0

  


  
  
  

  

  

  
  [Where problems could occur]

  Any regression would likely involve a misconstruction of the NUMA
  topology, in particular for machines with non contiguous node ids.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1848923] Re: pollinate.service fails to start: ERROR: should execute as the [pollinate] user -- missing CacheDirectory=

[Christian Ehrhardt ]

SRU Template added.
For backport planning I'll add B/F/G since the solution on't help Xenial and 
that really is old enough by now to have more people complain about this issue 
there to make it super-important.

** Also affects: pollinate (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: pollinate (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: pollinate (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: pollinate (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: pollinate (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: pollinate (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: pollinate (Ubuntu Focal)
   Status: New => Triaged

** Changed in: pollinate (Ubuntu Groovy)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1848923

Title:
  pollinate.service fails to start: ERROR: should execute as the
  [pollinate] user -- missing CacheDirectory=

Status in pollinate package in Ubuntu:
  In Progress
Status in pollinate source package in Xenial:
  Won't Fix
Status in pollinate source package in Bionic:
  Triaged
Status in pollinate source package in Focal:
  Triaged
Status in pollinate source package in Groovy:
  Triaged

Bug description:
  [Impact]

   * /var/cache is expected to be able to be cleared for a reboot without 
 drawbacks. But the directory of pollinate is a classic cache, yet it 
 only is created in postinst. That leads to the service failing on 
 reboot after the path was cleared.
 For example the cockpit images are affected by that

   * The Fix for that is to instruct systemd to (if needed) create that path
 under the same permissions.

  [Test Case]

   * sudo rm -rf /var/cache/pollinate
   * sudo reboot
   * systemctl status pollinate

   Without the fix it will fail to start missing the directory (but 
   complaining about a wrong user). With the fix it works as systemd 
   recreates that directory if needed.

  [Where problems could occur]

   * We modify the service file, so issues would be around the 
 /var/cache/pollinate creation/usage or the start/stop/restart
 of the service.

  [Other Info]
   
   * the postinst bits doeing the mkdir are not removed to easen backport to 
 e.g. Xenial where this systemd feature does not exist.


  

  In a standard Ubuntu 19.10 cloud image install, pollinate fails to
  start:

  ● pollinate.service - Pollinate to seed the pseudo random number generator
     Loaded: loaded (/lib/systemd/system/pollinate.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: exit-code) since Sun 2019-10-20 12:17:10 EEST; 3 
months 4 days ago
   Docs: https://launchpad.net/pollinate
   Main PID: 665 (code=exited, status=1/FAILURE)

  Oct 20 12:17:10 ubuntu systemd[1]: Starting Pollinate to seed the pseudo 
random number generator...
  Oct 20 12:17:10 ubuntu pollinate[708]: ERROR: should execute as the 
[pollinate] user
  Oct 20 12:17:10 ubuntu systemd[1]: pollinate.service: Main process exited, 
code=exited, status=1/FAILURE
  Oct 20 12:17:10 ubuntu systemd[1]: pollinate.service: Failed with result 
'exit-code'.
  Oct 20 12:17:10 ubuntu systemd[1]: Failed to start Pollinate to seed the 
pseudo random number generator.

  The user does exist:

  # id pollinate
  uid=110(pollinate) gid=1(daemon) groups=1(daemon)

  and the unit has "User=pollinate"

  This happens outside of systemd as well:

  # sudo -u pollinate /usr/bin/pollinate
  <13>Jan 24 09:31:05 pollinate[21456]: ERROR: should execute as the 
[pollinate] user

  set -x shows why:

  + [ ! -w /var/cache/pollinate ]
  + error should execute as the [pollinate] user

  This directory doesn't exist. So (1) this is a bad error message, and
  (2) pollinate.service is missing "CacheDirectory=pollinate". When
  adding that, it works.

  pollinate 4.33-2ubuntu1

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1892335] Re: New upstream microreleases 9.5.23 10.14 and 12.4

[Christian Ehrhardt ]

** Changed in: postgresql-12 (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1892335

Title:
  New upstream microreleases 9.5.23 10.14 and 12.4

Status in postgresql-12 package in Ubuntu:
  Fix Released
Status in postgresql-9.5 source package in Xenial:
  Fix Released
Status in postgresql-10 source package in Bionic:
  Fix Released
Status in postgresql-12 source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * MRE for latest stable fixes of Postgres release on August 13th.

  [Test Case]

   * The Postgres MREs traditionally rely on the large set of autopkgtests
 to run for verification. In a PPA those are all already pre-checked to
 be good for this upload.

  [Regression Potential]

   * Upstreams tests are usually great and in additon in the Archive there
 are plenty of autopkgtests that in the past catched issues before being
 released.
 But never the less there always is a risk for something to break. Since
 these are general stable releases I can't pinpoint them to a most-likely
 area.
 - usually this works smoothly except a few test hickups (flaky) that need 
to be
   clarified to be sure. Pre-checks will catch those to be discussed 
upfront (as last time)

  [Other Info]

   * This is a reoccurring MRE, see below and all the references
   * This includes a fix for two CVEs:
 CVE-2020-14349
 CVE-2020-14350

  ---

  Current versions in supported releases:
   postgresql-9.5 | 9.5.21-0ubuntu0.16.04.1 xenial
   postgresql-10 | 10.12-0ubuntu0.18.04.1 bionic
   postgresql-12 | 12.2-4 focal

  
  Special cases:
  - Groovy will as usual be synced from Debian.
 I already see
 postgresql-12 | 12.4-1   | groovy-proposed | source, amd64, i386, 
ppc64el, s390x

  Last relevant related stable updates: 9.5.23, 10.14 and 12.4
  You'll see that the last update was missed, so I'll combined them.

  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  - pad.lv/1815665
  - pad.lv/1828012
  - pad.lv/1833211
  - pad.lv/1839058
  - pad.lv/1863108

  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-12/+bug/1892335/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1912168] [NEW] please merge ppp 2.4.9 for 21.04 and then consider ipv6 default fix for SRU

[Christian Ehrhardt ]

Public bug reported:

Hi,
due to this ML on devel-discuss [1] I realized that there is a new version that 
should be merged for Ubuntu 21.04 - and probably later [2] be 
considered/discussed for an SRU
That new version is in Debian now [3] and I think it would be great to get that 
merged/synced.

I guess ppp might be out-of-focus today, therefore per [4] I'm also
pinging the Desktop team hoping this will help to get a look at it.

[1]: 
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2021-January/018916.html
[2]: 
https://github.com/paulusmack/ppp/pull/145/commits/0678d3bf69116af58b00fbc64bd4185acb4d5c37
[3]: https://tracker.debian.org/news/1217613/ppp-249-11-migrated-to-testing/
[4]: http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html

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

** Affects: ppp (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: ppp (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Affects: ppp (Ubuntu Focal)
 Importance: Undecided
 Status: New

** Affects: ppp (Ubuntu Groovy)
 Importance: Undecided
 Status: New

** Summary changed:

- please merge ppp 2.4.9 for various fixes
+ please merge ppp 2.4.9 for 21.04 and then consider ipv6 default fix for SRU

** Also affects: ppp (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: ppp (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: ppp (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: ppp (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Description changed:

  Hi,
  due to this ML on devel-discuss [1] I realized that there is a new version 
that should be merged for Ubuntu 21.04 - and probably later [2] be 
considered/discussed for an SRU
  That new version is in Debian now [3] and I think it would be great to get 
that merged/synced.
  
- I guess ppp might be out-of-focus today, therefore per [4] I'm assigning
- the Desktop team hoping this will help to get a look at it.
+ I guess ppp might be out-of-focus today, therefore per [4] I'm also
+ pinging the Desktop team hoping this will help to get a look at it.
  
  [1]: 
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2021-January/018916.html
  [2]: 
https://github.com/paulusmack/ppp/pull/145/commits/0678d3bf69116af58b00fbc64bd4185acb4d5c37
  [3]: https://tracker.debian.org/news/1217613/ppp-249-11-migrated-to-testing/
  [4]: http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1912168

Title:
  please merge ppp 2.4.9 for 21.04 and then consider ipv6 default fix
  for SRU

Status in ppp package in Ubuntu:
  New
Status in ppp source package in Xenial:
  New
Status in ppp source package in Bionic:
  New
Status in ppp source package in Focal:
  New
Status in ppp source package in Groovy:
  New

Bug description:
  Hi,
  due to this ML on devel-discuss [1] I realized that there is a new version 
that should be merged for Ubuntu 21.04 - and probably later [2] be 
considered/discussed for an SRU
  That new version is in Debian now [3] and I think it would be great to get 
that merged/synced.

  I guess ppp might be out-of-focus today, therefore per [4] I'm also
  pinging the Desktop team hoping this will help to get a look at it.

  [1]: 
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2021-January/018916.html
  [2]: 
https://github.com/paulusmack/ppp/pull/145/commits/0678d3bf69116af58b00fbc64bd4185acb4d5c37
  [3]: https://tracker.debian.org/news/1217613/ppp-249-11-migrated-to-testing/
  [4]: http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1842701] Re: Apache2 Balancer Manager mod_proxy_balancer not working after Update

[Christian Ehrhardt ]

To close this out, fixed in Groovy
 apache2 | 2.4.46-1ubuntu1 | groovy   | source, amd64, 
arm64, armhf, i386, ppc64el, riscv64, s390x


** Changed in: apache2 (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1842701

Title:
  Apache2 Balancer Manager mod_proxy_balancer not working after Update

Status in Apache2 Web Server:
  Fix Released
Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  Fix Released
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released
Status in apache2 package in Debian:
  Fix Released

Bug description:
  OS

  Description:Ubuntu 18.04.3 LTS
  Release:18.04
  Codename:   bionic

  
  I use this kind of configuration to reache the Balancer Manager.

   -
  |Bastian Host |
  |Apache Proxy | ---> LB Apache Balancer Manger
   -

  After Apache Update

  from: 2.4.29-1ubuntu4.8
  to:   2.4.29-1ubuntu4.10

  The Balancer Manager behind a Proxy is not Working and i think this is 
comming with
  the fix CVE-2019-10092

  https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2019-10092
  
http://changelogs.ubuntu.com/changelogs/pool/main/a/apache2/apache2_2.4.29-1ubuntu4.10/changelog

  
  I strip down the configuration to try and explain the situation.

  Install new Ubuntu 18.04 VirtualBox. From an another VM i saved the prior
  Apache Packages from /var/cache/apt/archives

  :~# apt-get install libapr1 libaprutil1 libaprutil1-dbd-sqlite3 
libaprutil1-ldap liblua5.2-0
  :~# dpkg -i apache2_2.4.29-1ubuntu4.8_amd64.deb 
apache2-bin_2.4.29-1ubuntu4.8_amd64.deb apache2-data_2.4.29-1ubuntu4.8_all.deb 
apache2-utils_2.4.29-1ubuntu4.8_amd64.deb

  :~# dpkg -l | grep apache2
  ii  apache2  2.4.29-1ubuntu4.8   amd64Apache HTTP Server
  ii  apache2-bin  2.4.29-1ubuntu4.8   amd64Apache HTTP Server 
(modules and other binary files)
  ii  apache2-data 2.4.29-1ubuntu4.8   all  Apache HTTP Server 
(common files)
  ii  apache2-utils2.4.29-1ubuntu4.8   amd64Apache HTTP Server 
(utility programs for web servers)

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  - -

  :~# vim /etc/apache2/sites-available/management.conf
  
  Servername 127.0.0.1
  ServerAdmin root@localhost

  
  SetHandler balancer-manager
  Require local
  #Require ip 192.168.56.0/24 127.0.0.1/24
  Require all granted
  

  LogLevel warn
  ErrorLog ${APACHE_LOG_DIR}/management_error.log
  CustomLog ${APACHE_LOG_DIR}/management_access.log combined

  

  # vim: syntax=apache ts=4 sw=4 sts=4 sr noet

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  - -

  :~# vim /etc/apache2/sites-available/proxytest.conf
  
  BalancerMember "http://192.168.168.130/test;
  BalancerMember "http://192.168.168.131/test; status=+H
  ProxySet lbmethod=bybusyness
  

  
  ServerAdmin root@localhost
  ServerName testapp01
  ServerAlias 127.0.0.1:8100

  ProxyPass   "/test" "balancer://test"
  ProxyPassReverse"/test" "balancer://test"

  CustomLog ${APACHE_LOG_DIR}/test-access.log combined
  ErrorLog  ${APACHE_LOG_DIR}/test-error.log

  

  # vim: syntax=apache ts=4 sw=4 sts=4 sr noet

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  - -

  :~# a2enmod proxy_balancer proxy_http lbmethod_bybusyness lbmethod_byrequests
  :~# a2ensite management proxytest

  :~# vim /etc/apache2/ports.conf
  [...]
  Listen 81
  Listen 8100

  :~# systemctl restart apache2

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  - -

  At that point i install also some console Browsers for testing.

  :~# apt-get install lynx elinks

  :~# tail -f /var/log/apache2/management_error.log

  :~# elinks 127.0.0.1:81/balancer-manager
  :~# lynx 127.0.0.1:81/balancer-manager

  i can do update the Load and made changes. i also connect from outside with
  Firefox

  http://192.168.56.211:81/balancer-manager

  all this creates no error log entrys, the log is still empty

  -

  update apache

  :~# apt-get update
  :~# apt-get upgrade

  :~# dpkg -l | grep apache2
  ii  apache22.4.29-1ubuntu4.10  amd64Apache HTTP Server
  ii  apache2-bin2.4.29-1ubuntu4.10  amd64Apache HTTP Server 
(modules and other binary files)
  ii  apache2-data   2.4.29-1ubuntu4.10  all  Apache HTTP Server 
(common files)
  ii  apache2-utils  2.4.29-1ubuntu4.10  amd64Apache HTTP Server 
(utility programs for web servers)

  
  do the same with all the Browsers and have 

[Group.of.nepali.translators] [Bug 1455818] Re: [SRU] mysql-server-5.6.postrm fails when /usr/share/mysql-common/configure-symlinks doesn't exist

[Christian Ehrhardt ]

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

** This bug has been marked a duplicate of bug 1771630
   package mysql-server-5.7 (not installed) failed to install/upgrade: 
installed mysql-server-5.7 package post-installation script subprocess returned 
error exit status 127

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1455818

Title:
  [SRU] mysql-server-5.6.postrm fails when /usr/share/mysql-common
  /configure-symlinks doesn't exist

Status in mysql-5.6 package in Ubuntu:
  Fix Released
Status in mysql-5.7 package in Ubuntu:
  Invalid
Status in mysql-5.6 source package in Vivid:
  Won't Fix
Status in mysql-5.7 source package in Vivid:
  Won't Fix
Status in mysql-5.6 source package in Wily:
  Won't Fix
Status in mysql-5.7 source package in Wily:
  Won't Fix
Status in mysql-5.7 source package in Xenial:
  Invalid

Bug description:
  It's impossible to install, upgrade, or even remove mysql 5.6 from my
  system. At this point, also blocking other package removals.

  apt-get install -f won't repair this broken package either.

  ProblemType: Package
  DistroRelease: Ubuntu 15.04
  Package: mysql-server-5.6 5.6.24-0ubuntu2
  ProcVersionSignature: Ubuntu 3.19.0-17.17-generic 3.19.6
  Uname: Linux 3.19.0-17-generic x86_64
  NonfreeKernelModules: nvidia wl
  ApportVersion: 2.17.2-0ubuntu1
  AptOrdering:
   mysql-server-5.6: Remove
   NULL: ConfigurePending
  Architecture: amd64
  Date: Sat May 16 18:22:19 2015
  DpkgTerminalLog:
   Removing mysql-server-5.6 (5.6.24-0ubuntu2) ...
   /var/lib/dpkg/info/mysql-server-5.6.postrm: line 53: 
/usr/share/mysql-common/configure-symlinks: No such file or directory
   dpkg: error processing package mysql-server-5.6 (--remove):
subprocess installed post-removal script returned error exit status 1
  DuplicateSignature: package:mysql-server-5.6:5.6.24-0ubuntu2:subprocess 
installed post-removal script returned error exit status 1
  ErrorMessage: subprocess installed post-removal script returned error exit 
status 1
  InstallationDate: Installed on 2014-01-27 (474 days ago)
  InstallationMedia: Xubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016)
  RelatedPackageVersions:
   dpkg 1.17.25ubuntu1
   apt  1.0.9.7ubuntu4
  SourcePackage: mysql-5.6
  Title: package mysql-server-5.6 5.6.24-0ubuntu2 failed to install/upgrade: 
subprocess installed post-removal script returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.apparmor.d.usr.sbin.mysqld: 2015-03-25T14:49:33
  mtime.conffile..etc.init.d.mysql: 2015-03-25T14:28:21

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1455818/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1903978] [NEW] New upstream microreleases 9.5.24 10.15, 12.5 and 13.1

[Christian Ehrhardt ]

Public bug reported:

[Impact]

 * MRE for latest stable fixes of Postgres release on August 13th.

[Test Case]

 * The Postgres MREs traditionally rely on the large set of autopkgtests
   to run for verification. In a PPA those are all already pre-checked to
   be good for this upload.

[Regression Potential]

 * Upstreams tests are usually great and in additon in the Archive there
   are plenty of autopkgtests that in the past catched issues before being
   released.
   But never the less there always is a risk for something to break. Since
   these are general stable releases I can't pinpoint them to a most-likely
   area.
   - usually this works smoothly except a few test hickups (flaky) that need to 
be
 clarified to be sure. Pre-checks will catch those to be discussed upfront 
(as last time)

[Other Info]

 * This is a reoccurring MRE, see below and all the references
 * This includes a fix for CVE:
   CVE-2020-25695

---

Current versions in supported releases:
 postgresql-9.5 | 9.5.23-0ubuntu0.16.04.1 | xenial-updates
 postgresql-10 | 10.14-0ubuntu0.18.04.1 | bionic-updates
 postgresql-12 | 12.4-0ubuntu0.20.04.1 | focal-updates
 postgresql-12 | 12.4-1| groovy
 postgresql-13 | 13.0-6build1 | hirsute-proposed/universe

Special cases:
- Hirsute will as usual be synced from Debian.
   I already see
   postgresql-13 | 13.1-1| unstable| source, amd64, arm64, 
armhf, i386, ppc64el, s390x
- 21.04 also has a postgresql-12 and while that is on the way to be
  removed and fulyl replaced by 13 that is too far out. Therefore we will
  upload 12.5 to Hirsute as well.
- I have checked with Debian (they are affected by the same FTFBS and test 
  fails of bug 1903573) but they will just remove postgresql-12 from 
  testing. We can't do that yet on hirsute without breaking too much

Last relevant related stable updates: 9.5.23, 10.14 and 12.4
You'll see that the last update was missed, so I'll combined them.

Standing MRE - Consider last updates as template:
- pad.lv/1637236
- pad.lv/1664478
- pad.lv/1690730
- pad.lv/1713979
- pad.lv/1730661
- pad.lv/1747676
- pad.lv/1752271
- pad.lv/1786938
- pad.lv/1815665
- pad.lv/1828012
- pad.lv/1833211
- pad.lv/1839058
- pad.lv/1863108
- pad.lv/1892335

As usual we test and prep from the PPA and then push through
SRU/Security as applicable.

** Affects: postgresql-9.5 (Ubuntu Xenial)
 Importance: Undecided
 Status: Triaged

** Affects: postgresql-10 (Ubuntu Bionic)
 Importance: Undecided
 Status: Triaged

** Affects: postgresql-12 (Ubuntu Focal)
 Importance: Undecided
 Status: Triaged

** Affects: postgresql-12 (Ubuntu Groovy)
 Importance: Undecided
 Status: Triaged

** Affects: postgresql-12 (Ubuntu Hirsute)
 Importance: Undecided
 Status: Triaged

** Affects: postgresql-13 (Ubuntu Hirsute)
 Importance: Undecided
 Status: In Progress

** Changed in: postgresql-10 (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: postgresql-12 (Ubuntu Focal)
   Status: New => Triaged

** Changed in: postgresql-12 (Ubuntu Groovy)
   Status: New => Triaged

** Changed in: postgresql-13 (Ubuntu Hirsute)
   Status: New => Triaged

** Changed in: postgresql-9.5 (Ubuntu Xenial)
   Status: New => Triaged

** No longer affects: postgresql-12 (Ubuntu)

** Changed in: postgresql-12 (Ubuntu Hirsute)
   Status: New => Invalid

** Changed in: postgresql-12 (Ubuntu Hirsute)
   Status: Invalid => Won't Fix

** Description changed:

  [Impact]
  
-  * MRE for latest stable fixes of Postgres release on August 13th.
+  * MRE for latest stable fixes of Postgres release on August 13th.
  
  [Test Case]
  
-  * The Postgres MREs traditionally rely on the large set of autopkgtests
-to run for verification. In a PPA those are all already pre-checked to
-be good for this upload.
+  * The Postgres MREs traditionally rely on the large set of autopkgtests
+    to run for verification. In a PPA those are all already pre-checked to
+    be good for this upload.
  
  [Regression Potential]
  
-  * Upstreams tests are usually great and in additon in the Archive there
-are plenty of autopkgtests that in the past catched issues before being
-released.
-But never the less there always is a risk for something to break. Since
-these are general stable releases I can't pinpoint them to a most-likely
-area.
-- usually this works smoothly except a few test hickups (flaky) that need 
to be
-  clarified to be sure. Pre-checks will catch those to be discussed 
upfront (as last time)
+  * Upstreams tests are usually great and in additon in the Archive there
+    are plenty of autopkgtests that in the past catched issues before being
+    released.
+    But never the less there always is a risk for something to break. Since
+    these are general stable releases I can't pinpoint them to a most-likely
+    area.
+    - usually this works smoothly except a few 

[Group.of.nepali.translators] [Bug 1734225] Re: Invalid service name defined in /etc/ctdb/events.d/50.samba

[Christian Ehrhardt ]

Hi,
coming by here after no movement for a while as this was forgotten.
o/ Karl :-)

This was fixed in 2%4.5.2+dfsg-1.
Commit:
https://git.samba.org/samba.git/?p=samba.git;a=commit;h=385aef614034a3f32276e19312f089990e6dbb85
Which made it into 4.5-stable as
https://git.samba.org/samba.git/?p=samba.git;a=commit;h=9cc435fdd602a5e2dee26e106e874e5c2ae5b8b5

Trusty is no more active, especially not for a low prio bug - so Won't
Fix there, but easy to prep for Xenial.

Repro:
1. install ctdb and samba
2. verify that the "correct" service names on xenial are smbd and nmbd
   systemctl status smbd nmbd
   while OTOH
   systemctl status samba won't show an active service
3. check the config of ctbd in /etc/ctdb/events.d/50.samba
   It should refer to smbd and nmbd

** Changed in: samba (Ubuntu Xenial)
 Assignee: Karl Stenerud (kstenerud) => Christian Ehrhardt  (paelzer)

** Changed in: samba (Ubuntu Trusty)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1734225

Title:
  Invalid service name defined in /etc/ctdb/events.d/50.samba

Status in samba package in Ubuntu:
  Fix Released
Status in samba source package in Trusty:
  Won't Fix
Status in samba source package in Xenial:
  Triaged

Bug description:
  [Impact]

   * samba/nmbd Service names as referenced by ctdb default config are
  wrong

   * Due to that ctdb deployments start the wrong init script which is
  bad.

   * Backport a later fix of >=4.5.2 to fix the issue

  
  [Test Case]

  1. install ctdb and samba
  $  apt install ctdb samba
  2. verify that the "correct" service names on xenial are smbd and nmbd
 $ systemctl status smbd nmbd
 while OTOH
 $ systemctl status samba won't show an active service
  3. check the config of ctbd 
 $ vim /etc/ctdb/events.d/50.samba
 It should refer to smbd and nmbd for "debian" based systems

  [Regression Potential]

   * This doesn't work without the fix, so we can't regress people relying 
 on it. Much more likely we have people that tripped over it in the past 
 and fixed it themselves which now might be behavior-affected in some 
 way. But even that should be safe because:
  a) user didn't care about the issue -> didn't change -> now gets the 
 fix as the conffile is the default
  b) user did care about the issue -> adapted the .conf and will now get
 an upgrade prompt
  c) user did care about the issue -> adapted the variable in anotther 
 place -> this makes use of bash's "use this if not set" mechanism 
 so the overrides of those users should not be affected.

  [Other Info]
   
   * n/a



  ---

  
  The CTDB deployed /etc/ctdb/events.d/50.samba script contain the following 
code to detect the smbd/nmbd service name:
  ---
  case $CTDB_INIT_STYLE in
  suse)
  CTDB_SERVICE_SMB=${CTDB_SERVICE_SMB:-smb}
  CTDB_SERVICE_NMB=${CTDB_SERVICE_NMB:-nmb}
  ;;
  debian)
  CTDB_SERVICE_SMB=${CTDB_SERVICE_SMB:-samba}
  CTDB_SERVICE_NMB=${CTDB_SERVICE_NMB:-""}
  ;;
  *)
  # Use redhat style as default:
  CTDB_SERVICE_SMB=${CTDB_SERVICE_SMB:-smb}
  CTDB_SERVICE_NMB=${CTDB_SERVICE_NMB:-""}
  ;;
  esac
  ---

  It detects Ubuntu as Debian (/etc/ctdb/functions) and so define that
  the smb service is named "samba" and the nmb service does not exists.

  That could be OK since Samba deploy an "samba" init script as well as
  smbd and nmbd. Except, this init script does not really work to start
  smbd and nmbd.

  To make CTDB happy, the previous code must be modified:
  --- 50.samba.orig 2017-11-23 23:34:35.146314429 +
  +++ 50.samba  2017-11-23 23:35:08.161814684 +
  @@ -14,8 +14,8 @@
     CTDB_SERVICE_NMB=${CTDB_SERVICE_NMB:-nmb}
     ;;
    debian)
  - CTDB_SERVICE_SMB=${CTDB_SERVICE_SMB:-samba}
  - CTDB_SERVICE_NMB=${CTDB_SERVICE_NMB:-""}
  + CTDB_SERVICE_SMB=smbd
  + CTDB_SERVICE_NMB=nmbd
     ;;
    *)
     # Use redhat style as default:

  I reproduced this issue on both Ubuntu 16.04 and 14.04. But it does
  not exists on Debian Stretch (the 50.samba has been updated).

  An easier workaround to avoid updating the 50.samba script is to set
  those 2 service name in the /etc/default/ctdb:

  CTDB_SERVICE_SMB=smbd
  CTDB_SERVICE_NMB=nmbd

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of

[Group.of.nepali.translators] [Bug 857651] Re: Unable to hide users from login screen / user switcher

[Christian Ehrhardt ]

Since so many components are involved a fix/change might have been missed.
And since I recently didn't hear anything about this otherwise rather hot bug I 
was giving focal a try.

It turns out that this was indeed improved. Only the user of pkg:ifmail user 
fdt name "Fidonet" is still visible. All other formerly affected packages are 
good in Focal.
I can't (without digging through history a lot) say what fixed that but I'll 
update the bug tasks accordingly. Setting Focal fixed and marking Bionic/Xenial 
as still affected releases.
The backport tasks for those packages are incomplete thou as it is unclear 
which change in which package fixed it for Focal.

Note: This is only speaking for the "default config" of Ubuntu Desktop
as in 20.04 we know that certain environments will behave differently
(e.g. KDE never was affected).

** Also affects: ifmail (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: ceph (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

** Also affects: accountsservice (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: netqmail (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: sddm (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: ifmail (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: ceph (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Also affects: accountsservice (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: netqmail (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: sddm (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** No longer affects: accountsservice (Ubuntu Xenial)

** No longer affects: accountsservice (Ubuntu Bionic)

** Changed in: ceph (Ubuntu Xenial)
   Status: New => Incomplete

** Changed in: ceph (Ubuntu Bionic)
   Status: New => Incomplete

** Changed in: ceph (Ubuntu)
   Status: Triaged => Fix Released

** No longer affects: ifmail (Ubuntu Xenial)

** No longer affects: ifmail (Ubuntu Bionic)

** No longer affects: lightdm (Ubuntu Xenial)

** No longer affects: lightdm (Ubuntu Bionic)

** Changed in: libvirt (Ubuntu)
   Status: Triaged => Fix Released

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Incomplete

** Changed in: libvirt (Ubuntu Bionic)
   Status: New => Incomplete

** Changed in: netqmail (Ubuntu Xenial)
   Status: New => Incomplete

** Changed in: netqmail (Ubuntu Bionic)
   Status: New => Incomplete

** Changed in: netqmail (Ubuntu)
   Status: Triaged => Fix Released

** No longer affects: sddm (Ubuntu Xenial)

** No longer affects: sddm (Ubuntu Bionic)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/857651

Title:
  Unable to hide users from login screen / user switcher

Status in accountsservice:
  Unknown
Status in SDDM:
  Fix Released
Status in accountsservice package in Ubuntu:
  Triaged
Status in ceph package in Ubuntu:
  Fix Released
Status in ifmail package in Ubuntu:
  Triaged
Status in libvirt package in Ubuntu:
  Fix Released
Status in lightdm package in Ubuntu:
  Triaged
Status in netqmail package in Ubuntu:
  Fix Released
Status in sddm package in Ubuntu:
  Fix Released
Status in ceph source package in Xenial:
  Incomplete
Status in libvirt source package in Xenial:
  Incomplete
Status in netqmail source package in Xenial:
  Incomplete
Status in ceph source package in Bionic:
  Incomplete
Status in libvirt source package in Bionic:
  Incomplete
Status in netqmail source package in Bionic:
  Incomplete

Bug description:
  Users that I have appended to the 'hidden-users' field in
  /etc/lightdm/users.conf are not actually hidden. They are still listed
  on the login screen and in Unity's user switching menu.

  ProblemType: Bug
  DistroRelease: Ubuntu 11.10
  Package: lightdm 0.9.7-0ubuntu1
  ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
  Uname: Linux 3.0.0-11-generic x86_64
  ApportVersion: 1.23-0ubuntu1
  Architecture: amd64
  Date: Fri Sep 23 11:44:29 2011
  InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Beta amd64 (20110413)
  SourcePackage: lightdm
  UpgradeStatus: Upgraded to oneiric on 2011-09-23 (0 days ago)
  mtime.conffile..etc.lightdm.users.conf: 2011-09-23T08:46:55.039175

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

___
Mailing 

[Group.of.nepali.translators] [Bug 1894942] Re: [UBUNTU 20.04] Lost virtio host --> guest notifications cause devices to cease normal operation

[Christian Ehrhardt ]

Hi,
the patches LGTM and I'll make it part of the Ubuntu builds.

One question thou: on one hand "occasionally end up with" sounds like this is 
almost impossible to explicitly test, but then the attached debug patch 
suggests there might be a way to trigger this through protvirt.
But even if that is the case backporting it to all kind of older versions there 
is no protvirt.
So I wanted to ask:
a) is there any way to reliably trigger this for A/B testing of the fix as far 
back as qemu 2.5?
b) how real is the danger to hit and consequences of this in the pre-protvirt 
(= Incomplete

** Changed in: qemu (Ubuntu Bionic)
   Status: New => Incomplete

** Changed in: qemu (Ubuntu Focal)
   Status: New => Triaged

** Changed in: qemu (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: qemu (Ubuntu)
   Importance: Undecided => High

** Changed in: qemu (Ubuntu)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1894942

Title:
  [UBUNTU 20.04] Lost virtio host --> guest notifications cause devices
  to cease normal operation

Status in Ubuntu on IBM z Systems:
  New
Status in qemu package in Ubuntu:
  In Progress
Status in qemu source package in Xenial:
  Incomplete
Status in qemu source package in Bionic:
  Incomplete
Status in qemu source package in Focal:
  Triaged

Bug description:
  Problem Description:

  When irqfds are not used setting of the adapter interruption
  host-->guest notifier bit is accomplished by the QEMU function
  virtio_set_ind_atomic().

  The atomic_cmpxchg() loop in virtio_set_ind_atomic() is broken because we 
occasionally end up with old and _old having different values (a legit compiler 
can generate code that accessed *ind_addr again to pick up a value for _old 
instead of using the value of old that was already fetched according to the 
rules of the abstract machine). This means the underlying CS instruction may 
use a different old (_old) than the one we intended to use if atomic_cmpxchg() 
performed the xchg part.
  
  The direct consequence of the problem is that host --> guest notifications 
can get lost. The indirect consequence is that queues may get stuck and the 
devices may cease operate normally. We stumbled on debugging a choked 
virtio-net interface (one that used the qemu driver and not vhost). But it can 
affect other virtio-ccw devices as well. 

  If irqfds are used for host->guest notifications, then we are safe
  because notifier bit manipulation is done in the kernel (and it's done
  correctly).

  
  The problem described above is fixed upstream by commit.

  1a8242f7c3 ("virtio-ccw: fix virtio_set_ind_atomic")

  All upstream versions since v2.0.0 are (potentially) affected.

  The same mistake was made in QEMU in another place, and is fixed by:

  45175361f1 ("s390x/pci: fix set_ind_atomic")

  We can file a separate BZ for it if necessary.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1894942/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux

[Christian Ehrhardt ]

** Changed in: openldap (Ubuntu Trusty)
   Status: Confirmed => Won't Fix

** Changed in: openldap (Ubuntu Trusty)
 Assignee: Sergio Durigan Junior (sergiodj) => (unassigned)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1557157

Title:
  apparmor profile denied for saslauthd: /run/saslauthd/mux

Status in openldap package in Ubuntu:
  Confirmed
Status in openldap source package in Trusty:
  Won't Fix
Status in openldap source package in Xenial:
  Confirmed
Status in openldap source package in Bionic:
  Confirmed
Status in openldap source package in Focal:
  Confirmed
Status in openldap source package in Groovy:
  Confirmed

Bug description:
  [Impact]

  When using openldap with sasl authentication, the slapd process will
  communicate with the saslauthd daemon via a socket in
  {,/var}/run/saslauthd/mux. Unfortunately, this will fail in every
  Ubuntu release from trusty onwards, because slapd's apparmor profile
  doesn't contain the necessary directive to allow it to read/write
  from/to the socket specified above.

  The fix is simple: just add the necessary directive to allow slapd to
  read/write from/to the saslauthd socket.

  [Test Case]

  One can reproduce the problem by doing:

  $ lxc launch ubuntu-daily:groovy openldap-bugbug1557157-groovy
  $ lxc shell openldap-bugbug1557157-groovy
  # apt install slapd sasl2-bin ldap-utils apparmor-utils

  (As the domain name, use "example.com").

  # sed -i -e 's/^START=.*/START=yes/' /etc/default/saslauthd
  # cat > /etc/ldap/sasl2/slapd.conf << __EOF__
  mech_list: PLAIN
  pwcheck_method: saslauthd
  __EOF__
  # adduser openldap sasl
  # aa-enforce /etc/apparmor.d/usr.sbin.slapd
  # systemctl restart slapd.service
  # systemctl restart saslauthd.service
  # passwd root

  (You can choose any password here. You will need to type it when
  running the next command.)

  # ldapsearch -H ldapi:/// -LLL -b 'dc=example,dc=com' -s base -U root
  -Y PLAIN

  The command will fail with something like:

  ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
  additional info: SASL(-1): generic failure: Password verification 
failed

  [Regression Potential]

  This is an extremely simple and well contained fix, so I don't
  envision any possible regressions after applying it.  It is important
  noticing that, since the problem affects older Ubuntu releases, the
  openldap package will have to be rebuilt against possible newer
  versions of libraries and other depencencies, which, albeit unlikely,
  may cause issues.

  [Original Description]

  When using slapd with saslauthd the processes communicate via the
  {,/var}/run/saslauthd/mux socket (this is the default location for the
  saslauthd server from the sasl2-bin package in the
  /etc/default/saslauthd config), but the apparmor profile for
  usr.sbin.slapd does not allow access to this socket/file.

  Syslog message:
  apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd" 
name="/run/saslauthd/mux" pid=1880
  4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0

  Please add the following line to  /etc/apparmor.d/usr.sbin.slapd:
  /{,var/}run/saslauthd/mux rw,

  Ubuntu version: Ubuntu 14.04.4 LTS
  slapd version: 2.4.31-1+nmu2ubu

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1875299] Re: Apache's mod_remoteip: IP address spoofing via X-Forwarded-For when mod_rewrite rule is triggered

[Christian Ehrhardt ]

** Changed in: apache2 (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1875299

Title:
  Apache's mod_remoteip: IP address spoofing via X-Forwarded-For when
  mod_rewrite rule is triggered

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  Triaged
Status in apache2 package in Debian:
  New

Bug description:
  There is a bug in mod_remoteip (a part of Apache Web Server): 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60251
  Although the status of this bug is "NEW", actually it was fixed in Apache 
2.4.24.
  Although a CVE id was not requested yet, actually it is a vulnerability.

  The fix was not backported to Ubuntu 16.04 (xenial).

  Impact: if a victim uses Apache rewrite rules, then an attacker can
  spoof his IP address for logs and PHP scripts.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: apache2 2.4.18-2ubuntu3.14
  ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
  Uname: Linux 4.4.0-22-generic x86_64
  Apache2ConfdDirListing: False
  ApportVersion: 2.20.1-0ubuntu2.23
  Architecture: amd64
  Date: Mon Apr 27 13:17:43 2020
  SourcePackage: apache2
  UpgradeStatus: No upgrade log present (probably fresh install)
  error.log:
   
  modified.conffile..etc.apache2.apache2.conf: [modified]
  modified.conffile..etc.apache2.mods-available.dir.conf: [modified]
  modified.conffile..etc.apache2.mods-available.ssl.conf: [modified]
  modified.conffile..etc.apache2.ports.conf: [modified]
  modified.conffile..etc.apache2.sites-available.000-default.conf: [modified]
  modified.conffile..etc.apache2.sites-available.default-ssl.conf: [modified]
  mtime.conffile..etc.apache2.apache2.conf: 2020-04-23T15:45:48.416970
  mtime.conffile..etc.apache2.mods-available.dir.conf: 
2020-04-23T12:03:13.711062
  mtime.conffile..etc.apache2.mods-available.ssl.conf: 
2020-04-23T12:02:44.854484
  mtime.conffile..etc.apache2.ports.conf: 2020-04-23T15:45:48.169037
  mtime.conffile..etc.apache2.sites-available.000-default.conf: 
2020-04-23T15:45:48.197030
  mtime.conffile..etc.apache2.sites-available.default-ssl.conf: 
2020-04-23T15:45:48.225022

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1874257] Re: SSH fails with connection timed out - in VPN and hangs here "expecting SSH2_MSG_KEX_ECDH_REPLY" + Ubuntu 16.04.6 LTS

[Christian Ehrhardt ]

Yeah Dan, thanks for chiming in.
In particular that would be at least (but not lmited to) the changes:

8.04
Rework DTLS MTU detection. (#10)
7.08
Support automatic DTLS MTU detection with OpenSSL.
7.07
Automatic DTLS MTU detection.

Ubuntu has these newer versions.
Bionic 18.04 is on 7.08 and the most recent LTS Focal is at 8.05.
The current development release is at the latest 8.09 of openconnect.

These are new features added in 7.07 and 7.08 - IMHO they do not qualify
for a SRU release into Xenial [1] - especially since you can "get away"
with a config change that mitigates the issue.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates

** Also affects: openssh (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Also affects: openconnect (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** No longer affects: linux (Ubuntu Xenial)

** No longer affects: openssh (Ubuntu Xenial)

** Changed in: openssh (Ubuntu)
   Status: Confirmed => Invalid

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

** Changed in: openconnect (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: openconnect (Ubuntu Xenial)
   Importance: Undecided => Wishlist

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1874257

Title:
  SSH fails with connection timed out - in VPN and hangs here "expecting
  SSH2_MSG_KEX_ECDH_REPLY" + Ubuntu 16.04.6 LTS

Status in linux package in Ubuntu:
  Invalid
Status in openconnect package in Ubuntu:
  Fix Released
Status in openssh package in Ubuntu:
  Invalid
Status in openconnect source package in Xenial:
  Confirmed

Bug description:
  Hello Team,

  SSH timeout issue, once connect to VPN.

  Environment

  ==
  Dell XPS 9570 
  Ubuntu 16.04.6 Xenial Xerus)
  kernel - 4.15.0-55-generic

  $dpkg -l | grep -i openssh
  ii  openssh-client 1:7.2p2-4ubuntu2.8  --> 
  ii  openssh-server 1:7.2p2-4ubuntu2.8  
  ii  openssh-sftp-server  1:7.2p2-4ubuntu2.8

  
  VPN tunnel info 
  
  vpn0  Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:IP  P-t-P:xx  Mask:255.255.252.0
inet6 addr: fe80::b8e2:bea4:2e62:fe08/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1406  Metric:1
RX packets:962 errors:0 dropped:0 overruns:0 frame:0
TX packets:1029 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:87839 (87.8 KB)  TX bytes:238740 (238.7 KB)

  Issue
  
  Unable to connect to any host via ssh or sftp after VPN connection 

  Tried 
  =

  Reinstalled the openssh-client package and still no luck. May I know
  why the default cipher is not taking/hanging? Please let me know .
  There were no recent changes.

  
  Workaround
  ===
  Able to connect to ssh / sftp $ssh -c aes128-ctr   user@IP

  
  Below is the debug ssh client logs ===
  ==

  $ssh -vvv  user@ip
  OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g  1 Mar 2016
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: Applying options for *
  debug2: resolving "IP" port 22
  debug2: ssh_connect_direct: needpriv 0
  debug1: Connecting to IP [IP] port 22.
  debug1: Connection established.
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_rsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_rsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_dsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_dsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_ecdsa type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_ed25519 type -1
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
  debug1: Enabling compatibility mode for protocol 2.0
  debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
  debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 
Ubuntu-4ubuntu0.3
  debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH* compat 0x0400
  debug2: fd 3 setting O_NONBLOCK
  debug1: Authenticating to IP:22 as 'user'
  debug3: send packet: type 20
  debug1: SSH2_MSG_KEXINIT sent
  debug3: receive packet: type 20
  debug1: SSH2_MSG_KEXINIT received
  debug2: local client KEXINIT proposal
  debug2: KEX 

[Group.of.nepali.translators] [Bug 1413379] Re: boinc doesn't always detect Virtualbox

[Christian Ehrhardt ]

Since >=7.9.3 is mentioned to be good this seems only to still affect
Xenial.

** Also affects: boinc (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1413379

Title:
  boinc doesn't always detect Virtualbox

Status in Boinc:
  Fix Released
Status in boinc package in Ubuntu:
  Fix Released
Status in boinc source package in Xenial:
  New

Bug description:
  The BOINC client does not always successfully detect Virtualbox,
  though Virtualbox does start successfully each time.

  15-Jan-2015 12:53:29 [---] VirtualBox version: 4.3.20r96996
  16-Jan-2015 11:26:36 [---] VirtualBox version: WARNING: The vboxdrv kernel 
module is not loaded. Either there is no module
  17-Jan-2015 13:31:43 [---] VirtualBox version: 4.3.20r96996
  18-Jan-2015 09:41:57 [---] VirtualBox version: 4.3.20r96996
  18-Jan-2015 22:43:25 [---] VirtualBox version: 4.3.20r96996
  19-Jan-2015 14:40:57 [---] VirtualBox version: 4.3.20r96996
  19-Jan-2015 20:45:52 [---] VirtualBox version: 4.3.20r96996
  19-Jan-2015 21:38:36 [---] VirtualBox version: 4.3.20r96996
  19-Jan-2015 22:27:01 [---] VirtualBox version: WARNING: The vboxdrv kernel 
module is not loaded. Either there is no module
  20-Jan-2015 00:42:59 [---] VirtualBox version: 4.3.20r96996
  20-Jan-2015 14:23:18 [---] VirtualBox version: WARNING: The vboxdrv kernel 
module is not loaded. Either there is no module
  20-Jan-2015 21:25:13 [---] VirtualBox version: WARNING: The vboxdrv kernel 
module is not loaded. Either there is no module
  20-Jan-2015 22:24:35 [---] VirtualBox version: WARNING: The vboxdrv kernel 
module is not loaded. Either there is no module
  20-Jan-2015 23:01:51 [---] VirtualBox version: WARNING: The vboxdrv kernel 
module is not loaded. Either there is no module
  20-Jan-2015 23:12:46 [---] VirtualBox version: WARNING: The vboxdrv kernel 
module is not loaded. Either there is no module
  21-Jan-2015 12:59:39 [---] VirtualBox version: WARNING: The vboxdrv kernel 
module is not loaded. Either there is no module
  21-Jan-2015 13:21:59 [---] VirtualBox version: 4.3.20r96996
  21-Jan-2015 20:01:22 [---] VirtualBox version: 4.3.20r96996
  21-Jan-2015 20:10:16 [---] VirtualBox version: 4.3.20r96996

  To work around I changed the start sequence of the init script:

  # mv 20boinc-client 80boinc-client

  It would appear that boinc starts too early in the boot sequence.

  $ cd /etc/rc2.d
  $ ls S*
  S01policykit S20hotkey-setup   S20winbind  
S50rsync S99acpi-support
  S10apmd  S20kerneloops S24dhcdbd   
S70dns-clean S99grub-common
  S20clamav-daemon S20nbd-server S35vboxautostart-service
S70pppd-dns  S99ondemand
  S20clamav-freshclam  S20openbsd-inetd  S35vboxballoonctrl-service  
S75sudo  S99rc.local
  S20fancontrolS20speech-dispatcher  S35vboxweb-service  
S80boinc-client
  S20hddtemp   S20vboxdrvS50pulseaudio   
S95distcc

To manage notifications about this bug go to:
https://bugs.launchpad.net/boinc-upstream/+bug/1413379/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1877454] Re: openssh-server hangs with AuthorizedKeysCommand

[Christian Ehrhardt ]

Thanks for the report Jeremy,
The fix is in V_7_5_P1 and by that >=Bionic is fixed - I agree to you this only 
has to target Xenial.

** Tags added: bitesize server-next

** Also affects: openssh (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Changed in: openssh (Ubuntu Xenial)
   Importance: Undecided => Medium

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1877454

Title:
  openssh-server hangs with AuthorizedKeysCommand

Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Xenial:
  Confirmed

Bug description:
  Please consider applying this change to openssh-server distributed in Xenial 
(16.04).
  Without it, sshd can sporadically hang when making use of the 
`AuthorizedKeysCommand` option.

  https://github.com/openssh/openssh-
  portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1680115] Re: mysql-systemd-start script does not work with datadir other than /var/lib/mysql

[Christian Ehrhardt ]

** Also affects: mysql-8.0 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: mysql-8.0 (Ubuntu)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1680115

Title:
  mysql-systemd-start script does not work with datadir other than
  /var/lib/mysql

Status in Ubuntu Server Guide:
  Invalid
Status in mysql-8.0 package in Ubuntu:
  Invalid
Status in mysql-8.0 source package in Xenial:
  New

Bug description:
  The /usr/share/mysql/mysql-systemd-start script does not work with
  datadir other than /var/lib/mysql because the datadir path is
  hardcoded in the script.

  Fix:

  Replace...

  sanity () {
if [ ! -r /etc/mysql/my.cnf ]; then
  echo "MySQL configuration not found at /etc/mysql/my.cnf. Please create 
one."
  exit 1
fi

if [ ! -d /var/lib/mysql ] && [ ! -L /var/lib/mysql ]; then
  echo "MySQL data dir not found at /var/lib/mysql. Please create one."
  exit 1
fi

if [ ! -d /srv/data/mysql/mysql ] && [ ! -L /srv/data/mysql/mysql ]; then
  echo "MySQL system database not found. Please run mysql_install_db tool."
  exit 1
fi
  }

  ...with...

  sanity () {
if [ ! -r /etc/mysql/my.cnf ]; then
  echo "MySQL configuration not found at /etc/mysql/my.cnf. Please create 
one."
  exit 1
fi

_DATADIR="$(mysqld --verbose --help | grep -i '^datadir' | awk
  '{print $2}' | sed 's|/$||')"

if [ ! -d $_DATADIR ] && [ ! -L _DATADIR ]; then
  echo "MySQL data dir not found at /var/lib/mysql. Please create one."
  exit 1
fi

if [ ! -d $_DATADIR ] && [ ! -L ${_DATADIR}/mysql ]; then
  echo "MySQL system database not found. Please run mysql_install_db tool."
  exit 1
fi
  }

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1874362] Re: xenial/man8/update-smart-drivedb.8.html incorrect

[Christian Ehrhardt ]

There were several issues with the tool to download unauthenticated data and 
such.
So it was removed in 6.4+svn4214-1 which is the one in Xenial and Bionic.

It was later introduced in an improved form in 7.0-1 therefore the
latest LTS release of ubuntu Focal is good.

** Also affects: smartmontools (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: smartmontools (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: smartmontools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1874362

Title:
  xenial/man8/update-smart-drivedb.8.html incorrect

Status in smartmontools package in Ubuntu:
  Fix Released
Status in smartmontools source package in Xenial:
  New
Status in smartmontools source package in Bionic:
  New
Status in smartmontools source package in Eoan:
  New

Bug description:
  manpage
  manpages.ubuntu.com/manpages/xenial/man8/update-smart-drivedb.8.html
  says
  Provided by: smartmontools_6.4+svn4214-1_amd64
  but
  invoking it fails with
  ~$ update-smart-drivedb
  update-smart-drivedb: command not found

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1246347] Re: Lots of "error on subcontainer 'ia_addr' insert (-1)" reports in /var/log/syslog

[Christian Ehrhardt ]

Given how low prio/heat this issue had I'm gonna mark the SRU tasks won't fix.
Triaged+Low severity would be correct as well, but that would trigger wrong 
expectations as I just see no one get to it.

That way it is clear and if this really is more painful/severe than I
thought people can speak up and outline why which then let us re-
prioritize it.

** Changed in: net-snmp (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: net-snmp (Ubuntu Bionic)
   Status: New => Won't Fix

** Changed in: net-snmp (Ubuntu Eoan)
   Status: New => Won't Fix

** Changed in: net-snmp (Ubuntu Bionic)
   Importance: Undecided => Low

** Changed in: net-snmp (Ubuntu Xenial)
   Importance: Undecided => Low

** Changed in: net-snmp (Ubuntu Eoan)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1246347

Title:
  Lots of "error on subcontainer 'ia_addr' insert (-1)" reports in
  /var/log/syslog

Status in Net-SNMP:
  Fix Released
Status in net-snmp package in Ubuntu:
  Fix Released
Status in net-snmp source package in Xenial:
  Won't Fix
Status in net-snmp source package in Bionic:
  Won't Fix
Status in net-snmp source package in Eoan:
  Won't Fix
Status in net-snmp package in Debian:
  Fix Released

Bug description:
  Lots of "error on subcontainer ‘ia_addr’ insert (-1)" reports are
  written to /var/log/syslog. The problem *seems* to be IPv6 link-local
  addresses of GRE tunnels. Several GRE tunnels have the same IPv6 link-
  local address, which should be okay (since their scope is link-local).
  However, snmpd seems to have a problem with that.

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: snmpd 5.4.3~dfsg-2.4ubuntu1.1
  ProcVersionSignature: Ubuntu 3.2.0-55.85-generic 3.2.51
  Uname: Linux 3.2.0-55-generic x86_64
  ApportVersion: 2.0.1-0ubuntu17.6
  Architecture: amd64
  Date: Wed Oct 30 15:29:46 2013
  InstallationMedia: Ubuntu-Server 12.04.1 LTS "Precise Pangolin" - Release 
amd64 (20120817.3)
  MarkForUpload: True
  SNMPVersion:
   NET-SNMP version:  5.4.3
   Web:   http://www.net-snmp.org/
   Email: net-snmp-cod...@lists.sourceforge.net
  SourcePackage: net-snmp
  SyslogSnmptrapd:
   
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.snmp.snmpd.conf: [modified]
  mtime.conffile..etc.snmp.snmpd.conf: 2013-10-11T12:02:23

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1797343] Re: Unfixed security issues CVE-2018-16758, CVE-2018-16738

[Christian Ehrhardt ]

** Also affects: tinc (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: tinc (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

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

** Changed in: tinc (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1797343

Title:
  Unfixed security issues CVE-2018-16758, CVE-2018-16738

Status in tinc package in Ubuntu:
  Fix Released
Status in tinc source package in Xenial:
  Confirmed
Status in tinc source package in Bionic:
  Confirmed

Bug description:
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16758

  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16738

  Fixed in Debian as of September 22nd. http://metadata.ftp-
  master.debian.org/changelogs//main/t/tinc/tinc_1.0.31-1+deb9u1_changelog

  And upstream in version 1.0.35

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1863108] [NEW] New upstream microreleases 9.5.21 10.12 11.7 and 12.2

[Christian Ehrhardt ]

Public bug reported:

[Impact]

 * MRE for latest stable fixes of Postgres release on Feb 13th.

[Test Case]

 * The Postgres MREs traditionally rely on the large set of autopkgtests
   to run for verification. In a PPA those are all already pre-checked to
   be good for this upload.

[Regression Potential]

 * Upstreams tests are usually great and in additon in the Archive there
   are plenty of autopkgtests that in the past catched issues before being
   released.
   But never the less there always is a risk for something to break. Since
   these are general stable releases I can't pinpoint them to a most-likely
   area.
   - usually this works smoothly except a few test hickups (flaky) that need to 
be
 clarified to be sure. Pre-checks will catch those to be discussed upfront 
(as last time)

[Other Info]

 * This is a reoccurring MRE, see below and all the references
 * This includes a fix for CVE: CVE-2020-1720 (Affects 9.6-12, so all but 
xenial)

---

Current versions in supported releases:
 postgresql-9.5 | 9.5.19-0ubuntu0.16.04 xenial
 postgresql-10 | 10.10-0ubuntu0.18.04.1 bionic
 postgresql-11 | 11.5-1eoan
 postgresql-12 | 12.1-2build1 focal

Special cases:
- Focal will as usual be synced from Debian.
   I already see 
https://buildd.debian.org/status/fetch.php?pkg=postgresql-12=s390x=12.2-1=1581600108=0

Last relevant related stable updates: 9.5.21, 10.12, 11.5 and 12.2
You'll see that the last update was missed, so I'll combined them.

Standing MRE - Consider last updates as template:
- pad.lv/1637236
- pad.lv/1664478
- pad.lv/1690730
- pad.lv/1713979
- pad.lv/1730661
- pad.lv/1747676
- pad.lv/1752271
- pad.lv/1786938
- pad.lv/1815665
- pad.lv/1828012
- pad.lv/1833211
- pad.lv/1839058

As usual we test and prep from the PPA and then push through
SRU/Security as applicable.

** Affects: postgresql-9.5 (Ubuntu Xenial)
 Importance: Undecided
 Status: Triaged

** Affects: postgresql-10 (Ubuntu Bionic)
 Importance: Undecided
 Status: Triaged

** Affects: postgresql-11 (Ubuntu Eoan)
 Importance: Undecided
 Status: Triaged

** Affects: postgresql-12 (Ubuntu Focal)
 Importance: Undecided
 Status: In Progress

** No longer affects: postgresql-11 (Ubuntu)

** Changed in: postgresql-10 (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: postgresql-11 (Ubuntu Eoan)
   Status: New => Triaged

** Changed in: postgresql-12 (Ubuntu Focal)
   Status: New => Triaged

** Changed in: postgresql-9.5 (Ubuntu Xenial)
   Status: New => Triaged

** Description changed:

  [Impact]
  
   * MRE for latest stable fixes of Postgres release on Feb 13th.
  
  [Test Case]
  
   * The Postgres MREs traditionally rely on the large set of autopkgtests
 to run for verification. In a PPA those are all already pre-checked to
 be good for this upload.
  
  [Regression Potential]
  
   * Upstreams tests are usually great and in additon in the Archive there
 are plenty of autopkgtests that in the past catched issues before being
 released.
 But never the less there always is a risk for something to break. Since
 these are general stable releases I can't pinpoint them to a most-likely
 area.
 - usually this works smoothly except a few test hickups (flaky) that need 
to be
   clarified to be sure. Pre-checks will catch those to be discussed 
upfront (as last time)
  
  [Other Info]
  
   * This is a reoccurring MRE, see below and all the references
+  * This includes a fix for CVE: CVE-2020-1720
  
  ---
  
  Current versions in supported releases:
   postgresql-9.5 | 9.5.19-0ubuntu0.16.04 xenial
   postgresql-10 | 10.10-0ubuntu0.18.04.1 bionic
   postgresql-11 | 11.5-1eoan
   postgresql-12 | 12.1-2build1 focal (will sync 12.2-1 from Debian)
  
  Special cases:
  - Focal will as usual be synced from Debian.
  
  Last relevant related stable updates: 9.5.21, 10.12, 11.5 and 12.2
  You'll see that the last update was missed, so I'll combined them.
  
  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  - pad.lv/1815665
  - pad.lv/1828012
  - pad.lv/1833211
  - pad.lv/1839058
  
  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.

** Description changed:

  [Impact]
  
   * MRE for latest stable fixes of Postgres release on Feb 13th.
  
  [Test Case]
  
   * The Postgres MREs traditionally rely on the large set of autopkgtests
 to run for verification. In a PPA those are all already pre-checked to
 be good for this upload.
  
  [Regression Potential]
  
   * Upstreams tests are usually great and in additon in the Archive there
 are plenty of autopkgtests that in the past catched issues before being
 released.
 But never the less there always is a risk for something to break. Since
 these are general stable releases 

[Group.of.nepali.translators] [Bug 1862154] Re: Syslog spammed with "domain is utf8 flagged"

[Christian Ehrhardt ]

$ git show pkg/ubuntu/bionic-devel:lib/Mail/SpamAssassin/DnsResolver.pm | grep 
"domain is utf8 flagged"
  info("dns: new_dns_packet: domain is utf8 flagged: %s", $domain);


$ git show pkg/ubuntu/eoan-devel:lib/Mail/SpamAssassin/DnsResolver.pm | grep 
"domain is utf8 flagged"
  info("dns: new_dns_packet: domain is utf8 flagged: %s", $domain);

$ git show pkg/ubuntu/focal-devel:lib/Mail/SpamAssassin/DnsResolver.pm | grep 
"domain is utf8 flagged"
  dbg("dns: new_dns_packet: domain is utf8 flagged: %s", $domain);

Upstream change is:
https://github.com/apache/spamassassin/commit/bdacc776ccbfdedee7f1e8175a333d9e419d4426

** Also affects: spamassassin (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: spamassassin (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: spamassassin (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1862154

Title:
  Syslog spammed with "domain is utf8 flagged"

Status in spamassassin package in Ubuntu:
  Fix Released
Status in spamassassin source package in Xenial:
  Triaged
Status in spamassassin source package in Bionic:
  Triaged
Status in spamassassin source package in Eoan:
  Triaged

Bug description:
  Seems that https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7632 has
  been re-introduced.

  # lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 18.04.3 LTS
  Release:  18.04
  Codename: bionic

  # apt-cache policy spamassassin
  spamassassin:
Installed: 3.4.2-0ubuntu0.18.04.3
Candidate: 3.4.2-0ubuntu0.18.04.3

  I am seeing *lots* of info logs for every email:

  Feb  6 07:30:26 spam02a spamd[11370]: dns: new_dns_packet: domain is utf8 
flagged: grace.ns.cloudflare.com
  Feb  6 07:30:26 spam02a spamd[11370]: dns: new_dns_packet: domain is utf8 
flagged: sid.ns.cloudflare.com
  Feb  6 07:30:26 spam02a spamd[11370]: dns: new_dns_packet: domain is utf8 
flagged: ns1.silverpop.com

  
  SpamAssassin/DnsResolver.pm - Line 549

  ---8<---
  if (utf8::is_utf8($domain)) {  # since Perl 5.8.1
info("dns: new_dns_packet: domain is utf8 flagged: %s", $domain);
  }
  ---8<---

  This should be a dbg flag - this is fixed in Spamassassin 3.4.4
  upstream - could we have a backport for this current version of 3.4.2?

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1856248] Re: Spamassassin needs updated to reflect security fixes

[Christian Ehrhardt ]

Hi Chris,
thanks for your report.
I checked the security Teams overview of those at
- https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-11805.html
- https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-12420.html

It seems they are still evaluating the options hence the status "needs Triage".
I'll assign this bug to ubuntu-security so that they can update this bug along 
whatever they decide on the CVE triaging.


** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-11805

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-12420

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

** Also affects: spamassassin (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: spamassassin (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: spamassassin (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: spamassassin (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: spamassassin (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Changed in: spamassassin (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: spamassassin (Ubuntu Trusty)
 Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)

** Changed in: spamassassin (Ubuntu Xenial)
 Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)

** Changed in: spamassassin (Ubuntu Bionic)
 Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)

** Changed in: spamassassin (Ubuntu Disco)
 Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)

** Changed in: spamassassin (Ubuntu Eoan)
 Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1856248

Title:
  Spamassassin needs updated to reflect security fixes

Status in spamassassin package in Ubuntu:
  Fix Released
Status in spamassassin source package in Trusty:
  New
Status in spamassassin source package in Xenial:
  New
Status in spamassassin source package in Bionic:
  New
Status in spamassassin source package in Disco:
  New
Status in spamassassin source package in Eoan:
  New

Bug description:
  lsb_release -rd
  Description: Ubuntu 18.04.3 LTS
  Release: 18.04

  apt-cache policy spamassassin
  spamassassin:
Installed: 3.4.2-0ubuntu0.18.04.1
Candidate: 3.4.2-0ubuntu0.18.04.1

  The current version of Spamassassin is 3.4.2, the newest version,
  3.4.3 fixes two security issues:

  CVE-2019-12420 for Multipart Denial of Service Vulnerability

  CVE-2018-11805 for nefarious CF files can be configured to
  run system commands without any output or errors.

  Request that Spamassassin be updated to the latest version 3.4.3 as
  soon as possible.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1707212] Re: The package doesn't set up a lua-interpreter alternative and thus doesn't seamlessly provide lua cli

[Christian Ehrhardt ]

I just acme by by accident, but wanted to update that this is fixed in
5.3.3-1 which means >=Bionic

** Also affects: lua5.3 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: lua5.3 (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1707212

Title:
  The package doesn't set up a lua-interpreter alternative and thus
  doesn't seamlessly provide lua cli

Status in lua5.3 package in Ubuntu:
  Fix Released
Status in lua5.3 source package in Xenial:
  New
Status in lua5.3 package in Debian:
  Unknown

Bug description:
  Ubuntu 17.04 Zesty amb64
  lua5.3: 5.3.3-1

  Installing other versions of the lua5.x interpreters (i.e. providers
  for the lua virtual packages) installs alternatives for the lua-
  interpreter.

  Installing lua5.3 package does not provide alternative for lua-
  interpreter but one must manually symlink /usr/bin/lu(a|ac) to
  /usr/bin/lu(a|ac)5.3.

  Note that there is an open question on Askubuntu for earlier version
  of Ubuntu:

  https://askubuntu.com/questions/850317/installing-lua5-2-vs-lua5-3-on-
  ubuntu-16-10

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua5.3/+bug/1707212/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1839058] Re: New upstream microreleases 9.5.19 10.10 and 11.5

[Christian Ehrhardt ]

** Changed in: postgresql-11 (Ubuntu)
   Status: Triaged => Fix Released

** Changed in: postgresql-11 (Ubuntu Eoan)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1839058

Title:
  New upstream microreleases 9.5.19 10.10 and 11.5

Status in postgresql-11 package in Ubuntu:
  Fix Released
Status in postgresql-9.5 source package in Xenial:
  Fix Released
Status in postgresql-10 source package in Bionic:
  Fix Released
Status in postgresql-11 source package in Disco:
  Fix Released
Status in postgresql-11 source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * MRE for latest stable fixes of Postgres.

  [Test Case]

   * The Postgres MREs traditionally rely on the large pack of autopkgtests
 to run for verification. In a PPA those are all already pre-checked to
 be good for this upload.

  [Regression Potential]

   * Upstreams tests are usually great and also in the Archive there are
 plenty of autopkgtests that in the past catched issues before released.
 But never the less

  [Other Info]

   * This is a reoccurring MRE, see below and all the references

  ---

  Current versions in supported releases:
   postgresql-9.5 | 9.5.18-0ubuntu0.16.04 xenial
   postgresql-10 | 10.9-0ubuntu0.18.04.1 bionic
   postgresql-10 | 10.9-0ubuntu0.18.10.1 cosmic
   postgresql-11 | 11.4-0ubuntu0.19.04.1 disco
   postgresql-11 | 11.4-1.1~ubuntu1 eoan

  Special cases:
  - Eoan will as usual be synced from Debian. But this time since we have
a slight test delta might some action to do so.

  Last relevant related stable updates: 9.5.18, 10.9, 11.4

  This is out of the usual cycle for CVE: CVE-2019-10164

  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  - pad.lv/1815665
  - pad.lv/1828012
  - pad.lv/1833211

  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.

  Regression potential:
  - usually this works smoothly except a few test hickups (flaky) that need to 
be
clarified to be sure. Pre-checks will catch those to be discussed upfront 
(as last time)

  Note: opening private as it is not yet announced
  Public announce will on this Thursday.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-11/+bug/1839058/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1833211] Re: New upstream microreleases 9.5.18, 10.9 and 11.5

[Christian Ehrhardt ]

** Changed in: postgresql-11 (Ubuntu Eoan)
   Status: Triaged => Fix Released

** Changed in: postgresql-11 (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1833211

Title:
  New upstream microreleases 9.5.18, 10.9 and 11.5

Status in postgresql-11 package in Ubuntu:
  Fix Released
Status in postgresql-9.5 source package in Xenial:
  Fix Released
Status in postgresql-10 source package in Bionic:
  Fix Committed
Status in postgresql-10 source package in Cosmic:
  Fix Committed
Status in postgresql-11 source package in Disco:
  Fix Released
Status in postgresql-11 source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * MRE for latest stable fixes of Postgres.

  [Test Case]

   * The Postgres MREs traditionally rely on the large pack of autopkgtests 
 to run for verification. In a PPA those are all already pre-checked to 
 be good for this upload.

  [Regression Potential]

   * Upstreams tests are usually great and also in the Archive there are 
 plenty of autopkgtests that in the past catched issues before released.
 But never the less 

  [Other Info]
   
   * This is a reoccurring MRE, see below and all the references

  ---

  Current versions in supported releases:
   postgresql-9.5 | 9.5.17-0ubuntu0.16.04 xenial
   postgresql-10 | 10.8-0ubuntu0.18.04.1 bionic
   postgresql-10 | 10.8-0ubuntu0.18.10.1 cosmic
   postgresql-11 | 11.3-0ubuntu0.19.04.1 disco
   postgresql-11 | 11.3-1 eoan

  Special cases:
  - Eoan will as usual be synced from Debian

  Last relevant related stable updates: 9.5.18, 10.9, 11.4

  This is out of the usual cycle for CVE: CVE-2019-10164

  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  - pad.lv/1815665
  - pad.lv/1828012

  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.

  Regression potential:
  - usually this works smoothly except a few test hickups that need to be
    clarified to be sure. Pre-checks will catch those to be discussed (as last 
time)

  Note: opening private as it is not yet announced
  Public announce will on this Thursday.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-11/+bug/1833211/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1848834] Re: ClusterMon resource creation core-dumps while created with extra_option -E

[Christian Ehrhardt ]

Yeah he was running on 16.04 which means he was using 1.1.14-2ubuntu1.6

Neither could I reproduce the crashes :-/

But I'm glad to hear that for you it was resolved after using -e
And even more glad that you found newer versions working better for you ´.

I hope this bug helps further users that might run into this to find
your workaround, but I don't see a crash to debug and fix in the package
yet (just as Paride)

** Also affects: pacemaker (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: pacemaker (Ubuntu Xenial)
   Status: New => Incomplete

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1848834

Title:
  ClusterMon resource creation core-dumps while created with
  extra_option -E

Status in pacemaker package in Ubuntu:
  Fix Released
Status in pacemaker source package in Xenial:
  Incomplete

Bug description:
  Hi
  I have a 2 nodes cluster with a number of resources working fine.
  I am using Ubuntu 16.04 with Pacemaker: 1.1.14
  The moment i create a ClusterMon resource with an extra_option "-E" to run a 
script, it crashes and i can see the following in dmesg

  
  [73880.444953] crm_mon[20739]: segfault at 0 ip 7f948cc5c746 sp 
7ffed0cb0fb8 error 4 in libc-2.23.so[7f948cbd1000+1c]

  I am using the following command to create the resource:
  pcs resource create newRes ClusterMon user="root" extra_options="-E 
/usr/local/bin/new.sh "
  OR
  pcs resource create newRes ocf:pacemaker:ClusterMon user="root" 
extra_options="-E /usr/local/bin/new.sh "

  
  and immediately i see following in /var/log/messages

  2019-10-19T01:53:11.783763-04:00 master daemon notice crmd 17042   notice: 
Operation newRes_monitor_0: not running (node=master.dhcp, call=85, rc=7, 
cib-update=58, confirmed=true)
  2019-10-19T01:53:12.097529-04:00 master daemon info systemd - Started Session 
c75 of user root.
  2019-10-19T01:53:12.105468-04:00 master auth info systemd-logind - New 
session c75 of user root.
  2019-10-19T01:53:12.150340-04:00 master daemon notice lrmd 17039   notice: 
newRes_start_0:30376:stderr [ mesg: ttyname failed: Inappropriate ioctl for 
device ]
  2019-10-19T01:53:12.186340-04:00 master daemon notice crmd 17042   notice: 
Operation newRes_start_0: ok (node=master.dhcp, call=86, rc=0, cib-update=59, 
confirmed=true)
  2019-10-19T01:53:12.195312-04:00 master kern info kernel - crm_mon[30398]: 
segfault at 0 ip 7f9cfbe41746 sp 7ffd971060e8 error 4 in 
libc-2.23.so[7f9cfbdb6000+1c]
  2019-10-19T01:53:12.216644-04:00 master auth info systemd-logind - Removed 
session c75.
  2019-10-19T01:53:12.241439-04:00 master daemon notice lrmd 17039   notice: 
newRes_monitor_1:30406:stderr [ 
/usr/lib/ocf/resource.d/heartbeat/ClusterMon: 155: kill: No such process ]
  2019-10-19T01:53:12.241980-04:00 master daemon notice lrmd 17039   notice: 
newRes_monitor_1:30406:stderr [  ]
  2019-10-19T01:53:12.245273-04:00 master daemon notice crmd 17042   notice: 
master.dhcp-newRes_monitor_1:87 [ 
/usr/lib/ocf/resource.d/heartbeat/ClusterMon: 155: kill: No such process\n\n ]

  
  Note:
  - All other types of resources i.e. IPAddr, Drbd, systemd are working fine.
  - Also, if the newRes is created wihtout -E, it works fine.
  - Script has no complicated code. Event without the "echo" command i am 
seeing same issue.
  cat /usr/local/bin/new.sh
  #!/bin/sh
  echo "HELLO from Crm_mon script" >> /var/log/messages
  exit

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1840956] Re: qemu-user-static fails to install in WSL and LXD

[Christian Ehrhardt ]

TBH - unless someone out there "really" is affected by it I'm
considering "qemu-user-static on aarch64 on LXD on Xenial" too much of a
special case to bother the SRU team with it.

I could keep states as-is, but to reflect that I'd think we should set
it to Won't Fix unless someone speaks up about this being more important
for Ubuntu than I think atm.

** Changed in: qemu (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1840956

Title:
  qemu-user-static fails to install in WSL and LXD

Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Won't Fix
Status in qemu source package in Bionic:
  Won't Fix
Status in qemu source package in Disco:
  Fix Released

Bug description:
  [Impact]

   * The check in qemu postinst to nnot by accident run in a container 
 doesn't work in WSL. Due to that it tries to register bin_fmt types 
 which can't work in that environment.

   * Fix the check, so that it recognizes WSL (and probably a few other 
 containsers)

  [Test Case]

   * Install qemu-user-static in WSL(1) Ubuntu guest

  [Regression Potential]

   * The old check just detected LXD/LXC and any other container that put 
 the container into  /proc/1/environ. So we could now (on install) skip 
 bin_fmt registration on some containers where we did it before.
 Overall that is just what we wanted, but there could be containers set 
 up very privileged (uncommon) that would be able to do that before.
 Those would regress in a sense that it is not done on install.
 But the change would not prevent that in those (expected to be rare 
 cases) the user/admin registers the type later.

  [Other Info]
   
   * n/a

  ---

  Happened running do-release-upgrade from 18.04 to 18.10 on Windows
  Subsystem for Linux, Windows 10 1903. qemu-user-static can no longer
  be installed or run.

  ProblemType: Package
  DistroRelease: Ubuntu 19.04
  Package: qemu-user-static 1:3.1+dfsg-2ubuntu3.3
  ProcVersionSignature: Microsoft 4.4.0-18362.1-Microsoft 4.4.35
  Uname: Linux 4.4.0-18362-Microsoft x86_64
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  Date: Wed Aug 21 11:43:54 2019
  Dmesg: [0.029344]  Microsoft 4.4.0-18362.1-Microsoft 4.4.35
  ErrorMessage: installed qemu-user-static package post-installation script 
subprocess returned error exit status 2
  Python3Details: /usr/bin/python3.7, Python 3.7.3, python3-minimal, 3.7.3-1
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.6ubuntu1.1
   apt  1.8.1
  SourcePackage: qemu
  Title: package qemu-user-static 1:3.1+dfsg-2ubuntu3.3 failed to 
install/upgrade: installed qemu-user-static package post-installation script 
subprocess returned error exit status 2
  UpgradeStatus: Upgraded to disco on 2019-08-21 (0 days ago)
  mtime.conffile..etc.apport.crashdb.conf: 2019-08-09T13:43:51.502822

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1842701] Re: Apache2 Balancer Manager mod_proxy_balancer not working after Update

[Christian Ehrhardt ]

Hi Horst,
yes I checked and the issue is in Eoan 2.4.41 - I checked that already last 
week and let Steve now.

Steve wanted to track the upstream discussions on this as going forward
we most likely want to follow upstreams guidance on this (e.g. want to
have it broken for better security).

But thanks for the ping, we might want to mark the bug tasks accordingly
to make this clear.

** Also affects: apache2 (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: apache2 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: apache2 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: apache2 (Ubuntu)
   Status: Fix Released => Confirmed

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

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

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1842701

Title:
  Apache2 Balancer Manager mod_proxy_balancer not working after Update

Status in Apache2 Web Server:
  Confirmed
Status in apache2 package in Ubuntu:
  Confirmed
Status in apache2 source package in Xenial:
  Fix Released
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  OS

  Description:Ubuntu 18.04.3 LTS
  Release:18.04
  Codename:   bionic

  
  I use this kind of configuration to reache the Balancer Manager.

   -
  |Bastian Host |
  |Apache Proxy | ---> LB Apache Balancer Manger
   -

  After Apache Update

  from: 2.4.29-1ubuntu4.8
  to:   2.4.29-1ubuntu4.10

  The Balancer Manager behind a Proxy is not Working and i think this is 
comming with
  the fix CVE-2019-10092

  https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2019-10092
  
http://changelogs.ubuntu.com/changelogs/pool/main/a/apache2/apache2_2.4.29-1ubuntu4.10/changelog

  
  I strip down the configuration to try and explain the situation.

  Install new Ubuntu 18.04 VirtualBox. From an another VM i saved the prior
  Apache Packages from /var/cache/apt/archives

  :~# apt-get install libapr1 libaprutil1 libaprutil1-dbd-sqlite3 
libaprutil1-ldap liblua5.2-0
  :~# dpkg -i apache2_2.4.29-1ubuntu4.8_amd64.deb 
apache2-bin_2.4.29-1ubuntu4.8_amd64.deb apache2-data_2.4.29-1ubuntu4.8_all.deb 
apache2-utils_2.4.29-1ubuntu4.8_amd64.deb

  :~# dpkg -l | grep apache2
  ii  apache2  2.4.29-1ubuntu4.8   amd64Apache HTTP Server
  ii  apache2-bin  2.4.29-1ubuntu4.8   amd64Apache HTTP Server 
(modules and other binary files)
  ii  apache2-data 2.4.29-1ubuntu4.8   all  Apache HTTP Server 
(common files)
  ii  apache2-utils2.4.29-1ubuntu4.8   amd64Apache HTTP Server 
(utility programs for web servers)

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  - -

  :~# vim /etc/apache2/sites-available/management.conf
  
  Servername 127.0.0.1
  ServerAdmin root@localhost

  
  SetHandler balancer-manager
  Require local
  #Require ip 192.168.56.0/24 127.0.0.1/24
  Require all granted
  

  LogLevel warn
  ErrorLog ${APACHE_LOG_DIR}/management_error.log
  CustomLog ${APACHE_LOG_DIR}/management_access.log combined

  

  # vim: syntax=apache ts=4 sw=4 sts=4 sr noet

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  - -

  :~# vim /etc/apache2/sites-available/proxytest.conf
  
  BalancerMember "http://192.168.168.130/test;
  BalancerMember "http://192.168.168.131/test; status=+H
  ProxySet lbmethod=bybusyness
  

  
  ServerAdmin root@localhost
  ServerName testapp01
  ServerAlias 127.0.0.1:8100

  ProxyPass   "/test" "balancer://test"
  ProxyPassReverse"/test" "balancer://test"

  CustomLog ${APACHE_LOG_DIR}/test-access.log combined
  ErrorLog  ${APACHE_LOG_DIR}/test-error.log

  

  # vim: syntax=apache ts=4 sw=4 sts=4 sr noet

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  - -

  :~# a2enmod proxy_balancer proxy_http lbmethod_bybusyness lbmethod_byrequests
  :~# a2ensite management proxytest

  :~# vim /etc/apache2/ports.conf
  [...]
  Listen 81
  Listen 8100

  :~# systemctl restart apache2

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  - -

  At that point i install also some console Browsers for testing.

  :~# apt-get install lynx elinks

  :~# tail -f /var/log/apache2/management_error.log

  :~# elinks 127.0.0.1:81/balancer-manager
  :~# lynx 127.0.0.1:81/balancer-manager

  i can do update the Load and made changes. i also connect from outside with
  Firefox

  http://192.168.56.211:81/balancer-manager

  all this 

[Group.of.nepali.translators] [Bug 1827202] Re: Apport hook may expose sensitive information

[Christian Ehrhardt ]

This fix is in 5.128-0ubuntu1 in Eoan

** Changed in: byobu (Ubuntu)
   Status: Fix Committed => Fix Released

** Changed in: byobu (Ubuntu)
 Assignee: Paride Legovini (legovini) => (unassigned)

** Tags removed: server-next

** Also affects: byobu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: byobu (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: byobu (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: byobu (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: byobu (Ubuntu Bionic)
   Status: New => Won't Fix

** Changed in: byobu (Ubuntu Disco)
   Status: New => Won't Fix

** Changed in: byobu (Ubuntu Xenial)
   Importance: Undecided => Low

** Changed in: byobu (Ubuntu Bionic)
   Importance: Undecided => Low

** Changed in: byobu (Ubuntu Disco)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1827202

Title:
  Apport hook may expose sensitive information

Status in byobu:
  Invalid
Status in byobu package in Ubuntu:
  Fix Released
Status in byobu source package in Xenial:
  Won't Fix
Status in byobu source package in Bionic:
  Won't Fix
Status in byobu source package in Disco:
  Won't Fix

Bug description:
  OVERVIEW
  

  Author: Sander Bos
  Author's e-mail address: sbos _at_ sbosnet _dot_ nl
  Author's website: 
  CVE identifier: requested
  Date: 2019-04-19
  Report version: 2


  SUMMARY
  ---

  The Ubuntu "byobu" package contains a security vulnerability which may
  lead to disclosure of private as well as sensitive information in case
  a bug or crash report file gets created by the user or in case the
  application crashes, with this report file then being uploaded to an
  external crash report database, all through the Ubuntu "Apport" crash
  report framework.

  The vulnerability is specific to the Ubuntu (and Debian) byobu package
  (and potentially derivate OS packages, for example Linux Mint), and not
  present in the upstream application itself (although it is in fact part
  of the upstream source code repository).


  DESCRIPTION
  ---

  "Byobu" [1, 2] is a text-based window manager, terminal multiplexer,
  and integrated DevOps environment which can act as an enhancement to
  the GNU Screen and tmux applications.  It was initially developed for
  Ubuntu, and is nowadays available in many GNU/Linux distributions as
  well as macOS and some BSD operating systems.

  The Ubuntu "byobu" package adds a file "debian/source_byobu.py" [3] to
  the program.  This file acts as a so-called "package hook" for the Ubuntu
  "Apport" crash report framework [4].  When a Byobu process crashes,
  or when the user manually creates a bug report file for the program,
  a local crash or bug report file gets created.  This report file may be
  amended with additional information, as defined by the package hook file.
  The resulting report file may then be uploaded to an external bug report
  database like Launchpad [5] or the Ubuntu Error Tracker [6].

  The vulnerability lies in the fact that the debian/source_byobu.py package
  hook file includes the user's ~/.screenrc file (line numbers prepended):

   10 def add_info(report):
  [...]
   13 attach_file_if_exists(report, path.expanduser('~/.screenrc'), 
'ScreenRC')

  This file however is a user's private dot file, which should therefore
  probably not be attached to the report at all to begin with.  Specifically
  though the file may contain actual sensitive information, including but
  not limited to passwords, user names, and host names.

  Thus, private and / or sensitive user information may end up in external
  bug databases and (potentially public) bug reports.  This applies
  specifically in case the system on which the application crashed is
  configured to automatically upload Apport crash reports without asking
  the user's permission or requiring any user intervention at all.

  The vulnerability is specific to the Ubuntu (and Debian) byobu package
  (and potentially derivate OS packages, for example Linux Mint), and not
  present in the upstream application itself.


  VULNERABILITY IMPACT
  

  The general vulnerability impact type of this vulnerability is disclosure
  of sensitive information potentially including but not limited to
  passwords, user names, and host names.

  The leakage of such sensitive information from the ~/.screenrc file is
  the core of this security vulnerability.  However, even when the file
  does not (or would never) include sensitive information like passwords,
  sending out a user dot file like ~/.screenrc could still be considered
  a privacy infringement on itself.

  The following are examples of GNU Screen commands which may be included
  in 

[Group.of.nepali.translators] [Bug 1843674] [NEW] FTBFS of libvirt in Xenial

[Christian Ehrhardt ]

Public bug reported:

[Impact]

 * libvirt became FTBFS in xenial due to other changes.

 * The fix just modifies the self-tests (not the active code that runs
in an ubuntu users env)

 * The change is already active in Ubuntu in later releases via
https://salsa.debian.org/libvirt-team/libvirt/commit/2be70b3

[Test Case]

 * Build libvirt in Xenial on LP infra and while doing so do not trigger test 
fails in
   test-openpty and test-posix_openpt

[Regression Potential]

 * Since we only change self-test code that runs at build time the runtime 
should show now 
   regressions. The one thing I can think of is that a rebuild could always 
change something 
   (even a no change rebuild) but since we want to bundle it with other SRUs 
there would be a 
   rebuild anyway - hence I'd think this has no regression risk of its own.

[Other Info]
 
 * This should not be fixed standalone but bundled with some other SRU to avoid 
useless rebuilds 
   - and even more so - users downloading updates for now gain.

---

Due to a unknown other update libvirt became an FTBFS in Xenial.

The issue shows up at build on launchpad infra and has two seld-tests broken.
>From the build log:
FAIL: test-openpty
==

openpty returned -1
FAIL test-openpty (exit status: 1)

FAIL: test-posix_openpt
===

../../../../gnulib/tests/test-posix_openpt.c:52: assertion '0 <= master' failed
FAIL test-posix_openpt (exit status: 134)


This is somewhat familiar to bug 1641615 but showing up again in Xenial now for 
yet unknown reasons.

The later re-occurrence of this outside of Xenial was later on fixed by [1] for 
good.
Probably now triggering by some SRu of a lib into Xenial (or unlikely some 
change in the builder setup).
We want to add that to Xenial as well to have it build fine again.

[1]: https://salsa.debian.org/libvirt-team/libvirt/commit/2be70b3

** Affects: libvirt (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: libvirt (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1843674

Title:
  FTBFS of libvirt in Xenial

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  New

Bug description:
  [Impact]

   * libvirt became FTBFS in xenial due to other changes.

   * The fix just modifies the self-tests (not the active code that runs
  in an ubuntu users env)

   * The change is already active in Ubuntu in later releases via
  https://salsa.debian.org/libvirt-team/libvirt/commit/2be70b3

  [Test Case]

   * Build libvirt in Xenial on LP infra and while doing so do not trigger test 
fails in
 test-openpty and test-posix_openpt

  [Regression Potential]

   * Since we only change self-test code that runs at build time the runtime 
should show now 
 regressions. The one thing I can think of is that a rebuild could always 
change something 
 (even a no change rebuild) but since we want to bundle it with other SRUs 
there would be a 
 rebuild anyway - hence I'd think this has no regression risk of its own.

  [Other Info]
   
   * This should not be fixed standalone but bundled with some other SRU to 
avoid useless rebuilds 
 - and even more so - users downloading updates for now gain.

  ---

  Due to a unknown other update libvirt became an FTBFS in Xenial.

  The issue shows up at build on launchpad infra and has two seld-tests broken.
  From the build log:
  FAIL: test-openpty
  ==

  openpty returned -1
  FAIL test-openpty (exit status: 1)

  FAIL: test-posix_openpt
  ===

  ../../../../gnulib/tests/test-posix_openpt.c:52: assertion '0 <= master' 
failed
  FAIL test-posix_openpt (exit status: 134)

  
  This is somewhat familiar to bug 1641615 but showing up again in Xenial now 
for yet unknown reasons.

  The later re-occurrence of this outside of Xenial was later on fixed by [1] 
for good.
  Probably now triggering by some SRu of a lib into Xenial (or unlikely some 
change in the builder setup).
  We want to add that to Xenial as well to have it build fine again.

  [1]: https://salsa.debian.org/libvirt-team/libvirt/commit/2be70b3

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1832622] Re: QEMU - count cache flush Spectre v2 mitigation (CVE) (required for POWER9 DD2.3)

[Christian Ehrhardt ]

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

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

** Changed in: linux (Ubuntu Disco)
   Importance: Undecided => High

** No longer affects: linux (Ubuntu Cosmic)

** No longer affects: linux (Ubuntu Eoan)

** No longer affects: linux (Ubuntu Xenial)

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

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1832622

Title:
  QEMU -  count cache flush Spectre v2 mitigation (CVE) (required for
  POWER9 DD2.3)

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Won't Fix
Status in linux source package in Bionic:
  Fix Released
Status in qemu source package in Bionic:
  Fix Committed
Status in qemu source package in Cosmic:
  Won't Fix
Status in linux source package in Disco:
  Confirmed
Status in qemu source package in Disco:
  Fix Committed
Status in qemu source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * This belongs to the overall context of spectre mitigations and even 
 more the try to minimize the related performance impacts.
 On ppc64el there is a new chip revision (DD 2.3) which provides
 a facility that helps to better mitigate some of this.

   * Backport the patches that will make the feature (if supported by the 
 HW) will pass the capability to the guest - to allow guests that 
 support the improved mitigation to use it.

  [Test Case]

   * Start guests with and without this capability
 * Check if the capability is guest visible as intented
 * Check if there are any issues on pre DD2.3 HW
   * Test migrations (IBM outlined the intented paths that will work 
 below)
   * The problem with the above (and also the reasons I didn't add a list 
 of commands this time) is that it needs special HW (mentioned DD2.3 
 revision) of the chips which aren't available to us right now.
 Due to that testing / verification of this on all releases is on IBM

  [Regression Potential]

   * Adding new capabilities usually works fine, there are three common 
 pitfalls which here are the regression potential.
 - (severe) the code would announce a capability that isn't really 
   available. The guest tries to use it and crashes
 - (medium) several migration paths especially from systems with the 
   new cap to older (un-updated systems) will fail. But that applies 
   to any "from machine with Feature to machine without that feature" 
   and isn't really a new regression. As outlined by IBM below they 
   even tried to make it somewhat compatible (by being a new value in 
   an existing cap)
 - (low) the guest will see new caps and or facilities. A really odd
   guest could stumble due to that (would actually be a guest bug 
   then)
Overall all of the above was considered by IBM when developing this 
and should be ok. For archive wide SRU considerations, this has NO 
effect on non ppc64el.

  [Other Info]
   
   * n/a

  ---

  Power9 DD 2.3  CPUs  running updated firmware will use a new Spectre
  v2 mitigation. The new mitigation improves performance of branch heavy
  workloads, but also requires kernel support in order to be fully
  secure.

  Without the kernel support there is a risk of a Spectre v2 attack
  across a process context switch, though it has not been demonstrated
  in practice.

  QEMU portion - platform definition needs to account for this new
  mitigation action.. so attribute for this needs to be added.

  In terms of support for virtualisation there are 2 sides, kvm and qemu
  support. Patch list for each,

  KVM:
  2b57ecd0208f KVM: PPC: Book3S: Add count cache flush parameters to 
kvmppc_get_cpu_char()
  This is part of LP1822870 already.

  QEMU:
  8ff43ee404 target/ppc/spapr: Add SPAPR_CAP_CCF_ASSIST
  399b2896d4 target/ppc/spapr: Add workaround option to SPAPR_CAP_IBS

  The KVM side is upstream as of v5.1-rc1.
  The QEMU side is upstream as of v4.0.0-rc0.

  In terms of migration the state is as follows.

  In order to specify to the guest to use the count cache flush
  workaround we use the spapr-cap cap-ibs (indirect branch speculation)
  with the value workaround. Previously the only valid values were
  broken, fixed-ibs (indirect branch serialisation) and fixed-ccd (count
  cache disabled). And add a new cap cap-ccf-assist (count cache flush
  assist) to specify the availability of the hardware assisted flush
  variant.

  Note the the way spapr caps work you can migrate to a host that supports a 
higher value, but not to one which doesn't 

[Group.of.nepali.translators] [Bug 1755681] Re: pstree crashes on fclose(NULL)

[Christian Ehrhardt ]

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

Lucas identified this beign the same as one that he works on.
Marking as duplicate.

** This bug has been marked a duplicate of bug 1837444
   pstree seg fault

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1755681

Title:
  pstree crashes on fclose(NULL)

Status in psmisc package in Ubuntu:
  Fix Released
Status in psmisc source package in Xenial:
  Confirmed

Bug description:
  I am on 16.04.4 LTS.  I am seeing pstree crash intermittently, and I
  tracked it down to an fclose(NULL):

  
https://gitlab.com/psmisc/psmisc/blob/28005b99fedef566b06286bd6ca72a7a4d673f20/src/pstree.c#L822

  I am guessing it is a race condition where the procfs entry disappears
  between dir listing and the fopen() call several lines above.

  This is fixed in the latest release (v23.0, released 9 months ago) but
  exists in the current version of psmisc for 16.04.4 (v22.21).

  Would this call for a bump of the upstream version, or an Ubuntu-
  specific patch to remove that fclose() call?

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1837444] Re: pstree seg fault

[Christian Ehrhardt ]

** Also affects: psmisc (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: psmisc (Ubuntu)
   Status: Triaged => Fix Released

** Changed in: psmisc (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: psmisc (Ubuntu Xenial)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1837444

Title:
  pstree seg fault

Status in psmisc package in Ubuntu:
  Fix Released
Status in psmisc source package in Xenial:
  Triaged

Bug description:
  Impact 
  --

  Users might face a segmentation fault crash while executing 'pstree'. 
Backporting this fix will avoid 'pstree' breakage in our users' systems under
  certain circumstances.

  This is a timing issue where if the 'get_threadname' function is called and
  during its execution the target thread is deleted, it tries to close a file
  that does not exist anymore. This happens because of a coding issue, 'pstree'
  invokes fclose function even if the fopen function call returns NULL. The
  proposed patch fixes this issue simply moving the fclose function call three
  lines up, inside of a conditional block which guarantees that the file was
  properly open (the pointer to the file is not NULL).

  This bug was introduced in upstream version 22.21 and fixed in version 23.0,
  which means that Xenial is the only affected Ubuntu release:

  $ rmadison psmisc
   psmisc | 22.15-2ubuntu1   | precise | source, amd64, armel, armhf, 
i386, powerpc
   psmisc | 22.15-2ubuntu1.2 | precise-updates | source, amd64, armel, armhf, 
i386, powerpc
   psmisc | 22.20-1ubuntu2   | trusty  | source, amd64, arm64, armhf, 
i386, powerpc, ppc64el
   psmisc | 22.21-2.1build1  | xenial  | source, amd64, arm64, armhf, 
i386, powerpc, ppc64el, s390x
   psmisc | 23.1-1   | bionic  | source, amd64, arm64, armhf, 
i386, ppc64el, s390x
   psmisc | 23.1-1ubuntu0.1  | bionic-updates  | source, amd64, arm64, armhf, 
i386, ppc64el, s390x
   psmisc | 23.2-1   | disco   | source, amd64, arm64, armhf, 
i386, ppc64el, s390x
   psmisc | 23.2-1   | eoan| source, amd64, arm64, armhf, 
i386, ppc64el, s390x

  
  Test Case
  -

  Since timing is an important factor for this issue, it is not easy to
  reproduce via a test case. This bug might pop up in any 'pstree' call
  regardless of the parameters passed to it. When it happens the user
  will be able to notice the segmentation fault immediately in the
  standard output. Below is the stack trace generated by the user who
  reported this bug on Debian [1]:

  Core was generated by `pstree'.
  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  _IO_new_fclose (fp=0x0) at iofclose.c:54
  54iofclose.c: No such file or directory.
  (gdb) bt
  #0  _IO_new_fclose (fp=0x0) at iofclose.c:54
  #1  0x004037be in ?? ()
  #2  0x00401a43 in ?? ()
  #3  0x7f577c553b45 in __libc_start_main (main=0x401670, argc=1,
  argv=0x7ffeb6139328, init=, fini=,
  rtld_fini=, stack_end=0x7ffeb6139318) at libc-start.c:287
  #4  0x00401e8d in ?? ()

  
  However, as presented in the last section it is an easily identifiable error
  in the code, and the fix is quite straightforward.

  [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815902

  
  Regression Potential 
  

  There is a potential problem since the bug was not reproducible in our
  side. Timing issues are hard to reproduce in general, so there might
  be another case(s) where this kind of situation can happen. The fix
  impacts only the 'pstree' utility, so any problem with other binaries
  provided by psmisc is not related to this update.


  [Original message]

  As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815902

  Perhaps Xenial needs to be upgraded to use 22.22??

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1838370] Re: slapd segfault on filter parse error

[Christian Ehrhardt ]

** Bug watch added: Debian Bug tracker #934277
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934277

** Also affects: openldap (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934277
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1838370

Title:
  slapd segfault on filter parse error

Status in openldap:
  Fix Released
Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Confirmed
Status in openldap source package in Bionic:
  Confirmed
Status in openldap source package in Disco:
  Confirmed
Status in openldap package in Debian:
  Unknown

Bug description:
  Impact
  --

  Users willing to use the slapd rwm overlay will face a slapd
  segmentation fault when trying to rewrite some rules. Backporting this
  fix will allow users using stable releases to take advantage of this
  feature without crashing slapd. This issue was fixed by upstream not
  freeing the rwm overlay filter memory without prior checking.

  Test Case
  -

  In this test case, the rwm overlay will be used and a rule will be
  created to deny any search request for uid=root, then the 'ldapsearch'
  will be invoked to trigger the failure. It is important to mention
  that the 'ldapsearch' command should fail regardless the presence of
  the bug in the package, the target here is the slapd crash. To
  reproduce this bug one can follow the procedure below in Ubuntu
  xenial, bionic or disco:

  $ sudo apt-get update
  $ sudo apt-get install slapd ldap-utils -y

  Reconfigure the slapd package. When asked about a domain, use "example.com".
  Choose a password you want (or just leave it blank), and accept defaults for
  everything else:

  $ sudo dpkg-reconfigure slapd

  Create a file called 'add-rwm.ldif' with the following content:

  $ cat add-rwm.ldif
  dn: cn=module{0},cn=config
  changetype: modify
  add: olcModuleLoad
  olcModuleLoad: rwm

  dn: olcOverlay=rwm,olcDatabase={1}mdb,cn=config
  changetype: add
  objectClass: olcOverlayConfig
  objectClass: olcRwmConfig
  olcOverlay: rwm
  olcRwmRewrite: {0} rwm-rewriteEngine "on"
  olcRwmRewrite: {1} rwm-rewriteContext "searchFilter"
  olcRwmRewrite: {2} rwm-rewriteRule "(.*)(uid=root)(.*)" "$1$2$3" "#"

  With this file in place, run:

  $ sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f add-rwm.ldif

  Now, to trigger the crash:

  $ ldapsearch -x -h localhost -b dc=example,dc=com -LLL uid=root
  Server is unwilling to perform (53)
  Additional information: searchFilter/searchFilterAttrDN massage error

  slapd process will die, and /var/crash will have a crash file for slapd. You
  can run the following command to confirm the error:

  $ cat /var/log/syslog | grep filter_free
  Aug  9 19:51:05 popular-gorilla slapd[1479]: filter_free: unknown filter 
type=28530

  Regression Potential
  

  Since the fix is a patch provided by upstream (reviewed by maintainers
  and us) simple mistakes like typos are not expected. The patch impacts
  only the rwm module which is not loaded by default. So any regression
  would affect only the users that make use of this overlay. If an user
  is not using rwm overlay and is facing any issue, it should be related
  to other problems related to LDAP directory services.

  [Original message]

  Hello!
  We have faced slapd crash, seems an attacker was trying to brute force one
  of our services and uid parsing failures caused slapd crash:

  Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH
  base="ou=test,dc=test,dc=com" scope=2 deref=0
  
filter="(&(uid=aistar123<>!n)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0"
  Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH attr=objectClass uid
  userPassword uidNumber gidNumber gecos homeDirectory loginShell
  krbPrincipalName cn memberOf modifyTimestamp modifyTimestamp
  shadowLastChange shadowMin shadow
  Max shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange
  krbPasswordExpiration pwdAttribute authorizedService accountExpires
  userAccountControl nsAccountLock host loginDisabled loginExpirationTime
  loginAllowedTimeMap sshPublic
  Key
  Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SEARCH RESULT tag=101 err=0
  nentries=0 text=massaged filter parse error
  Jul 26 18:59:47 kernel: [ 9441.554161] slapd[2367]: segfault at 18 ip
  7fc8d18ec512 sp 7fc8889e2810 error 4 in libc-2.23.so
  [7fc8d1868000+1c]

  Another faulty filter example:
  
filter="(&(uid=sql<>?)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0"
  
filter="(&(uid=fugeone<>?123)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0"

  $ lsb_release -rd
  Description: Ubuntu 16.04.5 LTS
  Release: 16.04

  $ slapd -VVV
  @(#) $OpenLDAP: slapd  (Ubuntu) (May 22 2018 13:54:12) $
  

[Group.of.nepali.translators] [Bug 1836929] Re: chrony has migration regressions from autopkgtests (disco/eoan)

[Christian Ehrhardt ]

After discussion decided that it is not a dup, they just share the
symptom to hit at autopkgtest time.

** This bug is no longer a duplicate of bug 1836882
   autopkgtest due to other packages changing

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1836929

Title:
  chrony has migration regressions from autopkgtests (disco/eoan)

Status in chrony package in Ubuntu:
  Fix Released
Status in chrony source package in Xenial:
  Won't Fix
Status in chrony source package in Bionic:
  Won't Fix
Status in chrony source package in Cosmic:
  Won't Fix
Status in chrony source package in Disco:
  In Progress
Status in chrony source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * Recent changes have caused the chrony autopkgtests to fail.
     In this case upstream of chrony and the clk tests changed, which need 
 to be back under control to match what works reliably for Disco.

   * Later versions have this fixed, backport the changes to fix it in Disco
     as well

  [Test Case]

   * Let the autopkgtests run (which is part of the proposed migration
     anyway)
     Sniffs already show them completing:
     https://bileto.ubuntu.com/excuses/3759/disco.html

  [Regression Potential]

   * There is no functional change, only the self-tests as well the
     autopkgtest execution are changed.
     The one source for a regression could be that the rebuild picks
     something up that triggers a behavior change. But the PPA builds have
     not shown something (at least not something obvious)

  [Other Info]

   * This is one of the cases where the actual package as used by the user
     has no bug. I'm unsure how to proceed. Do we want to push it just to
     disco-proposed but keep it there (to avoid downloads for "nothing")?
     I know rbasak wanted to discuss that in the SRU team for the even worse
     https://bugs.launchpad.net/cloud-archive/+bug/1829823/comments/14
     To some extend this come under the same banner.
   * If this is denied from SRU for this reason I'd ask to add a force-
     badtest as a replacement to unblock proposed migration.

  ---

  Checking last eoan merge I realized that some tests were failing for
  chrony:

  
https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/369588/comments/967625

  But eoan ran autopkgtests okay when the trigger was
  chrony/3.5-2ubuntu2 (this last merge):

  http://autopkgtest.ubuntu.com/packages/chrony/eoan/amd64

  Despite having failed for the previous 12 times (eoan).

  Now, for the first time, we have the same failure for disco:

  http://autopkgtest.ubuntu.com/packages/chrony/disco/amd64

  http://bit.ly/2LpMx4G

  """
  make: Leaving directory 
'/tmp/autopkgtest.pBHSAl/build.WCD/src/test/simulation/clknetsim'
  ...
  110-chronyc    PASS
  111-knownclient    FAIL
  112-port   FAIL
  121-orphan PASS
  ...
  SUMMARY:
    TOTAL  50
    PASSED 48
    FAILED 2(111-knownclient 112-port) (255 256 257 258 259 260 261 262 263 
264 265 266 267 268 269 270 271 272 273 274 255 256 257 258 259 260 261 262 263 
264 265 266 267 268 269 270 271 272 273 274 265)
  """

  And I'm able to reproduce locally:

  """
  (c)inaddy@iproute2verification:~/work/sources/ubuntu/chrony/test/simulation$ 
./111-knownclient
  Testing reply to client configured as server:
    network with 1*1 servers and 1 clients:
  non-default settings:
    client_conf=acquisitionport 123
    server_conf=server 192.168.123.2 noselect acquisitionport 123
  starting node 1: OK
  starting node 2: OK
  running simulation: OK
  checking chronyd exit:
    node 1: OK
    node 2: OK
  checking source selection:
    node 2: OK
  checking port numbers in packet log:
    node 1: BAD
    node 2: BAD
  FAIL

  AND

  (c)inaddy@iproute2verification:~/work/sources/ubuntu/chrony/test/simulation$ 
./112-port
  Testing port and acquisitionport directives:
    network with 1*1 servers and 1 clients:
  non-default settings:
  starting node 1: OK
  starting node 2: OK
  running simulation: OK
  checking chronyd exit:
    node 1: OK
    node 2: OK
  checking source selection:
    node 2: OK
  checking mean/min incoming/outgoing packet interval:
    node 1: 2.74e+02 2.74e+02 6.40e+01 6.40e+01 OK
    node 2: 2.74e+02 2.74e+02 6.40e+01 6.40e+01 OK
  checking clock sync time, max/rms time/freq error:
    node 2: 132 9.29e-05 1.21e-06 5.77e-05 1.01e-07 OK
  checking port numbers in packet log:
    node 1: BAD
    node 2: BAD
    network with 1*1 servers and 1 clients:
  non-default settings:
    client_conf=acquisitionport 123
  starting node 1: 

[Group.of.nepali.translators] [Bug 1836929] Re: chrony has migration regressions from autopkgtests (disco/eoan)

[Christian Ehrhardt ]

** Changed in: chrony (Ubuntu Eoan)
 Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)

** Changed in: chrony (Ubuntu Disco)
   Status: Won't Fix => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1836929

Title:
  chrony has migration regressions from autopkgtests (disco/eoan)

Status in chrony package in Ubuntu:
  Fix Released
Status in chrony source package in Xenial:
  Won't Fix
Status in chrony source package in Bionic:
  Won't Fix
Status in chrony source package in Cosmic:
  Won't Fix
Status in chrony source package in Disco:
  Triaged
Status in chrony source package in Eoan:
  Fix Released

Bug description:
  Checking last eoan merge I realized that some tests were failing for
  chrony:

  
https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/369588/comments/967625

  But eoan ran autopkgtests okay when the trigger was
  chrony/3.5-2ubuntu2 (this last merge):

  http://autopkgtest.ubuntu.com/packages/chrony/eoan/amd64

  Despite having failed for the previous 12 times (eoan).

  Now, for the first time, we have the same failure for disco:

  http://autopkgtest.ubuntu.com/packages/chrony/disco/amd64

  http://bit.ly/2LpMx4G

  """
  make: Leaving directory 
'/tmp/autopkgtest.pBHSAl/build.WCD/src/test/simulation/clknetsim'
  ...
  110-chronyc    PASS
  111-knownclient    FAIL
  112-port   FAIL
  121-orphan PASS
  ...
  SUMMARY:
    TOTAL  50
    PASSED 48
    FAILED 2(111-knownclient 112-port) (255 256 257 258 259 260 261 262 263 
264 265 266 267 268 269 270 271 272 273 274 255 256 257 258 259 260 261 262 263 
264 265 266 267 268 269 270 271 272 273 274 265)
  """

  And I'm able to reproduce locally:

  """
  (c)inaddy@iproute2verification:~/work/sources/ubuntu/chrony/test/simulation$ 
./111-knownclient
  Testing reply to client configured as server:
    network with 1*1 servers and 1 clients:
  non-default settings:
    client_conf=acquisitionport 123
    server_conf=server 192.168.123.2 noselect acquisitionport 123
  starting node 1: OK
  starting node 2: OK
  running simulation: OK
  checking chronyd exit:
    node 1: OK
    node 2: OK
  checking source selection:
    node 2: OK
  checking port numbers in packet log:
    node 1: BAD
    node 2: BAD
  FAIL

  AND

  (c)inaddy@iproute2verification:~/work/sources/ubuntu/chrony/test/simulation$ 
./112-port
  Testing port and acquisitionport directives:
    network with 1*1 servers and 1 clients:
  non-default settings:
  starting node 1: OK
  starting node 2: OK
  running simulation: OK
  checking chronyd exit:
    node 1: OK
    node 2: OK
  checking source selection:
    node 2: OK
  checking mean/min incoming/outgoing packet interval:
    node 1: 2.74e+02 2.74e+02 6.40e+01 6.40e+01 OK
    node 2: 2.74e+02 2.74e+02 6.40e+01 6.40e+01 OK
  checking clock sync time, max/rms time/freq error:
    node 2: 132 9.29e-05 1.21e-06 5.77e-05 1.01e-07 OK
  checking port numbers in packet log:
    node 1: BAD
    node 2: BAD
    network with 1*1 servers and 1 clients:
  non-default settings:
    client_conf=acquisitionport 123
  starting node 1: OK
  starting node 2: OK
  running simulation: OK
  checking chronyd exit:
    node 1: OK
    node 2: OK
  checking port numbers in packet log:
    node 1: BAD
    node 2: BAD
  FAIL
  """

  When doing verification for an iproute2 bug (LP: #1831775) we faced
  the 1st failure in autopkgtests for chrony in disco (at least from the
  ones I can check from autopkgtests.ubuntu.com).

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1832622] Re: QEMU - count cache flush Spectre v2 mitigation (CVE) (required for POWER9 DD2.3)

[Christian Ehrhardt ]

Cosmic is about to end full support, lets reduce the test matrix a bit
by already dropping the Cosmic task.

@IBM - I'm still waiting on a positive feedback on this sniff test.
Without I can't reliable make it part of the next coming (soon) qemu upload.
Also to be aware once SRUs on this are accepted by the SRU Team the same tests 
will be needed for Bionic and Disco.

** Changed in: qemu (Ubuntu Cosmic)
   Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1832622

Title:
  QEMU -  count cache flush Spectre v2 mitigation (CVE) (required for
  POWER9 DD2.3)

Status in The Ubuntu-power-systems project:
  In Progress
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Won't Fix
Status in qemu source package in Bionic:
  Incomplete
Status in qemu source package in Cosmic:
  Won't Fix
Status in qemu source package in Disco:
  Incomplete
Status in qemu source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * This belongs to the overall context of spectre mitigations and even 
 more the try to minimize the related performance impacts.
 On ppc64el there is a new chip revision (DD 2.3) which provides
 a facility that helps to better mitigate some of this.

   * Backport the patches that will make the feature (if supported by the 
 HW) will pass the capability to the guest - to allow guests that 
 support the improved mitigation to use it.

  [Test Case]

   * Start guests with and without this capability
 * Check if the capability is guest visible as intented
 * Check if there are any issues on pre DD2.3 HW
   * Test migrations (IBM outlined the intented paths that will work 
 below)
   * The problem with the above (and also the reasons I didn't add a list 
 of commands this time) is that it needs special HW (mentioned DD2.3 
 revision) of the chips which aren't available to us right now.
 Due to that testing / verification of this on all releases is on IBM

  [Regression Potential]

   * Adding new capabilities usually works fine, there are three common 
 pitfalls which here are the regression potential.
 - (severe) the code would announce a capability that isn't really 
   available. The guest tries to use it and crashes
 - (medium) several migration paths especially from systems with the 
   new cap to older (un-updated systems) will fail. But that applies 
   to any "from machine with Feature to machine without that feature" 
   and isn't really a new regression. As outlined by IBM below they 
   even tried to make it somewhat compatible (by being a new value in 
   an existing cap)
 - (low) the guest will see new caps and or facilities. A really odd
   guest could stumble due to that (would actually be a guest bug 
   then)
Overall all of the above was considered by IBM when developing this 
and should be ok. For archive wide SRU considerations, this has NO 
effect on non ppc64el.

  [Other Info]
   
   * n/a

  ---

  Power9 DD 2.3  CPUs  running updated firmware will use a new Spectre
  v2 mitigation. The new mitigation improves performance of branch heavy
  workloads, but also requires kernel support in order to be fully
  secure.

  Without the kernel support there is a risk of a Spectre v2 attack
  across a process context switch, though it has not been demonstrated
  in practice.

  QEMU portion - platform definition needs to account for this new
  mitigation action.. so attribute for this needs to be added.

  In terms of support for virtualisation there are 2 sides, kvm and qemu
  support. Patch list for each,

  KVM:
  2b57ecd0208f KVM: PPC: Book3S: Add count cache flush parameters to 
kvmppc_get_cpu_char()
  This is part of LP1822870 already.

  QEMU:
  8ff43ee404 target/ppc/spapr: Add SPAPR_CAP_CCF_ASSIST
  399b2896d4 target/ppc/spapr: Add workaround option to SPAPR_CAP_IBS

  The KVM side is upstream as of v5.1-rc1.
  The QEMU side is upstream as of v4.0.0-rc0.

  In terms of migration the state is as follows.

  In order to specify to the guest to use the count cache flush
  workaround we use the spapr-cap cap-ibs (indirect branch speculation)
  with the value workaround. Previously the only valid values were
  broken, fixed-ibs (indirect branch serialisation) and fixed-ccd (count
  cache disabled). And add a new cap cap-ccf-assist (count cache flush
  assist) to specify the availability of the hardware assisted flush
  variant.

  Note the the way spapr caps work you can migrate to a host that supports a 
higher value, but not to one which doesn't support the current value (i.e. only 
supports lower values). Where for cap-ibs these are defined as:
  0 - Broken
  1 - Workaround
  2 - fixed-ibs
  3 - fixed-ccd

  So the following migrations would be 

[Group.of.nepali.translators] [Bug 1830243] Re: [19.10 FEAT] KVM: Secure Linux Boot Toleration - qemu

[Christian Ehrhardt ]

Yeah lets focus on 2497b4a3 "s390-bios: Skip bootmap signature entries" here 
then.
If ever "IPLing from a dasd attached via vfio-ccw" is wanted that would be an 
extra bug/discussion.
Thanks Christian B. for pointing to the core change of this bug!

That way it applies as-is to 3.1, with very slight noise to 2.11 and even 2.5.
Started test builds in [1] as a PPA to evaluate.

Who has s390x test kernels with secure boot enabled available to give this a 
try?
Marking the bug tasks incomplete until that has been verified.

For formal review MPs are up [2][3][4] as well.

P.S. Cosmic will be EOL until this reaches the SRU queues. Not preparing
that.

[1]: 
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830243-secure-boot-toleration
[2]: 
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/369709
[3]: 
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/369710
[4]: 
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/369711

** Changed in: qemu (Ubuntu Disco)
   Status: New => Incomplete

** Changed in: qemu (Ubuntu Cosmic)
   Status: New => Incomplete

** Changed in: qemu (Ubuntu Cosmic)
   Status: Incomplete => Won't Fix

** Changed in: qemu (Ubuntu Bionic)
   Status: New => Incomplete

** Changed in: qemu (Ubuntu Xenial)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1830243

Title:
  [19.10 FEAT] KVM: Secure Linux Boot Toleration - qemu

Status in Ubuntu on IBM z Systems:
  In Progress
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Incomplete
Status in qemu source package in Bionic:
  Incomplete
Status in qemu source package in Cosmic:
  Won't Fix
Status in qemu source package in Disco:
  Incomplete
Status in qemu source package in Eoan:
  Fix Released

Bug description:
  Secure boot enablement KVM.
  Will be made available with qemu 4.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1830243/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1834514] Re: client service crashes when pulled options change

[Christian Ehrhardt ]

Hi,
this was adressed by upstream in [1]
and by adopted by Debian/Ubuntu in version 2.4.4-1 
  * Further changes to debian/openvpn@.service copied from upstream
- Enable Restart=on-failure
- Use KillMode=process
which in releases means Bionic and later is already fixed in regard to your 
request to consider restarting it automatically.

For Xenial IMHO the SRU [2] policy forbids this change as it could
change behavior in an unexpected way without the users noticing.
Fortunately users - like you - which conciously want this change to be
active on xenial can just add the lines via `systemctl edit `

  RestartSec=5s
  Restart=on-failure

[1]: 
https://github.com/OpenVPN/openvpn/commit/a4686e99b047081f0ef6f7945450183088464aa5
[2]: https://wiki.ubuntu.com/StableReleaseUpdates

** Also affects: openvpn (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: openvpn (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: openvpn (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: openvpn (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: openvpn (Ubuntu Bionic)
   Status: Triaged => Fix Released

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1834514

Title:
  client service crashes when pulled options change

Status in openvpn package in Ubuntu:
  Fix Released
Status in openvpn source package in Xenial:
  Won't Fix
Status in openvpn source package in Bionic:
  Fix Released

Bug description:
  package version: 2.3.10-1ubuntu2.1

  Crash logs:
  Jun 27 10:51:28 ubuntu-xenial ovpn-client[1182]: Preserving previous TUN/TAP 
instance: tun0
  Jun 27 10:51:28 ubuntu-xenial ovpn-client[1182]: NOTE: Pulled options changed 
on restart, will need to close and reopen TUN/TAP device.
  Jun 27 10:51:28 ubuntu-xenial ovpn-client[1182]: Closing TUN/TAP interface
  Jun 27 10:51:28 ubuntu-xenial ovpn-client[1182]: /sbin/ip addr del dev tun0 
local 10.66.0.32 peer 10.66.0.1
  Jun 27 10:51:28 ubuntu-xenial ovpn-client[1182]: Linux ip addr del failed: 
external program exited with error status: 2
  Jun 27 10:51:29 ubuntu-xenial ovpn-client[1182]: ROUTE_GATEWAY 
10.20.0.1/255.255.240.0 IFACE=enp0s8 HWADDR=08:00:27:b0:b7:a9
  Jun 27 10:51:29 ubuntu-xenial ovpn-client[1182]: ERROR: Cannot ioctl 
TUNSETIFF tun: Operation not permitted (errno=1)
  Jun 27 10:51:29 ubuntu-xenial ovpn-client[1182]: Exiting due to fatal error
  Jun 27 10:51:29 ubuntu-xenial systemd[1]: openvpn@client.service: Main 
process exited, code=exited, status=1/FAILURE
  Jun 27 10:51:29 ubuntu-xenial systemd[1]: openvpn@client.service: Unit 
entered failed state.
  Jun 27 10:51:29 ubuntu-xenial systemd[1]: openvpn@client.service: Failed with 
result 'exit-code'.


  When the client reconnects after a disconnect and the pulled options
  change in a way that the client requires an interface reset, it
  crashes, because it doesn't have the privileges anymore. Privileges
  are dropped by openvpn after startup for security reason as far as i
  understood.

  This google search shows that this is a common problem of openvpn:
  
https://www.google.com/search?ei=1uIUXeXTM8_N6ATK_p6gCw=openvpn+Pulled+options+changed+on+restart%2C+will+need+to+close+and+reopen+TUN%2FTAP+device=openvpn+Pulled+options+changed+on+restart%2C+will+need+to+close+and+reopen+TUN%2FTAP+device

  I'm aware that my specific problem might be fixed by bugfixes like
  this: https://community.openvpn.net/openvpn/ticket/649

  But as long as the possibility exists that a change in the pulled
  options require an interface reset, the service WILL crash and never
  restart without manual user interaction.

  This could be fixed by adding "Restart=on-failure" to the openvpn-
  client@.service for example.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1833781] Re: backport mod_reqtimeout with handshake support

[Christian Ehrhardt ]

This looks like a feature request to me, is there a bug that would make
this SRUable since you added a xenial diff?

Further it is quite some code and due to that more regression risk - so
without a broken use case that will be hard.

I'd ask you to provide a full SRU template [1] before going on with it.

** Also affects: apache2 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: apache2 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: apache2 (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: apache2 (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Changed in: apache2 (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: apache2 (Ubuntu Bionic)
   Status: New => Won't Fix

** Changed in: apache2 (Ubuntu Cosmic)
   Status: New => Won't Fix

** Changed in: apache2 (Ubuntu Disco)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1833781

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  New
Status in apache2 source package in Xenial:
  Won't Fix
Status in apache2 source package in Bionic:
  Won't Fix
Status in apache2 source package in Cosmic:
  Won't Fix
Status in apache2 source package in Disco:
  Won't Fix

Bug description:
  While mod_reqtimeout has been present since 2.2.15, the handshake parameter 
to RequestReadTimeout 
  was not added until 2.4.39. 

  The attached patch is for apache2_2.4.18-2ubuntu3.10 (Xenial), and
  will need to be backported to other versions.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1832622] Re: QEMU - count cache flush Spectre v2 mitigation (CVE) (required for POWER9 DD2.3)

[Christian Ehrhardt ]

I'm glad that the kernel patch is already integrated by bug 1822870 in
>=Bionic - no dependency on the kernel here then.

The patches themselve look small and clean.
Thanks for identifying the extra dependencies to:
- 8fea7044 (>=3.0)  target/ppc: Factor out the parsing in 
kvmppc_get_cpu_characteristics()
- 8c5909c4 (>=2.12) ppc/spapr-caps: Change migration macro to take full 
spapr-cap name

That overall makes the request to apply:
- 8c5909c4 (>=2.12) ppc/spapr-caps: Change migration macro to take full 
spapr-cap name
- 8fea7044 (>=3.0)  target/ppc: Factor out the parsing in 
kvmppc_get_cpu_characteristics()
- 399b2896 (>=4.0) target/ppc/spapr: Add workaround option to SPAPR_CAP_IBS
- 8ff43ee4 (>=4.0) target/ppc/spapr: Add SPAPR_CAP_CCF_ASSIST

By reading the bug top down I ran into issues with patch #4, but then I
read the rest and found that you already handled that. Taking the
backport from the referenced git worked great, thanks Michael.

There was some minor noise bringing that to 2.12 and 3.0 but it worked rather 
straight forward as expected for 2.12. In qemu 3.0 thou we need something else 
for the fourth patch. Neither the upstream original (9 rejects), nor the 
backport you provided for 2.11 apply (10 rejects).
Upstream is a bit closer, the lack of "large decr" in qemu 3.0 shows up as 
context change a few times, but those were resovable.

For "SPAPR_CAP_CCF_ASSIST" I followed your backport of leaving no holes
in the cap numbering (the alternative would be to retain it being 0x9,
but leave some in between undefined which would break when iterating).

TODO
check cosmic applied include/hw/ppc/spapr.h  SPAPR_CAP_CCF_ASSIST for wholes

IIRC Xenial has no P9 support and probably would be much harder to
backport, so unless further discussion this is a Won't Fix for Xenial.

Timing: we have a qemu SRU in the pipe that needs verification and
release. Once done we will enqueue that one.

But until then we can still work on this.
I opend MPs for internal review with the backports for Bionic/Cosmic/Disco/Eoan 
(linked to the bug here) and a PPA [1].
If you want to test anything ahead of proposed please feel free to take a look 
at MPs and/or the PPA.

[1]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1832622-qemu-
spectre-ppc

** Also affects: qemu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Eoan)
   Importance: Undecided
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
   Status: New

** Also affects: qemu (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Changed in: qemu (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: qemu (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: qemu (Ubuntu Cosmic)
   Status: New => Triaged

** Changed in: qemu (Ubuntu Disco)
   Status: New => Triaged

** Changed in: qemu (Ubuntu Eoan)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1832622

Title:
  QEMU -  count cache flush Spectre v2 mitigation (CVE) (required for
  POWER9 DD2.3)

Status in The Ubuntu-power-systems project:
  New
Status in qemu package in Ubuntu:
  Triaged
Status in qemu source package in Xenial:
  Won't Fix
Status in qemu source package in Bionic:
  Triaged
Status in qemu source package in Cosmic:
  Triaged
Status in qemu source package in Disco:
  Triaged
Status in qemu source package in Eoan:
  Triaged

Bug description:
  Power9 DD 2.3  CPUs  running updated firmware will use a new Spectre
  v2 mitigation. The new mitigation improves performance of branch heavy
  workloads, but also requires kernel support in order to be fully
  secure.

  Without the kernel support there is a risk of a Spectre v2 attack
  across a process context switch, though it has not been demonstrated
  in practice.

  
  QEMU portion - platform definition needs to account for this new mitigation 
action.. so attribute for this needs to be added.

  In terms of support for virtualisation there are 2 sides, kvm and qemu
  support. Patch list for each,

  KVM:
  2b57ecd0208f KVM: PPC: Book3S: Add count cache flush parameters to 
kvmppc_get_cpu_char()
  This is part of LP1822870 already.

  QEMU:
  8ff43ee404 target/ppc/spapr: Add SPAPR_CAP_CCF_ASSIST
  399b2896d4 target/ppc/spapr: Add workaround option to SPAPR_CAP_IBS

  The KVM side is upstream as of v5.1-rc1.
  The QEMU side is upstream as of v4.0.0-rc0.

  In terms of migration the state is as follows.

  In order to specify to the guest to use the count cache flush
  workaround we use the spapr-cap cap-ibs (indirect branch speculation)
  with the value workaround. Previously the only valid values were

[Group.of.nepali.translators] [Bug 1830268] Re: Use changed nested VMX attribute as trigger to refresh libvirt capability cache

[Christian Ehrhardt ]

Hmm, we just don't need the xenial portion.
As already mentioned at the backport the code was way different then.

I can start a VMX defined guest on Xenial:

  
core2duo
Intel

  

And it becomes -cpu core2duo,+vmx for qemu commandline.
So Xenial is actually "invalid" as the issue described here doesn't apply there.

** Changed in: libvirt (Ubuntu Xenial)
   Status: Triaged => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1830268

Title:
  Use changed nested VMX attribute as trigger to refresh libvirt
  capability cache

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Invalid
Status in libvirt source package in Bionic:
  In Progress
Status in libvirt source package in Cosmic:
  In Progress

Bug description:
  [impact]

  libvirt caches the 'nested vmx' capability of the host and does not
  update that even if the host's capability to handle nested vmx
  changes.  Having this domcapability missing means no guests are able
  to start any nested, kvm-accelerated, guests.  Additionally, since
  openstack live migration requires matching cpu features, this makes
  migrating guests that do have vmx enabled impossible to hosts where
  libvirt thinks nested vmx is disabled.

  Once the kernel module (kvm_intel) is reloaded with 'nested' enabled,
  libvirt does not update its domcapabilities cache, even over a
  libvirtd restart, or even over an entire system reboot.  Only certain
  conditions cause libvirt to update its capabilities cache (possibly
  libvirt upgrade, or qemu upgrade, or kernel upgrade...I haven't
  verified any of those yet)

  libvirt creates caches for its domcapabilities at 
/var/cache/libvirt/qemu/capabilities/.
  removing the cache xml files there and restarting libvirtd will cause the 
caches to be recreated with the correct current values.

  The fix backports the upstream fix:
  https://libvirt.org/git/?p=libvirt.git;a=commit;h=b183a753
  Which makes it always check the current vs the last stored attribute.

  [test case]

  check the kvm_intel module nested parameter:
  $ cat /sys/module/kvm_intel/parameters/nested
  Y

  it can be Y or N.  make sure libvirt agrees with the current setting:
  $ virsh domcapabilities | grep vmx
    

  if 'nested' is Y, domcapabilities should include a vmx feature line;
  if 'nested' is N, it should have no output (i.e. vmx not supported in
  guests).

  Then, change the kernel nested setting, and re-check domcapabilities.
  Restarting libvirtd doesn't update the cache, and even rebooting the
  entire system doesn't update the cache.

  $ virsh domcapabilities | grep vmx
  $ cat /sys/module/kvm_intel/parameters/nested
  N
  $ sudo rmmod kvm_intel
  $ sudo modprobe kvm_intel nested=1
  $ cat /sys/module/kvm_intel/parameters/nested
  Y
  $ virsh domcapabilities | grep vmx
  $ sudo systemctl restart libvirtd
  $ virsh domcapabilities | grep vmx
  $

  Not only should it work, but further configurung libvirt debug [1] the fix 
should leave a message like this when triggering:
    VIR_DEBUG("Outdated capabilities for '%s': kvm kernel nested "
  "value changed from %d",)

  Test #2:
  - restart libvirtd
  - call `virsh domcapabilities`
  - repeat the above
  - this should later on use the cache (faster)
  - If it always regenerates the cache (see spawned qemu's and new file
    dates) the detection is wrong

  Test #3:
  - some arches (e.g. s390x) don't have this attribute, check on one of those 
how their behavior changes.

  [regression potential]

  This will make libvirt refresh the capability cache more often. This is a 
quite expensive tasks (depending on the number of qemu's installed which can be 
anything from none to all arch emulators and the kvm based ones ~10. Those will 
be forked and probed again. The new code now adds a rather safe detection as 
the nested attribute would usually only change on a reboot or a module reload. 
So it should be rather safe. The one real regression would be if the detection 
would be wrong and always trigger.
  I added Test #2 above to check for that.

  [other info]

  related RH bugs, though no changes appear to have resulted from either:
  https://bugzilla.redhat.com/show_bug.cgi?id=1474874
  https://bugzilla.redhat.com/show_bug.cgi?id=1650950

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1762492] Re: pgsql resource agent should check for stats_temp_directory

[Christian Ehrhardt ]

Setting dev version to fix released per last comment.

** Changed in: resource-agents (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1762492

Title:
  pgsql resource agent should check for stats_temp_directory

Status in resource-agents package in Ubuntu:
  Fix Released
Status in resource-agents source package in Xenial:
  New
Status in resource-agents source package in Artful:
  Invalid
Status in resource-agents source package in Bionic:
  New

Bug description:
  [Impact]

   * Default postgres installation in Ubuntu (and Debian) configures 
stats_temp_directory inside /var/run/postgresql. However, this directory is not 
created after reboot. Usually this directory is created by pg_ctlcluster, which 
is a pg_ctl wraper called by systemd/upstart. However postgres resource agent 
is not using pg_ctlcluster when starting postgres, it calls pg_ctl directly, 
which won't recreate missing directories.
  This will prevent resource agent to properly start postgres.

   * This bug is already fixed in upstream:
  https://github.com/ClusterLabs/resource-agents/pull/1102/

   * This SRU cherrypicks the commit from the upstream - the commit
  checks if configured stats directory exists, and if it does not it
  tries to create it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1762492/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1749283] Re: configured stats_temp_directory does not get created after reboot

[Christian Ehrhardt ]

Thanks for the clarification Mario!
Now things fit together.
I'll mark the resource agent tasks invalid here per these comments to make sure 
no one is confused again.

TL;DR:
- not fixed in postgresql-common
- only fixed in resouce-agent for Xenial/Bionic via SRU in bug 1762492

** Changed in: resource-agents (Ubuntu Xenial)
   Status: Confirmed => Invalid

** Changed in: resource-agents (Ubuntu Bionic)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1749283

Title:
  configured stats_temp_directory does not get created after reboot

Status in postgresql-common package in Ubuntu:
  Won't Fix
Status in resource-agents package in Ubuntu:
  Fix Released
Status in postgresql-common source package in Xenial:
  Won't Fix
Status in resource-agents source package in Xenial:
  Invalid
Status in postgresql-common source package in Bionic:
  Won't Fix
Status in resource-agents source package in Bionic:
  Invalid
Status in postgresql-common package in Debian:
  Fix Released

Bug description:
  Default postgres installation in Ubuntu (and Debian) configures
  stats_temp_directory inside /var/run/postgresql:

  $ grep stats_temp /etc/postgresql/10/main/postgresql.conf 
  stats_temp_directory = '/var/run/postgresql/10-main.pg_stat_tmp'

  However, this directory is not created after reboot.

  In most cases this is not a problem as systemd starts postgres via
  pg_ctlcluster, a "multiversion/cluster aware pg_ctl wrapper", and
  pg_ctlcluster will create missing directories before starting
  postgres.

  But in cases where systemd is not starting postgres this is a problem.
  Specifically, when postgres is controlled by pacemaker (using postgres 
resource agent for pacemaker) it is started using pg_ctl wrapper. pg_ctl won't 
create missing directories and therefore postgres fails to start.

  The simplest solution for this issue is to have systemd recreate
  missing directories via /usr/lib/tmpfiles.d/postgresql.conf file.

  Currently only /var/run/postgresql and /var/log/postgresql are created
  using systemd-tmpfiles.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1749283/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1829823] Re: libvirt-bin: during shutdown libvirt-bin is stopped before libvirt-guests causing hang

[Christian Ehrhardt ]

n:
  
-  If you follow the same steps with the fixed package, when you look at
-  /var/log/upstart/libvirt-bin.log, you will see output of libvirt-guests
-  connecting to and shutting down the virtual machines which looks a little
-  like this: https://paste.ubuntu.com/p/s4jyJX2y9F/
+  If you follow the same steps with the fixed package, when you look at
+  /var/log/upstart/libvirt-bin.log, you will see output of libvirt-guests
+  connecting to and shutting down the virtual machines which looks a little
+  like this: https://paste.ubuntu.com/p/s4jyJX2y9F/
  
  [Regression Potential]
  
   * There is only one file modified, the upstart script for libvirt-bin.
     Currently this upstart file references a file which doesn't exist, so
-    fixing it will restore the behaviour in a way which aligns with exactly
+    fixing it will restore the behavior in a way which aligns with exactly
     what took place in previous versions.
  
-  * In xenial, there is no concern of stopping an already stopped service in
-    the event that the upstart script pre-stop section is called by systemd.
+  * In xenial, all of this isn't used at all - see below at "Other Info"
  
   * This change only effects systems during shutdown while they still
     have virtual machines running, and do not effect starting and stopping
     services while the machine is running normally.
  
   * I believe the regression potential is low.
  
  [Other Info]
  
   * Xenial is not effected by this bug even though it ships the exact same
     packages. This is because xenial uses insserv to generate service
-    dependency files ".depend.boot" ".depend.start" ".depend.stop" which parse
-    the scripts in /etc/init.d/ and systemd respects the dependency ordering
-    in these files.
-    libvirt-guests reports a dependency on libvirt-bin in the script header,
-    so systemd will always stop libvirt-guests before libvirt-bin, avoiding
-    the problem seen in trusty.
+    dependency files ".depend.boot" ".depend.start" ".depend.stop" which 
+parse the scripts in /etc/init.d/ and systemd respects the dependency 
+ordering in these files.
+    libvirt-guests reports a dependency on libvirt-bin in the script 
+header, so systemd will always stop libvirt-guests before libvirt-bin, 
+avoiding the problem seen in trusty.
  
-  * The fix is needed in trusty mitaka UCA and xenial will likely need the SRU
-    as part of the process.
+  * The fix is needed in trusty mitaka UCA and xenial will likely need the 
+SRU as part of the process.
+ 
+  * We'd never have uploaded that change alone for xenial (being a no-op 
+causing MBs to download and an upgrade. But we will bundle it with an 
+actual change - so it can "ride along" to eventually help
+Trusty-Mitaka.

** Changed in: libvirt (Ubuntu Xenial)
   Status: Fix Released => Triaged

** Changed in: libvirt (Ubuntu Xenial)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1829823

Title:
  libvirt-bin: during shutdown libvirt-bin is stopped before libvirt-
  guests causing hang

Status in Ubuntu Cloud Archive:
  In Progress
Status in libvirt package in Ubuntu:
  Invalid
Status in libvirt source package in Xenial:
  Triaged

Bug description:
  [Impact]

   * libvirt-bin, in: libvirt-1.3.1-1ubuntu10.24~cloud0 in trusty mitaka uca
     and the parent package in xenial, libvirt-1.3.1-1ubuntu10.24 are 
 affected.

   * When you shutdown a system in trusty which is running some kvm virtual
     machines, the libvirt-bin service is stopped before libvirt-guests.
     libvirt-guests tries to connect to the libvirt socket to send shutdown
     commands to the running vms, which cannot happen since libvirtd is not
     running.

   * On some machines, the qemu processes behind the virtual machines are 
 not killed and are left behind as defunct processes, which can cause 
 the system to hang on them not being terminated.

   * The bug is caused by the libvirt-bin upstart script [1] calling a
     non-existant script, /usr/lib/libvirt/libvirt-stop-guests [2]. This 
 script used to exist in the upstart script itself in version
 1.2.2-0ubuntu13.1.27 [3], the version in the trusty archives. In 
 liberty UCA, version 1.2.16-2ubuntu11.15.10.4~cloud0 [4], the script 
 was separated out into /usr/lib/libvirt/libvirt-stop-guests [2].
 In the mitaka release, the libvirt-stop-guests script was removed and 
 rewritten as /etc/init.d/libvirt-guests [5], but the script in [1] was 
 never updated to point to it.

     [1] http://paste.ubuntu.com/p/GxxBczkCmk
     [2] http://paste.ubuntu.com/p/fKCDQh46vh
     [3] http://paste.ubuntu.com/p/QrKXqK2Bvz
   

[Group.of.nepali.translators] [Bug 1830268] Re: libvirt caches nested vmx capability (in domcapabilities)

[Christian Ehrhardt ]

Currently libvirt tracks these elements to consider refreshing (they are
stored in the capability XMLs themselves).


  1558846766
  1557980947
  400

There are other ctime based caches as well like virQEMUCapsKVMUsable for
/dev/kvm.

The checker for the main caps is virQEMUCapsIsValid and so far checks:
- libvirt ctime (binary)
- libvirt version (internal build time value)
- qemu bin ctime (binary)
- do not not go further down if on emulated arch (won't change)
- /dev/kvm got accessible since last caching (DAC)
- /dev/kvm got unavailable since last caching (DAC)
- microcode changed (cpuinfo)
- kernel version changed
- Nesting is now supported

The latter sounds familiar right?
=> 
https://libvirt.org/git/?p=libvirt.git;a=commit;h=b183a75319b90d0af5512be513743e1eab950612

That is in 5.0 which means =>Disco already.
Lets check how backportable that is ...

** Also affects: libvirt (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1830268

Title:
  libvirt caches nested vmx capability (in domcapabilities)

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  New
Status in libvirt source package in Bionic:
  New
Status in libvirt source package in Cosmic:
  New

Bug description:
  [impact]

  libvirt caches the 'nested vmx' capability of the host and does not
  update that even if the host's capability to handle nested vmx
  changes.  Having this domcapability missing means no guests are able
  to start any nested, kvm-accelerated, guests.  Additionally, since
  openstack live migration requires matching cpu features, this makes
  migrating guests that do have vmx enabled impossible to hosts where
  libvirt thinks nested vmx is disabled.

  Once the kernel module (kvm_intel) is reloaded with 'nested' enabled,
  libvirt does not update its domcapabilities cache, even over a
  libvirtd restart, or even over an entire system reboot.  Only certain
  conditions cause libvirt to update its capabilities cache (possibly
  libvirt upgrade, or qemu upgrade, or kernel upgrade...I haven't
  verified any of those yet)

  libvirt creates caches for its domcapabilities at 
/var/cache/libvirt/qemu/capabilities/.
  removing the cache xml files there and restarting libvirtd will cause the 
caches to be recreated with the correct current values.

  [test case]

  check the kvm_intel module nested parameter:
  $ cat /sys/module/kvm_intel/parameters/nested
  Y

  it can be Y or N.  make sure libvirt agrees with the current setting:
  $ virsh domcapabilities | grep vmx
    

  if 'nested' is Y, domcapabilities should include a vmx feature line;
  if 'nested' is N, it should have no output (i.e. vmx not supported in
  guests).

  Then, change the kernel nested setting, and re-check domcapabilities.
  Restarting libvirtd doesn't update the cache, and even rebooting the
  entire system doesn't update the cache.

  $ virsh domcapabilities | grep vmx
  $ cat /sys/module/kvm_intel/parameters/nested
  N
  $ sudo rmmod kvm_intel
  $ sudo modprobe kvm_intel nested=1
  $ cat /sys/module/kvm_intel/parameters/nested
  Y
  $ virsh domcapabilities | grep vmx
  $ sudo systemctl restart libvirtd
  $ virsh domcapabilities | grep vmx
  $

  [regression potential]

  TBD, but this should only require better invalidating of the caps
  cache, which seems very low for any regression potential.  More
  overhead to regenerate the cache more often maybe.

  [other info]

  related RH bugs, though no changes appear to have resulted from either:
  https://bugzilla.redhat.com/show_bug.cgi?id=1474874
  https://bugzilla.redhat.com/show_bug.cgi?id=1650950

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1689488] Re: vnc console accepts only 8 characters

[Christian Ehrhardt ]

novnc 1.1 is in disco and later at least.

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

** No longer affects: novnc (Ubuntu Yakkety)

** Changed in: qemu (Ubuntu Xenial)
 Assignee: Christian Ehrhardt  (paelzer) => (unassigned)

** Changed in: qemu (Ubuntu Yakkety)
 Assignee: Christian Ehrhardt  (paelzer) => (unassigned)

** Also affects: qemu (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: novnc (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1689488

Title:
  vnc console accepts only 8 characters

Status in novnc package in Ubuntu:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in novnc source package in Xenial:
  New
Status in qemu source package in Xenial:
  Incomplete
Status in qemu source package in Yakkety:
  Won't Fix
Status in novnc source package in Bionic:
  New
Status in qemu source package in Bionic:
  New

Bug description:
  We have an issue when send message via vnc console. The vnc accepts
  only the first 8 characters.

  The issue happens on ubuntu 15.05/15.10/16.04/16.10, but does not
  exist in ubuntu 14.04 and ubuntu 17.04.

  After investigation, I found the issue is caused by commit
  
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2deb4acc7c7ee770a0e0e75fd321effd916ca7df

  and fixed by commit (it is already included in qemu v2.7.0, and ubuntu 
17.04/qemu-2.8)
  
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c5ce83334465ee5acb6789a2f22d125273761c9e

  Can we include the fix in next minor release of qemu-2.5 for ubuntu
  16.04 ?

  Thanks.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1830033] Re: Connection synchronization daemon fails at start due to a bug in launch script

[Christian Ehrhardt ]

I verified the proposed change (which is in the opposite diff direction
in the initial report) works in VMs and the PPA fixes the issue.

The fix seems easy enough, so I added MPs for Xenial and Bionic and a
PPA with the builds at [1]

[1]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830033-ipvsadm-
start

** Changed in: ipvsadm (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1830033

Title:
  Connection synchronization daemon fails at start due to a bug in
  launch script

Status in ipvsadm package in Ubuntu:
  Fix Released
Status in ipvsadm source package in Xenial:
  Triaged
Status in ipvsadm source package in Bionic:
  Triaged
Status in ipvsadm source package in Cosmic:
  Fix Released
Status in ipvsadm package in Debian:
  Fix Released

Bug description:
  [Impact]

   * the init script has an argument twice, which makes the service fail to 
 start 

   * Without the fix the service is rather unusable as it can't be
  started

  [Test Case]

   * Needs a VM (no container)
 $ sudo apt install ipvsadm
 $ echo 'AUTO="true"' | sudo tee -a /etc/default/ipvsadm
 $ echo 'DAEMON="master"' | sudo tee -a /etc/default/ipvsadm
 $ sudo systemctl restart ipvsadm
 $ systemctl status ipvsadm

 With the bug this will show the sevrice failing
 [...]
 Try `/sbin/ipvsadm -h' or '/sbin/ipvsadm --help' for more information.
 ...fail!

  
  [Regression Potential] 

   * Even in the default config (just enabling it to run) this doesn't work.
 Hence the risk should be next to none.
 I can think of setups that "are meant to work" , but so far "didn't 
 start" now properly would start. For example if someone 
 configured the service but ignored that it failed to start.
 I hope and expect that this is a rather unimportant risk, it actually 
 is the fix we are intending to make.

  [Other Info]
   
   * TBH it is in main for a dependency from keepalive but I wonder how much 
 that could be a sugegsts instead. But that is for the future.

  ---

  
  The launch script for ipvsadm has a bug that prevents LVS from start in 
synchronization mode.

  How to reproduce.
  1. Install ipvsadm on ubuntu server 16.04 and modify /etc/default/ipvsadm to 
lauch LVS in master mode (or backup):
  AUTO="true"
  DAEMON="master"
  IFACE="eno1"
  SYNCID="0"

  2. Start "ipvsadm" service and check systemd unit log:
  # systemctl start ipvsadm
  # journalctl -u ipvsadm
  What you expected to happen
  The log output without error:
  May 22 12:41:46 xxx systemd[1]: Starting LSB: ipvsadm daemon...
  May 22 12:41:46 xxx ipvsadm[4619]:  * Clearing the current IPVS 
table...
  May 22 12:41:46 xxx ipvsadm[4619]:...done.
  May 22 12:41:46 xxx ipvsadm[4619]:  * Loading IPVS configuration...
  May 22 12:41:46 xxx ipvsadm[4619]:...done.
  May 22 12:41:46 xxx ipvsadm[4619]:  * Starting IPVS Connection 
Synchronization Daemon master
  May 22 12:41:46 xxx ipvsadm[4619]:...done.
  May 22 12:41:46 xxx systemd[1]: Started LSB: ipvsadm daemon.

  What happened instead:
  May 22 12:32:59 xxx systemd[1]: Starting LSB: ipvsadm daemon...
  May 22 12:32:59 xxx ipvsadm[15743]:  * Clearing the current IPVS table...
  May 22 12:32:59 xxx ipvsadm[15743]:...done.
  May 22 12:32:59 xxx ipvsadm[15743]:  * Loading IPVS configuration...
  May 22 12:32:59 xxx ipvsadm[15743]:...done.
  May 22 12:32:59 xxx ipvsadm[15743]:  * Starting IPVS Connection 
Synchronization Daemon master
  May 22 12:32:59 xxx ipvsadm[15743]: Try `/sbin/ipvsadm -h' or 
'/sbin/ipvsadm --help' for more information.
  May 22 12:32:59 xxx ipvsadm[15743]:...fail!
  May 22 12:32:59 xxx ipvsadm[15743]:...done.
  May 22 12:32:59 xxx systemd[1]: Started LSB: ipvsadm daemon.

  As you can see in log output, there is an message: "Try `/sbin/ipvsadm
  -h' or '/sbin/ipvsadm --help' for more information". This message
  relates to bug in script /etc/init.d/ipvsadm.

  Here a difference how script should be updated to get it work:
  --- /etc/init.d/ipvsadm   2019-05-22 12:41:34.429916226 +
  +++ /root/ipvsadm 2019-05-22 11:18:04.307344255 +
  @@ -29,16 +29,16 @@
   case $DAEMON in
    master|backup)
    log_daemon_msg "Starting IPVS Connection Synchronization Daemon" 
"$DAEMON"
  - $IPVSADM --start-daemon $DAEMON --mcast-interface \
  + $IPVSADM --syncid $SYNCID --start-daemon $DAEMON --mcast-interface \
   $IFACE --syncid $SYNCID || log_end_msg 1
    log_end_msg 0
    ;;
    both)
    log_daemon_msg "Starting IPVS Connection Synchronization Daemon" 
"master"
  - $IPVSADM --start-daemon master --mcast-interface \
  + $IPVSADM --syncid $SYNCID 

[Group.of.nepali.translators] [Bug 1829823] Re: libvirt-bin: during shutdown libvirt-bin is stopped before libvirt-guests causing hang

[Christian Ehrhardt ]

Please do -NOT- make a Xenial SRU for that.
As we discussed on IRC and you pointed out in the report yourself - it is not 
affected due to systemd doing it right.

This should only be an Upstart related change that goes on top of the
Cloud-Archive-Mitaka Delta.

** Changed in: libvirt (Ubuntu)
   Status: In Progress => Invalid

** Changed in: libvirt (Ubuntu Xenial)
   Status: In Progress => Invalid

** Changed in: libvirt (Ubuntu)
 Assignee: Matthew Ruffell (mruffell) => (unassigned)

** Changed in: libvirt (Ubuntu Xenial)
 Assignee: Matthew Ruffell (mruffell) => (unassigned)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1829823

Title:
  libvirt-bin: during shutdown libvirt-bin is stopped before libvirt-
  guests causing hang

Status in Ubuntu Cloud Archive:
  In Progress
Status in libvirt package in Ubuntu:
  Invalid
Status in libvirt source package in Xenial:
  Invalid

Bug description:
  [Impact]

   * libvirt-bin, in: libvirt-1.3.1-1ubuntu10.24~cloud0 in trusty mitaka uca
     and the parent package in xenial, libvirt-1.3.1-1ubuntu10.24 are effected.

   * When you shutdown a system in trusty which is running some kvm virtual
     machines, the libvirt-bin service is stopped before libvirt-guests.
     libvirt-guests tries to connect to the libvirt socket to send shutdown
     commands to the running vms, which cannot happen since libvirtd is not
     running.

   * On some machines, the qemu processes behind the virtual machines are not
     killed and are left behind as defunct processes, which can cause the
     system to hang on them not being terminated.

   * The bug is caused by the libvirt-bin upstart script [1] calling a
     non-existant script, /usr/lib/libvirt/libvirt-stop-guests [2]. This script
     used to exist in the upstart script itself in version 1.2.2-0ubuntu13.1.27
     [3], the version in the trusty archives. In liberty UCA,
     version 1.2.16-2ubuntu11.15.10.4~cloud0 [4], the script was seperated out
     into /usr/lib/libvirt/libvirt-stop-guests [2]. In the mitaka release, the
     libvirt-stop-guests script was removed and rewritten as
     /etc/init.d/libvirt-guests [5], but the script in [1] was never updated to
     point to it.

     [1] http://paste.ubuntu.com/p/GxxBczkCmk
     [2] http://paste.ubuntu.com/p/fKCDQh46vh
     [3] http://paste.ubuntu.com/p/QrKXqK2Bvz
     [4] http://paste.ubuntu.com/p/W8DgQwpYv3
     [5] http://paste.ubuntu.com/p/Z28Sp2fPd6

   * Since the upstart script was never updated to point to it, libvirt-bin
     stops without stopping libvirt-guests first. When libvirt-guests is
     stopped later, it cannot access the libvirt socket, cannot shut down the
     machines, causing the bug.

   * The fix is to change the upstart script to point to the new libvirt-guests
     script.

  [Test Case]

   * You can reproduce this in trusty with the mitaka UCA enabled.

   1) Enable mitaka UCA and install libvirt0 and libvirt-bin

   $ sudo add-apt-repository cloud-archive:mitaka
   $ sudo apt update
   $ sudo apt install libvirt0 libvirt-bin

   2) Install a virtual machine, either by using virt-install or virt-manager.
     I used a bionic VM.

   3) Enable debugging on libvirt-guests so you can see what is going on

   Modify /etc/init.d/libvirt-guests and add "-x" to the end of
  "!/bin/sh"

   4) With the vm running, shut down the system

   $ sudo shutdown -h now

   5) Check /var/log/upstart/libvirt-bin.log, on reboot. It will say
   "No such file or directory: /usr/lib/libvirt/libvirt-stop-guests"

   6) During that shutdown, you will see messages like:
   error: failed to connect to the hypervisor
   error: no valid connection
   error: Failed to connect socket to '/var/run/libvirt/libvirt-sock':
   No such file or directory

   What should happen:

   If you follow the same steps with the fixed package, when you look at
   /var/log/upstart/libvirt-bin.log, you will see output of libvirt-guests
   connecting to and shutting down the virtual machines which looks a little
   like this: https://paste.ubuntu.com/p/s4jyJX2y9F/

  [Regression Potential]

   * There is only one file modified, the upstart script for libvirt-bin.
     Currently this upstart file references a file which doesn't exist, so
     fixing it will restore the behaviour in a way which aligns with exactly
     what took place in previous versions.

   * In xenial, there is no concern of stopping an already stopped service in
     the event that the upstart script pre-stop section is called by systemd.

   * This change only effects systems during shutdown while they still
     have virtual machines running, and do not effect starting and stopping
     services while the machine is running normally.

   * I believe the regression potential is low.

  [Other Info]

   * Xenial is not effected by this bug even 

[Group.of.nepali.translators] [Bug 1827286] Re: autofs - "Too many levels of symbolic links" after apt upgrade

[Christian Ehrhardt ]

Debugging per [1], did not show anything new.
There just is no activity on the actual access of /home all I see is the 
trigger for /home registering at startup.

Startup:
ubuntu@xenial-autofs-client:/$ sudo automount -f -v --debug
Starting automounter version 5.1.1, master map /etc/auto.master
using kernel protocol version 5.02
lookup_nss_read_master: reading master file /etc/auto.master
parse_init: parse(sun): init gathered global options: (null)
lookup_read_master: lookup(file): read entry +dir:/etc/auto.master.d
lookup_nss_read_master: reading master dir /etc/auto.master.d
lookup_read_master: lookup(dir): scandir: /etc/auto.master.d
lookup_read_master: lookup(file): read entry /-
master_do_mount: mounting /-
automount_path_to_fifo: fifo name /var/run/autofs.fifo--
lookup_nss_read_map: reading map file /etc/auto.nfs
parse_init: parse(sun): init gathered global options: 
nosymlink,fstype=nfs,nfsvers=3,rw,hard,intr,rsize=8192,wsize=8192
mounted direct on /home with timeouts disabled
do_mount_autofs_direct: mounted trigger /home
st_ready: st_ready(): state = 0 path /-

It is the open syscall itself that fails:
0.29 open("/home", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ELOOP 
(Too many levels of symbolic links) <0.12>

So we must have set up the kernel/trigger to be broken - no userspace component 
active at the time (although it might have set it up wrong before).
But since I haven't found fixes in autofs maybe it is fixed in the kernel then?

Yes, here I found a fix.
Installing linux-virtual-hwe-16.04 (since I was in a VM to test) resolved the 
issue.
With the same setup I can now mount /home just fine again on Xenial.

On a bare metal system you likely want linux-generic-hwe-16.04 instead.

I'm adding a kernel task to potentially identify and backport the fix to the 
4.4 kernel, but since after so much time it isn't in the stable releases 
chances are that it is hard to backport.
Until then you can get this issue resolved with the -hwe kernels.

[1]:
https://help.ubuntu.com/community/Autofs#Debugging_Auto_Mount_Problems

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

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

** Also affects: autofs5 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Also affects: autofs5 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

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

** Changed in: autofs5 (Ubuntu)
   Status: Confirmed => Invalid

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

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

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1827286

Title:
  autofs  - "Too many levels of symbolic links" after apt upgrade

Status in autofs5 package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in autofs5 source package in Xenial:
  Invalid
Status in linux source package in Xenial:
  Confirmed
Status in autofs5 source package in Bionic:
  Invalid
Status in linux source package in Bionic:
  Fix Released

Bug description:
  Description:Ubuntu 16.04.6 LTS
  Release:16.04

  I moved to autofs this week as a workaround for Bug #1577575 failing
  to mount NFS entries at boot. This worked file until I ran 'apt
  upgrade' today.

  Now trying to access /vol/home mount results in the following error:

  root@chi:~# ls -la /vol/home/
  ls: cannot access '/vol/home/': Too many levels of symbolic links
  root@chi:~# 

  Oddly enough, the other two autofs entries work fine (output trimmed):
  root@chi:~# ls -la /vol/media
  total 4
  ...
  root@chi:~# 
  root@chi:~# ls -al /vol/temp/
  total 24
  ...
  root@chi:~# 

  
  I have a scratch VM I can break tonight by performing upgrades individually 
and testing after each.  Will provide that detail when available.

  
  Here is /var/log/apt/history.log

   Start-Date: 2019-05-01  17:37:00
  Commandline: apt upgrade
  Upgrade: libdns-export162:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12, 
1:9.10.3.dfsg.P4-8ubuntu1.14), libisccfg140:amd64 
(1:9.10.3.dfsg.P4-8ubuntu1.12, 1:9.10.3.dfsg.P4-8ubuntu1.14), ureadahead:amd64 
(0.100.0-19, 0.100.0-19.1), libldap-2.4-2:amd64 (2.4.42+dfsg-2ubuntu3.4, 
2.4.42+dfsg-2ubuntu3.5), libirs141:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12, 
1:9.10.3.dfsg.P4-8ubuntu1.14), bind9-host:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12, 
1:9.10.3.dfsg.P4-8ubuntu1.14), dnsutils:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12, 
1:9.10.3.dfsg.P4-8ubuntu1.14), libisc160:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12, 

[Group.of.nepali.translators] [Bug 1823872] Re: Fixing fsfreeze-hook can break unattended upgrades

[Christian Ehrhardt ]

Thanks Rbalint for fixing that.
Since a triggering change in qemu is in at least >=Bionic and was reported to 
even affect continuous unattended upgrades there would you considering SRUing 
your changes as needed?
I added tasks for all releases, but set >=Bionic to high to to that being an 
issue in the field IMHO.

** Also affects: qemu (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** No longer affects: qemu (Ubuntu Bionic)

** No longer affects: qemu (Ubuntu Cosmic)

** Changed in: unattended-upgrades (Ubuntu Bionic)
 Assignee: (unassigned) => Balint Reczey (rbalint)

** Changed in: unattended-upgrades (Ubuntu Cosmic)
 Assignee: (unassigned) => Balint Reczey (rbalint)

** Changed in: unattended-upgrades (Ubuntu Bionic)
   Importance: Undecided => High

** Changed in: unattended-upgrades (Ubuntu Cosmic)
   Importance: Undecided => High

** Also affects: qemu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** No longer affects: qemu (Ubuntu Xenial)

** No longer affects: qemu (Ubuntu Trusty)

** Changed in: unattended-upgrades (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: unattended-upgrades (Ubuntu Trusty)
   Importance: Undecided => Medium

** Changed in: unattended-upgrades (Ubuntu Trusty)
 Assignee: (unassigned) => Balint Reczey (rbalint)

** Changed in: unattended-upgrades (Ubuntu Xenial)
 Assignee: (unassigned) => Balint Reczey (rbalint)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1823872

Title:
  Fixing fsfreeze-hook can break unattended upgrades

Status in qemu package in Ubuntu:
  Invalid
Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Trusty:
  New
Status in unattended-upgrades source package in Xenial:
  New
Status in unattended-upgrades source package in Bionic:
  New
Status in unattended-upgrades source package in Cosmic:
  New

Bug description:
  [Impact]

   * If an update has a new conffile at a path that in a former version was 
 a directory like
  old: /a/b/c
  new: a/b
 Here b is the new file name and was a directory in the old version.
 Then unattended upgrades breaks on installing such a package.

   * a recent qemu update has such a case and due to that triggered the 
 issue in >=Bionic

   * The fix is to harden unattended upgrades to be able to handle the case 
 without aborting.

  [Test Case]

  Get a qemu guest e.g. of Bionic before the update to 1:2.11+dfsg-1ubuntu7.12
  That can be done with:
$ time uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic
$ uvt-kvm create --password ubuntu bionic-testuu arch=amd64 release=bionic 
label=daily

  Log in and apt update & upgrade all packages, then Install the release level 
qemu in there.
$ uvt-kvm ssh bionic-testuu
$ sudo apt update
$ sudo apt dist-upgrade
$ sudo apt install unattended-upgrades
$ sudo apt install qemu-guest-agent=1:2.11+dfsg-1ubuntu7

  All before was preparation, now force the unattended upgrade to trigger the 
bug.
$ sudo unattended-upgrade -d

  With the bug you'll find some error like:
  found pkg: qemu-guest-agent
  conffile line: /etc/init.d/qemu-guest-agent f61a64ac1e48993023018fd1cff85191
  current md5: f61a64ac1e48993023018fd1cff85191
  conffile line: /etc/qemu/fsfreeze-hook/fsfreeze-hook 
15f6ff42cbc5550a07ee21c2a471d905
  /etc/qemu/fsfreeze-hook/fsfreeze-hook not in package conffiles 
/etc/init.d/qemu-guest-agent
  /etc/qemu/fsfreeze-hook
  found conffile /etc/qemu/fsfreeze-hook in new pkg but on dpkg status
  Traceback (most recent call last):
File "/usr/bin/unattended-upgrade", line 2057, in 
  sys.exit(main(options))
File "/usr/bin/unattended-upgrade", line 1773, in main
  if conffile_prompt(item.destfile):
File "/usr/bin/unattended-upgrade", line 988, in conffile_prompt
  with open(prefix + conf_file, 'rb') as fp:
  IsADirectoryError: [Errno 21] Is a directory: '/etc/qemu/fsfreeze-hook'

  [Regression Potential]

  TODO: rbalint who writes the fix
   * discussion of how regressions are most likely to manifest as a result of 
this change. 

   * It is assumed that any SRU candidate patch is well-tested before
 

[Group.of.nepali.translators] [Bug 1822204] Re: open-vm-tools 10.3.10 released

[Christian Ehrhardt ]

I talked to the security Team (Marc), they said for the SRU our usual
timing is enough as there is a another layer of protection against those
kind of attacks. Therefore the bug will stay open for a while unless
discussed otherwise.

un-assigning the security Team for now, and thanks for the guidance

** Changed in: open-vm-tools (Ubuntu Xenial)
 Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)

** Changed in: open-vm-tools (Ubuntu Bionic)
 Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)

** Changed in: open-vm-tools (Ubuntu Cosmic)
 Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)

** Changed in: open-vm-tools (Ubuntu Xenial)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1822204

Title:
  open-vm-tools 10.3.10 released

Status in open-vm-tools package in Ubuntu:
  Fix Released
Status in open-vm-tools source package in Xenial:
  Won't Fix
Status in open-vm-tools source package in Bionic:
  New
Status in open-vm-tools source package in Cosmic:
  New
Status in open-vm-tools package in Debian:
  Fix Released

Bug description:
  We have released open-vm-tools 10.3.10.

  open-vm-tools 10.3.10 is available for download from GitHub:

  https://github.com/vmware/open-vm-tools/tree/stable-10.3.10

  For more details and changes, please refer to the release notes at

  https://github.com/vmware/open-vm-
  tools/blob/stable-10.3.10/ReleaseNotes.md

  or the ChangeLog at:

  https://github.com/vmware/open-vm-tools/blob/stable-10.3.10/open-vm-
  tools/ChangeLog

  
  Also filed at Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925940

  Oliver

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1822204/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1822204] Re: open-vm-tools 10.3.10 released

[Christian Ehrhardt ]

Reviewing the changelog after talking to Bernd (thanks) I realized that
there are security critical issues in there.

There is a security fix in it "Among others Fix possible security issue with 
the permissions of the intermediate staging directory and path"
[1]

But there are some further really bad things fixed like:
5f3f6ccd Fix NULL pointer dereference and remove three lines of dead code.

Since we are in Freeze but for critical cases can still reconsider it I'd want 
to do the following:
1. subscribe the release team and ping them if this could be synced into Disco 
still
   Actually i'll trigger the sync right away so it shows up as -unapproved as 
well.
2. subscribe -security to evaluate the severity of the issue to decide if we 
can wait for 
   older releases for the next regular backport (planned towards the end of 
19.10) or if we 
   need/want to immediately work on those
   - subscribe security team

[1]: https://github.com/vmware/open-vm-
tools/commit/e88f91b00a715b79255de6576506d80ecfdb064c

** Also affects: open-vm-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: open-vm-tools (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: open-vm-tools (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: open-vm-tools (Ubuntu Xenial)
 Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)

** Changed in: open-vm-tools (Ubuntu Bionic)
 Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)

** Changed in: open-vm-tools (Ubuntu Cosmic)
 Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)

** Changed in: open-vm-tools (Ubuntu)
   Importance: Undecided => Critical

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1822204

Title:
  open-vm-tools 10.3.10 released

Status in open-vm-tools package in Ubuntu:
  Triaged
Status in open-vm-tools source package in Xenial:
  New
Status in open-vm-tools source package in Bionic:
  New
Status in open-vm-tools source package in Cosmic:
  New
Status in open-vm-tools package in Debian:
  Unknown

Bug description:
  We have released open-vm-tools 10.3.10.

  open-vm-tools 10.3.10 is available for download from GitHub:

  https://github.com/vmware/open-vm-tools/tree/stable-10.3.10

  For more details and changes, please refer to the release notes at

  https://github.com/vmware/open-vm-
  tools/blob/stable-10.3.10/ReleaseNotes.md

  or the ChangeLog at:

  https://github.com/vmware/open-vm-tools/blob/stable-10.3.10/open-vm-
  tools/ChangeLog

  
  Also filed at Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925940

  Oliver

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1822204/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1822780] Re: dependency issues in the pymacaroons stack

[Christian Ehrhardt ]

** Changed in: pymacaroons (Ubuntu Xenial)
   Status: Triaged => Invalid

** Changed in: pymacaroons (Ubuntu Xenial)
 Assignee: Andreas Hasenack (ahasenack) => (unassigned)

** Changed in: pymacaroons (Ubuntu Trusty)
   Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1822780

Title:
  dependency issues in the pymacaroons stack

Status in pymacaroons package in Ubuntu:
  Fix Released
Status in pymacaroons source package in Trusty:
  In Progress
Status in pymacaroons source package in Xenial:
  Invalid

Bug description:
  [Impact]

   * The pymacaroons stack has dependency issues identified when further
     testing the backport to trusty (currently in proposed)

   * Ensure that the pymacaroons stack works well in Trusty (for Ubuntu
     Advantage client) but also fix the issues that matter for Xenial in
     Xenial as well.

  [Test Case]

  * install python3-pymacaroons. This will pull in python3-libnacl 1.4.5 as 
well (expected)
  * Without the latest fix from proposed, this command will backtrace as shown:

  $ python3 -c "__requires__ = 'pymacaroons';from pkg_resources import 
load_entry_point"
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/pkg_resources.py", line 444, in 
_build_master
  ws.require(__requires__)
    File "/usr/lib/python3/dist-packages/pkg_resources.py", line 725, in require
  needed = self.resolve(parse_requirements(requirements))
    File "/usr/lib/python3/dist-packages/pkg_resources.py", line 632, in resolve
  raise VersionConflict(dist,req) # XXX put more info here
  pkg_resources.VersionConflict: (libnacl 1.4.5 
(/usr/lib/python3/dist-packages), Requirement.parse('libnacl>=1.3.6,<1.4'))

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
    File "", line 1, in 
    File "/usr/lib/python3/dist-packages/pkg_resources.py", line 2749, in 

  working_set = WorkingSet._build_master()
    File "/usr/lib/python3/dist-packages/pkg_resources.py", line 446, in 
_build_master
  return cls._build_from_requirements(__requires__)
    File "/usr/lib/python3/dist-packages/pkg_resources.py", line 459, in 
_build_from_requirements
  dists = ws.resolve(reqs, Environment())
    File "/usr/lib/python3/dist-packages/pkg_resources.py", line 628, in resolve
  raise DistributionNotFound(req)
  pkg_resources.DistributionNotFound: libnacl>=1.3.6,<1.4

  * the python3-six dependency check isn't reached, because the check
  stops at the first unsatisfied dependency and that happened to be
  libnacl. But when testing the fixed packages, there must be no
  backtrace like above.

  [Fix]

   * Changes
     - Trusty: drop python2 binaries in trusty (was not released there yet)
   Xenial has those already published, we are not gonna take them away.
   see [1]
     - Trusty: adapt python-six dependency to match what is really needed
   and available in Trusty. Xenial has a version higher than that so
   don't bother modifying it there.
   see [2]
     - Trusty and Xenial: adapt python-libnacl dependency by backporting
   upstream fix on a too struct version requirement.
   see [3]

  [1]: 
https://git.launchpad.net/~paelzer/ubuntu/+source/pymacaroons/commit/?id=6746ad32b4d785919e849a4bef5685bf0bec6be2
  [2]: 
https://git.launchpad.net/~paelzer/ubuntu/+source/pymacaroons/commit/?id=f94ac40aeb354c008c4764853b877991003ae429
  [3]: 
https://git.launchpad.net/~paelzer/ubuntu/+source/pymacaroons/commit/?id=1987dffcffae29c63ea71635db1cfe19badc145f

  [Regression Potential]

   * Lets split this section for Trusty and Xenial.
     a) Xenial only gets slightly relaxed version dependencies, those should
    allow pymacaroons to run, but actually never cause any additional
    issues.
     b) Trusty this isn't released in trusty at all yet (still in proposed
    intentionally). Therefore this is one of the few cases I'd call
    regression risk next to zero. If anything then issues out of the py2
    removal not working as expected, but it seems to be ok in build and
    tests.

  [Other Info]

   * This is related to the SRU in bug 1817665
   * Furthermore it is related to the MIR extension to Trusty in
     bug 1746772 bug 1817327 and bug 1621386

  ---

  On the extended testing for the SRU in bug 1817665 we found that there
  are a few dependency issues that need to be fixed.

  Affects X:
  python-libnacl - depends on <1.4 but xenial (and trusty soon) have 1.4.5
  Fix by importing 
https://github.com/ecordell/pymacaroons/commit/3924d5b56c42234d0bff3820bc4cb6c4d3f74d8d

  Affects T:
  python-six - depends on >=1.8.0 - but trusty is on 1.5.2 still
  We evaluated if we need to backport six as well (a lot or reverse deps).
  We found that the usage of pymacaroons 

[Group.of.nepali.translators] [Bug 1822780] Re: dependency issues in the pymacaroons stack

[Christian Ehrhardt ]

** Also affects: pymacaroons (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: pymacaroons (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: pymacaroons (Ubuntu Trusty)
   Status: New => Triaged

** Changed in: pymacaroons (Ubuntu Xenial)
   Status: New => Triaged

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

** Description changed:

  On the extended testing for the SRU in bug 1817665 we found that there
  are a few dependency issues that need to be fixed.
  
+ Affects X:
  python-libnacl - depends on <1.4 but xenial (and trusty soon) have 1.4.5
  Fix by importing 
https://github.com/ecordell/pymacaroons/commit/3924d5b56c42234d0bff3820bc4cb6c4d3f74d8d
  
+ Affects T:
  python-six - depends on >=1.8.0 - but trusty is on 1.5.2 still
  We evaluated if we need to backport six as well (a lot or reverse deps).
  We found that the usage of pymacaroons is actually ok with 1.5.2
  Upstream regularly bumps the dependency level as well as some changes that 
got added but in the meantime removed (e.g. the serialization).
  Eventually only two use cases for python3-six are left
  - pymacaroons/caveat_delegates/encrypted_first_party.py:4:from six import 
iteritems
  - pymacaroons/utils.py:5:from six import text_type, binary_type
  
  None of these are changed in six between 1.5.2 and 1.8 checked by
  Odd_block, ahasenack and me.
  
- python2 - we don't need/want python2 support in this, so since we don't
- usually exercise and have no interest in supporting the python2 paths
- lets drop them from pymacaroons in trusty (where they are not published
- yet).
+ Affects T:
+ python2 - we don't need/want python2 support in this, so since we don't 
usually exercise and have no interest in supporting the python2 paths lets drop 
them from pymacaroons in trusty (where they are not published yet).

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1822780

Title:
  dependency issues in the pymacaroons stack

Status in pymacaroons package in Ubuntu:
  Fix Released
Status in pymacaroons source package in Trusty:
  Triaged
Status in pymacaroons source package in Xenial:
  Triaged

Bug description:
  On the extended testing for the SRU in bug 1817665 we found that there
  are a few dependency issues that need to be fixed.

  Affects X:
  python-libnacl - depends on <1.4 but xenial (and trusty soon) have 1.4.5
  Fix by importing 
https://github.com/ecordell/pymacaroons/commit/3924d5b56c42234d0bff3820bc4cb6c4d3f74d8d

  Affects T:
  python-six - depends on >=1.8.0 - but trusty is on 1.5.2 still
  We evaluated if we need to backport six as well (a lot or reverse deps).
  We found that the usage of pymacaroons is actually ok with 1.5.2
  Upstream regularly bumps the dependency level as well as some changes that 
got added but in the meantime removed (e.g. the serialization).
  Eventually only two use cases for python3-six are left
  - pymacaroons/caveat_delegates/encrypted_first_party.py:4:from six import 
iteritems
  - pymacaroons/utils.py:5:from six import text_type, binary_type

  None of these are changed in six between 1.5.2 and 1.8 checked by
  Odd_block, ahasenack and me.

  Affects T:
  python2 - we don't need/want python2 support in this, so since we don't 
usually exercise and have no interest in supporting the python2 paths lets drop 
them from pymacaroons in trusty (where they are not published yet).

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1699529] Re: i386 autopkgtests are unstable

[Christian Ehrhardt ]

** Also affects: libreoffice (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1699529

Title:
  i386 autopkgtests are unstable

Status in libreoffice package in Ubuntu:
  Confirmed
Status in libreoffice source package in Xenial:
  New

Bug description:
  We had this before (maybe for a different reason). libreoffice's i386
  autopkgtests are failing a lot of the time now. They are run when
  dependencies are uploaded, and so if they aren't reliable then they
  slow down the speed with which these updates can get into the release,
  because failures have to be manually retried.

  See:

http://autopkgtest.ubuntu.com/packages/libr/libreoffice/artful/i386

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1749283] Re: configured stats_temp_directory does not get created after reboot

[Christian Ehrhardt ]

Note: I have seen your fixes to the Foundation Cloud for the same
purpose, that was one more use case but that is fixed now as well right?

** Changed in: resource-agents (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: resource-agents (Ubuntu Bionic)
   Status: New => Confirmed

** No longer affects: postgresql-common (Ubuntu Artful)

** No longer affects: resource-agents (Ubuntu Artful)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1749283

Title:
  configured stats_temp_directory does not get created after reboot

Status in postgresql-common package in Ubuntu:
  Won't Fix
Status in resource-agents package in Ubuntu:
  Fix Released
Status in postgresql-common source package in Xenial:
  Won't Fix
Status in resource-agents source package in Xenial:
  Confirmed
Status in postgresql-common source package in Bionic:
  Won't Fix
Status in resource-agents source package in Bionic:
  Confirmed
Status in postgresql-common package in Debian:
  Fix Released

Bug description:
  Default postgres installation in Ubuntu (and Debian) configures
  stats_temp_directory inside /var/run/postgresql:

  $ grep stats_temp /etc/postgresql/10/main/postgresql.conf 
  stats_temp_directory = '/var/run/postgresql/10-main.pg_stat_tmp'

  However, this directory is not created after reboot.

  In most cases this is not a problem as systemd starts postgres via
  pg_ctlcluster, a "multiversion/cluster aware pg_ctl wrapper", and
  pg_ctlcluster will create missing directories before starting
  postgres.

  But in cases where systemd is not starting postgres this is a problem.
  Specifically, when postgres is controlled by pacemaker (using postgres 
resource agent for pacemaker) it is started using pg_ctl wrapper. pg_ctl won't 
create missing directories and therefore postgres fails to start.

  The simplest solution for this issue is to have systemd recreate
  missing directories via /usr/lib/tmpfiles.d/postgresql.conf file.

  Currently only /var/run/postgresql and /var/log/postgresql are created
  using systemd-tmpfiles.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1749283/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1677398] Re: Apparmor prevents using storage pools and hostdev networks

[Christian Ehrhardt ]

Hi Nicolas,
yeah that isn't easy to fix and at least I didn't find the time to develop 
something completely new to cover this yet.

I challenge the statement "Even the default storage pool 
/var/lib/libvirt/images is not working", it does and it does well.
And for things that are under the control of Ubuntu in the Archive even a few 
alternative paths work (openstack, uvtool, ...).

The issue you report is -not- using the default paths, the Deny lists
"/mnt/images/ubuntu-admin-qcow2" which clearly is not in one of the
common paths.

In general for using uncommon paths [1] the solution is that an admin
has to declare those paths as allowed in a local apparmor include. So if
terraform would usually /a/b/c it should also either recommend the admin
to do so or even consider adding it to the files itself.

[1]: https://wiki.ubuntu.com/LibvirtApparmor#Using_uncommon_paths

** Changed in: libvirt (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

** Changed in: libvirt (Ubuntu Zesty)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1677398

Title:
  Apparmor prevents using storage pools and hostdev networks

Status in libvirt package in Ubuntu:
  Triaged
Status in libvirt source package in Xenial:
  Won't Fix
Status in libvirt source package in Yakkety:
  Won't Fix
Status in libvirt source package in Zesty:
  Won't Fix

Bug description:
  Apparmor prevents qemu-kvm guests from using ZFS volumes.

  [Impact]
  * storage pools are not usable.
Examples with zfs and LVM pools

  [Test Case 1]
  # Prep ZFS
  1) Create a zpool
   $ for i in $(seq 1 3); do dd if=/dev/zero of=/tmp/fdisk${i} bs=1M 
count=1024; done
   $ sudo zpool create internal /tmp/fdisk*
  2) Create a ZFS storage pool and volume (named like your zpool, "internal" 
here)
    $ virsh pool-define-as internal zfs
    $ virsh pool-start internal
    $ virsh vol-create-as internal foo 2G

  # prep LVM
  4) prepare a (fake) LVM
$ for i in $(seq 1 3); do dd if=/dev/zero of=/tmp/lvdisk${i} bs=1M 
count=1024; done
$ sync
$ DISKS=$(for i in $(seq 1 3); do sudo losetup -f show /tmp/lvdisk${i}; 
done)
$ sudo pvcreate --verbose $DISKS
$ sudo vgcreate --verbose testvg $DISKS
  5) Create LVM Pool and volume
   $ virsh pool-define-as testvg logical
   $ virsh pool-start testvg
   $ virsh vol-create-as testvg guest1 2G

  # Prep Guest and use Pools
  6) Create a KVM guest e.g. via uvtool
   $ uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=xenial
   $ ssh-keygen
   $ uvt-kvm create --password=ubuntu testguest release=xenial arch=amd64 
label=daily
  7) Edit the guest's XML profile to use the ZFS and LVM volumes (zvol)
  
    
    
    
  
  



  
  8) Start the guest

  The guest refuses to start:

    # virsh start nms
    error: Failed to start domain foo
    error: internal error: process exited while connecting to monitor: 
2017-03-29T22:07:31.507017Z qemu-system-x86_64: -drive 
file=/dev/zvol/internal/foo,format=raw,if=none,id=drive-virtio-disk0,cache=none:
 Could not open '/dev/zvol/internal/foo': Permission denied

  dmesg reveals the culprit:

  apparmor="DENIED" operation="open" 
profile="libvirt-988a8c25-5190-4762-8170-55dc75fc66ca" name="/dev/zd224" 
pid=23052 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=109 
ouid=109
  apparmor="DENIED" operation="open" 
profile="libvirt-988a8c25-5190-4762-8170-55dc75fc66ca" name="/dev/zd224" 
pid=23052 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=109 
ouid=109

  Checking /etc/apparmor.d/libvirt/libvirt-$UUID.files shows that no
  "/dev/zdXX" has been added.

  [Additional info]

  # lsb_release -rd
  Description:  Ubuntu 16.04.2 LTS
  Release:  16.04

  # apt-cache policy libvirt-bin apparmor linux-image-generic
  libvirt-bin:
    Installed: 1.3.1-1ubuntu10.8
    Candidate: 1.3.1-1ubuntu10.8
    Version table:
   *** 1.3.1-1ubuntu10.8 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   1.3.1-1ubuntu10 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  apparmor:
    Installed: 2.10.95-0ubuntu2.5
    Candidate: 2.10.95-0ubuntu2.5
    Version table:
   *** 2.10.95-0ubuntu2.5 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.10.95-0ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  linux-image-generic:
    Installed: 4.4.0.70.76
    Candidate: 4.4.0.70.76
    Version table:
   *** 4.4.0.70.76 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  500 

[Group.of.nepali.translators] [Bug 1815665] Re: New upstream microreleases 9.5.16, 10.7 and 11.2

[Christian Ehrhardt ]

** Changed in: postgresql-11 (Ubuntu Disco)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1815665

Title:
  New upstream microreleases 9.5.16, 10.7 and 11.2

Status in pg-partman package in Ubuntu:
  Invalid
Status in pg-repack package in Ubuntu:
  Invalid
Status in pglogical-ticker package in Ubuntu:
  Fix Released
Status in postgresql-10 package in Ubuntu:
  Invalid
Status in postgresql-11 package in Ubuntu:
  Fix Released
Status in postgresql-9.5 package in Ubuntu:
  Invalid
Status in postgresql-plproxy package in Ubuntu:
  Invalid
Status in postgresql-rum package in Ubuntu:
  Fix Released
Status in skytools3 package in Ubuntu:
  Invalid
Status in postgresql-9.5 source package in Xenial:
  In Progress
Status in skytools3 source package in Xenial:
  Invalid
Status in pg-repack source package in Bionic:
  Invalid
Status in postgresql-10 source package in Bionic:
  In Progress
Status in postgresql-plproxy source package in Bionic:
  Invalid
Status in postgresql-rum source package in Bionic:
  Invalid
Status in pg-partman source package in Cosmic:
  Invalid
Status in pg-repack source package in Cosmic:
  Invalid
Status in postgresql-10 source package in Cosmic:
  In Progress
Status in postgresql-plproxy source package in Cosmic:
  Invalid
Status in postgresql-rum source package in Cosmic:
  Invalid
Status in postgresql-11 source package in Disco:
  Fix Released

Bug description:
  Current versions in supported releases:
   postgresql-9.3 | 9.3.23-0ubuntu0.14.04 trusty <- no upstream updates anymore
   postgresql-9.5 | 9.5.14-0ubuntu0.16.04 xenial
   postgresql-10 | 10.6-0ubuntu0.18.04.1 bionic
   postgresql-10 | 10.6-0ubuntu0.18.10.1 cosmic

  Special cases:
  - Disco will be synced from Debian soon (we are on 11.1-2)
  - This is again a security update, so we prep and security will eval and 
publish through -security

  Last relevant related stable updates: 9.5.16, 10.7

  So the todo is to pick:
  MRE: Xenial 9.5.14 from 
https://ftp.postgresql.org/pub/source/v9.5.16/postgresql-9.5.16.tar.gz
  MRE: Bionic/Cosmic 10.7   from 
https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gz

  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  New - this bug
  - pad.lv/1815665

  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.

  Regression potential:
  - usually this works smoothly except a few test hickups that need to be
    clarified to be sure. But this time there are changes worth to
    mention for the SRU team.
    - change [1] is in all branches Xenil/Bionic/Cosmic and after
  coordinating with Debian and Upstream and some members of the SRU Team
  (Malta) and Debian we decided to revert this change in all releases
  that get SRUs (So 11.x in Disco is the only who will get it).
  What makes this slightly more important is that: if 
  client_min_messages is misused, then not having that fix
  could cause bad data.
  But users of Ubuntu are either:
  a) not affected at all and therefore are fine as-is (majority)
  b) not affected by the problem but have tests/scripts/CI/... that
     rely on the behavior (we don't want to SRU break them)
  c) have a case that is affected, in that case the "code using
     client_min_messages" is the one to be considered broken (in favor
     of the majority of users) and that code should be changed instead
     of PostgreSQL.
  Furthermore with that decision we are also in sync with Debian
  handling the same
   - Change [2] renaming of symbols rb/rbt is fine doing forward (Disco),
     but not in Bionic/Cosmic as we'd break en external ABI of the past in
     an SRU. Please Note that the offending plruby this change was made for
     is not even in the Archive.
   => Especially in regard to "regression potential" that means that we will
  NOT apply the two changes that are somewhat discussion-worthy. We
  might in later updates reconsider them, but for now when applying the
  latest stable release we revert those two primarily for the reason to
  have the lowest possible regression potential for the SRU.

  Note: opening private as it is not yet announced
  Public announce will on thursday.

  [1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c09daa910
  [2]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b2e754c14

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pg-partman/+bug/1815665/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to 

[Group.of.nepali.translators] [Bug 1815665] Re: New upstream microreleases 9.5.16, 10.7 and 11.2

[Christian Ehrhardt ]

After adapting the description for the new insights I uploaded the two
10.7 branches (Bionic/Cosmic) to the unapproved queue as well (9.5 for
Xenial was there already).

** Changed in: postgresql-10 (Ubuntu Cosmic)
   Status: Triaged => In Progress

** Changed in: postgresql-10 (Ubuntu Bionic)
   Status: Triaged => In Progress

** Changed in: pg-repack (Ubuntu Bionic)
   Status: Triaged => Invalid

** Changed in: pg-repack (Ubuntu Cosmic)
   Status: Triaged => Invalid

** Changed in: postgresql-plproxy (Ubuntu Bionic)
   Status: Triaged => Invalid

** Changed in: postgresql-plproxy (Ubuntu Cosmic)
   Status: Triaged => Invalid

** Changed in: postgresql-rum (Ubuntu)
   Status: Invalid => New

** Changed in: postgresql-rum (Ubuntu Bionic)
   Status: New => Invalid

** Changed in: postgresql-rum (Ubuntu Cosmic)
   Status: New => Invalid

** Changed in: skytools3 (Ubuntu Xenial)
   Status: Triaged => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1815665

Title:
  New upstream microreleases 9.5.16, 10.7 and 11.2

Status in pg-partman package in Ubuntu:
  Invalid
Status in pg-repack package in Ubuntu:
  Invalid
Status in pglogical-ticker package in Ubuntu:
  Confirmed
Status in postgresql-10 package in Ubuntu:
  Invalid
Status in postgresql-11 package in Ubuntu:
  Confirmed
Status in postgresql-9.5 package in Ubuntu:
  Invalid
Status in postgresql-plproxy package in Ubuntu:
  Invalid
Status in postgresql-rum package in Ubuntu:
  Fix Released
Status in skytools3 package in Ubuntu:
  Invalid
Status in postgresql-9.5 source package in Xenial:
  In Progress
Status in skytools3 source package in Xenial:
  Invalid
Status in pg-repack source package in Bionic:
  Invalid
Status in postgresql-10 source package in Bionic:
  In Progress
Status in postgresql-plproxy source package in Bionic:
  Invalid
Status in postgresql-rum source package in Bionic:
  Invalid
Status in pg-partman source package in Cosmic:
  Invalid
Status in pg-repack source package in Cosmic:
  Invalid
Status in postgresql-10 source package in Cosmic:
  In Progress
Status in postgresql-plproxy source package in Cosmic:
  Invalid
Status in postgresql-rum source package in Cosmic:
  Invalid
Status in postgresql-11 source package in Disco:
  Confirmed

Bug description:
  Current versions in supported releases:
   postgresql-9.3 | 9.3.23-0ubuntu0.14.04 trusty <- no upstream updates anymore
   postgresql-9.5 | 9.5.14-0ubuntu0.16.04 xenial
   postgresql-10 | 10.6-0ubuntu0.18.04.1 bionic
   postgresql-10 | 10.6-0ubuntu0.18.10.1 cosmic

  Special cases:
  - Disco will be synced from Debian soon (we are on 11.1-2)
  - This is again a security update, so we prep and security will eval and 
publish through -security

  Last relevant related stable updates: 9.5.16, 10.7

  So the todo is to pick:
  MRE: Xenial 9.5.14 from 
https://ftp.postgresql.org/pub/source/v9.5.16/postgresql-9.5.16.tar.gz
  MRE: Bionic/Cosmic 10.7   from 
https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gz

  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  New - this bug
  - pad.lv/1815665

  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.

  Regression potential:
  - usually this works smoothly except a few test hickups that need to be
    clarified to be sure. But this time there are changes worth to
    mention for the SRU team.
    - change [1] is in all branches Xenil/Bionic/Cosmic and after
  coordinating with Debian and Upstream and some members of the SRU Team
  (Malta) and Debian we decided to revert this change in all releases
  that get SRUs (So 11.x in Disco is the only who will get it).
  What makes this slightly more important is that: if 
  client_min_messages is misused, then not having that fix
  could cause bad data.
  But users of Ubuntu are either:
  a) not affected at all and therefore are fine as-is (majority)
  b) not affected by the problem but have tests/scripts/CI/... that
     rely on the behavior (we don't want to SRU break them)
  c) have a case that is affected, in that case the "code using
     client_min_messages" is the one to be considered broken (in favor
     of the majority of users) and that code should be changed instead
     of PostgreSQL.
  Furthermore with that decision we are also in sync with Debian
  handling the same
   - Change [2] renaming of symbols rb/rbt is fine doing forward (Disco),
     but not in Bionic/Cosmic as we'd break en external ABI of the past in
     an SRU. Please Note that the offending plruby this change was made for
     is not even in the Archive.
   

[Group.of.nepali.translators] [Bug 1815665] Re: New upstream microreleases 9.5.16, 10.7 and 11.2

[Christian Ehrhardt ]

Due to the reverts this is much less disruptive, plenty of bug tasks got 
invalid.
As 11.2 gets the change postgresql-rum in Disco is affected, but that is 
already in 1.3.2-4 which is in Disco.

** Changed in: postgresql-rum (Ubuntu)
   Status: New => Fix Released

** Changed in: postgresql-11 (Ubuntu Disco)
   Importance: Undecided => Critical

** Also affects: pglogical-ticker (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: pglogical-ticker (Ubuntu)
   Importance: Undecided => Critical

** Changed in: pglogical-ticker (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1815665

Title:
  New upstream microreleases 9.5.16, 10.7 and 11.2

Status in pg-partman package in Ubuntu:
  Invalid
Status in pg-repack package in Ubuntu:
  Invalid
Status in pglogical-ticker package in Ubuntu:
  Confirmed
Status in postgresql-10 package in Ubuntu:
  Invalid
Status in postgresql-11 package in Ubuntu:
  Confirmed
Status in postgresql-9.5 package in Ubuntu:
  Invalid
Status in postgresql-plproxy package in Ubuntu:
  Invalid
Status in postgresql-rum package in Ubuntu:
  Fix Released
Status in skytools3 package in Ubuntu:
  Invalid
Status in postgresql-9.5 source package in Xenial:
  In Progress
Status in skytools3 source package in Xenial:
  Invalid
Status in pg-repack source package in Bionic:
  Invalid
Status in postgresql-10 source package in Bionic:
  In Progress
Status in postgresql-plproxy source package in Bionic:
  Invalid
Status in postgresql-rum source package in Bionic:
  Invalid
Status in pg-partman source package in Cosmic:
  Invalid
Status in pg-repack source package in Cosmic:
  Invalid
Status in postgresql-10 source package in Cosmic:
  In Progress
Status in postgresql-plproxy source package in Cosmic:
  Invalid
Status in postgresql-rum source package in Cosmic:
  Invalid
Status in postgresql-11 source package in Disco:
  Confirmed

Bug description:
  Current versions in supported releases:
   postgresql-9.3 | 9.3.23-0ubuntu0.14.04 trusty <- no upstream updates anymore
   postgresql-9.5 | 9.5.14-0ubuntu0.16.04 xenial
   postgresql-10 | 10.6-0ubuntu0.18.04.1 bionic
   postgresql-10 | 10.6-0ubuntu0.18.10.1 cosmic

  Special cases:
  - Disco will be synced from Debian soon (we are on 11.1-2)
  - This is again a security update, so we prep and security will eval and 
publish through -security

  Last relevant related stable updates: 9.5.16, 10.7

  So the todo is to pick:
  MRE: Xenial 9.5.14 from 
https://ftp.postgresql.org/pub/source/v9.5.16/postgresql-9.5.16.tar.gz
  MRE: Bionic/Cosmic 10.7   from 
https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gz

  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  New - this bug
  - pad.lv/1815665

  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.

  Regression potential:
  - usually this works smoothly except a few test hickups that need to be
    clarified to be sure. But this time there are changes worth to
    mention for the SRU team.
    - change [1] is in all branches Xenil/Bionic/Cosmic and after
  coordinating with Debian and Upstream and some members of the SRU Team
  (Malta) and Debian we decided to revert this change in all releases
  that get SRUs (So 11.x in Disco is the only who will get it).
  What makes this slightly more important is that: if 
  client_min_messages is misused, then not having that fix
  could cause bad data.
  But users of Ubuntu are either:
  a) not affected at all and therefore are fine as-is (majority)
  b) not affected by the problem but have tests/scripts/CI/... that
     rely on the behavior (we don't want to SRU break them)
  c) have a case that is affected, in that case the "code using
     client_min_messages" is the one to be considered broken (in favor
     of the majority of users) and that code should be changed instead
     of PostgreSQL.
  Furthermore with that decision we are also in sync with Debian
  handling the same
   - Change [2] renaming of symbols rb/rbt is fine doing forward (Disco),
     but not in Bionic/Cosmic as we'd break en external ABI of the past in
     an SRU. Please Note that the offending plruby this change was made for
     is not even in the Archive.
   => Especially in regard to "regression potential" that means that we will
  NOT apply the two changes that are somewhat discussion-worthy. We
  might in later updates reconsider them, but for now when applying the
  latest stable release we revert those two primarily for the reason to
  have the lowest possible regression potential for the SRU.

  

[Group.of.nepali.translators] [Bug 1749283] Re: configured stats_temp_directory does not get created after reboot

[Christian Ehrhardt ]

@Mario / @Eric - just to check in whoms curt the ball is right now - Is
Mario or someone else in your Org still/again working on this? If not
who do we need to bother to re-assign properly?

** Changed in: resource-agents (Ubuntu Artful)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1749283

Title:
  configured stats_temp_directory does not get created after reboot

Status in postgresql-common package in Ubuntu:
  Won't Fix
Status in resource-agents package in Ubuntu:
  In Progress
Status in postgresql-common source package in Xenial:
  Won't Fix
Status in resource-agents source package in Xenial:
  New
Status in postgresql-common source package in Artful:
  Won't Fix
Status in resource-agents source package in Artful:
  Invalid
Status in postgresql-common source package in Bionic:
  Won't Fix
Status in resource-agents source package in Bionic:
  New
Status in postgresql-common package in Debian:
  Fix Released

Bug description:
  Default postgres installation in Ubuntu (and Debian) configures
  stats_temp_directory inside /var/run/postgresql:

  $ grep stats_temp /etc/postgresql/10/main/postgresql.conf 
  stats_temp_directory = '/var/run/postgresql/10-main.pg_stat_tmp'

  However, this directory is not created after reboot.

  In most cases this is not a problem as systemd starts postgres via
  pg_ctlcluster, a "multiversion/cluster aware pg_ctl wrapper", and
  pg_ctlcluster will create missing directories before starting
  postgres.

  But in cases where systemd is not starting postgres this is a problem.
  Specifically, when postgres is controlled by pacemaker (using postgres 
resource agent for pacemaker) it is started using pg_ctl wrapper. pg_ctl won't 
create missing directories and therefore postgres fails to start.

  The simplest solution for this issue is to have systemd recreate
  missing directories via /usr/lib/tmpfiles.d/postgresql.conf file.

  Currently only /var/run/postgresql and /var/log/postgresql are created
  using systemd-tmpfiles.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1749283/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1650493] Re: numastat fails with double free or corruption

[Christian Ehrhardt ]

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

Resurrected in bug 1817258 :-)
And released in Disco it seems.

** Changed in: numactl (Ubuntu Disco)
   Status: Incomplete => Fix Released

** Changed in: numactl (Ubuntu Cosmic)
   Status: Fix Released => Invalid

** Changed in: numactl (Ubuntu Bionic)
   Status: Fix Released => Invalid

** Changed in: numactl (Ubuntu Xenial)
   Status: Fix Released => Invalid

** Changed in: numactl (Ubuntu Cosmic)
 Assignee: Canonical Server Team (canonical-server) => (unassigned)

** This bug has been marked a duplicate of bug 1817258
   "numastat" doesn't display correct information for the guest.

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1650493

Title:
  numastat  fails with double free or corruption

Status in The Ubuntu-power-systems project:
  Fix Released
Status in numactl package in Ubuntu:
  Fix Released
Status in numactl source package in Xenial:
  Invalid
Status in numactl source package in Bionic:
  Invalid
Status in numactl source package in Cosmic:
  Invalid
Status in numactl source package in Disco:
  Fix Released

Bug description:
  while trying to get stat of the guest process (configured with
  hugepages), numastat fails

  
  Environment details
  
  # uname -a
  Linux lep8b 4.8.0-30-generic #32-Ubuntu SMP Fri Dec 2 03:43:46 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linu

  =
  Issue
  =
  2016-12-14 07:02:56,396 process  L0368 INFO | Running 'numastat 61257'
  2016-12-14 07:02:56,402 process  L0462 DEBUG| [stderr] *** Error in 
`numastat': double free or corruption (out): 0x0100265005a0 ***
  2016-12-14 07:02:56,403 process  L0462 DEBUG| [stdout]
  2016-12-14 07:02:56,403 process  L0482 INFO | Command 'numastat 
61257' finished with -6 after 0.00309896469116s
  2016-12-14 07:02:56,403 process  L0462 DEBUG| [stdout] Per-node 
process memory usage (in MBs) for PID 61257 (qemu-system-ppc)
  2016-12-14 07:02:56,404 process  L0462 DEBUG| [stderr] === 
Backtrace: =
  2016-12-14 07:02:56,404 process  L0462 DEBUG| [stderr] 
/lib/powerpc64le-linux-gnu/libc.so.6(+0x86d54)[0x3fff9a736d54]
  2016-12-14 07:02:56,404 process  L0462 DEBUG| [stderr] 
/lib/powerpc64le-linux-gnu/libc.so.6(+0x93c30)[0x3fff9a743c30]
  2016-12-14 07:02:56,404 process  L0462 DEBUG| [stderr] 
/lib/powerpc64le-linux-gnu/libc.so.6(cfree+0x68)[0x3fff9a748218]
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
/lib/powerpc64le-linux-gnu/libc.so.6(fclose+0x1c8)[0x3fff9a727d68]
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
numastat(+0x7aa4)[0x401d7aa4]
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
numastat(+0x2388)[0x401d2388]
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
/lib/powerpc64le-linux-gnu/libc.so.6(+0x2291c)[0x3fff9a6d291c]
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
/lib/powerpc64le-linux-gnu/libc.so.6(__libc_start_main+0xb8)[0x3fff9a6d2b18]
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] === Memory 
map: 
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
401d-401e r-xp  08:92 40325510   
/usr/bin/numastat
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
401e-401f r--p  08:92 40325510   
/usr/bin/numastat
  2016-12-14 07:02:56,406 process  L0462 DEBUG| [stderr] 
401f-4020 rw-p 0001 08:92 40325510   
/usr/bin/numastat
  2016-12-14 07:02:56,406 process  L0462 DEBUG| [stderr] 
1002650-1002653 rw-p  00:00 0[heap]
  2016-12-14 07:02:56,406 process  L0462 DEBUG| [stderr] 
3fff9a6b-3fff9a86 r-xp  08:92 25745199   
/lib/powerpc64le-linux-gnu/libc-2.24.so
  2016-12-14 07:02:56,406 process  L0462 DEBUG| [stderr] 
3fff9a86-3fff9a87 ---p 001b 08:92 25745199   
/lib/powerpc64le-linux-gnu/libc-2.24.so
  2016-12-14 07:02:56,406 process  L0462 DEBUG| [stderr] 
3fff9a87-3fff9a88 r--p 001b 08:92 25745199   
/lib/powerpc64le-linux-gnu/libc-2.24.so
  2016-12-14 07:02:56,406 process  L0462 DEBUG| [stderr] 
3fff9a88-3fff9a89 rw-p 001c 08:92 25745199   
/lib/powerpc64le-linux-gnu/libc-2.24.so
  2016-12-14 07:02:56,406 process  L0462 DEBUG| [stderr] 
3fff9a8b-3fff9a8c rw-p  00:00 0
  2016-12-14 07:02:56,407 process  L0462 DEBUG| [stderr] 
3fff9a8c-3fff9a8e r-xp  00:00 0  [vdso]
  2016-12-14 07:02:56,407 process   

[Group.of.nepali.translators] [Bug 1817327] Re: [Mir] python-libnacl

[Christian Ehrhardt ]

This is only needed for Xenial/Trusty as python-libnacl was the backend
of pymacaroons there and changing that would be too much regression
risk. Therefore the timeline of this support is clearly defined with the
EOL of Tusty/Xenial.

It is a duplication in functionality, but never both are in main.
python-libnacl - requested to be in Trusty/Xenial here
python-nacl - is in main >=Bionic

I added T/X tasks therefore and marked the forward looking main bug "invalid".
I'll start on a MIR eval on this later today, so I assign myself.

** Also affects: python-libnacl (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: python-libnacl (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: python-libnacl (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: python-libnacl (Ubuntu Trusty)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

** Changed in: python-libnacl (Ubuntu Xenial)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

** Description changed:

  # MIR for python-libnacl
  
  Availability:
  -
    - python-libnacl package is available in xenial-universe.
    - package needs to be uploaded to trusty and no previous version is present
  
  Rationale:
  --
  
-  - There is a newer dependency chain on python-nacl instead of python-libnacl 
in
- bionic and later already, but we do not want to introduce a risk of regression
- by adapting python-pymacaroons.
+  - There is a newer dependency chain on python-nacl instead of python-
+libnacl in bionic and later already, but we do not want to introduce a 
+risk of regression by adapting python-pymacaroons.
  
- - This is a new build dependency from ubuntu-advantage-tools package which 
will
- deliver the abilty to enable Ubuntu Advantage support entitlement.
+ - This is a new build dependency from ubuntu-advantage-tools package which 
+   will deliver the abilty to enable Ubuntu Advantage support entitlement.
  
  Security:
  -
   - No known CVEs
  
  Quality assurance:
  --
  
   - Working defaults [its a library for external consumption]
   - It does not ask debconf questions
   - No long standing high or critical bugs in debian and upstream project
   - Maintainership looks active from both debian and upstream project
   - tests exist and are run during build
   - the package uses a debian/watch file
   - lintian notifications do not raise siginificant warnings
-  - the package builds python2 elements but we are only pulling python3 binary
+  - the package builds python2 elements but we are only pulling python3 
+ binary
  
  UI standards: (generally only for user-facing applications)
  -
   - None
  
  Dependencies:
  -
   - libsodium which will be pulled in per LP: #1621386
  
  Standards compliance:
  -
  
  Maintenance:
   - upstream and debian package maintenance is active and well maintained
  
  Background information:
  
  This is needed for the UA client and support pymacaroons
   - To avoid added risk in shifting python-pymacaroons to python-nacl package, 
we would like to introduce a separate package.

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1817327

Title:
  [Mir] python-libnacl

Status in python-libnacl package in Ubuntu:
  Invalid
Status in python-libnacl source package in Trusty:
  New
Status in python-libnacl source package in Xenial:
  New

Bug description:
  # MIR for python-libnacl

  Availability:
  -
    - python-libnacl package is available in xenial-universe.
    - package needs to be uploaded to trusty and no previous version is present

  Rationale:
  --

   - There is a newer dependency chain on python-nacl instead of python-
 libnacl in bionic and later already, but we do not want to introduce a 
 risk of regression by adapting python-pymacaroons.

  - This is a new build dependency from ubuntu-advantage-tools package which 
will deliver the abilty to enable Ubuntu Advantage support entitlement.

  Security:
  -
   - No known CVEs

  Quality assurance:
  --

   - Working defaults [its a library for external consumption]
   - It does not ask debconf questions
   - No long standing high or critical bugs in debian and upstream project
   - Maintainership looks active from both debian and upstream project
   - tests exist and are run during build
   - the package uses a debian/watch file
   - lintian notifications do not raise siginificant warnings
   - the package builds python2 elements but we are only pulling python3 
  binary

  UI standards: (generally only for user-facing applications)
  -
   - None

  Dependencies:
  -
   - libsodium which will be pulled in per LP: #1621386

[Group.of.nepali.translators] [Bug 1621386] Re: [MIR] libsodium

[Christian Ehrhardt ]

I added tasks for Xenial and Trusty, the main task I set back to fix
released as that is truly complete and didn't change. This is "just" for
the time-warping back for X/T which we will have to evaluate.

I'll start on the MIR evaluation of those later on today

** Also affects: libsodium (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libsodium (Ubuntu Trusty)
   Importance: Undecided
   Status: New

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

** Changed in: libsodium (Ubuntu Trusty)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

** Changed in: libsodium (Ubuntu Xenial)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1621386

Title:
  [MIR] libsodium

Status in libsodium package in Ubuntu:
  Fix Released
Status in libsodium source package in Trusty:
  New
Status in libsodium source package in Xenial:
  New

Bug description:
  [Availability]
  The package is currently available in universe, currently imported directly 
from Debian with no Ubuntu specific patches.

  [Rationale]
  libsodium is a dependency of ZeroMQ, which in turn is a dependency of 
unity-scopes-api.  Therefore, we will need to include it in main to support 
Unity 8.

  [Security]
  I couldn't find any CVEs or other advisories for the libsodium library, or 
djb's "nacl" library (http://nacl.cr.yp.to/) that it is derived from.

  [Quality Assurance]
  Package is a library, so not something end users will interact with directly. 
 There are other apps and libraries in universe that currently link with 
libsodium, and install without issue.

  The library asks no debconf questions on install.

  Bugs are tracked in Debian and Ubuntu here:
  https://bugs.launchpad.net/ubuntu/+source/libsodium
  https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libsodium

  The one Ubuntu bug looks like it might be user confusion about -dev
  packages.  The one Debian report is complaining about Debian packaging
  an old version of libsodium: something that seems to have since been
  fixed but not noted in the bug report.

  New releases appear to be packaged in Debian promptly
  (https://packages.qa.debian.org/libs/libsodium.html), and the latest
  Debian release was recently migrated into Yakkety.

  The package is a software crypto library, so doesn't rely on exotic
  hardware.

  Library has a test suite that is run as part of the package build.

  The package has a debian/watch file checking for new releases on
  github.

  [UI Standards]
  The package contains a non-graphical crypto library.

  [Dependencies]
  The libsodium18 binary package only depends on libc6.  For source 
build-depends, there is debhelper, pkg-config, and dh-autoreconf.  All are 
already in main.

  [Maintenance]
  The package currently lists ubuntu-devel-discuss as its maintainer.  It 
doesn't look like we've ever made any changes to the versions of the package 
migrated from Debian though.

  [Background information]
  The package has reasonable description strings and hasn't been renamed 
recently.  The source package name matches the upstream project name.

  [ABI Stability]
  The library is plain C, so should be fairly robust.  The upstream developers 
committed to API and ABI stability with the 1.0.0 release (October 2014):

  https://github.com/jedisct1/libsodium/releases/tag/1.0.0

  A bit worryingly though, they changed soname in the 1.0.6 release
  (November 2015):

  https://github.com/jedisct1/libsodium/releases/tag/1.0.6

  The changelog seems to indicate that the release should have been
  compatible but they changed soname just to be sure.  It is unclear
  whether this is likely to happen again.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1746772] Re: [MIR] pymacaroons, python-libnacl

[Christian Ehrhardt ]

I added tasks for Xenial and Trusty, the main task I set back to fix
released as that is truly complete and didn't change. This is "just" for
the time-warping back for X/T which we will have to evaluate.

I'll start on the MIR evaluation of those later on today

** Also affects: pymacaroons (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: pymacaroons (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Changed in: pymacaroons (Ubuntu Trusty)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

** Changed in: pymacaroons (Ubuntu Xenial)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1746772

Title:
  [MIR] pymacaroons, python-libnacl

Status in pymacaroons package in Ubuntu:
  Fix Released
Status in pymacaroons source package in Trusty:
  New
Status in pymacaroons source package in Xenial:
  New

Bug description:
  pymacaroons
  =

  1. Availability: all

  2. Rationale:
  macaroon is a new dependency that MAAS will use. This provides the library 
for macaroon based authentication, which MAAS will use for the support 
remote/centralized authentication.

  3. Security:
  No CVE's

  4. QA:
  0 bugs in debian/ubuntu

  5. UI standards:
  None

  6. Dependencies:

  Dependencies in universe:
   -  python{3}-libnacl - Python 3 bindings for libsodium based on ctypes

  7. Standards:
  No lintian errors.

  Packaged with debhelper. Source format is 3.0 (quilt)

  Standards version: 3.9.8

  8. Maintenance:
  Easy.

  9. Background information:
  This package provides the macaroon library for MAAS to allow it to work for 
macaroon based authentication systems.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1815665] Re: New upstream microreleases 9.5.16, 10.7 and 11.2

[Christian Ehrhardt ]

The error is due to this change [1]

While we could modify and rebuild postgresql-rum we don't know what else
people might have built against that which is not in the Archive.

This applies only to branches 11 (not yet released, so ok) and 10
(Bionic/Cosmic)

My suggestion would be to carry a revert of this change as it is not
SRU-able in my opinion.

I thought more about the other change [2] and I must say after
considering it more I also think it is a break of the SRU promises. So
I'll suggest adding a revert of that to our streams of 9.5 and 10 that
are in active releases.

[1]: 
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b2e754c14e2741a076691e8c6f0099afffaa842e
[2]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c09daa910


** Changed in: pg-partman (Ubuntu Cosmic)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1815665

Title:
  New upstream microreleases 9.5.16, 10.7 and 11.2

Status in pg-partman package in Ubuntu:
  Invalid
Status in pg-repack package in Ubuntu:
  Invalid
Status in postgresql-10 package in Ubuntu:
  Invalid
Status in postgresql-11 package in Ubuntu:
  Confirmed
Status in postgresql-9.5 package in Ubuntu:
  Invalid
Status in postgresql-plproxy package in Ubuntu:
  Invalid
Status in postgresql-rum package in Ubuntu:
  Invalid
Status in skytools3 package in Ubuntu:
  Invalid
Status in postgresql-9.5 source package in Xenial:
  Triaged
Status in skytools3 source package in Xenial:
  Triaged
Status in pg-repack source package in Bionic:
  Triaged
Status in postgresql-10 source package in Bionic:
  Triaged
Status in postgresql-plproxy source package in Bionic:
  Triaged
Status in postgresql-rum source package in Bionic:
  New
Status in pg-partman source package in Cosmic:
  Invalid
Status in pg-repack source package in Cosmic:
  Triaged
Status in postgresql-10 source package in Cosmic:
  Triaged
Status in postgresql-plproxy source package in Cosmic:
  Triaged
Status in postgresql-rum source package in Cosmic:
  New
Status in postgresql-11 source package in Disco:
  Confirmed

Bug description:
  Current versions in supported releases:
   postgresql-9.3 | 9.3.23-0ubuntu0.14.04 trusty <- no upstream updates anymore
   postgresql-9.5 | 9.5.14-0ubuntu0.16.04 xenial
   postgresql-10 | 10.6-0ubuntu0.18.04.1 bionic
   postgresql-10 | 10.6-0ubuntu0.18.10.1 cosmic

  Special cases:
  - Disco will be synced from Debian soon (we are on 11.1-2)
  - This is again a security update, so we prep and security will eval and 
publish through -security

  Last relevant related stable updates: 9.5.16, 10.7

  So the todo is to pick:
  MRE: Xenial 9.5.14 from 
https://ftp.postgresql.org/pub/source/v9.5.16/postgresql-9.5.16.tar.gz
  MRE: Bionic/Cosmic 10.7   from 
https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gz

  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  New - this bug
  - pad.lv/1815665

  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.

  
  Regression potential:
  - usually this works smoothly, but this time there is a change worth to 
mention for the SRU team. There is a change in all branches like [1]
I agree with the change - it is right to fix the FE/BE protocol, the 
only thing that should be affected are testcases like the ones I found.
So maybe some CIs (checking expected vs actual output) might break and 
logs might increase (now tracking formerly ignored errors), but 
not more.

  Note: opening private as it is not yet announced
  Public announce will on thursday.

  [1]:
  https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c09daa910

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pg-partman/+bug/1815665/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1815665] Re: New upstream microreleases 9.5.16, 10.7 and 11.2

[Christian Ehrhardt ]

https://codesearch.debian.net/search?q=%5BSs%5D%5BEe%5D%5BTt%5D%5Cs*client_min_messages.*fatal
Not sure how I could search that way in a past release, but it gives some 
confirming hits.

For our current case I can confirm the following issues being due to this:
- skytools3 (xenial, not in archive later) #1
- pg-repack (bionic/cosmic) #2a
- postgres-plproxy (bionic/cosmic) #2b

The following two seems to be a different error thou:
- postgres-rum 
This is more like the Tables were never created with errors like:
"operator does not exist: smallint[] % unknown at character 34"
- pg-partman [i386]

I'm adding bug tasks for those we identified and set them to triaged as we know 
how to fix them.
#3 - pg-partman [i386] - will stay unhandled until analyzed
#4 - postgres-rum - split this from the others and define is as #4

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

** Also affects: pg-repack (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: postgresql-plproxy (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: postgresql-rum (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: pg-partman (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: pg-repack (Ubuntu)
   Status: New => Invalid

** Changed in: pg-partman (Ubuntu)
   Status: New => Invalid

** Changed in: pg-repack (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: pg-repack (Ubuntu Cosmic)
   Status: New => Triaged

** Changed in: postgresql-plproxy (Ubuntu)
   Status: New => Invalid

** Changed in: postgresql-rum (Ubuntu)
   Status: New => Invalid

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

** Changed in: skytools3 (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: postgresql-plproxy (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: postgresql-plproxy (Ubuntu Cosmic)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1815665

Title:
  New upstream microreleases 9.5.16, 10.7 and 11.2

Status in pg-partman package in Ubuntu:
  Invalid
Status in pg-repack package in Ubuntu:
  Invalid
Status in postgresql-10 package in Ubuntu:
  Invalid
Status in postgresql-11 package in Ubuntu:
  Confirmed
Status in postgresql-9.5 package in Ubuntu:
  Invalid
Status in postgresql-plproxy package in Ubuntu:
  Invalid
Status in postgresql-rum package in Ubuntu:
  Invalid
Status in skytools3 package in Ubuntu:
  Invalid
Status in postgresql-9.5 source package in Xenial:
  Triaged
Status in skytools3 source package in Xenial:
  Triaged
Status in pg-repack source package in Bionic:
  Triaged
Status in postgresql-10 source package in Bionic:
  Triaged
Status in postgresql-plproxy source package in Bionic:
  Triaged
Status in postgresql-rum source package in Bionic:
  New
Status in pg-partman source package in Cosmic:
  New
Status in pg-repack source package in Cosmic:
  Triaged
Status in postgresql-10 source package in Cosmic:
  Triaged
Status in postgresql-plproxy source package in Cosmic:
  Triaged
Status in postgresql-rum source package in Cosmic:
  New
Status in postgresql-11 source package in Disco:
  Confirmed

Bug description:
  Current versions in supported releases:
   postgresql-9.3 | 9.3.23-0ubuntu0.14.04 trusty <- no upstream updates anymore
   postgresql-9.5 | 9.5.14-0ubuntu0.16.04 xenial
   postgresql-10 | 10.6-0ubuntu0.18.04.1 bionic
   postgresql-10 | 10.6-0ubuntu0.18.10.1 cosmic

  Special cases:
  - Disco will be synced from Debian soon (we are on 11.1-2)
  - This is again a security update, so we prep and security will eval and 
publish through -security

  Last relevant related stable updates: 9.5.16, 10.7

  So the todo is to pick:
  MRE: Xenial 9.5.14 from 
https://ftp.postgresql.org/pub/source/v9.5.16/postgresql-9.5.16.tar.gz
  MRE: Bionic/Cosmic 10.7   from 
https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gz

  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  New - this bug
  - pad.lv/1815665

  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.

  
  Regression potential:
  - usually this works smoothly, but this time there is a change worth to 
mention for the SRU team. There is a change in all branches like [1]
I agree with the change - it is right to fix the FE/BE protocol, the 
only thing that should be affected are testcases like the ones I found.
So maybe some CIs (checking expected vs actual output) might break and 
logs might increase (now tracking formerly ignored errors), but 
not more.

  Note: opening private as it is not yet announced
  Public 

[Group.of.nepali.translators] [Bug 1709877] Re: CPU hotplug fails in the system with empty numa nodes, "Invalid value '0-1, 16-17' for 'cpuset.mems': Invalid argument"

[Christian Ehrhardt ]

Done at 
https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#CPU_Hotplug_with_QEMU-KVM
By that this issue is resolved.

** Changed in: libvirt (Ubuntu Xenial)
   Status: Incomplete => Won't Fix

** Also affects: ubuntu-release-notes
   Importance: Undecided
   Status: New

** Changed in: ubuntu-release-notes
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1709877

Title:
  CPU hotplug fails in the system with empty numa nodes, "Invalid value
  '0-1,16-17' for 'cpuset.mems': Invalid argument"

Status in The Ubuntu-power-systems project:
  Incomplete
Status in Release Notes for Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Won't Fix

Bug description:
  == Comment: #0 - Satheesh Rajendran  - 2017-07-19 
04:13:18 ==
  CPU hotplug operation fails in the host with empty numa nodes(with no memory) 
even though VM placement is static and with/without numad is running.
  ..
   32
  ...

  
  # virsh setvcpus virt-tests-vm1 6 --live
  error: Invalid value '0-1,16-17' for 'cpuset.mems': Invalid argument

  
  # numactl --hardware
  available: 4 nodes (0-1,16-17)
  node 0 cpus: 0 8 16 24 32 40
  node 0 size: 16188 MB
  node 0 free: 1119 MB
  node 1 cpus: 48 56 64 72 80 88
  node 1 size: 32630 MB
  node 1 free: 13233 MB
  node 16 cpus: 96 104 112 120 128 136
  node 16 size: 0 MB
  node 16 free: 0 MB
  node 17 cpus: 144 152 160 168 176 184
  node 17 size: 0 MB
  node 17 free: 0 MB
  node distances:
  node   0   1  16  17 
0:  10  20  40  40 
1:  20  10  40  40 
   16:  40  40  10  20 
   17:  40  40  20  10 

  # cat /sys/fs/cgroup/cpuset/cpuset.mems 
  0-1

  Host:
  #uname -a
  Linux powerkvm4-lp1 4.10.0-27-generic #30~16.04.2-Ubuntu SMP Thu Jun 29 
16:06:52 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

  ii  libvirt-bin1.3.1-1ubuntu10.11 
  ii  numad  0.5+20150602-4 
  qemu-kvm   1:2.5+dfsg-5ubuntu10.14

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1709877/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1710390] Re: iwlwifi: Microcode SW error detected. Restarting 0x2000000

[Christian Ehrhardt ]

This is actually about two bugs in one and related to bug 1804841
Lets disambiguate them.

One can be avoided by a config in network-manager as mentioned in comment #19
Lets handle this bug here as "that one" - at least in Bionic and later - fixed 
by being set by default.

This was initially fixed in 1.12.4-1ubuntu1
>From changelog:
- NetworkManager.conf: disable MAC randomization feature. There is no
  easy way for desktop users to disable this feature yet. And there are
  reports that it doesn't work well with some systems.
And also became part of Bionic in 1.10.6-2ubuntu1

I'm marking this bug fixed since Bionic due to that.

---

Everyone else still affected despite this workaround has another yet 
unclarified issue.
This shall be tracked in bug 1804841

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

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

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

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

** Changed in: linux (Ubuntu)
   Status: Confirmed => Fix Released

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

** Changed in: linux (Ubuntu Xenial)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1710390

Title:
  iwlwifi: Microcode SW error detected. Restarting 0x200

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Incomplete
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released

Bug description:
  This bug was resolved (see 1588632)  On ubuntu 17.04 recent update
  from kernel 4.10.0-30-generic to 4.10.0-32-generic has resulted in a
  regression, reintroducing this bug.

  iwlwifi :03:00.0: Microcode SW error detected.  Restarting 0x200.
  [   12.294262]  iwl_pcie_irq_handle_error+0x39/0x160 [iwlwifi]
  --- 
  ApportVersion: 2.20.4-0ubuntu4.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  janice 1664 F pulseaudio
  CurrentDesktop: XFCE
  DistroRelease: Ubuntu 17.04
  HibernationDevice: RESUME=UUID=be1fb904-a9f5-4c1f-a154-349c0a6e63de
  InstallationDate: Installed on 2016-07-12 (396 days ago)
  InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160712)
  MachineType: Dell Inc. Dell System XPS 15Z
  Package: linux (not installed)
  ProcFB:
   0 nouveaufb
   1 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-30-generic 
root=UUID=c280c3d0-6ec1-4080-9d10-74acc2399bad ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 4.10.0-30.34-generic 4.10.17
  RelatedPackageVersions:
   linux-restricted-modules-4.10.0-30-generic N/A
   linux-backports-modules-4.10.0-30-generic  N/A
   linux-firmware 1.164.1
  Tags:  zesty
  Uname: Linux 4.10.0-30-generic x86_64
  UpgradeStatus: Upgraded to zesty on 2017-03-11 (153 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev root sambashare sudo www-data
  _MarkForUpload: True
  dmi.bios.date: 09/07/2012
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A12
  dmi.board.name: 0XK6HV
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: 0.1
  dmi.modalias: 
dmi:bvnDellInc.:bvrA12:bd09/07/2012:svnDellInc.:pnDellSystemXPS15Z:pvr:rvnDellInc.:rn0XK6HV:rvrA00:cvnDellInc.:ct8:cvr0.1:
  dmi.product.name: Dell System XPS 15Z
  dmi.sys.vendor: Dell Inc.

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1770532] Re: DKIM signing not working in bionic

[Christian Ehrhardt ]

Hi Neustradamus,
the initial bug was reported as "Upon upgrading to bionic, amavisd-new DKIM 
signing no longer works." so no one thought about former releases.
This also matches that there were no bugs about that issue, prior to Bionic 
being released.

Also there is an increased risk the further changes are backported.
In this case all >=Bionic was on 2.11, but Xenial is 2.10 and Trusty even on 
2.7.
So even if it happens in older versions the tradeoff between regressions for 
current users vs the benefit of the fix for others might be different.
Especially with a somewhat dead upstream and a patch that existed in three 
variants - also the test instructions are ok'ish but not totally complete to 
try it in different variants. Therefore the risk is too high to apply it 
further back (IMHO).

The old patch applies, but with a 788 line offset in a 34k line perl
file - oO

For now - for me personally - this is Won't Fix, but I'm open to be
convinced if we get enough confirmation and confidence in it. So if you
really think the very same issue affects Xenial, please share some
details about why you think so. Do the testing steps above trigger it
for you, if you can add extra details about testing if needed for
Xenial.

** Also affects: amavisd-new (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: amavisd-new (Ubuntu Xenial)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1770532

Title:
  DKIM signing not working in bionic

Status in amavisd-new package in Ubuntu:
  Fix Released
Status in amavisd-new source package in Xenial:
  Won't Fix
Status in amavisd-new source package in Bionic:
  Fix Released
Status in amavisd-new source package in Cosmic:
  Fix Released
Status in amavisd-new package in Debian:
  Confirmed

Bug description:
  [Impact]

   * There is a known upstream issue in 2.0.11 breaking DKIM signing.
 - https://bugzilla.redhat.com/show_bug.cgi?id=1364730
 - https://lists.amavis.org/pipermail/amavis-users/2018-February/005292.html

   * given the activity on the report it seems plenty of people set this up 
 pre-Bionic and are now running into these failures on upgrade to the 
 current LTS.

   * Add a fix to avoid more people being hit by this on upgrade and forced 
 to deploy workarounds (or drop the functionality)

  [Test Case]

   * Setup amavisd for DKIM signing, see 
 https://www.ijs.si/software/amavisd/amavisd-new-docs.html#dkim
 or any of
 
https://www.faqforge.com/linux/how-to-enable-dkim-email-signatures-in-amavisd-new-and-ispconfig-3/
 https://nwgat.ninja/setting-up-dkim-and-spf-with-amavis-on-ubuntu-16-04-2/
 ...
 There seem to be a lot all doing the same essential steps.

 TL;DR would be:
 $ apt install amavisd-new
 $ mkdir -p /var/db/dkim/
 $ amavisd-new genrsa /var/db/dkim/example-foo.key.pem
 Add in /etc/amavis/conf.d/21-ubuntu_defaults
  $enable_dkim_signing = 1;
  dkim_key('example.com', 'foo', '/var/db/dkim/example-foo.key.pem');
  @dkim_signature_options_bysender_maps = (
  { '.' => { ttl => 21*24*3600, c => 'relaxed/simple' } } );
  @mynetworks = qw(0.0.0.0/8 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12
  192.168.0.0/16);  # list your internal networks
  - Now showkeys will report your key including the pblic key you'll need
   - amavisd-new showkeys
  - add the public key (as displayed) to your DNS zone, increment SOA sequence 
number and reload DNS;
  - then test signing and a published key
 - amavisd-new testkeys

  Never the less you'd need to setup a lot of details and it feels
  unclear if you test the right thing, therefor my preference is with so
  many users reporting about the issue to rely on them to test their
  real setups.

  [Regression Potential]

   * Lacking upstream being active there is always a chance things are 
 missed, but multiple people came up with very similar solutions and 
 multiple people tested these successfully.
 The actual change sets the originating flag where it is needed on the 
 creation of dkim signatures.
 Due to that setups not triggering dkim_make_signatures should be not 
 affected at all. And those that use dkim_make_signatures are those 
 failing now due to the issue.

  [Other Info]
   
   * Upstream seems essentially dead atm, so it is on the community (users 
 reporting patches on the ML) and the Distributions (e.g. Fedora have 
 taken a very similar change) alone for now.
   * For some extra confidence I'd ask for some extra time in proposed for 
 this update.

  

  Upon upgrading to bionic, amavisd-new DKIM signing no longer works.

  A quick google search reveals that this is a known bug in amavisd
  2.11.0:

  https://bugzilla.redhat.com/show_bug.cgi?id=1364730
  

[Group.of.nepali.translators] [Bug 1805920] Re: iPXE ignores vlan 0 traffic

[Christian Ehrhardt ]

To keep potential regressions even lower I'd for now only consider that for 
>=Bionic.
That also helps as if someone intentionally spawns an old type KVM machine (pre 
Bionic) on a >=Bionic host we don#t have to care about this too much (machine 
type, not release runnin IN the guest). That makes us able to ignore 
ipxe-qemu-256k-compat-efi-roms in regard to this issue.

** Also affects: ipxe-qemu-256k-compat (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu)
   Status: Confirmed => Invalid

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

** Also affects: ipxe (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: ipxe-qemu-256k-compat (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

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

** Also affects: ipxe (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: ipxe-qemu-256k-compat (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Disco)
   Importance: Undecided
   Status: Invalid

** Also affects: ipxe (Ubuntu Disco)
   Importance: Undecided
   Status: Fix Released

** Also affects: ipxe-qemu-256k-compat (Ubuntu Disco)
   Importance: Undecided
   Status: New

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

** Also affects: ipxe (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: ipxe-qemu-256k-compat (Ubuntu Trusty)
   Importance: Undecided
   Status: New

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

** Also affects: ipxe (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: ipxe-qemu-256k-compat (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** No longer affects: linux (Ubuntu Trusty)

** No longer affects: linux (Ubuntu Xenial)

** No longer affects: linux (Ubuntu Bionic)

** No longer affects: linux (Ubuntu Cosmic)

** No longer affects: linux (Ubuntu Disco)

** Changed in: ipxe-qemu-256k-compat (Ubuntu Trusty)
   Status: New => Invalid

** Changed in: ipxe-qemu-256k-compat (Ubuntu Xenial)
   Status: New => Invalid

** No longer affects: ipxe-qemu-256k-compat (Ubuntu Trusty)

** No longer affects: ipxe-qemu-256k-compat (Ubuntu Xenial)

** No longer affects: ipxe-qemu-256k-compat (Ubuntu Bionic)

** No longer affects: ipxe-qemu-256k-compat (Ubuntu Cosmic)

** No longer affects: ipxe-qemu-256k-compat (Ubuntu Disco)

** Changed in: ipxe-qemu-256k-compat (Ubuntu)
   Status: New => Won't Fix

** Changed in: ipxe (Ubuntu Trusty)
   Status: New => Won't Fix

** Changed in: ipxe (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: ipxe-qemu-256k-compat (Ubuntu)
   Status: Won't Fix => Invalid

** Changed in: ipxe (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: ipxe (Ubuntu Cosmic)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1805920

Title:
  iPXE ignores vlan 0 traffic

Status in MAAS:
  Invalid
Status in ipxe package in Ubuntu:
  Fix Released
Status in ipxe-qemu-256k-compat package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in ipxe source package in Trusty:
  Won't Fix
Status in ipxe source package in Xenial:
  Won't Fix
Status in ipxe source package in Bionic:
  Triaged
Status in ipxe source package in Cosmic:
  Triaged
Status in ipxe source package in Disco:
  Fix Released

Bug description:
  I have three MAAS rack/region nodes which are blades in a Cisco UCS
  chassis. This is an FCE deployment where MAAS has two DHCP servers,
  infra1 is the primary and infra3 is the secondary. The pod VMs on
  infra1 and infra3 PXE boot fine but the pod VMs on infra2 fail to PXE
  boot. If I reconfigure the subnet to provide DHCP on infra2 (either as
  primary or secondary) then the pod VMs on infra2 will PXE boot but the
  pod VMs on the demoted infra node (that no longer serves DHCP) now
  fail to PXE boot.

  While commissioning a pod VM on infra2 I captured network traffic with
  tcpdump on the vnet interface.

  Here is the dump when the PXE boot fails (no dhcp server on infra2):
  https://pastebin.canonical.com/p/THW2gTSv4S/

  Here is the dump when PXE boot succeeds (when infra2 is serving dhcp):
  https://pastebin.canonical.com/p/HH3XvZtTGG/

  The only difference I can see is that in the unsuccessful scenario,
  the reply is an 802.1q packet -- it's got a vlan tag for vlan 0.
  Normally vlan 0 traffic is passed as if it is not tagged and indeed, I
  can ping between the blades with no problem. Outgoing packets are
  untagged but incoming packets are tagged vlan 0 -- but the ping works.
  It seems vlan 0 is used as a part of 802.1p to set priority 

[Group.of.nepali.translators] [Bug 1807743] Re: QEMU timerfd_create support on PowerPC

[Christian Ehrhardt ]

I agree to the case, but not fully to the fix.
The old syscall definitions came in in 2007 via [1] "Update Linux kernel 
syscall list" (v0.10.0)
The feature adding the timerfd was added in 2014 with [2] "linux-user: support 
timerfd_{create, gettime, settime} syscalls" (v2.2.0) using the wrong 
definitions.

Later this was fixed 2015 for arm [3] "linux-user/arm: Correct
TARGET_NR_timerfd to TARGET_NR_timerfd_create" (v2.4.0) and for the rest
2016 in [4] "linux-user: correct timerfd_create syscall numbers"
(2.6.0).

No follow on fixes after that seen in upstream/master

That said things are fixed in Yakkety and later.
And the feature didn't exist in Trusty.
So only Xenial is affected.

The changes seem doable, and even if one used the old header on a
backport it became the number which still is the same number. Also those
headers are not meant for external use (no one links on that, and even
if one would - again - it is the same number now).

Old value only used in the defines:
$ grep -Hrn 'TARGET_NR_timerfd\s'
linux-user/sparc/syscall_nr.h:281:#define TARGET_NR_timerfd 312
linux-user/unicore32/syscall_nr.h:361:#define TARGET_NR_timerfd 
  350
linux-user/ppc/syscall_nr.h:322:#define TARGET_NR_timerfd   306
linux-user/sparc64/syscall_nr.h:313:#define TARGET_NR_timerfd   312
linux-user/mips/syscall_nr.h:323:#define TARGET_NR_timerfd  
(TARGET_NR_Linux + 318)
linux-user/sh4/syscall_nr.h:326:#define TARGET_NR_timerfd   322
linux-user/m68k/syscall_nr.h:320:#define TARGET_NR_timerfd  318
linux-user/x86_64/syscall_nr.h:284:#define TARGET_NR_timerfd283
linux-user/s390x/syscall_nr.h:246:#define TARGET_NR_timerfd 317
linux-user/i386/syscall_nr.h:327:#define TARGET_NR_timerfd  322
linux-user/mips64/syscall_nr.h:287:#define TARGET_NR_timerfd   
(TARGET_NR_Linux + 281)
linux-user/mips64/syscall_nr.h:601:#define TARGET_NR_timerfd   
(TARGET_NR_Linux + 277)
linux-user/alpha/syscall_nr.h:416:#define TARGET_NR_timerfd 
477

That said, that LGTM - except I'd backport the official upstream fixes [3] and 
[4].
@Wes - would you mind outlining steps to reproduce as that is an integral part 
of any SRU [5]


[1]: 
https://git.qemu.org/?p=qemu.git;a=commit;h=8dd77cca03ac6325bda61dbdb8b8a2021fe524c3
 
[2]: 
https://git.qemu.org/?p=qemu.git;a=commit;h=518343413fd311a3d95798b2c1d51853fd8d3c85
[3]: 
https://git.qemu.org/?p=qemu.git;a=commit;h=d82322e175d58c0c8951cbc905da1ca9ee2e008c
[4]: 
https://git.qemu.org/?p=qemu.git;a=commit;h=93a92d3bd649cd315db47b9fb5dcb6af657cc22c
[5]: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template

** Also affects: qemu (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

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

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

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

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

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

** Description changed:

+ [Impact]
+ 
+  * A bad named define made timerfd_create be in the code but not
+ available
+ 
+  * two smaller fixes to be backported from upstream that change the define 
+names; This will enable the timerfd_create in qemu-user
+ 
+ [Test Case]
+ 
+  * TODO @WES
+ 
+ [Regression Potential]
+ 
+  * The headers are only used internally so no outside regression should 
+happen.
+  * Even then only the names changed but the number stayed, that means even 
+if it would be an external ABI (it isn't) the number would be the same
+  * Internally the old define was only used when defining it, but not used 
+(see grep in comment #1)
+  * The one regression I could think of is software running in qemu-user 
+today and working by having a path like "does this have timerfd create 
+-> no, ok then do A", with the change this might become "-> yes, so do 
+B" and if that B is broken there would be a regression, but I'd 
+consider it unlikely since all versions after Xenials 2.5 had the new 
+variant and I have seen no complaints about it.
+ 
+ [Other Info]
+  
+  * n/a
+ 
+ 
+ ---
+ 
  QEMU erroneously fails to detect support for the timerfd_create syscall
  when running user-mode emulation of PowerPC targets. QEMU supports the
  timerfd_create syscall, but because the PowerPC target syscall header
  has it named "timerfd" instead of "timerfd_create", support is
  

[Group.of.nepali.translators] [Bug 247590] Re: main inclusion request: trousers

[Christian Ehrhardt ]

Hi, this 2008 promotion was auto-demoted in Bionic for an upstream
change in Strongswan no more holding it in place. That is fixed in the
recent Bionic upload triggering this old component mismatch again. I'd
ask an AA to re-promote libtspi1 for that in Disco and assigned the AA's
to the Disco Task that I added.

** Also affects: trousers (Ubuntu Disco)
   Importance: Undecided
   Status: Fix Released

** Changed in: trousers (Ubuntu Disco)
 Assignee: (unassigned) => Ubuntu Package Archive Administrators 
(ubuntu-archive)

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

** Also affects: trousers (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: trousers (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: trousers (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: trousers (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: trousers (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

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

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

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

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/247590

Title:
  main inclusion request: trousers

Status in trousers package in Ubuntu:
  New
Status in trousers source package in Precise:
  Fix Released
Status in trousers source package in Trusty:
  Fix Released
Status in trousers source package in Xenial:
  Fix Released
Status in trousers source package in Bionic:
  Invalid
Status in trousers source package in Cosmic:
  Invalid
Status in trousers source package in Disco:
  New

Bug description:
  Binary package hint: trousers

  Please consider trousers for inclusion into Ubuntu main.
   * https://wiki.ubuntu.com/MainInclusionTrousers

  libltspi-dev is a build dependency for ecryptfs-utils, which is under 
consideration for main:
   * Bug #247400
   * https://wiki.ubuntu.com/MainInclusionReportEcryptfsUtils

  We could, perhaps, remove libltspi-dev as a build dependency for 
ecryptfs-utils (Patch with Bug #247389).  I requested that Debian do this 
upstream, but they disagreed.  See:
   * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490233

  libltspi contains support for the Trusted Computing (TPM) chips which
  are found on many new laptops and servers, particularly IBM hardware.

  If we include support for libltspi, ecryptfs could be used to
  cryptographically couple filesystems to particular hardware.

  :-Dustin

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1799990] Re: tomcat7 doesn't start after upgrade to 7.0.68-1ubuntu0.3

[ Christian Ehrhardt ]

The script would usually call tomcat with:
  -Djava.security.policy=="$CATALINA_BASE"/work/catalina.policy

The dir here by the suggested sed is replaced by
  work -> policy

Many other things are referenced based on "$CATALINA_BASE/..." and they
are all in "/var/lib/tomcat7/...".

So is the generated policy file (generated from /etc/tomcat7/policy.d/):
  /var/lib/tomcat7/policy/catalina.policy

You said "on upgrade" so I checked some other versions.
There actually is a /var/lib/tomcat[78]/work directory in each installation 
Trusty to Bionic.

The issue you describe is present in Trusty's version of tomcat7 just as
much.

The catalina.sh script in tomcat8 has the bug you describe already
fixed, so >=Bionic are good.


I highly appreciate filing this bug and already documenting a way to fix it up 
in a local installation. But TBH for an SRU I'm afraid to break it for those 
who fixed their conf e.g. by placing their policy in /work and now would 
suddenly pick up a different config after the update. Post release changes to 
config handling always suffer from that, and while sometimes negligible, here 
they might be more severe :-/
There could be some tricks like a postinst checking if the work... path exists 
and if so keep things as is, but otherwise modify it - but that makes a complex 
situation more complex.
And /usr/share/tomcat7/bin/catalina.sh is no conffile [1], so users with 
changes would not be prompted if they had custom changes.

I don't understand why this would hit you "on upgrade" unless you had
the same non conffile change in an older version and it is then
obviously overwritten on each update (as intended by the packaging).

I wondered what we could do to help further users, but not break those with 
existing set ups fixed some way.
To enable the security manager you'd switch this to yes [2]:
  # Use the Java security manager? (yes/no)
  TOMCAT7_SECURITY=no
in /etc/init.d/tomcat7 (there is no other conf file for it that I'd have seen).

If you do so you get your reported effect of a failing start of the process.
Your suggested solution to the (non conffile) catalina.sh would be overwritten 
every update of the package.
But this:
  ln -s /var/lib/tomcat7/policy/catalina.policy /var/lib/tomcat7/work/
Would make it work as well, yet should survive upgrades.

We I'd suggest to do in the tomcat7 postinst:
1. if someone already established anything at 
/var/lib/tomcat7/work/catalina.policy leave it alone
2. if not then create the link as suggested
   ln -s /var/lib/tomcat7/policy/catalina.policy /var/lib/tomcat7/work/
3. remove the link on "purge" (but don't fail if it doesn't exist)

That should:
1. fix the issue if people just set TOMCAT7_SECURITY=yes
2. not kill users config if there is any at 
/var/lib/tomcat7/work/catalina.policy
3. not affect configurations that have no set TOMCAT7_SECURITY=yes
4. no be overwritten on upgrades
5. the upgrade to tomcat8 is incompatible anyway and has the fix since release 
(path in .sh matching real path)

I wonder what your opinion on that is.
If you like the suggestion I might create something for the Team to review.

[1]: 
https://raphaelhertzog.com/2010/09/21/debian-conffile-configuration-file-managed-by-dpkg/
[2]: 
https://git.launchpad.net/ubuntu/+source/tomcat7/tree/debian/README.Debian?h=ubuntu/xenial-devel#n10

** Also affects: tomcat7 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: tomcat7 (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: tomcat7 (Ubuntu)
   Status: Confirmed => Fix Released

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

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/170

Title:
  tomcat7 doesn't start after upgrade to 7.0.68-1ubuntu0.3

Status in tomcat7 package in Ubuntu:
  Fix Released
Status in tomcat7 source package in Trusty:
  Confirmed
Status in tomcat7 source package in Xenial:
  Confirmed

Bug description:
  With Security Manager enabled, tomcat7 doesn't start after upgrade to
  7.0.68-1ubuntu0.3

  Fix:

  sed -i 's/work\/catalina.policy/policy\/catalina.policy/g'
  /usr/share/tomcat7/bin/catalina.sh

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1792400] Re: smbd failed in host when both lxd container and host have smbd

[ Christian Ehrhardt ]

** Changed in: samba (Ubuntu Trusty)
   Status: Fix Committed => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1792400

Title:
  smbd failed in host when both lxd container and host have smbd

Status in samba package in Ubuntu:
  Fix Released
Status in samba source package in Trusty:
  Invalid
Status in samba source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Issue: the current init script
 * won't start samba related services on the host if there is a process 
   of the same binary in a container
 * might on stop affect a process that it was not intended to stop

   * Solution: Fix init scripts to
 * start action to have a safer process detection with containers around
     * stop action to not affect unintended processes due to stale pidfiles

  [Test Case]

   * 1. Start a container
   * 2. Start samba in the Container (or winbind or nmbd)
   * 3. Start samba in the host (or winbind or nmbd)
    => it will not start as such a binary is already running
   * #2 and #3 can be switched, and then as 4. restart smbd in the host
    => it will shut down but not re-start

  Fixed: The container process should have no influence

   This also fixes issues where the pidfile would not be updated
   * install and start smbd
   * "Simulate" a corrupted pidfile by putting the PID of a different
     process in it
   * stop the sambd service
    => without the fixes this will drag down the other process you put in
   the pidfile

  Fixed: a stale pidfile entry should not let non-smbd (or winbind,
  nmbd) processes be affected

  [Regression Potential]

   * We tried to think of all edge cases of these start/stop actions but
     didn't come up with one that is broken. Aside from missing one of those
     cases there might be non-archive scripts that expect the old behavior.
     But even for thse no critical ones came to my mind so far.
     Worst case there'd be a combination that leads to the service
     no(re-)starting after the SRU - so thinking about potential cases is
     important.

  [Other Info]

   * n/a

  ---

  Setup: install smbd in host and lxd-container.

  Now restart smbd in host:

  service smbd restart
  All is OK.
  Problem: nmap shows "closed" on ports 139 and 445. And users cannot use smbd 
server in host.

    ● smbd.service - LSB: start Samba SMB/CIFS daemon (smbd)
     Loaded: loaded (/etc/init.d/smbd; bad; vendor preset: enabled)
     Active: active (exited) since Die 2016-10-18 17:35:23 CEST; 2s ago
   Docs: man:systemd-sysv-generator(8)
    Process: 24218 ExecStop=/etc/init.d/smbd stop (code=exited, 
status=0/SUCCESS)
    Process: 21980 ExecReload=/etc/init.d/smbd reload (code=exited, 
status=0/SUCCESS)
    Process: 25190 ExecStart=/etc/init.d/smbd start (code=exited, 
status=0/SUCCESS)

  Okt 18 17:35:22 speedy systemd[1]: Starting LSB: start Samba SMB/CIFS daemon 
(smbd)...
  Okt 18 17:35:23 speedy smbd[25190]:  * Starting SMB/CIFS daemon smbd
  Okt 18 17:35:23 speedy smbd[25190]:...done.
  Okt 18 17:35:23 speedy systemd[1]: Started LSB: start Samba SMB/CIFS daemon 
(smbd).

  ps axf | grep smbd:

  25356 pts/2S+ 0:00  |   \_ grep --color=auto smbd
  19915 ?Ss 0:08  \_ /usr/sbin/smbd -D
  19919 ?S  0:00  \_ /usr/sbin/smbd -D

  However, netstat -tpln | grep "smbd" returns nothing and also nmap
  shows "closed" on ports 139 and 445.

  Workaround [1]:
  change /etc/init.d/smbd:
   if ! start-stop-daemon --start --quiet --oknodo --exec /usr/sbin/smbd -- -D 
; then

  to

   if ! start-stop-daemon --start --quiet --oknodo --pidfile
  /var/run/samba/smbd.pid --exec /usr/sbin/smbd -- -D ; then

  I reported this to:
  https://discuss.linuxcontainers.org/t/samba-in-host-and-container/2523

  apt-cache policy samba
  samba:
    Installed: 2:4.3.11+dfsg-0ubuntu0.16.04.15
    Candidate: 2:4.3.11+dfsg-0ubuntu0.16.04.16
    Version table:
   2:4.3.11+dfsg-0ubuntu0.16.04.16 500
  500 http://de.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
   *** 2:4.3.11+dfsg-0ubuntu0.16.04.15 500
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   2:4.3.8+dfsg-0ubuntu1 500
  500 http://de.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  1. https://serverfault.com/questions/810544/samba-daemon-does-not-
  work-as-systemd-service-but-works-in-foreground

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : 

[Group.of.nepali.translators] [Bug 1576187] Re: backuppc/smb: BackupPC failes to backup SMB shares after smbclient update

[ Christian Ehrhardt ]

Yes this change (the Debian version of it, not yours) is in since 3.3.1-3
Thanks a lot Mark! for the ping on this forgotten bug also for the 
documentation of the config in regard to BackupZeroFilesIsFatal if previously 
set to 1.

(And also thanks for your upstreaming work on this)


** Also affects: backuppc (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: backuppc (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: backuppc (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: backuppc (Ubuntu)
   Status: Triaged => Fix Released

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1576187

Title:
  backuppc/smb: BackupPC failes to backup SMB shares after smbclient
  update

Status in backuppc:
  Unknown
Status in backuppc package in Ubuntu:
  Fix Released
Status in backuppc source package in Trusty:
  New
Status in backuppc source package in Xenial:
  New
Status in backuppc source package in Bionic:
  Fix Released

Bug description:
  After the current update of samba 4.1.6 to 4.3.8 samba on trusty the
  BackupPC smb transfer is broken.

  Several bugs in smbclient >= 4.1.6 in combination with BackupPC:
   https://bugzilla.samba.org/show_bug.cgi?id=11642 (tarmode is no longer 
verbose and ignores verbose flag)
- patch1 (reenable tarmode verbose, and skip inaccessible files) 
https://attachments.samba.org/attachment.cgi?id=11733
- patch 2 (modified clitar.c for tarmode verbose) 
https://attachments.samba.org/attachment.cgi?id=11734
   https://bugzilla.redhat.com/show_bug.cgi?id=1294761 (mis-interpreted failure 
of new tar:\d+ lines) (fix: 
https://bugzilla.redhat.com/attachment.cgi?id=264=diff)

  Package Information:

   0)root@essrv2:~ $ dpkg -l | grep -E "(smb|samba|backuppc)"
   ii backuppc 3.3.0-1ubuntu1 amd64 high-performance, enterprise-grade system 
for backing up PCs
   ii libpam-smbpass:amd64 2:4.3.8+dfsg-0ubuntu0.14.04.2 amd64 pluggable 
authentication module for Samba
   ii libsmbclient:amd64 2:4.3.8+dfsg-0ubuntu0.14.04.2 amd64 shared library for 
communication with SMB/CIFS servers
   ii python-samba 2:4.3.8+dfsg-0ubuntu0.14.04.2 amd64 Python bindings for Samba
   ii samba 2:4.3.8+dfsg-0ubuntu0.14.04.2 amd64 SMB/CIFS file, print, and login 
server for Unix
   ii samba-common 2:4.3.8+dfsg-0ubuntu0.14.04.2 all common files used by both 
the Samba server and client
   ii samba-common-bin 2:4.3.8+dfsg-0ubuntu0.14.04.2 amd64 Samba common files 
used by both the server and the client
   ii samba-doc 2:4.3.8+dfsg-0ubuntu0.14.04.2 all Samba documentation
   ii samba-dsdb-modules 2:4.3.8+dfsg-0ubuntu0.14.04.2 amd64 Samba Directory 
Services Database
   ii samba-libs:amd64 2:4.3.8+dfsg-0ubuntu0.14.04.2 amd64 Samba core libraries
   ii samba-vfs-modules 2:4.3.8+dfsg-0ubuntu0.14.04.2 amd64 Samba Virtual 
FileSystem plugins
   ii smbclient 2:4.3.8+dfsg-0ubuntu0.14.04.2 amd64 command-line SMB/CIFS 
clients for Unix

  System information of the update:

   0)root@essrv2:~ $ grep samba /var/log/apt/history.log | sed "s|),|)\n|g" | 
grep -E "(samba|smb)"
   Upgrade: libpam-smbpass:amd64 (4.1.6+dfsg-1ubuntu2.14.04.13, 
4.3.8+dfsg-0ubuntu0.14.04.2)
python-samba:amd64 (4.1.6+dfsg-1ubuntu2.14.04.13, 
4.3.8+dfsg-0ubuntu0.14.04.2)
samba:amd64 (4.1.6+dfsg-1ubuntu2.14.04.13, 4.3.8+dfsg-0ubuntu0.14.04.2)
samba-dsdb-modules:amd64 (4.1.6+dfsg-1ubuntu2.14.04.13, 
4.3.8+dfsg-0ubuntu0.14.04.2)
samba-common-bin:amd64 (4.1.6+dfsg-1ubuntu2.14.04.13, 
4.3.8+dfsg-0ubuntu0.14.04.2)
samba-libs:amd64 (4.1.6+dfsg-1ubuntu2.14.04.13, 4.3.8+dfsg-0ubuntu0.14.04.2)
samba-doc:amd64 (4.1.6+dfsg-1ubuntu2.14.04.13, 4.3.8+dfsg-0ubuntu0.14.04.2)
smbclient:amd64 (4.1.6+dfsg-1ubuntu2.14.04.13, 4.3.8+dfsg-0ubuntu0.14.04.2)
samba-vfs-modules:amd64 (4.1.6+dfsg-1ubuntu2.14.04.13, 
4.3.8+dfsg-0ubuntu0.14.04.2)
samba-common:amd64 (4.1.6+dfsg-1ubuntu2.14.04.13, 
4.3.8+dfsg-0ubuntu0.14.04.2)
libsmbclient:amd64 (4.1.6+dfsg-1ubuntu2.14.04.13, 
4.3.8+dfsg-0ubuntu0.14.04.2)

  Log of backup when failing:

   Running: /usr/bin/smbclient esrouter\\backups -U backup -E -d 1 -c 
tarmode\ full -TcrX - \*.sysdmp.tar.xz
   full backup started for share backups
   Xfer PIDs are now 25749,25748
   Domain=[E_SPIRIT] OS=[Windows 6.1] Server=[Samba 4.3.8-Ubuntu]
   tar:316 tarmode is now full, system, hidden, noreset, quiet
   tar:712 Total bytes received: 224900956
 create 644 0/0 138326 esrouter.2016-04-26.packages
 pool 644 0/0 136349 esrouter.2016-04-23.packages
 pool 644 0/0 27551 esrouter.2016-04-23.dpkg
 create 644 0/0 56037724 esrouter.2016-04-23.evh.tar.xz
 create 644 0/0 56017156 esrouter.2016-04-24.evh.tar.xz
 create 644 0/0 27964 esrouter.2016-04-26.dpkg
 pool 644 0/0 

[Group.of.nepali.translators] [Bug 1650493] Re: numastat fails with double free or corruption

[ Christian Ehrhardt ]

So to summarize:
- per latest IBM comment the version in 18.10 2.0.11-2.1 works
- This is also the version in 18.04, so that works as well
- But the referred fix (pointed out in comment #13 that is actually supposed in 
Upstream version 
  2.12) is NOT in any of those package versions

I'm marking the bug tasks accordingly for 18.04/18.10 as fixed due to
that, but clearly there is some confusion going on - so I keep the main
task on incomplete to reflect that.

Either the fix mentioned was not the actual fix needed or the recent
tests were not testing the case correctly.

Given this confusion at the current state no SRUs are planned, so I'll
mark Xenial as Won't Fix to make that clear as well.

** Also affects: numactl (Ubuntu Cosmic)
   Importance: Medium
 Assignee: Canonical Server Team (canonical-server)
   Status: Incomplete

** Also affects: numactl (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: numactl (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: numactl (Ubuntu Cosmic)
   Status: Incomplete => Fix Released

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

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

** Also affects: numactl (Ubuntu Dd-series)
   Importance: Undecided
   Status: New

** Changed in: numactl (Ubuntu Dd-series)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1650493

Title:
  numastat  fails with double free or corruption

Status in The Ubuntu-power-systems project:
  Triaged
Status in numactl package in Ubuntu:
  Fix Released
Status in numactl source package in Xenial:
  Fix Released
Status in numactl source package in Bionic:
  Fix Released
Status in numactl source package in Cosmic:
  Fix Released
Status in numactl source package in DD-Series:
  Incomplete

Bug description:
  while trying to get stat of the guest process (configured with
  hugepages), numastat fails

  
  Environment details
  
  # uname -a
  Linux lep8b 4.8.0-30-generic #32-Ubuntu SMP Fri Dec 2 03:43:46 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linu

  =
  Issue
  =
  2016-12-14 07:02:56,396 process  L0368 INFO | Running 'numastat 61257'
  2016-12-14 07:02:56,402 process  L0462 DEBUG| [stderr] *** Error in 
`numastat': double free or corruption (out): 0x0100265005a0 ***
  2016-12-14 07:02:56,403 process  L0462 DEBUG| [stdout]
  2016-12-14 07:02:56,403 process  L0482 INFO | Command 'numastat 
61257' finished with -6 after 0.00309896469116s
  2016-12-14 07:02:56,403 process  L0462 DEBUG| [stdout] Per-node 
process memory usage (in MBs) for PID 61257 (qemu-system-ppc)
  2016-12-14 07:02:56,404 process  L0462 DEBUG| [stderr] === 
Backtrace: =
  2016-12-14 07:02:56,404 process  L0462 DEBUG| [stderr] 
/lib/powerpc64le-linux-gnu/libc.so.6(+0x86d54)[0x3fff9a736d54]
  2016-12-14 07:02:56,404 process  L0462 DEBUG| [stderr] 
/lib/powerpc64le-linux-gnu/libc.so.6(+0x93c30)[0x3fff9a743c30]
  2016-12-14 07:02:56,404 process  L0462 DEBUG| [stderr] 
/lib/powerpc64le-linux-gnu/libc.so.6(cfree+0x68)[0x3fff9a748218]
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
/lib/powerpc64le-linux-gnu/libc.so.6(fclose+0x1c8)[0x3fff9a727d68]
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
numastat(+0x7aa4)[0x401d7aa4]
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
numastat(+0x2388)[0x401d2388]
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
/lib/powerpc64le-linux-gnu/libc.so.6(+0x2291c)[0x3fff9a6d291c]
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
/lib/powerpc64le-linux-gnu/libc.so.6(__libc_start_main+0xb8)[0x3fff9a6d2b18]
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] === Memory 
map: 
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
401d-401e r-xp  08:92 40325510   
/usr/bin/numastat
  2016-12-14 07:02:56,405 process  L0462 DEBUG| [stderr] 
401e-401f r--p  08:92 40325510   
/usr/bin/numastat
  2016-12-14 07:02:56,406 process  L0462 DEBUG| [stderr] 
401f-4020 rw-p 0001 08:92 40325510   
/usr/bin/numastat
  2016-12-14 07:02:56,406 process  L0462 DEBUG| [stderr] 
1002650-1002653 rw-p  00:00 0[heap]
  2016-12-14 07:02:56,406 process  L0462 DEBUG| [stderr] 
3fff9a6b-3fff9a86 r-xp  08:92 25745199   
/lib/powerpc64le-linux-gnu/libc-2.24.so
  2016-12-14 07:02:56,406 process  L0462 DEBUG| [stderr] 
3fff9a86-3fff9a87 ---p 001b 08:92 

[Group.of.nepali.translators] [Bug 1792400] Re: smbd failed in host when both lxd container and host have smbd

[ Christian Ehrhardt ]

** Also affects: samba (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: samba (Ubuntu Trusty)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1792400

Title:
  smbd failed in host when both lxd container and host have smbd

Status in samba package in Ubuntu:
  Fix Released
Status in samba source package in Trusty:
  Triaged
Status in samba source package in Xenial:
  Triaged

Bug description:
  Setup: install smbd in host and lxd-container.

  Now restart smbd in host:

  service smbd restart
  All is OK.
  Problem: nmap shows "closed" on ports 139 and 445. And users cannot use smbd 
server in host.

    ● smbd.service - LSB: start Samba SMB/CIFS daemon (smbd)
     Loaded: loaded (/etc/init.d/smbd; bad; vendor preset: enabled)
     Active: active (exited) since Die 2016-10-18 17:35:23 CEST; 2s ago
   Docs: man:systemd-sysv-generator(8)
    Process: 24218 ExecStop=/etc/init.d/smbd stop (code=exited, 
status=0/SUCCESS)
    Process: 21980 ExecReload=/etc/init.d/smbd reload (code=exited, 
status=0/SUCCESS)
    Process: 25190 ExecStart=/etc/init.d/smbd start (code=exited, 
status=0/SUCCESS)

  Okt 18 17:35:22 speedy systemd[1]: Starting LSB: start Samba SMB/CIFS daemon 
(smbd)...
  Okt 18 17:35:23 speedy smbd[25190]:  * Starting SMB/CIFS daemon smbd
  Okt 18 17:35:23 speedy smbd[25190]:...done.
  Okt 18 17:35:23 speedy systemd[1]: Started LSB: start Samba SMB/CIFS daemon 
(smbd).

  ps axf | grep smbd:

  25356 pts/2S+ 0:00  |   \_ grep --color=auto smbd
  19915 ?Ss 0:08  \_ /usr/sbin/smbd -D
  19919 ?S  0:00  \_ /usr/sbin/smbd -D

  However, netstat -tpln | grep "smbd" returns nothing and also nmap
  shows "closed" on ports 139 and 445.

  Workaround [1]:
  change /etc/init.d/smbd:
   if ! start-stop-daemon --start --quiet --oknodo --exec /usr/sbin/smbd -- -D 
; then

  to

   if ! start-stop-daemon --start --quiet --oknodo --pidfile
  /var/run/samba/smbd.pid --exec /usr/sbin/smbd -- -D ; then

  I reported this to:
  https://discuss.linuxcontainers.org/t/samba-in-host-and-container/2523

  apt-cache policy samba
  samba:
    Installed: 2:4.3.11+dfsg-0ubuntu0.16.04.15
    Candidate: 2:4.3.11+dfsg-0ubuntu0.16.04.16
    Version table:
   2:4.3.11+dfsg-0ubuntu0.16.04.16 500
  500 http://de.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
   *** 2:4.3.11+dfsg-0ubuntu0.16.04.15 500
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   2:4.3.8+dfsg-0ubuntu1 500
  500 http://de.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  1. https://serverfault.com/questions/810544/samba-daemon-does-not-
  work-as-systemd-service-but-works-in-foreground

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1792400] Re: smbd failed in host when both lxd container and host have smbd

[ Christian Ehrhardt ]

This is "just one more" case of the common old init scripts didn't
consider there could be more (=containers).

Interesting is that the stop already runs with the --pidfile so the stop
will not kill it.

But the start will be blocked, as the existance of such a process will
make --start be a no-op.

Man page:
Note: unless --pid or --pidfile are specified, start-stop-daemon behaves 
similar to killall(1).  start-stop-daemon will scan the process table looking  
for  any  processes  which match  the  process  name, parent pid, uid, and/or 
gid (if specified). Any matching process will prevent --start from starting the 
daemon. All matching processes will be sent the TERM signal (or the one 
specified via --signal or --retry) if --stop is specified. For daemons which 
have long-lived children which need to live through a --stop, you must  specify 
a pidfile.

-S, --start [--] arguments
Check  for the existence of a specified process.  If such a process exists, 
start-stop-daemon does nothing, and exits with error status 1 (0 if --oknodo is 
specified).  If such a process does not exist, it starts an instance, using 
either the executable specified by --exec or, if specified, by --startas.  Any 
arguments given after -- on  the command line are passed unmodified to the 
program being started.


The --oknodo will make it a silent non fatal exit int hat case - as it
is fine to run "start" if it is running already.


I'd recommend "--pidfile $SMBDPID" instead of the suggested path, but otherwise 
would agree to the fix.

It should be safe as that is essentially how later versions (Bionic) do
it (via MAINPID tracking in systemd).

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

** Tags added: server-next

** Also affects: samba (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: samba (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: samba (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1792400

Title:
  smbd failed in host when both lxd container and host have smbd

Status in samba package in Ubuntu:
  Fix Released
Status in samba source package in Xenial:
  Triaged

Bug description:
  Setup: install smbd in host and lxd-container.

  Now restart smbd in host:

  service smbd restart
  All is OK.
  Problem: nmap shows "closed" on ports 139 and 445. And users cannot use smbd 
server in host.

    ● smbd.service - LSB: start Samba SMB/CIFS daemon (smbd)
     Loaded: loaded (/etc/init.d/smbd; bad; vendor preset: enabled)
     Active: active (exited) since Die 2016-10-18 17:35:23 CEST; 2s ago
   Docs: man:systemd-sysv-generator(8)
    Process: 24218 ExecStop=/etc/init.d/smbd stop (code=exited, 
status=0/SUCCESS)
    Process: 21980 ExecReload=/etc/init.d/smbd reload (code=exited, 
status=0/SUCCESS)
    Process: 25190 ExecStart=/etc/init.d/smbd start (code=exited, 
status=0/SUCCESS)

  Okt 18 17:35:22 speedy systemd[1]: Starting LSB: start Samba SMB/CIFS daemon 
(smbd)...
  Okt 18 17:35:23 speedy smbd[25190]:  * Starting SMB/CIFS daemon smbd
  Okt 18 17:35:23 speedy smbd[25190]:...done.
  Okt 18 17:35:23 speedy systemd[1]: Started LSB: start Samba SMB/CIFS daemon 
(smbd).

  ps axf | grep smbd:

  25356 pts/2S+ 0:00  |   \_ grep --color=auto smbd
  19915 ?Ss 0:08  \_ /usr/sbin/smbd -D
  19919 ?S  0:00  \_ /usr/sbin/smbd -D

  However, netstat -tpln | grep "smbd" returns nothing and also nmap
  shows "closed" on ports 139 and 445.

  Workaround [1]:
  change /etc/init.d/smbd:
   if ! start-stop-daemon --start --quiet --oknodo --exec /usr/sbin/smbd -- -D 
; then

  to

   if ! start-stop-daemon --start --quiet --oknodo --pidfile
  /var/run/samba/smbd.pid --exec /usr/sbin/smbd -- -D ; then

  I reported this to:
  https://discuss.linuxcontainers.org/t/samba-in-host-and-container/2523

  apt-cache policy samba
  samba:
    Installed: 2:4.3.11+dfsg-0ubuntu0.16.04.15
    Candidate: 2:4.3.11+dfsg-0ubuntu0.16.04.16
    Version table:
   2:4.3.11+dfsg-0ubuntu0.16.04.16 500
  500 http://de.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
   *** 2:4.3.11+dfsg-0ubuntu0.16.04.15 500
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   2:4.3.8+dfsg-0ubuntu1 500
  500 http://de.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  1. https://serverfault.com/questions/810544/samba-daemon-does-not-
  work-as-systemd-service-but-works-in-foreground

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to :