date:20170529

[Group.of.nepali.translators] [Bug 1670036] Re: Misapplied patches in 4.0.6-2ubuntu0.1 break reading and writing JPEG compressed files

2017-05-29 Thread Marc Deslauriers

Thanks for reporting this issue and for the updated patch. I'll prepare
a security regression updates and will publish them this week, likely
tomorrow.

Thanks!

** Also affects: tiff (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

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

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

** Changed in: tiff (Ubuntu Trusty)
 Assignee: (unassigned) => Marc Deslauriers (mdeslaur)

** Changed in: tiff (Ubuntu Xenial)
 Assignee: (unassigned) => Marc Deslauriers (mdeslaur)

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

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

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

** Changed in: tiff (Ubuntu Yakkety)
 Assignee: (unassigned) => Marc Deslauriers (mdeslaur)

** Changed in: tiff (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/1670036

Title:
  Misapplied patches in 4.0.6-2ubuntu0.1 break reading and writing JPEG
  compressed files

Status in LibTIFF:
  New
Status in tiff package in Ubuntu:
  Invalid
Status in tiff source package in Trusty:
  Confirmed
Status in tiff source package in Xenial:
  Confirmed
Status in tiff source package in Yakkety:
  Confirmed

Bug description:
  The patches applied to libtiff 4.0.6 in 4.0.6-2ubuntu01 seem to break
  JPEG tiff read and write.

  To reproduce:

  $ tiffcp -c jpeg k2a.tif x.tif

  (where k2a.tif is a simple uncompressed RGB strip tiff) appears to
  work. However, x.tif, the output, will now not read without warnings:

  $ tiffcp x.tif y.tif
  TIFFFetchNormalTag: Warning, ASCII value for tag "JPEGTables" does not end in 
null byte. Forcing it to be null.
  JPEGLib: Warning, Premature end of JPEG file.

  This was working fine until a couple of days ago, so I guess it's one
  of the most recent patches.

  Some packages using libtiff seem to be broken too. For example,
  openslide, which uses libtiff to load jp2k-compressed slide images, is
  no longer working:

  $ openslide-write-png CMU-1-Small-Region.svs 0 0 0 100 100 x.png
  TIFFFetchNormalTag: Warning, ASCII value for tag "JPEGTables" does not end in 
null byte. Forcing it to be null.
  TIFFFetchNormalTag: Warning, ASCII value for tag "JPEGTables" does not end in 
null byte. Forcing it ... repeats 8 more times
  openslide-write-png: Premature end of JPEG file

  and x.png is not a valid PNG image.  The test .svs image may be
  downloaded here:

  http://openslide.cs.cmu.edu/download/openslide-testdata/Aperio/

To manage notifications about this bug go to:
https://bugs.launchpad.net/libtiff/+bug/1670036/+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 1672740] Re: Netplan replug function is incompatible with ath9k_htc module

2017-05-29 Thread Mathieu Trudel-Lapierre

Added a task for snappy for the core snap to be recreated. Adding
'verification-done' tag since this fix has been tested.

** Also affects: snappy
   Importance: Undecided
   Status: New

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

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

Title:
  Netplan replug function is incompatible with ath9k_htc module

Status in netplan:
  Fix Released
Status in Snappy:
  New
Status in nplan package in Ubuntu:
  Fix Released
Status in nplan source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  Replugging ath9k_htc may confuse the driver and cause connection issues.

  [Test case]
  - Run nplan integration tests on the release
  - Validate that netplan generate && netplan apply alone, without config, 
behave as expected (no result)
  - Validate that netplan generate && netplan apply with minimal config writes 
/run/NetworkManager/conf.d/10-globally-managed-devices.conf
  - Validate that netplan generate && netplan apply works with any existing 
configuation.

  - Run 'netplan apply' with a valid config for an ath9k_htc device,
  validate the device is not replugged.

  [Regression potential]
  Any failure to work with existing configuration should be considered a 
regression. Any new failure of the test suite would be a regression.

  ---

  We hit the following problem about the interaction  between netplan
  and the ath9k_htc module, controlling the chip Atheros AR9271.

  If you run the following command

  netplan --debug apply

  or  you use console-conf for setting the network interfaces we get the
  following messages :

  ** (generate:2261): DEBUG: Processing input file 
//etc/netplan/00-snapd-config.yaml..
  ** (generate:2261): DEBUG: eth0: setting default backend to 1
  ** (generate:2261): DEBUG: Generating output files..
  ** (generate:2261): DEBUG: NetworkManager: definition eth0 is not for us 
(backend 1)
  DEBUG:netplan generated networkd configuration exists, restarting networkd
  DEBUG:no netplan generated NM configuration exists
  DEBUG:device lo operstate is unknown, not replugging
  DEBUG:device eth0 operstate is up, not replugging
  DEBUG:replug wlan0: unbinding 4-1:1.0 from /sys/bus/usb/drivers/ath9k_htc
  DEBUG:replug wlan0: rebinding 4-1:1.0 to /sys/bus/usb/drivers/ath9k_htc

  The last two row show two consecutive actions, one soon after the
  other:  unbind and bind the usb device on usb hub.

  The module ath9k_htc doesn't work fine in this situation: the wireless
  interface disappears.

  Our problem can be fixed by using the same approach used for mac80211_hwsim e 
mwifiex_pcie modules.
  The attached patch file fix the issue following the same pattern adopted for 
the following modules:
  mwifiex_pcie,mac80211_hwsim.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1672740/+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 1688632] Re: nplan 0.21 update

2017-05-29 Thread Mathieu Trudel-Lapierre

** Also affects: nplan (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: nplan (Ubuntu Yakkety)
   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/1688632

Title:
  nplan 0.21 update

Status in nplan package in Ubuntu:
  Fix Released
Status in nplan source package in Xenial:
  Fix Committed
Status in nplan source package in Yakkety:
  New
Status in nplan source package in Zesty:
  New

Bug description:
  [Impact]
  Nplan has been in active development and includes important bug fixes and 
critical features for users.

  [Test case]
  - Run nplan integration tests on the release
  - Validate that netplan generate && netplan apply alone, without config, 
behave as expected (no result)
  - Validate that netplan generate && netplan apply with minimal config writes 
/run/NetworkManager/conf.d/10-globally-managed-devices.conf
  - Validate that netplan generate && netplan apply works with any existing 
configuation.

  [Regression potential]
  Any failure to work with existing configuration should be considered a 
regression. Any new failure of the test suite would be a regression.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1688632/+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 1691186] Re: linux-gke: 4.4.0-1014.14 -proposed tracker

2017-05-29 Thread Brad Figg

** Changed in: kernel-sru-workflow/regression-testing
   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/1691186

Title:
  linux-gke: 4.4.0-1014.14 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Fix Released
Status in Kernel SRU Workflow certification-testing series:
  Confirmed
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Fix Released
Status in Kernel SRU Workflow security-signoff series:
  In Progress
Status in Kernel SRU Workflow upload-to-ppa series:
  New
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux-gke package in Ubuntu:
  Invalid
Status in linux-gke source package in Xenial:
  New

Bug description:
  This bug is for tracking the  upload package.
  This bug will contain status and testing results related to that
  upload.

  For an explanation of the tasks and the associated workflow see: 
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  -- swm properties --
  boot-testing-requested: true
  kernel-stable-master-bug: 1691180
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1691186/+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 1690730] Re: New upstream microreleases 9.3.17, 9.5.7 and 9.6.3

