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

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

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

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

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: 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

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

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

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

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: 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: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote: > On 2020-11-14, Sune Vuorela wrote: > > Unfortunately, only like 10% of the relevant packages have test suites > > enabled and run, because gettings things to work reliable is sometimes > > hard. > So, based on your estimate and the c

Bug#974934: RFP: golang-github-ncabatoff-go-seq -- sequence Go values to allow sorting them

Package: wnpp Severity: wishlist * Package name: golang-github-ncabatoff-go-seq Version : 0.0~git20180805.b08ef85-1 Upstream Author : Nick Cabatoff * URL : https://github.com/ncabatoff/go-seq * License : Expat Programming Lang: Go Description : sequence

Bug#974935: RFP: golang-github-ncabatoff-fakescraper -- scrape Prometheus metrics from inside the app

Package: wnpp Severity: wishlist * Package name: golang-github-ncabatoff-fakescraper Version : 0.0~git20201102.4b37ba6-1 Upstream Author : Nick Cabatoff * URL : https://github.com/ncabatoff/fakescraper * License : https://github.com/ncabatoff/fakescraper/issues/

Bug#977164: RFP: golang-github-victoriametrics-metricsql -- standalone PromQL and MetricsQL parser

Package: wnpp Severity: wishlist Tags: patch * Package name: golang-github-victoriametrics-metricsql Version : 0.8.0-1 Upstream Author : VictoriaMetrics * URL : https://github.com/VictoriaMetrics/metricsql * License : Apache-2.0 Programming Lang: Go Descript

Re: Bug#974087: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

Hi! On Mon, 2020-11-16 at 02:33:53 +0100, Guillem Jover wrote: > On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote: > > > Adding more hurdles does not help. > > > I think this is a hurdle we do not need. > > > > To me, a one-line change in packagin

Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

On Fri, 2021-01-08 at 19:23:13 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > [snip] > > We did a full archive rebuild testing this change, and I provided > > patches to all known affected packages several months ago. It is a > > one-line change in debian/rules in most cases: > > > > > > ht

Re: Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

having a thought about too. But as a starting point I prepared the attached patch, which sets the variable from dpkg-buildpackage and pkg-info.mk. Once there's agreement on the variable(s), I'm fine merging this, but whether to include this for bullseye would need release-team approval a

Re: move to merged-usr-only?

*Sigh*, replying only now because I find this topic exhausting, draining, tiresome and I'd rather be doing productive stuff instead of rehashing stuff for the nth time. :( Even though I've also tried to document and summarize this in the dpkg FAQ and the dpkg MergedUsr wiki page, but I assume I'm n

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

Hi! On Thu, 2021-02-11 at 21:59:42 +0100, Raphaël Hertzog wrote: > Package: general > Severity: normal > User: de...@kali.org > Usertags: origin-kali > X-Debbugs-Cc: hert...@debian.org, debian-d...@lists.debian.org > Control: affects -1 ftp.debian.org dpkg-dev > After having been bitten (in Kali)

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

On Fri, 2021-02-12 at 01:05:21 +0100, Mattia Rizzolo wrote: > On Fri, 12 Feb 2021, 12:52 am Guillem Jover, wrote: > > Then there's the problem with changing contents for already seen > > files, which seems like a dak bug. It does not allow to change a > > tarball once it

Re: Questioning debian/upstream/signing-key.asc

Hi! [ Ccing Daniel, as he proposed the shipping of upstream signatures, so leaving full context. ] On Fri, 2021-03-26 at 10:13:25 +0100, Christoph Biedl wrote: > a few days ago, I ran uscan on a package where I knew there was a new > upstream version - just to encounter an validation error sinc

Re: Questioning debian/upstream/signing-key.asc

[ CCing Daniel. ] On Fri, 2021-03-26 at 17:31:16 +0100, Ansgar wrote: > On Fri, 2021-03-26 at 09:06 -0700, Russ Allbery wrote: > > I'm not all that familiar with the intended semantics of OpenPGP key > > expirations, but intuitively I think a signature made before the > > expiration should be cons

Re: Questioning debian/upstream/signing-key.asc

Hi! On Fri, 2021-04-02 at 13:38:51 +0200, Guillem Jover wrote: > On Fri, 2021-03-26 at 10:13:25 +0100, Christoph Biedl wrote: > > However, I uncertain whether is really worth the efforts to maintain > > d/u/s-k, or more precisely, ping maintainers to do so. Personally, I > >

