Re: OpenPGP certificates with SHA-1 issues in Debian keyrings

Hi! On Thu, 2025-03-20 at 22:00:04 +0100, Christoph Biedl wrote: > Being one of those on the list, I'm even more confused than I'd be about > this anyway. Ok, let me try to clarify, then! > So those people you listed: > > * Did they something wrong (although certainly with best intentions)? I

Re: OpenPGP certificates with SHA-1 issues in Debian keyrings

Hi! On Sun, 2025-03-23 at 18:46:37 -0400, Robert Edmonds wrote: > Guillem Jover wrote: > > Not all of these issues are equally "bad" from a Debian point of view, > > but all are probably bad for the certificate owners, as it might imply > > that people cannot ve

Re: OpenPGP certificates with SHA-1 issues in Debian keyrings

Hi! On Thu, 2025-03-20 at 10:55:16 +0900, Charles Plessy wrote: > sorry but I am confused... can you explain at a beginner level what is the > difference between a certificate and a "key" in the sense it is used in the > Developers Reference? Ah, sorry, the OpenPGP working group and as part of th

BTS not unmangling quoting markers with format=flowed (was: Re: Change the expectation that emails should wrap at 80 characters)

Hi! On Sun, 2025-03-16 at 18:55:52 +0100, Guillem Jover wrote: > On Sun, 2025-03-16 at 18:18:58 +0100, Guillem Jover wrote: > > […] > > such as: > > > > # On time+3, Carol wrote: > > # >On time+2, Bob wrote: > > # >>On time+1, Alice wrote:

Re: Change the expectation that emails should wrap at 80 characters

Hi! On Sun, 2025-03-16 at 18:18:58 +0100, Guillem Jover wrote: > […] > such as: > > # On time+3, Carol wrote: > # >On time+2, Bob wrote: > # >>On time+1, Alice wrote: > # >>>Some long reply line that supposedly gets wrapper at 7x chars or > #

Re: Change the expectation that emails should wrap at 80 characters

Hi! On Thu, 2025-02-27 at 13:29:59 +, Colin Watson wrote: This thread did, however, cause me to work out how to configure my mailer to send format=flowed, since it does look as though that's somewhat nicer for receivers who aren't using the same kind of dinosaur setup as I am, and support se

Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st

Hi! On Tue, 2025-02-25 at 08:14:52 -0800, Otto Kekäläinen wrote: > Salsa CI has had for many years the job 'missing-breaks' that > complements piuparts by checking that the files a package introduce > don't clash with files shipped by any other package in the > distribution without having proper B

Bug#1098361: ITP: golang-github-ergochat-readline -- readline implementation in pure Go

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-github-ergochat-readline Version : 0.1.3-1 Upstream Author : ergo.chat * URL : https://github.com/ergochat/readline * License : Expat Programming Lang: Go Description

Bug#1095156: ITP: golang-github-xyproto-randomstring -- generate random strings

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-github-xyproto-randomstring Version : 1.2.0-1 Upstream Author : Alexander F. Rødseth * URL : https://github.com/xyproto/randomstring * License : BSD-3-clause Programming Lang: Go

Re: Invalid check in debian/patches

Hi! On Sat, 2025-02-01 at 22:33:16 +0100, Abou Al Montacir wrote: > On Sat, 2025-02-01 at 17:35 +0100, Abou Al Montacir wrote: > > But also, in this particular case, it's not the issue of the spec but of a > > particular tool trying to enforce the rule. > > > > I'll file a bug to fix it. > I fin

Re: DEP-14: Default branch name 'debian/latest' objections?

On Thu, 2025-01-23 at 17:06:04 -0800, Otto Kekäläinen wrote: > Current https://dep-team.pages.debian.net/deps/dep14/ states that the > default Debian branch name is 'debian/latest': > > > In Debian this means that uploads to unstable and experimental should be > > prepared either in > > the debia

Re: DEP-14: Default branch name 'debian/latest' objections?

Hi! On Mon, 2025-01-27 at 06:28:59 -0600, G. Branden Robinson wrote: > At 2025-01-27T12:27:12+0100, IOhannes m zmölnig (Debian GNU|Linux) wrote: > > as for the original subject of this thread: what's actually wrong with > > 'debian/main' instead of 'debian/latest'? i personally do not really > >

Re: Is HURD's lack of HOST_NAME_MAX and PATH_MAX a good architectural approach

Hi! On Mon, 2025-01-20 at 13:21:32 -0700, Sam Hartman wrote: > TL;DR: Is it time for the rest of Debian to stop conforming to HURD's > lack of maximums for path and hostname? By thispoint I think we > recognize those lack of maximums as an anti-pattern for DOS prevention > and other security reaso