2017-05-29 Thread Launchpad Bug Tracker

This bug was fixed in the package postgresql-9.6 - 9.6.3-0ubuntu0.17.04

---
postgresql-9.6 (9.6.3-0ubuntu0.17.04) zesty; urgency=medium

  * New upstream release (LP: #1690730)
- Restrict visibility of pg_user_mappings.umoptions, to protect passwords
  stored as user mapping options (CVE-2017-7486)
- Prevent exposure of statistical information via leaky operators
  (CVE-2017-7484)
- Restore libpq's recognition of the PGREQUIRESSL environment variable
  (CVE-2017-7485)

- A dump/restore is not required for those running 9.6.X.
- However, if you use foreign data servers that make use of user passwords
  for authentication, see the first changelog entry.
- Also, if you are using third-party replication tools that depend on
  "logical decoding", see the fourth changelog entry.


- Details about other changes at full changelog:
  https://www.postgresql.org/docs/9.6/static/release-9-6-3.html

 -- Christian Ehrhardt   Mon, 15 May
2017 08:46:09 +0200

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

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2017-7484

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2017-7485

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2017-7486

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

Title:
  New upstream microreleases 9.3.17, 9.5.7 and 9.6.3

Status in postgresql-9.3 package in Ubuntu:
  Triaged
Status in postgresql-9.5 package in Ubuntu:
  Triaged
Status in postgresql-9.6 package in Ubuntu:
  Triaged
Status in postgresql-9.3 source package in Trusty:
  Fix Committed
Status in postgresql-9.5 source package in Xenial:
  Fix Released
Status in postgresql-9.5 source package in Yakkety:
  Fix Released
Status in postgresql-9.6 source package in Zesty:
  Fix Released

Bug description:
  https://www.postgresql.org/about/news/1746/

  As per the standing micro-release exception these should land in
  stable Ubuntu releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-9.3/+bug/1690730/+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 1692590] Re: linux-hwe: 4.8.0-54.57~16.04.1 -proposed tracker

2017-05-29 Thread Brad Figg

** Changed in: kernel-sru-workflow/automated-testing
   Status: Incomplete => 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/1692590

Title:
  linux-hwe: 4.8.0-54.57~16.04.1 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Fix Released
Status in Kernel SRU Workflow certification-testing series:
  In Progress
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Confirmed
Status in Kernel SRU Workflow security-signoff series:
  Fix Released
Status in Kernel SRU Workflow upload-to-ppa series:
  New
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux-hwe package in Ubuntu:
  Invalid
Status in linux-hwe source package in Xenial:
  New

Bug description:
  This bug is for tracking the  upload package.
  This bug will contain status and testing results related to that
  upload.

  For an explanation of the tasks and the associated workflow see: 
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  -- swm properties --
  boot-testing-requested: true
  kernel-stable-master-bug: 1692589
  phase: Promoted to proposed
  proposed-announcement-sent: true
  proposed-testing-requested: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1692590/+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 1672175] Re: gnome-shell should recommend chrome-gnome-shell

2017-05-29 Thread Łukasz Zemczak

Hello Jeremy, or anyone else affected,

Accepted gnome-shell into xenial-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/gnome-
shell/3.18.5-0ubuntu0.3 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: gnome-shell (Ubuntu)
   Status: Fix Released => Triaged

** Changed in: gnome-shell (Ubuntu Xenial)
   Status: In Progress => Fix Committed

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

Title:
  gnome-shell should recommend chrome-gnome-shell

Status in gnome-shell package in Ubuntu:
  Triaged
Status in gnome-shell source package in Xenial:
  Fix Committed
Status in gnome-shell source package in Yakkety:
  Fix Committed

Bug description:
  Impact
  ==
  Users who have ubuntu-gnome-desktop installed recently got chrome-gnome-shell 
