Bug#983854: ubuntu-dev-tools: Making SourcePackage abstract class botched backportpackage

2021-04-08 Thread Dan Streetman
On Thu, Apr 8, 2021 at 12:36 PM Mattia Rizzolo  wrote:
>
> On Tue, Mar 02, 2021 at 10:21:47AM +0100, Ondřej Surý wrote:
> > commit ee9b8756d9e81003ad199f24a15f69201009bbe7 in upstream package
> > (included in 0.179) botched the ability to run backportpackage on the
> > dsc files:
>
> ahem.
>
> > $ /usr/bin/backportpackage -b -w tmp php-grpc_1.35.0+1.33.1-2.dsc # 
> > just a random package
> > Traceback (most recent call last):
> >   File "/usr/bin/backportpackage", line 424, in 
> >   sys.exit(main(sys.argv))
> >   File "/usr/bin/backportpackage", line 394, in main
> >   pkg = find_package(opts.mirror,
> >   File "/usr/bin/backportpackage", line 204, in find_package
> >   return SourcePackage(version=version, dscfile=package,
> > TypeError: Can't instantiate abstract class SourcePackage with abstract 
> > method distribution

I'm surprised that *ever* worked, as it was clearly ignoring the
warning (from 2010) in the SourcePackage() comment, "Use
DebianSourcePackage or UbuntuSourcePackage instead of using this".

I never use backportpackage myself, but just changing it to use
UbuntuSourcePackage instead should work.
https://code.launchpad.net/~ddstreet/ubuntu-dev-tools/+git/ubuntu-dev-tools/+merge/400848

>
> Dan: ↑
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> More about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-



Bug#985070: corosync: fails to start in unprivileged container

2021-03-12 Thread Dan Streetman
Source: corosync
Severity: normal

Dear Maintainer,

corosync doesn't start in an unprivileged container.

upstream PR:
https://github.com/corosync/corosync/pull/620
https://github.com/corosync/corosync/pull/623

ubuntu bugs:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1911904
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1918735



Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2

2020-09-03 Thread Dan Streetman
On Thu, Sep 3, 2020 at 3:02 PM Michael Biebl  wrote:
>
> Hi Dan

Hi Michael

>
> Am 03.09.20 um 20:42 schrieb Dan Streetman:
> > On Mon, Aug 17, 2020 at 4:42 AM Michael Biebl  wrote:
> and over again.
> >>
> >> Afaics, the simplest solution, is to simply drop
> >>
> >> PathExists=/run/systemd/resolve/stub-resolv.conf
> >>
> >> and instead add a
> >>
> >> [Install]
> >> WantedBy=systemd-resolved.service
> >>
> >>
> >> to resolvconf-pull-resolved.service and also add a
> >> After=systemd-resolved.service
> >
> > It looks like resolvconf's resolvconf-pull-resolved.path has been
> > updated to use PathChanged instead.
>
>
> Now I'm confused.
> What my patch does (and which has been applied to resolvconf) is to drop
> PathExists (instead the service is activated via
> [Install]
> WantedBy=systemd-resolved.service
> )
> The PathChanged= bit has always been there. My patch did not add this.

Sorry my bad, you are right, both PathExists= and PathChanged= were
there before, and just PathChanged= now. Looks correct!

>
> Michael
>



Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2

2020-09-03 Thread Dan Streetman
On Mon, Aug 17, 2020 at 4:42 AM Michael Biebl  wrote:
>
> Control: severity -1 serious
> Control: tags -1 + patch
>
> Hi everyone,
>
> I think the effects of this issue are severe enough, that it needs to be
> fixed for bullseye. In other words, it should be RC
>
> On Sat, 08 Aug 2020 13:13:44 +0200 =?utf-8?q?Thomas_M=C3=BChlbacher?=
>  wrote:
> > I noticed that there were already two related bugreports, with Michael
> > Biebl providing a solution for the issue:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967906
> >
> > And to a lesser degree this one, I suppose:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968009
> >
> > I tried the container setup again with `PathExists=` dropped from
> > `resolvconf-pull-resolved.path` and it stops the errors from occurring,
> > however I did not verify that this way the service still does what it's
> > supposed to.
>
> #967906 and the related upstream bug report
> https://github.com/systemd/systemd/issues/16669 have more context.
>
> In short: PathExists in systemd v246 changed its behaviour to actually
> match the documentation.
> For resolvconf-pull-resolved.service that means, it's continuously
> started over and over again.
>
> Afaics, the simplest solution, is to simply drop
>
> PathExists=/run/systemd/resolve/stub-resolv.conf
>
> and instead add a
>
> [Install]
> WantedBy=systemd-resolved.service
>
>
> to resolvconf-pull-resolved.service and also add a
> After=systemd-resolved.service

It looks like resolvconf's resolvconf-pull-resolved.path has been
updated to use PathChanged instead.

That should fix the constant loop, though I'm not sure if it is
optimal, as I vaguely remember someone complaining that
systemd-resolved rewrites stub-resolv.conf often, and IIUC
PathChanged= triggers on inotify IN_CLOSE_WRITE so it would trigger
each time systemd-resolved opened (for write) and closed the file.
Although I have not actually looked into the code, so maybe it's fine.

In general I've tried to stay away from resolvconf as the integration
with resolved has been a bit painful, and I think xnox is in the
process of trying to fix that up.

I do tag any LP bugs that I notice relate to resolved/resolvconf
integration/interaction with the 'resolved-resolvconf' tag:
https://bugs.launchpad.net/bugs/+bugs?field.tag=resolved-resolvconf

>
> I've attached a prospective patch.
>
> Dan, Dimitri, would welcome your feedback here, since most of the
> resolvconf/resolved integration is seemingly coming from you.
>
>
> Regards,
> Michael



Bug#969340: nvme-cli: generate /etc/nvme/host* files at install time, not build time

2020-08-31 Thread Dan Streetman
v2 debdiff, with slight adjustment that may be better
diff -Nru --exclude package.bash-completion --exclude changelog --exclude control nvme-cli-1.12/debian/nvme-cli.postinst nvme-cli-1.12/debian/nvme-cli.postinst
--- nvme-cli-1.12/debian/nvme-cli.postinst	1969-12-31 19:00:00.0 -0500
+++ nvme-cli-1.12/debian/nvme-cli.postinst	2020-08-31 15:41:46.0 -0400
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+set -e
+
+if [ "$1" = "configure" ]; then
+if [ ! -s /etc/nvme/hostnqn ]; then
+nvme gen-hostnqn > /etc/nvme/hostnqn
+fi
+
+if [ ! -s /etc/nvme/hostid ]; then
+uuidgen > /etc/nvme/hostid
+fi
+fi
+
+#DEBHELPER#
diff -Nru --exclude package.bash-completion --exclude changelog --exclude control nvme-cli-1.12/debian/rules nvme-cli-1.12/debian/rules
--- nvme-cli-1.12/debian/rules	2018-08-06 12:12:32.0 -0400
+++ nvme-cli-1.12/debian/rules	2020-08-31 14:11:23.0 -0400
@@ -7,6 +7,10 @@
 
 override_dh_auto_install:
 	dh_auto_install -- PREFIX=/usr
+	# Remove build-time unique id files, instead these will be
+	# generated by the postinst script
+	rm -f debian/nvme-cli/etc/nvme/hostid
+	rm -f debian/nvme-cli/etc/nvme/hostnqn
 
 override_dh_auto_test:
 	# Overriding auto test, since the tests require that the build machine


Bug#969345: nvme-cli: debian/package.bash-completion not needed

2020-08-31 Thread Dan Streetman
Package: nvme-cli
Version: 1.9-1
Severity: minor

Dear Maintainer,

The debian/package.bash-completion file is not needed, as the bash
completion script is installed/packaged by the Makefile.



Bug#969183: nvme-cli: bring debhelper compat to 13 and fix build deps

2020-08-31 Thread Dan Streetman
> This adds some build deps there were missing:
> uuid-dev

I should have also mentioned that without the uuid-dev package
installed at build time, the nvme command 'gen-hostnqn' can't be
built, so this patch does fix that.



Bug#969183: Fwd: Bug#969183: nvme-cli: bring debhelper compat to 13 and fix build deps

2020-08-31 Thread Dan Streetman
> This adds some build deps there were missing:
> uuid-dev

I should have also mentioned that without the uuid-dev package
installed at build time, the nvme command 'gen-hostnqn' can't be
built, so this patch does fix that.

Also this is related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969340

and in Ubuntu, this bug:
https://bugs.launchpad.net/ubuntu/+source/nvme-cli/+bug/1867366



Bug#969340: nvme-cli: generate /etc/nvme/host* files at install time, not build time

2020-08-31 Thread Dan Streetman
Package: nvme-cli
Version: 1.12-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Dear Maintainer,

The nvme-cli package currently generates the /etc/nvme/hostnqn and
/etc/nvme/hostid files during the build, which results in the content
of the files being identical for all installed systems. Since these
files are supposed to contain ids unique to the installed system,
having them included in the binary package is incorrect, and instead
they should be generated during package install.

This patch removes the files from the binary package, and adds a postinst
to generate the files (if needed).

Note that this also requires the patch from:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969183
because without that patch, the build doesn't include uuid-dev, and the
nvme 'gen-hostnqn' command is not able to be built.

This is also tracked in Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/nvme-cli/+bug/1867366

Thanks for considering the patch.
diff -Nru nvme-cli-1.12/debian/nvme-cli.postinst 
nvme-cli-1.12/debian/nvme-cli.postinst
--- nvme-cli-1.12/debian/nvme-cli.postinst  1969-12-31 19:00:00.0 
-0500
+++ nvme-cli-1.12/debian/nvme-cli.postinst  2020-08-31 14:11:37.0 
-0400
@@ -0,0 +1,11 @@
+#!/bin/sh -e
+
+if [ ! -s /etc/nvme/hostnqn ]; then
+nvme gen-hostnqn > /etc/nvme/hostnqn
+fi
+
+if [ ! -s /etc/nvme/hostid ]; then
+uuidgen > /etc/nvme/hostid
+fi
+
+exit 0
diff -Nru nvme-cli-1.12/debian/package.bash-completion 
nvme-cli-1.12/debian/package.bash-completion
--- nvme-cli-1.12/debian/package.bash-completion2017-02-06 
08:20:45.0 -0500
+++ nvme-cli-1.12/debian/package.bash-completion1969-12-31 
19:00:00.0 -0500
@@ -1 +0,0 @@
-bash_completion.d/nvme
diff -Nru nvme-cli-1.12/debian/rules nvme-cli-1.12/debian/rules
--- nvme-cli-1.12/debian/rules  2018-08-06 12:12:32.0 -0400
+++ nvme-cli-1.12/debian/rules  2020-08-31 14:11:23.0 -0400
@@ -7,6 +7,10 @@
 
 override_dh_auto_install:
dh_auto_install -- PREFIX=/usr
+   # Remove build-time unique id files, instead these will be
+   # generated by the postinst script
+   rm -f debian/nvme-cli/etc/nvme/hostid
+   rm -f debian/nvme-cli/etc/nvme/hostnqn
 
 override_dh_auto_test:
# Overriding auto test, since the tests require that the build machine


Bug#969183: nvme-cli: bring debhelper compat to 13 and fix build deps

2020-08-28 Thread Dan Streetman
Package: nvme-cli
Version: 1.12-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Dear Maintainer,

This patch brings the debhelper-compat version up to 13, since it is currently 
still set to 9 which is deprecated and generates warnings during build.

This also does a 'wrap-and-sort -ast'.

This removes some build deps that are no longer needed:
libudev-dev
python3-nose (technically the tests use python3-nose2, but they aren't run 
during build anyway, because they require nvme hardware)

This adds some build deps there were missing:
pkg-config
uuid-dev

Thanks!
diff -Nru nvme-cli-1.12/debian/compat nvme-cli-1.12/debian/compat
--- nvme-cli-1.12/debian/compat 2016-01-07 12:34:55.0 -0500
+++ nvme-cli-1.12/debian/compat 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-9
diff -Nru nvme-cli-1.12/debian/control nvme-cli-1.12/debian/control
--- nvme-cli-1.12/debian/control2019-11-23 08:40:09.0 -0500
+++ nvme-cli-1.12/debian/control2020-08-28 12:24:46.0 -0400
@@ -3,12 +3,19 @@
 Section: admin
 Priority: optional
 Standards-Version: 4.1.1
-Build-Depends: debhelper (>= 9), libudev-dev, python3-nose, pci.ids, 
uuid-runtime
+Build-Depends:
+ debhelper-compat (= 13),
+ pci.ids,
+ pkg-config,
+ uuid-dev,
+ uuid-runtime,
 Homepage: https://github.com/linux-nvme/nvme-cli
 
 Package: nvme-cli
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
 Description: userspace tooling to control NVMe drives
  NVMe is a fast, scalable, direct attached storage interface, accessing
  solid state drives through PCIe.


Bug#969182: debhelper: compat 11 adds install --strip-program=true which generates annoying warnings during build

2020-08-28 Thread Dan Streetman
Package: debhelper
Version: 12.10ubuntu1
Severity: minor

Dear Maintainer,

The debhelper compat level 11 adds the --strip-program=true parameter to calls 
to install,
to prevent install-time stripping (debian bug 844077).

However, if the upstream Makefile is calling install without -s, the addition 
of --strip-program=true
causes annoying/confusing warning messages to be printed many times during 
build, e.g.:

install: WARNING: ignoring --strip-program option as -s option was not specified



Bug#945527: cachefilesd: if statement nr_in_(ready|build)_table underflow causes segfault

2020-06-03 Thread Dan Streetman
On Wed, Jun 3, 2020 at 5:39 AM Daniel Scharon
 wrote:
>
> Dear Maintainer,
>
> are you willing to accept this patch?
>
> @Dan: Is your patch or at least the bug itself reported to upstream?

Upstream cachefilesd hasn't seen any commits in over 3 years:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/cachefilesd.git

and the maintainer says he plans to 'overhaul the whole thing':
https://www.redhat.com/archives/linux-cachefs/2020-March/msg2.html

so I considered upstream essentially dead.

>
> Thank you and kind regards,
> Daniel



Bug#945527: cachefilesd: if statement nr_in_(ready|build)_table underflow causes segfault

2019-11-26 Thread Dan Streetman
Package: cachefilesd
Version: 0.10.10-0.2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear Maintainer,

the build_cull_table() function scans through elements up to 
nr_in_ready_table/nr_in_build_table, and performs actions if a match was found; 
however the match detection logic simply compares the for loop index against 
nr_in_*_table - 1, which underflows when 0, resulting in incorrect if section 
being run and then segfaulting.


In Ubuntu, the attached patch was applied to achieve the following:

  * Avoid counter underflow, leading to segfault (LP: #1854054)


Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers eoan-updates
  APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan'), 
(100, 'eoan-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-23-generic (SMP w/24 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru cachefilesd-0.10.10/cachefilesd.c cachefilesd-0.10.10/cachefilesd.c
--- cachefilesd-0.10.10/cachefilesd.c   2019-07-19 10:55:33.0 -0400
+++ cachefilesd-0.10.10/cachefilesd.c   2019-11-26 08:09:57.0 -0500
@@ -1389,13 +1389,13 @@
if (cullready[loop] == child)
break;
 
-   if (loop == nr_in_ready_table - 1) {
+   if (loop + 1 == nr_in_ready_table) {
/* child was oldest object */
cullready[--nr_in_ready_table] = (void 
*)(0x6b00 | __LINE__);
put_object(child);
goto removed;
}
-   else if (loop < nr_in_ready_table - 1) {
+   else if (loop + 1 < nr_in_ready_table) {
/* child was somewhere in between */
memmove([loop],
[loop + 1],
@@ -1409,12 +1409,12 @@
if (cullbuild[loop] == child)
break;
 
-   if (loop == nr_in_build_table - 1) {
+   if (loop + 1 == nr_in_build_table) {
/* child was oldest object */
cullbuild[--nr_in_build_table] = (void 
*)(0x6b00 | __LINE__);
put_object(child);
}
-   else if (loop < nr_in_build_table - 1) {
+   else if (loop + 1 < nr_in_build_table) {
/* child was somewhere in between */
memmove([loop],
[loop + 1],


Bug#943520: mdadm: Introduce broken state parsing to mdadm

2019-10-25 Thread Dan Streetman
Package: mdadm
Version: 4.1-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear Maintainer,

* Currently, mounted raid0/md-linear arrays have no indication/warning when one 
or more members are removed or suffer from some non-recoverable error 
condition. The mdadm tool shows "clean" state regardless if a member was 
removed.

* The patch proposed in this SRU addresses this issue by introducing a new 
state "broken", which is analog to "clean" but indicates that array is not in a 
good/correct state. The commit, available upstream as 43ebc910 ("mdadm: 
Introduce new array state 'broken' for raid0/linear") [0], was extensively 
discussed and received a good amount of reviews/analysis by both the current 
mdadm maintainer as well as an old maintainer.

* One important note here is that this patch requires a counter-part in the 
kernel to be fully functional, which was SRUed in LP: #1847773.
It works fine/transparently without this kernel counter-part though.


In Ubuntu, the attached patch was applied to achieve the following:

  * Introduce "broken" state for RAID0/Linear in mdadm (LP: #1847924)


Thanks for considering the patch.
diff -Nru mdadm-4.1/debian/control mdadm-4.1/debian/control
--- mdadm-4.1/debian/control2019-05-04 23:58:27.0 -0400
+++ mdadm-4.1/debian/control2019-10-13 17:04:34.0 -0400
@@ -1,8 +1,7 @@
 Source: mdadm
 Section: admin
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian QA Group 
+Maintainer: Debian QA Group 
 Build-Depends: debhelper (>= 11), po-debconf, groff-base
 Standards-Version: 4.3.0
 Vcs-Git: https://git.dgit.debian.org/mdadm
diff -Nru 
mdadm-4.1/debian/patches/lp-1847924-introduce-new-array-state-broken.patch 
mdadm-4.1/debian/patches/lp-1847924-introduce-new-array-state-broken.patch
--- mdadm-4.1/debian/patches/lp-1847924-introduce-new-array-state-broken.patch  
1969-12-31 19:00:00.0 -0500
+++ mdadm-4.1/debian/patches/lp-1847924-introduce-new-array-state-broken.patch  
2019-10-13 17:04:34.0 -0400
@@ -0,0 +1,159 @@
+Subject: Introduce new array state 'broken' for raid0/linear
+
+Currently if a md raid0/linear array gets one or more members removed while
+being mounted, kernel keeps showing state 'clean' in the 'array_state'
+sysfs attribute. Despite udev signaling the member device is gone, 'mdadm'
+cannot issue the STOP_ARRAY ioctl successfully, given the array is mounted.
+
+Nothing else hints that something is wrong (except that the removed devices
+don't show properly in the output of mdadm 'detail' command). There is no
+other property to be checked, and if user is not performing reads/writes
+to the array, even kernel log is quiet and doesn't give a clue about the
+missing member.
+
+This patch is the mdadm counterpart of kernel new array state 'broken'.
+The 'broken' state mimics the state 'clean' in every aspect, being useful
+only to distinguish if an array has some member missing. All necessary
+paths in mdadm were changed to deal with 'broken' state, and in case the
+tool runs in a kernel that is not updated, it'll work normally, i.e., it
+doesn't require the 'broken' state in order to work.
+Also, this patch changes the way the array state is showed in the 'detail'
+command (for raid0/linear only) - now it takes the 'array_state' sysfs
+attribute into account instead of only rely in the MD_SB_CLEAN flag.
+
+Author: Guilherme G. Piccoli 
+Origin: upstream,
+git.kernel.org/pub/scm/utils/mdadm/mdadm.git/commit/?id=cb77f8c598ede2b7efec23f899b1cda44c315195
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1847924
+Last-Update: 2019-10-13
+---
+ Detail.c  | 14 --
+ Monitor.c |  8 ++--
+ maps.c|  1 +
+ mdadm.h   |  1 +
+ mdmon.h   |  2 +-
+ monitor.c |  4 ++--
+ 6 files changed, 23 insertions(+), 7 deletions(-)
+
+diff --git a/Detail.c b/Detail.c
+index b3e857a..d24f334 100644
+--- a/Detail.c
 b/Detail.c
+@@ -81,6 +81,7 @@ int Detail(char *dev, struct context *c)
+   int external;
+   int inactive;
+   int is_container = 0;
++  char *arrayst;
+ 
+   if (fd < 0) {
+   pr_err("cannot open %s: %s\n",
+@@ -485,9 +486,18 @@ int Detail(char *dev, struct context *c)
+   else
+   st = ", degraded";
+ 
++  if (array.state & (1 << MD_SB_CLEAN)) {
++  if ((array.level == 0) ||
++  (array.level == LEVEL_LINEAR))
++  arrayst = map_num(sysfs_array_states,
++sra->array_state);
++  else
++  arrayst = "clean";
++  } else
++  arrayst = "active";
++
+   printf(" State : %s%s%s%s%s%s \n",
+- (array.state & (1 << 

Bug#931304: [PATCH] hid2hci: Fix udev rules for linux-4.14+

2019-09-10 Thread Dan Streetman
From: Ville Syrjälä 

Since commit 1455cf8dbfd0 ("driver core: emit uevents when
device is bound to a driver") the kernel started emitting
"bind" and "unbind" uevents which confuse the hid2hci
udev rules.

The symptoms on an affected machine (Dell E5400 in my case)
include bluetooth devices not appearing and udev hogging
the cpu as it's busy processing a constant stream of these
"bind"+"unbind" uevents.

Change the udev rules not do anything except for "add" and
"change" events. This seems to cure my machine at least.

v2: Don't mess up "change" (Zbyszek)
Fix up the commit message a bit

Closes: #931304
Origin: upstream, https://lore.kernel.org/patchwork/patch/1021109/

---
 tools/hid2hci.rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hid2hci.rules b/tools/hid2hci.rules
index db6bb03d2..5c7208af7 100644
--- a/tools/hid2hci.rules
+++ b/tools/hid2hci.rules
@@ -1,6 +1,6 @@
 # do not edit this file, it will be overwritten on update
 
-ACTION=="remove", GOTO="hid2hci_end"
+ACTION!="add|change", GOTO="hid2hci_end"
 SUBSYSTEM!="usb*", GOTO="hid2hci_end"
 
 # Variety of Dell Bluetooth devices - match on a mouse device that is
-- 
2.20.1



Bug#939516: patch/merge-request

2019-09-05 Thread Dan Streetman
On Thu, Sep 5, 2019 at 3:40 PM Sven Joachim  wrote:
>
> On 2019-09-05 15:03 -0400, Dan Streetman wrote:
>
> > I have a commit to fix this here:
> > https://salsa.debian.org/ddstreet-guest/dpkg/commit/dcccd6ed83989d7a2a752d05b1e4c0326c8c8a21
> >
> > however it seems that dpkg in salsa has merge requests disabled, so i
> > can't open a merge request for it.  Can you review that commit please?
>
> It would be best to include the patch in the mail
> (run "git format-patch" and attach the resulting file) so that it can be
> commented here.  Just one remark for now, you should run
> dh_autoreconf_clean in the clean target.

sure, just sent it with git send-email, and updated it to call
dh_autoreconf_clean in clean target.  thanks!

>
> Cheers,
>Sven



Bug#939516: [PATCH] d/rules: replace custom rule for 'configure' with call to dh_autoreconf

2019-09-05 Thread Dan Streetman
From: Dan Streetman 

Having a custom rule to create 'configure' means that if the file
may not get correctly rebuilt; instead dh_autoreconf should be
called to make sure it is always correctly rebuilt.

Closes: #939516
---
 debian/rules | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/debian/rules b/debian/rules
index a542193fc..006d069ce 100755
--- a/debian/rules
+++ b/debian/rules
@@ -47,15 +47,10 @@ endif
 
 D := $(CURDIR)/debian/tmp
 
-# Create configure script if necessary, automake handles rebuilding it.
-configure:
-   dh_testdir
-
-   ./autogen
-
 # Configure the build tree
-build-tree/config.status: configure
+build-tree/config.status:
dh_testdir
+   dh_autoreconf
 
install -d build-tree
cd build-tree && ../configure $(confflags) \
@@ -164,6 +159,7 @@ clean:
 
[ ! -f Makefile ] || $(MAKE) distclean
rm -rf build-tree
+   dh_autoreconf_clean
dh_clean
 
 
-- 
2.20.1



Bug#939516: patch/merge-request

2019-09-05 Thread Dan Streetman
I have a commit to fix this here:
https://salsa.debian.org/ddstreet-guest/dpkg/commit/dcccd6ed83989d7a2a752d05b1e4c0326c8c8a21

however it seems that dpkg in salsa has merge requests disabled, so i
can't open a merge request for it.  Can you review that commit please?



Bug#939516: dpkg: debian/rules 'configure' rule does not always recreate configure file

2019-09-05 Thread Dan Streetman
Package: dpkg
Version: 1.20.0
Severity: normal

Dear Maintainer,

The debian/rules file has a manual rule for the 'configure' file, but this
results in the 'configure' file not always being recreated.

For example:
$ head -1 debian/changelog 
dpkg (1.20.0) UNRELEASED; urgency=medium
$ echo hello > configure
$ chmod 755 configure
$ dpkg-buildpackage
...
../configure: 1: hello: not found

While that's a silly example, and unlikely to ever cause real issues for
Debian since the Debian dpkg source doesn't carry the 'configure' file,
the Ubuntu dpkg source *does* unfortunately carry the 'configure' file,
and this caused a real regression:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1842947



Bug#932393: spice-html5: Windows guest display is inverted vertically

2019-07-18 Thread Dan Streetman
Package: spice-html5
Version: 0.1.7-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

When running a Windows VM using the QXL driver from [1] the display is inverted 
and therefore almost unusable.

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/fix-windows-spice-upside-down-bitmaps.patch:
Handle non topdown bitmaps (LP: #1836361)

The Ubuntu bug is 
https://bugs.launchpad.net/ubuntu/+source/spice-html5/+bug/1836361
Commit taken from upstream 
https://github.com/freedesktop/spice-html5/commit/7ba763feb5322f0c97758070075b60cee5464f47


Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers disco-updates
  APT policy: (500, 'disco-updates'), (500, 'disco-security'), (500, 'disco'), 
(100, 'disco-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-20-generic (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
spice-html5-0.1.7/debian/patches/fix-windows-spice-upside-down-bitmaps.patch 
spice-html5-0.1.7/debian/patches/fix-windows-spice-upside-down-bitmaps.patch
--- 
spice-html5-0.1.7/debian/patches/fix-windows-spice-upside-down-bitmaps.patch
1969-12-31 19:00:00.0 -0500
+++ 
spice-html5-0.1.7/debian/patches/fix-windows-spice-upside-down-bitmaps.patch
2019-07-12 10:24:36.0 -0400
@@ -0,0 +1,52 @@
+Description: Handle non topdown bitmaps
+ Backport of an upstream patch.
+ .
+ spice-html5 (0.1.7-3ubuntu1) eoan; urgency=medium
+ .
+   * d/p/fix-windows-spice-upside-down-bitmaps.patch:
+ Handle non topdown bitmaps (LP: #1836361)
+
+Origin: upstream, 
https://github.com/freedesktop/spice-html5/commit/7ba763feb5322f0c97758070075b60cee5464f47
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1836361
+
+--- spice-html5-0.1.7.orig/bitmap.js
 spice-html5-0.1.7/bitmap.js
+@@ -26,25 +26,31 @@
+ function convert_spice_bitmap_to_web(context, spice_bitmap)
+ {
+ var ret;
+-var offset, x;
++var offset, x, src_offset = 0, src_dec = 0;
+ var u8 = new Uint8Array(spice_bitmap.data);
+ if (spice_bitmap.format != SPICE_BITMAP_FMT_32BIT &&
+ spice_bitmap.format != SPICE_BITMAP_FMT_RGBA)
+ return undefined;
+ 
++if (!(spice_bitmap.flags & SPICE_BITMAP_FLAGS_TOP_DOWN))
++{
++src_offset = (spice_bitmap.y - 1 ) * spice_bitmap.stride;
++src_dec = 2 * spice_bitmap.stride;
++}
++
+ ret = context.createImageData(spice_bitmap.x, spice_bitmap.y);
+-for (offset = 0; offset < (spice_bitmap.y * spice_bitmap.stride); )
+-for (x = 0; x < spice_bitmap.x; x++, offset += 4)
++for (offset = 0; offset < (spice_bitmap.y * spice_bitmap.stride); 
src_offset -= src_dec)
++for (x = 0; x < spice_bitmap.x; x++, offset += 4, src_offset += 4)
+ {
+-ret.data[offset + 0 ] = u8[offset + 2];
+-ret.data[offset + 1 ] = u8[offset + 1];
+-ret.data[offset + 2 ] = u8[offset + 0];
++ret.data[offset + 0 ] = u8[src_offset + 2];
++ret.data[offset + 1 ] = u8[src_offset + 1];
++ret.data[offset + 2 ] = u8[src_offset + 0];
+ 
+ // FIXME - We effectively treat all images as having 
SPICE_IMAGE_FLAGS_HIGH_BITS_SET
+ if (spice_bitmap.format == SPICE_BITMAP_FMT_32BIT)
+ ret.data[offset + 3] = 255;
+ else
+-ret.data[offset + 3] = u8[offset];
++ret.data[offset + 3] = u8[src_offset];
+ }
+ 
+ return ret;
diff -Nru spice-html5-0.1.7/debian/patches/series 
spice-html5-0.1.7/debian/patches/series
--- spice-html5-0.1.7/debian/patches/series 2018-08-16 10:14:00.0 
-0400
+++ spice-html5-0.1.7/debian/patches/series 2019-07-12 10:24:36.0 
-0400
@@ -1,2 +1,3 @@
 add-ctrl-alt-del-button.patch
 fix-windows-spice-upside-down.patch
+fix-windows-spice-upside-down-bitmaps.patch


Bug#929728: systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug

2019-06-27 Thread Dan Streetman
ack - let me redo this a bit and open a MR in salsa.

On Thu, Jun 27, 2019 at 10:45 AM Martin Pitt  wrote:
>
> Hello,
>
> rmmod failure due to "busy" is annoying indeed, and a bit hard to fix, thus
> your approach with removing the individual hosts instead seems fine.
>
> If the module isn't available though, I'd consider this a bad testbed.
> autopkgtest's testbed VM construction scripts (VM, container, cloud) all
> install the linux-image-extra bits to make sure that the module exists. If 
> this
> silently gets skipped, it could then be that this functionality just never 
> gets
> tested, so I'm not too happy about that part.
>
> Thanks,
>
> Martin



Bug#929730: systemd: boot-and-services test expects first kernel log line, but not always in logs

2019-06-27 Thread Dan Streetman
Opened MR:
https://salsa.debian.org/systemd-team/systemd/merge_requests/34

thanks!

On Tue, Jun 25, 2019 at 4:55 PM Michael Biebl  wrote:
>
> Am 25.06.19 um 22:51 schrieb Michael Biebl:
> > Dan, could you submit your patch as merge request?
>
> Btw, we use gbp-dch style commit messages.
>
> E.g. Debian bugs are closed by adding a
>
> Closes: #929730
>
> line to the git commit message.
>
> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/man.gbp.dch.html
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>



Bug#931076: systemd: __main__.SeccompTest is failing on Ubuntu CI

2019-06-25 Thread Dan Streetman
Package: systemd
Version: 240-6ubuntu5.1
Severity: normal

Dear Maintainer,

Upstream systemd CI is broken on Ubuntu due to a recent upstream change.  The 
d/t/boot-and-services test needs to be fixed to account for the new upstream 
change.

This is reported upstream at:
https://github.com/systemd/systemd/issues/12709

This is reported for Ubuntu at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1831296

Since upstream systemd CI uses the debian test packaging from experimental, 
this has to be corrected in that repo.  Merge request is open here:
https://salsa.debian.org/systemd-team/systemd/merge_requests/33

Please consider merging.  Thanks.



Bug#929728: systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug

2019-05-29 Thread Dan Streetman
On Wed, May 29, 2019 at 12:08 PM Michael Biebl  wrote:
>
> Am 29.05.19 um 18:02 schrieb Dan Streetman:
> > Package: systemd
> > Version: 241-5
> > Severity: normal
> > Tags: patch
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu eoan ubuntu-patch
> >
> > Dear Maintainer,
> >
> > 'storage' test fails on some archs/releases trying to modprobe and/or rmmod 
> > scsi_debug.
> >
>
> I've never seen this failure. Can you eloborate on the conditions when
> this happens?

a couple examples - search for scsi_debug:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/s/systemd/20190529_064803_7dbf0@/log.gz
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/s/systemd/20190216_115842_cf8d3@/log.gz



>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>



Bug#929730: systemd: boot-and-services test expects first kernel log line, but not always in logs

2019-05-29 Thread Dan Streetman
On Wed, May 29, 2019 at 12:35 PM Michael Biebl  wrote:
>
> Am 29.05.19 um 18:19 schrieb Dan Streetman:
> > Package: systemd
> > Version: 241-5
> > Severity: normal
> > Tags: patch
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu eoan ubuntu-patch
> >
> > Dear Maintainer,
> >
> > boot-and-services test expects the first(ish) kernel log line to be in the 
> > system logs, but that is not guaranteed to be in the logs.
> >
> > -- Package-specific info:
> >
> >
> >   * d/t/boot-and-services:
> > - don't fail if some kernel msgs are missed (LP: #1830479)
>
>
> Afair, this is due to the kernel ring buffer being too small (on arm64)
> Wouldn't it be better to address that? After all, you also want early
> boot messages when running systemd in production.

that's one reason; is systemd missing kernel messages due to no fault
of its own really something that should fail the test case?

note that unless systemd-journald explicitly noted that kernel
messages were missed, it still checks for the command-line kernel line

>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>



Bug#929730: systemd: boot-and-services test expects first kernel log line, but not always in logs

2019-05-29 Thread Dan Streetman
Package: systemd
Version: 241-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

boot-and-services test expects the first(ish) kernel log line to be in the 
system logs, but that is not guaranteed to be in the logs.

-- Package-specific info:


  * d/t/boot-and-services:
- don't fail if some kernel msgs are missed (LP: #1830479)


Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers disco-updates
  APT policy: (500, 'disco-updates'), (500, 'disco-security'), (500, 'disco'), 
(100, 'disco-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-13-generic (SMP w/24 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.131ubuntu19
ii  udev 240-6ubuntu5
diff -Nru systemd-241/debian/tests/boot-and-services 
systemd-241/debian/tests/boot-and-services
--- systemd-241/debian/tests/boot-and-services  2019-05-24 16:58:59.0 
-0400
+++ systemd-241/debian/tests/boot-and-services  2019-05-29 12:17:13.0 
-0400
@@ -108,8 +108,15 @@
 with open('/var/log/syslog') as f:
 log = f.read()
 if not is_container:
+out = subprocess.check_output(['journalctl'])
+if re.search(b'Missed.*kernel messages', out):
+# if we missed some, just check for any kernel msg
+kernel_regex = 'kernel:.*'
+else:
+# otherwise, check for the first(ish) kernel msg
+kernel_regex = 'kernel:.*[cC]ommand line:'
 # has kernel messages
-self.assertRegex(log, 'kernel:.*[cC]ommand line:')
+self.assertRegex(log, kernel_regex)
 # has init messages
 self.assertRegex(log, 'systemd.*Reached target Graphical Interface')
 # has other services
@@ -185,8 +192,14 @@
 def test_no_options(self):
 out = subprocess.check_output(['journalctl'])
 if not is_container:
+if re.search(b'Missed.*kernel messages', out):
+# if we missed some, just check for any kernel msg
+kernel_regex = b'kernel:.*'
+else:
+# otherwise, check for the first(ish) kernel msg
+kernel_regex = b'kernel:.*[cC]ommand line:'
 # has kernel messages
-self.assertRegex(out, b'kernel:.*[cC]ommand line:')
+self.assertRegex(out, kernel_regex)
 # has init messages
 self.assertRegex(out, b'systemd.*Reached target Graphical Interface')
 # has other services


Bug#929726: ask-password: prevent buffer overrow when reading from keyring

2019-05-29 Thread Dan Streetman
On Wed, May 29, 2019 at 11:58 AM Michael Biebl  wrote:
>
> Thanks for the patch, Dan.
> I see this has already been committed upstream, which is great.
>
> Am 29.05.19 um 17:50 schrieb Dan Streetman:
> > +Subject: [PATCH] ask-password: prevent buffer overrow when reading from
>  ^
> I assume this is a typo and you meant either buffer overrun or overflow

yes, sorry, i just copied from the github bug:
https://github.com/systemd/systemd/pull/12566

>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>



Bug#929728: systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug

2019-05-29 Thread Dan Streetman
Package: systemd
Version: 241-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

'storage' test fails on some archs/releases trying to modprobe and/or rmmod 
scsi_debug.

-- Package-specific info:


  * d/t/storage:
- fix handling of scsi_debug module, test drives (LP: #1829347)


Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers disco-updates
  APT policy: (500, 'disco-updates'), (500, 'disco-security'), (500, 'disco'), 
(100, 'disco-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-13-generic (SMP w/24 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.131ubuntu19
ii  udev 240-6ubuntu5
diff -Nru systemd-241/debian/tests/storage systemd-241/debian/tests/storage
--- systemd-241/debian/tests/storage2019-05-24 16:58:59.0 -0400
+++ systemd-241/debian/tests/storage2019-05-29 11:52:19.0 -0400
@@ -12,40 +12,69 @@
 from glob import glob
 
 
-@unittest.skipIf(os.path.isdir('/sys/module/scsi_debug'),
- 'The scsi_debug module is already loaded')
+SCSI_DEBUG_DIR='/sys/bus/pseudo/drivers/scsi_debug'
+
 class FakeDriveTestBase(unittest.TestCase):
 @classmethod
 def setUpClass(klass):
-# create a fake SCSI hard drive
-subprocess.check_call(['modprobe', 'scsi_debug', 'dev_size_mb=32'])
+if not os.path.isdir(SCSI_DEBUG_DIR):
+subprocess.call(['modprobe', 'scsi_debug', 'dev_size_mb=32'],
+stderr=subprocess.DEVNULL)
+# if still not available, we can't run any of our tests
+if not os.path.isdir(SCSI_DEBUG_DIR):
+klass.skipTest('scsi_debug module not loaded')
+
+def setUp(self):
+# remove any existing drives, then add back one for us to use
+self.remove_scsi_debug_drives()
+with open(os.path.join(SCSI_DEBUG_DIR, 'add_host'), 'r+') as f:
+print('Adding scsi_debug drive')
+f.write('1')
+for wait in range(10):
+f.seek(0)
+if f.read().strip() == '1':
+break
+time.sleep(0.1)
+else:
+self.skipTest('Could not add scsi_debug drive to test')
 # wait until drive got created
 sys_dirs = []
-while not sys_dirs:
-sys_dirs = 
glob('/sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*:*/block')
+for tries in range(100):
+sys_dirs = glob(os.path.join(SCSI_DEBUG_DIR,
+ 'adapter*/host*/target*/*:*/block'))
+if sys_dirs:
+break
 time.sleep(0.1)
-assert len(sys_dirs) == 1
+if len(sys_dirs) < 1:
+self.skipTest('could not find scsi_debug block device')
+elif len(sys_dirs) > 1:
+self.skipTest('too many scsi_debug block devices (%s)' % 
len(sys_dirs))
 devs = os.listdir(sys_dirs[0])
 assert len(devs) == 1
-klass.device = '/dev/' + devs[0]
-
-@classmethod
-def tearDownClass(klass):
-# create a fake SCSI hard drive
-subprocess.check_call(['rmmod', 'scsi_debug'])
+self.device = '/dev/' + devs[0]
 
 def tearDown(self):
-# clear drive
-with open(self.device, 'wb') as f:
-block = b'0' * 1048576
-try:
-while True:
-f.write(block)
-except OSError:
-pass
+self.remove_scsi_debug_drives()
 subprocess.check_call(['udevadm', 'settle'])
 subprocess.check_call(['systemctl', 'daemon-reload'])
 
+def remove_scsi_debug_drives(self):
+with open(os.path.join(SCSI_DEBUG_DIR, 'add_host'), 'r+') as f:
+n = f.read().strip()
+f.seek(0)
+if n == '0':
+return
+print('Removing %s scsi_debug test drive(s)' % n)
+f.write('-%s' % n)
+for wait in range(50):
+f.seek(0)
+n = f.read().strip()
+if n == '0':
+break
+time.sleep(0.1)
+else:
+self.skipTest('Could not remove %s scsi_debug drives' % n)
+
 
 class CryptsetupTest(FakeDriveTestBase):
 def setUp(self):
@@ -215,6 +244,7 @@
 self.format_luks()
 with open('/etc/crypttab', 'w') as f:
 f.write('%s %s none luks,tmp\n' % (self.plaintext_name, 
self.device))
+self.apply('cryptsetup.target')
 
 mountpoint = '/run/crypt1.systemdtest'
 

Bug#929726: ask-password: prevent buffer overrow when reading from keyring

2019-05-29 Thread Dan Streetman
Package: systemd
Version: 241-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

When we read from keyring, a temporary buffer is allocated in order to
determine the size needed for the entire data. However, when zeroing that area,
we use the data size returned by the read instead of the lesser size allocate
for the buffer.

That will cause memory corruption that causes systemd-cryptsetup to crash
either when a single large password is used or when multiple passwords have
already been pushed to the keyring

  * d/p/ask-password-prevent-buffer-overrow-when-reading-fro.patch:
- prevent buffer overflow when reading keyring (LP: #1814373)


Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers disco-updates
  APT policy: (500, 'disco-updates'), (500, 'disco-security'), (500, 'disco'), 
(100, 'disco-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-13-generic (SMP w/24 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.131ubuntu19
ii  udev 240-6ubuntu5
diff -Nru 
systemd-241/debian/patches/ask-password-prevent-buffer-overrow-when-reading-fro.patch
 
systemd-241/debian/patches/ask-password-prevent-buffer-overrow-when-reading-fro.patch
--- 
systemd-241/debian/patches/ask-password-prevent-buffer-overrow-when-reading-fro.patch
   1969-12-31 19:00:00.0 -0500
+++ 
systemd-241/debian/patches/ask-password-prevent-buffer-overrow-when-reading-fro.patch
   2019-05-29 11:44:09.0 -0400
@@ -0,0 +1,35 @@
+From 59c55e73eaee345e1ee67c23eace8895ed499693 Mon Sep 17 00:00:00 2001
+From: Thadeu Lima de Souza Cascardo 
+Date: Mon, 13 May 2019 16:58:01 -0300
+Subject: [PATCH] ask-password: prevent buffer overrow when reading from
+ keyring
+
+When we read from keyring, a temporary buffer is allocated in order to
+determine the size needed for the entire data. However, when zeroing that area,
+we use the data size returned by the read instead of the lesser size allocate
+for the buffer.
+
+That will cause memory corruption that causes systemd-cryptsetup to crash
+either when a single large password is used or when multiple passwords have
+already been pushed to the keyring.
+
+Signed-off-by: Thadeu Lima de Souza Cascardo 
+
+Origin: upstream, 
https://github.com/systemd/systemd/commit/59c55e73eaee345e1ee67c23eace8895ed499693
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1814373
+
+---
+ src/shared/ask-password-api.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/shared/ask-password-api.c
 b/src/shared/ask-password-api.c
+@@ -81,7 +81,7 @@
+ if (n < m)
+ break;
+ 
+-explicit_bzero_safe(p, n);
++explicit_bzero_safe(p, m);
+ free(p);
+ m *= 2;
+ }
diff -Nru systemd-241/debian/patches/series systemd-241/debian/patches/series
--- systemd-241/debian/patches/series   2019-05-24 16:58:59.0 -0400
+++ systemd-241/debian/patches/series   2019-05-29 11:44:29.0 -0400
@@ -35,3 +35,4 @@
 debian/Let-graphical-session-pre.target-be-manually-started.patch
 debian/Add-env-variable-for-machine-ID-path.patch
 debian/Drop-seccomp-system-call-filter-for-udev.patch
+ask-password-prevent-buffer-overrow-when-reading-fro.patch


Bug#927883: knockd: Change ProtectSystem=true and add CAP_SYS_MODULE

2019-04-24 Thread Dan Streetman
Package: knockd
Version: 0.7-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

any knockd configuration rules that call ufw fail because any ufw changes 
always update the ufw conf files in /etc/ufw/, but the knockd systemd service 
is started with ProtectSystem=full.

knockd's systemd service restricts its capabilities, so it's unable to load 
modules needed for changing iptables rules, e.g. ip6_tables module


In Ubuntu, the attached patch was applied to achieve the following:


  * d/knockd.service:
- Change ProtectSystem to 'true', to allow using ufw in knockd rules
  (LP: #1823051)
- Add CAP_SYS_MODULE so knockd can load iptables modules if needed
  (LP: #1825974)


Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers disco-updates
  APT policy: (500, 'disco-updates'), (500, 'disco-security'), (500, 'disco')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-8-generic (SMP w/24 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru knockd-0.7/debian/control knockd-0.7/debian/control
--- knockd-0.7/debian/control   2016-11-17 04:54:44.0 -0500
+++ knockd-0.7/debian/control   2019-04-23 06:31:56.0 -0400
@@ -1,8 +1,7 @@
 Source: knockd
 Section: net
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Leo Antunes 
+Maintainer: Leo Antunes 
 Build-Depends: debhelper (>= 9.20160709~), autotools-dev, libpcap0.8-dev
 Standards-Version: 3.9.8
 Homepage: http://www.zeroflux.org/projects/knock
diff -Nru knockd-0.7/debian/knockd.service knockd-0.7/debian/knockd.service
--- knockd-0.7/debian/knockd.service2019-03-10 11:13:50.0 -0400
+++ knockd-0.7/debian/knockd.service2019-04-23 06:31:56.0 -0400
@@ -9,8 +9,8 @@
 ExecReload=/bin/kill -HUP $MAINPID
 KillMode=mixed
 SuccessExitStatus=0 2 15
-ProtectSystem=full
-CapabilityBoundingSet=CAP_NET_RAW CAP_NET_ADMIN
+ProtectSystem=true
+CapabilityBoundingSet=CAP_NET_RAW CAP_NET_ADMIN CAP_SYS_MODULE
 
 [Install]
 WantedBy=multi-user.target


Bug#925966: autopkgtest-buildvm-ubuntu-cloud: restore support for precise, trusty

2019-03-29 Thread Dan Streetman
Package: autopkgtest
Version: 5.10
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

creation of qemu imgs for use with autopkgtest-virt-qemu is done with the 
autopkgtest-buildvm-ubuntu-cloud program. This was dropped in version 5.6:

  [ Martin Pitt ]
  * autopkgtest-buildvm-ubuntu-cloud: Drop obsolete Ubuntu release names

however, precise and trusty are not 'obsolete Ubuntu release names' just yet.

In Ubuntu, the attached patch was applied to achieve the following:

  * autopkgtest-buildvm-ubuntu-cloud: work with precise and trusty;
they aren't dead yet!
(LP: #1822331)


Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers disco
  APT policy: (500, 'disco')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-13-generic (SMP w/24 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Binary files 
/tmp/E_Ri6gEHkY/autopkgtest-5.10/lib/__pycache__/adtlog.cpython-37.pyc and 
/tmp/mRDDcPm7fM/autopkgtest-5.10ubuntu0+bug1822331v20190329b1/lib/__pycache__/adtlog.cpython-37.pyc
 differ
Binary files 
/tmp/E_Ri6gEHkY/autopkgtest-5.10/lib/__pycache__/VirtSubproc.cpython-37.pyc and 
/tmp/mRDDcPm7fM/autopkgtest-5.10ubuntu0+bug1822331v20190329b1/lib/__pycache__/VirtSubproc.cpython-37.pyc
 differ
diff -Nru autopkgtest-5.10/tools/autopkgtest-buildvm-ubuntu-cloud 
autopkgtest-5.10ubuntu0+bug1822331v20190329b1/tools/autopkgtest-buildvm-ubuntu-cloud
--- autopkgtest-5.10/tools/autopkgtest-buildvm-ubuntu-cloud 2019-02-25 
09:05:15.0 -0500
+++ 
autopkgtest-5.10ubuntu0+bug1822331v20190329b1/tools/autopkgtest-buildvm-ubuntu-cloud
2019-03-29 10:19:14.0 -0400
@@ -150,7 +150,7 @@
 
 
 def download_image(cloud_img_url, release, arch):
-if release in ['xenial']:
+if release in ['precise', 'trusty', 'xenial']:
 diskname = '%s-server-cloudimg-%s-disk1.img' % (release, arch)
 else:
 # images were renamed in Ubuntu 16.10


Bug#924400: knockd: systemd service script should use After=network-online.target, not network.target

2019-03-12 Thread Dan Streetman
Package: knockd
Version: 0.7-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

The knockd package systemd service assigns knockd to start After 
'network.target',
but the system's actual networking is not guaranteed or even expected to be up
after the network.target; instead knockd should start After 
'network-online.target'.

In Ubuntu, the attached patch was applied to achieve the following:

  * Fix knockd.service to use After=network-online.target (LP: #1819345)


Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers disco
  APT policy: (500, 'disco')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-13-generic (SMP w/24 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru knockd-0.7/debian/control knockd-0.7/debian/control
--- knockd-0.7/debian/control   2016-11-17 04:54:44.0 -0500
+++ knockd-0.7/debian/control   2019-03-12 11:11:55.0 -0400
@@ -1,8 +1,7 @@
 Source: knockd
 Section: net
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Leo Antunes 
+Maintainer: Leo Antunes 
 Build-Depends: debhelper (>= 9.20160709~), autotools-dev, libpcap0.8-dev
 Standards-Version: 3.9.8
 Homepage: http://www.zeroflux.org/projects/knock
diff -Nru knockd-0.7/debian/knockd.service knockd-0.7/debian/knockd.service
--- knockd-0.7/debian/knockd.service2016-10-08 10:05:00.0 -0400
+++ knockd-0.7/debian/knockd.service2019-03-12 11:11:55.0 -0400
@@ -1,6 +1,6 @@
 [Unit]
 Description=Port-Knock Daemon
-After=network.target
+After=network-online.target
 Documentation=man:knockd(1)
 
 [Service]


Bug#922801: debian/network/if-pre-up.d/vlan: add missing biosdevname case matches

2019-02-20 Thread Dan Streetman
Package: vlan
Version: 2.0.4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

The if-pre-up.d/vlan script is missing some of the biosdevname interface names.


Thanks for considering the patch.
diff -Nru vlan-2.0.4/debian/network/if-pre-up.d/vlan 
vlan-2.0.4ubuntu1/debian/network/if-pre-up.d/vlan
--- vlan-2.0.4/debian/network/if-pre-up.d/vlan  2019-02-04 12:11:29.0 
+0100
+++ vlan-2.0.4ubuntu1/debian/network/if-pre-up.d/vlan   2019-02-20 
20:08:02.0 +0100
@@ -19,7 +19,7 @@
 mkdir -p "$STATEDIR" && echo "VLAN_PLUS_VID_NO_PAD" > "$STATEDIR/name-type"
 VLANID=`echo $IFACE|sed "s/vlan0*//"`
   ;;
-  eth*.0*|bond*.0*|wlan*.0*)
+  eth*.0*|bond*.0*|wlan*.0*|em*.0*|p[0-9]*.0*)
 # Silently ignore interfaces which ifupdown handles on its own
 # If IF_BRIDGE_PORTS is set, probably we're called by bridge-utils
 [ -z "$IF_VLAN_RAW_DEVICE" -a -z "$IF_BRIDGE_PORTS" ] && exit 0


Bug#915724: cups: MaxJobTime=0 results in jobs being cancelled immediately instead of never

2018-12-06 Thread Dan Streetman
Package: cups
Version: 2.2.9-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

Setting the cupsd option MaxJobTime to 0 should make the server wait
indefinitely for the job to be ready for print. Instead, after
updating job-cancel-after option with MaxJobTime=0 value it results
in immediate cancelling.


In Ubuntu, the attached patch was applied to achieve the following:

  [ Dariusz Gadomski ]
  * Fix handling of MaxJobTime 0 (LP: #1804576)

Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 
'cosmic'), (100, 'cosmic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-11-generic (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru cups-2.2.9/debian/patches/fix-handling-of-MaxJobTime.patch 
cups-2.2.9/debian/patches/fix-handling-of-MaxJobTime.patch
--- cups-2.2.9/debian/patches/fix-handling-of-MaxJobTime.patch  1969-12-31 
19:00:00.0 -0500
+++ cups-2.2.9/debian/patches/fix-handling-of-MaxJobTime.patch  2018-12-06 
03:14:58.0 -0500
@@ -0,0 +1,36 @@
+Description: Fix handling of MaxJobTime 0
+ Setting MaxJobTime to 0 resulted in immediate job cancellation
+ instead of disabling timeout-based cancelation (as per documentation).
+ .
+ cups (2.2.9-3ubuntu1) disco; urgency=medium
+ .
+   * Fix handling of MaxJobTime 0 (LP: #1804576)
+Origin: upstream, 
https://github.com/apple/cups/commit/8c7143551ab03423990c62923209363d760f925f
+Bug: https://github.com/apple/cups/issues/5438
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1804576
+
+--- cups-2.2.9.orig/scheduler/job.c
 cups-2.2.9/scheduler/job.c
+@@ -5130,8 +5130,10 @@ update_job(cupsd_job_t *job)/* I - Job
+ 
+ if (cancel_after)
+ job->cancel_time = time(NULL) + ippGetInteger(cancel_after, 0);
+-  else
++  else if (MaxJobTime > 0)
+ job->cancel_time = time(NULL) + MaxJobTime;
++  else
++job->cancel_time = 0;
+ }
+ }
+   }
+--- cups-2.2.9.orig/scheduler/printers.c
 cups-2.2.9/scheduler/printers.c
+@@ -3445,7 +3445,7 @@ add_printer_defaults(cupsd_printer_t *p)
+"document-format-default", NULL, "application/octet-stream");
+ 
+   if (!cupsGetOption("job-cancel-after", p->num_options, p->options))
+-ippAddInteger(p->attrs, IPP_TAG_PRINTER, IPP_TAG_INTEGER,
++ippAddInteger(p->attrs, IPP_TAG_PRINTER, MaxJobTime > 0 ? IPP_TAG_INTEGER 
: IPP_TAG_NOVALUE,
+ "job-cancel-after-default", MaxJobTime);
+ 
+   if (!cupsGetOption("job-hold-until", p->num_options, p->options))
diff -Nru cups-2.2.9/debian/patches/series cups-2.2.9/debian/patches/series
--- cups-2.2.9/debian/patches/series2018-12-05 16:45:00.0 -0500
+++ cups-2.2.9/debian/patches/series2018-12-06 03:14:58.0 -0500
@@ -38,3 +38,4 @@
 0038-The-lp-and-lpr-commands-now-provide-better-error-mes.patch
 0039-Fix-E-option-Issue-5440.patch
 manpage-translations.patch
+fix-handling-of-MaxJobTime.patch


Bug#915669: open-iscsi: system with iSCSI DHCP iBFT does not contain DNS search domain at runtime

2018-12-05 Thread Dan Streetman
Package: open-iscsi
Version: 2.0.874-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

iBFT has no mechanism to provide the DNS search domain, so when open-iscsi 
creates
a /run/net-$DEVICE.conf file (which will never contain any value for 
DOMAINSEARCH)
it prevents ipconfig from running, and creating its own .conf file which *does*
contain a DNS search domain (if the dhcp server provides one).  At runtime, if
no dhcp client is specified to run for the interface (it does not need to, since
open-iscsi configured the networking from the initramfs), then /etc/resolv.conf
will have no DNS search domain.

In Ubuntu, the attached patch was applied to achieve the following:

  [Scott Moser]
  * debian/extra/initramfs.local-top: handle iSCSI iBFT DHCP to correctly
run ipconfig to gather all DHCP config info, including DNS search
domain, which iBFT can't provide.  (LP: #1806777)


Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 
'cosmic'), (100, 'cosmic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-11-generic (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru open-iscsi-2.0.874/debian/control open-iscsi-2.0.874/debian/control
--- open-iscsi-2.0.874/debian/control   2018-11-14 16:50:29.0 -0500
+++ open-iscsi-2.0.874/debian/control   2018-12-05 11:28:12.0 -0500
@@ -1,8 +1,7 @@
 Source: open-iscsi
 Section: net
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian iSCSI Maintainers 

+Maintainer: Debian iSCSI Maintainers 

 Uploaders: Ritesh Raj Sarraf ,
Christian Seiler 
 Build-Depends: autotools-dev,
diff -Nru open-iscsi-2.0.874/debian/extra/initramfs.local-top 
open-iscsi-2.0.874/debian/extra/initramfs.local-top
--- open-iscsi-2.0.874/debian/extra/initramfs.local-top 2018-11-14 
16:50:29.0 -0500
+++ open-iscsi-2.0.874/debian/extra/initramfs.local-top 2018-12-05 
11:28:12.0 -0500
@@ -93,6 +93,7 @@
. /scripts/functions
 
udevadm settle
+   IBFT_DHCP_DEVICE=""
 
if [ -n "$ISCSI_AUTO" ] ; then
# try to auto-configure network interface based
@@ -136,7 +137,13 @@
echo "UPTIME='${UPTIME}'"
echo "DHCPLEASETIME='${DHCPLEASETIME}'"
echo "DOMAINSEARCH=''"
-   } > "/run/net-${DEVICE}.conf"
+   } > "/run/net-${DEVICE}.conf.ibft"
+   if [ "$PROTO" != "dhcp" -a "$DHCPLEASETIME" = 
"0" ]; then
+   # this is static ibft configuration.
+   mv "/run/net-${DEVICE}.conf.ibft" 
"/run/net-${DEVICE}.conf"
+   else
+   IBFT_DHCP_DEVICE="$DEVICE"
+   fi
echo "${DEVICE}" > 
/run/initramfs/open-iscsi.interface
# iscsistart -N doesn't set the default 
gateway. Therefore,
# we need to add it ourselves. However, the ip 
command is
@@ -172,9 +179,23 @@
 
# run configure_networking even if we have iscsi_auto, because there
# could be other network interfaces that need to be configured
-   # manually
+   # also, if we set up DHCP iBFT, we need ipconfig to run so it creates
+   # a proper /run/net-${DEVICE}.conf file that includes the DNS search
+   # domain, which we don't get in our iBFT data (see LP: #1806777)
configure_networking
 
+   if [ -n "$IBFT_DHCP_DEVICE" ]; then
+   if ! [ -e "/run/net-${DEVICE}.conf" ] ; then
+   echo "ipconfig dhcp failed, using iSCSI iBFT config - 
DNS search domain may be missing at runtime" >&2
+   # We have DHCP iBFT, but ipconfig DHCP failed;
+   # so we should fallback to just using the iBFT config,
+   # though that will not include the DNS search domain
+   mv "/run/net-${DEVICE}.conf.ibft" 
"/run/net-${DEVICE}.conf"
+   # need to re-run configure_networking to process conf 
file
+   configure_networking
+   fi
+   fi
+
# Save network device we configured via configure_networking, but only
# if we didn't already get one from autoconfiguration (then we always
# prefer that).


Bug#915049: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled

2018-11-29 Thread Dan Streetman
Package: systemd
Version: 239-14
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. This 
makes non-EDNS clients (nslookup) receive a "shortened" answer even when UDP 
returns a truncated reply for a new TCP query. For instance,

- If the client supports EDNS:

$ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
30

- If the client does not support EDNS:

$ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
29

In the second case, no-EDNS, TCP should provide the complete answer, but it's 
capped at UDP's size.

This leads to complete failures for common dns lookups, e.g.:

telnet testing.irongiantdesign.com
telnet: could not resolve testing.irongiantdesign.com/telnet: Temporary failure 
in name resolution

-- Package-specific info:


Ubuntu bug for this is LP: #1804487
https://bugs.launchpad.net/systemd/+bug/1804487

upstream systemd bug is 10816
https://github.com/systemd/systemd/issues/10816

This was debugged and fixed upstream by Victor Tapia.

Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 'cosmic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-11-generic (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.131ubuntu15
ii  udev 239-7ubuntu10.4
diff -Nru 
systemd-239/debian/patches/debian/increase-TCP-stub-payload-size.patch 
systemd-239/debian/patches/debian/increase-TCP-stub-payload-size.patch
--- systemd-239/debian/patches/debian/increase-TCP-stub-payload-size.patch  
1969-12-31 19:00:00.0 -0500
+++ systemd-239/debian/patches/debian/increase-TCP-stub-payload-size.patch  
2018-11-29 09:42:01.0 -0500
@@ -0,0 +1,34 @@
+commit e6eed9445956cfa496e1db933bfd3530db23bfce
+Author: Victor Tapia 
+Date:   Wed Nov 21 14:01:04 2018 +0100
+
+resolved: Increase size of TCP stub replies
+
+DNS_PACKET_PAYLOAD_SIZE_MAX is limiting the size of the stub replies to
+512 with EDNS off or 4096 with EDNS on, without checking the protocol
+used. This makes TCP replies for clients without EDNS support to be
+limited to 512, making the truncate flag useless if the query result is
+bigger than 512 bytes.
+
+This commit increases the size of TCP replies to DNS_PACKET_SIZE_MAX
+
+Fixes: #10816
+
+--- a/src/resolve/resolved-dns-packet.h
 b/src/resolve/resolved-dns-packet.h
+@@ -120,11 +120,14 @@
+ 
+ static inline uint16_t DNS_PACKET_PAYLOAD_SIZE_MAX(DnsPacket *p) {
+ 
+-/* Returns the advertised maximum datagram size for replies, or the 
DNS default if there's nothing defined. */
++/* Returns the advertised maximum size for replies, or the DNS 
default if there's nothing defined. */
+ 
+ if (p->opt)
+ return MAX(DNS_PACKET_UNICAST_SIZE_MAX, p->opt->key->class);
+ 
++if (p->ipproto == IPPROTO_TCP)
++return DNS_PACKET_SIZE_MAX;
++
+ return DNS_PACKET_UNICAST_SIZE_MAX;
+ }
+ 
diff -Nru systemd-239/debian/patches/series systemd-239/debian/patches/series
--- systemd-239/debian/patches/series   2018-11-20 13:44:39.0 -0500
+++ systemd-239/debian/patches/series   2018-11-29 09:42:01.0 -0500
@@ -52,3 +52,4 @@
 debian/Revert-udev-rules-Permission-changes-for-dev-dri-renderD.patch
 debian/Revert-systemctl-when-removing-enablement-or-mask-symlink.patch
 debian/Drop-seccomp-system-call-filter-for-udev.patch
+debian/increase-TCP-stub-payload-size.patch


Bug#900065: drbd-utils: newer udev rules handling causes drbd to create incorrect symlink

2018-05-25 Thread Dan Streetman
Package: drbd-utils
Version: 8.9.10-3
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Maintainer,

Newer udev handling of rules that create SYMLINKs causes the way drbd creates 
symlinks
to fail, by creating a single symlink with whitespace inside the symlink, 
instead of
multiple symlinks.

This upstream patch applies cleanly the this version of drbd-utils in debian.

  * Fix creation of drbd symlinks, broken by newer udev

Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 'bionic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-19-generic (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
drbd-utils-8.9.10/debian/patches/0001-v9-fix-nonsense-symlinks-due-to-udev-change-of-strin.patch
 
drbd-utils-8.9.10/debian/patches/0001-v9-fix-nonsense-symlinks-due-to-udev-change-of-strin.patch
--- 
drbd-utils-8.9.10/debian/patches/0001-v9-fix-nonsense-symlinks-due-to-udev-change-of-strin.patch
1969-12-31 19:00:00.0 -0500
+++ 
drbd-utils-8.9.10/debian/patches/0001-v9-fix-nonsense-symlinks-due-to-udev-change-of-strin.patch
2018-05-25 11:07:21.0 -0400
@@ -0,0 +1,67 @@
+From: Lars Ellenberg 
+Subject: [PATCH] v9: fix nonsense symlinks due to udev change of
+ string_escape=none -> replace
+Bug-Ubuntu: https://launchpad.net/bugs/1673255
+Origin: upstream, 
https://github.com/LINBIT/drbd-utils/commit/05c0797248af6f4e3b5b04545fe068dba41e3d81
+diff --git a/scripts/drbd.rules.in b/scripts/drbd.rules.in
+index cdf4af61..46444bd1 100644
+--- a/scripts/drbd.rules.in
 b/scripts/drbd.rules.in
+@@ -6,7 +6,12 @@ KERNEL!="drbd*", GOTO="drbd_end"
+ IMPORT{program}="@sbindir@/drbdadm sh-udev minor-%m"
+ 
+ # Use symlink from the environment if available
+-ENV{SYMLINK}!="", SYMLINK="$env{SYMLINK}", GOTO="have_symlink"
++# some udev version thought it was a good idea to change a long established
++# default of string_escape=none to string_escape=replace :-/
++# therefore, recent enough drbdadm will no longer export space separated 
lists.
++ENV{SYMLINK_BY_DISK}!="", SYMLINK+="$env{SYMLINK_BY_DISK}"
++ENV{SYMLINK_BY_RES}!="", SYMLINK+="$env{SYMLINK_BY_RES}", GOTO="have_symlink"
++ENV{SYMLINK}!="", OPTIONS+="string_escape=none", SYMLINK="$env{SYMLINK}", 
GOTO="have_symlink"
+ 
+ # Legacy rules for older DRBD 8.3 & 8.4 when drbdadm sh-udev did not yet 
export SYMLINK
+ ENV{DISK}!="", SYMLINK+="drbd/by-disk/$env{DISK}"
+diff --git a/user/v9/drbdadm_main.c b/user/v9/drbdadm_main.c
+index 7a705fd8..d6d2f970 100644
+--- a/user/v9/drbdadm_main.c
 b/user/v9/drbdadm_main.c
+@@ -840,18 +840,31 @@ static int sh_udev(const struct cfg_ctx *ctx)
+   else
+   printf("DEVICE=drbd%u\n", vol->device_minor);
+ 
++  /* in case older udev rules are still in place,
++   * but do not yet have the work-around for the
++   * udev default change of "string_escape=none" -> "replace",
++   * populate plain "SYMLINK" with just the "by-res" one. */
+   printf("SYMLINK=");
+   if (vol->implicit)
+-  printf("drbd/by-res/%s", res->name);
++  printf("drbd/by-res/%s\n", res->name);
+   else
+-  printf("drbd/by-res/%s/%u", res->name, vol->vnr);
++  printf("drbd/by-res/%s/%u\n", res->name, vol->vnr);
++
++  /* repeat, with _BY_RES */
++  printf("SYMLINK_BY_RES=");
++  if (vol->implicit)
++  printf("drbd/by-res/%s\n", res->name);
++  else
++  printf("drbd/by-res/%s/%u\n", res->name, vol->vnr);
++
++  /* and add the _BY_DISK one explicitly */
+   if (vol->disk) {
++  printf("SYMLINK_BY_DISK=");
+   if (!strncmp(vol->disk, "/dev/", 5))
+-  printf(" drbd/by-disk/%s", vol->disk + 5);
++  printf("drbd/by-disk/%s\n", vol->disk + 5);
+   else
+-  printf(" drbd/by-disk/%s", vol->disk);
++  printf("drbd/by-disk/%s\n", vol->disk);
+   }
+-  printf("\n");
+ 
+   return 0;
+ }
+-- 
+2.17.0
+
diff -Nru drbd-utils-8.9.10/debian/patches/series 
drbd-utils-8.9.10/debian/patches/series
--- drbd-utils-8.9.10/debian/patches/series 2017-05-12 07:43:00.0 
-0400
+++ drbd-utils-8.9.10/debian/patches/series 2018-05-25 11:02:41.0 
-0400
@@ -5,3 +5,4 @@
 initscript-remove-path.patch
 reproducible-build
 initscript-add-start-runlevels.patch
+0001-v9-fix-nonsense-symlinks-due-to-udev-change-of-strin.patch


Bug#896433: ifupdown: ifquery can't be called recursively from ifup/ifdown, but if-pre/up.d scripts call it

2018-04-23 Thread Dan Streetman
On Sun, Apr 22, 2018 at 3:24 PM, Guus Sliepen <g...@debian.org> wrote:
> On Fri, Apr 20, 2018 at 04:52:24PM -0400, Dan Streetman wrote:
>
>> Scripts in the if-pre-up.d and if-up.d dirs call ifquery directly, or call 
>> it indirectly
>> through other scripts.  However ifquery tries to lock each interface and 
>> exits with
>> error if it's called from ifup or ifdown.  Since ifquery doesn't change 
>> anything,
>> there is no reason interface locks need to be taken; ifquery can be safely 
>> run
>> recurseively from ifup/ifdown.
>
> You're right, it should be possible to run ifquery recursively. But it
> should still ensure the interface is locked before querying it, to
> ensure consistency.
>
>> In Ubuntu, the attached patch was applied to achieve the following:
>
> The patch avoids locking at all when no_act == true. Consider this:
>
> iface foo inet ...
> pre-up ifquery --state bar
>
> iface bar inet ...
>
> Now if I call ifup foo and ifup bar at the same time, then the ifquery
> might theoretically read a half-written /run/network/ifstate.bar.

Eh?

ifquery --state doesn't use the ifstate.* files.  It reads state from
the global ifstate file.

main() checks (state_query) and then calls do_state(argc, argv) to
actually print out the current state of any/all specified interfaces
(all if none specified).

The do_state() function calls read_all_state() to actually get the
state info of all interfaces.

The read_all_state() function first locks the global .ifstate.lock
file, then opens and reads the global /run/network/ifstate file (then
closes both).  It does not open or read any of the ifstate.* files.

In fact ifquery --state returns do_state(), so it will never even
reach the call to do_interface() that my patch adjusts.

Am I misunderstanding your assertion?

> Granted, the change of this is extremely small, and one could also
> question whether it makes sense to run ifquery in this way at all, since
> even if it did read a consistent /run/network/ifstate.bar, it could
> either read the state as being up or down depending on whether ifup bar
> finished before or after ifquery. But it's not hard to do it correctly,
> so I'll make it so it only avoids locking if it detects recursion.
>
>> Thanks for considering the patch.
>
> Thanks for sending the patch :)
>
> --
> Met vriendelijke groet / with kind regards,
>   Guus Sliepen <g...@debian.org>



Bug#896434: vlan interfaces must be created in raw-device ifup post, not during raw-device udev processing

2018-04-20 Thread Dan Streetman
Package: vlan
Version: 1.9-3.2
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

Currently, vlan interfaces are created by /lib/udev/vlan-network-interface 
during
udev detection/processing of the vlan's raw-device.  However this can lead to
a race condition of both the raw-device and its vlan interface(s) being ifup'ed,
and if a vlan interface is brought up before its raw-device, and that raw-device
is taken down during ifup (such as is required for e.g. bonds with certain 
params),
any additional configuration on the vlan(s) will be lost when they are taken 
down.
For example, if a vlan has a gateway set, it will be lost if the vlan is ifup'ed
before its raw-device (bond) is ifup'ed.
See https://bugs.launchpad.net/bugs/1573272 for details.

In Ubuntu, the attached patch was applied to achieve the following:

  * Revert change for lp1573272; instead fix by redesigning when vlan
interfaces are created; after raw-device ifup, not during raw-device
udev processing. (LP: #1701023)

There are multiple bugs related to this vlan change, all summarized here:
https://bugs.launchpad.net/bugs/1701023

Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers bionic
  APT policy: (500, 'bionic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-13-generic (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -u vlan-1.9/debian/control vlan-1.9/debian/control
--- vlan-1.9/debian/control
+++ vlan-1.9/debian/control
@@ -1,8 +1,7 @@
 Source: vlan
 Section: misc
 Priority: extra
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Ard van Breemen 
+Maintainer: Ard van Breemen 
 Uploaders: Loic Minier 
 Build-Depends: debhelper (>= 5)
 Standards-Version: 3.7.2
diff -u vlan-1.9/debian/network/if-pre-up.d/vlan 
vlan-1.9/debian/network/if-pre-up.d/vlan
--- vlan-1.9/debian/network/if-pre-up.d/vlan
+++ vlan-1.9/debian/network/if-pre-up.d/vlan
@@ -60,9 +60,8 @@
 exit 1
 fi
 if [ ! -e "/sys/class/net/$IFACE" ]; then
-# Try ifup for the raw device, if it fails then bring it up directly
-# this is required e.g. there is no configuration for the raw device
-ifup $IF_VLAN_RAW_DEVICE || ip link set up dev $IF_VLAN_RAW_DEVICE
+# we cannot call ifup for the raw-device here, see LP: #1701023
+ip link set up dev $IF_VLAN_RAW_DEVICE
 vconfig add $IF_VLAN_RAW_DEVICE $VLANID
 fi
 fi
diff -u vlan-1.9/debian/vlan-network-interface 
vlan-1.9/debian/vlan-network-interface
--- vlan-1.9/debian/vlan-network-interface
+++ vlan-1.9/debian/vlan-network-interface
@@ -25,10 +25,21 @@
 
-# Now that the environment is ready, call the pre-up script to create the 
vlan
-export IFACE IF_VLAN_RAW_DEVICE
-
-# Create the VLANs related to the interface
-if [ "$IF_VLAN_RAW_DEVICE" = "$INTERFACE" ] || \
-echo $IFACE | grep -q $INTERFACE; then
-/etc/network/if-pre-up.d/vlan
+# If there is no vlan-raw-device defined, check for vlan-formatted name
+# for example, eth1.123
+if [ -z "$IF_VLAN_RAW_DEVICE" ]; then
+IF_VLAN_RAW_DEVICE=${IFACE%%.*}
+[ "$IFACE" = "$IF_VLAN_RAW_DEVICE" ] && continue
 fi
+
+# Check if this (vlan) $IFACE uses raw-device $INTERFACE
+[ "$IF_VLAN_RAW_DEVICE" != "$INTERFACE" ] && continue
+
+# If we're being called directly from udev, we only want to create the
+# vlan interface if there is no associated ifupdown config for the
+# raw-device; otherwise the ifup for the raw-device will create the
+# vlan interface(s)
+[ "$1" = "UDEV" ] && ifquery $IF_VLAN_RAW_DEVICE && continue
+
+# Create the VLAN interface(s) related to the raw-device interface
+export IFACE IF_VLAN_RAW_DEVICE
+/etc/network/if-pre-up.d/vlan
 done
diff -u vlan-1.9/debian/vlan.vlan-network-interface.udev 
vlan-1.9/debian/vlan.vlan-network-interface.udev
--- vlan-1.9/debian/vlan.vlan-network-interface.udev
+++ vlan-1.9/debian/vlan.vlan-network-interface.udev
@@ -1 +1 @@
-ACTION=="add", SUBSYSTEM=="net", RUN+="vlan-network-interface"
+ACTION=="add", SUBSYSTEM=="net", RUN+="vlan-network-interface UDEV"
only in patch2:
unchanged:
--- vlan-1.9.orig/debian/network/if-up.d/vlan
+++ vlan-1.9/debian/network/if-up.d/vlan
@@ -0,0 +1,8 @@
+#!/bin/sh
+
+# after vlan-raw-device interface is ifup'ed, then
+# create any associated vlan interfaces
+# (LP: #1701032)
+if [ -x /lib/udev/vlan-network-interface ]; then
+  env INTERFACE=$IFACE /lib/udev/vlan-network-interface
+fi


Bug#896433: ifupdown: ifquery can't be called recursively from ifup/ifdown, but if-pre/up.d scripts call it

2018-04-20 Thread Dan Streetman
Package: ifupdown
Version: 0.8.17
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

Scripts in the if-pre-up.d and if-up.d dirs call ifquery directly, or call it 
indirectly
through other scripts.  However ifquery tries to lock each interface and exits 
with
error if it's called from ifup or ifdown.  Since ifquery doesn't change 
anything,
there is no reason interface locks need to be taken; ifquery can be safely run
recurseively from ifup/ifdown.

In Ubuntu, the attached patch was applied to achieve the following:

  * Allow ifquery to be called recursively from ifup/ifdown.
Many of the if-pre-up.d/if-up.d scripts call ifquery directly,
or indirectly through other scripts they call; these ifquery calls
will fail.  This changes that to allow ifquery to run, since
ifquery does not change anything, it can be safely called
from ifup/ifdown.  (LP: #1701023)

Please see
https://bugs.launchpad.net/ubuntu/bionic/+source/ifupdown/+bug/1701023
for details on why this patch is required.

Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers bionic
  APT policy: (500, 'bionic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-13-generic (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ifupdown-0.8.17ubuntu1/debian/control 
ifupdown-0.8.17ubuntu1+hf1701023v20180420b1/debian/control
--- ifupdown-0.8.17ubuntu1/debian/control   2018-03-21 17:38:53.0 
-0400
+++ ifupdown-0.8.17ubuntu1+hf1701023v20180420b1/debian/control  2018-04-20 
16:37:59.0 -0400
@@ -1,8 +1,7 @@
 Source: ifupdown
 Section: admin
 Priority: important
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Guus Sliepen 
+Maintainer: Guus Sliepen 
 Standards-Version: 3.9.8
 Build-Depends: debhelper (>= 9.20120410~), dh-systemd
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/ifupdown.git
diff -Nru ifupdown-0.8.17ubuntu1/main.c 
ifupdown-0.8.17ubuntu1+hf1701023v20180420b1/main.c
--- ifupdown-0.8.17ubuntu1/main.c   2016-11-25 06:16:17.0 -0500
+++ ifupdown-0.8.17ubuntu1+hf1701023v20180420b1/main.c  2018-04-20 
16:37:55.0 -0400
@@ -785,6 +785,7 @@
/* Split into physical and logical interface */
 
char iface[80], liface[80];
+   FILE *lock = NULL, *plock = NULL;
 
strncpy(iface, target_iface, sizeof(iface));
iface[sizeof(iface) - 1] = '\0';
@@ -840,44 +841,44 @@
return false;
}
 
+   if (!no_act) {
+   /* Bail out if we are being called recursively on the same 
interface */
 
-   /* Bail out if we are being called recursively on the same interface */
-
-   char envname[160];
-   char *siface = strdup(iface);
-   sanitize_file_name(siface);
-   snprintf(envname, sizeof envname, "IFUPDOWN_%s", siface);
-   free(siface);
-   char *envval = getenv(envname);
-   if(envval && is_locked(iface)) {
-   fprintf(stderr, "%s: recursion detected for interface %s in %s 
phase\n", argv0, iface, envval);
-   return false;
-   }
-
-   /* Are we configuring a VLAN interface? If so, lock the parent 
interface as well. */
-
-   char piface[80];
-   FILE *plock = NULL;
-   strncpy(piface, iface, sizeof piface);
-   if ((pch = strchr(piface, '.'))) {
-   *pch = '\0';
-   snprintf(envname, sizeof envname, "IFUPDOWN_%s", piface);
+   char envname[160];
+   char *siface = strdup(iface);
+   sanitize_file_name(siface);
+   snprintf(envname, sizeof envname, "IFUPDOWN_%s", siface);
+   free(siface);
char *envval = getenv(envname);
-   if(envval && is_locked(piface)) {
-   fprintf(stderr, "%s: recursion detected for parent 
interface %s in %s phase\n", argv0, piface, envval);
+   if(envval && is_locked(iface)) {
+   fprintf(stderr, "%s: recursion detected for interface 
%s in %s phase\n", argv0, iface, envval);
return false;
}
 
-   plock = lock_interface(piface, NULL);
+   /* Are we configuring a VLAN interface? If so, lock the parent 
interface as well. */
+
+   char piface[80];
+   strncpy(piface, iface, sizeof piface);
+   if ((pch = strchr(piface, '.'))) {
+   *pch = '\0';
+   snprintf(envname, sizeof envname, "IFUPDOWN_%s", 
piface);
+   char *envval = getenv(envname);
+   if(envval && is_locked(piface)) {
+ 

Bug#783387: dhclient does not wait for ipv6 dad

2018-02-20 Thread Dan Streetman
This also requires the patch from this bug:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1718568



Bug#854010: Merge request for this bug

2017-11-21 Thread Dan Streetman
Please see this MR with the latest patches for this bug report:

https://code.launchpad.net/~ddstreet/ubuntu-dev-tools/+git/ubuntu-dev-tools/+merge/322863



Bug#863426: isc-dhcp: dhclient DHCPv6 does not work with interface alias

2017-06-07 Thread Dan Streetman
Package: isc-dhcp
Version: 4.3.5-3
Followup-For: Bug #863426
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Dear Maintainer,

an updated isc-dhcp patch is attached, that moves the interface alias
stripping to client/dhclient.c as soon as the parameter is parsed from argv.
This allows dhclient to handle the interface name with no alias at all times.
The previous patch failed to allow dhclient to release the interface.

Thanks for considering the patch.
diff -Nru isc-dhcp-4.3.5/debian/control isc-dhcp-4.3.5/debian/control
--- isc-dhcp-4.3.5/debian/control   2017-01-19 12:11:21.0 -0500
+++ isc-dhcp-4.3.5/debian/control   2017-06-07 16:38:45.0 -0400
@@ -1,8 +1,7 @@
 Source: isc-dhcp
 Section: net
 Priority: important
-Maintainer: Ubuntu Developers <ubuntu-devel-disc...@lists.ubuntu.com>
-XSBC-Original-Maintainer: Debian ISC DHCP maintainers 
<pkg-dhcp-de...@lists.alioth.debian.org>
+Maintainer: Debian ISC DHCP maintainers 
<pkg-dhcp-de...@lists.alioth.debian.org>
 Uploaders: Andrew Pollock <apoll...@debian.org>, Michael Gilbert 
<mgilb...@debian.org>
 Vcs-Git: https://anonscm.debian.org/pkg-dhcp/isc-dhcp.git
 Vcs-Browser: 
https://anonscm.debian.org/gitweb/?p=pkg-dhcp/isc-dhcp.git;a=summary
diff -Nru isc-dhcp-4.3.5/debian/patches/series 
isc-dhcp-4.3.5/debian/patches/series
--- isc-dhcp-4.3.5/debian/patches/series2017-01-19 12:11:21.0 
-0500
+++ isc-dhcp-4.3.5/debian/patches/series2017-06-07 16:38:38.0 
-0400
@@ -32,3 +32,4 @@
 dhcp-improved-xid-correct-byte-order.patch
 dhcp-4.2.4-dhclient-options-changed.patch
 ubuntu-dhcpd-conf.patch
+strip-interface-alias.patch
diff -Nru isc-dhcp-4.3.5/debian/patches/strip-interface-alias.patch 
isc-dhcp-4.3.5/debian/patches/strip-interface-alias.patch
--- isc-dhcp-4.3.5/debian/patches/strip-interface-alias.patch   1969-12-31 
19:00:00.0 -0500
+++ isc-dhcp-4.3.5/debian/patches/strip-interface-alias.patch   2017-06-07 
16:38:38.0 -0400
@@ -0,0 +1,39 @@
+Author: Dan Streetman <dan.street...@canonical.com>
+Description: Since isc-dhcp strips the interface alias from all
+  interfaces it enumerates, when comparing the cmdline interface
+  name to find the matching enumerated interface, the cmdline name
+  must have its alias stripped also.  Without this, DHCPv6 fails
+  when using an interface alias.
+Forwarded: yes
+Bug: [ISC bug tracking is private; bug email has been sent]
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1693819
+
+
+Index: isc-dhcp-4.3.5/client/dhclient.c
+===
+--- isc-dhcp-4.3.5.orig/client/dhclient.c
 isc-dhcp-4.3.5/client/dhclient.c
+@@ -447,15 +447,19 @@ main(int argc, char **argv) {
+ " requested interface %s", argv[i]);
+   } else {
+   struct interface_info *tmp = NULL;
++  int len;
+ 
+   status = interface_allocate(, MDL);
+   if (status != ISC_R_SUCCESS)
+   log_fatal("Can't record interface %s:%s",
+ argv[i], isc_result_totext(status));
+-  if (strlen(argv[i]) >= sizeof(tmp->name))
+-  log_fatal("%s: interface name too long (is %ld)",
+-argv[i], (long)strlen(argv[i]));
+-  strcpy(tmp->name, argv[i]);
++  /* strip any interface alias, e.g. eth1:1 -> eth1 */
++  len = strchrnul(argv[i], ':') - argv[i];
++  if (len >= sizeof(tmp->name))
++  log_fatal("%s: interface name too long (is %d)",
++argv[i], len);
++  strncpy(tmp->name, argv[i], len);
++  tmp->name[len] = 0;
+   if (interfaces) {
+   interface_reference(>next,
+   interfaces, MDL);


Bug#863426: isc-dhcp: dhclient DHCPv6 does not work with interface alias

2017-05-26 Thread Dan Streetman
Package: isc-dhcp
Version: 4.3.5-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Dear Maintainer,

dhclient does not work when doing DHCPv6 with an interface alias, e.g.

dhclient -6 -v eth0:1

fails.  The attached patch is required to fix it.

  * When comparing enumerated interface name with cmdline interface name,
the cmdline interface name alias extension must be stripped since all
enumerated interface names have their alias extension stripped.
Without this, DHCPv6 fails for interface aliases. (LP: #1693819)


Thanks for considering the patch.


-- System Information:
Debian Release: stretch/sid
  APT prefers zesty-updates
  APT policy: (500, 'zesty-updates'), (500, 'zesty-security'), (500, 'zesty'), 
(100, 'zesty-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-20-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru isc-dhcp-4.3.5/debian/control isc-dhcp-4.3.5/debian/control
--- isc-dhcp-4.3.5/debian/control   2017-01-19 12:11:21.0 -0500
+++ isc-dhcp-4.3.5/debian/control   2017-05-26 10:57:51.0 -0400
@@ -1,8 +1,7 @@
 Source: isc-dhcp
 Section: net
 Priority: important
-Maintainer: Ubuntu Developers <ubuntu-devel-disc...@lists.ubuntu.com>
-XSBC-Original-Maintainer: Debian ISC DHCP maintainers 
<pkg-dhcp-de...@lists.alioth.debian.org>
+Maintainer: Debian ISC DHCP maintainers 
<pkg-dhcp-de...@lists.alioth.debian.org>
 Uploaders: Andrew Pollock <apoll...@debian.org>, Michael Gilbert 
<mgilb...@debian.org>
 Vcs-Git: https://anonscm.debian.org/pkg-dhcp/isc-dhcp.git
 Vcs-Browser: 
https://anonscm.debian.org/gitweb/?p=pkg-dhcp/isc-dhcp.git;a=summary
diff -Nru isc-dhcp-4.3.5/debian/patches/series 
isc-dhcp-4.3.5/debian/patches/series
--- isc-dhcp-4.3.5/debian/patches/series2017-01-19 12:11:21.0 
-0500
+++ isc-dhcp-4.3.5/debian/patches/series2017-05-26 10:57:24.0 
-0400
@@ -32,3 +32,4 @@
 dhcp-improved-xid-correct-byte-order.patch
 dhcp-4.2.4-dhclient-options-changed.patch
 ubuntu-dhcpd-conf.patch
+strip-alias-when-comparing-interface-names.patch
diff -Nru 
isc-dhcp-4.3.5/debian/patches/strip-alias-when-comparing-interface-names.patch 
isc-dhcp-4.3.5/debian/patches/strip-alias-when-comparing-interface-names.patch
--- 
isc-dhcp-4.3.5/debian/patches/strip-alias-when-comparing-interface-names.patch  
1969-12-31 19:00:00.0 -0500
+++ 
isc-dhcp-4.3.5/debian/patches/strip-alias-when-comparing-interface-names.patch  
2017-05-26 10:57:32.0 -0400
@@ -0,0 +1,40 @@
+Author: Dan Streetman <dan.street...@canonical.com>
+Description: Since isc-dhcp strips the interface alias from all
+  interfaces it enumerates, when comparing the cmdline interface
+  name to find the matching enumerated interface, the cmdline name
+  must have its alias stripped also.  Without this, DHCPv6 fails
+  when using an interface alias.
+Forwarded: yes
+Bug: [ISC bug tracking is private; bug email has been sent]
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1693819
+
+---
+ common/discover.c | 15 ++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+Index: isc-dhcp-4.3.5/common/discover.c
+===
+--- isc-dhcp-4.3.5.orig/common/discover.c
 isc-dhcp-4.3.5/common/discover.c
+@@ -600,7 +600,20 @@ discover_interfaces(int state) {
+ 
+   /* See if we've seen an interface that matches this one. */
+   for (tmp = interfaces; tmp; tmp = tmp->next) {
+-  if (!strcmp(tmp->name, info.name))
++#if defined(sun) || defined(__linux)
++  char *s, n[IFNAMSIZ];
++
++  strcpy(n, tmp->name);
++  /* next_iface() strips the interface alias,
++   * so we mustn't include it when strcmp */
++  s = strchr(n, ':');
++  if (s != NULL) {
++  *s = '\0';
++  }
++#else
++  char *n = tmp->name;
++#endif /* defined(sun) || defined(__linux) */
++  if (!strcmp(n, info.name))
+   break;
+   }
+ 


Bug#859127: vlan loses config if raw device ifup's after vlan

2017-03-30 Thread Dan Streetman
Package: vlan
Version: 1.9-3.2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

The vlan pkg's /etc/network/if-pre-up.d/vlan script currently will bring
up the raw device before creating the vlan interface, using ip link up,
but if the raw device then is ifup'ed after the vlan interface, the raw
device may be taken down and back up, which will remove any vlan routes
or other configuration from the vlan.  This patch instead changes the
script to do a full ifup for the raw device, so that it is fully ready
before the vlan interface is created and configured.

This is created from Ubuntu launchpad bug 1573272:
https://bugs.launchpad.net/ubuntu/+source/vlan/+bug/1573272

In Ubuntu, the attached patch was applied to achieve the following:

  * In vlan ifupdown pre-up script, instead of calling ip link up for
raw device before creating vlan interface, do a full ifup for raw
device.  Otherwise, if raw device processes ifup after vlan device,
the raw device may be taken down and back up, which removes all vlan
routes and other configuration. (LP: #1573272)


Thanks for considering the patch.


-- System Information:
Debian Release: stretch/sid
  APT prefers yakkety-updates
  APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 
'yakkety'), (100, 'yakkety-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-44-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u vlan-1.9/debian/network/if-pre-up.d/vlan vlan-1.9/debian/network/if-pre-up.d/vlan
--- vlan-1.9/debian/network/if-pre-up.d/vlan
+++ vlan-1.9/debian/network/if-pre-up.d/vlan
@@ -60,7 +60,7 @@
 exit 1
 fi
 if [ ! -e "/sys/class/net/$IFACE" ]; then
-ip link set up dev $IF_VLAN_RAW_DEVICE
+ifup $IF_VLAN_RAW_DEVICE
 vconfig add $IF_VLAN_RAW_DEVICE $VLANID
 fi
 fi


Bug#854010: ubuntu-dev-tools: pull-lp-source not getting source pkg for binary name

2017-02-02 Thread Dan Streetman
Package: ubuntu-dev-tools
Version: 0.158
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

Calling pull-lp-source with the name of a binary package fails to get the
corresponding source package.

In Ubuntu, this is tracked with bug 1453330:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1453330

This patch corrects that so pull-lp-source will correctly lookup the source
package name for any binary package name provided.

Thanks for considering the patch.
diff -Nru ubuntu-dev-tools-0.157/pull-lp-source ubuntu-dev-tools-0.158/pull-lp-source
--- ubuntu-dev-tools-0.157/pull-lp-source	2016-05-09 00:56:05.0 -0400
+++ ubuntu-dev-tools-0.158/pull-lp-source	2017-02-02 16:52:52.0 -0500
@@ -40,25 +40,36 @@
 from ubuntutools.logger import Logger
 from ubuntutools.misc import split_release_pocket
 
+from launchpadlib.launchpad import Launchpad as LP
 
-def source_package_for(binary, release):
-"""Query DDE to find the source package for a particular binary
-Should really do this with LP, but it's not possible LP: #597041
-"""
-url = ('http://dde.debian.net/dde/q/udd/dist/d:ubuntu/r:%s/p:%s/?t=json'
-   % (release, binary))
-data = None
-try:
-data = json.load(urllib2.urlopen(url))['r']
-except urllib2.URLError, e:
-Logger.error('Unable to retrieve package information from DDE: '
- '%s (%s)', url, str(e))
-except ValueError, e:
-Logger.error('Unable to parse JSON response from DDE: '
- '%s (%s)', url, str(e))
-if not data:
+
+def getSPPH(lp, archive, package, version, series, pocket, try_binary=True):
+params = { 'exact_match': True, 'order_by_date': True, }
+if pocket:
+params['pocket'] = pocket
+if series:
+params['distro_series'] = series()
+else:
+params['version'] = version
+spphs = archive.getPublishedSources(source_name=package, **params)
+if spphs:
+return spphs[0]
+if not try_binary:
 return None
-return data[0]['source']
+
+# Didn't find any, maybe the package is a binary package name
+if series:
+del params['distro_series']
+archs = lp.load(series().architectures_collection_link).entries
+params['distro_arch_series'] = archs[0]['self_link']
+bpphs = archive.getPublishedBinaries(binary_name=package, **params)
+if bpphs:
+bpph_build = lp.load(bpphs[0].build_link)
+source_package = bpph_build.source_package_name
+return getSPPH(lp, archive, source_package, version, series, pocket,
+   try_binary=False)
+
+return None
 
 
 def main():
@@ -85,6 +96,7 @@
 
 # Login anonymously to LP
 Launchpad.login_anonymously()
+lp = LP.login_anonymously("pull-lp-source", "production")
 
 package = str(args[0]).lower()
 
@@ -106,29 +118,25 @@
 (release, pocket) = split_release_pocket(version, default=None)
 except PocketDoesNotExistError, e:
 pass
+
+distro = Distribution('ubuntu')
+archive = distro.getArchive()
+
+series = None
 if release in ubuntu_info.all:
-archive = Distribution('ubuntu').getArchive()
-try:
-spph = archive.getSourcePackage(package, release, pocket)
-except SeriesNotFoundException, e:
-Logger.error(str(e))
-sys.exit(1)
-except PackageNotFoundException, e:
-source_package = source_package_for(package, release)
-if source_package is not None and source_package != package:
-try:
-spph = archive.getSourcePackage(source_package, release,
-pocket)
-package = source_package
-except PackageNotFoundException:
-Logger.error(str(e))
-sys.exit(1)
-else:
-Logger.error(str(e))
-sys.exit(1)
+series = distro.getSeries(release)
 
-version = spph.getVersion()
-component = spph.getComponent()
+spph = getSPPH(lp, archive, package, version, series, pocket)
+if not spph:
+Logger.error("Package %s not found in %s", package, release)
+sys.exit(1)
+
+if package != spph.source_package_name:
+Logger.normal("Using source package %s for %s",
+  spph.source_package_name, package);
+package = spph.source_package_name
+version = spph.source_package_version
+component = spph.component_name
 
 Logger.normal('Downloading %s version %s', package, version)
 srcpkg = UbuntuSourcePackage(package, version, component=component,


Bug#851164: udev: NVMe symlinks broken by devices with spaces in model or serial strings

2017-01-12 Thread Dan Streetman
Package: systemd
Version: 232-8
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

udev creates symlinks for all NVMe drives at /dev/disk/by-id/nvme-MODEL_SERIAL.
The MODEL and SERIAL strings come directly from the NVMe device, and may
contain whitespace; if they do, this breaks the creation of the symlink
because udev treats it as multiple symlinks, separated by the whitespace.

These patches, which are merged upstream, change udev default behavior to
replace all whitespace, when added to a SYMLINK value as a result of variable
substitution, with underscores.  This results in a single symlink for each
NVMe drive, which is the correct behavior.  Note that this also fixes any
broken symlinks for other devices/buses that are a result of unexpected
whitespace included in variables.

This is tracked upstream in github bug 4833:
https://github.com/systemd/systemd/issues/4833

and in Ubuntu in launchpad bug 1647485:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647485
diff -Nru systemd-232/debian/patches/0001-libudev-util-change-util_replace_whitespace-to-retur.patch systemd-232/debian/patches/0001-libudev-util-change-util_replace_whitespace-to-retur.patch
--- systemd-232/debian/patches/0001-libudev-util-change-util_replace_whitespace-to-retur.patch	1969-12-31 19:00:00.0 -0500
+++ systemd-232/debian/patches/0001-libudev-util-change-util_replace_whitespace-to-retur.patch	2017-01-12 09:55:40.0 -0500
@@ -0,0 +1,32 @@
+From a9d99b32a34589777e95898dac0597dbfbede4ea Mon Sep 17 00:00:00 2001
+From: Dan Streetman <ddstr...@ieee.org>
+Date: Tue, 3 Jan 2017 14:31:45 -0500
+Subject: [PATCH 1/3] libudev-util: change util_replace_whitespace to return
+ number of chars in dest
+
+Instead of returning 0, which is unhelpful, return the number of chars
+copied into the dest string.  This allows callers that care about that
+to easily use it, instead of having to calculate the strlen.
+
+No current users of the function check the return value, so this does not
+break any existing code; it is used in the following patch.
+---
+ src/libudev/libudev-util.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/libudev/libudev-util.c b/src/libudev/libudev-util.c
+index 574cfea..a9819b9 100644
+--- a/src/libudev/libudev-util.c
 b/src/libudev/libudev-util.c
+@@ -186,7 +186,7 @@ int util_replace_whitespace(const char *str, char *to, size_t len)
+ to[j++] = str[i++];
+ }
+ to[j] = '\0';
+-return 0;
++return j;
+ }
+ 
+ /* allow chars in whitelist, plain ascii, hex-escaping and valid utf8 */
+-- 
+2.9.3
+
diff -Nru systemd-232/debian/patches/0002-udev-event-add-replace_whitespace-param-to-udev_even.patch systemd-232/debian/patches/0002-udev-event-add-replace_whitespace-param-to-udev_even.patch
--- systemd-232/debian/patches/0002-udev-event-add-replace_whitespace-param-to-udev_even.patch	1969-12-31 19:00:00.0 -0500
+++ systemd-232/debian/patches/0002-udev-event-add-replace_whitespace-param-to-udev_even.patch	2017-01-12 09:55:40.0 -0500
@@ -0,0 +1,309 @@
+From e20a917105b9c41e7e552ca5f11f9077897db505 Mon Sep 17 00:00:00 2001
+From: Dan Streetman <ddstr...@ieee.org>
+Date: Tue, 3 Jan 2017 14:37:59 -0500
+Subject: [PATCH 2/3] udev-event: add replace_whitespace param to
+ udev_event_apply_format
+
+If replace_whitespace is true, each substitution value has all its
+whitespace removed/replaced by util_replace_whitespace (except the
+SUBST_RESULT substitution - $result{} or %c{} - which handles spaces
+itself as field separators).  All existing callers are updated to
+pass false, so no functional change is made by this patch.
+
+This is needed so the SYMLINK assignment can replace any spaces
+introduced through variable substitution, becuase the SYMLINK value is
+a space-separated list of symlinks to create.  Any variables that
+contain spaces will thus unexpectedly change the symlink value from
+a single symlink to multiple incorrectly-named symlinks.
+
+This is used in the next patch, which enables the whitespace
+replacement for SYMLINK variable substitution.
+---
+ src/udev/udev-event.c   | 39 +++
+ src/udev/udev-rules.c   | 40 
+ src/udev/udev.h |  4 +++-
+ src/udev/udevadm-test.c |  2 +-
+ 4 files changed, 59 insertions(+), 26 deletions(-)
+
+diff --git a/src/udev/udev-event.c b/src/udev/udev-event.c
+index 304a287..be7c736 100644
+--- a/src/udev/udev-event.c
 b/src/udev/udev-event.c
+@@ -73,7 +73,9 @@ void udev_event_unref(struct udev_event *event) {
+ free(event);
+ }
+ 
+-size_t udev_event_apply_format(struct udev_event *event, const char *src, char *dest, size_t size) {
++size_t udev_event_apply_format(struct udev_event *event,
++   const char *src, char *dest, size_t size,
++   

Bug#834928: This is fixed in ifupdown 0.8.11

2016-09-21 Thread Dan Streetman
This is a bug in ifupdown, not isc-dhcp-client.  It's fixed in 0.8.11
by the change to ifupdown's wait-for-ll6.sh:

--- ifupdown-0.8.10/wait-for-ll6.sh 2015-12-01 16:50:26.0 -0500
+++ ifupdown-0.8.11/wait-for-ll6.sh 2016-04-20 08:57:37.0 -0400
@@ -4,7 +4,7 @@
 delay=${IF_LL_INTERVAL:-0.1}

 for attempt in $(seq 1 $attempts); do
- lladdress=$(ip -6 -o a s dev "$IFACE" scope link)
+ lladdress=$(ip -6 -o a s dev "$IFACE" scope link -tentative)
  if [ -n "$lladdress" ]; then
  attempt=0
  break



Bug#722496: debdiff v2

2016-09-12 Thread Dan Streetman
sorry, there was a problem with the last patch; it didn't work if the
vlan interface already existed, even if the raw device mtu was too
low.  this updated debdiff checks and increases the dev mtu even if
the vlan interface already exists.
diff -u vlan-1.9/debian/changelog vlan-1.9/debian/changelog
--- vlan-1.9/debian/changelog
+++ vlan-1.9/debian/changelog
@@ -1,3 +1,10 @@
+vlan (1.9-3.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Increase vlan raw device mtu if less than vlan mtu. (Closes: #722496)
+
+ -- Dan Streetman <dan.street...@canonical.com>  Fri, 09 Sep 2016 09:03:11 
-0400
+
 vlan (1.9-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u vlan-1.9/debian/network/if-pre-up.d/vlan 
vlan-1.9/debian/network/if-pre-up.d/vlan
--- vlan-1.9/debian/network/if-pre-up.d/vlan
+++ vlan-1.9/debian/network/if-pre-up.d/vlan
@@ -49,6 +49,14 @@
   ;;
 esac
 
+if [ -n "$IF_MTU" -a -n "$IF_VLAN_RAW_DEVICE" ]; then
+CUR_DEV_MTU=`cat /sys/class/net/$IF_VLAN_RAW_DEVICE/mtu`
+# increase the vlan raw device mtu if needed
+if [ -n "$CUR_DEV_MTU" ] && [ $CUR_DEV_MTU -lt $IF_MTU ]; then
+ip link set dev $IF_VLAN_RAW_DEVICE mtu $IF_MTU
+fi
+fi
+
 if [ -n "$IF_VLAN_RAW_DEVICE" ]; then
 if [ ! -x /sbin/vconfig ]; then
 exit 0


Bug#722496: debdiff to fix bug

2016-09-09 Thread Dan Streetman
this debdiff contains a patch to the /etc/network/if-pre-up.d/vlan
script that increases the vlan raw device mtu if it's lower than the
configured vlan mtu.  This fixes the bug by allowing the vlan to come
up correctly.
diff -u vlan-1.9/debian/changelog vlan-1.9/debian/changelog
--- vlan-1.9/debian/changelog
+++ vlan-1.9/debian/changelog
@@ -1,3 +1,10 @@
+vlan (1.9-3.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Increase vlan raw device mtu if less than vlan mtu. (Closes: #722496)
+
+ -- Dan Streetman <dan.street...@canonical.com>  Fri, 09 Sep 2016 09:03:11 
-0400
+
 vlan (1.9-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u vlan-1.9/debian/network/if-pre-up.d/vlan 
vlan-1.9/debian/network/if-pre-up.d/vlan
--- vlan-1.9/debian/network/if-pre-up.d/vlan
+++ vlan-1.9/debian/network/if-pre-up.d/vlan
@@ -57,6 +57,13 @@
 echo "$IF_VLAN_RAW_DEVICE does not exist, unable to create $IFACE"
 exit 1
 fi
+if [ -n "$IF_MTU" ]; then
+CUR_DEV_MTU=`cat /sys/class/net/$IF_VLAN_RAW_DEVICE/mtu`
+# increase the vlan raw device mtu if needed
+if [ -n "$CUR_DEV_MTU" ] && [ $CUR_DEV_MTU -lt $IF_MTU ]; then
+ip link set dev $IF_VLAN_RAW_DEVICE mtu $IF_MTU
+fi
+fi
 if [ ! -e "/sys/class/net/$IFACE" ]; then
 ip link set up dev $IF_VLAN_RAW_DEVICE
 vconfig add $IF_VLAN_RAW_DEVICE $VLANID


Bug#722496: this is an issue with large mtu vlans

2016-09-09 Thread Dan Streetman
This is actually a bug in the vlan package, the problem is if a vlan
has a mtu set that is higher than the vlan raw device mtu, it fails
while being ifup'ed, e.g.:

auto eth1
iface eth1 inet static
  address 1.2.3.4/24
  mtu 9000

auto eth1.10
iface eth1.10 inet static
  address 6.7.8.9/24
  mtu 9000


then 'sudo ifup eth1.10' fails, if eth1 has not been brought up yet.