Bug#944684: mmdebstrap: APT list files for /etc/apt/sources.list.d/*.list remain in image
Am Mittwoch, den 13.11.2019, 19:25 +0100 schrieb Johannes Schauer: > Hi, > > Quoting Benjamin Drung (2019-11-13 19:22:14) > > mmdebstrap fails to remove all APT list files at the cleanup stage. > > APT > > list files for /etc/apt/sources.list.d/*.list remain in image. You > > can > > reproduce it by running: > > > > mmdebstrap --keyring=/usr/share/keyrings/debian-archive-keyring.gpg > > \ > > -v --component=main \ > > --setup-hook="echo \"deb http://deb.debian.org/debian $suite > > contrib\" > \"\$1/etc/apt/sources.list.d/example.list\"" > > buster /tmp/buster.tar.xz > > > > why do you think this is a bug? Since mmdebstrap echos "cleaning package lists and apt cache..." and runs apt-get --option Dir::Etc::SourceList=/dev/null update Running 'rm -rf "$0/var/lib/apt/lists/"*' in a customize hook has no effect. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet signature.asc Description: This is a digitally signed message part
Bug#942761: mmdebstrap: hooks not documented in man page / --help
Am Mittwoch, den 13.11.2019, 19:22 +0100 schrieb Johannes Schauer:
> Hi,
>
> Quoting Benjamin Drung (2019-11-13 19:03:31)
> > > If you are successfully using hooks today, then I'd be happy to
> > > hear
> > > whether the way the work now is useful for you or not.
> > Yes, I am successfully using hooks now. I migrated our custom in-
> > house build
> > script from using debootstrap to use mmdebstrap using custom hooks.
> > So the
> > hooks are useful and work. They are easy enough to use. I thought
> > about
> > alternatives, but found nothing better.
>
> okay, that's good to know.
>
> > One hook is missing: A clean hook that is run after the cleanup,
> > which would
> > be run at last step of the setup function.
>
> What kind of stuff would you run there instead of putting it into the
> customize
> hook?
My cleanup script contains two things:
1) Removal of different stuff like /etc/resolv.conf,
/etc/udev/rules.d/70-persistent-net.rules, and /var/lib/apt/lists/"*
(removing the apt lists in the customize hook is too early, see
#944684)
2) Adjusting the timestamp of files/directories, e.g.:
find "$0/etc/" "$0/var/" -newermt "@${SOURCE_DATE_EPOCH}" \
\( -type f -o -type l \) -print0 | \
xargs -0r touch -hm -d "@${SOURCE_DATE_EPOCH}"
> > I have only one issue related to the hooks: There is no easy, safe,
> > and
> > reliable way to copy stuff out of the image to an existing
> > directory. Use
> > case: copy the kernel+initrd out of the image for PXE booting.
>
> I agree and I have needed this myself several times already. I'm
> still thinking
> of a good way to implement this because it does not only involve
> copying the
> data itself but also assuring right permission and ownership
> information.
> Furthermore, it should be possible to copy files in and out of the
> chroot at
> any point where hook are currently run.
>
> Currently I'm doing a lot of this in my own scripts:
>
> --customize-hook='cp -a tmpfile "$1/target/directory"'
> --customize-hook='echo foobar > "$1/target/file"'
>
> I have been considering adding another option that allows extracting
> a tarball
> or copying a directory structure into the chroot but everytime I
> somehow feel
> that it's a bit overkill to create a new option for something that
> some shell
> snippet in the --customize-hook can already do.
Copying files into the chroot is no problem, since it can be done by
simple cp or rsync.
> I did not yet see a need for copying stuff out of the chroot because
> whatever
> is needed can be simply taken from the final tarball or the created
> directory.
Copying files out of the chroot is the problem. Currently I have to
create a temporary directory and make it world writable.
Copying the files after the final tarball was created is not a
solution, because I do not want to have some files in the tarball.
Example: I want to run
dpkg-query -f='${Package}\t${Version}\n' -W
and store the output outside of the chroot. How about supporting
mounting directories into the chroot during building? Would that give
me the option to just copy/create the files inside that mounted
directory in a safe manner?
--
Benjamin Drung
Debian & Ubuntu Developer
Platform Engineering Compute (Enterprise Cloud)
1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet
signature.asc
Description: This is a digitally signed message part
Bug#944684: mmdebstrap: APT list files for /etc/apt/sources.list.d/*.list remain in image
Package: mmdebstrap Version: 0.5.1-2 Severity: normal Hi, mmdebstrap fails to remove all APT list files at the cleanup stage. APT list files for /etc/apt/sources.list.d/*.list remain in image. You can reproduce it by running: mmdebstrap --keyring=/usr/share/keyrings/debian-archive-keyring.gpg \ -v --component=main \ --setup-hook="echo \"deb http://deb.debian.org/debian $suite contrib\" > \"\$1/etc/apt/sources.list.d/example.list\"" buster /tmp/buster.tar.xz -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#942761: mmdebstrap: hooks not documented in man page / --help
Am Montag, den 21.10.2019, 13:59 +0200 schrieb Johannes Schauer: > Hi, > > Quoting Benjamin Drung (2019-10-21 09:41:37) > > The hooks are not documented in the man page / --help output > > despite > > having them documented in the end of the mmdebstrap file: > > > > $ man mmdebstrap | grep hook > > $ > > yes, that is a feature not a bug. :) > > I was never quite sure about how I want to implement hooks with > mmdebstrap as > in what interface would be useful and easy enough to use. So I > implemented the > functionality but by not documenting it, it is still experimental and > might > change in future releases. > > If you are successfully using hooks today, then I'd be happy to hear > whether > the way the work now is useful for you or not. Yes, I am successfully using hooks now. I migrated our custom in-house build script from using debootstrap to use mmdebstrap using custom hooks. So the hooks are useful and work. They are easy enough to use. I thought about alternatives, but found nothing better. One hook is missing: A clean hook that is run after the cleanup, which would be run at last step of the setup function. I have only one issue related to the hooks: There is no easy, safe, and reliable way to copy stuff out of the image to an existing directory. Use case: copy the kernel+initrd out of the image for PXE booting. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet signature.asc Description: This is a digitally signed message part
Bug#943325: mmdebstrap requires that the correct keyring is specified
Am Freitag, den 25.10.2019, 09:57 +0200 schrieb Johannes Schauer:
> Hi,
>
> Quoting Benjamin Drung (2019-10-24 11:54:14)
> > Since automatically choosing the right keyring is non-reliable and
> > adding symlinks into /etc/apt/trusted.gpg.d affects the host
> > system, I
> > like to have a --keyring parameter until there is a better solution
> > found.
> >
> > This --keyring parameter should set the apt option
> > Dir::Etc::Trusted if
> > it points to a file and Dir::Etc::TrustedParts if it points to a
> > directory. I can remember --keyring and find the correct full path
> > without needing to look into a man page.
>
> actually I found an even better reason why a --keyring parameter is
> no problem:
> debootstrap has it as well!
>
> So the user might actually expect the parameter to exist and has an
> idea of how
> it works.
>
> And yes, it should set the apt options you mention depending on
> whether a file
> or directory is passed and it should be possible to specify the --
> keyring
> parameter multiple times.
>
> Thanks!
Thanks for implementing it. Specifying --keyring before --aptopt fails:
mmdebstrap --keyring=/usr/share/keyrings/debian-archive-keyring.gpg \
-v --aptopt='Acquire::http { Proxy "123"; }' \
buster /tmp/buster.tar.xz
--
Benjamin Drung
Debian & Ubuntu Developer
Platform Engineering Compute (Enterprise Cloud)
1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet
signature.asc
Description: This is a digitally signed message part
Bug#943327: mmdebstrap: Please support using pixz
Am Mittwoch, den 13.11.2019, 17:54 +0100 schrieb Johannes Schauer:
> Quoting Benjamin Drung (2019-11-13 17:08:46)
> > > with some minor changes committed here:
> > >
> > > https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/4b82a664daa5b2430a00b737706ee77c75288158
> >
> > Sadly, this change breaks mmdebstrap:
> >
> > $ LANG=C tar -tf root.tar.xz
> > ./dev/
> > ./dev/console
> > ./dev/fd
> > ./dev/full
> > ./dev/null
> > ./dev/ptmx
> > ./dev/pts/
> > ./dev/random
> > ./dev/shm/
> > ./dev/stderr
> > ./dev/stdin
> > ./dev/stdout
> > ./dev/tty
> > ./dev/urandom
> > ./dev/zero
> > tar: Skipping to next header
> > tar: Exiting with failure status due to previous errors
> >
> > When I developed the patch, I just checked that the tarball was
> > created and
> > the file size matches, but I didn't check the content.
>
> ah indeed. This is of course because mmdebstrap assembles the tarball
> from two
> parts and then runs the compressor outside of tar. A correct patch
> probably
> look more like this:
>
> @@ -161,7 +161,7 @@ sub get_tar_compressor($) {
> } elsif ($filename =~ /\.lz4$/) {
> return 'lz4';
> } elsif ($filename =~ /\.(xz|txz)$/) {
> - return 'xz';
> + return ('xz', '--threads=0');
> } elsif ($filename =~ /\.zst$/) {
> return 'zstd';
> }
I have tested this proposed change by dirty patching the two exec
lines:
exec ($tar_compressor, '--threads=0') or error "[...]";
It works and creates a tarball. The generated tarball is actually
working (verified by using it).
--
Benjamin Drung
Debian & Ubuntu Developer
Platform Engineering Compute (Enterprise Cloud)
1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet
signature.asc
Description: This is a digitally signed message part
Bug#944677: mmdebstrap: /var/log/apt/eipp.log.xz remains in tarball/output
Package: mmdebstrap Version: 0.5.1-2 Severity: minor Tags: upstream Hi, I noticed that /var/log/apt/eipp.log.xz remains in the tarball/output. This is a log file from APT and should be better removed to make the output better reproducible. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#943327: mmdebstrap: Please support using pixz
Am Mittwoch, den 13.11.2019, 12:04 +0100 schrieb Johannes Schauer: > Control: tag -1 + pending > > Hi, > > with some minor changes committed here: > > https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/4b82a664daa5b2430a00b737706ee77c75288158 Sadly, this change breaks mmdebstrap: $ LANG=C tar -tf root.tar.xz ./dev/ ./dev/console ./dev/fd ./dev/full ./dev/null ./dev/ptmx ./dev/pts/ ./dev/random ./dev/shm/ ./dev/stderr ./dev/stdin ./dev/stdout ./dev/tty ./dev/urandom ./dev/zero tar: Skipping to next header tar: Exiting with failure status due to previous errors When I developed the patch, I just checked that the tarball was created and the file size matches, but I didn't check the content. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet signature.asc Description: This is a digitally signed message part
Bug#943327: mmdebstrap: Please support using pixz
tags 943327 patch
thanks
On Wed, 23 Oct 2019 15:52:26 +0200 Benjamin Drung <
benjamin.dr...@cloud.ionos.com> wrote:
> Am Mittwoch, den 23.10.2019, 14:56 +0200 schrieb Johannes Schauer:
> > Hi,
> >
> > Quoting Benjamin Drung (2019-10-23 14:14:15)
> > > one of mmdebstrap benefits over deboostrap is that it is
> > > faster. Creating a
> > > xz tarball as output will take a lot of time, since xz consumes a
> > > lot of
> > > compute power and tar uses only one core.
> > >
> > > pixz is a pallalel version of xz that can speedup the compression a
> > > lot.
> > > It can be simply used by tar by specifying -Ipixz.
> > >
> > > So please support using pixz when creating xz tarballs, maybe even
> > > as default
> > > if pixz can be found.
> >
> > I never heard of pixz. Is it still actively developed? I see that the
> > last
> > release is already four years old and in Debian we have the same
> > version since
> > oldstable. I just don't want to add code to support unmaintained or
> > rarely used
> > software.
>
> I wasn't aware that pixz hasn't have a lot of development recently, but
> I do not see any signs that it is dead. It look like it is being
> feature complete and under maintenance now.
>
> > Currently, mmdebstrap supports all compression file endings supported
> > by tar
> > and tar currently does not know about pixz. Is there a reason why tar
> > maintainers thought they don't add that compressor to their list?
>
> This question triggered me to search the web and I found out, that xz
> gained support for parallel compression files (only compressing, but
> not decompressing):
>
> $ time tar -J -cf root1.tar.xz -C root .
> real5m19,349s
> user5m19,775s
> sys 0m4,185s
>
> $ time tar -Ipixz -cf root2.tar.xz -C root .
> real0m59,250s
> user10m23,438s
> sys 0m3,734s
>
> $ time tar -I"xz -T 0" -cf root3.tar.xz -C root .
> real 1m0,764s
> user10m43,783s
> sys 0m3,892s
>
> So it would be nice if mmdebstrap would use -I"xz -T 0" for compressing
> xz in parallel. This does not require addition dependencies!
Attached a simple patch that adds the -I"xz -T 0" option when using xz
as compression.
--
Benjamin Drung
Debian & Ubuntu Developer
Platform Engineering Compute (Enterprise Cloud)
1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet
From 07e3917529792be9f89083752c5ee887d96d2278 Mon Sep 17 00:00:00 2001
From: Benjamin Drung
Date: Tue, 12 Nov 2019 19:17:30 +0100
Subject: [PATCH] Use parallel xz compression
One of mmdebstrap benefits over deboostrap is that it is faster.
Creating a xz tarball as output will take a lot of time, since xz
consumes a lot of compute power and tar uses only one core.
Therefore use parallel xz compression since xz supports it using the -T
parameter.
Closes: #943327
Signed-off-by: Benjamin Drung
---
mmdebstrap | 5 +
1 file changed, 5 insertions(+)
diff --git a/mmdebstrap b/mmdebstrap
index c8dbbe5..ae8b397 100755
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -2395,6 +2395,11 @@ sub main() {
my $exitstatus = 0;
my @taropts = ('--sort=name', "--mtime=\@$mtime", '--clamp-mtime', '--numeric-owner', '--one-file-system', '-c', '--exclude=./dev');
+# Use parallel xz compression
+if (get_tar_compressor($options->{target}) eq 'xz') {
+ push @taropts, "-Ixz -T 0"
+}
+
# disable signals so that we can fork and change behaviour of the signal
# handler in the parent and child without getting interrupted
my $sigset = POSIX::SigSet->new(SIGINT, SIGHUP, SIGPIPE, SIGTERM);
--
2.20.1
Bug#935540: debian-installer: Errors on sources.list security repositories
On Sun, 25 Aug 2019 16:29:51 +0200 Cyril Brulebois wrote: > [ Please don't drop submitters; quoting in full accordingly. ] > > Philip Hands (2019-08-24): > > Cyril Brulebois writes: > > > > > Control: tag -1 - d-i > > > > > > Hi Gustavo, > > > > > > Gustavo Romero Vazquez (2019-08-23): > > >> See the Wiki Debian (https://wiki.debian.org/Status/Testing), the > > >> security repositories for bullseye are the next (and they working): > > >> > > >> deb http://security.debian.org testing-security main contrib non-free > > >> deb-src http://security.debian.org testing-security main contrib non-free > > >> > > >> Regards and good luck!! > > > > > > You're absolutely right. I had stashed a branch a while ago, but it was > > > suggested to handle things slightly differently: > > > > > >“do it other way around and hardcode the old releases rather than > > > hardcode the new one?” > > > > > > I've just rebased it on top of master, and it'd be great if someone > > > could rework it to take the above comment in consideration: > > > > > > https://salsa.debian.org/installer-team/apt-setup/tree/pu/security-naming-scheme > > > > Hopefully something like this what you were wanting done: > > > > https://salsa.debian.org/installer-team/apt-setup/commit/78078caff231de7bb5a161fa19210b4ac6eb2cb5 > > Yes, that looks sane enough. > > I meant to check how this could affect Ubuntu. But from what I can see > in apt-setup/0.141ubuntu2, there are a bunch of changes already anyway, > so except for a possible merge conflict, that shouldn't be much of an > issue. > > Feel free to release that to master/the archive if you like. Any updates on this? I am hit by this bug as well and the proposed fix looks good to me. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#937085: mozilla-devscripts: Python2 removal in sid/bullseye
block 937085 by 780741 thanks Hi, I ported amo-changelog and xpi-repack to Python 3 in version 0.54, but I wasn't able to port all scripts, because there is no Python 3 version of redland-bindings (see Debian bug #780741). -- Benjamin Drung Debian & Ubuntu Developer
Bug#943325: mmdebstrap requires that the correct keyring is specified
Am Freitag, den 25.10.2019, 09:57 +0200 schrieb Johannes Schauer: > Hi, > > Quoting Benjamin Drung (2019-10-24 11:54:14) > > Since automatically choosing the right keyring is non-reliable and > > adding symlinks into /etc/apt/trusted.gpg.d affects the host > > system, I > > like to have a --keyring parameter until there is a better solution > > found. > > > > This --keyring parameter should set the apt option > > Dir::Etc::Trusted if > > it points to a file and Dir::Etc::TrustedParts if it points to a > > directory. I can remember --keyring and find the correct full path > > without needing to look into a man page. > > actually I found an even better reason why a --keyring parameter is > no problem: > debootstrap has it as well! > > So the user might actually expect the parameter to exist and has an > idea of how > it works. > > And yes, it should set the apt options you mention depending on > whether a file > or directory is passed and it should be possible to specify the -- > keyring > parameter multiple times. Great. If you want to make mmdebstrap more compatible with debootstrap, then you could use the default keyring files from debootstrap: $ grep -ir keyrings /usr/share/debootstrap/scripts/ /usr/share/debootstrap/scripts/woody:keyring /usr/share/keyrings/debian-archive-removed-keys.gpg /usr/share/debootstrap/scripts/potato:keyring /usr/share/keyrings/debian-archive-removed-keys.gpg /usr/share/debootstrap/scripts/woody.buildd:keyring /usr/share/keyrings/debian-archive-removed-keys.gpg /usr/share/debootstrap/scripts/aequorea:keyring /usr/share/keyrings/tanglu-archive-keyring.gpg /usr/share/debootstrap/scripts/gutsy:keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg /usr/share/debootstrap/scripts/kali:keyring /usr/share/keyrings/kali-archive-keyring.gpg /usr/share/debootstrap/scripts/sarge:keyring /usr/share/keyrings/debian-archive-removed-keys.gpg /usr/share/debootstrap/scripts/etch:keyring /usr/share/keyrings/debian-archive-removed-keys.gpg /usr/share/debootstrap/scripts/sid:keyring /usr/share/keyrings/debian-archive-keyring.gpg The pattern for the keyring look quite straight forward. BTW, you can use libdistro-info-perl to determine if it is Debian or Ubuntu and if it is still supported. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#943400: fakechroot: New upstream release 2.20.1
Package: fakechroot Version: 2.19-3.2 Severity: wishlist Hi, please update fakechroot to the new upstream release 2.20.1, because it supports the renameat2 systemcall (needed for mv command): https://github.com/dex4er/fakechroot/issues/60 -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#942590: mmdebstrap: Please support YAML configuration input file as alternative
Am Dienstag, den 22.10.2019, 11:25 +0200 schrieb Johannes Schauer: > Hi, > > Quoting Benjamin Drung (2019-10-18 18:24:53) > > I like to use mmdebstrap to produce a golden live image. This > > includes > > calling several custom hooks. My current command line call for the > > proof-of-concept is already more than 1000 characters long. That > > makes > > memorizing the full command infeasible and I have to place the > > command > > call into a shell script. > > > > It would be nice if the parameters for mmdebstrap could be placed > > into a > > YAML configuration file so that running > > `mmdebstrap --config=example.yaml` is enough to produce the output. > > > > Inspiration can be taken from > > https://salsa.debian.org/raspi-team/image-specs/blob/master/raspi3.yaml > > > > What do you think about that idea? Do you like it or do you have an > > alternative suggestion? > > I'm not against this idea. > > Right now indeed the best option is to use a shell script instead of > a > configuration file. In both cases you end up having a file lying > around > somewhere and I didn't yet see sufficient advantage of making that > file a > configuration file instead of a shell script. Maybe you can convince > me about > the advantages of a configuration file over a shell script? The advantage of a configuration file is that it is simpler to review than a shell script since it only contains configuration. Shell scripts tend to extend to do more stuff. Second benefit is that you can overwrite configuration items from the file by specifying the parameter on the command line. Having that flexibility in the shell script as well is possible, but makes it longer. Third benefit is that the configuration file is simpler to generate from a data structure in a program than to construct the command line arguments, since YAML has lists. Example: mmdebstrap: verbose: True aptopt: Dir::Etc::Trusted "/usr/share/keyrings/debian-archive-keyring.gpg" components: - main - contrib suite: buster target: example.tar.xz instead of: $ mmdebstrap -v \ "--aptopt=Dir::Etc::Trusted \"/usr/share/keyrings/debian-archive-keyring.gpg\"" \ --component=main,contrib buster example.tar.xz > Disadvantages are, that one has to learn yet another invented > configuration > file structure and/or format and that this will again increase the > amount of > necessary documentation, introduce new bugs and make an already > complex piece > of software even more complex and hard to understand. This is true, but if the configuration file just does a one-to-one mapping, just the input parsing part is longer. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#943325: mmdebstrap requires that the correct keyring is specified
Am Mittwoch, den 23.10.2019, 13:59 +0200 schrieb Johannes Schauer: > Hi, > > Quoting Benjamin Drung (2019-10-23 13:35:38) > > It is very convenient that building a basic chroot can be done > > without > > specifying a lot of parameters: > > > > $ mmdebstrap buster /tmp/buster.tar.xz > > > > Sadly this call will fail if you build a Debian chroot on Ubuntu or > > an > > Ubuntu chroot on Debian. You can to look up how to specify a > > keyring: > > > > --aptopt='Dir::Etc::Trusted "/usr/share/keyrings/debian-archive- > > keyring.gpg"' > > > > It would be nice if mmdebstrap had a --keyring option for > > specifying the > > keyring file. Maybe it would be nice if mmdebstrap would look for > > the correct > > keyring for Debian and Ubuntu chroots by default. > > Yes, I see the problem. This has not been fixed yet, because I'm not > using any > Debian derivative myself. I wonder what the best way to fix this > would be? > > Adding a --keyring option would save some typing over typing > > --aptopt='Dir::Etc::Trusted > > But it would still require typing the full path. > > You probably can shorten your line above a bit by using: > > --aptopt='Dir::Etc::TrustedParts "/usr/share/keyrings/"' > > But this assumes that /usr/share/keyrings does not contain anything > that you > don't want to validate against. > > If I add a way to automatically choose the right keyring it could > become a bit > non-reliable in the long term because at least Debian keyring files > keep > changing filenames and mmdebstrap would have to catch up with what is > valid for > stable, oldstable and oldoldstable. > > Automatically choosing the keyring also has the disadvantage that > it's not > clear to me how the user should best disable that functionality if > it's not > desired. Lastly, every automatism might create unexpected behaviour. > > Until there is a better solution I think the easiest way right now > for people > who often build cross-distro images, is to let their system apt > (which is the > one used by mmdebstrap) trust the right keys by adding symlinks into > /etc/apt/trusted.gpg.d. Since automatically choosing the right keyring is non-reliable and adding symlinks into /etc/apt/trusted.gpg.d affects the host system, I like to have a --keyring parameter until there is a better solution found. This --keyring parameter should set the apt option Dir::Etc::Trusted if it points to a file and Dir::Etc::TrustedParts if it points to a directory. I can remember --keyring and find the correct full path without needing to look into a man page. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#943327: mmdebstrap: Please support using pixz
Am Mittwoch, den 23.10.2019, 14:56 +0200 schrieb Johannes Schauer: > Hi, > > Quoting Benjamin Drung (2019-10-23 14:14:15) > > one of mmdebstrap benefits over deboostrap is that it is > > faster. Creating a > > xz tarball as output will take a lot of time, since xz consumes a > > lot of > > compute power and tar uses only one core. > > > > pixz is a pallalel version of xz that can speedup the compression a > > lot. > > It can be simply used by tar by specifying -Ipixz. > > > > So please support using pixz when creating xz tarballs, maybe even > > as default > > if pixz can be found. > > I never heard of pixz. Is it still actively developed? I see that the > last > release is already four years old and in Debian we have the same > version since > oldstable. I just don't want to add code to support unmaintained or > rarely used > software. I wasn't aware that pixz hasn't have a lot of development recently, but I do not see any signs that it is dead. It look like it is being feature complete and under maintenance now. > Currently, mmdebstrap supports all compression file endings supported > by tar > and tar currently does not know about pixz. Is there a reason why tar > maintainers thought they don't add that compressor to their list? This question triggered me to search the web and I found out, that xz gained support for parallel compression files (only compressing, but not decompressing): $ time tar -J -cf root1.tar.xz -C root . real5m19,349s user5m19,775s sys 0m4,185s $ time tar -Ipixz -cf root2.tar.xz -C root . real0m59,250s user10m23,438s sys 0m3,734s $ time tar -I"xz -T 0" -cf root3.tar.xz -C root . real1m0,764s user10m43,783s sys 0m3,892s So it would be nice if mmdebstrap would use -I"xz -T 0" for compressing xz in parallel. This does not require addition dependencies! -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#943327: mmdebstrap: Please support using pixz
Package: mmdebstrap Version: 0.5.1-1 Severity: wishlist Tags: upstream Hi, one of mmdebstrap benefits over deboostrap is that it is faster. Creating a xz tarball as output will take a lot of time, since xz consumes a lot of compute power and tar uses only one core. pixz is a pallalel version of xz that can speedup the compression a lot. It can be simply used by tar by specifying -Ipixz. So please support using pixz when creating xz tarballs, maybe even as default if pixz can be found. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#943323: E: run_chroot failed: E: cannot unlink policy-rc.d: No such file or directory
Am Mittwoch, den 23.10.2019, 14:01 +0200 schrieb Johannes Schauer: > Hi, > > Quoting Benjamin Drung (2019-10-23 13:01:52) > > when I delete /usr/sbin/policy-rc.d as part of a custom hook, > > mmdebstrap > > will fail: > > > > $ mmdebstrap -v --customize-hook='rm "$1/usr/sbin/policy-rc.d"' \ > > --aptopt='Dir::Etc::Trusted "/usr/share/keyrings/debian-archive- > > keyring.gpg"' \ > > buster /tmp/buster.tar.xz > > [...] > > I: running --customize-hook in shell: sh -c 'rm > > "$1/usr/sbin/policy-rc.d"' exec /tmp/mmdebstrap.kPFtRoxVVX > > E: run_chroot failed: E: cannot unlink policy-rc.d: No such file or > > directory > > I: removing tempdir /tmp/mmdebstrap.kPFtRoxVVX... > > > > Please only try to remove /usr/sbin/policy-rc.d if it still exists. > > whoops, indeed. Fixed in git! > > Out of interest: why would you delete policy-rc.d as part of a hook? I was porting our custom build script (which used debootstrap followed by a lot of shell code) which did the same policy-rc.d magic. When using mmdebstrap, this policy-rc.d magic can be dropped since mmdebstrap takes care of it. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#943325: mmdebstrap requires that the correct keyring is specified
Package: mmdebstrap Version: 0.5.1-1 Severity: wishlist Tags: upstream Hi, It is very convenient that building a basic chroot can be done without specifying a lot of parameters: $ mmdebstrap buster /tmp/buster.tar.xz Sadly this call will fail if you build a Debian chroot on Ubuntu or an Ubuntu chroot on Debian. You can to look up how to specify a keyring: --aptopt='Dir::Etc::Trusted "/usr/share/keyrings/debian-archive-keyring.gpg"' It would be nice if mmdebstrap had a --keyring option for specifying the keyring file. Maybe it would be nice if mmdebstrap would look for the correct keyring for Debian and Ubuntu chroots by default. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#943323: E: run_chroot failed: E: cannot unlink policy-rc.d: No such file or directory
Package: mmdebstrap Version: 0.5.1-1 Severity: normal Tags: upstream Hi, when I delete /usr/sbin/policy-rc.d as part of a custom hook, mmdebstrap will fail: $ mmdebstrap -v --customize-hook='rm "$1/usr/sbin/policy-rc.d"' \ --aptopt='Dir::Etc::Trusted "/usr/share/keyrings/debian-archive-keyring.gpg"' \ buster /tmp/buster.tar.xz [...] I: running --customize-hook in shell: sh -c 'rm "$1/usr/sbin/policy-rc.d"' exec /tmp/mmdebstrap.kPFtRoxVVX E: run_chroot failed: E: cannot unlink policy-rc.d: No such file or directory I: removing tempdir /tmp/mmdebstrap.kPFtRoxVVX... Please only try to remove /usr/sbin/policy-rc.d if it still exists. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#942761: mmdebstrap: hooks not documented in man page / --help
Package: mmdebstrap Version: 0.5.1-1 Severity: minor Hi, The hooks are not documented in the man page / --help output despite having them documented in the end of the mmdebstrap file: $ man mmdebstrap | grep hook $ -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#942590: mmdebstrap: Please support YAML configuration input file as alternative
Package: mmdebstrap Version: 0.5.0-2 Severity: wishlist Tags: upstream Hi, I like to use mmdebstrap to produce a golden live image. This includes calling several custom hooks. My current command line call for the proof-of-concept is already more than 1000 characters long. That makes memorizing the full command infeasible and I have to place the command call into a shell script. It would be nice if the parameters for mmdebstrap could be placed into a YAML configuration file so that running `mmdebstrap --config=example.yaml` is enough to produce the output. Inspiration can be taken from https://salsa.debian.org/raspi-team/image-specs/blob/master/raspi3.yaml What do you think about that idea? Do you like it or do you have an alternative suggestion? -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#942588: mmdebstrap: --component requires spaces instead of comma separation
Package: mmdebstrap Version: 0.5.0-2 Severity: normal Hi, mmdebstrap's man page says about --component: "Comma separated list of components like main, contrib and non-free which will be used for all URI-only MIRROR arguments.". But using comma as separator fails: $ mmdebstrap -v \ "--aptopt=Dir::Etc::Trusted \"/usr/share/keyrings/debian-archive-keyring.gpg\"" \ --component=main,contrib buster example.tar.xz I: automatically chosen mode: unshare I: chroot architecture amd64 is equal to the host's architecture I: using /tmp/mmdebstrap.1yCnFabKq6 as tempdir I: running apt-get update... Get:1 http://deb.debian.org/debian buster InRelease [122 kB] Get:2 http://security.debian.org/debian-security buster/updates InRelease [39.1 kB] Get:3 http://deb.debian.org/debian buster-updates InRelease [49.3 kB] Fetched 210 kB in 0s (623 kB/s) Reading package lists... W: Skipping acquire of configured file 'main,contrib/binary-amd64/Packages' as repository 'http://security.debian.org/debian-security buster/updates InRelease' doesn't have the component 'main,contrib' (component misspelt in sources.list?) W: Skipping acquire of configured file 'main,contrib/binary-amd64/Packages' as repository 'http://deb.debian.org/debian buster InRelease' doesn't have the component 'main,contrib' (component misspelt in sources.list?) W: Skipping acquire of configured file 'main,contrib/binary-amd64/Packages' as repository 'http://deb.debian.org/debian buster-updates InRelease' doesn't have the component 'main,contrib' (component misspelt in sources.list?) E: apt-get update -oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false failed I: removing tempdir /tmp/mmdebstrap.1yCnFabKq6... Using spaces as separator works. So there is either a bug in mmdebstrap or the documentation is misleading. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#942586: mmdebstrap fails with apt Install-Recommends "true"
Package: mmdebstrap Version: 0.5.0-2 Severity: important Hi, building a chroot with the APT option Install-Recommends "true" (as described in the man page) fails: $ mmdebstrap -v \ "--aptopt=Dir::Etc::Trusted \"/usr/share/keyrings/debian-archive-keyring.gpg\"" \ "--aptopt=Apt::Install-Recommends \"true\"" buster example.tar.xz [...] I: downloading apt... Reading package lists... Building dependency tree... apt is already the newest version (1.8.2). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. E: nothing got downloaded Downloading apt fails, because apt is already installed due to installing recommend. -- Benjamin Drung Debian & Ubuntu Developer Platform Engineering Compute (Enterprise Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#911563: ITP: pystemd - Cython-based wrapper on top of libsystemd
Hi, Am Montag, den 02.09.2019, 20:12 +0300 schrieb Alexandros Afentoulis: > On 9/2/19 12:42 PM, Benjamin Drung wrote: > > Hi, > > > > > > I had a look at it and pushed three smaller commits. I left two > > points > > for you before uploading it: > > > > 1) Please update debian/copyright to reflect the license change > > > > 2) Please upgrade debhelper 11 to version 12 > > > > done, commits in Salsa Thanks. I had to correct the license name. I created a release commit and uploaded it to Debian. Now let's wait for it to pass the NEW queue. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#911563: ITP: pystemd - Cython-based wrapper on top of libsystemd
Hi, Am Samstag, den 31.08.2019, 16:08 +0300 schrieb Alexandros Afentoulis: > I actually fixed autopkgtest in Salsa by simply using CI team's > pipeline > predefined jobs. They've done great work there. > > https://salsa.debian.org/python-team/modules/pystemd/pipelines/68325 > > So please take a look at the package and let me know how to proceed. I had a look at it and pushed three smaller commits. I left two points for you before uploading it: 1) Please update debian/copyright to reflect the license change 2) Please upgrade debhelper 11 to version 12 Besides that, lintian found some spelling issues. Please report them upstream so that they are repaired in their next release. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#911563: ITP: pystemd - Cython-based wrapper on top of libsystemd
Hi, On Sun, 21 Oct 2018 23:18:29 +0300 Alexandros Afentoulis < alexaf.d...@bloom.re> wrote: > Package: wnpp > Severity: wishlist > Owner: Alexandros Afentoulis what is the current status of packaging pystemd? I am interested in the Debian package of it and can offer to sponsor the package if needed. Upstream changed the license to LGPL-2.1+ (from BSD+Patents). So the possible licensing issues has been resolved. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#933922: [Pkg-salt-team] Bug#933922: src:salt: Unsafe use of yaml.load()
Am Montag, den 05.08.2019, 01:41 -0400 schrieb Scott Kitterman: > Package: src:salt > Version: 2018.3.4+dfsg1-6 > Severity: grave > Tags: security > Justification: user security hole > > The new version of pyyaml no longer allows use of yaml.load() without > a > loader being specifed. This raises a deprecation warning which has > caused and autopkgtest failure on this package. These are generally > trivial to fix, see the upstream guidance [1]. This was already reported to upstream in https://github.com/saltstack/salt/issues/39531 and was fixed by pull request https://github.com/saltstack/salt/pull/40751 I will cherry-pick these changes. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#931412: O: xmms2 -- Client/server based media player system
Package: wnpp Severity: normal I intend to orphan the xmms2 package, because I am not using it any more and lack enough time to properly maintain the package. The package description is: XMMS2 is a redesign of the XMMS music player. It features a client-server model, allowing multiple (even simultaneous!) user interfaces, both textual and graphical. All common audio formats are supported using plug-ins. On top of this, there is a flexible media library to organize your music. . This package is a metapackage depending on various other XMMS2 packages. Installing this package gets you a command line client and enables XMMS2 playback of Ogg Vorbis and MP3 files from local and remote sources.
Bug#931410: O: packaging-dev -- convenient tools to develop packages
Package: wnpp Severity: normal I intend to orphan the packaging-dev package. The package description is: This metapackage depends on common packages useful for the development of Debian-format packages, including patch management systems, build systems, packaging macros, helpful scripts for developers, and tools for building and testing packages. . This metapackage provides tools for packaging, rather than the development of software. No other package should depend or build-depend on this package.
Bug#931409: O: lxmms2 -- control XMMS2 with a LIRC compatible remote control
Package: wnpp Severity: normal I intend to orphan the lxmms2 package, because I do not use it any more and lack enough time to properly maintain the package. The package description is: lxmms2 is a tiny XMMS2 client to control XMMS2 with a LIRC compatible remote control. Following actions are supported: - play (starts playback) - pause (pauses playback) - toggle_play_pause (toggles pause and starts playback if XMMS2 is not playing at all) - toggle_pause (toggles pause) - stop (stops playback) - next (advances to the next track) - prev (goes back to the previous track) - volume_up (increases the volume) - volume_down (decreases the volume)
Bug#931406: O: flower
Package: wnpp Severity: normal Hi, I am not using flower any more and lack enough time to properly maintain the package. Feel free to take over the package. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#931405: O: django-sortedm2m
Package: wnpp Severity: normal Hi, I am not using django-sortedm2m any more and lack enough time to properly maintain the package. Feel free to take over the package and/or move it to the Python or Django group. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#931404: O: gevent-socketio
Package: wnpp Severity: normal Hi, I am not using gevent-socketio any more and lack enough time to properly maintain the package. Feel free to take over the package and/or move it to the Python group. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#931382: O: gevent-websocket
Package: wnpp Severity: normal Hi, I am not using gevent-websocket any more and lack enough time to properly maintain the package. Feel free to take over the package and/or move it to the Python group. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#931062: unblock: ionit/0.3.2+really0.2.1-2
Am Donnerstag, den 27.06.2019, 10:52 +0200 schrieb Paul Gevers: > Hi Benjamin, > > On 25-06-2019 13:25, Benjamin Drung wrote: > > The ionit.service fix for bug #919690 introduced a systemd > > dependency > > loop. systemd will break the loop at a (random?) place which can > > make > > boot behave incorrectly. > > Bah. One of the big reasons why you should fix your bugs earlier. I discovered the failing ifup@.service in January while testing and reported #919690 against ifupdown. On 2019-06-20 I troubleshooted this issue further and discovered that it was a configuration issue caused by ionit running too late. Then I reassigned it and fixed ionit. > And to > ask a nasty question, why didn't you spot this issue in the previous > version? I tested that version and checked that all systemd services were running. Sadly the dependency loop was just mentioned in the dmesg output. That's why I didn't saw it in my initial tests. > > I fixed the dependency loop in ionit 0.3.2+really0.2.1-2. A debdiff > > is > > attached. > > > > unblock ionit/0.3.2+really0.2.1-2 > > Unblocked, thanks. Thanks. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#931104: openvswitch-common: Wrong dependency on python-six
Package: openvswitch-common Version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12 Severity: grave Hi, openvswitch-common correctly depends on python3, because it ships scripts written in Python 3: ``` # file /usr/bin/ov* | grep python /usr/bin/ovn-detrace:a /usr/bin/python3 script, ASCII text executable /usr/bin/ovn-docker-overlay-driver: a /usr/bin/python3 script, ASCII text executable /usr/bin/ovn-docker-underlay-driver: a /usr/bin/python3 script, ASCII text executable /usr/bin/ovs-dpctl-top: a /usr/bin/python3 script, ASCII text executable /usr/bin/ovs-l3ping: a /usr/bin/python3 script, ASCII text executable /usr/bin/ovs-parse-backtrace:a /usr/bin/python3 script, ASCII text executable /usr/bin/ovs-pcap: a /usr/bin/python3 script, ASCII text executable /usr/bin/ovs-tcpdump:a /usr/bin/python3 script, ASCII text executable /usr/bin/ovs-tcpundump: a /usr/bin/python3 script, ASCII text executable /usr/bin/ovs-test: a /usr/bin/python3 script, ASCII text executable /usr/bin/ovs-vlan-test: a /usr/bin/python3 script, ASCII text executable ``` But openvswitch-common depends on python-six (pulling in Python 2) instead of python3-six. Following script import six and will fail if python3-six is missing: ``` # grep "from six" $(file /usr/bin/ov* | grep python | sed 's/:.*//') /usr/bin/ovs-l3ping:from six.moves import xmlrpc_client as xmlrpclib /usr/bin/ovs-test:from six.moves import xmlrpc_client as xmlrpclib /usr/bin/ovs-vlan-test:from six.moves import BaseHTTPServer /usr/bin/ovs-vlan-test:from six.moves import http_client as httplib ``` This can be easily reproduced in a minimal Debian chroot: ``` # ovs-l3ping Traceback (most recent call last): File "/usr/bin/ovs-l3ping", line 24, in from six.moves import xmlrpc_client as xmlrpclib ModuleNotFoundError: No module named 'six' ``` -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#931062: unblock: ionit/0.3.2+really0.2.1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package ionit The ionit.service fix for bug #919690 introduced a systemd dependency loop. systemd will break the loop at a (random?) place which can make boot behave incorrectly. I fixed the dependency loop in ionit 0.3.2+really0.2.1-2. A debdiff is attached. unblock ionit/0.3.2+really0.2.1-2 -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet diff -Nru ionit-0.3.2+really0.2.1/debian/changelog ionit-0.3.2+really0.2.1/debian/changelog --- ionit-0.3.2+really0.2.1/debian/changelog2019-06-20 15:36:08.0 +0200 +++ ionit-0.3.2+really0.2.1/debian/changelog2019-06-25 13:18:08.0 +0200 @@ -1,3 +1,10 @@ +ionit (0.3.2+really0.2.1-2) unstable; urgency=medium + + * Drop After=local-fs.target from ionit.service to break dependency loop +(Closes: #931060) + + -- Benjamin Drung Tue, 25 Jun 2019 13:18:08 +0200 + ionit (0.3.2+really0.2.1-1) unstable; urgency=medium * Run ionit.service before systemd-modules-load.service diff -Nru ionit-0.3.2+really0.2.1/debian/patches/Drop-After-local-fs.target-from-ionit.service.patch ionit-0.3.2+really0.2.1/debian/patches/Drop-After-local-fs.target-from-ionit.service.patch --- ionit-0.3.2+really0.2.1/debian/patches/Drop-After-local-fs.target-from-ionit.service.patch 1970-01-01 01:00:00.0 +0100 +++ ionit-0.3.2+really0.2.1/debian/patches/Drop-After-local-fs.target-from-ionit.service.patch 2019-06-25 13:16:16.0 +0200 @@ -0,0 +1,45 @@ +From ce7c305312bb68319784e2d693955297138c273a Mon Sep 17 00:00:00 2001 +From: Benjamin Drung +Date: Tue, 25 Jun 2019 12:00:24 +0200 +Subject: [PATCH] Drop After=local-fs.target from ionit.service + +Letting `ionit.service` run before `systemd-udev-trigger.service` +introduces a dependency loop: + +``` +systemd[1]: systemd-udev-trigger.service: Found ordering cycle on ionit.service/start +systemd[1]: systemd-udev-trigger.service: Found dependency on local-fs.target/start +systemd[1]: systemd-udev-trigger.service: Found dependency on local-fs-pre.target/start +systemd[1]: systemd-udev-trigger.service: Found dependency on multipathd.service/start +``` + +`systemd-udev-trigger.service` runs before `multipathd.service` which +runs before `local-fs-pre.target` which runs before `local-fs.target`. +`ionit.service` wants to run before `systemd-udev-trigger.service` but +after `local-fs.target`. + +Therefore drop `After=local-fs.target` from `ionit.service` to break the +dependency loop. `/etc` and `/usr` is probably mounted inside the initrd +already. + +Bug-Debian: https://bugs.debian.org/931060 +Signed-off-by: Benjamin Drung +--- + ionit.service | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/ionit.service b/ionit.service +index 8f56106..4c4e1c8 100644 +--- a/ionit.service b/ionit.service +@@ -2,7 +2,6 @@ + Description=Render configuration files from Jinja templates + Documentation=man:ionit(1) + DefaultDependencies=no +-After=local-fs.target + Before=ferm.service network-pre.target openibd.service shutdown.target sysinit.target systemd-modules-load.service systemd-udev-trigger.service + Wants=network-pre.target + RequiresMountsFor=/usr +-- +2.20.1 + diff -Nru ionit-0.3.2+really0.2.1/debian/patches/series ionit-0.3.2+really0.2.1/debian/patches/series --- ionit-0.3.2+really0.2.1/debian/patches/series 2019-06-20 13:54:04.0 +0200 +++ ionit-0.3.2+really0.2.1/debian/patches/series 2019-06-25 13:16:39.0 +0200 @@ -1,2 +1,3 @@ Run-ionit.service-before-systemd-modules-load.service.patch Run-ionit.service-before-systemd-udev-trigger.service.patch +Drop-After-local-fs.target-from-ionit.service.patch
Bug#931060: ionit.service creates a systemd dependency loop
Package: ionit Version: 0.3.2+really0.2.1-1 Severity: serious Tags: patch upstream Letting ionit.service run before systemd-udev-trigger.service (fix for Deiban bug #919690) introduces a dependency loop: systemd[1]: systemd-udev-trigger.service: Found ordering cycle on ionit.service/start systemd[1]: systemd-udev-trigger.service: Found dependency on local-fs.target/start systemd[1]: systemd-udev-trigger.service: Found dependency on local-fs-pre.target/start systemd[1]: systemd-udev-trigger.service: Found dependency on multipathd.service/start systemd will break the loop where the dependency is required for correct booting. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#930801: unblock: rdma-core/22.3-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi,
rdma-core is maintained by the Linux RDMA group. It follows the Linux
kernel release schedule and concepts. Upstream backports fixes to their
stable branches. We have currently rdma-core 22.1-1 in Debian
unstable/testing. Upstream released 22.3 which contains only bug fixes.
I prepared an updated package 22.3-1 (patch attached). Before uploading
anything, I like to hear your opinion: Is this change okay for buster,
should I wait for the release, or better keep that update out of buster?
unblock rdma-core/22.3-1
--
Benjamin Drung
System Developer
Debian & Ubuntu Developer
1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss
Member of United Internet
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8310ec6c..db291328 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -65,7 +65,7 @@ endif()
set(PACKAGE_NAME "RDMA")
# See Documentation/versioning.md
-set(PACKAGE_VERSION "22.1")
+set(PACKAGE_VERSION "22.3")
# When this is changed the values in these files need changing too:
# debian/control
# debian/libibverbs1.symbols
@@ -360,23 +360,23 @@ else()
set(HAVE_FULL_SYMBOL_VERSIONS 1)
endif()
-if (${NO_PYVERBS})
- set(CYTHON_EXECUTABLE "")
-else ()
- # Look for Python. We prefer some variant of python 3 if the system has it.
- FIND_PACKAGE(PythonInterp 3 QUIET)
- if (NOT ${PythonInterp_FOUND})
-FIND_PACKAGE(PythonInterp REQUIRED)
- endif()
- FIND_PACKAGE(cython)
-endif()
-
# Look for Python. We prefer some variant of python 3 if the system has it.
FIND_PACKAGE(PythonInterp 3 QUIET)
-if (NOT ${PythonInterp_FOUND})
+if (PythonInterp_FOUND)
+ # pyverbs can only use python3:
+ if (NO_PYVERBS)
+set(CYTHON_EXECUTABLE "")
+ else()
+FIND_PACKAGE(cython)
+ endif()
+else()
+ # But we still must have python (be it 2) for the build process:
FIND_PACKAGE(PythonInterp REQUIRED)
+ set(CYTHON_EXECUTABLE "")
endif()
+
# A cython & python-devel installation that matches our selected interpreter.
+
if (CYTHON_EXECUTABLE)
# cmake has really bad logic here, if PythonIterp has been run it tries to
# find a matching -devel installation but will happily return a non-matching
diff --git a/buildlib/RDMA_BuildType.cmake b/buildlib/RDMA_BuildType.cmake
index 0951edad..17206f51 100644
--- a/buildlib/RDMA_BuildType.cmake
+++ b/buildlib/RDMA_BuildType.cmake
@@ -8,7 +8,7 @@ function(RDMA_BuildType)
# in performance contexts it doesn't make much sense to have the default
build
# turn off the optimizer.
if(NOT CMAKE_BUILD_TYPE)
-set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE String
+ set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING
"Options are ${build_types}"
FORCE
)
diff --git a/buildlib/cbuild b/buildlib/cbuild
index 9ced0de6..15095d0c 100755
--- a/buildlib/cbuild
+++ b/buildlib/cbuild
@@ -641,10 +641,6 @@ def run_deb_build(args,env):
"-e","DEB_BUILD_OPTIONS=parallel=%u"%(multiprocessing.cpu_count()),
];
-if not env.build_pyverbs:
-opts.append("-e");
-opts.append("EXTRA_CMAKE_FLAGS=%s"%(' '.join(["-DNO_PYVERBS=1"])));
-
# Create a go.py that will let us run the compilation as the user and
# then switch to root only for the packaging step.
with open(os.path.join(tmpdir,"go.py"),"w") as F:
diff --git a/buildlib/check-build b/buildlib/check-build
index 5ae0cc1c..348b0590 100755
--- a/buildlib/check-build
+++ b/buildlib/check-build
@@ -14,6 +14,7 @@ import copy
import shlex
import pipes
from contextlib import contextmanager;
+from distutils.version import LooseVersion;
def get_src_dir():
"""Get the source directory using git"""
@@ -106,7 +107,7 @@ def check_lib_symver(args,fn):
private,args.PACKAGE_VERSION));
syms = list(syms - private);
-syms.sort(key=lambda x:re.split('[._]',x));
+syms.sort(key=LooseVersion)
if newest_symver != syms[-1]:
raise ValueError("Symbol version %r implied by filename %r not the
newest in ELF (%r)"%(
newest_symver,fn,syms));
diff --git a/buildlib/package-build-test b/buildlib/package-build-test
index 46a1cf6f..29c17838 100755
--- a/buildlib/package-build-test
+++ b/buildlib/package-build-test
@@ -11,7 +11,7 @@ if [ -e "/.dockerenv" ] || (grep -q docker /proc/self/cgroup
&>/dev/null); then
exit 0
fi
-for OS in centos7 tumbleweed
+for OS in centos7 leap
do
echo
echo "Check
Bug#930776: unblock: ionit/0.3.2-1
Control: tags -1 - moreinfo Am Donnerstag, den 20.06.2019, 15:02 +0200 schrieb Paul Gevers: > Control: tags -1 moreinfo confirmed > > Hi Benjamin, > > On 20-06-2019 14:05, Benjamin Drung wrote: > > Okay. I prepared a version with just the fixes for the > > ionit.service > > (debdiff attached). Why not going through testing-proposed-updates? > > If > > not, the version number will be 0.3.2+really0.2.1-2 instead of > > 0.2.1-2. > > Or better 0.3.2+really0.2.1-1 (as the first version of the upstream > version 0.3.2+really0.2.1) but I don't mind yours if you really > prefer that. Okay. Uploaded that debdiff as 0.3.2+really0.2.1-1. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#930776: unblock: ionit/0.3.2-1
Control: tags -1 - moreinfo Am Donnerstag, den 20.06.2019, 13:45 +0200 schrieb Paul Gevers: > Control: tags -1 moreinfo > > Hi Benjamin > > On 20-06-2019 12:52, Benjamin Drung wrote: > > ionit runs too late for /etc/network/interfaces (RC bug #919690). > > This > > is fixed in 0.3.2-1. The debdiff is attached. > > Please, pretty please. At this moment of the release only targeted > fixes > [1]. Revert the other upstream changes and upload a version which > targets the bug only (e.g. with a +really version). Your fix has to > go > through unstable, not testing-proposed-updates. Okay. I prepared a version with just the fixes for the ionit.service (debdiff attached). Why not going through testing-proposed-updates? If not, the version number will be 0.3.2+really0.2.1-2 instead of 0.2.1-2. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet diff -Nru ionit-0.2.1/debian/changelog ionit-0.2.1/debian/changelog --- ionit-0.2.1/debian/changelog 2019-01-07 14:22:30.0 +0100 +++ ionit-0.2.1/debian/changelog 2019-06-20 13:55:12.0 +0200 @@ -1,3 +1,10 @@ +ionit (0.2.1-2) testing-proposed-updates; urgency=medium + + * Run ionit.service before systemd-modules-load.service + * Run ionit.service before systemd-udev-trigger.service (Closes: #919690) + + -- Benjamin Drung Thu, 20 Jun 2019 13:55:12 +0200 + ionit (0.2.1-1) unstable; urgency=medium * New upstream release. diff -Nru ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-modules-load.service.patch ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-modules-load.service.patch --- ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-modules-load.service.patch 1970-01-01 01:00:00.0 +0100 +++ ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-modules-load.service.patch 2019-06-20 13:51:57.0 +0200 @@ -0,0 +1,33 @@ +From f56792f9b2d618d38207170d61f420bf58e26603 Mon Sep 17 00:00:00 2001 +From: Benjamin Drung +Date: Wed, 10 Apr 2019 13:30:47 +0200 +Subject: [PATCH] Run ionit.service before systemd-modules-load.service + +In case you want to render modprobe configuration files, the ionit +service needs to run before systemd-modules-load.service (which runs +also before sysinit.target and races with ionit.service). + +Therefore let ionit.service run explicitly before +systemd-modules-load.service. + +Signed-off-by: Benjamin Drung +--- + ionit.service | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ionit.service b/ionit.service +index 1e23862..a67cc88 100644 +--- a/ionit.service b/ionit.service +@@ -3,7 +3,7 @@ Description=Render configuration files from Jinja templates + Documentation=man:ionit(1) + DefaultDependencies=no + After=local-fs.target +-Before=ferm.service network-pre.target openibd.service shutdown.target sysinit.target ++Before=ferm.service network-pre.target openibd.service shutdown.target sysinit.target systemd-modules-load.service + Wants=network-pre.target + RequiresMountsFor=/usr + +-- +2.20.1 + diff -Nru ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-udev-trigger.service.patch ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-udev-trigger.service.patch --- ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-udev-trigger.service.patch 1970-01-01 01:00:00.0 +0100 +++ ionit-0.2.1/debian/patches/Run-ionit.service-before-systemd-udev-trigger.service.patch 2019-06-20 13:52:07.0 +0200 @@ -0,0 +1,40 @@ +From 11b6dbab36c0b1d983179d10e3a079e0f31102bc Mon Sep 17 00:00:00 2001 +From: Benjamin Drung +Date: Thu, 20 Jun 2019 12:14:42 +0200 +Subject: [PATCH] Run ionit.service before systemd-udev-trigger.service + +live-boot creates a `/etc/network/interfaces` file that contains an +`allow-hotplug` entry for the network boot device `eth0`. +`systemd-udev-trigger.service` executes +`/lib/udev/rules.d/80-ifupdown.rules` which calls +`/lib/udev/ifupdown-hotplug`. This scripts starts `ifup@eth0.service`. +Afterwards `ionit` runs and might replace `allow-hotplug` by `auto` if a +template `/etc/network/interfaces.jinja` is provided. Then +`networking.service` and `ifup@eth0.service` will start at the same time +and race. + +Therefore let `ionit.service` run before `systemd-udev-trigger.service` +to support generating `/etc/network/interfaces`. + +Bug-Debian: https://bugs.debian.org/919690 +Signed-off-by: Benjamin Drung +--- + ionit.service | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ionit.service b/ionit.service +index a67cc88..8f56106 100644 +--- a/ionit.service b/ionit.service +@@ -3,7 +3,7
Bug#930776: unblock: ionit/0.3.2-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package ionit
ionit runs too late for /etc/network/interfaces (RC bug #919690). This
is fixed in 0.3.2-1. The debdiff is attached.
ionit is a quite new and very small tool (popcon count: 4), which is
developed and used by us. It has 100% test coverage (run at build time
and as autopkgtest).
unblock ionit/0.3.2-1
--
Benjamin Drung
System Developer
Debian & Ubuntu Developer
1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss
Member of United Internet
diff -Nru ionit-0.2.1/debian/changelog ionit-0.3.2/debian/changelog
--- ionit-0.2.1/debian/changelog2019-01-07 14:22:30.0 +0100
+++ ionit-0.3.2/debian/changelog2019-06-20 12:21:44.0 +0200
@@ -1,3 +1,13 @@
+ionit (0.3.2-1) unstable; urgency=medium
+
+ * New upstream release.
+- Support specifying a configuration file
+- Support specifying --config multiple times
+- Run ionit.service before systemd-modules-load.service
+- Run ionit.service before systemd-udev-trigger.service (Closes: #919690)
+
+ -- Benjamin Drung Thu, 20 Jun 2019 12:21:44
+0200
+
ionit (0.2.1-1) unstable; urgency=medium
* New upstream release.
diff -Nru ionit-0.2.1/ionit ionit-0.3.2/ionit
--- ionit-0.2.1/ionit 2019-01-07 14:01:10.0 +0100
+++ ionit-0.3.2/ionit 2019-06-20 12:17:42.0 +0200
@@ -28,6 +28,7 @@
import ionit_plugin
+DEFAULT_CONFIG = "/etc/ionit"
LOG_FORMAT = '%(asctime)s %(name)s %(levelname)s: %(message)s'
SCRIPT_NAME = "ionit"
@@ -86,23 +87,34 @@
return context
-def collect_context(directory):
+def get_config_files(paths):
+"""Return files for the given paths (could either be files or
directories)."""
+logger = logging.getLogger(SCRIPT_NAME)
+files = []
+for path in paths:
+logger.debug("Searching for configuration files in '%s'...", path)
+try:
+if os.path.isfile(path):
+files.append(path)
+else:
+files += sorted([os.path.join(path, f) for f in
os.listdir(path)])
+except OSError as error:
+logger.warning("Failed to read configuration directory: %s", error)
+logger.debug("Configuration files: %s", files)
+return files
+
+
+def collect_context(paths):
"""Collect context that will be used when rendering the templates"""
logger = logging.getLogger(SCRIPT_NAME)
-logger.debug("Collecting context from '%s'...", directory)
-try:
-files = sorted(os.listdir(directory))
-except OSError as error:
-logger.warning("Failed to read configuration directory: %s", error)
-files = []
+logger.debug("Collecting context...")
failures = 0
context = {}
-for filename in files:
+for file in get_config_files(paths):
file_context = None
-file = os.path.join(directory, filename)
-extension = os.path.splitext(filename)[1]
+extension = os.path.splitext(file)[1]
try:
if extension == ".json":
logger.info("Reading configuration file '%s'...", file)
@@ -184,9 +196,9 @@
def main(argv):
"""Main function with argument parsing"""
parser = argparse.ArgumentParser()
-parser.add_argument("-c", "--config", default="/etc/ionit",
-help="Configuration directory containing context for
rendering (default: "
- "%(default)s)")
+parser.add_argument("-c", "--config", action="append",
+help="Configuration directory/file containing context
for rendering "
+ "(default: %s)" % (DEFAULT_CONFIG,))
parser.add_argument("-t", "--templates", default="/etc",
help="Directory to search for Jinja templates
(default: %(default)s)")
parser.add_argument("-e", "--template-extension", default="jinja",
@@ -197,6 +209,8 @@
help="Decrease output verbosity to warnings and
errors",
action="store_const", const=logging.WARNING)
args = parser.parse_args(argv)
+if args.config is None:
+args.config = [DEFAULT_CONFIG]
logging.basicConfig(level=args.log_level, format=LOG_FORMAT)
logger = logging.getLogger(SCRIPT_NAME)
di
Bug#919690: ionit runs too late for /etc/network/interfaces
reassign 919690 ionit 0.2.1-1 severity 919690 serious retitle 919690 ionit runs too late for /etc/network/interfaces thanks Hi, I finally troubleshot this issue. live-boot creates a /etc/network/interfaces file that contains an allow-hotplug for the network boot device. systemd-udev-trigger.service executes /lib/udev/rules.d/80-ifupdown.rules which calls /lib/udev/ifupdown- hotplug. This scripts starts ifup@ens3.service. Afterwards ionit runs and replaces allow-hotplug by auto. Then networking.service and ifup@ens3.service start at the same time and race. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#930656: unblock: gokey/0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package gokey
The current version of gokey suffers the RC bug #930426 which makes the
RSA key generation non-deterministic. The main purpose of gokey is to
generate deterministic keys. The second upload to Debian unstable fixes
the build failure by increasing the timeout for the tests, because the
tests take very long on mips/mipsel. The gokey tests takes 11408.183 s
(= 190 min) on minkus.debian.org (mips porter box).
By the way, gokey
0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-2 is more or less
the same version as 0.0~git20190103.40eba7e-1, because there are only
two upstream commits between 20181023.b4e2780 and 20190103.40eba7e.
The debdiff is attached. My email address changes and this is not
mentioned in the changelog.
unblock gokey/0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-3
--
Benjamin Drung
System Developer
Debian & Ubuntu Developer
1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss
Member of United Internet
diff -Nru
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/changelog
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/changelog
---
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/changelog
2019-06-04 20:53:29.0 +0200
+++
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/changelog
2019-06-17 20:04:04.0 +0200
@@ -1,3 +1,18 @@
+gokey (0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-3) unstable;
urgency=medium
+
+ * Increase test timeout to six hours, because the tests need 190 minutes
+on mips (Closes: #919759)
+ * Run tests for RSA2048 and RSA4096 again
+
+ -- Benjamin Drung Mon, 17 Jun 2019 20:04:04
+0200
+
+gokey (0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-2) unstable;
urgency=medium
+
+ * Cherry-pick patch from upstream to import deterministic RSA key generation
+code from Go 1.10 crypto/rsa package (Closes: #930426)
+
+ -- Benjamin Drung Thu, 13 Jun 2019 15:51:37
+0200
+
gokey (0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-1) unstable;
urgency=medium
* Team upload.
diff -Nru
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/control
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/control
--- gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/control
2019-06-04 20:52:40.0 +0200
+++ gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/control
2019-06-13 15:53:37.0 +0200
@@ -1,6 +1,6 @@
Source: gokey
Maintainer: Debian Go Packaging Team
-Uploaders: Benjamin Drung ,
+Uploaders: Benjamin Drung ,
Anthony Fok
Section: utils
Testsuite: autopkgtest-pkg-go
diff -Nru
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/0002-disable-TestGetKey-for-RSA.patch
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/0002-disable-TestGetKey-for-RSA.patch
---
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/0002-disable-TestGetKey-for-RSA.patch
2019-06-04 20:52:40.0 +0200
+++
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/0002-disable-TestGetKey-for-RSA.patch
1970-01-01 01:00:00.0 +0100
@@ -1,24 +0,0 @@
-Description: Disable tests for RSA2048 and RSA4096 in TestGetKey
- rsa.GenerateKey has been intentionally made non-deterministic since Go 1.11.
- This patch fixes the "gokey_test.go:161: keys with same invocation options
- do not match" error in TestGetKey with Go >= 1.11.
-Author: Anthony Fok
-Origin: vendor
-Bug: https://github.com/cloudflare/gokey/issues/17
-Last-Update: 2018-12-31
-This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
a/gokey_test.go
-+++ b/gokey_test.go
-@@ -165,8 +165,9 @@
- func TestGetKey(t *testing.T) {
- testGetKeyType(EC256, t)
- testGetKeyType(EC521, t)
-- testGetKeyType(RSA2048, t)
-- testGetKeyType(RSA4096, t)
-+ // rsa.GenerateKey is no longer deterministic in Go >= 1.11
-+ //testGetKeyType(RSA2048, t)
-+ //testGetKeyType(RSA4096, t)
- testGetKeyType(X25519, t)
- testGetKeyType(ED25519, t)
- }
diff -Nru
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/Import-deterministic-RSA-key-generation-code-from-Go.patch
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/Import-deterministic-RSA-key-generation-code-from-Go.patch
---
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/Import-deterministic-RSA-key-generation-code-from-Go
Bug#919759: gokey FTBFS on armel/mips*: FAIL github.com/cloudflare/gokey
Hi, I reproduced this testing timeout on the mipsel porter box eller.debian.org. Then I increased the timeout and it succeeded: [...] ok github.com/cloudflare/gokey 9.447s ? github.com/cloudflare/gokey/cmd/gokey [no test files] === RUN TestKnownKey --- PASS: TestKnownKey (684.76s) PASS ok github.com/cloudflare/gokey/rsa 684.769s [...] The buildd on mips took 20.669s for github.com/cloudflare/gokey and on mipsel 9.475s. A expansion for mips would end up with 1492s = 24.9min. So I have to increase the test timeout to at least 30min. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#930426: gokey: Output of gokey is not deterministic any more
Package: gokey Version: 0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-1 Severity: grave Tags: upstream Justification: renders package unusable Hi, Currently the output of gokey is not deterministic any more and therefore renders it completely useless. This was fixed in gokey 0.0~git20190103.40eba7e-1 by upstream: - Import deterministic RSA key generation code from Go 1.10 crypto/rsa package Please either upgrade to 0.0~git20190103.40eba7e or cherry-pick the relevant change. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#930419: Regression: Resolving DNS names does not work any more
Package: live-boot
Version: 1:20180603
Severity: important
Tags: patch
Hi,
libnss_dns.so and libnss_files.so are needed to resolve DNS names. They
are not included any more in the initramfs since the files were moved
from /lib to /usr/lib. A patch to fix it is attached.
--
Benjamin Drung
System Developer
Debian & Ubuntu Developer
1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss
Member of United Internet
>From 85521ffd0062f8dcc3d727ccde1dac94d53dcb68 Mon Sep 17 00:00:00 2001
From: Benjamin Drung
Date: Wed, 12 Jun 2019 13:03:09 +0200
Subject: [PATCH] Also search for libnss_*.so files in /usr/lib
The libnss_*.so were moved from /lib to /usr/lib and were not found any
more (breaking resolving the FQDN with "hostname -f").
Therefore also search for libnss_*.so files in /usr/lib.
Signed-off-by: Benjamin Drung
---
backend/initramfs-tools/live.hook | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/backend/initramfs-tools/live.hook
b/backend/initramfs-tools/live.hook
index 1817814..b37f54f 100755
--- a/backend/initramfs-tools/live.hook
+++ b/backend/initramfs-tools/live.hook
@@ -236,11 +236,11 @@ fi
[ "${QUIET}" ] || echo -n " dns"
-# /lib/libnss_dns.so.*:a DNS
-# /lib/libnss_files.so.*: /etc/hosts and /etc/passwd
-# /lib/libnss_compat.so.*: /etc/passwd
+# libnss_dns.so.*:DNS
+# libnss_files.so.*: /etc/hosts and /etc/passwd
+# libnss_compat.so.*: /etc/passwd
-for _SHLIB in $(find /lib -name 'libnss_dns.so.*' -o -name 'libnss_files.so.*')
+for _SHLIB in $(find /lib /usr/lib -name 'libnss_dns.so.*' -o -name
'libnss_files.so.*')
do
copy_exec "${_SHLIB}"
done
--
2.20.1
Bug#927348: unblock: salt/2018.3.4+dfsg1-2
Control: tags -1 moreinfo Am Samstag, den 25.05.2019, 10:58 +0200 schrieb Paul Gevers: > On 24-05-2019 15:38, Benjamin Drung wrote: > > I would like to upload that proposed version to unstable. > > Please go ahead and remove the moreinfo tag when the package is build > and installed. salt 2018.3.4+dfsg1-6 uploaded, built successfully and debci succeeded as well. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#927348: unblock: salt/2018.3.4+dfsg1-2
Hi Paul, Am Dienstag, den 14.05.2019, 20:13 +0200 schrieb Paul Gevers: > Hi Benjamin, > > On 14-05-2019 13:13, Benjamin Drung wrote: > > Hi Paul, > > > > Am Freitag, den 10.05.2019, 20:40 +0200 schrieb Paul Gevers: > > > Control: tags -1 moreinfo > > > > > > So, all in all, I don't want to unblock the new upstream with > > > your > > > packaging, we're too late in the cycle and the version really > > > doesn't > > > match the freeze policy. However, I am offering you an upload > > > based > > > on the version currently in buster via t-p-u. If you go that > > > route, > > > please only fix bugs 919849, 928337, 922352, 924763, the > > > LC_ALL=C.UTF-8 item and the systemd issue. Please fix 919849 > > > without > > > switching your build to sphinxdoc, that isn't appropriate at this > > > moment. > > > > Okay. So you prefer an upload to t-p-u or can I just revert those > > rejected changes (typos fixes and using dh_sphinxdoc) and do > > another > > upload to unstable? > > I would prefer an upload to unstable if you also revert to the > previous > upstream tar ball (e.g. using the +really version syntax). I prepared the relevant changes in the master-proposed branch: https://salsa.debian.org/salt-team/salt/commits/master-proposed Attached a diff between 2018.3.4~git20180207+dfsg1-1 from testing and the proposed 2018.3.4+dfsg1-6 created with: git diff debian/2018.3.4_git20180207+dfsg1-1..master-proposed -- debian I tested this proposed version that it builds and that the documentation works as expected (including the search) and that all needed files are there and that it contains to broken symlinks. While testing I found and fixed another instance of privacy breach: https://salsa.debian.org/salt-team/salt/commit/08a00aaa4670d0713ec55c0d23d25e64ad85e624 (privacy breach is not part of the policy yet, see #726998) Let me know if this change is acceptable or not. I would like to upload that proposed version to unstable. If you insists of staying with the 2018.3.4~git20180207+dfsg1 snapshot, I will rebase this patch on top of 2018.3.4~git20180207+dfsg1 and prepare the upload for t-p-u. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet diff --git a/debian/changelog b/debian/changelog index e1942d9d..9d0dfca3 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,65 @@ +salt (2018.3.4+dfsg1-6) unstable; urgency=medium + + * Revert changes that were rejected by the release team: +- Drop fixing various spelling mistakes +- Drop using jquery.js from sphinx +- Drop using dh_sphinxdoc +- Drop patch to set script type explicitly to text/javascript + * doc: Use local Open Sans fonts instead of querying Google +to fix possible privacy breach + + -- Benjamin Drung Fri, 24 May 2019 15:01:45 +0200 + +salt (2018.3.4+dfsg1-5) unstable; urgency=medium + + * Cherry-pick upstream patch to fix edge case when minion ID is a +16-character string (Closes: #928337) + + -- Benjamin Drung Thu, 02 May 2019 13:23:44 +0200 + +salt (2018.3.4+dfsg1-4) unstable; urgency=medium + + * Cherry-pick upstream patch to fix retrieving systemd version (for 241-3) + + -- Benjamin Drung Fri, 26 Apr 2019 16:38:39 +0200 + +salt (2018.3.4+dfsg1-3) unstable; urgency=medium + + [ Benjamin Drung ] + * tests: Drop copying missing templates directory + * salt-doc: Install favicon in document root and do not compress it + * salt-doc: Fix JavaScript symlinks to bootstrap (Closes: #919849) + * doc: Set script type explicitly to text/javascript + * Use jquery.js from sphinx + * Symlink vendor JavaScript files before building + * Use dh_sphinxdoc + + [ Steffen Kockel ] + * doc: Fix logo link to point to contents.html + * doc: Ensure searchtools.js gets included (to fix the search) + + -- Benjamin Drung Thu, 25 Apr 2019 13:39:10 +0200 + +salt (2018.3.4+dfsg1-2) unstable; urgency=medium + + * Fix test_xen_virtual on kernels with no Xen support (Closes: #922352) + * Expose tornado4 as tornado for zmq.eventloop.ioloop (Closes: #924763) + + -- Benjamin Drung Wed, 17 Apr 2019 20:26:11 +0200 + +salt (2018.3.4+dfsg1-1) unstable; urgency=medium + + * New upstream release. + * Refresh patches + * Fix various spelling mistakes + * Drop NOTICE from salt-common (the upstream tarball does not contain it) + * Skip SampleConfTest and ExtendTestCase if the required sample conf or +templates directories are missing + * Run tests with LC_ALL=C.UTF-8 + * R
Bug#927348: unblock: salt/2018.3.4+dfsg1-2
Hi Paul, Am Freitag, den 10.05.2019, 20:40 +0200 schrieb Paul Gevers: > Control: tags -1 moreinfo > > So, all in all, I don't want to unblock the new upstream with your > packaging, we're too late in the cycle and the version really doesn't > match the freeze policy. However, I am offering you an upload based > on the version currently in buster via t-p-u. If you go that route, > please only fix bugs 919849, 928337, 922352, 924763, the > LC_ALL=C.UTF-8 item and the systemd issue. Please fix 919849 without > switching your build to sphinxdoc, that isn't appropriate at this > moment. Okay. So you prefer an upload to t-p-u or can I just revert those rejected changes (typos fixes and using dh_sphinxdoc) and do another upload to unstable? -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#927348: unblock: salt/2018.3.4+dfsg1-2
Control: tags -1 - moreinfo
Hi,
Am Donnerstag, den 02.05.2019, 21:05 +0200 schrieb Paul Gevers:
> Control: tags -1 moreinfo
>
> Hi Benjamin,
>
> On Thu, 18 Apr 2019 13:01:31 +0200 Benjamin Drung
> wrote:
> > This version fixes the test_xen_virtual test case (bug #922352) and
> > exposes tornado4 as tornado for zmq.eventloop.ioloop (bug #924763).
> > Our
> > salt 2018.3.3+dfsg1-1 package introduced a big patch to use
> > python3-tornado4 (instead of python3-tornado) due to missing
> > support for
> > tornado version 5. Without the fix for #924763,
> > zmq.eventloop.ioloop
> > will import tornado version 5 (if python3-tornado is installed).
>
> Both bugs have severity normal. Do you really want to bother now or
> is the severity not correct (then please fix that and elaborate)?
Bug #922352 can cause a build failure (and does on Ubuntu). Therefore I
raised it to serious.
Determining the severity of bug #924763 is more complicated. The
reporter stumbled over a warning spit out by salt. The warning message
by itself is more or less harmless, but the underlying problem of the
wrong import might have bad effects. I haven't seen any yet, but they
might be there. IMO we shouldn't release salt with an issue introduced
by one of our patches.
> > I also included fix-various-spelling-mistakes.patch which fixes
> > several
> > spelling mistakes. Because this patch file is long, I excluded it
> > from the
> > attached debdiff.
>
> Bugs can be introduced that way. I am not going to review that diff,
> fixing spelling mistakes at this moment isn't appropriate unless
> these mistakes are crucial somewhere.
I can drop that patch again when this is the only blocker for getting
the unblock request accepted.
> > This version also switches from the a pre-release git snapshot to
> > the
> > official 2018.3.4 release. The only difference between this
> > snapshot and
> > the release are two commits ("Fix ssh on Windows" and "Update url
> > to
> > libsodium for mac builds") and that the release tarball ships less
> > files
> > than what can be found in git.
>
> If that was all (salt/modules/ssh.py and
> tests/integration/modules/test_ssh.py), I could except it. But with
> less files, there is also a changes that ...
All previous upstream releases like 2017.7.3, 2017.7.2, and so on did
not contain these additional files that the git snapshot
2018.3.4~git20180207 contained. All these additional, auxiliary files
are not needed for the installation. I should have used the upstream
method to create the release tarball instead of using "git archive"
when creating the 2018.3.4~git20180207 tarball.
> > For that reason, the attached debdiff is created with this command:
> >
> > debdiff --exclude fix-various-spelling-mistakes.patch
> > salt_2018.3.4~git20180207+dfsg1-1.dsc salt_2018.3.4+dfsg1-2.dsc |
> > filterdiff -i '*/debian/*' -i '*/tests/*/test_ssh.py' -i
> > '*/salt/modules/ssh.py' -i '*/pkg/osx/build_env.sh' >
> > salt_2018.3.4+dfsg1-2.debdiff
> >
> > Alternatively this more simple git diff command could be used:
> >
> > git diff --diff-filter=ACM
> > debian/2018.3.4_git20180207+dfsg1-1..debian/2018.3.4+dfsg1-2
> >
> > You can also look at all the individual commits on salsa:
> > https://salsa.debian.org/salt-team/salt/compare/debian%2F2018.3.4_git20180207+dfsg1-1...debian%2F2018.3.4+dfsg1-2
> >
> > All 7575 unittest succeeded and I successfully tested this new salt
> > version on Debian unstable with our production environment setup
> > (running the highstate on a salt minion connected to the salt
> > master).
> >
> > unblock salt/2018.3.4+dfsg1-2
>
> You didn't even elaborate on all the (at this phase of the release
> inappropriate) changes to the packaging. There is even a newer
> version
> than the one you already mention in a follow up in this bug.
Which changes to the packaging do you refer to?
Running the tests with LC_ALL=C.UTF-8 fixes a build failure in case the
building machine uses an ANSII locale, which would be worth another RC
bug report.
Upload 2018.3.4+dfsg1-3 repairs the documentation in salt-doc. It
ensures that the pre-built minified Javascript and CSS files are not
leaked into the salt-doc binary package and that all created symlink
are correct. Before this version, salt-doc contained broken symlinks
and the search did not work.
systemd 241 broke salt. Upload 2018.3.4+dfsg1-4 fixes that. There were
no bug report opened for it, but it would be worth one RC bug.
The newly opened RC bug #928337 was fixed in 2018.3.4+dfsg1-5.
--
Benjamin Drung
System Developer
Debian & Ubuntu Developer
1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss
Member of United Internet
Bug#927348: unblock: salt/2018.3.4+dfsg1-2
retitle 927348 unblock: salt/2018.3.4+dfsg1-4
thanks
Hi,
two more uploads for salt were needed: The first for repairing the
documentation (correct JavaScript symlinks and making the search work
again). The second for fixing the autopkgtest when using systemd 241-3.
A debdiff between salt 2018.3.4+dfsg1-2 and 2018.3.4+dfsg1-4 is
attached.
unblock salt/2018.3.4+dfsg1-4
--
Benjamin Drung
System Developer
Debian & Ubuntu Developer
1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss
Member of United Internet
diff -Nru salt-2018.3.4+dfsg1/debian/changelog salt-2018.3.4+dfsg1/debian/changelog
--- salt-2018.3.4+dfsg1/debian/changelog 2019-04-17 20:26:11.0 +0200
+++ salt-2018.3.4+dfsg1/debian/changelog 2019-04-26 16:38:39.0 +0200
@@ -1,3 +1,26 @@
+salt (2018.3.4+dfsg1-4) unstable; urgency=medium
+
+ * Cherry-pick upstream patch to fix retrieving systemd version (for 241-3)
+
+ -- Benjamin Drung Fri, 26 Apr 2019 16:38:39 +0200
+
+salt (2018.3.4+dfsg1-3) unstable; urgency=medium
+
+ [ Benjamin Drung ]
+ * tests: Drop copying missing templates directory
+ * salt-doc: Install favicon in document root and do not compress it
+ * salt-doc: Fix JavaScript symlinks to bootstrap (Closes: #919849)
+ * doc: Set script type explicitly to text/javascript
+ * Use jquery.js from sphinx
+ * Symlink vendor JavaScript files before building
+ * Use dh_sphinxdoc
+
+ [ Steffen Kockel ]
+ * doc: Fix logo link to point to contents.html
+ * doc: Ensure searchtools.js gets included (to fix the search)
+
+ -- Benjamin Drung Thu, 25 Apr 2019 13:39:10 +0200
+
salt (2018.3.4+dfsg1-2) unstable; urgency=medium
* Fix test_xen_virtual on kernels with no Xen support (Closes: #922352)
diff -Nru salt-2018.3.4+dfsg1/debian/control salt-2018.3.4+dfsg1/debian/control
--- salt-2018.3.4+dfsg1/debian/control 2019-04-05 14:43:18.0 +0200
+++ salt-2018.3.4+dfsg1/debian/control 2019-04-25 17:08:50.0 +0200
@@ -11,6 +11,8 @@
debhelper (>= 11),
dh-python,
dpkg-dev (>= 1.16.2),
+ libjs-bootstrap,
+ libjs-modernizr,
python3,
python3 (>= 3.6) | python3-mock,
python3-augeas,
@@ -52,6 +54,7 @@
python3-twilio,
python3-yaml,
python3-zmq (>= 13.1.0),
+ sphinx-common,
virtualenv
Build-Depends-Indep: python3-doc, python3-sphinx (>= 1.3.5)
Standards-Version: 4.3.0
@@ -219,11 +222,11 @@
Package: salt-doc
Architecture: all
Section: doc
+Built-Using: ${sphinxdoc:Built-Using}
Depends: libjs-bootstrap,
- libjs-jquery,
libjs-modernizr,
- libjs-sphinxdoc,
- ${misc:Depends}
+ ${misc:Depends},
+ ${sphinxdoc:Depends}
Breaks: salt-common (<< 2016.11.5)
Replaces: salt-common (<< 2016.11.5)
Description: additional documentation for salt, the distributed remote execution system
diff -Nru salt-2018.3.4+dfsg1/debian/patches/doc-fix-logo-link.patch salt-2018.3.4+dfsg1/debian/patches/doc-fix-logo-link.patch
--- salt-2018.3.4+dfsg1/debian/patches/doc-fix-logo-link.patch 1970-01-01 01:00:00.0 +0100
+++ salt-2018.3.4+dfsg1/debian/patches/doc-fix-logo-link.patch 2019-04-25 17:09:29.0 +0200
@@ -0,0 +1,27 @@
+From 5c3036d248c4ae76d2fa7598cde179294aa4b2bb Mon Sep 17 00:00:00 2001
+From: Steffen Kockel
+Date: Tue, 23 Apr 2019 17:45:00 +0200
+Subject: [PATCH] doc: Fix logo link
+
+The link on the brand image was pointing to index.html which does not
+exist. The index file seems to be contents.html.
+---
+ doc/_themes/saltstack/layout.html | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/doc/_themes/saltstack/layout.html b/doc/_themes/saltstack/layout.html
+index 85e0a3cf..d5ff2cd6 100644
+--- a/doc/_themes/saltstack/layout.html
b/doc/_themes/saltstack/layout.html
+@@ -181,7 +181,7 @@
+
+
+
+-
++
+
+ {%- block relbar1 %}{{ relbar() }}{% endblock %}
+
+--
+2.17.1
+
diff -Nru salt-2018.3.4+dfsg1/debian/patches/doc-Set-script-type-explicitly-to-text-javascript.patch salt-2018.3.4+dfsg1/debian/patches/doc-Set-script-type-explicitly-to-text-javascript.patch
--- salt-2018.3.4+dfsg1/debian/patches/doc-Set-script-type-explicitly-to-text-javascript.patch 1970-01-01 01:00:00.0 +0100
+++ salt-2018.3.4+dfsg1/debian/patches/doc-Set-script-type-explicitly-to-text-javascript.patch 2019-04-25 17:09:29.0 +0200
@@ -0,0 +1,52 @@
+From e22e49d974937ed9107cf33c679799c914f27777 Mon Sep 17
Bug#928022: ITP: modernize -- Modernizes Python code for eventual Python 3 migration
Am Freitag, den 26.04.2019, 13:11 +0200 schrieb Jonas Smedegaard: > Quoting Benjamin Drung (2019-04-26 12:15:51) > > Package: wnpp > > Severity: wishlist > > Owner: Benjamin Drung > > > > * Package name: modernize > > Version : 0.7 > > Upstream Author : Armin Ronacher > > * URL : https://pypi.org/project/modernize > > * License : BSD-3-clause plus some PSF-2 > > Programming Lang: Python > > Description : Modernizes Python code for eventual Python 3 > > migration > > > > This library is a very thin wrapper around lib2to3 to utilize it to > > make > > Python 2 code more modern with the intention of eventually porting > > it > > over to Python 3. > > > > The source will produce the binary packages modernize and > > python3-libmodernize. This package is a dependency for salt-pylint, > > which I intent to package. > > > > I plan to maintain that package as part of the Debian Python > > Modules > > Team. > > Please pretty please name this as python-modernize or modernize- > python - > unless the plan is to extend to cover perl5-to-perl6 and Haskell-to- > Rust > or similar. Are there other tools named modernize or do you consider 'modernize' to be too generic? -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#928028: ITP: salt-pylint -- PyLint plugins needed in the several SaltStack projects
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: salt-pylint Version : 2019.1.11 Upstream Author : SaltStack Team * URL : https://github.com/saltstack/salt-pylint * License : Apache-2.0 Programming Lang: Python Description : PyLint plugins needed in the several SaltStack projects The python3-saltpylint binary package contains plugins for PyLint which are used in several SaltStack projects. I will maintain that package as part of the Debian Salt Team. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#928022: ITP: modernize -- Modernizes Python code for eventual Python 3 migration
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: modernize Version : 0.7 Upstream Author : Armin Ronacher * URL : https://pypi.org/project/modernize * License : BSD-3-clause plus some PSF-2 Programming Lang: Python Description : Modernizes Python code for eventual Python 3 migration This library is a very thin wrapper around lib2to3 to utilize it to make Python 2 code more modern with the intention of eventually porting it over to Python 3. The source will produce the binary packages modernize and python3-libmodernize. This package is a dependency for salt-pylint, which I intent to package. I plan to maintain that package as part of the Debian Python Modules Team. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#927348: unblock: salt/2018.3.4+dfsg1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package salt
This version fixes the test_xen_virtual test case (bug #922352) and
exposes tornado4 as tornado for zmq.eventloop.ioloop (bug #924763). Our
salt 2018.3.3+dfsg1-1 package introduced a big patch to use
python3-tornado4 (instead of python3-tornado) due to missing support for
tornado version 5. Without the fix for #924763, zmq.eventloop.ioloop
will import tornado version 5 (if python3-tornado is installed).
I also included fix-various-spelling-mistakes.patch which fixes several
spelling mistakes. Because this patch file is long, I excluded it from the
attached debdiff.
This version also switches from the a pre-release git snapshot to the
official 2018.3.4 release. The only difference between this snapshot and
the release are two commits ("Fix ssh on Windows" and "Update url to
libsodium for mac builds") and that the release tarball ships less files
than what can be found in git.
For that reason, the attached debdiff is created with this command:
debdiff --exclude fix-various-spelling-mistakes.patch
salt_2018.3.4~git20180207+dfsg1-1.dsc salt_2018.3.4+dfsg1-2.dsc |
filterdiff -i '*/debian/*' -i '*/tests/*/test_ssh.py' -i
'*/salt/modules/ssh.py' -i '*/pkg/osx/build_env.sh' >
salt_2018.3.4+dfsg1-2.debdiff
Alternatively this more simple git diff command could be used:
git diff --diff-filter=ACM
debian/2018.3.4_git20180207+dfsg1-1..debian/2018.3.4+dfsg1-2
You can also look at all the individual commits on salsa:
https://salsa.debian.org/salt-team/salt/compare/debian%2F2018.3.4_git20180207+dfsg1-1...debian%2F2018.3.4+dfsg1-2
All 7575 unittest succeeded and I successfully tested this new salt
version on Debian unstable with our production environment setup
(running the highstate on a salt minion connected to the salt master).
unblock salt/2018.3.4+dfsg1-2
-- System Information:
Debian Release: buster/sid
APT prefers disco
APT policy: (500, 'disco')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.0.0-13-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru --exclude fix-various-spelling-mistakes.patch
salt-2018.3.4~git20180207+dfsg1/debian/changelog
salt-2018.3.4+dfsg1/debian/changelog
--- salt-2018.3.4~git20180207+dfsg1/debian/changelog2019-02-08
17:05:57.0 +0100
+++ salt-2018.3.4+dfsg1/debian/changelog2019-04-17 20:26:11.0
+0200
@@ -1,3 +1,23 @@
+salt (2018.3.4+dfsg1-2) unstable; urgency=medium
+
+ * Fix test_xen_virtual on kernels with no Xen support (Closes: #922352)
+ * Expose tornado4 as tornado for zmq.eventloop.ioloop (Closes: #924763)
+
+ -- Benjamin Drung Wed, 17 Apr 2019 20:26:11
+0200
+
+salt (2018.3.4+dfsg1-1) unstable; urgency=medium
+
+ * New upstream release.
+ * Refresh patches
+ * Fix various spelling mistakes
+ * Drop NOTICE from salt-common (the upstream tarball does not contain it)
+ * Skip SampleConfTest and ExtendTestCase if the required sample conf or
+templates directories are missing
+ * Run tests with LC_ALL=C.UTF-8
+ * Remove unused minified documentation CSS files
+
+ -- Benjamin Drung Fri, 05 Apr 2019 13:58:40
+0200
+
salt (2018.3.4~git20180207+dfsg1-1) unstable; urgency=medium
* New upstream pre-release snapshot.
diff -Nru --exclude fix-various-spelling-mistakes.patch
salt-2018.3.4~git20180207+dfsg1/debian/patches/0001-Skip-SampleConfTest-if-sample-conf-directories-are-m.patch
salt-2018.3.4+dfsg1/debian/patches/0001-Skip-SampleConfTest-if-sample-conf-directories-are-m.patch
---
salt-2018.3.4~git20180207+dfsg1/debian/patches/0001-Skip-SampleConfTest-if-sample-conf-directories-are-m.patch
1970-01-01 01:00:00.0 +0100
+++
salt-2018.3.4+dfsg1/debian/patches/0001-Skip-SampleConfTest-if-sample-conf-directories-are-m.patch
2019-04-03 16:36:21.0 +0200
@@ -0,0 +1,97 @@
+From 0473683aceaba9a975fc28f72ff80e8ab12dea2d Mon Sep 17 00:00:00 2001
+From: Benjamin Drung
+Date: Wed, 3 Apr 2019 14:50:12 +0200
+Subject: [PATCH 1/2] Skip SampleConfTest if sample conf directories are
+ missing
+
+The release tarball does not contain `conf/cloud.profiles.d`,
+`conf/cloud.providers.d`, and `conf/cloud.maps.d`. Therefore the test
+cases will fail:
+
+```
+==
+ERROR: test_conf_cloud_maps_d_files_are_commented
(unit.test_config.SampleConfTest)
+[CPU:0.0%|MEM:53.9%]
+--
+Traceback (most recent call last):
+ File "tests/unit/test_config.py", line 236, in
test_conf_cloud_maps_d_files_are_commented
+cloud_sample_files = os.listdir(SAMPLE_CONF_DIR + 'cloud.maps.d/')
+FileNotF
Bug#926873: ITP: pyrundeck -- Python library for the Rundeck REST API
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: pyrundeck Version : 0.9.7 Upstream Author : Philipp Schmitt * URL : https://github.com/pschmitt/pyrundeck * License : GPL-3 Programming Lang: Python Description : Python library for the Rundeck REST API Pyrundeck is a library for communicating with Rundeck via a RESTful (Representational State Transfer) application programming interface (API). I will maintian the package in the Python group. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#926727: esperanza: Consider removing this software from Debian?
Am Dienstag, den 09.04.2019, 12:32 -0400 schrieb Boyuan Yang: > Package: esperanza > Severity: important > Version: 0.4.0+git20091017-5 > X-Debbugs-CC: bdr...@debian.org > > Hi, > > It looks like esperanza has no upstream activity for 10 years and that > it is > currently affected by Qt4 Removal in Debian [1]. Its popcon data is > also > declining. Is it okay if we remove it from Debian? Yes. Feel free to go ahead to remove it. I am not using it any more. If someone else still likes esperanza and has time, please go ahead and port it to Qt5 and take over the Debian maintenance. -- Benjamin Drung Debian & Ubuntu Developer
Bug#570623: reprepro: please add multiple version management
Am Sonntag, den 31.03.2019, 15:12 +0200 schrieb Vincent Bernat: > Package: reprepro > Version: 5.3.0-1 > Followup-For: Bug #570623 > > What is the status of this feature? The merge request is not > available anymore It seems that the support for pull requests were disabled. > and the GitHub repository of the fork is not up-to-date with > 5.3.0. I refreshed the patches on top of version 5.3.0 and pushed it to https://salsa.debian.org/bdrung/reprepro/ and https://github.com/profitbricks/reprepro -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#924562: openvswitch-switch breaks networking.service due to dependency loop
Package: openvswitch-switch Version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-10 Priority: critical Hi, the fix for RC bug #878757 introduces a regression. openvswitch- switch.service specifies: [Unit] Description=Open vSwitch After=network.target openvswitch-nonetwork.service Requires=openvswitch-nonetwork.service Before=networking.service networking.service specifies Before=network.target. So openvswitch- switch.service should run before (via networking.service) and after network.target, which is an unsolvable loop dependency: $ dmesg | grep systemd [...] [ 21.887888] systemd[1]: network.target: Found ordering cycle on network.target/start [ 21.887893] systemd[1]: network.target: Found dependency on networking.service/start [ 21.887896] systemd[1]: network.target: Found dependency on openvswitch-switch.service/start [ 21.887898] systemd[1]: network.target: Found dependency on network.target/start [ 21.887901] systemd[1]: network.target: Breaking ordering cycle by deleting job networking.service/start [ 21.887904] systemd[1]: networking.service: Job networking.service/start deleted to break ordering cycle starting with network.target/start This broken dependency leads to not configured IPoIB devices. So please remove network.target from "After" dependencies list of openvswitch-switch.service. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506B. Geschäftsführer: Andreas Gauger, Achim Weiss.
Bug#922064: [Pkg-salt-team] Bug#922064: Bug#922064: Please restore previous version
Am Mittwoch, den 13.03.2019, 17:41 +0100 schrieb Dirk Heinrichs:
> Am 13.03.19 um 13:38 schrieb Benjamin Drung:
>
> > and let me know the output?
>
> Sure. Here you are:
>
> [...]
> Mär 13 17:36:28 salt salt-master[20006]: line: b'PageTables: ',
> fields:
> [b'PageTables:']
> [...]
Thanks. That output is surprising. According to the log, /proc/meminfo
is parsed completely the first the time. The second time, it is only
parsed to this partial line. Was this file closed or what went wrong?
Can you try this:
diff --git a/psutil/_pslinux.py b/psutil/_pslinux.py
index 41be6665..aa0a7940 100644
--- a/usr/lib/python3/dist-packages/psutil/_pslinux.py
+++ b/usr/lib/python3/dist-packages/psutil/_pslinux.py
@@ -401,7 +401,11 @@ def virtual_memory():
with open_binary('%s/meminfo' % get_procfs_path()) as f:
for line in f:
fields = line.split()
-mems[fields[0]] = int(fields[1]) * 1024
+print("line: %r, fields: %r" % (line, fields))
+if len(fields) != 2:
+print("remaining: %r" % (f.read()))
+if fields:
+mems[fields[0]] = int(fields[1]) * 1024
# /proc doc states that the available fields in /proc/meminfo vary
# by architecture and compile options, but these 3 values are also
If the file was closed, a read() should produce a ValueError. If the
remaining file content is empty, it will look like a kernel bug to me.
--
Benjamin Drung
System Developer
Debian & Ubuntu Developer
ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin
Email: benjamin.dr...@profitbricks.com
URL: http://www.profitbricks.com
Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Andreas Gauger, Achim Weiss.
Bug#922064: [Pkg-salt-team] Bug#922064: Please restore previous version
Am Samstag, den 02.03.2019, 09:58 +0100 schrieb Dirk Heinrichs:
> Hi,
>
> since the Salt master is still not starting, could the Salt packages
> at
> least be rolled back to the previous version until the problem is
> solved?
Rolling back the salt package does not help, because this bug is inside
psutil.
For further debugging, can change _pslinux.py and run it again:
diff --git a/psutil/_pslinux.py b/psutil/_pslinux.py
index 41be6665..aa0a7940 100644
--- a/usr/lib/python3/dist-packages/psutil/_pslinux.py
+++ b/usr/lib/python3/dist-packages/psutil/_pslinux.py
@@ -401,7 +401,9 @@ def virtual_memory():
with open_binary('%s/meminfo' % get_procfs_path()) as f:
for line in f:
fields = line.split()
-mems[fields[0]] = int(fields[1]) * 1024
+print("line: %r, fields: %r" % (line, fields))
+if fields:
+mems[fields[0]] = int(fields[1]) * 1024
# /proc doc states that the available fields in /proc/meminfo vary
# by architecture and compile options, but these 3 values are also
and let me know the output?
--
Benjamin Drung
System Developer
Debian & Ubuntu Developer
1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss
Member of United Internet
Bug#922064: [salt-master] Salt master doesn't start anymore after update
Am Dienstag, den 12.02.2019, 17:42 +0100 schrieb Dirk Heinrichs: > Am 12.02.19 um 17:37 schrieb Benjamin Drung: > > > So then it is a bug in psutil. Can you attach the content of > > /proc/meminfo? > > Here you are: > # cat /proc/meminfo > MemTotal: 16350148 kB > MemFree: 3822056 kB > MemAvailable:9057676 kB > Buffers:1356 kB > Cached: 4943992 kB > SwapCached:0 kB > Active: 7324360 kB > Inactive: 948080 kB > Active(anon):3682896 kB > Inactive(anon): 326888 kB > Active(file):3641464 kB > Inactive(file): 621192 kB > Unevictable: 0 kB > Mlocked: 0 kB > SwapTotal: 0 kB > SwapFree: 0 kB > Dirty:28 kB > Writeback: 0 kB > AnonPages: 3327100 kB > Mapped: 450524 kB > Shmem:682688 kB > Slab:2764932 kB > SReclaimable:1286500 kB > SUnreclaim: 1478432 kB > KernelStack: 11024 kB > PageTables:30728 kB > NFS_Unstable: 0 kB > Bounce:0 kB > WritebackTmp: 0 kB > CommitLimit: 8175072 kB > Committed_AS:8113820 kB > VmallocTotal: 34359738367 kB > VmallocUsed: 0 kB > VmallocChunk: 0 kB > Percpu: 8272 kB > HardwareCorrupted: 0 kB > AnonHugePages: 1359872 kB > ShmemHugePages:0 kB > ShmemPmdMapped:0 kB > HugePages_Total: 0 > HugePages_Free:0 > HugePages_Rsvd:0 > HugePages_Surp:0 > Hugepagesize: 2048 kB > Hugetlb: 0 kB > DirectMap4k: 8894708 kB > DirectMap2M: 7806976 kB > DirectMap1G: 0 kB That file works fine. > > psutil failed to parse it on your machine. > > Hmm, is this new in 2018.3.4? Didn't have this problem with 2018.3.3. As already stated. This is a bug in python3-psutil. It's not salt fault and therefore the update is not the reason. > And could it be because it's an LXC Container? Very likely. Can you send me the output of /proc/meminfo from inside the container? -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#922064: [salt-master] Salt master doesn't start anymore after update
Am Dienstag, den 12.02.2019, 17:34 +0100 schrieb Dirk Heinrichs: > Am 12.02.19 um 17:28 schrieb Benjamin Drung: > > > What version of psutil do you have installed? I cannot reproduce > > this > > crash. > > # dpkg --list|grep psutil > ii python3-psutil5.5.0-1 > amd64module providing convenience functions for managing > processes (Python3) > > > What is the output of python3 -c "import psutil; > > print(psutil.virtual_memory())" > > # python3 -c "import psutil; print(psutil.virtual_memory())" > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/psutil/__init__.py", line > 1952, > in virtual_memory > ret = _psplatform.virtual_memory() > File "/usr/lib/python3/dist-packages/psutil/_pslinux.py", line 400, > in > virtual_memory > mems[fields[0]] = int(fields[1]) * 1024 > IndexError: list index out of range So then it is a bug in psutil. Can you attach the content of /proc/meminfo? psutil failed to parse it on your machine. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#922064: [salt-master] Salt master doesn't start anymore after update
Am Montag, den 11.02.2019, 17:59 +0100 schrieb Dirk Heinrichs: > Package: salt-master > Version: 2018.3.4~git20180207+dfsg1-1 > Severity: normal The stack trace points to python3-psutil: File "/usr/bin/salt-master", line 22, in salt_master() File "/usr/lib/python3/dist-packages/salt/scripts.py", line 95, in salt_master import salt.cli.daemons File "/usr/lib/python3/dist-packages/salt/cli/daemons.py", line 48, in import salt.utils.parsers File "/usr/lib/python3/dist-packages/salt/utils/parsers.py", line 27, in import salt.config as config File "/usr/lib/python3/dist-packages/salt/config/__init__.py", line 101, in _DFLT_IPC_WBUFFER = _gather_buffer_space() * .5 File "/usr/lib/python3/dist-packages/salt/config/__init__.py", line 86, in _gather_buffer_space total_mem = psutil.virtual_memory().total File "/usr/lib/python3/dist-packages/psutil/__init__.py", line 1952, in virtual_memory ret = _psplatform.virtual_memory() File "/usr/lib/python3/dist-packages/psutil/_pslinux.py", line 400, in virtual_memory mems[fields[0]] = int(fields[1]) * 1024 What version of psutil do you have installed? I cannot reproduce this crash. What is the output of python3 -c "import psutil; print(psutil.virtual_memory())" -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#921631: [Pkg-salt-team] Bug#921631: salt-master: gitfs requires git when using pygit2 as gitfs_provider
Am Donnerstag, den 07.02.2019, 08:21 -0500 schrieb Malcolm Acker: > When using pygit2 as the gitfs_provider critical errors are thrown in > the error log if the git package is not installed: > 2019-02-07 07:44:20,180 [salt.utils.gitfs :2565][ERROR ][2577] > The git command line utility is required when using the 'pygit2' > gitfs_provider. > 2019-02-07 07:44:20,181 [salt.utils.gitfs :2468][CRITICAL][2577] No > suitable gitfs provider module is installed. > 2019-02-07 07:44:20,185 [salt.loader :1702][ERROR ][2577] > Failed to load function git.envs because its module (git) is not in > the whitelist: ['gitfs', 'roots'] > > Installing the Debian git package and restarting salt-master resolves > this issue. I have briefly tested the pygit2 python module (https > clone, commit log listing) and it does not appear the python module > on it's own requires the git binary. I checked salt/utils/gitfs.py and found out that GitProvider.clean_stale_refs() calls 'git remote prune origin'. This function is used by Pygit2._fetch(). So the git binary is still needed, unless you want to replace the 'git remote prune origin' call with a native pygit2 call. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#917429: salt-minion: Upgrade to 2018.3.3 generates some Python 2 vs 3 warnings
Am Donnerstag, den 27.12.2018, 17:56 +0100 schrieb Sylvestre Ledru: > Upgrading from 2017.7.4+dfsg1-1 to the new version generates a lot > of warnings: > 2018-12-27 17:54:41,264 [salt.loader :1524][WARNING ][20543] > Failed to import module zpool.cpython-36. Bad magic number. If > migrating from Python2 to Python3, remove all .pyc files and try > again. This is a one-time warning. salt will remove the .pyc files and the warning will be gone on the next job. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#910236: salt-master: error: Failed to load configuration: unknown error (_ssl.c:2788)
On Wed, 03 Oct 2018 20:00:31 +0200 Michael Fladischer wrote:
> Package: salt-master
> Version: 2017.7.4+dfsg1-1
> Severity: important
>
> Dear Maintainer,
>
> after a fresh install of salt-master I was unable to start it with
the default
> configuration, resulting in this error on startup:
>
> salt-master: error: Failed to load configuration: unknown error
(_ssl.c:2788)
>
> Using pudb3 I was able to get this stacktrace:
>
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/salt/utils/parsers.py", line
546, in process_config_dir
> self.config.update(self.setup_config())
> File "/usr/lib/python3/dist-packages/salt/utils/parsers.py", line
1754, in setup_config
> return config.master_config(self.get_config_file_path())
> File "/usr/lib/python3/dist-packages/salt/config/__init__.py", line
3546, in master_config
> apply_sdb(opts)
> File "/usr/lib/python3/dist-packages/salt/config/__init__.py", line
2346, in apply_sdb
> import salt.utils.sdb
> File "/usr/lib/python3/dist-packages/salt/utils/sdb.py", line 14,
in
> import salt.loader
> File "/usr/lib/python3/dist-packages/salt/loader.py", line 26, in
> import salt.utils.event
> File "/usr/lib/python3/dist-packages/salt/utils/event.py", line 70,
in
> import tornado.iostream
> File "/usr/lib/python3/dist-packages/tornado/iostream.py", line 40,
in
> from tornado.netutil import ssl_wrap_socket, ssl_match_hostname,
SSLCertificateError, _client_ssl_defaults, _server_ssl_defaults
> File "/usr/lib/python3/dist-packages/tornado/netutil.py", line 57,
in
> ssl.Purpose.SERVER_AUTH)
> File "/usr/lib/python3.6/ssl.py", line 502, in
create_default_context
> context = SSLContext(PROTOCOL_TLS)
> File "/usr/lib/python3.6/ssl.py", line 391, in __new__
> self = _SSLContext.__new__(cls, protocol)
> ssl.SSLError: unknown error (_ssl.c:2788)
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/salt/cli/daemons.py", line
132, in prepare
> super(Master, self).prepare()
> File "/usr/lib/python3/dist-packages/salt/utils/parsers.py", line
1036, in prepare
> self.parse_args()
> File "/usr/lib/python3/dist-packages/salt/utils/parsers.py", line
200, in parse_args
> process_option_func()
> File "/usr/lib/python3/dist-packages/salt/utils/parsers.py", line
549, in process_config_dir
> 'Failed to load configuration: {0}'.format(exc)
> File "/usr/lib/python3/dist-packages/salt/utils/parsers.py", line
277, in error
> self.exit(salt.defaults.exitcodes.EX_USAGE, '{0}: error:
{1}\n'.format(self.get_prog_name(), msg))
> File "/usr/lib/python3/dist-packages/salt/utils/parsers.py", line
268, in exit
> optparse.OptionParser.exit(self, status, msg)
> File "/usr/lib/python3.6/optparse.py", line 1559, in exit
> sys.exit(status)
> SystemExit: 64
>
> Strangely I'm unable to reproduce this behaviour by manually
repeating the SSLContext creation in the Python REPL.
Can you please retest with salt >= 2018.3.3+dfsg1-1?
--
Benjamin Drung
System Developer
Debian & Ubuntu Developer
1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss
Member of United Internet
Bug#921658: [Pkg-salt-team] Bug#921658: salt build depends on python3-cassandra that is not in buster
Am Donnerstag, den 07.02.2019, 16:43 -0300 schrieb eamanu15: > Hi > > El jue., 7 de feb. de 2019 a la(s) 16:38, Benjamin Drung ( > benjamin.dr...@cloud.ionos.com) escribió: > > Am Donnerstag, den 07.02.2019, 15:52 -0300 schrieb eamanu15: > > > Hello, > > > > > > python-cassandra is in process to adopt by me > > > > > > Please see: 888400 and 914650 > > > > Please let me know once the fixed python-cassandra version is > > available > > in testing. Then I will happily add the build dependency back to > > salt. > > Currently, I am searching an sporsor. I was working with Hector Oron > on upload. But I did not have notice about him (#888400). > > Could you help me to upload? Currently I am quite busy. If you haven't found a sponsor until next week, feel free to ping me. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#921658: [Pkg-salt-team] Bug#921658: salt build depends on python3-cassandra that is not in buster
Am Donnerstag, den 07.02.2019, 15:52 -0300 schrieb eamanu15: > Hello, > > python-cassandra is in process to adopt by me > > Please see: 888400 and 914650 Please let me know once the fixed python-cassandra version is available in testing. Then I will happily add the build dependency back to salt. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#921658: [Pkg-salt-team] Bug#921658: salt build depends on python3-cassandra that is not in buster
Am Donnerstag, den 07.02.2019, 20:12 +0200 schrieb Adrian Bunk: > Source: salt > Version: 2018.3.3+dfsg1-2 > Severity: serious > Tags: ftbfs > Control: block -1 by 857298 > > salt build depends on python3-cassandra that is not > in buster due to #857298. python3-cassandra is just a build dependency for running the tests. I will drop it for now. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#921630: [Pkg-salt-team] Bug#921630: salt-common: Python DeprecationWarning when using platform.linux_distribution in Python 3.5+
Hi, Am Donnerstag, den 07.02.2019, 08:05 -0500 schrieb Malcolm Acker: > Package: salt-common > Version: 2018.3.3+dfsg1-2 > Severity: normal > > Dear Maintainer, > > The following error messages are printed to console/log and causes > issues with OS-level targeting via grains: > > 2019-02-07 07:34:10,823 [py.warnings :110 ][WARNING ][1645] > /usr/lib/python3/dist-packages/salt/loader.py:741: > DeprecationWarning: dist() and linux_distribution() functions are > deprecated in Python 3.5 > ret = funcs[key]() > > 2019-02-07 07:34:10,884 [py.warnings :110 ][WARNING ][1645] > /usr/lib/python3/dist-packages/salt/grains/core.py:1756: > DeprecationWarning: dist() and linux_distribution() functions are > deprecated in Python 3.5 > linux_distribution(supported_dists=_supported_dists)] > > This is solved upstream in the following merge request: > - https://github.com/saltstack/salt/pull/50822/ > > This fix requires an additional package dependency: python3-distro I don't like that pull requests. I makes the code more longer, harder to read, and requires python3-distro for Python 3.7. I came up with a different solution (two hours before you created this bug report): https://github.com/saltstack/salt/pull/51541 -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#919231: Salt-master unable to access directories
reassign 919231 systemd 240-5 retitle 919231 CacheDirectory/StateDirectory does not change owner/group thanks Hi Stijn, your bug description was enough for me to reproduce this misbehavior and tracked it down to systemd not behaving like the documentation describes: StateDirectory=, CacheDirectory= Except in case of ConfigurationDirectory=, the innermost specified directories will be owned by the user and group specified in User= and Group=. If the specified directories already exist and their owning user or group do not match the configured ones, all files and directories below the specified directories as well as the directories themselves will have their file ownership recursively changed to match what is configured. As an optimization, if the specified directories are already owned by the right user and group, files and directories below of them are left as-is, even if they do not match what is requested. The salt-master systemd service is configured to use /var/lib/salt/pki/master and /var/cache/salt/master as state and cache directory. salt should change the ownership, but it does not. Steps to reproduce: Take a minimal Debian 9 installation and: ``` root@debian:~# apt install salt-master root@debian:~# sed -i 's/stretch/buster/g' /etc/apt/sources.list root@debian:~# apt upgrade [...] Setting up salt-master (2018.3.3+dfsg1-2) ... Installing new version of config file /etc/salt/master ... Job for salt-master.service failed because the control process exited with error code. See "systemctl status salt-master.service" and "journalctl -xe" for details. invoke-rc.d: initscript salt-master, action "restart" failed. ● salt-master.service - The Salt Master Server Loaded: loaded (/lib/systemd/system/salt-master.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2019-02-06 16:16:37 UTC; 8ms ago Docs: man:salt-master(1) file:///usr/share/doc/salt/html/contents.html https://docs.saltstack.com/en/latest/contents.html Process: 31417 ExecStart=/usr/bin/salt-master (code=exited, status=13) Main PID: 31417 (code=exited, status=13) Feb 06 16:16:37 debian systemd[1]: Starting The Salt Master Server... Feb 06 16:16:37 debian salt-master[31417]: Failed to create directory path "/var/lib/salt/pki/master/minions" - [Errno 13] Permission denied: '/var/lib/salt/pki/master/minions' Feb 06 16:16:37 debian systemd[1]: salt-master.service: Main process exited, code=exited, status=13/n/a Feb 06 16:16:37 debian systemd[1]: salt-master.service: Failed with result 'exit-code'. Feb 06 16:16:37 debian systemd[1]: Failed to start The Salt Master Server. dpkg: error processing package salt-master (--configure): installed salt-master package post-installation script subprocess returned error exit status 1 [...] ``` Instead of doing an upgrade test, you can just do the test on testing by stopping salt-master, changing the permission to root and starting salt-master. ``` root@debian:~# systemctl cat salt-master.service # /lib/systemd/system/salt-master.service [Unit] Description=The Salt Master Server Documentation=man:salt-master(1) file:///usr/share/doc/salt/html/contents.html https://docs.saltstack.com/en/latest/contents.html After=network.target [Service] LimitNOFILE=10 Type=notify NotifyAccess=all ExecStart=/usr/bin/salt-master User=salt Group=salt CacheDirectory=salt/master RuntimeDirectory=salt StateDirectory=salt/pki/master [Install] WantedBy=multi-user.target root@debian:~# ls -ld /var/lib/salt /var/lib/salt/pki /var/lib/salt/pki/master drwxr-xr-x 3 salt salt 4096 Feb 6 16:16 /var/lib/salt drwxr-xr-x 3 root root 4096 Feb 6 16:16 /var/lib/salt/pki drwx-- 7 root root 4096 Feb 6 16:10 /var/lib/salt/pki/master root@debian:~# ls -ld /var/cache/salt /var/cache/salt/master drwxr-xr-x 3 root root 4096 Feb 6 16:10 /var/cache/salt drwxr-xr-x 8 root root 4096 Feb 6 16:11 /var/cache/salt/master rroot@debian:~# dpkg -l | grep systemd | sed 's/ \+amd64 .*$//' ii libnss-systemd:amd64 240-5 ii libpam-systemd:amd64 240-5 ii libsystemd0:amd64 240-5 ii python-systemd234-2+b1 ii python3-systemd 234-2+b1 ii systemd 240-5 ii systemd-sysv 240-5 ``` The workaround is to manually change the owner/group to salt: root@debian:~# chown -R salt:salt /var/lib/salt/pki/master /var/cache/salt/master root@debian:~# systemctl start salt-master -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#920116: u-boot-exynos: broken console setting on odroid-U3
Hi,
On Mon, 21 Jan 2019 15:00:11 -0800 Vagrant Cascadian wrote:
> Package: u-boot-exynos
> Version: 2019.01+dfsg-1
> Severity: important
>
> Upstream reverted a patch that was present in all v2018.x u-boot
> versions that sets the console variable to include the console=
> argument, so boot scripts will set console=console=ttyAC1,115200
instead
> of console=ttyAC1,115200.
>
>
https://git.denx.de/?p=u-boot.git;a=commit;h=767edf0f6b3eaa0303f3fd6afdc14ddce0aca70c
>
> In order for platforms to behave consistantly on Debian, Debian's u-
boot
> package should re-apply the patch (which was carried in one form or
> another for prior Debian u-boot-exynos packages)...
>
> Interestingly enough, as of stretch's kernel, odroid-U3 doesn't need
to
> set a console= argument at all, linux will get the appropriate values
> from the device-tree.
I stumbled over exactly the same issue with my Odroid HC1 board.
Attached a patch to address the reason for the revert and revert the
revert.
--
Benjamin Drung
Debian & Ubuntu Developer
From 82987dbf64ab031482eee52267e2fb1edce52531 Mon Sep 17 00:00:00 2001
From: Dongjin Kim
Date: Sat, 28 Oct 2017 00:22:27 -0400
Subject: [PATCH] arm: config: fix default console only to specify the device
This reverts commit 767edf0f6b3eaa0303f3fd6afdc14ddce0aca70c and restores
commit 232ed3ca534708527a9515c7c41bc3542949525c.
Debian's flash-kernel expect the console variable to just contain the device,
because it will set the bootargs to "console=${console}". So revert adding
"console=" to the console parameter, but also adjust the shipped bootscripts
for exynos boards to cope with it.
Bug-Debian: https://bugs.debian.org/920116
Signed-off-by: Benjamin Drung
---
board/samsung/common/bootscripts/autoboot.cmd | 2 +-
board/samsung/common/bootscripts/bootzimg.cmd | 4 ++--
board/samsung/common/dfu_sample_env.txt | 4 ++--
include/configs/odroid.h | 4 ++--
include/configs/odroid_xu3.h | 4 ++--
include/configs/s5p_goni.h| 4 ++--
include/configs/s5pc210_universal.h | 4 ++--
include/configs/trats.h | 4 ++--
include/configs/trats2.h | 4 ++--
9 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/board/samsung/common/bootscripts/autoboot.cmd b/board/samsung/common/bootscripts/autoboot.cmd
index 11c724c4e09..e0c691e6656 100644
--- a/board/samsung/common/bootscripts/autoboot.cmd
+++ b/board/samsung/common/bootscripts/autoboot.cmd
@@ -12,7 +12,7 @@ setenv initrdaddr "4200"
setenv loaddtb "load mmc ${mmcbootdev}:${mmcbootpart} ${fdtaddr} ${fdtfile}"
setenv loadinitrd "load mmc ${mmcbootdev}:${mmcbootpart} ${initrdaddr} ${initrdname}"
setenv loadkernel "load mmc ${mmcbootdev}:${mmcbootpart} '${kerneladdr}' '${kernelname}'"
-setenv kernel_args "setenv bootargs ${console} root=/dev/mmcblk${mmcrootdev}p${mmcrootpart} rootfstype=${rootfstype} rootwait ${opts}"
+setenv kernel_args "setenv bootargs console=${console} root=/dev/mmcblk${mmcrootdev}p${mmcrootpart} rootfstype=${rootfstype} rootwait ${opts}"
Routine: check_dtb - check that target.dtb exists on boot partition
setenv check_dtb "
diff --git a/board/samsung/common/bootscripts/bootzimg.cmd b/board/samsung/common/bootscripts/bootzimg.cmd
index 2fb4c163a73..ea4bec47646 100644
--- a/board/samsung/common/bootscripts/bootzimg.cmd
+++ b/board/samsung/common/bootscripts/bootzimg.cmd
@@ -1,5 +1,5 @@
setenv kernelname zImage;
-setenv boot_kernel "setenv bootargs \"${console} root=/dev/mmcblk${mmcrootdev}p${mmcrootpart} rootfstype=${rootfstype} rootwait ${opts}\";
+setenv boot_kernel "setenv bootargs \"console=${console} root=/dev/mmcblk${mmcrootdev}p${mmcrootpart} rootfstype=${rootfstype} rootwait ${opts}\";
load mmc ${mmcbootdev}:${mmcbootpart} 0x40007FC0 '${kernelname}';
if load mmc ${mmcbootdev}:${mmcbootpart} 4080 ${fdtfile}; then
bootz 0x40007FC0 - 4080;
@@ -7,4 +7,4 @@ else
echo Warning! Booting without DTB: '${fdtfile}'!;
bootz 0x40007FC0 -;
fi;"
-run boot_kernel;
\ No newline at end of file
+run boot_kernel;
diff --git a/board/samsung/common/dfu_sample_env.txt b/board/samsung/common/dfu_sample_env.txt
index d6ee8a228a8..cbd788ec670 100644
--- a/board/samsung/common/dfu_sample_env.txt
+++ b/board/samsung/common/dfu_sample_env.txt
@@ -1,9 +1,9 @@
-mmcboot=setenv bootargs root=/dev/mmcblk${mmcdev}p${mmcrootpart} ${rootfstype} rootwait ${console}; run loaduimage; bootm 0x40007FC0
+mmcboot=setenv bootargs root=/dev/mmcblk${mmcdev}p${mmcrootpart} ${rootfstype} rootwait console=${console}; run loaduimage; bootm 0x40007FC0
rootfstype=ext4
loaduimage=ext4load mmc ${mmcdev}:${mmcbootpart} 0x40007FC0 uImage
mmcdev=0
mmcbootpart=2
mmcrootpart=5
-console=console=ttySAC2,115200n8
+console=ttySAC2,115200
Bug#918800: PROBLEM: USB 3.0 NIC operates only at USB 2.0 speed on Odroid HC1
Hi, The Odroid HC1 ARM board contains a JMicron JMS578 USB 3.0 to SATA Bridge and a Realtek Gbps Ethernet device connected to an USB 3.0 host. The SATA bridge works correctly at USB 3.0 speed, but the Ethernet controller operates only at USB 2.0 speed. I tracked this behaviour down to the CONFIG_USB_XHCI_PLATFORM kernel configuration. The r8152 driver operates only at 480M when using CONFIG_USB_XHCI_PLATFORM=m: root@odroid:~# lsusb -t /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M root@odroid:~# dmesg | grep 'usb \?[56]\|dwc3' [3.538934] exynos-dwc3 soc:usb3-0: Linked as a consumer to regulator.9 [3.544589] exynos-dwc3 soc:usb3-0: Linked as a consumer to regulator.11 [3.551085] dwc3 1200.dwc3: Failed to get clk 'ref': -2 [3.557547] exynos-dwc3 soc:usb3-1: Linked as a consumer to regulator.9 [3.563377] exynos-dwc3 soc:usb3-1: Linked as a consumer to regulator.11 [3.569830] dwc3 1240.dwc3: Failed to get clk 'ref': -2 [4.518245] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.00 [4.526207] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [4.533316] usb usb5: Product: xHCI Host Controller [4.538166] usb usb5: Manufacturer: Linux 5.0.0-rc4 xhci-hcd [4.543807] usb usb5: SerialNumber: xhci-hcd.1.auto [4.576021] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM. [4.584112] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.00 [4.592349] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [4.599430] usb usb6: Product: xHCI Host Controller [4.604286] usb usb6: Manufacturer: Linux 5.0.0-rc4 xhci-hcd [4.609917] usb usb6: SerialNumber: xhci-hcd.1.auto [5.103725] usb 5-1: new high-speed USB device number 2 using xhci-hcd [5.256710] usb 5-1: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00 [5.263420] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [5.270526] usb 5-1: Product: USB 10/100/1000 LAN [5.275203] usb 5-1: Manufacturer: Realtek [5.279274] usb 5-1: SerialNumber: 0100 [5.504131] usb 5-1: reset high-speed USB device number 2 using xhci-hcd When changing to CONFIG_USB_XHCI_PLATFORM=y, it works as expected: root@odroid:~# lsusb -t /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M root@odroid:~# dmesg | grep 'usb \?[56]\|dwc3' [3.572120] exynos-dwc3 soc:usb3-0: Linked as a consumer to regulator.9 [3.577802] exynos-dwc3 soc:usb3-0: Linked as a consumer to regulator.11 [3.584308] dwc3 1200.dwc3: Failed to get clk 'ref': -2 [3.723387] exynos-dwc3 soc:usb3-1: Linked as a consumer to regulator.9 [3.729518] exynos-dwc3 soc:usb3-1: Linked as a consumer to regulator.11 [3.735952] dwc3 1240.dwc3: Failed to get clk 'ref': -2 [3.769931] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.00 [3.777877] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [3.785068] usb usb5: Product: xHCI Host Controller [3.789919] usb usb5: Manufacturer: Linux 5.0.0-rc4 xhci-hcd [3.795551] usb usb5: SerialNumber: xhci-hcd.1.auto [3.827760] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM. [3.835868] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.00 [3.843995] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [3.851185] usb usb6: Product: xHCI Host Controller [3.856036] usb usb6: Manufacturer: Linux 5.0.0-rc4 xhci-hcd [3.861669] usb usb6: SerialNumber: xhci-hcd.1.auto [5.024304] usb 6-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd [5.049333] usb 6-1: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00 [5.056049] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [5.063154] usb 6-1: Product: USB 10/100/1000 LAN [5.067829] usb 6-1:
Bug#919231: [Pkg-salt-team] Bug#919231: salt-master: Upgrade Stretch -> Buster: permission denied on certain files/directories
Hi, Am Sonntag, den 13.01.2019, 23:00 +0100 schrieb Stijn Segers: > Package: salt-master > Version: 2018.3.3+dfsg1-2 > Severity: important > > Dear Maintainer, > > Upgrading salt-master from its Stretch version to Buster (whole > system was > upgraded) breaks the Salt master. > > [...] > Permission denied: '/var/cache/salt/master/.salt_key' > > [...] > Permission denied: '/var/lib/salt/pki/master/minions' The salt master service in /lib/systemd/system/salt-master.service is configured as following: [Service] User=salt Group=salt CacheDirectory=salt/master RuntimeDirectory=salt StateDirectory=salt/pki/master Which means that systemd should take care to correctly set the permission in /var/cache/salt/master, /run/salt, and /var/lib/salt/pki/master. This might be a systemd bug. Further troubleshooting is needed... -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#899002: systemd: networking and rdma-load-modules@infiniband service run in parallel despite the declared dependency order
tags 899002 buster severity 899002 grave thanks Hi, This race condition bug hit me also with an Odroid HC1. This ARM boards has an Ethernet controller connected over USB. Without this bugfix, the networking service does not wait until the USB hub is initialised and the Ethernet controller is found: root@odroid:~# journalctl --no-pager -u networking -- Logs begin at Fri 2018-06-22 11:11:49 UTC, end at Fri 2018-06-22 11:17:01 UTC. -- Jun 22 11:11:50 odroid systemd[1]: Starting Raise network interfaces... Jun 22 11:11:51 odroid dhclient[331]: Internet Systems Consortium DHCP Client 4.3.5 Jun 22 11:11:51 odroid dhclient[331]: Copyright 2004-2016 Internet Systems Consortium. Jun 22 11:11:51 odroid ifup[316]: Internet Systems Consortium DHCP Client 4.3.5 Jun 22 11:11:51 odroid ifup[316]: Copyright 2004-2016 Internet Systems Consortium. Jun 22 11:11:51 odroid ifup[316]: All rights reserved. Jun 22 11:11:51 odroid ifup[316]: For info, please visit https://www.isc.org/software/dhcp/ Jun 22 11:11:51 odroid dhclient[331]: All rights reserved. Jun 22 11:11:51 odroid dhclient[331]: For info, please visit https://www.isc.org/software/dhcp/ Jun 22 11:11:51 odroid dhclient[331]: Jun 22 11:11:51 odroid ifup[316]: Cannot find device "eth0" Jun 22 11:11:51 odroid dhclient[331]: Failed to get interface index: No such device Jun 22 11:11:51 odroid ifup[316]: Failed to get interface index: No such device Jun 22 11:11:51 odroid ifup[316]: If you think you have received this message due to a bug rather Jun 22 11:11:51 odroid ifup[316]: than a configuration issue please read the section on submitting Jun 22 11:11:51 odroid ifup[316]: bugs on either our web page at www.isc.org or in the README file Jun 22 11:11:51 odroid ifup[316]: before submitting a bug. These pages explain the proper Jun 22 11:11:51 odroid ifup[316]: process and the information we find helpful for debugging.. Jun 22 11:11:51 odroid ifup[316]: exiting. Jun 22 11:11:51 odroid dhclient[331]: Jun 22 11:11:51 odroid dhclient[331]: If you think you have received this message due to a bug rather Jun 22 11:11:51 odroid dhclient[331]: than a configuration issue please read the section on submitting Jun 22 11:11:51 odroid dhclient[331]: bugs on either our web page at www.isc.org or in the README file Jun 22 11:11:51 odroid dhclient[331]: before submitting a bug. These pages explain the proper Jun 22 11:11:51 odroid dhclient[331]: process and the information we find helpful for debugging.. Jun 22 11:11:51 odroid dhclient[331]: Jun 22 11:11:51 odroid dhclient[331]: exiting. Jun 22 11:11:51 odroid ifup[316]: ifup: failed to bring up eth0 Jun 22 11:11:51 odroid systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE Jun 22 11:11:51 odroid systemd[1]: networking.service: Failed with result 'exit-code'. Jun 22 11:11:51 odroid systemd[1]: Failed to start Raise network interfaces. For this reason I am raising the severity. Please get ifupdown >= 0.8.33 into testing! -- Benjamin Drung Debian & Ubuntu Developer
Bug#919849: [Pkg-salt-team] Bug#919849: salt-doc: broken symlinks: /usr/share/doc/salt/html/_static/*/bootstrap* -> ../../../../../twitter-bootstrap/files/*/bootstrap*
Am Montag, den 21.01.2019, 16:34 +0100 schrieb Benjamin Drung: > Am Sonntag, den 20.01.2019, 06:07 +0100 schrieb Andreas Beckmann: > > Package: salt-doc > > Version: 2018.3.3+dfsg1-2 > > Severity: normal > > User: debian...@lists.debian.org > > Usertags: piuparts > > > > Hi, > > > > during a test with piuparts I noticed your package ships (or > > creates) > > a broken symlink. > > > > From the attached log (scroll to the bottom...): > > > > 0m29.8s ERROR: FAIL: Broken symlinks: > > /usr/share/doc/salt/html/_static/js/vendor/bootstrap.min.js -> > > ../../../../../../twitter-bootstrap/files/js/bootstrap.min.js > > (salt- > > doc) > > /usr/share/doc/salt/html/_static/js/vendor/bootstrap.js -> > > ../../../../../../twitter-bootstrap/files/js/bootstrap.js (salt- > > doc) > > /usr/share/doc/salt/html/_static/css/bootstrap.min.css -> > > ../../../../../twitter-bootstrap/files/css/bootstrap.min.css (salt- > > doc) > > /usr/share/doc/salt/html/_static/css/bootstrap-responsive.min.css > > -> ../../../../../twitter-bootstrap/files/css/bootstrap- > > responsive.min.css (salt-doc) > > > > > > Is salt-doc missing a Depends/Recommends/Suggests: libjs-twitter- > > bootstrap ? > > salt-doc depends on libjs-bootstrap to provide these files. Sadly the > path has changed between the version in stable and in unstable. I > will fix the symlinks with the next upload. I saw it wrong. The path in stable and unstable are the same. I probably overlooked the changed path between src:twitter-bootstrap and src:twitter-bootstrap3. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#919849: [Pkg-salt-team] Bug#919849: salt-doc: broken symlinks: /usr/share/doc/salt/html/_static/*/bootstrap* -> ../../../../../twitter-bootstrap/files/*/bootstrap*
Am Sonntag, den 20.01.2019, 06:07 +0100 schrieb Andreas Beckmann: > Package: salt-doc > Version: 2018.3.3+dfsg1-2 > Severity: normal > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > > From the attached log (scroll to the bottom...): > > 0m29.8s ERROR: FAIL: Broken symlinks: > /usr/share/doc/salt/html/_static/js/vendor/bootstrap.min.js -> > ../../../../../../twitter-bootstrap/files/js/bootstrap.min.js (salt- > doc) > /usr/share/doc/salt/html/_static/js/vendor/bootstrap.js -> > ../../../../../../twitter-bootstrap/files/js/bootstrap.js (salt-doc) > /usr/share/doc/salt/html/_static/css/bootstrap.min.css -> > ../../../../../twitter-bootstrap/files/css/bootstrap.min.css (salt- > doc) > /usr/share/doc/salt/html/_static/css/bootstrap-responsive.min.css > -> ../../../../../twitter-bootstrap/files/css/bootstrap- > responsive.min.css (salt-doc) > > > Is salt-doc missing a Depends/Recommends/Suggests: libjs-twitter- > bootstrap ? salt-doc depends on libjs-bootstrap to provide these files. Sadly the path has changed between the version in stable and in unstable. I will fix the symlinks with the next upload. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#919690: ifupdown: ifquery from ifup@.service fails with exit code 1 on boot
Package: ifupdown Version: 0.8.34 Severity: important Hi, I have a Debian live system (using live-boot) launched in QEMU with a static network configuration. live-boot brings up the network interface ens3 in the initrd to fetch the squashfs root image. The ifup@ens3.service fails: ``` $ systemctl status ifup@ens3.service ● ifup@ens3.service - ifup for ens3 Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2019-01-18 15:26:29 UTC; 9min ago Process: 696 ExecStart=/bin/sh -ec ifup --allow=hotplug ens3; ifquery --state ens3 (code=exited, status=1/FAILURE) Main PID: 696 (code=exited, status=1/FAILURE) Jan 18 15:26:29 systemd[1]: Started ifup for ens3. Jan 18 15:26:29 systemd[1]: ifup@ens3.service: Main process exited, code=exited, status=1/FAILURE Jan 18 15:26:29 systemd[1]: ifup@ens3.service: Failed with result 'exit-code'. ``` Adding --verbose to ifup and ifquery revealed that ifquery fails with exit code 1, but does not produce any output. The journal shows that ifup@ens3.service exits before ens3 is ready: ``` Jan 18 15:26:29 systemd[1]: Started ifup for ens3. Jan 18 15:26:29 systemd[1]: ifup@ens3.service: Main process exited, code=exited, status=1/FAILURE Jan 18 15:26:29 systemd[1]: ifup@ens3.service: Failed with result 'exit-code'. Jan 18 15:26:30 systemd-udevd[491]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Jan 18 15:26:30 systemd-udevd[491]: Could not generate persistent MAC address for ethoipsix0: No such file or directory Jan 18 15:26:30 kernel: IPv6: ADDRCONF(NETDEV_UP): ens3: link is not ready Jan 18 15:26:30 kernel: e1000: ens3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Jan 18 15:26:30 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): ens3: link becomes ready ``` -- Package-specific info: --- /etc/network/interfaces: # interfaces(5) file used by ifup(8) and ifdown(8) # Include files from /etc/network/interfaces.d: source-directory /etc/network/interfaces.d # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto ens3 iface ens3 inet static address 10.91.240.1/22 pre-up ip address flush dev $IFACE up ip route add 10.0.0.0/8 via 10.91.243.254 dev $IFACE up ip route add 192.168.0.0/16 via 10.91.243.254 dev $IFACE up sysctl -w net.ipv4.conf.ens3.forwarding=0 --- up and down scripts installed: /etc/network/if-down.d: total 1 -rwxr-xr-x 1 root root 256 Apr 1 2016 resolvconf /etc/network/if-post-down.d: total 0 /etc/network/if-pre-up.d: total 1 -rwxr-xr-x 1 root root 344 Jun 30 2016 ethtool /etc/network/if-up.d: total 3 -rwxr-xr-x 1 root root 817 Apr 1 2016 000resolvconf -rwxr-xr-x 1 root root 1685 Jun 30 2016 ethtool -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ifupdown depends on: ii adduser 3.118 ii iproute2 4.20.0-2 ii libc6 2.28-5 ii lsb-base 10.2018112800 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.4.1-2 Versions of packages ifupdown suggests: pn ppp pn rdnssd -- no debconf information
Bug#918800: linux-image-4.19.0-1-armmp-lpae: USB 3.0 network card operates only at USB 2.0 speed on Odroid HC1
Package: src:linux Version: 4.19.12-1 Severity: normal Dear Maintainer, The Odroid HC1 ARM board contains a JMicron JMS578 USB 3.0 to SATA Bridge and a Realtek Gbps Ethernet device connected to an USB 3.0 host. The SATA bridge works correctly at USB 3.0 speed, but the Ethernet controller operates only at USB 2.0 speed: root@odroid:~# lsusb -t /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M I have tested linux 4.19.12-1 from Debian testing, 4.19.13-1 from unstable and 4.20-1~exp1 from experimental. They all show the same behavior. -- Package-specific info: ** Version: Linux version 4.19.0-1-armmp-lpae (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.19.13-1 (2018-12-30) ** Command line: net.ifnames=0 console=ttySAC2,115200n8 ** Not tainted ** Kernel log: root@odroid:~# dmesg | grep 'usb \?3' [8.637794] exynos5_usb3drd_phy 1210.phy: 1210.phy supply vbus not found, using dummy regulator [8.645903] exynos5_usb3drd_phy 1210.phy: Linked as a consumer to regulator.0 [8.653300] exynos5_usb3drd_phy 1210.phy: 1210.phy supply vbus-boost not found, using dummy regulator [8.672414] exynos5_usb3drd_phy 1250.phy: 1250.phy supply vbus not found, using dummy regulator [8.672550] exynos5_usb3drd_phy 1250.phy: Linked as a consumer to regulator.0 [8.672570] exynos5_usb3drd_phy 1250.phy: 1250.phy supply vbus-boost not found, using dummy regulator [8.958202] exynos-dwc3 soc:usb3-0: Linked as a consumer to regulator.9 [8.963984] exynos-dwc3 soc:usb3-0: Linked as a consumer to regulator.11 [8.973066] exynos-dwc3 soc:usb3-1: Linked as a consumer to regulator.9 [8.978923] exynos-dwc3 soc:usb3-1: Linked as a consumer to regulator.11 [9.140610] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19 [9.153605] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [9.170064] usb usb3: Product: xHCI Host Controller [9.170074] usb usb3: Manufacturer: Linux 4.19.0-1-armmp-lpae xhci-hcd [9.181849] usb usb3: SerialNumber: xhci-hcd.4.auto [9.766820] usb 3-1: new high-speed USB device number 2 using xhci-hcd [9.919833] usb 3-1: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00 [9.926565] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [9.933682] usb 3-1: Product: USB 10/100/1000 LAN [9.938356] usb 3-1: Manufacturer: Realtek [9.942417] usb 3-1: SerialNumber: 0100 [ 14.805113] usb 3-1: reset high-speed USB device number 2 using xhci-hcd Full kernel log is attached. ** Model information Hardware: SAMSUNG EXYNOS (Flattened Device Tree) Revision: Device Tree model: Hardkernel Odroid HC1 ** Loaded modules: cdc_ether usbnet r8152 mii sg pwm_samsung exynos_trng rng_core s3c2410_wdt leds_pwm cpufreq_dt ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb sd_mod uas usb_storage scsi_mod xhci_plat_hcd xhci_hcd dwc3 udc_core phy_generic clk_s2mps11 s2mps11 phy_exynos_mipi_video dwc3_exynos phy_exynos_dp_video ohci_exynos ohci_hcd ehci_exynos ehci_hcd dw_mmc_exynos dw_mmc_pltfm i2c_exynos5 usbcore dw_mmc phy_exynos_usb2 phy_exynos5_usbdrd ** PCI devices: not available ** USB devices: Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 4.19.0-1-armmp-lpae (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-4.19.0-1-armmp-lpae depends on: ii initramfs-tools [linux-initramfs-tool] 0.132 ii kmod25-2 ii linux-base 4.5 Versions of packages linux-image-4.19.0-1-armmp-lpae
Bug#917090: flash-kernel: Please avoid leading or trailing spaces in bootargs
Package: flash-kernel
Version: 3.96
Severity: normal
Tags: patch
Dear Maintainer,
Leading or trailing spaces in bootargs and therefore /proc/cmdline are
inconvenient. Avoid them by only adding spaces between parameters that are not
empty. A patch for that is attached.
I have successfully tested it on Hardkernel's Odroid HC1.
--
Benjamin Drung
Debian & Ubuntu Developer
>From 38bb9da092897928666175042ac0cc34f0777075 Mon Sep 17 00:00:00 2001
From: Benjamin Drung
Date: Sat, 22 Dec 2018 13:47:58 +0100
Subject: [PATCH] Avoid leading or trailing spaces in bootargs
Leading or trailing spaces in bootargs and therefore /proc/cmdline are
inconvenient. Avoid them by only adding spaces between parameters that are not
empty.
Tested on Hardkernel's Odroid HC1.
---
bootscript/all/bootscr.uboot-generic | 8 ++--
bootscript/arm64/bootscr.uboot-generic | 8 ++--
bootscript/armhf/bootscr.sunxi | 8 ++--
functions | 15 +--
4 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/bootscript/all/bootscr.uboot-generic
b/bootscript/all/bootscr.uboot-generic
index 989f14c..631955f 100644
--- a/bootscript/all/bootscr.uboot-generic
+++ b/bootscript/all/bootscr.uboot-generic
@@ -22,10 +22,14 @@ if test "${console}" = "ttymxc0" && test -n "${baudrate}";
then
fi
if test -n "${console}"; then
- setenv bootargs "${bootargs} console=${console}"
+ if test -n "${bootargs}"; then
+setenv bootargs "${bootargs} console=${console}"
+ else
+setenv bootargs "console=${console}"
+ fi
fi
-setenv bootargs "@@LINUX_KERNEL_CMDLINE_DEFAULTS@@ ${bootargs}
@@LINUX_KERNEL_CMDLINE@@"
+setenv bootargs
"@@LINUX_KERNEL_CMDLINE_DEFAULTSLINUX_KERNEL_CMDLINE_DEFAULTS_DELIM@@${bootargs}@@LINUX_KERNEL_CMDLINE_DELIMLINUX_KERNEL_CMDLINE@@"
@@UBOOT_ENV_EXTRA@@
if test -z "${fk_kvers}"; then
diff --git a/bootscript/arm64/bootscr.uboot-generic
b/bootscript/arm64/bootscr.uboot-generic
index 33f90d2..d644ee5 100644
--- a/bootscript/arm64/bootscr.uboot-generic
+++ b/bootscript/arm64/bootscr.uboot-generic
@@ -15,10 +15,14 @@
# The uboot must support the booti and generic filesystem load commands.
if test -n "${console}"; then
- setenv bootargs "${bootargs} console=${console}"
+ if test -n "${bootargs}"; then
+setenv bootargs "${bootargs} console=${console}"
+ else
+setenv bootargs "console=${console}"
+ fi
fi
-setenv bootargs @@LINUX_KERNEL_CMDLINE_DEFAULTS@@ ${bootargs}
@@LINUX_KERNEL_CMDLINE@@
+setenv bootargs
"@@LINUX_KERNEL_CMDLINE_DEFAULTSLINUX_KERNEL_CMDLINE_DEFAULTS_DELIM@@${bootargs}@@LINUX_KERNEL_CMDLINE_DELIMLINUX_KERNEL_CMDLINE@@"
@@UBOOT_ENV_EXTRA@@
if test -z "${fk_kvers}"; then
diff --git a/bootscript/armhf/bootscr.sunxi b/bootscript/armhf/bootscr.sunxi
index 9576b24..8750583 100644
--- a/bootscript/armhf/bootscr.sunxi
+++ b/bootscript/armhf/bootscr.sunxi
@@ -33,10 +33,14 @@ else
fi
if test -n "${console}"; then
- setenv bootargs "${bootargs} console=${console}"
+ if test -n "${bootargs}"; then
+setenv bootargs "${bootargs} console=${console}"
+ else
+setenv bootargs "console=${console}"
+ fi
fi
-setenv bootargs @@LINUX_KERNEL_CMDLINE_DEFAULTS@@ ${bootargs}
@@LINUX_KERNEL_CMDLINE@@
+setenv bootargs
"@@LINUX_KERNEL_CMDLINE_DEFAULTSLINUX_KERNEL_CMDLINE_DEFAULTS_DELIM@@${bootargs}@@LINUX_KERNEL_CMDLINE_DELIMLINUX_KERNEL_CMDLINE@@"
@@UBOOT_ENV_EXTRA@@
if test -z "${image_locations}"; then
diff --git a/functions b/functions
index 1533192..de925f8 100644
--- a/functions
+++ b/functions
@@ -432,6 +432,12 @@ get_kernel_cmdline_defaults() {
echo "$LINUX_KERNEL_CMDLINE_DEFAULTS"
}
+get_delimiter() {
+ if test -n "$1"; then
+ echo " "
+ fi
+}
+
mkimage_kernel() {
local kaddr="$1"
local epoint="$2"
@@ -475,10 +481,15 @@ mkimage_script() {
echo "WARNING: ubootenv.d snippet used, but $sdata has
no @@UBOOT_ENV_EXTRA@@ marker. Snippet will be ignored." >&2
fi
+ kernel_cmdline=$(get_kernel_cmdline)
+ kernel_cmdline_defaults=$(get_kernel_cmdline_defaults)
+
printf "Generating boot script u-boot image... " >&2
sed -e "s/@@KERNEL_VERSION@@/$kvers/g" \
--e "s!@@LINUX_KERNEL_CMDLINE@@!$(get_kernel_cmdline)!g" \
--e
"s!@@LINUX_KERNEL_CMDLINE_DEFAULTS@@!$(get_kernel_cmdline_defaults)!g" \
+-e "s!@@LINUX_KERNEL_CMDLINE@@!$kernel_cmdline!g" \
+-e
"s!@@LINUX_KERNEL_CMDLINE_DEFAULTS@@!$kernel_cmdline_defaults!g" \
+-e "s!@@LINUX_KERNEL_CMDLINE_DELIM@@!$(get_delimiter
"$kernel_cmdline")!g" \
+-e "s!@@LINUX_KERNEL_CMDLINE_DEFAULTS_DELIM@@!$(get_delimiter
"$kernel_cmdline_defaults")!g" \
-e "/@@UBOOT_ENV_EXTRA@@/{
s/@@UBOOT_ENV_EXTRA@@//g
r $ubootenv
--
2.19.1
Bug#917001: python3-twilio: twilio missing dependency on requests
Package: python3-twilio Version: 6.8.2-1 Severity: serious Hi, I get an import error on a minimal Debian chroot: ``` In [3]: from twilio.rest import Client as TwilioRestClient --- ModuleNotFoundError Traceback (most recent call last) in () > 1 from twilio.rest import Client as TwilioRestClient /usr/lib/python3/dist-packages/twilio/rest/__init__.py in () 12 from twilio.base.exceptions import TwilioException 13 from twilio.base.obsolete import obsolete_client ---> 14 from twilio.http.http_client import TwilioHttpClient 15 16 /usr/lib/python3/dist-packages/twilio/http/http_client.py in () > 1 from requests import Request, Session, hooks 2 3 from twilio.http import HttpClient 4 from twilio.http.response import Response 5 from twilio.http.request import Request as TwilioRequest ModuleNotFoundError: No module named 'requests' ``` Please add a dependency on `requests`. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#916980: flash-kernel: Please support Hardkernel's Odroid HC1/HC2 boards
Package: flash-kernel Version: 3.96 Severity: normal Tags: patch Dear Maintainer, please support Hardkernel's Odroid HC1/HC2 boards. Odroid HC1 board is based on Odroid XU4 board, but it has no HDMI, no eMMC, no built-in USB3.0 hub, no extension port pins, and no GPIO button. USB3.0 ports are used for built-in JMicron USB to SATA bridge and Gigabit R8152 ethernet chips. HC1 uses only passive cooling. The kernel ships a different device tree blob for it. I have successfully tested following flash-kernel configuration: Machine: Hardkernel Odroid HC1 Kernel-Flavors: armmp armmp-lpae DTB-Id: exynos5422-odroidhc1.dtb Boot-Script-Path: /boot/boot.scr U-Boot-Script-Name: bootscr.uboot-generic Required-Packages: u-boot-tools The Odroid HC2 uses the same hardware, but a bigger case to allow mounting a 3.5" drive instead of a 2.5" drive. The Linux kernel does not provide a HC2 DTB so the HC1 DTB is also used for the Odroid HC2. So this flash-kernel configuration should also support the Odroid HC2. -- Benjamin Drung Debian & Ubuntu Developer
Bug#896921: Upgrading salt to 2018.3.3 / tornado incompatibility
Hi everyone, I was working on salt to get it in shape before Debian freezes for the buster release. The current status is: * Pushed a building python3-tornado4 version to the tornado4 branch on salsa [tornado4]. * Pushed current state of salt 2018.3.3 packaging to the wip-2018.3 branch [wip-2018.3] * salt builds against python3-tornado on Debian stretch, but fails on Debian unstable against python3-tornado4 * Ignoring the test failures does not help: The salt-minion will fail to start on unstable * Built packages for Ubuntu 18.10 (Python 3.6) and 19.04 (Python 3.7) [ppa]: python3-tornado4 builds, but salt not Remaining work: * 4 tornado tests are failing on Python 3.7 on Debian unstable. See upstream bug #2536 [2536] * Analyze and fix salt test failures on Debian unstable (might be either tornado4 rename or Python 3.7 related) Help of getting salt working is appreciated. [tornado4] https://salsa.debian.org/python-team/modules/python-tornado/commits/tornado4 [wip-2018.3] https://salsa.debian.org/salt-team/salt/commits/wip-2018.3 [ppa] https://launchpad.net/~bdrung/+archive/ubuntu/ppa [2536] https://github.com/tornadoweb/tornado/issues/2536 -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#570623: Submitted MR on Salsa
Hi John, thanks for creating this pull request. Am Dienstag, den 13.11.2018, 15:41 -0600 schrieb John Goerzen: > One additional comment - it would probably be good to default > Limit: 1 to mimic prior behavior, wouldn't it? I changed the default to "Limit: 1", rebased the patch set on master, and created a pull request for it: https://salsa.debian.org/brlink/reprepro/merge_requests/2 -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#912348: ITP: netconsole -- Dynamically configure Linux netconsole
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: netconsole Version : 0.1 Upstream Author : Benjamin Drung * URL : https://github.com/profitbricks/netconsole * License : ISC Programming Lang: Bash Description : Dynamically configure Linux netconsole Netconsole is a Linux kernel module that sends all kernel log messages over the network to another computer. It was designed to be as instantaneous as possible, to enable the logging of even the most critical kernel bugs. It works from IRQ contexts as well, and does not enable interrupts while sending packets. Due to these unique needs, only IP networks, UDP packets and Ethernet devices are supported. This package contains a netconsole service that dynamically configures netconsole by configuring one or more hosts by their names or IP addresses. The initscripts package on CentOS 7 provides a /etc/init.d/netconsole initscript that can configure netconsole by just configuring SYSLOGADDR. The functionality is similar, but this package also provides also a systemd service and allows to specify multiple log hosts. Beside the CentOS script, I found no other tool doing this job. Therefore I published our inhouse package to get it into Debian. I am open to merge this script and service into a other packages if this package is considered to be too small. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Bug#909490: pylint: doesn't support Python 3.7
On Mon, 24 Sep 2018 15:13:19 +0200 Mattia Rizzolo wrote: > Source: pylint > Version: 1.9.2-1 > Severity: serious > > pylint needs the same care astroid received yesterday, being split into > a package version 1.9.2 building the py2 variant, and another version > 2.1.1 building the py3 variant. > > Possibly sooner rather than later, things have been stalled for months > already. I am already working on upgrading the package to 2.1.1 for Python 3. Anyone interested in working on the pylint2 source package for the Python 2 support? -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
Bug#902631: devscripts: CI fails in unstable due to Python 3.7
Hi, On Sat, 1 Sep 2018 12:43:27 +0200 Nicolas Dandrimont wrote: > > As a proof of concept I've gone and done the changes needed to pull > this off on a fork of the git repo in my personal namespace. > > https://salsa.debian.org/olasd/astroid > > The astroid source package is in the master / upstream branches; > The astroid2 source package is in the astroid2 / upstream-1.x > branches. > > I had to do some wrangling of the astroid source package, to convert > it to pybuild, because the default setuptools buildsystem only works > when python2 is in the build depends. > > I could see a point in splitting the git repositories but I don't > think that's very critical. > > I'm happy to do a NMU in a week so that we can move forward with the > split package plan. I agree on splitting the source package into the legacy Python 2 version and a recent Python 3 version. I looked at your fork in your personal namespace. It looks good to me. Since this package is team maintained, will you merge the changes and upload them (unless Sandro says something against it)? I like to open a freeze exception bug in Ubuntu and get this solution synced to Ubuntu. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
Bug#570623: reprepro: please add multiple version management
Hi everyone, I rebased the patch set on top of the 5.2.0-1 release. Attached are all 71 patches as tarball. You can also pull the multiple-versions branch from https://github.com/profitbricks/reprepro Feel free to report bugs on GitHub. Release Notes = Changes between 2017-04-12 and 2018-09-03: * Rebased on 5.2.0 * Fix missing quotation mark in component list * Fixed "Package database is not sorted!!!" by update command https://github.com/profitbricks/reprepro/issues/6 * Fixed screwing up database names by the database migration https://github.com/profitbricks/reprepro/issues/8 * Fix adding the same upstream tarball twice https://github.com/profitbricks/reprepro/issues/9 * Fix removesrc when multiple version are available -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens multiple-versions-patches-5.2.0.tar.xz Description: application/xz-compressed-tar
Bug#906280: ITP: ionit -- Render configuration files from Jinja templates
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: ionit Version : 0.1 Upstream Author : Benjamin Drung * URL : https://github.com/bdrung/ionit * License : ISC Programming Lang: Python 3 Description : Render configuration files from Jinja templates ionit is a simple and small configuration templating tool. It collects a context and renders Jinja templates in a given directory. The context can be either static JSON or YAML files or dynamic Python files. Python files can also define functions passed through to the rendering. ionit comes with an early boot one shot service that is executed before the networking service which allows one to generate configurations files for the networking and other services before they are started. In this regard, ionit can act as tiny stepbrother of cloud-init. I developed this tool since we found nothing similar. We will use ionit in our company. I will maintain the package on my own. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
Bug#906208: collectd-core: Please build against Python 3
Package: collectd-core Version: 5.7.1-1.1 Severity: normal Hi, Python 2 will reach its end of life soon and many packages in Debian are moving to Python 3. I want to get rid of Python 2 and collectd is the last package that pulls it into the system. Please build collectd against Python 3 instead of Python 2. Thanks. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
Bug#892612: ITP: conbuilder -- container-basade package builder for Debian packages
Am Sonntag, den 11.03.2018, 11:31 + schrieb Federico Ceratto: > Package: wnpp > Severity: wishlist > Owner: Federico Ceratto > > * Package name: conbuilder > Version : 0.0.1 > Upstream Author : Federico Ceratto > * URL : https://salsa.debian.org/federico/conbuilder > * License : GPLv3 > Programming Lang: Python > Description : container-basade package builder for Debian > packages > > Build Debian packages using OverlayFS and systemd namespace > containers. > > conbuilder creates a base filesystem using debootstrap, then > overlays it with a filesystem to install the required dependencies > and finally runs the build on another overlay. > > Layers are created, reused and purged automatically to achieve > fast package builds while minimizing disk usage. > > It takes less than 2 seconds to start a new build on an already > existing > overlay. What's the difference to sbuild which is configured to use overlays? -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
Bug#896921: [Pkg-salt-team] Bug#896921: Bug#896921: Salt 2018.3.2 has been released
Am Sonntag, den 01.07.2018, 10:45 +0200 schrieb Dirk Heinrichs: > Am 18.05.2018 um 10:27 schrieb Benjamin Drung: > > > 2018.3 unless there is a blocking reason. > > There's 2018.3.2 meanwhile. Can we get this one, then? Sadly no, since this version still does not work with Tornado 5 in Python 3. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens signature.asc Description: This is a digitally signed message part
Bug#894245: [Pkg-salt-team] Bug#894245: Bug#894245: Salt, Tornado Incompatibility, and ZMQ Timeline
Am Donnerstag, den 28.06.2018, 18:59 +0300 schrieb Vincas Dargis: > On Thu, 28 Jun 2018 09:42:41 +0200 Benjamin Drung > wrote: > > Am Samstag, den 16.06.2018, 22:02 +0300 schrieb Vincas Dargis: > > > 2017.7.6 is released now [0], could this fix the issue? > > > > > > [0] https://docs.saltstack.com/en/latest/topics/releases/2017.7.6. > > > html > > > > Sadly no, since we use Python 3 and this combination still does not > > work: https://github.com/saltstack/salt-jenkins/issues/995 > > Oh well. > > I guess I should switch my salt-master to some Stretch VM then. > > Does this kind of "hard breakage" occurs frequently on Sid with Salt > (I > use Sid for less than a year)? It's the first time since I'm involved. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506B. Geschäftsführer: Andreas Gauger, Achim Weiss.
Bug#894245: [Pkg-salt-team] Bug#894245: Salt, Tornado Incompatibility, and ZMQ Timeline
Am Samstag, den 16.06.2018, 22:02 +0300 schrieb Vincas Dargis: > On Wed, 2 May 2018 12:15:12 -0400 Jamie Bliss > > wrote: > > On Wed, May 2, 2018 at 11:34 AM, Jamie Bliss > m> > > wrote: > > #896921. It was merged April 25 into 2017.7, so should make it into > > the > > next point releases for 2017.7 and 2018.3. > > 2017.7.6 is released now [0], could this fix the issue? > > [0] https://docs.saltstack.com/en/latest/topics/releases/2017.7.6.html Sadly no, since we use Python 3 and this combination still does not work: https://github.com/saltstack/salt-jenkins/issues/995 -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506B. Geschäftsführer: Andreas Gauger, Achim Weiss.
Bug#896921: [Pkg-salt-team] Bug#896921: Salt / tornado incompatibility - new upstream release is out with a fix
Am Montag, den 25.06.2018, 17:05 +0100 schrieb Shish: > Looks like 2018.3.1 is out, and the version installed from upstream's > personal repository no longer has the bug :) > > Specifically, I'm using > http://repo.saltstack.com/apt/debian/9/amd64/latest/pool/main/s/salt/ > on Buster The difference between the upstream package and the package in Debian is that Debian's package uses Python 3 instead of Python 2. Sadly, tornado 5 is still not supported in salt 2018.3.1 if Python 3 is used. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
Bug#902361: [pkg-go] Bug#902361: golang-pault-go-archive: Please update to >= 0.0~git20180624.470edde
Am Montag, den 25.06.2018, 10:16 -0400 schrieb Paul R. Tagliamonte: > I'm happy to tag a release for whoever's packaging. File a bug on the > repo before you want to dput Michael, will you update the package? -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
Bug#902361: golang-pault-go-archive: Please update to >= 0.0~git20180624.470edde
Package: golang-pault-go-archive Version: 0.0~git20180223.29fe7b6-1 Severity: normal Hi, please update golang-pault-go-archive to >= 0.0~git20180624.470edde to expose Downloader.Keyring (needed for debiman). Thanks. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