Re: How to conditionally patch a package based on architecture with debhelper?

Hi! On Thu, 2025-01-16 at 13:26:39 -0500, Chris Knadle wrote: > Looking at the manpage for dpkg-architecture, the variable I may want to > conditionally build upon might be DEB_TARGET_ARCH rather than DEB_HOST_ARCH. Others have already given pointers about this confusion. I'm more interested in t

Re: Removing manpages from libpam-modules to improve multi-arch

Hi! On Wed, 2025-01-15 at 09:43:36 -0700, Sam Hartman wrote: > My proposal is to move the man pages into libpam-doc. > I'm not actually convinced that normal Debian users need man pages for > all the pam modules on all Debian systems, and a suggests relationship > should be sufficient. > If people

Re: gettext 0.23.x

Hi! On Mon, 2025-01-06 at 16:45:54 +0100, Simon Josefsson wrote: > Santiago Vila writes: > > Note for Guillem: I've included your suggested fix in the bug template. Great, thanks! > I don't think we should patch upstream code for things that aren't clear > upstream bugs. Patching upstream code

Re: gettext 0.23.x

Hi! On Sun, 2025-01-05 at 19:37:44 +0100, Santiago Vila wrote: > El 5/1/25 a las 19:15, Guillem Jover escribió: > > I think this indicates a problem in the upstream autotools support, > > and it might be better to try to fix that instead of adding what seems > > like a work

Re: gettext 0.23.x

Hi! On Sun, 2025-01-05 at 17:44:33 +0100, Santiago Vila wrote: > I've just uploaded gettext 0.23.1-0.1 for experimental. Ah, great, thanks! > In most cases, the failure is like this: > > make[3]: Entering directory '/<>/po' > *** error: gettext infrastructure mismatch: using a Makefile.in.in fr

Re: Proposal: Optional `Priority: optional` and changed `Section` fall-back

Hi! On Sun, 2024-12-15 at 09:27:06 +0100, Niels Thykier wrote: > Historically, if you omitted `Priority` and `Section` from your > package, `dpkg` would warn and use `-` or `unknown` as placeholder > when it absolutely needed a value for these fields in the `.dsc` and > the `.changes` file. The re

Re: A 2025 NewYear present: make dpkg --force-unsafe-io the default?

Hi! On Sat, 2024-12-28 at 20:28:30 +0100, Gioele Barabucci wrote: > There is a possible related, but independent, optimization that has the > chance to significantly reduce dpkg install's time up to 90%. > > There is PoC patch [1,2] to teach dpkg to reflink files from data.tar > instead of copyin

Re: A 2025 NewYear present: make dpkg --force-unsafe-io the default?

