Re: Architecture: all binNMUs (was: deduplicating jquery/)
On 06.12.20 01:08, Paul Wise wrote: > On Sat, Dec 5, 2020 at 12:21 PM Matthias Klose wrote: > >> Maybe there is more. But there's no progress, or intent to fix every tool to >> be >> aware of binNMUs. Maybe it's better to rethink how sourceful no-change >> no-maintainer uploads could be done without introducing the above issues? > > `dch --rebuild` already exists, so this would just need support in > wanna-build/sbuild for generating such uploads and support in dak for > accepting sourceful uploads from wanna-build/buildds rather than > maintainers. Given the whole source code trust story it'd be better if dak were to do it by itself rather than relying on an external service to do it. (Or we make it culturally allowed to do it using client-side tooling, as long as it is a no-change-but-debian/changelog upload.) Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Porter roll call for Debian Bullseye
On 12/1/20 5:02 AM, YunQiang Su wrote: > I am sorry for the later response. >Hi, > > I am an active porter for the following architectures and I intend > to continue this for the lifetime of the Bullseye release (est. end > of 2024): > > For mipsel and mips64el, I > - test most packages on this architecture > - run a Debian testing or unstable system on port that I use regularly > - fix toolchain issues great ;-) gcc-cross-mipsen and gcc-10-cross-mipsen have never been in testing ... > - triage arch-specific bugs > - fix arch-related bugs any help with #972269 ?
Re: Architecture: all binNMUs (was: deduplicating jquery/)
On 12/6/20 12:27 PM, Philipp Kern wrote: > On 06.12.20 01:08, Paul Wise wrote: >> On Sat, Dec 5, 2020 at 12:21 PM Matthias Klose wrote: >> >>> Maybe there is more. But there's no progress, or intent to fix every tool >>> to be >>> aware of binNMUs. Maybe it's better to rethink how sourceful no-change >>> no-maintainer uploads could be done without introducing the above issues? >> >> `dch --rebuild` already exists, so this would just need support in >> wanna-build/sbuild for generating such uploads and support in dak for >> accepting sourceful uploads from wanna-build/buildds rather than >> maintainers. > > Given the whole source code trust story it'd be better if dak were to do > it by itself rather than relying on an external service to do it. > > (Or we make it culturally allowed to do it using client-side tooling, as > long as it is a no-change-but-debian/changelog upload.) a useful "change" is an extra build dependency on the version you are running a transition for. Apparently working this way for binNMUs. Matthias
Re: RFC: DEP-14 update, second attempt
Hi, On Sun, 29 Nov 2020, Paride Legovini wrote: > I tried to do a synthesis of past August/September thread on the > finalization of DEP-14 [1], see: > > https://salsa.debian.org/dep-team/deps/-/merge_requests/1/diffs Looks good to me, thanks for your work! I merged your branch and I updated the status of the DEP in the table on the index page too. > I tried to stick to what I believe we had consensus on, however I think that > point (3) has a shortcoming: it allows / branches, but > doesn't cover cases where has no development _suite_. For example > it wouldn't allow the kali/kali-dev branch, as Kali doesn't have suites > (IIUC). This case could be covered by adding: > >However, when `` has no concept of suite for the >development release but has a fixed codename for it, the >use of the `/` scheme is accepted. > > I'd like to include this, but I left it out as it wasn't discussed before. > Let me know what you think. I don't think this needs to be spelled out. First when you don't have "suites", the difference between a suite and a codename doesn't matter much, you can say that the name of the distribution is both a suite and a codename (and in fact the Release file in kali shows this use of the same name in both fields). Also in the specific case of Kali, I will likely switch to kali/latest rather than kali/kali-dev. ;-) Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#976690: ITP: python-strictyaml -- type-safe YAML parser that parses and validates a restricted subset of the YAML specification.
Package: wnpp Severity: wishlist Owner: Romain Porte X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@microjoe.org, debian-pyt...@lists.debian.org * Package name: python-strictyaml Version : 1.1.1 Upstream Author : Colm O'Connor * URL : https://hitchdev.com/strictyaml * License : MIT Programming Lang: Python Description : type-safe YAML parser that parses and validates a restricted subset of the YAML specification. This package is introduced as a dependency for the python-gftools package, that I also intent to package. I intent to mainain this package under the umbrella of the Debian Python Team. signature.asc Description: PGP signature
Bug#976701: ITP: libnetconf2 -- NETCONF protocol library
Package: wnpp Severity: wishlist Owner: Ondřej Surý -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libnetconf2 Version : 1.1.16 Upstream Author : CESNET, z.s.p.o. * URL : https://github.com/CESNET/libnetconf2 * License : Apache-2.0. Programming Lang: C, C++ Description : NETCONF protocol library NETCONF library in C intended for building NETCONF clients and servers. NETCONF is the NETwork CONFiguration protocol introduced by IETF. . libnetconf2 is a NETCONF library in C handling NETCONF authentication and all NETCONF RPC communication both server and client-side. Note that NETCONF datastore implementation is not a part of this library. The library supports both NETCONF 1.0 (RFC 4741) as well as NETCONF 1.1 (RFC 6241). The main features include: . * NETCONF over SSH (RFC 4742, RFC 6242), using libssh. * NETCONF over TLS (RFC 7589), using OpenSSL. * DNSSEC SSH Key Fingerprints (RFC 4255) * NETCONF over pre-established transport sessions (using this mechanism the communication can be tunneled through sshd(8), for instance). * NETCONF Call Home (RFC 8071). * NETCONF Event Notifications (RFC 5277), -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl/N2eRfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcK5sw/8CqwvPrMo3m7Bg7foEUEazfK7hucklmf8l4L0biC3sITTwIj2YdniVJnw eUNCU+TUO+AEae9qOhj0LWqzH6CW62u8YWfJ0TvbTV3uhmwwhRCK+MuE4VoI4bxH YDReimFSTgJ1rPD+Kt2ueF9TDpiO6V88om5r5oAhaVHUcclNZmtXJ6sWOxytlWI4 FGAhsLqhi0Mfvk9oLQ9ijbcQtynuLyHBmgx5QpWgMfB0Bst+/MdpI1dSaoDqWrmE 08kBN/2KHq48Fw/NZGZyPS7y+9n3rwHSGesz/jpQTJEUYwC1gt+ZfnMUw+0DrK8X PiLlS+I9XDQT+r3au6bZhi1nUIvWs7vhRmiUzMsGoII62BwKeuSIq0gjw6FqOSOy Zbe9XGgBgq63XdMSIFF3nt12N+YpmdZGAECeIpwXofCohQSoeC1NZpoX5voHECXT 94PmmDzaT9kmZ6fvfqo4WnrPWgLxowLFAkeZCUjfnfruJebxyiX0TZ+bbWcxeiVB w0ez1qP8w9TF+jgsuORXRksrZacrhbgseOG00Vc3jUZSnT45rKOAUMsuRO11Ymt7 4EiDClqRCxyXuQqSxBgxikF2QwkTXyiCb7e/vI0q4yMO4OAKSMGjYe2SgQFNy1cY f9cnrGHMH4joYS2lqEjNYrujckJ3/Qr46pWP8WRPnFjKMgdROeU= =xph4 -END PGP SIGNATURE-
dpkg-source reproducibility
Hello, over all the years I had assumed the -x and -b operations of dpkg-source are inverse, and the other way around as well. In other words, I expected to rely on the following: Running "dpkg-source -x" on a .dsc, and then "dpkg-source -b" on the unpacked tree re-creates the initial .dsc file. Having a bitwise identical result was certainly nice to have, but I consider it sufficient if the resulting .dsc, unpacked as well, results in a file tree with identical file list and content¹. Now I came across a (native) package that fails that rule - after running "dpkg-source -b", the top-level .gitignore file was missing. While I could work around this, it felt wrong. Therefore I'd like to understand whether the above approach is not the right one, the source package has been created in an interesting way (alternative implementations of "dpkg-source -b"?), whether this is acceptable, and how to sanely deal with it. And I wouldn't care if that hadn't been an impediment when preparing a NMU for that package since debdiff showed the top-level .gitignore was removed. Something that certainly should not happen in a NMU. Christoph ¹ File permissions is another story. signature.asc Description: PGP signature