installed to fix a regression introduced in Firefox 52 (LP: #1323734).

  Some people use gnome-shell without that metapackage installed.

  Test Case
  =
  Does gnome-shell recommend chrome-gnome-shell?

  Regression Potential
  
  Low. chrome-gnome-shell was already tested (LP: #1652537)

  Other Info
  ==
  This is only a recommends since perhaps users of gnome-shell without 
ubuntu-gnome-desktop don't want a lot of extra packages installed. This isn't 
critical functionality.

  Ubuntu 17.04 was released with gnome-shell recommending chrome-gnome-
  shell.

  Currently, Ubuntu 17.10 Alpha's gnome-shell does not recommend chrome-
  gnome-shell because the Ubuntu Desktop Team is trying to get a minimal
  gnome-shell into main first then add the extra dependencies later. I
  expect chrome-gnome-shell to be in main and be restored as a
  recommends before 17.10 is released.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1672175/+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 1613805] Re: [evolution/wip/webkit2] EHTMLEditorView - Restore the selection end mark correctly when processing HTML to plain text

2017-05-29 Thread Launchpad Bug Tracker

This bug was fixed in the package evolution - 3.18.5.2-0ubuntu3.2

---
evolution (3.18.5.2-0ubuntu3.2) xenial-proposed; urgency=medium

  * debian/patches/lp1613805.patch: EHTMLEditorView - Restore the selection
end mark correctly when processing HTML to plain text (LP: #1613805)

 -- Jamie Strandboge   Thu, 11 May 2017 18:42:04 +

** Changed in: evolution (Ubuntu Xenial)
   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/1613805

Title:
  [evolution/wip/webkit2] EHTMLEditorView - Restore the selection end
  mark correctly when processing HTML to plain text

Status in evolution package in Ubuntu:
  Fix Released
Status in evolution source package in Xenial:
  Fix Released
Status in evolution source package in Artful:
  Fix Released

Bug description:
  [Impact]
  Ubuntu 16.04 evolution users sometimes send emails with ##SELECTION_END## due 
to a copy/paste error in the EHTMLEditorView code when converting HTML to plain 
text.

  This is fixed in newer Ubuntu releases. The fix is a from upstream:
  https://mail.gnome.org/archives/commits-list/2016-May/msg06756.html

  [Test Case]
  I tried to find a test case but was unable to as it doesn't seem to always 
happen and there is no upstream bug or steps to reproduce. The code change is 
obvious though. This is the broken code:

  if (strstr (*text, "##SELECTION_START##")) {
   GString *tmp;

   tmp = e_str_replace_string (
    *text,
    "##SELECTION_START##",
    "");

   g_free (*text);
   *text = g_string_free (tmp, FALSE);
  }

  if (strstr (*text, "##SELECTION_END##")) {
   GString *tmp;

   tmp = e_str_replace_string (
    *text,
    "##SELECTION_START##",
    "");

   g_free (*text);
   *text = g_string_free (tmp, FALSE);
  }

  Notice how if it finds ##SELECTION_END## in the text, it will not end
  up replacing it because it tries to replace ##SELECTION_START##
  instead. Contrast that to the stanza just above it that correctly
  searches for and replaces ##SELECTION_START##.

  Test case then is simply testing for no regressions:
  1. send an html mail
  2. respond to an html in html
  3. respond to an html in plain text
  4. send an email in plain text
  5. respond to a plain text email in html
  6. respond to a plain text email in plain text

  [Regression Potential]
  The regression potential is considered low since the change is minimal and 
obviously correct. In addition I personally used the patch for months (until 
upgrading to 17.04) and have several users that also use it without issue.

  == Original description ==
  From https://mail.gnome.org/archives/commits-list/2016-May/msg06756.html:

  "EHTMLEditorView - Restore the selection end mark correctly when
  processing HTML to plain text

  Otherwise the ##SELECTON_END## string could be left in the output."

  I sometimes see this from people on xenial. Patch in the commit list
  needs a light backport. I will attach a debdiff if it works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1613805/+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 1689425] Re: /usr/bin/gnome-software:11:g_source_attach:debconf_accept_cb:socket_source_dispatch:g_main_dispatch:g_main_context_dispatch

2017-05-29 Thread Launchpad Bug Tracker

This bug was fixed in the package gnome-software -
3.20.1+git20170509.0.8292905-0ubuntu1~xenial1

---
gnome-software (3.20.1+git20170509.0.8292905-0ubuntu1~xenial1) xenial; 
urgency=medium

  * New upstream snapshot from the wip/ubuntu-3-20 branch at
git://git.gnome.org/gnome-software.
- Fix crash when debconf socket fails (LP: #1689425)

 -- Robert Ancell   Tue, 09 May 2017
16:58:47 +1200

** Changed in: gnome-software (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

** Changed in: gnome-software (Ubuntu Yakkety)
   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/1689425

Title:
  /usr/bin/gnome-
  
software:11:g_source_attach:debconf_accept_cb:socket_source_dispatch:g_main_dispatch:g_main_context_dispatch

Status in gnome-software package in Ubuntu:
  Fix Released
Status in gnome-software source package in Xenial:
  Fix Released
Status in gnome-software source package in Yakkety:
  Fix Released
Status in gnome-software source package in Zesty:
  Fix Committed
Status in gnome-software source package in Artful:
  Fix Released

Bug description:
  [Impact]
  The change to add debconf support (bug 1679435) caused new crashes to occur 
in errors.ubuntu.com. The stacktrace show this crash occurring when a 
g_socket_accept generates an error. The exact cause of this failing is unknown, 
but the fix is to handle this error like any other.

  [Test Case]
  1. Run GNOME Software

  Expected result:
  Doesn't crash

  Observed result:
  Crashes reported on errors.ubuntu.com

  [Regression Potential]
  Low, we not just exit a function when an error occurs instead of crashing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1689425/+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 1686077] Re: Own org.gnome.SettingsDaemon.MediaKeys D-Bus name too

2017-05-29 Thread Launchpad Bug Tracker

This bug was fixed in the package gnome-settings-daemon -
3.24.2-0ubuntu0.1

---
gnome-settings-daemon (3.24.2-0ubuntu0.1) zesty; urgency=medium

  * New upstream release (LP: #1689610)
- Fix gdm starting with no plugins which broke Hi-DPI support
  on the login screen (LP: #1685035)
- Fix brightness control in some dual-GPU computers (LP: #1683445)
- Own the D-Bus name that the API documentation tells users of the
  multimedia keys API they should use (org.gnome.SettingsDaemon.MediaKeys),
  in addition to the D-Bus name that they actually use in practice
  (org.gnome.SettingsDaemon). (LP: #1686077)
  * Add revert-disable-rfkill-keys-handling.patch:
- Revert commit that disabled GNOME's rfkill handling. Although
  this fixes problems for some users, it makes things worse for
  other people.

 -- Jeremy Bicha   Tue, 09 May 2017 14:05:29 -0400

** Changed in: gnome-settings-daemon (Ubuntu Zesty)
   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/1686077

Title:
  Own org.gnome.SettingsDaemon.MediaKeys D-Bus name too

Status in GNOME Settings Daemon:
  Fix Released
Status in gnome-settings-daemon package in Ubuntu:
  Fix Released
Status in unity-settings-daemon package in Ubuntu:
  Triaged
Status in gnome-settings-daemon source package in Xenial:
  Triaged
Status in unity-settings-daemon source package in Xenial:
  Triaged
Status in gnome-settings-daemon source package in Yakkety:
  Triaged
Status in unity-settings-daemon source package in Yakkety:
  Triaged
Status in gnome-settings-daemon source package in Zesty:
  Fix Released
Status in unity-settings-daemon source package in Zesty:
  Triaged
Status in gnome-settings-daemon package in Debian:
  Fix Released

Bug description:
  Impact
  ==
  This bugfix enabled gnome-settings-daemon's multimedia key support to work 
according to what the API has said for years (in addition to the way it's been 
commonly used).

  https://git.gnome.org/browse/gnome-settings-
  daemon/commit/?h=gnome-3-24=42f75ed4cdc86498d6e02e511a1314b8916bd4aa

  https://mail.gnome.org/archives/desktop-devel-
  list/2017-April/msg00069.html

  The SRU justification is that newer versions of apps will be switching
  to the D-Bus name in the API documentation. If someone installs the
  newer version from a PPA or a Flatpak or Snap, the multimedia key
  support should continue working.

  Test Case
  =
  Install this update on Ubuntu GNOME.
  Reboot
  Install d-feet then run d-feet
  Switch to the session tab.
  Type 'settings' into the search box.'
  In the list of results there should be both org.gnome.SettingsDaemon and 
org.gnome.SettingsDaemon.MediaKeys with cmd: 
/usr/lib/gnome-settings-daemon/gsd-media-keys

  Regression Potential
  
  This should just make gnome(unity)-settings-daemon own both the commonly used 
D-Bus name and the one actually defined in the API docs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-settings-daemon/+bug/1686077/+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 1690730] Re: New upstream microreleases 9.3.17, 9.5.7 and 9.6.3

2017-05-29 Thread Launchpad Bug Tracker

This bug was fixed in the package postgresql-9.5 - 9.5.7-0ubuntu0.16.10

---
postgresql-9.5 (9.5.7-0ubuntu0.16.10) yakkety; urgency=medium

  * New upstream release (LP: #1690730)
- Restrict visibility of pg_user_mappings.umoptions, to protect passwords
  stored as user mapping options (CVE-2017-7486)
- Prevent exposure of statistical information via leaky operators
  (CVE-2017-7484)
- Restore libpq's recognition of the PGREQUIRESSL environment variable
  (CVE-2017-7485)

- A dump/restore is not required for those running 9.5.X.
- However, if you use foreign data servers that make use of user passwords
  for authentication, see the first changelog entry.
- Also, if you are using third-party replication tools that depend on
  "logical decoding", see the fourth changelog entry.

- Details about other changes at full changelog:
  https://www.postgresql.org/docs/9.5/static/release-9-5-7.html

 -- Christian Ehrhardt   Mon, 15 May
2017 08:46:09 +0200

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

** Changed in: postgresql-9.5 (Ubuntu Xenial)
   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/1690730

Title:
  New upstream microreleases 9.3.17, 9.5.7 and 9.6.3

Status in postgresql-9.3 package in Ubuntu:
  Triaged
Status in postgresql-9.5 package in Ubuntu:
  Triaged
Status in postgresql-9.6 package in Ubuntu:
  Triaged
Status in postgresql-9.3 source package in Trusty:
  Fix Committed
Status in postgresql-9.5 source package in Xenial:
  Fix Released
Status in postgresql-9.5 source package in Yakkety:
  Fix Released
Status in postgresql-9.6 source package in Zesty:
  Fix Released

Bug description:
  https://www.postgresql.org/about/news/1746/

  As per the standing micro-release exception these should land in
  stable Ubuntu releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-9.3/+bug/1690730/+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 1665088] Re: netplan bridge config doesn't support stp boolean

2017-05-29 Thread Mathieu Trudel-Lapierre

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

** No longer affects: ubuntu

** Also affects: nplan (Ubuntu Zesty)
   Importance: Undecided
   Status: New

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

** Also affects: nplan (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: nplan (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/1665088

Title:
  netplan bridge config doesn't support stp boolean

Status in netplan:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in nplan source package in Xenial:
  New
Status in nplan source package in Yakkety:
  New
Status in nplan source package in Zesty:
  New

Bug description:
  [Impact]
  Users of netplan may wish to specify a custom MTU value for a device.

  [Test case]
  - Run nplan integration tests on the release
  - Validate that netplan generate && netplan apply alone, without config, 
behave as expected (no result)
  - Validate that netplan generate && netplan apply with minimal config writes 
/run/NetworkManager/conf.d/10-globally-managed-devices.conf
  - Validate that netplan generate && netplan apply works with any existing 
configuation.
  - Use the config below; ensure behavior is as expected (STP value is set on 
the interface; adjust device names as appropriate). There should be no errors 
at applying the requested configuration.

  [Regression potential]
  Any failure to work with existing configuration should be considered a 
regression. Any new failure of the test suite would be a regression.

  ---

  networkd supports setting STP value in Bridge type netdevs, but
  netplan does not accept the key.

  root@ubuntu:/etc/netplan# apt-cache policy nplan
  nplan:
    Installed: 0.18
    Candidate: 0.18
    Version table:
   *** 0.18 500
  500 http://archive.ubuntu.com/ubuntu zesty/main amd64 Packages
  100 /var/lib/dpkg/status
  root@ubuntu:/etc/netplan# lsb_release -rd
  Description: Ubuntu Zesty Zapus (development branch)
  Release: 17.04

  root@ubuntu:/etc/netplan# cat 52-bridge.yaml
  network:
  ethernets:
  eth0:
  addresses:
  - 10.11.12.13/24
  match:
  macaddress: '52:54:00:12:34:00'
  set-name: foobar0
  eth1:
  match:
  macaddress: '52:54:00:12:34:02'
  set-name: eth1
  eth2:
  match:
  macaddress: '52:54:00:12:34:04'
  set-name: eth2
  bridges:
  br0:
  addresses:
  - 192.168.14.2/24
  interfaces:
  - eth1
  - eth2
  parameters:
  ageing-time: 250
  priority: 22
  forward-delay: 1
  hello-time: 1
  max-age: 10
  path-cost:
  eth1: 50
  eth2: 75
  stp: true
  version: 2

  root@ubuntu:/etc/netplan# netplan generate
  Error in network definition //etc/netplan/52-bridge.yaml line 24 column 16: 
unknown key stp

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1665088/+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 1664702] Re: No documented way to pass in bond or bridge paramters

2017-05-29 Thread Mathieu Trudel-Lapierre

** Also affects: nplan (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: nplan (Ubuntu Yakkety)
   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/1664702

Title:
  No documented way to pass in bond or bridge paramters

Status in netplan:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in nplan source package in Xenial:
  Fix Committed
Status in nplan source package in Yakkety:
  New
Status in nplan source package in Zesty:
  New

Bug description:
  [Impact]
  Documentation is important for users to know how to write the required 
configuration file for bond or bridge device parameters.

  [Test case]
  - Run nplan integration tests on the release
  - Validate that netplan generate && netplan apply alone, without config, 
behave as expected (no result)
  - Validate that netplan generate && netplan apply with minimal config writes 
/run/NetworkManager/conf.d/10-globally-managed-devices.conf
  - Validate that netplan generate && netplan apply works with any existing 
configuation.
  - Validate that documentation shipped with netplan includes information about 
the allowed parameters for bond and bridge devices (see 
/usr/share/doc/netplan/netplan.html)

  [Regression potential]
  Any failure to work with existing configuration should be considered a 
regression. Any new failure of the test suite would be a regression.

  ---

  According to the current documentation[1], there is no way to set bond
  or bridge parameters. This is a requirement for the MAAS use case.

  MAAS passes these parameters in the v1 YAML the same way as they are
  represented in /etc/network/interfaces[2], inside a 'params'
  dictionary. This allows interface type specific settings such as
  spanning-tree and bonding modes to be specified, such as:

  br0:
    params:
  bridge_stp: on
  ...
  bond0:
    params:
  bond-mode: 4

  (Note the quirk there with '-' being used for the bond and '_' for the
  bridge; this is due to to an inconsistency regarding the /e/n/i
  syntax.)

  I'm tentatively thinking of passing them in the same way, to prevent
  information loss. But perhaps this could be standardized; a 'params'
  dictionary could be used for generic OS or renderer-specific settings
  where there is no guarantee of support, but netplan could standardize
  commonly-used settings and present them in an "official" after they
  each parameter has been fully specified.

  [1]:
  https://git.launchpad.net/netplan/tree/doc/netplan.md

  [2]:
  https://wiki.debian.org/NetworkConfiguration

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1664702/+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 1631018] Re: netplan does not support globs for interface names with the NetworkManager renderer

2017-05-29 Thread Mathieu Trudel-Lapierre

** Also affects: nplan (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: nplan (Ubuntu Zesty)
   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/1631018

Title:
  netplan does not support globs for interface names with the
  NetworkManager renderer

Status in nplan package in Ubuntu:
  Fix Released
Status in nplan source package in Xenial:
  Fix Committed
Status in nplan source package in Yakkety:
  New
Status in nplan source package in Zesty:
  New

Bug description:
  [Impact]
  Documentation for netplan is misleading and may suggest that globbing is 
always possible in netplan config.

  [Test case]
  - Validate that documentation shipped with netplan points out that globbing 
is not supported in the NetworkManager renderer (see 
/usr/share/doc/netplan/netplan.html)

  [Regression potential]
  Any failure to work with existing configuration should be considered a 
regression. Any new failure of the test suite would be a regression.

  ---

  snapd creates a netplan configuration file which uses globs for
  ethernet interface names. Netplan currently does not support these as
  NetworkManager does not offer any possibility to specify globs in its
  connection files.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1631018/+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 1649616] Re: Keystone Token Flush job does not complete in HA deployed environment

2017-05-29 Thread Eric Desrochers

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

** Also affects: keystone (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: keystone (Ubuntu Zesty)
   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/1649616

Title:
  Keystone Token Flush job does not complete in HA deployed environment

Status in Ubuntu Cloud Archive:
  New
Status in OpenStack Identity (keystone):
  Fix Released
Status in puppet-keystone:
  Triaged
Status in tripleo:
  Triaged
Status in keystone package in Ubuntu:
  New
Status in keystone source package in Xenial:
  New
Status in keystone source package in Yakkety:
  New
Status in keystone source package in Zesty:
  New

Bug description:
  The Keystone token flush job can get into a state where it will never
  complete because the transaction size exceeds the mysql galara
  transaction size - wsrep_max_ws_size (1073741824).

  
  Steps to Reproduce:
  1. Authenticate many times
  2. Observe that keystone token flush job runs (should be a very long time 
depending on disk) >20 hours in my environment
  3. Observe errors in mysql.log indicating a transaction that is too large

  
  Actual results:
  Expired tokens are not actually flushed from the database without any errors 
in keystone.log.  Only errors appear in mysql.log.

  
  Expected results:
  Expired tokens to be removed from the database

  
  Additional info:
  It is likely that you can demonstrate this with less than 1 million tokens as 
the >1 million token table is larger than 13GiB and the max transaction size is 
1GiB, my token bench-marking Browbeat job creates more than needed.  

  Once the token flush job can not complete the token table will never
  decrease in size and eventually the cloud will run out of disk space.

  Furthermore the flush job will consume disk utilization resources.
  This was demonstrated on slow disks (Single 7.2K SATA disk).  On
  faster disks you will have more capacity to generate tokens, you can
  then generate the number of tokens to exceed the transaction size even
  faster.

  Log evidence:
  [root@overcloud-controller-0 log]# grep " Total expired" 
/var/log/keystone/keystone.log
  2016-12-08 01:33:40.530 21614 INFO keystone.token.persistence.backends.sql 
[-] Total expired tokens removed: 1082434
  2016-12-09 09:31:25.301 14120 INFO keystone.token.persistence.backends.sql 
[-] Total expired tokens removed: 1084241
  2016-12-11 01:35:39.082 4223 INFO keystone.token.persistence.backends.sql [-] 
Total expired tokens removed: 1086504
  2016-12-12 01:08:16.170 32575 INFO keystone.token.persistence.backends.sql 
[-] Total expired tokens removed: 1087823
  2016-12-13 01:22:18.121 28669 INFO keystone.token.persistence.backends.sql 
[-] Total expired tokens removed: 1089202
  [root@overcloud-controller-0 log]# tail mysqld.log 
  161208  1:33:41 [Warning] WSREP: transaction size limit (1073741824) 
exceeded: 1073774592
  161208  1:33:41 [ERROR] WSREP: rbr write fail, data_len: 0, 2
  161209  9:31:26 [Warning] WSREP: transaction size limit (1073741824) 
exceeded: 1073774592
  161209  9:31:26 [ERROR] WSREP: rbr write fail, data_len: 0, 2
  161211  1:35:39 [Warning] WSREP: transaction size limit (1073741824) 
exceeded: 1073774592
  161211  1:35:40 [ERROR] WSREP: rbr write fail, data_len: 0, 2
  161212  1:08:16 [Warning] WSREP: transaction size limit (1073741824) 
exceeded: 1073774592
  161212  1:08:17 [ERROR] WSREP: rbr write fail, data_len: 0, 2
  161213  1:22:18 [Warning] WSREP: transaction size limit (1073741824) 
exceeded: 1073774592
  161213  1:22:19 [ERROR] WSREP: rbr write fail, data_len: 0, 2

  
  Disk utilization issue graph is attached.  The entire job in that graph takes 
from the first spike is disk util(~5:18UTC) and culminates in about ~90 minutes 
of pegging the disk (between 1:09utc to 2:43utc).

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1649616/+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 1645324] Re: ebtables: Lock file handling has races

2017-05-29 Thread Eric Desrochers

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

** Also affects: ebtables (Ubuntu Yakkety)
   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/1645324

Title:
  ebtables: Lock file handling has races

Status in ebtables package in Ubuntu:
  Fix Released
Status in ebtables source package in Trusty:
  In Progress
Status in ebtables source package in Xenial:
  New
Status in ebtables source package in Yakkety:
  New
Status in ebtables source package in Zesty:
  Triaged
Status in ebtables source package in Artful:
  Fix Released
Status in ebtables package in Debian:
  New

Bug description:
  [Impact]

   * ebtables uses creation of a file with an exclusive flag
     as a lock to synchronize table modification when used
     with --concurrent parameter.

   * If ebtables crashes it will leave a stale lock file.
     This will prevent another copy of ebtables from running,
     and indirectly any other service that depends on ebtables
     will also be affected.

   * This change adds support for real locks that get
     cleaned up if a process exits or crashes.

  [Test Case]

   * Test Case1:
     1. $ sudo touch /var/lib/ebtables/lock"
     2. $ sudo ebtables --concurrent -L
     3. ebtables can't acquire a lock

   * Test Case 2:
     1. $ while true; do /usr/sbin/ebtables --concurrent -L; done
     2. hard reboot VM
     3. likely that the lock file is present under /var/lib/ebtables
     4. libvird hanging, try to connect to qemu:///system

  [Regression Potential]

   * Normal Use:
     There is no regression potential during normal use and
     operation of ebtables.

   * Package Upgrade:
     There is a very very small regression potential during the package
     upgrade to the latest version. Once the package is upgraded that
     potential is gone. It is a very small potential because several
     things have to happen in a very small time frame and in an exact
     order since ebtables is not a resident program like a daemon:
   1. ebtables is launched during package upgrade AND
   2. new ebtables binary has not yet been written to disk AND
   3. it is launched with --concurent switch AND
   4. another ebtables with new binary is launched AND
   5. it is launched with --concurent switch AND
   6. the first ebtables copy hasn't exited yet AND
   7. both copies of ebtables are launched with a WRITE command AND
   8. both copies of ebtables are manipulating the same resource.
     Then one of the binaries could potentially fail, but once the old
     binary exits the potential is gone so subsequent re-runs of
     ebtables will succeed.

  * Dragan's patch has been submitted to Debian via :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860590

  * Note that the ebtables upstream project is nearly dead. Nowadays,
  all the development is now happening in nft project which is intended
  to be replacement.

  
  [Original Text]
  libvirtd is hanging after startup due to ebtables lock file -from an earlier 
run- remains intact when the system reboots.
  Same issue is happening than it is reported here: 
https://bugzilla.redhat.com/show_bug.cgi?id=1290327 when the system boots.

  After booting the system, It's not possible connect to the qemu-service.
  - libvirt daemon tried to obtain a lock:
  [pid 20966] read(24, "Trying to obtain lock /var/lib/e"..., 1024) = 45
  [pid 20966] poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2, 
4294967295) = 1 ([{fd=24, revents=POLLIN}])
  [pid 20966] read(24, "Trying to obtain lock /var/lib/e"..., 1024) = 45
  [pid 20966] poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2, 
4294967295) = 1 ([{fd=24, revents=POLLIN}])
  [pid 20966] read(24, "Trying to obtain lock /var/lib/e"..., 1024) = 45
  [pid 20966] poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2, 
4294967295^CProcess 20916 detached

  - there was a file named 'lock' in /var/lib/ebtables directory with timestamp 
14:54
  - ebtables was configured:
  * Ebtables support available, number of installed rules [ OK ]
  (other nodes appeared to be in the same state from ebtables point of view, 
but without the lock file)
  - I removed the lock file and libvirt started to work instantly - the lock 
obtain messages have disappeared from the trace and virsh commands are working
  - at 14:54 the host was booting up. According to the logs, there were other 
reboots after that one, but the lock file remained intact (at least the 
timestamp was not updated).

  Could you please suggest a solution to be sure that ebtables lock file
  is removed during boot?

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

___
Mailing

[Group.of.nepali.translators] [Bug 1573272] Re: default gateway route not installed for bond interfaces through reboot

2017-05-29 Thread Mathieu Trudel-Lapierre

** Changed in: vlan (Ubuntu Artful)
   Status: Fix Released => 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/1573272

Title:
  default gateway route not installed for bond interfaces through reboot

Status in vlan package in Ubuntu:
  New
Status in vlan source package in Trusty:
  Fix Committed
Status in vlan source package in Xenial:
  Fix Committed
Status in vlan source package in Yakkety:
  Fix Committed
Status in vlan source package in Zesty:
  Fix Committed
Status in vlan source package in Artful:
  New
Status in vlan package in Debian:
  New

Bug description:
  [Impact]

  Systems using vlans, especially those using vlans on top of bond
  interfaces, in addition to default or other routes on the vlans, may
  find their vlan routes are not present at boot.

  The attached debdiff patches fix the vlan package's /etc/network/if-
  pre-up.d/vlan script.  Currently, the script will bring up a vlan's
  raw device if needed; but the problem is if the vlan's ifup processing
  happens before the raw device's ifup processing, the raw device may be
  taken down and back up (especially for bonds), and when the raw device
  is taken down, the vlan is as well, and thus loses all its routing
  configuration.  Instead of only bringing the raw device up using ip
  link up, the patch changes the vlan script to do a full ifup on the
  raw device, so it will remain up after the vlan is configured.

  [Test Case]

  Set up a system using two interfaces configured into a bond interface,
  with a vlan on top of that bond.  Add a default route and/or specific
  routes to the vlan interface.  Then edit the system as described in
  comment 8, and reboot.  The vlan's routes will not be present in the
  system.

  [Regression Potential]

  Any modifications to ifupdown or the scripts it uses may cause wider
  problems with network configuration.  Specifically, this could cause
  problems when using vlan interfaces, as it forces every vlan's raw
  device interface to be fully ifup'ed before the vlan interface can
  finish its ifup.

  [Other Info]

  original description below:

  
  Expectation:  After reboot, route for default gateway specified on bonded 
interface is installed according to "gateway x.x.x.x"  (where x.x.x.x is a 
valid IPv4 address) specified in /etc/network/interfaces or files sourced per 
/etc/network/interfaces

  Actual Result: After reboot, route is not installed. Interface does
  work otherwise (I can ping the gateway on that subnet, for instance).
  'ifdown -a' followed by  'ifup -a' (run with proper permission... so
  sudo) brings the gateway back until next reboot.

  Package:  I'm not familiar enough to be certain what is causing this,
  but I was seeing this in beta2 of 16.04 as well.

  *username snipped*@*hostname snipped*:~$ lsb_release -rd
  Description:Ubuntu 16.04 LTS
  Release:16.04
  *username snipped*@*hostname snipped*:~$ apt-cache policy ifenslave
  ifenslave:
    Installed: 2.7ubuntu1
    Candidate: 2.7ubuntu1
    Version table:
   *** 2.7ubuntu1 100
  100 /var/lib/dpkg/status

  *username snipped*@*hostname snipped*:~$ apt-cache policy ifupdown
  ifupdown:
    Installed: 0.8.10ubuntu1
    Candidate: 0.8.10ubuntu1
    Version table:
   *** 0.8.10ubuntu1 100
  100 /var/lib/dpkg/status

    /etc/network/interfaces

  --
  # This file describes the network interfaces available on your system
  # and how to activate them. For more information, see interfaces(5).

  source /etc/network/interfaces.d/*

  # The loopback network interface
  auto lo
  iface lo inet loopback

  # The primary network interface
  auto enp2s0f1
  iface enp2s0f1 inet manual
  bond-master bond0

  auto enp2s0f0
  iface enp2s0f0 inet manual
  bond-master bond0

  auto bond0
  iface bond0 inet static
  address 10.96.96.2
  netmask 255.255.255.0
  network 10.96.96.0
  broadcast 10.96.96.255
  # dns-* options are implemented by the resolvconf package, if 
installed
  dns-search *snip*
  bond-mode balance-alb
  bond-slaves none
  bond-miimon 100
  auto bond0.3000
  iface bond0.3000 inet static
  address 172.21.33.29
  netmask 255.255.255.0
  network 172.21.33.0
  broadcast 172.21.33.255
  gateway 172.21.33.1
  dns-search *snip*
  vlan-raw-device bond0
  dns-nameservers 172.31.10.84 8.8.8.8 4.2.2.2

  -
  interfaces.d is empty:

  *username snipped*@*hostname snipped*:~$ ls -lisah /etc/network/interfaces.d
  total 8.0K
  10748247 4.0K drwxr-xr-x 2 root root 4.0K Jan 24 14:08 .
  10748237 4.0K drwxr-xr-x 7 root root 4.0K Apr 21 17:32 ..

To manage notifications about this bug go to:

[Group.of.nepali.translators] [Bug 1573272] Re: default gateway route not installed for bond interfaces through reboot

2017-05-29 Thread Launchpad Bug Tracker

This bug was fixed in the package vlan - 1.9-3.2ubuntu4

---
vlan (1.9-3.2ubuntu4) artful; urgency=medium

  * Correct previous patch, to work for ifupdown configuration where a
vlan is configured but the vlan's raw device has no ifupdown config.
(LP: #1573272)

 -- Dan Streetman   Mon, 29 May 2017
18:13:27 -0400

** Changed in: vlan (Ubuntu Artful)
   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/1573272

Title:
  default gateway route not installed for bond interfaces through reboot

Status in vlan package in Ubuntu:
  Fix Released
Status in vlan source package in Trusty:
  Fix Committed
Status in vlan source package in Xenial:
  Fix Committed
Status in vlan source package in Yakkety:
  Fix Committed
Status in vlan source package in Zesty:
  Fix Committed
Status in vlan source package in Artful:
  Fix Released
Status in vlan package in Debian:
  New

Bug description:
  [Impact]

  Systems using vlans, especially those using vlans on top of bond
  interfaces, in addition to default or other routes on the vlans, may
  find their vlan routes are not present at boot.

  The attached debdiff patches fix the vlan package's /etc/network/if-
  pre-up.d/vlan script.  Currently, the script will bring up a vlan's
  raw device if needed; but the problem is if the vlan's ifup processing
  happens before the raw device's ifup processing, the raw device may be
  taken down and back up (especially for bonds), and when the raw device
  is taken down, the vlan is as well, and thus loses all its routing
  configuration.  Instead of only bringing the raw device up using ip
  link up, the patch changes the vlan script to do a full ifup on the
  raw device, so it will remain up after the vlan is configured.

  [Test Case]

  Set up a system using two interfaces configured into a bond interface,
  with a vlan on top of that bond.  Add a default route and/or specific
  routes to the vlan interface.  Then edit the system as described in
  comment 8, and reboot.  The vlan's routes will not be present in the
  system.

  [Regression Potential]

  Any modifications to ifupdown or the scripts it uses may cause wider
  problems with network configuration.  Specifically, this could cause
  problems when using vlan interfaces, as it forces every vlan's raw
  device interface to be fully ifup'ed before the vlan interface can
  finish its ifup.

  [Other Info]

  original description below:

  
  Expectation:  After reboot, route for default gateway specified on bonded 
interface is installed according to "gateway x.x.x.x"  (where x.x.x.x is a 
valid IPv4 address) specified in /etc/network/interfaces or files sourced per 
/etc/network/interfaces

  Actual Result: After reboot, route is not installed. Interface does
  work otherwise (I can ping the gateway on that subnet, for instance).
  'ifdown -a' followed by  'ifup -a' (run with proper permission... so
  sudo) brings the gateway back until next reboot.

  Package:  I'm not familiar enough to be certain what is causing this,
  but I was seeing this in beta2 of 16.04 as well.

  *username snipped*@*hostname snipped*:~$ lsb_release -rd
  Description:Ubuntu 16.04 LTS
  Release:16.04
  *username snipped*@*hostname snipped*:~$ apt-cache policy ifenslave
  ifenslave:
    Installed: 2.7ubuntu1
    Candidate: 2.7ubuntu1
    Version table:
   *** 2.7ubuntu1 100
  100 /var/lib/dpkg/status

  *username snipped*@*hostname snipped*:~$ apt-cache policy ifupdown
  ifupdown:
    Installed: 0.8.10ubuntu1
    Candidate: 0.8.10ubuntu1
    Version table:
   *** 0.8.10ubuntu1 100
  100 /var/lib/dpkg/status

    /etc/network/interfaces

  --
  # This file describes the network interfaces available on your system
  # and how to activate them. For more information, see interfaces(5).

  source /etc/network/interfaces.d/*

  # The loopback network interface
  auto lo
  iface lo inet loopback

  # The primary network interface
  auto enp2s0f1
  iface enp2s0f1 inet manual
  bond-master bond0

  auto enp2s0f0
  iface enp2s0f0 inet manual
  bond-master bond0

  auto bond0
  iface bond0 inet static
  address 10.96.96.2
  netmask 255.255.255.0
  network 10.96.96.0
  broadcast 10.96.96.255
  # dns-* options are implemented by the resolvconf package, if 
installed
  dns-search *snip*
  bond-mode balance-alb
  bond-slaves none
  bond-miimon 100
  auto bond0.3000
  iface bond0.3000 inet static
  address 172.21.33.29
  netmask 255.255.255.0
  network 172.21.33.0
  broadcast 172.21.33.255
  gateway 172.21.33.1
  dns-search *snip*
  vlan-raw-device bond0
  dns-nameservers 172.31.10.84

[Group.of.nepali.translators] [Bug 1482893] Re: common loader in catalina.properties is wrong

2017-05-29 Thread Mathew Hodson

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

** Changed in: tomcat8 (Ubuntu)
   Status: Fix Committed => Fix Released

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

** Changed in: tomcat8 (Ubuntu Yakkety)
   Importance: Undecided => Medium

** No longer affects: tomcat6 (Ubuntu)

** No longer affects: tomcat6 (Ubuntu Yakkety)

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

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

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

** Changed in: tomcat7 (Ubuntu Yakkety)
   Importance: Undecided => Medium

** Changed in: tomcat8 (Ubuntu Xenial)
   Status: In Progress => Triaged

** Changed in: tomcat8 (Ubuntu Yakkety)
   Status: In Progress => 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/1482893

Title:
  common loader in catalina.properties  is wrong

Status in tomcat7 package in Ubuntu:
  New
Status in tomcat8 package in Ubuntu:
  Fix Released
Status in tomcat6 source package in Xenial:
  New
Status in tomcat7 source package in Xenial:
  New
Status in tomcat8 source package in Xenial:
  Triaged
Status in tomcat7 source package in Yakkety:
  New
Status in tomcat8 source package in Yakkety:
  Triaged
Status in tomcat7 package in Debian:
  New
Status in tomcat8 package in Debian:
  Fix Released

Bug description:
  [Impact]

  * The order of paths in common.loader does not follow the upstream
  tomcat recommendations. This can lead to unexpected behavior.

  [Test Case]

  * The broken tomcat8 will have

  
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.home}/common/classes,${catalina.home}/common/*.jar

  while the corrected version will have

  
common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.base}/common/classes","${catalina.base}/common/*.jar","${catalina.home}/common/classes","${catalina.home}/common/*.jar"

  in catalina.properties.

  [Regression Potential]

  * The primary source of regressions would be end-users relying on the
  old path order and thus getting a different class loaded with the
  'fixed' version. However, the Ubuntu order is unspecified as being
  stable, and is contradictory to the public documentation.

  Please fix the following line in catalina.properties in all tomcat
  source packages.

  WRONG:
  
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.home}/common/classes,${catalina.home}/common/*.jar

  CORRECT:
  
common.loader=${catalina.base}/common/classes,${catalina.base}/common/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar

  Following problems with the wrong statement:
  1. Odering is wrong: catalina.base should overrule catalina.home here (see 
class loader howto below).
  2. catalina.home is expanded normally to /usr/share/tomcat7, but there is no 
common directory - it is below
  /var/lib/tomcat7 (as expanded by catalina.base).
  3. ${catalina.base}/lib,${catalina.base}/lib/*.jar are pointing to non 
existing directories.  I recommend to skip this part.

  For reference see 
https://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html
  > The locations searched by this class loader are defined by the 
common.loader property in
  > $CATALINA_BASE/conf/catalina.properties.
  > The default setting will search the following locations in the order they 
are listed:
  >
  >unpacked classes and resources in $CATALINA_BASE/lib
  >JAR files in $CATALINA_BASE/lib
  >unpacked classes and resources in $CATALINA_HOME/lib
  >JAR files in $CATALINA_HOME/lib

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tomcat7/+bug/1482893/+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 1670036] Re: Misapplied patches in 4.0.6-2ubuntu0.1 break reading and writing JPEG compressed files

[Group.of.nepali.translators] [Bug 1672740] Re: Netplan replug function is incompatible with ath9k_htc module

[Group.of.nepali.translators] [Bug 1688632] Re: nplan 0.21 update

[Group.of.nepali.translators] [Bug 1691186] Re: linux-gke: 4.4.0-1014.14 -proposed tracker

[Group.of.nepali.translators] [Bug 1690730] Re: New upstream microreleases 9.3.17, 9.5.7 and 9.6.3

[Group.of.nepali.translators] [Bug 1692590] Re: linux-hwe: 4.8.0-54.57~16.04.1 -proposed tracker

[Group.of.nepali.translators] [Bug 1672175] Re: gnome-shell should recommend chrome-gnome-shell

[Group.of.nepali.translators] [Bug 1613805] Re: [evolution/wip/webkit2] EHTMLEditorView - Restore the selection end mark correctly when processing HTML to plain text

[Group.of.nepali.translators] [Bug 1689425] Re: /usr/bin/gnome-software:11:g_source_attach:debconf_accept_cb:socket_source_dispatch:g_main_dispatch:g_main_context_dispatch

[Group.of.nepali.translators] [Bug 1686077] Re: Own org.gnome.SettingsDaemon.MediaKeys D-Bus name too

[Group.of.nepali.translators] [Bug 1690730] Re: New upstream microreleases 9.3.17, 9.5.7 and 9.6.3

[Group.of.nepali.translators] [Bug 1665088] Re: netplan bridge config doesn't support stp boolean

[Group.of.nepali.translators] [Bug 1664702] Re: No documented way to pass in bond or bridge paramters

[Group.of.nepali.translators] [Bug 1631018] Re: netplan does not support globs for interface names with the NetworkManager renderer

[Group.of.nepali.translators] [Bug 1649616] Re: Keystone Token Flush job does not complete in HA deployed environment

[Group.of.nepali.translators] [Bug 1645324] Re: ebtables: Lock file handling has races

[Group.of.nepali.translators] [Bug 1573272] Re: default gateway route not installed for bond interfaces through reboot

[Group.of.nepali.translators] [Bug 1573272] Re: default gateway route not installed for bond interfaces through reboot

[Group.of.nepali.translators] [Bug 1482893] Re: common loader in catalina.properties is wrong

19 matches

Site Navigation

Mail list logo

Footer information