Hi! [ This was long ago, and the following is from recollection from the top of my head and some mild «git log» crawling, and while I think it's still accurate description of past events, interested people can probably sieve through the various long discussions at the time in bug reports a

Filesystem snapshotting in dpkg (was Re: A 2025 NewYear present: make dpkg --force-unsafe-io the default?)

Hi! On Fri, 2024-12-27 at 12:46:02 -0500, Jonathan Kamens wrote: > On 12/27/24 7:34 AM, Geert Stappers wrote: > > Yeah, it feels wrong that dpkg gets file system code, gets code for one > > particular file system. > > I disagree. If there is a significant optimization that dpkg can implement > th

Re: Moving apt (and hence bootstraps) from GnuPG to Sequioa (via gpgv-sq)

Hi! On Mon, 2024-12-23 at 13:20:39 +0100, Chris Hofstaedtler wrote: > * Julian Andres Klode [241223 12:49]: > > Something still pulls in gpgv there > > which is unfortunate, we lack a 5MB savings. I think that would be gpgv being Priority: important, which makes debootstrap and friends pull it i

Re: Building with many cores without OOM

Hi! On Thu, 2024-12-05 at 09:23:24 +0100, Helmut Grohne wrote: > On Wed, Dec 04, 2024 at 02:03:29PM +0100, Guillem Jover wrote: > > On Thu, 2024-11-28 at 10:54:37 +0100, Helmut Grohne wrote: > > > For one thing, I propose extending debhelper to provide > > > --min-ra

Re: Should l10n packages be Recommends or Suggests?

Hi! On Fri, 2024-12-06 at 09:22:43 -, Sune Vuorela wrote: > Though I do also think we have a hole in our dependency system here. I think most of the needed pieces are there already though. > if I set my system up to be in entish, I don't want to chase translation > files all over the package

Re: Building with many cores without OOM

Hi! On Wed, 2024-12-04 at 14:37:45 +, Stefano Rivera wrote: > Hi Guillem (2024.12.04_13:03:29_+) > > > Are there other layers that could reasonably be used to implement a more > > > general form of parallelism limiting based on system RAM? Ideally, we'd > > > consolidate these implementati

Re: Building with many cores without OOM

Hi! On Wed, 2024-12-04 at 14:03:30 +0100, Guillem Jover wrote: > On Thu, 2024-11-28 at 10:54:37 +0100, Helmut Grohne wrote: > > Are there other layers that could reasonably be used to implement a more > > general form of parallelism limiting based on system RAM? Ideally, we&#x

Re: Building with many cores without OOM

Hi! On Thu, 2024-11-28 at 10:54:37 +0100, Helmut Grohne wrote: > I am one of those who builds a lot of different packages with different > requirements and found that picking a good parallel=... value in > DEB_BUILD_OPTIONS is hard. Go too low and your build takes very long. Go > too high and you

Re: Freestanding arch

Hi! On Sun, 2024-11-24 at 16:09:42 +, Bastien Roucariès wrote: > Le dimanche 24 novembre 2024, 12:06:26 UTC Bastien Roucariès a écrit : > > I plan to implement freestanding architecture specification. > > Following Toulouse debian mini debconf and javascript presentation it will > > be really

Re: RFC: "Recommended bloat", and how to possibly fix it

Hi! On Tue, 2024-11-05 at 17:35:59 -0600, Aaron Rainbolt wrote: > With all this in mind, I'd like to call some attention to a feature > request made by Patrick Schleizer some time ago, whom I've copied on > this email. The feature request suggests the addition of a new field to > Debian's binary d

Re: DEP-0, DEP0 or DEP 0?

Hi! On Thu, 2024-11-14 at 00:48:18 -0800, Otto Kekäläinen wrote: > I am the kind of person that gets hugely annoyed by things like this. > Is anyone else feeling it? >· > Can we agree on calling Debian Enhancement Proposals DEP-N with a dash? I'm also all for consistency, although I'm in general

[Summary]: Supporting alternative zlib implementations

Hi! [ I'll try to summarize the current discussion and status, what might be blockers, and a potential incremental way forward. ] On Wed, 2024-09-25 at 10:48:50 +0200, Mark Brown wrote: > On Tue, Sep 24, 2024 at 05:45:49PM +0200, Guillem Jover wrote: > > On Tue, 2024-09-24 at

Re: Re: It makes no sense to link vmlinuz and initramfs to the root directory

Hi! On Tue, 2024-11-12 at 11:02:53 +0100, Johannes Schauer Marin Rodrigues wrote: > Quoting Hans (2024-11-12 09:35:08) > > However, maybe a link is alo no more needed, even with a seperated /boot > > partition. > > It's just a symlink. What's the harm? For me, the default location of the symlink

Re: Bug#1086878: python-catalogue: 2.1.0 was yanked - what version scheme should we use for 2.0.10?

Hi! On Thu, 2024-11-07 at 02:01:49 +, Colin Watson wrote: > On Thu, Nov 07, 2024 at 02:42:08AM +0100, Guillem Jover wrote: > > Given that I assume the current (non-retracted) upstream version is > > going to be close to surpass the retracted one, I'd go for the +really &g

Re: Rebuilds to enable PAC and BTI support on arm64

Hi! On Wed, 2024-11-06 at 17:28:38 +0500, Andrey Rakhmatullin wrote: > On Wed, Nov 06, 2024 at 10:43:07AM +0100, Emanuele Rocca wrote: > > As a final thought, given that new toolchain versions bring multiple > > improvements over the years it's perhaps worth thinking about rebuilding > > the archi

Re: Bug#1086878: python-catalogue: 2.1.0 was yanked - what version scheme should we use for 2.0.10?

Hi! On Thu, 2024-11-07 at 01:15:08 +, Colin Watson wrote: > Source: python-catalogue > Version: 2.1.0-6 > Severity: normal > X-Debbugs-Cc: Andreas Tille , debian-devel@lists.debian.org > https://pypi.org/project/catalogue/#history shows that 2.1.0 was yanked > from PyPI, but it's what we curr

Re: efficient way to detect linker script files?

Hi! On Tue, 2024-10-22 at 23:00:29 +0200, Serafeim (Serafi) Zanikolas wrote: > I'd like to discover all installed linker scripts, for the purposes of > #823531 (check for broken linker scripts files). it's not clear to me > that there's a convention I could rely on to avoid brute forcing > filetyp

Re: Epoch for src:fuse-ext2 to replace src:fuse-umfuse-ext2's fuseext2 binary

Hi! On Tue, 2024-10-22 at 00:00:21 +0200, Ben Hutchings wrote: > On Mon, 2024-10-21 at 00:49 +0200, наб wrote: > > On Sun, Oct 20, 2024 at 11:39:36PM +0200, Ben Hutchings wrote: > > > On Sun, 2024-10-20 at 20:03 +0200, наб wrote: > > > > I'd like to use an epoch so I'm asking for consensus per pol

Re: Bug#1085388: ITP: einops -- Flexible and powerful tensor operations for readable and reliable code.

Hi! On Fri, 2024-10-18 at 12:03:46 -0700, Mo Zhou wrote: > Package: wnpp > Severity: wishlist > Owner: Mo Zhou > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name    : einops > * URL : https://einops.rocks > * License : MIT/Expat >   Programming Lang: Python >  

Re: Bug#1081111: ITP: sphinx-toolbox -- Box of handy tools for Sphinx

Hi! On Sun, 2024-09-08 at 08:55:58 +0530, Kathara Sasikumar wrote: > Package: wnpp > Severity: wishlist > Owner: Kathara Sasikumar > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: sphinx-toolbox > Version : 3.8.0 > Upstream Contact: Dominic Davis-Foster > * URL

Re: Bug#1078734: ITP: legacycrypt -- The legacycrypt module is a standalone version of https://docs.python.org/3/library/crypt.html (deprecated), to ease 3.13 transition.

Hi! On Wed, 2024-08-14 at 20:47:56 -0500, eevelweezel wrote: > Package: wnpp > Severity: wishlist > Owner: eevelweezel > X-Debbugs-Cc: debian-devel@lists.debian.org, eevel.wee...@gmail.com > * Package name: legacycrypt > Version : 0.0.3 > Upstream Contact: Christian Heimes > * U

Re: Bug#1085206: ITP: evalidate -- Validation and secure evaluation of untrusted Python expressions

Hi! On Wed, 2024-10-16 at 11:00:31 +0100, Colin Watson wrote: > Package: wnpp > Severity: wishlist > Owner: Colin Watson > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: evalidate > Version : 2.0.3 > Upstream Contact: Yaroslav Polyakov > * URL : http

Re: Bug#1085127: ITP: go-nmap -- Nmap XML parsing library for Go (library)

Hi! On Mon, 2024-10-14 at 22:20:11 -0300, Marcos Rodrigues de Carvalho (aka oday) wrote: > Package: wnpp > Severity: wishlist > Owner: "Marcos Rodrigues de Carvalho (aka oday)" > X-Debbugs-Cc: debian-devel@lists.debian.org, marcosrcarvalh...@gmail.com > > * Package name: go-nmap > Version

Re: signify and signify-openbsd names

Hi! On Tue, 2024-10-08 at 09:01:06 +0200, Simon Josefsson wrote: > 1) Take current non-OpenBSD 'signify' source package and upload NEW > 'signify-mail' with d/control modified as: > > Source: signify-mail > ... > Package: signify-mail > Replaces: signify (<= 1.14-7) > > Do we need 'Breaks: signi

Re: signify and signify-openbsd names

Hi! On Wed, 2024-10-09 at 19:42:45 +0200, Ben Hutchings wrote: > On Wed, 2024-10-09 at 10:26 +0100, Jonathan Dowland wrote: > > On Mon Oct 7, 2024 at 8:58 AM BST, Marc Haber wrote: > > > P.S.: Isnt it about time to rename exim4 to exim? > > > > Or apache2 to apache? > The ASF is responsible for

Re: ITS: aiocoap

Hi! On Tue, 2024-10-08 at 11:37:52 +0200, Mazen Neifer wrote: > Source: aiocoap > Severity: important > I would like to salvage this package because it is no more maintained. > > Last maintainer upload was more than 5 years ago. > Last commit to git on salsa was on February 2019. > > If no obje

Re: Alternative signature mechanisms for upstream source verification

Hi! On Fri, 2024-10-04 at 18:21:01 +, Stefano Rivera wrote: > Picking up a thread that started on debian-pyt...@lists.debian.org: > https://lists.debian.org/msgid-search/14198883.O9o76ZdvQC@galatea > > Upstreams that care about supply chain security have been building > mechanisms to authenti

Re: Bug#1082850: ITP: golang-github-mitchellh-pointerstructure -- Addressing and modifying values in Go structures using a string syntax

Hi! On Fri, 2024-09-27 at 12:28:51 +, Francisco Vilmar Cardoso Ruviaro wrote: > Package: wnpp > Severity: wishlist > Owner: Francisco Vilmar Cardoso Ruviaro > X-Debbugs-Cc: debian-devel@lists.debian.org, vil...@debian.org > * Package name: golang-github-mitchellh-pointerstructure > Ver

Re: Supporting alternative zlib implementations

Hi! On Wed, 2024-09-25 at 00:39:10 +0200, Fay Stegerman wrote: > * Guillem Jover [2024-09-24 17:45]: > > Personally, I think fully migrating from zlib to zlib-ng would sound > > great (even for trixie), but I guess we can take it slow if you do not > > feel confident or ha

Re: Supporting alternative zlib implementations

Hi! On Tue, 2024-09-24 at 15:58:10 +0200, Mark Brown wrote: > In the past I've pushed back on doing anything here since zlib is > essential and it seemed better to be consistent over the ecosystem than > to use a more niche implementation, and some of the early optimisation > efforts had not worke

Re: Question about library package splitting

Hi! On Fri, 2024-09-06 at 11:32:55 +0200, Ervin Hegedüs wrote: > Here comes the problem: libmodsecurity3 has two types of collection stores: > in-memory and LMDB. It's VERY important: you MUST decide the type of > choosed backend in compilation time, later you can't change it in runtime! I think

Re: Should OpenSSL/ libssl3 depend on brotli?

Hi! On Sat, 2024-09-07 at 00:12:58 +0200, Sebastian Andrzej Siewior wrote: > Is it okay for libssl3 do depend on libbrotli? It would increase minimal > installs by ~900KiB on amd64. > tl;dr > coreutils build-depends on libssl-dev which makes libssl essential. > libssl already supports compression

Bug#1080429: ITP: golang-github-mostynb-go-grpc-compression -- Go gRPC encoding wrappers for compression algorithms missing from google.golang.org/grpc

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-github-mostynb-go-grpc-compression Version : 1.2.3-1 Upstream Author : Mostyn Bramley-Moore * URL : https://github.com/mostynb/go-grpc-compression * License : Apache-2.0 Programming

Bug#1080428: ITP: golang-github-go-viper-mapstructure -- decode generic map values into native Go structures and vice versa

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-github-go-viper-mapstructure Version : 2.1.0-1 Upstream Author : Viper * URL : https://github.com/go-viper/mapstructure * License : Expat Programming Lang: Go Description

Bug#1080354: ITP: golang-opentelemetry-collector -- OpenTelemetry Collector (library)

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-opentelemetry-collector Version : 0.108.1-1 Upstream Author : OpenTelemetry - CNCF * URL : https://github.com/open-telemetry/opentelemetry-collector * License : Apache-2.0

Bug#1080351: ITP: golang-github-bboreham-go-loser -- Loser Tree data structure, for fast k-way merge

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-github-bboreham-go-loser Version : 0.0~git20230920.fcc2c21-1 Upstream Author : Bryan Boreham * URL : https://github.com/bboreham/go-loser * License : Apache-2.0 Programming Lang: Go

Bug#1080349: ITP: golang-github-victoriametrics-easyproto -- simple building blocks for protobuf marshaling and unmarshaling

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: golang-github-victoriametrics-easyproto Version : 0.1.4-1 Upstream Author : VictoriaMetrics * URL : https://github.com/VictoriaMetrics/easyproto * License : Apache-2.0 Programming Lang: Go

Re: Mandatory LC_ALL=C.UTF-8 during package building

Hi! On Sat, 2024-07-06 at 13:13:48 +0200, Alexandre Detiste wrote: > Le mar. 2 juil. 2024 à 14:37, Guillem Jover a écrit : > > On Tue, 2024-07-02 at 09:52:05 +0100, Simon McVittie wrote: > > > On Tue, 02 Jul 2024 at 03:47:29 +0200, Guillem Jover wrote: > > > >

Re: Mandatory LC_ALL=C.UTF-8 during package building

Hi! [ Mostly trying to clarify some of my earlier comments. ] On Fri, 2024-06-07 at 17:20:29 +0100, Simon McVittie wrote: > On Fri, 07 Jun 2024 at 14:32:14 +0200, Guillem Jover wrote: > > I'm a non-native speaker, who has been involved > > in l10n for a long time, while a

Re: Q: Ubuntu PPA induced version ordering mess.

Hi! On Tue, 2024-07-02 at 03:32:53 +0200, Guillem Jover wrote: > On Tue, 2024-07-02 at 00:54:13 +0100, Wookey wrote: > > Quite. People are quite resistant to spoiling neat version numbers > > with epochs, and no-one likes them, but they don't do any actual harm > > (exce

Re: Mandatory LC_ALL=C.UTF-8 during package building

Hi! On Tue, 2024-07-02 at 09:52:05 +0100, Simon McVittie wrote: > On Tue, 02 Jul 2024 at 03:47:29 +0200, Guillem Jover wrote: > > On Fri, 2024-06-07 at 15:40:07 +0200, Alexandre Detiste wrote: > > > Maybe a compromise would be to at least mandate some UTF-8 locale. > &g

Re: Mandatory LC_ALL=C.UTF-8 during package building

ounter to l10n work, or perhaps to switch to a subset of the locale settings. Niels? Thanks, Guillem From 94c2540fe290ffaa70680d21725e3541642ab2f2 Mon Sep 17 00:00:00 2001 From: Guillem Jover Date: Tue, 2 Jul 2024 03:34:35 +0200 Subject: [PATCH] dpkg-buildpackage: Require an UTF-8 (or ASCII) locale

Re: Q: Ubuntu PPA induced version ordering mess.

Hi! On Tue, 2024-07-02 at 00:54:13 +0100, Wookey wrote: > On 2024-07-01 23:59 +0200, Alec Leamas wrote: > > But this is not about third parties, it's about upstream which publishes PPA > > packages. So far these are by far the most used Linux packages. > > > > I also hesitate to add an epoch, aft

Re: Reviving schroot as used by sbuild

Hi! On Tue, 2024-06-25 at 09:32:21 -0700, Russ Allbery wrote: > Simon McVittie writes: > > Persisting a container root filesystem between multiple operations comes > > with some serious correctness issues if there are "hooks" that can modify > > it destructively on each operation: see

Re: Enabling some -Werror=format* by default?

Hi! On Mon, 2024-06-10 at 18:01:58 +0200, Helmut Grohne wrote: > Ideally, we'd not just do a rebuild with the flags, but also do a > rebuild without and then compare the binary .debs. In the event that we > misguide configure, we expect the .debs to differ and otherwise to equal > due to the work

Re: Enabling some -Werror=format* by default?

Hi! On Mon, 2024-06-10 at 20:09:21 +0500, Andrey Rakhmatullin wrote: > On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote: > > > Do you think it makes sense to add this a flag that enables -Werror=format > > > to dpkg-buildflags(1), before, or after a test rebu

Re: Enabling some -Werror=format* by default?

Hi! On Mon, 2024-06-10 at 16:06:13 +0500, Andrey Rakhmatullin wrote: > On Mon, Jun 10, 2024 at 07:48:59AM +0200, Helmut Grohne wrote: > > > We recently increased the time_t size on certain architectures and some > > > packages started failing to build because they were using a format > > > specifi

Re: Mandatory LC_ALL=C.UTF-8 during package building

Hi! On Thu, 2024-06-06 at 15:31:55 +0100, Simon McVittie wrote: > On Thu, 06 Jun 2024 at 13:32:27 +0300, Hakan Bayındır wrote: > > C, or C.UTF-8 is not a universal locale which works > > for all. > > Sure, and I don't think anyone is arguing that you or anyone else should > set the locale for you

Re: MBF: drop dependencies on system-log-daemon

Hi! On Tue, 2024-05-28 at 10:57:13 +0900, Simon Richter wrote: > On 5/27/24 22:18, Simon McVittie wrote: > > So I think your syslogd-is-journald could not be a Provides on the > > existing systemd-sysv package, and would have to be a separate package. > > I'm not sure that the benefit is worth it

Re: New supply-chain security tool: backseat-signed

Hi! On Sat, 2024-04-06 at 19:13:22 +0800, Sean Whitton wrote: > On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote: > > Right now the preferred form of source in Debian is an upstream-signed > > release tarball, NOT anything from git. > > The preferred form of modification is not simply up for

Re: Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)

