On Tue, Jun 30, 2015 at 10:19:08PM +0200, Guus Sliepen wrote:
> Yes I did, and it doesn't work correctly yet. So I'm planning to make it
> so when it tries to ifup a VLAN interface, it first tries to lock the
> physical interface it wants to create a VLAN on. I haven't finished that
> yet, but I'll
as this
was the case affecting the deployment I was interested in.
Please let me know what you think about it.
Thanks,
Dariusz Gadomski
# HG changeset patch
# User Dariusz Gadomski
# Date 1433853683 -7200
# Tue Jun 09 14:41:23 2015 +0200
# Branch hierarchical-lock
# Node ID
ly no other modifications
to ifupdown are needed in the scenario I need to handle. If it does
not - I will try to alter my current implementation to use
per-interface stanzas.
> --
> Met vriendelijke groet / with kind regards,
> Guus Sliepen
Regards,
Dariusz Gadomski
signature.asc
Description: Digital signature
On Tue, Jun 16, 2015 at 03:40:04PM +0200, Guus Sliepen wrote:
> But is it just ifup running in parallel, or is there also an
> ifup -a running at the same time?
According to my observations there is a single ifup call for
each interface and additionally there is a ifup -a called from another
scr
Hello Guus!
On Tue, Jun 16, 2015 at 03:40:04PM +0200, Guus Sliepen wrote:
> Hm, looking at the code I don't think so, since a VLAN interface still
> runs "ip link set dev bondX up", which may mess with the
> if-pre-up.d/ifenslave script. I'll do some tests with the concurrency
> branch and VLANs o
On Tue, Jun 30, 2015 at 10:19:08PM +0200, Guus Sliepen wrote:
> Yes I did, and it doesn't work correctly yet. So I'm planning to make it
> so when it tries to ifup a VLAN interface, it first tries to lock the
> physical interface it wants to create a VLAN on. I haven't finished that
> yet, but I'll
Hello Ken.
Thank you for looking into this issue. I fully agree with the approach
to reuse as much of the existing QA infrastructure as possible.
> I am unfamiliar with autopkgtests, could you please describe:
> - the goals of autopkgtests (specifically what level of testing confidence is
> aime
Package: pcp
Version: 3.12.0
There is an effort ongoing to make pcp included in the main component
of the Ubuntu 17.10 release (this may be tracked at [1]).
As a part of this effort we want to improve the quality of the
packaging by integrating autopkgtest and debian/watch file for this
package.
autopkgtests and d/watch. (closes: #871254)
+
+ -- Dariusz Gadomski Thu, 03 Aug 2017
10:37:04 +0200
+
pcp (3.12.0) unstable; urgency=low
* New release (full details in CHANGELOG).
diff -Nru pcp-3.12.0/debian/tests/check_cli_tools.py
pcp-3.12.0/debian/tests/check_cli_tools.py
--- pcp-3.12.0
Package: libgtk-3-0
Version: 3.22.4-1
Severity: normal
Trying to run a gtk-based application that does not depend directly or
indirectly on libgl1-mesa-glx leads to a process termination with
message:
Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No
such file or directory
Looks like this behaviour was introduced with a change to cairo
in version 1.12.16-4 [1]. So looks like gtk was depending on being
linked to libGL.so indirectly via cairo.
So, any of the below should fix it:
1) Re-enable GL/EGL support in cairo.
2) Add libgl1-mesa-glx as a dependency of gtk.
3) [u
On Fri, Dec 09, 2016 at 05:44:16PM +, D. B. wrote:
> #2 seems like the superior option, right?
I agree, yes.
If there is no need of re-enabling gl in cairo then #2 is the best way to go
since GTK+ calls it directly.
@@ -1,3 +1,9 @@
+gtk+3.0 (3.22.6-2) unstable; urgency=medium
+
+ * Add libgl1 to dependencies. (Closes: #847366)
+
+ -- Dariusz Gadomski Tue, 17 Jan 2017
11:19:18 +0100
+
gtk+3.0 (3.22.6-1) unstable; urgency=medium
[ Jeremy Bicha ]
diff -Nru gtk+3.0-3.22.6/debian/control gtk+3.0-3.22.6/debian
: #1782152)
This issue has been fixed upstream:
https://gitlab.gnome.org/GNOME/gdm/issues/399
Thanks for considering the patch.
Dariusz Gadomski
-- System Information:
Debian Release: buster/sid
APT prefers bionic-updates
APT policy: (500, 'bionic-updates'), (500, 'bionic-security&#x
Source: sysstat
Version: 11.6.0-1
Severity: normal
Dear Maintainer,
This is related to bug #872926. The patch applied to the original bug
contains only half of the upstream fix: get_filesystem_nr in count.c, while
the upstream also considered it's worth to patch the other potential source
of a se
Package: sysstat
Version: 11.6.0-1
Followup-For: Bug #883863
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did yo
Source: open-vm-tools
Version: 2:10.2.0-2
Severity: normal
Dear Maintainer,
The tools.conf template shipped with the Debian package
(debian/local/tools.conf) is incorrect.
It's current contents:
bindir = "/usr/bin"
do not mean anything to open-vm-tools - it's not interpreted in any way by
vmto
This is an alternative I recommend (based on the comment from
open-vm-tools/lib/include/vmware/tools/log.h)
tools.conf
[logging]
# Turns on logging globally. It can still be disabled for each domain.
# log = true
# Disables core dumps on fatal errors; they're enabled by default.
# enabl
Hi Bernd,
Thanks for taking care of this.
> good catch, will be shipped with the next upload.
Btw. could you give me any estimate about when the next upload may
take place?
Ideally, if it happens before March 1 (according to [1]) it would be
automatically imported to Ubuntu as well.
[1]: https:
' in Gnome
settings after connecting a fairly new display/TV.
I'd appreciate syncing with upstream.
Thank you,
Dariusz Gadomski
-- System Information:
Debian Release: buster/sid
APT prefers bionic-updates
APT policy: (500, 'bionic-updates'), (500, 'bionic-security
20 matches
Mail list logo
