Since the basic issue is understood in bash vs gnu kill implementation
IMHO there is no reason to carry an Ubuntu delta just for that.
I still want it properly fixed one day, and not just explained.
As far as it looks right now this seems to become part of bash 4.4.
Which means this bug will
FYI - the merge itself would be complete, but while testing I found an issue
introduced in some former ubuntu delta that would now kill the configuration of
an already installed nis on update (bad handling of conffiles).
We will have to create a fix for this transition before we can go on with
FYI - the merge itself would be complete, but while testing I found an issue
introduced in some former ubuntu delta that would now kill the configuration of
an already installed nis on update (bad handling of conffiles).
We will have to create a fix for this transition before we can go on with
** Description changed:
*** Still processing FFE and filling in the template ***
[Availability]
The source code is available from: git://dpdk.org/dpdk
General information: http://dpdk.org
The package is already part of universe and builds for the target
architecture
** Patch added: "fix-bug-1516543.diff"
https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/1516543/+attachment/4520134/+files/fix-bug-1516543.diff
** Changed in: dpdk (Ubuntu)
Status: Triaged => Fix Committed
** Changed in: dpdk (Ubuntu)
Assignee: ChristianEhrh
** Changed in: dpdk (Ubuntu)
Assignee: (unassigned) => ChristianEhrhardt (paelzer)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1516543
Title:
dpdk-init depends on executables in /usr/
Patch submitted to the repository, here FYI.
Stefan do you take this over then?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1516543
Title:
dpdk-init depends on executables in /usr/bin
To manage
** Description changed:
*** Still processing FFE and filling in the template ***
[Availability]
The source code is available from: git://dpdk.org/dpdk
General information: http://dpdk.org
+ The package is already part of universe and builds for the target
architecture
I dropped the merge proposal for wily since it would even be a SRU now.
I'll follow up on the upstreaming of bash which in the meantime made it to the
archive at
https://lists.gnu.org/archive/html/bug-bash/2015-10/msg4.html
--
You received this bug notification because you are a member of
Some initial analysis to support further decisions
Version check
Version upstream
4.2.8p4 2015/10/21
Latest versions in Ubuntu
1:4.2.6.p3+dfsg-1ubuntu3.6 | precise-security
1:4.2.6.p5+dfsg-3ubuntu2.14.04.5 | trusty-security
1:4.2.6.p5+dfsg-3ubuntu6.2 | vivid-security
Some initial analysis to support further decisions
Version check
Version upstream
4.2.8p4 2015/10/21
Latest versions in Ubuntu
1:4.2.6.p3+dfsg-1ubuntu3.6 | precise-security
1:4.2.6.p5+dfsg-3ubuntu2.14.04.5 | trusty-security
1:4.2.6.p5+dfsg-3ubuntu6.2 | vivid-security
** Changed in: nis (Ubuntu)
Assignee: (unassigned) => ChristianEhrhardt (paelzer)
** Changed in: nis (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
** Changed in: nis (Ubuntu)
Assignee: (unassigned) => ChristianEhrhardt (paelzer)
** Changed in: nis (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchp
FYI - After a discussion I'll likely revamp the patches for wily and upstream
the next days.
Until then we will also decide if this is worth SRUs for trusty/vivid.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
FYI - After a discussion I'll likely revamp the patches for wily and upstream
the next days.
Until then we will also decide if this is worth SRUs for trusty/vivid.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
** Patch added: "Fix for wily"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674/+attachment/4486127/+files/wily_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "Fix for upstream"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674/+attachment/4486128/+files/upstream_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
Other MOTD plugins use caching, for example
/usr/lib/update-notifier/update-motd-reboot-required does:
if [ -f /var/run/reboot-required ]; then
cat /var/run/reboot-required
fi
Actually /usr/lib/update-notifier/update-motd-updates-available already uses
"caching" like the others.
It
** Patch added: "Fix for vivid"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674/+attachment/4486126/+files/vivid_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
** Patch added: "Fix for trusty"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674/+attachment/4486125/+files/trusty_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
** Patch added: "Fix for upstream"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674/+attachment/4486128/+files/upstream_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Other MOTD plugins use caching, for example
/usr/lib/update-notifier/update-motd-reboot-required does:
if [ -f /var/run/reboot-required ]; then
cat /var/run/reboot-required
fi
Actually /usr/lib/update-notifier/update-motd-updates-available already uses
"caching" like the others.
It
** Patch added: "Fix for wily"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674/+attachment/4486127/+files/wily_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
** Patch added: "Fix for vivid"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674/+attachment/4486126/+files/vivid_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "Fix for trusty"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674/+attachment/4486125/+files/trusty_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Here the bigger, but more architecturally complete solution for
wily (which is actually identical at this time).
Summary:
- move the actual updating part out of the pam based trigger completely (avoids
slowdown)
- pam based motd now only prints the cached info (if existing)
- hook into apt with
Here the bigger, but more architecturally complete solution for
wily (which is actually identical at this time).
Summary:
- move the actual updating part out of the pam based trigger completely (avoids
slowdown)
- pam based motd now only prints the cached info (if existing)
- hook into apt with
** Patch added: "Enhanced fix for Wily and Upstream"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674/+attachment/4487279/+files/wily_and_dev_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the
** Patch added: "Enhanced fix for Wily and Upstream"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674/+attachment/4487279/+files/wily_and_dev_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi AZ,
thanks for your feedback.
>> IMHO if something overloads your machine with disk I/O it has to stall it.
> This is a bit tricky, because overload means that the machine will be able
> not complete all task in the time given, i.e. tasks will accumulate until the
> resources are exhausted.
Martin:
- I already removed one indirection with my former patch and love to remove one
more.
Simple code = good code - thanks for the good hint.
- I changed it slightly to use the existing variable so people recognize from
which code
it came and to avoid issues if one ever changes only one
** Patch added: "Enhanced fix for Wily and Upstream (version 3)"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674/+attachment/4489492/+files/wily_and_dev_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
** Patch added: "Enhanced fix for Wily and Upstream (version 3)"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674/+attachment/4489492/+files/wily_and_dev_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Martin:
- I already removed one indirection with my former patch and love to remove one
more.
Simple code = good code - thanks for the good hint.
- I changed it slightly to use the existing variable so people recognize from
which code
it came and to avoid issues if one ever changes only one
snmp and snmpd are part of one source being: net-snmp
I could confirm that this still affects wily/upstream
The killall was introduced way back by
* debian/snmp.preinst, debian/snmp.prerm: kill any/all processes owned by
snmp user before install/uninstall, LP: #573391
-- Dustin Kirkland
snmp and snmpd are part of one source being: net-snmp
I could confirm that this still affects wily/upstream
The killall was introduced way back by
* debian/snmp.preinst, debian/snmp.prerm: kill any/all processes owned by
snmp user before install/uninstall, LP: #573391
-- Dustin Kirkland
** Patch added: "debdiff for wily and upstream"
https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1245604/+attachment/4489741/+files/wily_and_dev_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
** Patch added: "debdiff for wily and upstream"
https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1245604/+attachment/4489741/+files/wily_and_dev_package.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The parameter parsing for the bash builtins is based on this:
#define ISOPTION(s, c) (s[0] == '-' && !s[2] && s[1] == c)
In addition the -- is used to recognize negative numbers to signify
process groups instead of just a process.
This is rather unusable for lonopts, but at least the -L could
** Patch added: "Add -L option to bash builtin of kill to be more compatible to
procps version of kill"
https://bugs.launchpad.net/hundredpapercuts/+bug/1488939/+attachment/4479983/+files/bash-make-kill-more-procops-compatible.patch
--
You received this bug notification because you are a
>From the procps man page:
The -L flag is Linux-specific.
Also I would expect that the long options might be special or new, so
I'm not sure how willing bash will be to take a modification for this.
BTW - these are the allowed parameters from the bash Doc
Options:
-s sigSIG is a
I wanted to fix it in the procps package where kill belongs to.
But there everything is ok, like:
.libs/kill -l
HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT
CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH POLL PWR SYS
.libs/kill --list
HUP INT QUIT
** Patch added: "gracefully handle empty ppa spec"
https://bugs.launchpad.net/hundredpapercuts/+bug/1405950/+attachment/4480820/+files/bug-1405950-gracefullyhandle-empty-ppa-spec.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This code went through several major overhauls, so I won't try to fix them all.
As I already stated the last LTS 14.04.3 is already fine.
I provide a patch just for the most recent - currently being
upstream/wily which should ensure the issue doesn't come back once more.
--
You received this
It might not be good to stir up such an old bug, but it gets regularly
updated and new complains so maybe a new approach might help.
So let us make one thing clear, IMHO if something overloads your machine with
disk I/O it has to stall it.
So the solutions paths are more like this:
a) beat it
Interesting, there must be a fix out there somewhere - but so far I find
it rather unclear where it is included.
On Ubuntu 14.04.3 LTS with software-properties-common 0.92.37.5 it works in
the requested way:
=> sudo apt-add-repository ppa:
Cannot add PPA: 'ppa:'.
Please check that the PPA name
** Patch removed: "Add -L option to bash builtin of kill to be more compatible
to procps version of kill"
https://bugs.launchpad.net/hundredpapercuts/+bug/1488939/+attachment/4479983/+files/bash-make-kill-more-procops-compatible.patch
** Patch added: "Add -L option to bash builtin of kill to
I proposed a merge including my fix for further review
(https://code.launchpad.net/~paelzer/ubuntu/wily/bash/fix-
for-1488939/+merge/272916) and also started a discussion at bug-
b...@gnu.org to get their feedback regarding changing options. I will
add a link to the thread once it shows up in the
As described by Robie versions are:
precise: n/a
trusty: n/a
vivid: 1.53+2014.06.08.git.918
wily: 1.56-1
To reproduce the issue I installed the tool and wrote a minimal test
wrapper based on online examples - and hey it is fairly short (not even
worth an attachment).
#!/usr/bin/env python3
** Patch added: "backport of the fix that was upstream in python3-memcache 1.54"
https://bugs.launchpad.net/ubuntu/+source/python-memcache/+bug/1492604/+attachment/4484805/+files/fix-python3-memcache-str-handling-rebase1.53.diff
--
You received this bug notification because you are a member
I can confirm that with this as backport applied the testcase runs fine.
** Changed in: python-memcache (Ubuntu)
Status: New => In Progress
** Changed in: python-memcache (Ubuntu)
Assignee: (unassigned) => ChristianEhrhardt (paelzer)
--
You received this bug notification b
** Patch added: "backport of the fix that was upstream in python3-memcache 1.54"
https://bugs.launchpad.net/ubuntu/+source/python-memcache/+bug/1492604/+attachment/4484805/+files/fix-python3-memcache-str-handling-rebase1.53.diff
--
You received this bug notification because you are a member
As described by Robie versions are:
precise: n/a
trusty: n/a
vivid: 1.53+2014.06.08.git.918
wily: 1.56-1
To reproduce the issue I installed the tool and wrote a minimal test
wrapper based on online examples - and hey it is fairly short (not even
worth an attachment).
#!/usr/bin/env python3
I can confirm that with this as backport applied the testcase runs fine.
** Changed in: python-memcache (Ubuntu)
Status: New => In Progress
** Changed in: python-memcache (Ubuntu)
Assignee: (unassigned) => ChristianEhrhardt (paelzer)
--
You received this bug notification b
The fix for "CONFIG_RTE_BUILD_COMBINE_LIBS + LIBRTE_PMD_XENVIRT" that went
upstream was mine :-)
I didn't retry the 32bit buld since then, but I did not see a fix for that
on the list yet.
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
On Tue, Dec 8, 2015 at 12:49 PM, Thiago
Hi Thiago,
Yes as of now it seems that the 32bit build issue is the only issue
blocking me currently to enable XEN_PMD in the build.
If you could get a fix to that to upstream to DPDK I think I can pick it up
and use it to enable XEN_PMD in the next version of the package.
In the worst case it
Hi,
I was able to identify the underlying issue of the build problem with
LIBRTE_PMD_XENVIRT & COMBINE_LIBS.
There is a much simpler fix than what was suggested to you for this specific
issue.
I submitted it to dpdk-dev =>
http://dpdk.org/ml/archives/dev/2015-December/029246.html
Since it is a
Building on i386 instead of amd64 reveal issues in the XEN_PMD code that might
force me to drop the enablement.
I'll have a look if it is simple.
** Changed in: dpdk (Ubuntu)
Status: Fix Committed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I reported the build issue at dpdk-dev =>
http://dpdk.org/ml/archives/dev/2015-December/029261.html
I'm not really willing to carry any super-special "only build it in
amd64" delta just for that.
Waiting on your (Thiago) and upstream responses to decide how to
proceed.
--
You received this bug
Hi Thiago,
good news.
I wanted to let you know that the following fixes that went into the release of
DPDK 2.2:
- 539ed5f8 mk: fix combined library build with Xen driver (my patch)
- f17230e1 xenvirt: fix build for 32-bit platform (thanks to Huawei Xie for
that one)
together seem to be
Hi Seth,
much of the code should be still similar.
But making you aware that such an upgrade might come was just the point of
my mail.
The final decision 2.0/2.1/2.2 which way we will go will be taken on the
sprint next week.
I'll let you know asap then.
Am 05.01.2016 01:35 schrieb "Seth Arnold"
Eventually the async apt-check is to avoid stalling humans, and there it
makes total sense.
We could think to do something like
function checkit {
*code of the check*
}
if [[ $- == *i* ]];
then
checkit &
else
checkit
fi
That would cause the check to be synchronous (as it was in the
debdiff to show the suggested change, this is in no way an upload to be
sponsored yet as it needs way more testing.
Just FYI so you see what was changed
** Patch added: "xenial_update-notifier.debdiff"
deb for testing the approach, not very large so we can just attach it.
** Attachment added: "update-notifier-common_3.165_all.deb"
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1527710/+attachment/4537009/+files/update-notifier-common_3.165_all.deb
--
You received this bug
Hi Thiago,
if you want to experiment with it, there is a - yet unstable - preview of DPDK
2.2 with xen pmd enabled at
https://launchpad.net/~paelzer/+archive/ubuntu/dpdk-merge-2.2/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi Thiago,
thanks for splitting up the discussion.
We are not entirely sure yet on how to manage (combined) library versions (so
is the DPDK project overall).
And in that regard we will see if we can just "take the patch" or need to find
a different solution.
I'm working on 2.2 now and once
Hi Thiago,
I'll take a look at enabling XEN once I have eliminated a few other DPDK
roadblockers.
But this request is not part of the MIR Request you posted in.
I unfortunately don't have a way to move your comment to a new bug.
To provide you with proper tracking and keep the MIR bug free of
** Description changed:
*** Still processing FFE and filling in the template ***
[Availability]
The source code is available from: git://dpdk.org/dpdk
General information: http://dpdk.org
The package is already part of universe and builds for the target
architecture
First of all thanks for checking the fix. and yes so far it is only
released for Xenial (16.04).
Given the time it was open and the amount of feedback we have got I
assumed it wouldn't be worth an SRU -
https://wiki.ubuntu.com/StableReleaseUpdates.
I'm still not sure if it is worth an SRU given
First of all thanks for checking the fix. and yes so far it is only
released for Xenial (16.04).
Given the time it was open and the amount of feedback we have got I
assumed it wouldn't be worth an SRU -
https://wiki.ubuntu.com/StableReleaseUpdates.
I'm still not sure if it is worth an SRU given
I looked into it more in detail - It is actually a bigger change than just
reusing what we did for Xenial.
Since for Xenial we did a lot of cleanup regarding upstart we can't just
"reuse" what we have for trusty.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I looked into it more in detail - It is actually a bigger change than just
reusing what we did for Xenial.
Since for Xenial we did a lot of cleanup regarding upstart we can't just
"reuse" what we have for trusty.
--
You received this bug notification because you are a member of Ubuntu
Server
Initial Analysis:
- stemmer can be set at the configure step, but it isn't by d/rules (default is
auto)
- providing libstemmer-dev converts the auto to a yes (as happened in the
ubuntu3 version)
- that yes then builds the code that is missing regarding this error here
- but also builds the
FYI about Debian on that situation.
- They are on 2.2.24 (so a merge is outstanding), but that is not affecting
this situation.
- Debian has the libstemmer-dev build dependency since 2.2.12-2 (Mar 2014)
- Our merges usually have (as the last by Doko) "Drop build dependency on
libstemmer-dev
Since it was only 98% clear :-), here a summary of a short and easy
guide to trigger the issue in e.g. a container:
#1 install dovecot+lucene
sudo apt-get install dovecot-lucene
#2 configure lucene
sed -ie 's/#mail_plugins = $/mail_plugins = $mail_plugins fts fts_lucene/'
Hi Robie,
I'll copy the SRU Teamplate up next time - just wasn't aware yet it should go
there.
Regarding the Test, yes I was only able to Test apache in general.
But not easily regarding the bug - this could be done thou given more time
investment.
I wanted to say with my "but we have to rely
** Description changed:
- killall in Precise is supposed to limit the number of arguments to 64,
- but due to a fencepost error, 66 arguments will be blocked but 65 is
- not.
+ [Impact]
+
+ * killall with exactly 65 (33 in 32-bit environments) arguments can kill
random processes
+ * this can
Raof, Racb and I just agreed on removing the dovecot-lucene.
Steps to be taken:
#1
- Merge to .24 in the Dev release (Debian is ahead atm)
- on that merge drop dovecot-lucene package
- should be case 11 on https://wiki.debian.org/PackageTransition
- discuss with if that makes sure it gets removed
Please be aware of related bug 1589174 that kind of is a post cleanup
for the cloud-init portion.
** Changed in: curtin
Status: New => Confirmed
** Changed in: curtin
Assignee: (unassigned) => ChristianEhrhardt (paelzer)
** Changed in: curtin
Importance: Undecided =&g
Took a look at it, the backport already done by Apache applies nicely.
I ran it through various sbuild's and adt's and it always built fine (also the
change is rather minimal - which is good for a SRU).
I installed the resulting deb's in a trusty container and the apache
still works fine after
** Patch added: "debdiff - fix timeout that can happen with mod proxy"
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1495988/+attachment/4679034/+files/bug-1495988-apache-modproxytimeouts.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Request for SRU sponsoring
[Impact]
* hang until ProxyTimeout timeout if ProxyErrorOverride is set
* see https://bz.apache.org/bugzilla/show_bug.cgi?id=53420 for more
[Test Case]
* use the feature of
https://httpd.apache.org/docs/current/mod/mod_proxy.html#proxyerroroverride
[Regression
Ok, so a bit of a summary for those like me who not auto-understand all
these packaging things like racb :-P
Reason behind it is that the file /usr/share/man/man1/clamdscan.1.gz was moved
between
from package clamav-daemon to clamdscan.
While clamav-daemon recommends clamdscan it can exist
Actually I realized Breaks <<0.99-plus-remaining-version is as good or
even better than just <<0.99, so I do the "usual" thing on break/replace
on the version that is adding the break/replace and by that hopefully
lowering the chance for confusion of the next one looking at the
package.
--
You
After some more thinking "<Wily and Trusty->Xenial need that relation anyway -
which means we should be able to rely on it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Patch added: "debdiff for xenial with the proper break/replaces"
https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1581839/+attachment/4680998/+files/fix-bug-1581839-xenial.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
** Patch added: "debdiff for wily with the proper break/replaces"
https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1581839/+attachment/4680997/+files/fix-bug-1581839-wily.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Debdiffs are complete and sbuild is happy (expected given the change),
but I want to give it some testing before adding the SRU+subscription.
That won't be today thou.
I'll need that test for steps to reproduce anyway.
--
You received this bug notification because you are a member of Ubuntu
See related discussions:
http://lists.gnu.org/archive/html/bug-tar/2016-05/msg00012.html
http://lists.gnu.org/archive/html/bug-tar/2016-06/msg00014.html
TL;DR:
In reference to my testcase:
BAD:
tar -c -f /tmp/test.tar -C dir subdir --exclude subdir/file
FIXED:
tar -c -f /tmp/test.tar -C dir
Public bug reported:
Hi,
this is a regression in tar 1.28-2.1 -> 1.29-1 and by that it is valid for
Xenial -> Yakkety, but as well for Debian Stretch.
Fortunately there is at least a simple test:
rm -rf dir; mkdir -p dir/subdir; touch dir/subdir/file; tar -c -f /tmp/test.tar
-C dir subdir
** Bug watch added: Debian Bug tracker #826195
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826195
** Also affects: tar (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826195
Importance: Unknown
Status: Unknown
--
You received this bug notification because you
Hi Thiago,
sorry - I did not want to upset you.
In that case that clearly isn't you, but upstream along the discussion you are
driving there that we are waiting on.
In fact no state really matches this case perfectly:
- confirmed suggests it is waiting for me/us to finally triage/work on it
Hi Thiago,
sorry - I did not want to upset you.
In that case that clearly isn't you, but upstream along the discussion you are
driving there that we are waiting on.
In fact no state really matches this case perfectly:
- confirmed suggests it is waiting for me/us to finally triage/work on it
Of course,
tested "4.7.0-040700rc3_4.7.0-040700rc3.201606121131", still broken.
** Tags added: kernel-bug-exists-upstream
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1590650
Title:
Noisy white
This is in fact now the way it always should have been.
So not a bug in tar, but if any in the code using tar.
... closing
** Changed in: tar (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Tests are nice, there seem to be a file move in just another package
New clamav-daemon breaks older clamav-base by file
/usr/share/man/man5/clamd.conf.5.gz
Need to integrate that as well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Test for verification:
1. Spawn Trusty container
2. apt-get install clamav-daemon
3. replace trusty with xenial in /etc/apt/sources.list
4. apt-get update
FIX CASE
5. make fixed package available locally (http://paste.ubuntu.com/1726/)
6. verify with apt-cache policy that the local repo works
while (and almost nobody does LTS->nonLTS).
That said I'd vote to only fix T->X.
** Changed in: clamav (Ubuntu Wily)
Status: Triaged => Won't Fix
** Changed in: clamav (Ubuntu Wily)
Assignee: ChristianEhrhardt (paelzer) => (unassigned)
** Patch removed: "debdiff for wil
** Patch removed: "debdiff for xenial with the proper break/replaces"
https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1581839/+attachment/4680998/+files/fix-bug-1581839-xenial.debdiff
** Patch added: "V2 debdiff for xenial with the proper break/replaces"
** Description changed:
+ [Impact]
+ * Upgrade path Trusty->Xenial is broken if clamav-daemon is installe
+ * The fix shall restore the upgrade path by marking properly with
+breaks/replaces as needed
+
+ [Test Case]
+ 1. Spawn Trusty container
+ 2. apt-get install clamav-daemon
+ 3.
1 - 100 of 5968 matches
Mail list logo