Re: systemd-analyze security as a release goal
Matthew Garrett writes: > On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote: > >> qemu is basically an interpreter for foreign machine code. If your >> threat model allows access to qemu-user-static for an attacker, they >> can run pretty much any binary is if it were native, and the whole >> SystemCallArchitectures hardening becomes meaningless. > > My understanding of the threat is that compatibility syscalls (eg, x32 > on amd64) are less well-tested than the local architecture syscalls, and > so allowing apps to call them increases the risk - a compromised app > that can make compatibility syscalls stands a higher probability of > being able to elevate privileges, either in userland or to the kernel > itself. Allowing qemu to translate syscalls from other architectures to > the local syscall ABI doesn't increase that risk, so isn't a concern. > The goal isn't to prevent code form other architectures from running, > it's to reduce the attack surface by preventing calls to the > compatbility syscalls. Thanks, your user story is much better than mine: SystemCallArchitectures=native slightly inconveniences attackers by forcing them to make multiple payloads, instead of "meh, I'll just build for IA32; that works on regular AND embedded/old systems".
The future of mipsel port
Hi, folks, Welcome to era of Trixie, and let's talk about the future of mipsel. mipsel port has some problems as somebody may know: 1. 2G user RAM space make some packages FTBFS, especially with LTO enabled. 2. Y2038 problem, which requires almost rebootstrap. 3. The current hardwares, include MIPS P5600, Ingenic X2000, Loongson 3A4000, are NAN2008 hardwares, and some new software supposed that NAN2008 is always true. [1] https://sourceware.org/binutils/docs-2.25/as/MIPS-NaN-Encodings.html 4. the maintenance status of big projects, like Firefox, Libreoffice etc are not so good. So I consider to suggest drop mipsel support from the list of official ports. (And let's keep mips64el port). As CIP United, we do maintain an unofficial port of mipsel. So I wish that Debian can still accept our patch to support mipsel port (source only). https://repo.oss.cipunited.com/debian/ Debian mips32r2el port with: * -mnan=2008 * -mfp64 * -mmsa (not yet, will have another port) * -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 * -D_TIME_BITS=64 Known supported hardwares: MIPS P5600 Ingenic X2000 Loongson 3A4000
Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
On Mon, 2023-07-17 at 07:16 +0200, Helmut Grohne wrote: > Then I found trei...@debian.org using edos-file-overwrite. That latter > one seems like what I need here. Should we move it to the qa space and > drop the edos part? I suggest debian...@lists.debian.org usertags > file-overwrite. Otherwise, Ralf are you ok with me reusing your tag? I have scripts to automate usertags changes and watch weekly diffs. The QA copy runs from cron fixing some typos and my fork is modified and run when I notice any weird changes. The script can be used to easily perform moving and or renaming of usertags as needed here. https://salsa.debian.org/qa/qa/blob/master/data/cronjobs/usertags-fixes https://salsa.debian.org/pabs/qa/blob/master/data/cronjobs/usertags-fixes editor data/cronjobs/usertags-fixes mkdir tmp rsync --timeout=60 --recursive --delete rsync://bugs-mirror.debian.org/bts-spool-index/user/ tmp/all/ ./data/cronjobs/usertags-fixes --debug tmp -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
Hello, On Mon, Jul 17, 2023 at 10:35:24AM +0200, Andreas Beckmann wrote: > On 17/07/2023 07.16, Helmut Grohne wrote: > > Then I found trei...@debian.org using edos-file-overwrite. That latter > > one seems like what I need here. Should we move it to the qa space and > > drop the edos part? I suggest debian...@lists.debian.org usertags > > file-overwrite. Otherwise, Ralf are you ok with me reusing your tag? > > Moving the usertag to the qa namespace sounds like a good idea. I agree > And dropping the ancient edos prefix ... Yes. At the origin, the edos prefix was useful for us as the tool used to detect these bugs came from the edos project, but that project is over since a long time. And the tag has been used since then by others for tagging these kind of bugs discovered independently. So yes, time to simplify. > edos-file-overwrite has been used primarily for file-vs-file conflicts (as > these are the only ones detectable by analyzing .contents files) That was it's original target, and more specifically between packages in the same distro, but as Andreas explained that was extended by others to upgrading bugs: > We also didn't distinguish between file overwrites happening within a distro > (two packages in sid shipping the same file) and on upgrades (the file in > question moved between packages with insufficient Breaks+Replaces). Maybe we > should. Sounds like a good idea. However, I do not think that usertags support a hierarchy of tags. So maybe different specific usertags with a common prefix, like fileconflict-installation (error occurs when one tries to install two packages togther) fileconflict-upgrade (error occurs when upgrading, due to missing breaks/replaces) fileconflict-directory (error occuring due to /usr merge) Or something in this direction. -Ralf.
Re: Proposed MBF: Removal of libfreetype6-dev
Hi Sven,
On Mon, 17 Jul 2023 at 01:13, Sven Joachim wrote:
>
> On 2023-07-16 22:38 +1000, Hugh McMaster wrote:
>
> > I will be removing the transitional package libfreetype6-dev (from the
> > source package freetype) later this year.
> >
> > [snip]
>
> My suggestion is to drop the libfreetype6-dev package immediately and
> not waste your and other people's time with mass-bug filing, because
> libfreetype-dev already has a versioned Provides on libfreetype6-dev.
> This is what I did with three transitional -dev packages in ncurses, and
> although I had initially been skeptical it worked like a charm. See the
> discussion in #1032708.
This is helpful and offer an immediate way forward.
I'll be uploading FreeType 2.13.1 in a few weeks, so I'll drop
libfreetype6-dev at that time.
I'm curious: do you plan to drop Provides: libncurses5-dev (=
${binary:Version}), ... from your control file at some point?
Hugh
Bug#1041318: ITP: rust-json-event-parser -- JSON event parser and serializer
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-json-event-parser Version : 0.1.1 Upstream Contact: Tpt * URL : https://github.com/oxigraph/json-event-parser * License : Apache-2.0 or Expat Programming Lang: Rust Description : JSON event parser and serializer JSON event parser is a simple streaming JSON parser and serializer implementation in Rust. . It does not aim to be the fastest or the more versatile JSON parser possible but to be an as simple as possible implementation. This package is needed for oxigraph (bug#996504). It will be maintained in the collaborative debian section of salsa, at https://salsa.debian.org/debian/rust-json-event-parser - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS1LsgACgkQLHwxRsGg ASGuZxAAnGaRse4xNrc1A8yia/ZGZPbilR93QiVzblYfKtAvPp7sMUkpvjPhkdP6 EEXdvcHUP72p/yQj6wmRzptLtDxNd6/K4V0DQpZj1wA11i3BJHiiX4udVqqBQlvQ FpCgMw28c4VzYW84JGAYEb7Dqsd85U8rZLdpSmaZ+eAIzeRAjfoldLKn7wfoxZKk iB/veI19T/oAHyRYnG1ptukLBexUvjxQxZczhr1/6e5Njk0glY1/oNLQ7ewv7NGS 1Pcislx9jEsxPmtxGEzBifoV/H+2lYvir3HqNEx6pWF4BqiUEFDTfaRPUiQ/PsTQ azbJNcZzSiRLKFw6dZzXqnAZgQCgicO4a8GEoBNDaRWlbe7PL9BidfshcOnKXX/i 4x943xCCOhXSGCTrbIW2nwM8etz9QRXn7zmqHjCAH2arFPjRCv3E4dABhO1J/lP/ sNnMwKNtljuAG++ucBkXaN0JYV4JSQGRoCocegDbjYQBOsDG7ARgEJyJBdPbBoIH PF6HVgWCCvhJ9V8sEFy2/aY26ycfUzwKst7Qz80V35A3wyZMTrHQHs0A+dAVRhU1 foxNCFRhUdO/4HDB7opVfyZ7hOuagRiv0ccxa/jKzMtduh6JMYQf291NyN08valq yMTE83L5588OnZv/Z+AcRZQbtPOQZqyrqEEBtFTyo9qCUjtbUrk= =oDlV -END PGP SIGNATURE-
Re: Proposed MBF: Removal of libfreetype6-dev
Hi Simon, On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote: > > On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote: > > Currently, there are 219 build-dependencies and 29 (direct) > > dependencies on libfreetype6-dev, which has been released with > > bullseye and bookworm. > > Lintian diagnoses this as "[build-]depends-on-obsolete-package" since > 2.116.0 (MR at [1], instances of the relevant tags listed at [2] and > [3]) which will hopefully help progress towards dropping the transitional > package. Thanks for pointing this out. I wasn't aware Lintian had started flagging dependencies on obsolete packages some 10 months ago. Having Lintian issue a warning or error instead of bug filing is preferable. > [1] https://salsa.debian.org/lintian/lintian/-/merge_requests/417 > (partially reverted in > https://salsa.debian.org/lintian/lintian/-/merge_requests/452 but the > freetype part remains) > [2] > https://udd.debian.org/lintian-tag.cgi?tag=build-depends-on-obsolete-package > [3] https://udd.debian.org/lintian-tag.cgi?tag=depends-on-obsolete-package > > Unfortunately lintian.debian.org is not currently updating, so please > don't use that as a source.
Bug#1041316: ITP: rust-fast-rgb8 -- conversions between linear float and 8-bit sRGB
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-fast-rgb8 Version : 1.0.0 Upstream Contact: Thom Chiovoloni * URL : https://github.com/thomcc/fast-srgb8 * License : Apache-2.0 or CC0-1.0 or Expat Programming Lang: Rust Description : conversions between linear float and 8-bit sRGB fast-srgb8 is a small crate implementing fast conversion between linear float and 8-bit sRGB. This package is needed by rust-palette (bug#1040661). It will be maintained in the collaborative debian section of salsa, at https://salsa.debian.org/debian/rust-fast-rgb8 - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS1IicACgkQLHwxRsGg ASF8wA//XqNCLrPd3g8ONx4zDru4XJR1auMUhMXMQCuNTBjigGjy31saOnWLfBZi 7SzMTHKDQZ04XBBGGqVFll2ei873oYWzz1I0A3cMdMUb8RnGrwaOuync4CbNUF/y /GkVajpfF3tHvDYJ5BgEIoNAmqTBm3nVQs8/m0OPP94w0EnqaVs7pNLhBL0caD1t s26cSbDnb6GGwrUOdVzUqsI2Yr+TGsK6MBJ3ZUCFcvrndFyaMk46rf+3DRYGXTqq SoLl3Z5EDnMN8Dkzf9WvHZrOBmHP36MJO/htA4+RL+Vdak8BIdo7/qYZsvGFubyc sEYL1pdL1IZcmBLq5rfxXaBjsL7Tm+wyZjOr1EqHh8yE6CMZFP0B95VeqTY6Z27M 5Cgzm9Npz9PE9pZO4nmTMh0E3jDb2nC5wJvZdq7MDFa+b/XS33pHotQyG82H8bqR IlFycw1UDVajxALZ1KLS4kJvX082BeHVBLLlIxGjztPdM7bVzVDtQzEqK3p9F4gb RjZu2u62nrr0PUNOUM1qS73ZIoeD6XvTUx7D3o+XtKHemBgA8dg1l+28FL9pkECy 9EwR3BFT5E0P9+ThdYUZllPHoAFTohpFe7OHqYKvqkQBYohUVy5+1LAZiTi3KnYE 3fVx9AgTWu4L0ETFeyUFH22ViWifgGkR+ULUrbMmOFeUvN5m+XM= =uQ4K -END PGP SIGNATURE-
Bug#1041315: ITP: ipp-crypto -- Intel(R) Integrated Performance Primitives Cryptography
Package: wnpp Severity: wishlist Owner: Colin Ian King X-Debbugs-Cc: debian-devel@lists.debian.org, colin.i.k...@gmail.com * Package name: ipp-crypto Version : 2021.8 Upstream Contact: Andrey Matyukov * URL : https://github.com/intel/ipp-crypto * License : Apache-2.0 Programming Lang: C Description : Intel(R) Integrated Performance Primitives Cryptography Intel(R) Integrated Performance Primitives (Intel(R) IPP) Cryptography is a secure, fast and lightweight library of building blocks for cryptography, highly-optimized for various Intel® CPUs. The library provides a comprehensive set of routines commonly used for cryptographic operations, including: Symmetric Cryptography Primitive Functions: AES (ECB, CBC, CTR, OFB, CFB, XTS, GCM, CCM, SIV) SM4 (ECB, CBC, CTR, OFB, CFB, CCM) TDES (ECB, CBC, CTR, OFB, CFB) RC4 One-Way Hash Primitives: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 MD5 SM3 Data Authentication Primitive Functions: HMAC AES-CMAC Public Key Cryptography Functions: RSA, RSA-OAEP, RSA-PKCS_v15, RSA-PSS DLP, DLP-DSA, DLP-DH ECC (NIST curves), ECDSA, ECDH, EC-SM2 Multi-buffer RSA, ECDSA, SM3, x25519 Finite Field Arithmetic Functions Big Number Integer Arithmetic Functions PRNG/TRNG and Prime Numbers Generation It can be useful for: Security (constant-time execution for secret processing functions) Designed for the small footprint size Optimized for different Intel CPUs and instruction set architectures (including hardware cryptography instructions support): Intel Streaming SIMD Extensions 2 (Intel SSE2) Intel SSE3 Intel SSE4.2 Intel Advanced Vector Extensions (Intel AVX) Intel Advanced Vector Extensions 2 (Intel AVX2) Intel Advanced Vector Extensions 512 (Intel AVX-512) Configurable CPU dispatching for the best performance Kernel mode compatibility Thread-safe design I intend to maintain this by tracking the upstream project and keeping the package up to date with releases. I also intend to pull in bug fixes from the upstream project into the packaging and also feedback any Debian bug reports back to the upstream project. I also will run static analysis on the code using tools such a CoverityScan to find and report or fix coding issues. Since I'm a DM, I require a sponsor for this package. Colin Ian King
Re: pre-MBF: fail to build (repack) source
On Mon, Jul 17, 2023 at 11:10:52AM +0100, Simon McVittie wrote: > > I wonder what's the point of B-D-Arch And B-D-Indep then? > > The point is the same as it always was: primarily to exclude large > dependencies from a `dpkg-buildpackage -B` build chroot (like the official > buildd for each architecture) if they are only needed when building > Architecture: all packages such as documentation, and secondarily to > exclude large dependencies from a `dpkg-buildpackage -A` build chroot > (like the official "all" buildd) if they are only needed when building > Architecture: any packages. > > B-D-I are required/guaranteed to be installed for builds that will run > `debian/rules build-indep`, and B-D-A for builds that will run > `debian/rules build-arch`. What Adam has been exercising for this MBF > are builds that will do neither, but only build the source package > (`dpkg-buildpackage -S`). This is a somewhat common thing to want to do > if you do all your builds in a chroot, container, VM or remote machine: > you start from an unpacked source directory or git clone, and you want > to build binary packages "over there", which in many cases requires > giving sbuild etc. a .dsc to work with, but you do not necessarily have > all of the "heavier" dependencies on the local development system where > you will convert the source directory into a .dsc. > > You can move tools, libraries etc. from B-D to B-D-A or B-D-I as > appropriate, *if* they are not needed by `debian/rules clean`. In > practice this is usually the case for most "large" build-dependencies. ah, makes sense, thank you! > For instance, if you have documentation built with Doxygen, LaTeX > or other large frameworks, it's usually OK for those tools to be in > Build-Depends-Indep only; or if you have a GTK GUI and you've taken > steps to avoid building it in Architecture: all builds, it's probably > OK for GTK to be in Build-Depends-Arch only. *nods* > One common failure mode is that if your source package only builds > Architecture: all packages, it's tempting to move debhelper from > Build-Depends to Build-Depends-Indep, but that's incorrect for the > reasons that Adam raised here (because debhelper is needed during clean). for src:developers-reference, debhelper is the only package listed in B-D atm :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ First, they came for the transgender, and I spoke out immediatly even though I'm straight and cis because I've read the rest of the fucking poem. signature.asc Description: PGP signature
Bug#1041314: ITP: rust-safe-arch -- safe exposure of core::arch
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-safe-arch Version : 0.6.0 Upstream Contact: Daniel "Lokathor" Gee * URL : https://github.com/lokathor/safe_arch * License : Apache-2.0 or Expat or Zlib Programming Lang: Rust Description : safe exposure of core::arch safe-arch exposes arch-specific intrinsics as safe function. This package will be maintained in the collaborative debian section of Salsa, at https://salsa.debian.org/debian/rust-safe-arch - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS1Fz8ACgkQLHwxRsGg ASFGQhAAoFDnieRSR2yQgqE0lI/b8RIRSJkG2OFyFAmjcOIcjauBY9JA3u/id7fx OhfxjgTeGc99ca2SeRqCmv68bk59+2YePnbryGFdCNyB7daKqHvR3V7hT8b6ru6H Dv5S5mHG/ak86mEzIQa4alMPB0tZhVKFda/4tOHAR8ihmi1mnP5/j3iKSbjWNUPp /VPYjlkdirlVh7nSWGGGMhZER3AgTnOPsXFcRZODexrZdcnAUiqJA7KNFODrDAw9 LooxSTKJ4DZYso/NpYmzQZ2mbYbzbDShvwJv9eCnHUn9mPFIWxxD0heRVd7XFswS QN6MI/6G6IfkWrBOC9ZIurLEFf1B0GlEP0XnWDpRJjKtIVCnciKD0gS18g7M+Fei QNNhDCBJwZGoQov6i9EYaxc9ewzLQ6LX/zsHv77K/RtuINnNGfN9yXI+2kj6pHQC Y57NtKb7DWCv6zHYR7QT/UYQqca+WhbK8ia1BTKoyi7DoqZAozoO0BsOZ0GXGOQW 4csCiYQWr8u22OG4qI+W73NqXe7eek8TAmN/8W2gpeOnecbO6sMWIzd4Ya2QLecT cUskiTsNO/oeOdYa/sqeBDdvhejOsYofvX9BJwG48kjCAncQYQoyHgauyf3B/891 k1Vo7jAqo9MI3uVBgmsDhyp6Pn2M54DxZnBRJvvOWCXXnlIDoV4= =KED9 -END PGP SIGNATURE-
Re: pre-MBF: fail to build (repack) source
Quoting Simon McVittie (2023-07-17 12:10:52) > On Mon, 17 Jul 2023 at 08:57:51 +, Holger Levsen wrote: > > On Sun, Jul 16, 2023 at 11:41:36AM +0100, Simon McVittie wrote: > > > On Sun, 16 Jul 2023 at 00:03:00 +0200, Adam Borowski wrote: > > > > due to Build-Depends > > > > being inadequate (per the Policy, B-D-Indep are _not_ necessarily > > > > installed) > > > > > > For completeness, B-D-Arch are not guaranteed to be installed during > > > clean either. > > > > I wonder what's the point of B-D-Arch And B-D-Indep then? > > The point is the same as it always was: primarily to exclude large > dependencies from a `dpkg-buildpackage -B` build chroot (like the official > buildd for each architecture) if they are only needed when building > Architecture: all packages such as documentation, and secondarily to > exclude large dependencies from a `dpkg-buildpackage -A` build chroot > (like the official "all" buildd) if they are only needed when building > Architecture: any packages. additionally, moving build dependencies from Build-Depends to Build-Depends-Indep is also one of the least disruptive ways to make a Debian source package cross-compilable in cases where build dependencies that do not work in a cross-context are only used to build the arch:all packages. https://wiki.debian.org/CrossBuildPackagingGuidelines#Declare_.22Indep.22_Build-Dependencies Moving stuff to Build-Depends-Indep also helps the architecture bootstrap use-case as arch:all packages do not have to be bootstrapped for a new architecture and the fewer build dependencies remain in Build-Depends or Build-Depends-Arch the fewer build dependency cycles remain. Thanks! cheers, josch signature.asc Description: signature
Re: pre-MBF: fail to build (repack) source
On Mon, 17 Jul 2023 at 08:57:51 +, Holger Levsen wrote: > On Sun, Jul 16, 2023 at 11:41:36AM +0100, Simon McVittie wrote: > > On Sun, 16 Jul 2023 at 00:03:00 +0200, Adam Borowski wrote: > > > due to Build-Depends > > > being inadequate (per the Policy, B-D-Indep are _not_ necessarily > > > installed) > > > > For completeness, B-D-Arch are not guaranteed to be installed during > > clean either. > > I wonder what's the point of B-D-Arch And B-D-Indep then? The point is the same as it always was: primarily to exclude large dependencies from a `dpkg-buildpackage -B` build chroot (like the official buildd for each architecture) if they are only needed when building Architecture: all packages such as documentation, and secondarily to exclude large dependencies from a `dpkg-buildpackage -A` build chroot (like the official "all" buildd) if they are only needed when building Architecture: any packages. B-D-I are required/guaranteed to be installed for builds that will run `debian/rules build-indep`, and B-D-A for builds that will run `debian/rules build-arch`. What Adam has been exercising for this MBF are builds that will do neither, but only build the source package (`dpkg-buildpackage -S`). This is a somewhat common thing to want to do if you do all your builds in a chroot, container, VM or remote machine: you start from an unpacked source directory or git clone, and you want to build binary packages "over there", which in many cases requires giving sbuild etc. a .dsc to work with, but you do not necessarily have all of the "heavier" dependencies on the local development system where you will convert the source directory into a .dsc. You can move tools, libraries etc. from B-D to B-D-A or B-D-I as appropriate, *if* they are not needed by `debian/rules clean`. In practice this is usually the case for most "large" build-dependencies. For instance, if you have documentation built with Doxygen, LaTeX or other large frameworks, it's usually OK for those tools to be in Build-Depends-Indep only; or if you have a GTK GUI and you've taken steps to avoid building it in Architecture: all builds, it's probably OK for GTK to be in Build-Depends-Arch only. One common failure mode is that if your source package only builds Architecture: all packages, it's tempting to move debhelper from Build-Depends to Build-Depends-Indep, but that's incorrect for the reasons that Adam raised here (because debhelper is needed during clean). smcv
Bug#1041309: ITP: rust-wide -- wide data types
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-wide Version : 0.7.11 Upstream Contact: Daniel "Lokathor" Gee * URL : https://github.com/lokathor/wide * License : Apache-2.0 or Expat or Zlib Programming Lang: Rust Description : wide data types wide provides portable "wide" data types that do their best to be SIMD when possible. This package is needed by rust-palette (bug#1040661). It will be maintained in the collaborative debian section of Salsa, at https://salsa.debian.org/debian/rust-wide - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS1DZQACgkQLHwxRsGg ASEveQ/+MmxDgN+d4h80E+OV6h1P9s8Fz0W/3aeyHUBABhldBI2UvaTz16UYsdWl x+MjPHAvJt7fFGdItcTksSoPElKZQLqj9mJUc8zMRD8faOxNfHt/HMz2XFNyjuhZ kQx09lNGI/58POZvXcP4G/cuSKnZwV3AM3HdS/VKJpiJrnB1buBr9jPKeKoNr88s x5A4AhWIWcpb0u5rvfHOk1sR3fHMIVL0+DIjFCnmmVV3RbWoUI8e7TqZNu5OnBDf IlbNNUxlqv0Nt+bo1fUUQVK6t6rR80tGG3mOxa7j6PSuW4wjbOT6VJJ8BWVv6plQ d/43MVpyEuCbRHC7eidI601G9s1vCuzQuUs3PK2elJKRPat2D0Uk7aKplcQHldz8 hMb5wEVZq62gXHvd2kE98ZCzY9bXGWygtXv6KelkC48cQdKFXF0HrYcvG8Ufvepx 2CYW5LEJj7zPbLjPEqY2MJ4hRwmdz8C2JhTm2+5xYN/+kRo+ymrzbxNIKQ5L8Ggh TclnbKFQEO0GDwOIOZuYo8ofucMAKUOekxFm53C15XLMeLmOda+3dq4oI9m6wk4F heCJu2p3szB2i+wBGIMxNFye6IW0dg3YZS8c7AEOzk/0I651vh3JdrAALnf5wMiX 1LmKZscwUDl1AZ6o+Ayt2ekiGq/RbemLD9GQf1bEWrComIEZs14= =3RiD -END PGP SIGNATURE-
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Fri, Jul 14, 2023 at 09:33:12AM -0400, Jeremy Bícha wrote: > On Wed, Jul 12, 2023 at 8:32 AM Lukas Märdian wrote: > > (We're also working on a bidirectional Netplan-NetworkManager integration, > > that allows NM to feed back it's configuration into Netplan YAML format. It > > is > > a small patch for NetworkManager and is purely optional.) > > Does that already exist in Ubuntu 23.10 "Mantic"? Yes, we enabled it in Ubuntu just recently. The code can be found here: https://git.launchpad.net/network-manager/tree/debian/patches/netplan Cheers, Lukas signature.asc Description: PGP signature
Re: pre-MBF: fail to build (repack) source
Hi Adam, On Sun, Jul 16, 2023 at 12:03:00AM +0200, Adam Borowski wrote: > Here's a raw list of packages that fail to build their source (ie, > "dpkg-buildpackage -S"). Usually, this is either due to Build-Depends > being inadequate (per the Policy, B-D-Indep are _not_ necessarily > installed), or due to failing the "clean" target from a clean tree. with what severity do you plan to file these bugs? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Every time you see the word "smart" used to describe a device, replace it with "surveillance." Surveillance watch. Surveillance streetlights. Surveillance oven. Surveillance toilet. Surveillance car. Surveillance city. (@mollyali) signature.asc Description: PGP signature
Re: pre-MBF: fail to build (repack) source
On Sun, Jul 16, 2023 at 11:41:36AM +0100, Simon McVittie wrote:
> On Sun, 16 Jul 2023 at 00:03:00 +0200, Adam Borowski wrote:
> > due to Build-Depends
> > being inadequate (per the Policy, B-D-Indep are _not_ necessarily
> > installed)
> For completeness, B-D-Arch are not guaranteed to be installed during
> clean either. Similarly, Build-Conflicts are guaranteed to be absent,
> but the rarely-used Build-Conflicts-{Arch,Indep} are allowed to be
> present during clean. Policy reference for this is §7.7:
> clean
> Only the Build-Depends and Build-Conflicts fields must be
> satisfied when this target is invoked.
I wonder what's the point of B-D-Arch And B-D-Indep then?
Speaking as one of the src:developers-reference maintainers here, which
is affected from the above. Also up to now I've only ever used
dpkg-checkbuilddeps without passing any options...
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
Ich glaube die Letzte Generation ist die erste kriminelle Vereinigung in der
Geschichte, deren einziges Ziel es ist, dass sich die Regierung an die
Verfassung und ihre eigenen Gesetze hält. (@muellermusik)
signature.asc
Description: PGP signature
Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
On 17/07/2023 07.16, Helmut Grohne wrote: Then I found trei...@debian.org using edos-file-overwrite. That latter one seems like what I need here. Should we move it to the qa space and drop the edos part? I suggest debian...@lists.debian.org usertags file-overwrite. Otherwise, Ralf are you ok with me reusing your tag? Moving the usertag to the qa namespace sounds like a good idea. And dropping the ancient edos prefix ... edos-file-overwrite has been used primarily for file-vs-file conflicts (as these are the only ones detectable by analyzing .contents files) IIRC you were looking also for other cases, e.g. file-vs-directory. Maybe we should use two tags in combination, the general file-overwrite and a more fine-grained one describing the actual problem even better. We also didn't distinguish between file overwrites happening within a distro (two packages in sid shipping the same file) and on upgrades (the file in question moved between packages with insufficient Breaks+Replaces). Maybe we should. There is also the case of files that shouldn't be shipped in any package (e.g. /usr/lib/python3/dist-packages/examples/README.txt), which usually shows up with a file-overwrite error if more than one package ships the file. IIRC I didn't tag these with the edos-file-overwrite usertag. (Such files are usually also reported to lintian to flag them as "overly generic filename", e.g. #947264) Is there some place where these tags are documented? Ideally some wiki page with links to the corresponding bts query to get the bug lists ... And information how these errors are searched for (semi-)automatically. Andreas