Hi! On Wed, 2024-04-03 at 23:53:56 +0100, James Addison wrote: > On Wed, 3 Apr 2024 19:36:33 +0200, Guillem wrote: > > On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote: > > > On 2024-03-29 22:41, Guillem Jover wrote: > > > I think with my upstream hat on I

Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)

Hi! On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote: > On 2024-03-29 22:41, Guillem Jover wrote: > > (For dpkg at least I'm pondering whether to play with switching to > > doing something equivalent to «git archive» though, but see above, or > > maybe generate

autoreconf --force not forcing (was Re: Validating tarballs against git repositories)

Hi! On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote: > Let's try to go in detail on how this was done on the build system > side (I'm doing this right now, as previously only had skimmed over > the process). > > The build system hook was planted in the tarball

Re: Some t64 libraries already in testing; I'm confused

Hi! On Sun, 2024-03-31 at 06:54:10 +0200, Andreas Metzler wrote: > On 2024-03-30 Julian Gilbey wrote: > > My very limited understanding of this major transition was that the > > t64 libraries are being held in unstable until (almost) everything is > > ready, at which point there will be a coordin

Re: Validating tarballs against git repositories

Hi! On Fri, 2024-03-29 at 23:53:20 -0600, Antonio Russo wrote: > On 2024-03-29 22:41, Guillem Jover wrote: > > On Fri, 2024-03-29 at 18:21:27 -0600, Antonio Russo wrote: > >> Had tooling existed in Debian to automatically validate this faithful > >> reproduction, we mig

