Bug#994279: ITP: pyreflink -- Python Library wrapping platform-specific reflink implementations
Package: wnpp Severity: wishlist Owner: Stefano Rivera X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pyreflink Version : 0.2.1 Upstream Author : Ruben De Smet * URL : https://gitlab.com/rubdos/pyreflink * License : Expat Programming Lang: Python (CFFI C extensions) Description : Python Library wrapping platform-specific reflink implementations Python wrapper around the ``reflink`` system calls. . Features: . * Btrfs, XFS, OCFS2 ``reflink`` support. Btrfs is tested the most. * Apple macOS APFS ``clonefile`` support. Little testing, be careful. It might eat data. * A convenience method that checks support for reflinks within a specific directory. I intend to maintain this under the Debian Python Team, as a dependency of the beets testsuite.
Re: Require packages to build without any configured DNS
On September 14, 2021 5:16:51 PM UTC, Johannes Schauer Marin Rodrigues wrote: >Quoting Mattia Rizzolo (2021-09-14 15:34:36) >> On Tue, Sep 14, 2021 at 10:05:01AM +0200, Johannes Schauer Marin Rodrigues >> wrote: >> > Hi, >> > >> > Quoting Mattia Rizzolo (2021-09-06 16:39:39) >> > > As the pbuilder maintainer, I've been asked to make it serve a >> > > non-working >> > > /etc/resolv.conf just to make that bug above moot, so I'm quite biased >> > > on the >> > > matter myself :) >> > >> > sbuild already disables network access for all chroot backends that >> > support it. >> >> As several people already stated, this is *not* about network access. > >Yes, I mention it for context. > >> > Schroot, the default chroot backend, currently doesn't allow this. See >> > #802849. >> >> Likewise pbuilder, yes. >> >> > The only chroot backend that allows disabling the network is the unshare >> > backend. It does so, by unsharing the network namespace, only bringing up >> > the >> > loopback interface and writing an empty /etc/resolv.conf. >> >> So you ship an *empty* /etc/resolv.conf? Then I suppose you also can't build >> packages using dnspython in their tests with your configuration? > >Correct. This currently fails: > >sbuild -d unstable --chroot-mode=unshare python-oslo.rootwrap > >The error message is the same as for the package mentioned in #989171, namely: > >https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/python-oslo.rootwrap.html > >This is why I'm writing about sbuild. I wonder if it's a bug for sbuild to >write out an empty /etc/resolv.conf. At least based on the error text, I think it would be the same whether it was empty or missing: "Resolver configuration could not be read or specified no nameserver" As far as I can tell, dnspython is behaving reasonably. I don't think we should make it so it is an error for a package to complain it can't function. Scott K
Re: Require packages to build without any configured DNS
Quoting Mattia Rizzolo (2021-09-14 15:34:36) > On Tue, Sep 14, 2021 at 10:05:01AM +0200, Johannes Schauer Marin Rodrigues > wrote: > > Hi, > > > > Quoting Mattia Rizzolo (2021-09-06 16:39:39) > > > As the pbuilder maintainer, I've been asked to make it serve a non-working > > > /etc/resolv.conf just to make that bug above moot, so I'm quite biased on > > > the > > > matter myself :) > > > > sbuild already disables network access for all chroot backends that support > > it. > > As several people already stated, this is *not* about network access. Yes, I mention it for context. > > Schroot, the default chroot backend, currently doesn't allow this. See > > #802849. > > Likewise pbuilder, yes. > > > The only chroot backend that allows disabling the network is the unshare > > backend. It does so, by unsharing the network namespace, only bringing up > > the > > loopback interface and writing an empty /etc/resolv.conf. > > So you ship an *empty* /etc/resolv.conf? Then I suppose you also can't build > packages using dnspython in their tests with your configuration? Correct. This currently fails: sbuild -d unstable --chroot-mode=unshare python-oslo.rootwrap The error message is the same as for the package mentioned in #989171, namely: https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/python-oslo.rootwrap.html This is why I'm writing about sbuild. I wonder if it's a bug for sbuild to write out an empty /etc/resolv.conf. Thanks! cheers, josch signature.asc Description: signature
Re: dh_install -X not excluding any files
On 2021-09-14 John Paul Adrian Glaubitz wrote: > I'm currently working on packaging KIWI [1] for Debian where I need to > exclude on of the binaries from being installed into /usr/bin. > I tried using "dh_install -Xkiwicompat" [2] but that doesn't work no > matter what variation I'm trying, the binary kiwicompat still gets > installed into /usr/bin. > Does anyone have a clue why excluding "kiwicompat" doesn't work? Hello, It is not installed by dh_install: | dh_auto_install | [...] | running install_scripts | Installing kiwi-ng script to /dev/shm/KIW/kiwi-debian/debian/kiwi/usr/bin | Installing kiwicompat script to /dev/shm/KIW/kiwi-debian/debian/kiwi/usr/bin | make[1]: Leaving directory '/dev/shm/KIW/kiwi-debian' |debian/rules override_dh_install | make[1]: Entering directory '/dev/shm/KIW/kiwi-debian' | dh_install -Xkiwicompat Since there is only a single binary package dh_auto_install installs directly to debian/kiwi/ (sid)ametzler@argenau:/dev/shm/KIW/kiwi-debian$ dh_auto_install --no-act --verbo se make -j1 install DESTDIR=/dev/shm/KIW/kiwi-debian/debian/kiwi AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true" Since you are already overriding dh_auto_install you could simply rm the offending file there. cu Andreas
Re: dh_install -X not excluding any files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, On Tue, 2021-09-14 at 16:36 +0200, John Paul Adrian Glaubitz wrote: > I'm currently working on packaging KIWI [1] for Debian where I need > to exclude > on of the binaries from being installed into /usr/bin. > > I tried using "dh_install -Xkiwicompat" [2] but that doesn't work no > matter what > variation I'm trying, the binary kiwicompat still gets installed into > /usr/bin. You mean installed in debian/tmp during build or in the final package? I think that adding a debian/not-installed with usr/bin/kiwicompat would do the trick? With best regards, b. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEumC8IPN+WURNbSUAE2VyCRPS8i0FAmFA0e8ACgkQE2VyCRPS 8i1PHA//fewiAb5SF9icTKYGmpp3FSq9YgZPOnIHwswVGI6V4pulpAf9FjrI80lB 2xxmOzAPXSY4SxY1EOY8f6gcrfDeohOxPuEGf1CNQ0klvB0fEk1tYa3tbxlixE1v 81zW6TT0pBcqHSZPbn62YznOxURJh76HM5B5EzfgSOtJiakg29QutWmjWNQDVBxc y3lT/k3N0MkY0niqCoyq9JcrMXvWV7Q9+gxbVNSxUNeXPu2hL3NzCLiqE2mUuRHD pNuwC6APrRq6bJGL8Ri6bgV4qby8UJc4NzGRD/kGcS8plk4pjp2Z4a4AdN1g9IVr vx7msD5rTgzD8rW/cxKEGJy5DZ43GKxzsfW0rfxmfwgcoK+6Ls3nRWxxb29/0b0k 7KGGHXG6uWWD9A9SddV5jjedT7cnJOvgfQ8+n7joTDiAFh9GIP4j6QhMqNN35Qv2 YY4luxLCJnBCTqrrWI+cCoIg2Yla98Y9Tk6H7TtCRzWWBS9LQ0cpOFMGU0yOwY2o qrMI3gF4/VliTJJ2iq4TQDVEn6h0MNNzCKnWSiBvRE0IxEk4r2NeavpnrTD1tv2m 0GASIwpTAVR6wKIGg2mJezYHwz7hjoKz1mJUddqTMSgixzpKhN2U7pQTbobro2en Ir3O0yHF2v3GM4l5+nxg7MTEOB9hnAYaFXzOoX0r0N3s3/Qlp3A= =Lb6k -END PGP SIGNATURE-
dh_install -X not excluding any files
(Please CC in replies me as I'm not subscribed to debian-devel) Hello! I'm currently working on packaging KIWI [1] for Debian where I need to exclude on of the binaries from being installed into /usr/bin. I tried using "dh_install -Xkiwicompat" [2] but that doesn't work no matter what variation I'm trying, the binary kiwicompat still gets installed into /usr/bin. Does anyone have a clue why excluding "kiwicompat" doesn't work? Thanks, Adrian > [1] https://github.com/OSInside/kiwi > [2] https://github.com/glaubitz/kiwi-debian/blob/master/debian/rules#L25 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#994244: ITP: ilorest -- cli for managing servers over the Redfish API
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ilorest Version : 3.2.2 Upstream Author : Rajeev Kallur * URL : https://github.com/HewlettPackard/python-redfish-utility * License : BSD-3-clause Programming Lang: Python Description : cli for managing servers over the Redfish API The Redfish Utility is a command line interface that allows one to manage servers that take advantage of Redfish APIs. In addition to using the utility manually to execute individual commands, you can create scripts to automate tasks.
Bug#994243: ITP: simple-image-filter -- An image processing software
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: simple-image-filter Version : 1.0.9 Upstream Author : dependon * URL : https://github.com/dependon/simple-image-filter * License : GPL-3 Programming Lang: C++ Description : An image processing software, can handle image rotation, clip, basic beautification, filter and other graph functions
Re: Require packages to build without any configured DNS
On Tue, Sep 14, 2021 at 10:05:01AM +0200, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Mattia Rizzolo (2021-09-06 16:39:39) > > As the pbuilder maintainer, I've been asked to make it serve a non-working > > /etc/resolv.conf just to make that bug above moot, so I'm quite biased on > > the > > matter myself :) > > sbuild already disables network access for all chroot backends that support > it. As several people already stated, this is *not* about network access. > Schroot, the default chroot backend, currently doesn't allow this. See > #802849. Likewise pbuilder, yes. > The only chroot backend that allows disabling the network is the unshare > backend. It does so, by unsharing the network namespace, only bringing up the > loopback interface and writing an empty /etc/resolv.conf. So you ship an *empty* /etc/resolv.conf? Then I suppose you also can't build packages using dnspython in their tests with your configuration? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Require packages to build without any configured DNS
On Mon, Sep 13, 2021 at 04:05:57PM -0700, Don Armstrong wrote: > On Fri, 10 Sep 2021, Adrian Bunk wrote: > > On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote: > > >... > > > I think dnspython's previous approach was correct: just like glibc, musl, > > > and > > > other libraries, if /etc/resolv.conf is missing they should treat that as > > > though it specified a nameserver on localhost. > > > > How libraries implement a standard high-level C interface is not > > necessarily relevant for how a DNS library implements a low-level > > interface. > > It seems to me that upstream should just not raise > NoResolverConfiguration, and instead not configure any nameservers. > > Then, if someone tries to resolve without any configured nameservers, > NoNameservers will be raised, which is the same thing that happens if > there are no good nameservers, and is less inconsistent with the > previous behavior. I would consider it worse if init of a module returns success in a situation where it is known that the whole module is nonfunctional, and then returns an error every time a thread tries to use the module. There are obviously several options what could be done, but it's difficult to call the current behaviour a bug in a DNS module. The large picture is that there is no piece of software involved in all this that is clearly buggy itself, the problem is that all pieces together are at the border of forbidden "uses network" in Debian builds. My personal stake in all this is that I've raised the topic twice with Mattia since it makes it a lot harder to use reproducible for finding FTBFS, and I was initially making the case for having the IP address of a non-existing nameserver in /etc/resolv.conf in the reproducible environment. My impression of this discussion is that unless someone discusses and convinces an upstream to change their (not obviously buggy) software, the affected packages must not run these tests during the build and if there are autopkgtest they must have a "needs-internet" restriction. cu Adrian
Bug#994231: ITP: kiwi -- Flexible OS Image and Appliance Builder
Package: wnpp Severity: wishlist Owner: John Paul Adrian Glaubitz X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: kiwi Version : 9.23.56 Upstream Author : Marcus Schäfer , and others * URL : https://osinside.github.io/kiwi * License : GPL-3 Programming Lang: Python Description : Flexible OS Image and Appliance Builder The KIWI Image System provides an operating system image builder for Linux supported hardware platforms as well as for virtualization and cloud systems. This package will be co-maintained by Marcus Schäfer. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Require packages to build without any configured DNS
Hi, Quoting Mattia Rizzolo (2021-09-06 16:39:39) > As the pbuilder maintainer, I've been asked to make it serve a non-working > /etc/resolv.conf just to make that bug above moot, so I'm quite biased on the > matter myself :) sbuild already disables network access for all chroot backends that support it. Schroot, the default chroot backend, currently doesn't allow this. See #802849. The only chroot backend that allows disabling the network is the unshare backend. It does so, by unsharing the network namespace, only bringing up the loopback interface and writing an empty /etc/resolv.conf. Thanks! cheers, josch signature.asc Description: signature
