Bug#870287: ITP: gnome-shell-extension-gnome-docker-integration -- hide veth devices in network-manager typically used by Docker and LXC
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: gnome-shell-extension-gnome-docker-integration Version : unreleased Upstream Author : Jan Trejbal * URL : https://github.com/Trejjam/Gnome-Docker-integration * License : GPLv3 Programming Lang: JavaScript Description : hide veth devices in network-manager typically used by Docker and LXC Hides the veth devides in network-manager when using tools that create veth devices, such as Docker and LXC.
Detached upstream signature and git packaging
Hi,
TL;DR We need to define a way to store detached upstream signatures in git.
I'm including a proposal, suggestions welcome.
Not too long ago both uscan and dpkg-source added support for detached
upstream signatures, that is: a signed pgp signature for each upstream
released tarball.
For this to be of any use, the source package needs to ship the keyring of the
upstream public keys (debian/upstream/signing-key.{asc,pgp}), with that uscan
can check the validity of the tarball.
dpkg-source can also add the detached signatures in the corresponding
changes files and upload them as part of the source package, this way
these could be published in the archive and checked by our users.
So far so good, but for packagers that work on git repositories to handle
their packages there is no defined way to handle/store these "extra" files.
Using the usual git-buildpackage workflow (or equivalent git workflows)
maintainers prepare new upstream releases relying on pristine-tar so that the
released tarball can be generated from the git information.
We need a similar mechanism to store the detached upstream
signatures, a simple approach could be to simply store the detached
signatures in the pristine-tar branch, and export these files when checking out
the orig.tar. This would mean to modify pristine-tar commit and checkout
actions to take into account the orig.tar.{$ext}.{asc,pgp} files.
Alternatively, we could use a different branch for these signatures, and avoid
meddling with pristine-tar, but this would add useless overhead.
Happy hacking,
--
"EIEIO Go home and have a glass of warm, dairy-fresh milk"
-- The GNU C Library Reference Manual, Chapter 2.2, Error Codes
Saludos /\/\ /\ >< `/
signature.asc
Description: PGP signature
Looking for new opendnssec and softhsm maintainer
Fellow colleagues, I am looking for a new maintainer for opendnssec and softhsm package. Honestly, I am not using neither, and it's quite hard to do a packaging when you don't use the packages in question, and I think the package suffer as a consequence, and I very much dislike that, so a new maintainer using the package and interested in improving the Debian packages would be great. Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, fast DNS(SEC) resolver Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro pečení chleba všeho druhu
Re: Running tests with xvfb
Jeff writes ("Running tests with xvfb"):
> I have a package whose tests crash X on my machine, which uses nouveau.
> This makes testing rather inconvenient.
>
> Running the tests in a chroot with xvfb works, but takes an age (i.e. a
> couple of minutes) to set up the chroot. This is also not conducive to
> rapid testing of small changes.
1. Why are you setting up the chroot each time ? You could keep it
set up.
> Running the test outside the chroot with xvfb still crashes X, because
> xvfb seems to grab the "real" X if it is there.
2. I think you mean "the test grabs the real X" not that xvfb grabs
it.
3. Probably the actual difference is that when you run the tests in a
chroot, something launders your environment so that DISPLAY is not
set. (Or maybe that your chroot tool is providing a separate AF_UNIX
display numbering space, so that a default of ":0" now goes to Xvfb.)
If I am right you can fix this problem by starting Xvfb in your main
session, and running the tests with the appropriate setting of
DISPLAY.
If this does not work then I think it is a bug in the tests, which
should honour DISPLAY.
Ian.