Re: Proposed mass-bug filing: missing support for build-arch or build-indep

Hi! On Mon, 2021-04-19 at 15:11:21 +0200, Lucas Nussbaum wrote: > I would like to propose a mass bug filing on source packages that miss > support for build-arch or build-indep targets in debian/rules. Thanks, that'd be great! > There are currently 411 packages in testing that do not include tho

Re: Epoch bump for kernelshark

On Tue, 2021-05-25 at 20:04:04 -0300, David Bremner wrote: > Mattia Rizzolo writes: > > On Sun, May 23, 2021 at 03:17:10PM -0500, Richard Laager wrote: > >> On 5/23/21 8:34 AM, Sudip Mukherjee wrote: > >> > And, as a result, upstream kernelshark is now at v2.0 but the Debian > >> > packaged versio

Re: Planning for libidn shared library version transition

On Tue, 2021-05-25 at 19:43:21 +0200, Andreas Metzler wrote: > On 2021-05-24 Simon Josefsson wrote: > > Generally, does things looks okay? Specifically, what about the > > Breaks/Replaces/Conflicts? The d/changelog entry? Will the confusing > > 'Replaces: libidn11-dev' for the libidn11 (!) pack

Re: Bug#989068: ITP: object-cloner -- Java Object cloning library with extensible strategies

Hi! On Mon, 2021-05-24 at 20:08:57 -0400, James Valleroy wrote: > Package: wnpp > Severity: wishlist > Owner: James Valleroy > X-Debbugs-Cc: debian-devel@lists.debian.org, jvalle...@mailbox.org > > * Package name: object-cloner > Version : 0.2 > Upstream Author : Kamran Zafar >

Re: What are desired semantics for /etc/shells?

Hi! On Thu, 2021-06-10 at 20:00:02 +0200, Helmut Grohne wrote: > Due to working on installation bootstrap, I was looking into > `/etc/shells`. > > Introduction > > > `/etc/shells` contains valid login shells. Some programs match the configured > shell of a user against this file to

Re: Need help with Multi-Arch in systemd

On Fri, 2021-07-09 at 12:29:19 +0200, Michael Biebl wrote: > Am 09.07.2021 um 11:37 schrieb Timo Röhling: > > * Michael Biebl [2021-07-09 11:01]: > > > Splitting out libsystemd-shared (once) will make PID1 very brittle. > > > It can lead to situations where old systemd + new libsystemd-private > >

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote: > Sean Whitton dixit: > >* #978636 move to merged-usr-only? > > > > We were asked to decide whether or not Debian 'bookworm' should > > continue to support systems which are not using the merged-usr > > filesystem layout. We decided t

Re: What are desired semantics for /etc/shells?