Re: Validating tarballs against git repositories

Hi! On Fri, 2024-03-29 at 18:21:27 -0600, Antonio Russo wrote: > This is a vector I've been somewhat paranoid about myself, and I > typically check the difference between git archive $TAG and the downloaded > tar, whenever I package things. Obviously a backdoor could have been > inserted into the

Bug#1067413: RFP: keydb -- persistent key-value database with network interface

Package: wnpp Severity: wishlist X-Debbugs-Cc: Chris Lamb , Sascha Steinbiss * Package name: keydb Version : 6.3.4 Upstream Contact: https://github.com/Snapchat/KeyDB * URL : https://keydb.dev/ * License : BSD-3-clause Programming Lang: C, C++ Description

Extended description of filesystem namespace clashes

Hi! On Wed, 2024-02-28 at 07:41:50 +0100, Helmut Grohne wrote: > That said, I appreciate your work on analyzing the situation as it also > uncovers tangential problems e.g. where different packages put programs > with different functionality into bin and sbin. It is up to > interpretation of Debia

Re: Package marked for autoremoval due to closed bug? [and 1 more messages]

Hi! On Tue, 2024-03-19 at 10:32:04 +, Ian Jackson wrote: > [2] In my case src:dgit depends on git-buildpackage. The autoremoval > robot wants to remove git-buildpackage because of the time_t bugs > against rpm, xdelta, and pristine-tar. One root cause is that > src:dpkg isn't migrating becau

