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'd r

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 two t

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 by adding

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

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

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

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

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

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

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

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

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 >

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

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. > G

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

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

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

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

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 breaking

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

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

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 packages I

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

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 +

Re: Policy consensus on transition when removing initscripts.

On Tue, 2023-06-27 at 21:05:57 -0700, Russ Allbery wrote: > Simon Richter writes: > > On 6/28/23 02:31, Russ Allbery wrote: > >> Normally Conflicts is always added with Replaces because otherwise you can > >> have the following situation: > > >> * Package A version 1.0-1 is installed providing

Re: 64-bit time_t transition for 32-bit archs: a proposal

at can be cleaned up lazily > > What do you think? Yeah, sounds good to me. > On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote: > > On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote: > > > > Hmm, rechecking the script, I think we'd want to at least > &

Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy

Hi! On Sat, 2023-06-17 at 11:39:51 +0200, Étienne Mollier wrote: > Martin-Éric Racine, on 2023-06-16: > > Someone filed a bug asking to re-introduce an epoch. > > > > An older fork of the same package back in Wheezy last featured the epoch. > > > > Personally, I'm fine with either marking the

Re: 64-bit time_t transition for 32-bit archs: a proposal

Hi! On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote: > On Fri, May 19, 2023 at 05:34:56AM +0200, Guillem Jover wrote: > > Enabling time64 explicitly is what also had first come to my mind, > > which does not seem too onerous if all the debhelper override > > di

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

Hi! On Fri, 2023-05-19 at 12:42:32 +0100, Steve McIntyre wrote: > Guillem Jover wrote: > >On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote: > >> > […], I'm also dubious about this, and introduces a special case > >> > and complexity that does not seem wa

Re: 64-bit time_t transition for 32-bit archs: a proposal

On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote: > On Thu, May 18, 2023 at 03:04:30AM +0200, Guillem Jover wrote: > > On Tue, 2023-05-16 at 21:04:10 -0700, Steve Langasek wrote: > > > === Technical details === > > > > The proposed implementation of

Re: 64-bit time_t transition for 32-bit archs: a proposal

Hi! On Tue, 2023-05-16 at 21:04:10 -0700, Steve Langasek wrote: > === Technical details === > > The proposed implementation of this transition is as follows: > > * Update dpkg-buildflags to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 > by default on 32-bit archs.  (Note that this enables

Re: RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.)

Hi! On Tue, 2023-04-18 at 17:54:20 -0500, G. Branden Robinson wrote: > At 2023-04-18T16:07:45+0200, Florian Weimer wrote: > > TL;DR: I want to propose a GCC 14 change which will impact > > distributions, so I'd like to gather some feedback from Debian. > > I would appreciate some discussion on

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

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

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

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

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

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

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

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

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

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

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

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

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 and > i

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

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

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

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 d

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

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

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

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

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

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 >

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

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 packag

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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/o req

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

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

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

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

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: 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: 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: 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 (!)

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

  1   2   3   4   5   6   7   8   9   10   >