Hi! On Tue, 2021-06-15 at 13:31:15 +0200, Felix C. Stegerman wrote: > FYI I just noticed another inconsistency: on my merged /usr systems > (installed as such, not converted later w/ usrmerge), /etc/shells > contains both /bin/ and /usr/bin/ paths for some shells, but not all > (e.g. no /usr/bin/s

Re: Need help with Multi-Arch in systemd

On Wed, 2021-07-14 at 11:59:11 +0100, Simon McVittie wrote: > On Thu, 08 Jul 2021 at 23:03:48 +0200, Michael Biebl wrote: > > [a separate libsystemd-shared-249 .deb] would also mean, that on every > > new upstream release, systemd would have to go through NEW > > It seems like we're rejecting a go

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Thu, 2021-07-15 at 10:13:47 +0100, Luca Boccassi wrote: > As it has been said and written many times already, in reality this is > not broken by design at all and in fact it is the only successful > strategy that has been deployed by other distros - it's what is being > called merged-usr-via-mov

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Mon, 2021-07-19 at 15:10:42 +0200, Michael Biebl wrote: > Am 19.07.21 um 03:36 schrieb Guillem Jover: > > What I've also said multiple times, is that > > merged-usr-via-moves-and-symlink-farms could have been implemented in > > a fully automated way, by debhelper, w/

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Mon, 2021-07-19 at 16:41:42 +0200, Johannes Schauer Marin Rodrigues wrote: > So what what is actually the roadmap after the bullseye release? What is the > way forward? Should I rather file bugs with patches against individual > packages > to move their files from /(sbin|bin|lib)/ to /usr/(sbin

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

On Tue, 2021-07-20 at 11:31:37 +0200, Guillem Jover wrote: > Unfortunately, when the supporters of the merged-/usr-via-aliased-dirs > pushed their approach into the distribution, that meant that package > stopped being able to ship compatibility symlinks under «/», and those >

Re: Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[ Barak, I appreciate your mail, but *sigh*, it's still frustrating, as pretty much many of the mails related to this, as they keep ignoring what has been said, and I feel like talking to a wall. :/ ] On Thu, 2021-07-22 at 11:48:34 +0100, Barak A. Pearlmutter wrote: > Seriously? Being able to

Re: merged /usr

On Tue, 2021-07-27 at 11:44:32 +0200, Wouter Verhelst wrote: > On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote: > > On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote: > > > I've suggested previously that we can easily make it RC for bookworm to > > > have a file outside a

Re: merged /usr

On Tue, 2021-07-27 at 16:26:34 +0200, Simon Richter wrote: > On 7/27/21 11:44 AM, Wouter Verhelst wrote: > > A package in the essential set could work around the issue by moving a > > file around and creating a necessary symlink in preinst rather than > > shipping things. The set of Essential packa

Re: merged /usr

On Tue, 2021-07-27 at 13:23:46 -0400, Calum McConnell wrote: > > Of course, having to unnecessarily add more maintainer scripts to > > handle something that dpkg can do perfectly fine on its own > > TL;DR: merged-usr-via-symlink-farms cannot be done without changing dpkg, In my mind that's "false

Re: Arch triplet for uefi applications

On Tue, 2021-08-10 at 12:34:18 +, Bastien Roucariès wrote: > I am going to compile shell.efi from source. > > I whish to install to something stable, but I need an arch triplet > in order to put in a multiarch (like) location. Multiarch-based pathnames should only be used by multiarch-conform

Re: merged /usr

On Fri, 2021-08-13 at 07:53:20 +0200, Marco d'Itri wrote: > Implementations with real /bin /sbin /lib* directories and symlink farms > are not useful because they would negate the major benefits of > merged-/usr, i.e. the ability of sharing and independently updating > /usr. Yes, that major bene

Re: merged /usr vs. symlink farms

On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote: > My recollection (which might be wrong, but a quick look at release > notes seems to support it with 11.04 having multiarch 2 years before > Wheezy) is that Canonical led the way with the multiarch effort in > Ubuntu, and Debian followed w

Re: merged /usr vs. symlink farms

On Fri, 2021-08-20 at 07:56:33 -0600, Sam Hartman wrote: > > "Theodore" == Theodore Ts'o writes: > Theodore> FWIW, from following the discussion, I've become more and > Theodore> more convinced that a symlink farm is *not* the right > Theodore> answer, regardless of whether it is d

Re: merged /usr vs. symlink farms

On Wed, 2021-08-25 at 09:57:09 -0700, Russ Allbery wrote: > Wouter Verhelst writes: > > The problem here is also that if there are two packages like that, on an > > usrmerge system, we would not know this is happening. Also this does not need to come from "buggy" packaging practices. > I agree,

Re: merged /usr vs. symlink farms

Hi! On Sun, 2021-08-22 at 09:18:25 +0200, Andreas Metzler wrote: > Afaict we have still no idea on how to move on. > > 1 I think you agree that there is a significant number of usrmerged Debian > installations out there. It does not really matter whether there are 7% or > 40%. They exist and

Epoch bump for golang-github-valyala-fasthttp

Hi! The golang-github-valyala-fasthttp package used to have date-based release numbers (current Debian version 20160617-2). Upstream has since switched to semver (latest upstream version 1.31.0). So the version scheme has been reset, and unfortunately given that no prefix was used when initially

Re: merged /usr vs. symlink farms

unblock 848622 by 134758 thanks On Sun, 2021-08-22 at 11:21:38 +0100, Luca Boccassi wrote: > On Sat, 2021-08-21 at 22:57 +0200, Guillem Jover wrote: > > On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote: > > > The bug is real, nobody doubts that - it has been filed on d

Re: Epoch bump for golang-github-valyala-fasthttp

On Fri, 2021-11-12 at 10:55:26 +0530, Pirate Praveen wrote: > On 12 November 2021 12:38:23 am IST, Guillem Jover wrote: > >The golang-github-valyala-fasthttp package used to have date-based > >release numbers (current Debian version 20160617-2). Upstream has > >since switc

Re: devscripts: wrap-and-sort should default to -ast

On Wed, 2021-02-10 at 11:47:12 +, Phil Morrell wrote: > As a user of -satb, I'd like to point out that the flags are not all > equal. Two of them support a (more objective?) desire that "addition to > a list in line-based VCS should have no deletions". That is -at, whereas > -s is a subjective

Re: Unmet :native dependency error when cross-compiling with dpkg-buildpackage

Hi! On Wed, 2021-12-08 at 15:26:10 +0300, Uladzimir Bely wrote: > The conditions are the following: > Build Architecture: amd64 > Host Architecture: arm64 > The package I'm trying to cross-build is 'u-boot' with some patches. It has > build-time dependency 'swig:native'. But swig from Debian rep

Bug#1002056: ITP: zlib-ng -- optimized zlib compression library

Package: wnpp Severity: wishlist Owner: Guillem Jover X-Debbugs-Cc: debian-devel@lists.debian.org, Mark Brown * Package name: zlib-ng Version : 2.0.5 Upstream Author : zlib-ng Team * URL : http://github.com/zlib-ng/zlib-ng * License : Zlib, Zlib-RFC, CC-BY

Re: The future of src:ntp

On Sun, 2022-01-23 at 15:12:49 -0600, Richard Laager wrote: > On 1/19/22 15:04, Bernhard Schmidt wrote: > > On 19.01.22 20:34, Richard Laager wrote: > > > 2. I create transitional binary packages in src:ntpsec: > I got to thinking about this more. This won't work, because src:ntp is > 1:4.2.8p15+d

Re: The future of src:ntp

On Mon, 2022-01-24 at 08:08:16 +0100, Guillem Jover wrote: > On Sun, 2022-01-23 at 15:12:49 -0600, Richard Laager wrote: > > On 1/19/22 15:04, Bernhard Schmidt wrote: > > > On 19.01.22 20:34, Richard Laager wrote: > > > > 2. I create transitional binary packages

deb-porterbox (was: Re: No mips64el porterbox?)

Hi! On Tue, 2022-03-01 at 10:28:28 +0100, Julien Puydt wrote: > one of my package has a failure on mips64el and upstream is ready to > help me find the cause and debug the issue. > > Unfortunately, on https://db.debian.org/machines.cgi I only see five > developer machines on this architecture --

DKIM and Exim (was Re: Gmail bounce unauthenticated @debian.org addresses)

Hi! On Fri, 2022-03-04 at 14:36:01 +, Colin Watson wrote: > I reproduced a similar problem, then set up DKIM for myself and > everything then worked, so I think you're correct. > > The links in the original d-d-a email were mostly stale, but I found > https://bynicolas.com/server/exim-multi-d

Re: proposed MBF: packages still using source format 1.0

Hi! [ But, this one again… ] On Thu, 2022-03-10 at 18:17:15 +, Steve McIntyre wrote: > Why on earth *would* you mess around using Debian revisions on a > native-format package, though? IMHO it's pointless and is just going > to confuse people. Unless you can explain a good reason to need this

Re: proposed MBF: packages still using source format 1.0

On Thu, 2022-03-10 at 12:09:14 -0700, Sam Hartman wrote: > You're trying to produce packages from CI builds or other automation > where you sometimes have native Debian revisions. > > * you are producing a package where you have distinct upstream and > debian branches, and you cannot control th

Re: proposed MBF: packages still using source format 1.0

Hi! On Tue, 2022-03-15 at 15:36:48 +, Ian Jackson wrote: > However, given that I perceive that: > - there is a campaign to abolish 1.0 > - there are important use cases where 1.0 is needed > - the campaign to abolish 1.0 is being prosecuted anyway > I have deliberately chosen to continue

Re: Epoch bump for gnome-shell-extension-autohidetopbar

Hi! On Mon, 2022-03-28 at 13:21:03 +0200, Tobias Frost wrote: > gnome-shell-extension-autohidetopbar is currently packaged with a date/name > version, eg. > 20209, unfortunatly without a leading 0~... > > I recently agreed [1] with upstream to tag their releases to > match the version as on

Re: Bug#1008304: ITP: http-nio -- http/s file system provider for Java NIO.2

Hi! On Sat, 2022-03-26 at 14:59:17 +0100, Pierre Gruet wrote: > Package: wnpp > Severity: wishlist > Owner: Debian-med team > X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org > > * Package name: http-nio > Version : 0.1.0 > Upstream Author : Daniel Gomez-S

RFC: Additions to dpkg's Pre-Depends

Hi! As per Debian policy §3.5, and given dpkg “Essential: yes” nature, I'm bringing up the following potential additions to dpkg's Pre-Depends, and whether there is consensus about each of them individually and independently. * libmd-dev - Rationale: src:dpkg currently has its embedded MD5

Re: RFC: Additions to dpkg's Pre-Depends

On Wed, 2022-07-06 at 16:45:18 +0200, Andreas Henriksson wrote: > On Wed, Jul 06, 2022 at 05:13:05AM +0200, Guillem Jover wrote: > [...] > > * libaudit-dev > > - Rationale: > > This could allow to add Linux audit support to dpkg on package action > > events

Re: RFC: Additions to dpkg's Pre-Depends

On Wed, 2022-07-06 at 17:30:22 +0200, Guillem Jover wrote: > > Unless I'm mistaken if dpkg dep on libcap(2) and libaudit, then dpkg > > would transitively dep on both libcap(2) and libcap-ng which seems > > suboptimal. > > Yes, but its an internal implementation

Re: Bug#1013992: ITP: session-migration -- tool to migrate in user session settings

On Tue, 2022-06-28 at 21:51:44 -0400, Jeremy Bicha wrote: > On Tue, Jun 28, 2022 at 8:07 PM Guillem Jover wrote: > > > Package: session-migration > > > Description: Tool to migrate in user session settings > > > This tool is used to migrate in session user data whe

RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)

Hi! There's been talk about switching away from netkit-telnet and netkit-telnetd as the default implementations for some time now, and replacing them with the ones from inetutils, which is a maintained project and does see releases (even though with a long cadence). This has been discussed someho

Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)

Hi! On Sun, 2022-07-17 at 04:18:59 +0200, Guillem Jover wrote: > There's been talk about switching away from netkit-telnet and > netkit-telnetd as the default implementations for some time now, > and replacing them with the ones from inetutils, which is a maintained > pro

Re: RFC: Additions to dpkg's Pre-Depends

Hi! On Wed, 2022-07-06 at 05:13:05 +0200, Guillem Jover wrote: > As per Debian policy §3.5, and given dpkg “Essential: yes” nature, I'm > bringing up the following potential additions to dpkg's Pre-Depends, > and whether there is consensus about each of them individually

Re: Done: Switch default from netkit-telnet(d) to inetutils-telnet(d)

Hi! On Sun, 2022-07-17 at 04:18:59 +0200, Guillem Jover wrote: > There's been talk about switching away from netkit-telnet and > netkit-telnetd as the default implementations for some time now, > and replacing them with the ones from inetutils, which is a maintained > pro

Re: Automatic trimming of changelogs in binary packages

Hi! On Thu, 2022-08-18 at 21:18:35 +0200, Gioele Barabucci wrote: > in 2020 there was a brief discussion on debian-devel@ about trimming > changelogs [1,2]. My objections from that time still stand: I would also like to highlight D

Re: Transition proposal: pkg-config to pkgconf

Hi! On Mon, 2022-08-29 at 15:38:08 +0200, Andrej Shadura wrote: > It seems like the proposal went mostly unnoticed. Any comments, > ideas, anything? I at least read it, and it looked great. But… > Most importantly, I need a green light from the current pkg-config > maintainer (Tollef) to proceed

Re: packages expected to fail on some archs

Hi! [ Mostly to summarize the status re dpkg. ] On Sun, 2022-09-11 at 17:08:57 +0200, Samuel Thibault wrote: > The issue we see is that some DDs end up setting a hardcoded list in > the "Architecture" field, rather than just letting builds keep failing > on these archs (and then possibly succeedi

Re: R³ by default: not for bookworm

Hi! On Sun, 2022-09-18 at 03:39:43 +0200, Adam Borowski wrote: > A few packages had a value of R³ other than "no" / "binary-targets", > these are deprecated now; bugs filed. Deprecated by who or what? > The process of adding/changing a field in "control" differs between the > three source format

Re: Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions

Hi! On Wed, 2022-12-14 at 15:27:18 +0100, Juri Grabowski wrote: > Package: wnpp > Version: 1.79 > Severity: wishlist > Owner: Juri Grabowski > X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@jugra.de > * Package name: distribution-gpg-keys > Version : 1.7.9 > Upstream Author

Re: Please, minimize your build chroots

On Fri, 2022-12-16 at 18:55:42 +0100, Andreas Metzler wrote: > or apt. > > I am wondering if there is point to this or whether policy should be > changed? Is there some value in investing work in having packages > buildable without Prioriry required packages? > > Such installations can only be fo

Re: depends-on-obsolete-package lsb-base

On Wed, 2023-01-18 at 18:23:16 +0100, Adam Borowski wrote: > On Wed, Jan 18, 2023 at 08:19:15AM -0800, Otto Kekäläinen wrote: > > Lintian just started erroring on 'depends-on-obsolete-package > > lsb-base' on many of my packages yesterday. > > It's a very low priority cleanup; the Depends is redun

Re: Please, minimize your build chroots

On Sat, 2023-01-28 at 16:32:17 +0100, Adam Borowski wrote: > On Sat, Jan 28, 2023 at 01:59:40PM +0100, Santiago Vila wrote: > > Unsupported by whom? What is supported or unsupported is explained in > > policy. > > Policy says it must work. Therefore it should be supported (by fixing the > > bugs)

Re: Please, minimize your build chroots

On Sat, 2023-01-28 at 21:35:01 +0200, Adrian Bunk wrote: > I don't think such arguments are bringing us forward, > we should rather resolve the problem that these differ. > > All/Most(?) packages where they do differ are packages that were until > recently part of the essential set, and since deb

Re: Please, minimize your build chroots

On Sun, 2023-01-29 at 12:28:37 +0200, Adrian Bunk wrote: > On Sun, Jan 29, 2023 at 05:00:56AM +0100, Guillem Jover wrote: > > On Sat, 2023-01-28 at 21:35:01 +0200, Adrian Bunk wrote: > > > Removing tzdata from the essential set made sense, and I do see your > > > poi

Re: -ffile-prefix-map option and reproducibility

Hi! On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: > When building packages, a -ffile-prefix-map option is automatically injected > into CFLAGS. Where does it come from? Since when? This is coming from dpkg-buildflags (in this case probably indirectly via debhelper). AFAICS it was a

Re: -ffile-prefix-map option and reproducibility

On Tue, 2023-02-07 at 20:00:06 +0100, Sven Joachim wrote: > On 2023-02-07 17:50 +0100, Guillem Jover wrote: > > On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: > >> I suspect this was added to improve reproducibility. Ironically, it makes > >> packages tha

Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support

Hi! On Wed, Feb 15, 2023, at 7:51 PM, Fabian Grünbichler wrote: > debcargo, the tool used by the Debian rust team to streamline the work > of transforming upstream crates into Debian source packages generates > d/control entries for librust-* binary packages qualified as arch:any > and M-A:same, i

Re: Problems verifying signed github releases (Re: Q: uscan with GitHub)

Hi! On Sun, 2023-02-19 at 18:34:56 +0100, Jens Reyer wrote: > [This is a followup to the thread "Q: uscan with GitHub" at > https://lists.debian.org/debian-devel/2022/10/msg00313.html. I manually set > in-reply-to, but am not sure if it'll work.] > My upstream creates a tarball with git-archive,

Re: Dropping debpkg from devscripts (in trixie)

Hi! On Mon, 2023-03-20 at 12:54:18 +, Benjamin Drung wrote: > README for debpkg in devscripts says: "debpkg: A wrapper for dpkg used > by debi to allow convenient testing of packages. For debpkg to work, it > needs to be made setuid root, and this needs to be performed by the > sysadmin -- it

Re: Possible doc package side-effect from going source-only upload

Hi! On Thu, 2019-09-19 at 07:15:43 -0500, Dirk Eddelbuettel wrote: > So presumably the dependency graph within debian/rules is wrong. Would > anybody here know > > - either a failsafe idiom forcing the right thing to happen > - or a more efficient way > > to ensure the binary-arch is built

Re: domain-specific names for source packages

Hi! On Tue, 2019-10-22 at 20:05:28 +0200, Jonas Smedegaard wrote: > Let us please all name new source package same as main binary package > (not same as upstream project). I'm not sure, as is, this is a good general rule. I'd reword as, we should always namespace source packages appropriately, r

Re: should all bug reports be filed against /source/ packages?

Hi! On Wed, 2019-10-23 at 08:32:11 +0200, Ansgar wrote: > the thread about naming (source) packages reminded me of an other thing: > Debian's bug tracking system currently (mostly) tracks bugs against > binary packages and (less often) against source packages. > It gets confused if a source & bin

Re: TZ=UTC wrong?

Hi! On Wed, 2019-10-30 at 13:09:33 +, Colin Watson wrote: > First, is this a distinction with a meaningful difference worth spending > the time on changing it? Depends, I guess. See below. > Second, it is not correct to say that the format requires an offset. > Referring to timezone(3), the

Re: Facilitating external repositories

On Sun, 2019-11-03 at 11:04:01 -0800, Russ Allbery wrote: > Timo Weingärtner writes: > > Please don't use /etc/apt/trusted* for 3rd-party repositories. If a key > > is in there its owner can impersonate the official debian repos for > > default setups.¹ Please use some other path (such as > > /var

Re: Summary: Git Packaging: Native source formats

(Even though it was not clear in the initial mail, I'm assuming this is about using native format 1.0 with non-native versions.) On Fri, 2019-08-30 at 12:57:56 -0400, Sam Hartman wrote: > My take away from this discussion though is that using a native package > format even when there are upstream

Re: Git Packaging Round 2: When to Salsa

On Sun, 2019-09-15 at 12:23:48 +0200, Marc Haber wrote: > On Sun, 15 Sep 2019 00:04:14 +0200, Guillem Jover wrote: > > I think the common prefixes for these are pu/ and next/? These are > > also documented somehow in the gitworkflows(7) man page. > > The definition of t

Re: Summary: Git Packaging: Native source formats

On Tue, 2019-11-05 at 02:34:13 +0100, Guillem Jover wrote: > I'm planning to add warnings for 1.0 formats when using a version that > does not match the type of tarball found. Ideally 1.0 formats would > error out in the same way 3.0 do, but this is impractical, and I guess > w

dpkg sysusers and file metadata (was Re: Integration with systemd)

Hi! On Fri, 2019-11-01 at 11:36:19 +, Simon McVittie wrote: > On Thu, 31 Oct 2019 at 17:51:28 -0700, Russ Allbery wrote: > > I think we should adopt sysusers.d fragments as the preferred mechanism > > for creating system users > > I have been tempted to write a small reimplementation of syste

Re: Git Packaging Round 2: When to Salsa

Hi! On Wed, 2019-11-06 at 12:43:58 +, Simon McVittie wrote: > On Tue, 05 Nov 2019 at 02:41:29 +0100, Guillem Jover wrote: > > It does, it's specifically mentioned as a branch that will be > > rewinded. See the “Branch management for next and pu after a feature

Bug#944629: RFP: libcatalyst-plugin-session-store-redis-perl -- Redis Session store for Catalyst

Package: wnpp Severity: wishlist Tags: patch * Package name: libcatalyst-plugin-session-store-redis-perl Version : 0.09 Upstream Author : Thomas Klausner * URL : https://metacpan.org/release/Catalyst-Plugin-Session-Store-Redis * License : Artistic or GPL-1+

Re: d/changelog and experimental

Hi! On Tue, 2019-12-03 at 08:15:19 +0100, Paolo Greppi wrote: > What is the best approach for d/changelog when releasing a package > to unstable after it has been through a few iterations to experimental ? > > It would seem that the right thing to do is to keep all experimental > changelog entries

Re: Is running dpkg-buildpackage manually from the command line forbidden?

On Fri, 2020-01-17 at 11:12:50 +0100, Ansgar wrote: > Johannes Schauer writes: > > My advice would also be to switch from debootstrap to mmdebstrap because the > > latter is able to create a chroot with only Essential:yes packages in it > > while > > debootstrap includes Priority:required packages

Re: Y2038 - best way forward in Debian?

Hi! On Tue, 2020-02-04 at 13:14:10 +, Steve McIntyre wrote: > The glibc folks have taken an interesting approach. > > * 64-bit ABIs/architectures are already using 64-bit time_t >throughout. The design is sane and so we should already be mostly >safe here, modulo silly code bugs (we'

Re: Y2038 - best way forward in Debian?

On Wed, 2020-02-05 at 15:35:28 +0100, Ansgar wrote: > On Wed, 2020-02-05 at 08:33 -0500, Sam Hartman wrote: > > Steve, you're presuming that we would not create a new soname for > > libc6 on architectures where we want a new time ABI. > > Isn't the libc ABI for some reason part of Debian's archite

<    2   3   4   5   6   7   8   9   10   >