Re: Another take on package relationship substvars

Hi! On Fri, 2024-02-23 at 17:59:14 -0800, Steve Langasek wrote: > One generic case that this doesn't handle is Essential: yes packages. For > many of these, the ${shlibs:Depends} gets promoted in debian/control to > Pre-Depends, not to Depends. Ah! Good point. I think the particular case of the

Re: time_t progress report

Hi! On Mon, 2024-02-19 at 19:48:38 -0800, Steve Langasek wrote: > I have coordinated with the gcc maintainer so that we can have the default > flags in gcc-13 changed this week. > > We are therefore targeting Friday for the mass NMUs to unstable though there > is a possibility this won't start un

Re: Another take on package relationship substvars

Hi! On Thu, 2024-02-22 at 23:14:13 +0100, gregor herrmann wrote: > On Thu, 22 Feb 2024 19:32:21 +0100, Niels Thykier wrote: > > If you forget to add a susbtvars that you should added, it is a latent RC > > bug with only a warning from dpkg-gencontrol that you might miss if you grab > > a coffee wh

Re: Another take on package relationship substvars

Hi! On Thu, 2024-02-22 at 19:32:21 +0100, Niels Thykier wrote: > Our current way of dealing with package relationship substvars such as > ${misc:Depends} has been annoying me for a while. As it is, we are stuck in > this way setup where the "Depends" field in debian/control is de facto > mandatory

Re: Bug#1064082: ITP: golang-github-cheggaaa-pb -- Console progress bar for Golang

Hi! On Fri, 2024-02-16 at 15:07:55 -0800, Loren M. Lang wrote: > Package: wnpp > Severity: wishlist > Owner: Loren M. Lang > * Package name: golang-github-cheggaaa-pb > Version : 3.1.5-1 > Upstream Author : Sergey Cherepanov > * URL : https://github.com/cheggaaa/pb >

Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

Hi! On Fri, 2024-02-02 at 08:21:57 -0800, Steve Langasek wrote: > Once all of these packages have built in experimental and we have identified > and addressed all adverse interactions with the usrmerge transition, the > plan is: > > - dpkg uploaded to unstable with abi=time64 enabled by default[

Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

> are a number of newly-identified packages that fail to compile and have a > > large number of reverse-dependencies. I will continue to work to identify > > false-positives here in the hopes of bringing this count down before pulling > > the trigger on an actual transition. &

SOP migration (was Re: Reaction to potential PGP schism)

Hi! Daniel thanks for all your work on the OpenPGP working group, and on SOP! :) On Wed, 2023-12-20 at 22:16:28 -0500, Daniel Kahn Gillmor wrote: > # What Can Debian Do About This? > > I've attempted to chart one possible path out of part of this situation > by proposing a minimized, simplified

Re: Signature strength of .dsc

Hi! On Fri, 2023-12-01 at 00:20:16 +, Dimitri John Ledkov wrote: > Currently dak requires signatures on .changes & .dsc uploads. .changes with > signatures are publicly announced and then .dsc are published in the > archive with signatures. .changes references .dsc. > > All .dsc have Checksums

Re: New Essential package procps-base

Hi! On Tue, 2023-11-14 at 17:29:01 +1100, Craig Small wrote: > What: > Create a new package procps-base. This uses the existing procps source > package and just enable building of pidof. procps-base will be an Essential > package and only contain pidof. > > Why: > This would bring the pidof varia

Re: Linking coreutils against OpenSSL

Hi! On Thu, 2023-11-09 at 17:38:05 -0500, Benjamin Barenblat wrote: > coreutils can link against OpenSSL, yielding a substantial speed boost > in sha256sum etc. For many years, this was inadvisable due to license > conflicts. However, as of bookworm, coreutils requires GPL-3+ and > OpenSSL is Apac

Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages

Hi! On Sat, 2023-09-16 at 10:31:20 +0530, Hideki Yamane wrote: > ## More bandwidth > > According to https://www.speedtest.net/global-index, broadband bandwidth > in Nicaragua becomes almost 10x > > - 2012: 1.7Mbps > - 2023: 17.4Mbps Well that page still does not look too great for many othe

Re: Enabling branch protection on amd64 and arm64

Hi! On Sun, 2023-08-27 at 12:51:53 +0200, Guillem Jover wrote: > On Tue, 2023-06-27 at 16:09:40 +0100, Wookey wrote: > > OK. We're all agreed on that then. Guillem can stick it in the next > > dpkg upload. So this happened, and Johannes reported that this seems to be bre

Re: Enabling -fstack-clash-protection for trixie

Hi! On Sun, 2023-08-06 at 23:25:23 +0200, Moritz Mühlenhoff wrote: > Following the procedure to modify default dpkg-buildflags I propose to > enable -fstack-clash-protection on amd64. The bug for dpkg tracking this > is #918914. > > | -fstack-clash-protection > | Generate code to prevent stack cl

Re: Enabling branch protection on amd64 and arm64

Hi! On Tue, 2023-06-27 at 16:09:40 +0100, Wookey wrote: > On 2023-06-27 16:58 +0200, Moritz Mühlenhoff wrote: > > Am Wed, Jun 21, 2023 at 05:41:36PM +0200 schrieb Emanuele Rocca: > > > On 2022-10-26 08:20, Moritz Mühlenhoff wrote: > > > > I think this should rather be applied early after the Bookw

Re: Issues in the Patch Tagging Guidelines

Hi! [ Started this some days ago and only finished it now, I see Jonathan has covered some parts of this. ] On Thu, 2023-08-10 at 15:42:03 +0200, Lucas Nussbaum wrote: > On 08/08/23 at 01:25 +0200, Guillem Jover wrote: > > Lately I've been updating metadata in patches in packa

Re: Potential MBF: packages failing to build twice in a row

On Wed, 2023-08-09 at 22:10:51 +0200, Johannes Schauer Marin Rodrigues wrote: > Quoting Guillem Jover (2023-08-09 20:55:17) > > I think I've mentioned this before, but dpkg-source is supposed to be > > generating reproducible source packages since around the time dpkg-deb >

Re: Potential MBF: packages failing to build twice in a row

Hi! On Wed, 2023-08-09 at 19:55:41 +0200, Johannes Schauer Marin Rodrigues wrote: > I would only consider switching the default if at the same time, some checks > were done that made sure that the result is bit-by-bit identical to the > original. > > The source package is the *input* to sbuild no

Issues in the Patch Tagging Guidelines

Hi! Lately I've been updating metadata in patches in packages I maintain and noticed several issues with the Patch Tagging Guidelines, and after Lucas created the new great patches UDD service [P] and we discussed some other issues there, it looked like the guidelines could do with some fixes and

Re: hardening flags

Hi! On Sat, 2023-07-29 at 16:59:29 +0200, Martin Uecker wrote: > are there any plans to add -fstack-clash-protection to > the hardening flags? See #918914. Thanks, Guillem

Re: systmd-analyze security as a release goal

Hi! On Thu, 2023-07-06 at 18:41:38 +1000, Trent W. Buck wrote: > "Trent W. Buck" writes: > > e.g. I expect "SystemCallArchitectures=native" to break for a lot of > > people (anyone doing dpkg --add-architecture) Yes, see #982456. > Short version: > > • SystemCallArchitectures=native + debian

  1   2   3   4   5   6   7   8   9   10   >