Re: Need maintainer guide for debugging on i386

On Thu, May 01, 2025 at 12:28:10PM +, Mathias Gibbens wrote: > On Mon, 2025-04-21 at 13:12 +0200, Bastien Roucaries wrote: > > Now we could not install on i386, we need a wiki page for how to > > debug quickly on i386 > > It's easy to setup an i386 container with Incus, which is how I've > b

Re: Do we need a conflict of interest policy?

I'm a bit dubious about a ChatGPT authored Conflict of Interest (COI) policy because most of them that you will find on-line, and thus what a Large Language Model (LLM) will regurgitate, are meant for orgaizations where you have a small body of people who vote. So for example, if you serve on the

Re: What is going on with atomics?

A question about --as-needed as an upstream developer who wants to care about more than just Debian or Linux. Am I correct in assuming this will work on any system using GNU binutils? And it doesn't matter whether you are using gcc, clang, etc. What about other OS's such as *BSD, MacOS, etc.? I

Re: write the fine manual (was Re: Removing manpages from libpam-modules to improve multi-arch)

On Wed, Jan 15, 2025 at 06:03:42PM -0600, G. Branden Robinson wrote: > I've saved the worst for last. > > That is of course docbook-to-man. Ingo and I both find the quality of > its output to be execrable. It has been unmaintained for many years and > consistently seems to burn out and drive fro

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

On Thu, Dec 26, 2024 at 01:19:34PM -0500, Michael Stone wrote: > Further reading: look at the auto_da_alloc option in ext4. Note that it says > that doing the rename without the sync is wrong, but there's now a heuristic > in ext4 that tries to insert an implicit sync when that anti-pattern is used

Re: Directory structure suggestion for configuration in /etc

On Sat, Dec 21, 2024 at 04:38:46PM -0800, Josh Triplett wrote: > On Fri, Dec 20, 2024 at 08:37:33AM -0600, rhys wrote: > > > > > > > Right now, the model we have is "some packages use the empty /etc model, > > > some packages install commented-out defaults, and there's no > > > consistency". I'd

Re: Musings about Usernames in adduser and Debian

On Tue, Dec 10, 2024 at 09:24:15PM +0100, Marc Haber wrote: > > But things are moving by shadow upstream taking a user-hostile stance, > willing to take away freedom. I must be fine with that because I > cannot change it. But I don't need to like it. As a suggestion, we might make more forward pr

Re: Musings about Usernames in adduser and Debian

On Tue, Dec 10, 2024 at 06:08:40PM +0100, Simon Josefsson wrote: > I would involve cross-distribution discussion about this though. > Perhaps the /etc/passwd APIs affect some POSIX specifications, and a > non-ASCII extension could be proposed. Yeah, good point. If the scope is going to include pa

Re: Musings about Usernames in adduser and Debian

On Tue, Dec 10, 2024 at 02:52:05PM +0100, Gioele Barabucci wrote: > NFC has been mentioned in a broader discussion on PRECIS/RFC8264/RFC8265. > > The IdentifierClass of RFC 8264 explicitly disallows all these "security > land mines": https://www.rfc-editor.org/rfc/rfc8264.html#section-4.2.3 > > T

Re: Musings about Usernames in adduser and Debian

On Tue, Dec 03, 2024 at 09:39:03PM +0100, Gioele Barabucci wrote: > NFC would solve both of these "problems": > > * Both U+00E9 (é) and U+0065, U+0301 are NFC-normalized to U+00E9, > * Both U+2126 (Ohm sign) and U+0349 (omega) are NFC-normalized to U+0349 > (omega). > > What NFC alone will not so

Re: Should l10n packages be Recommends or Suggests?

On Thu, Dec 05, 2024 at 01:02:29PM -0800, Josh Triplett wrote: > Personally, I am quite sympathetic to the argument about wasting disk > space, and I care about the size of the base system myself. But I think > the primary affordance we make for such use cases is for core system > packages to have

Re: Should l10n packages be Recommends or Suggests?

On Thu, Dec 05, 2024 at 08:55:35PM +0100, Roland Clobus wrote: > > How about adding the translations to the main package e2fsprogs, and let the > package 'localepurge' remove them? For people who care about installed size, > that package helps to remove undesired translation files. (Although all >

Re: Should l10n packages be Recommends or Suggests?

On Thu, Dec 05, 2024 at 09:28:34AM -0800, Josh Triplett wrote: > There are a variety of reasons people don't want a package installed. > For packages that run a service or affects how the system behaves or > similar, it's much more debatable whether to install them by default, > even if doing so ma

Should l10n packages be Recommends or Suggests?

Currently e2fsprogs recommends e2fsprogs-l10n. In Debian Policy, it states: This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. It seems to me that po translation f

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

On Sat, Nov 30, 2024 at 03:28:40AM +0100, наб wrote: > I was expecting src:fuse-umfuse-ext2 to clear the RM queue by the time > this was uploaded, so I didn't think to enumerate them earlier. > > Tested all, all fixed, closed all. Many thanks for testing them and then closing them all. That was

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

On Thu, Oct 24, 2024 at 05:37:59PM +0200, наб wrote: > > idk if you got a notification (the confirmation mail would indicate > otherwise?), but the patch is at #1085590. I've tested it to behave > the same as the real fuseext2 and it upgrades smoothly. I've uploaded e2fsprogs 1.47.2~rc1-1 to unss

Re: Simpler git workflow for packaging with upstreamless repositories

On Thu, Nov 28, 2024 at 10:35:49AM +0100, Simon Josefsson wrote: > > I think this is a good example of us talking past each other in this > thread: some people question the value of pristine in the first place > (and I've been compelled by those arguments), and some people argue that > the cost is

Re: Simpler git workflow for packaging with upstreamless repositories

commit 91c7ab39337da63371b4814bef2b2aaf85a9e37c (origin/pristine-tar, pristine-tar) Author: Theodore Ts'o Date: Mon May 20 23:12:54 2024 -0400 pristine-tar data for e2fsprogs_1.47.1.orig.tar.gz e2fsprogs_1.47.1.orig.tar.gz.asc | 11 +++ e2fsprogs_1.47.1.orig.tar.gz.delta | Bin 0 -> 63961 bytes e2

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

On Thu, Nov 07, 2024 at 12:08:22AM -0700, Soren Stoutner wrote: > On Wednesday, November 6, 2024 10:41:46 PM MST Aaron Rainbolt wrote: > > Again, this isn't a problem limited to a derivative distribution. I > > respect that your opinion of how Recommends should work differs from > > mine. That does

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

On Thu, Oct 24, 2024 at 02:13:05PM +0200, наб wrote: > > I've implemented this but can't test it fully because > https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git > is missing an up-to-date pristine-tar > (it's at 1.47.0 so it looks like you just forgot to push?). Yes, that combined to some

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

On Tue, Oct 22, 2024 at 04:56:05PM +0200, наб wrote: > > ...but now that I look at this there's fuse2fs, > which is naturally better than some third-party implementation. > > The interface is a little different > (the default is -o rw instead of -s -o ro,allow_other,default_permissions) > so this

Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?

On Fri, Aug 23, 2024 at 03:08:11PM +0200, Marco d'Itri wrote: > > Salsa CI?) > The effort needed to do so is so small that the question really should > be "why should I NOT spend a few seconds enabling Salsa CI?". > > > 3) What's the simple recipe for enable Salsa CI? > salsa update_projects $NA

Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?

On Tue, Aug 20, 2024 at 06:35:52PM -0700, Otto Kekäläinen wrote: > > In short: > I would very much like to see all top-150 packages run Salsa CI at > least once before being uploaded to unstable. What people think is a > reasonable way to proceed to reach this goal? Since I'm the e2fsprogs (one o

Re: De-vendoring gnulib in Debian packages

On Sun, May 12, 2024 at 04:27:06PM +0200, Simon Josefsson wrote: > Going into detail, you use 'gzip -9n' but I use git-archive defaults > which is the same as -n aka --no-name. I agree adding -9 aka --best is > an improvement. Gnulib's maint.mk also add --rsyncable, would you agree > that this is

Re: De-vendoring gnulib in Debian packages

On Sat, May 11, 2024 at 04:09:23PM +0200, Simon Josefsson wrote: >The current approach of running autoreconf -fi is based on a >misunderstanding: autoreconf -fi is documented to not replace certain >files with newer versions: >https://lists.nongnu.org/archive/html/bug-gnulib/2024-04

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

On Thu, Apr 11, 2024 at 03:37:46PM +0100, Colin Watson wrote: > > When was the last time this actually happened to you? I certainly > remember it being a problem in the early 2.5x days, but it's been well > over a decade since this actually bit me. I'd have to go through git archives, but I beli

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

On Sat, Apr 06, 2024 at 04:30:44PM +0100, Simon McVittie wrote: > > But, it is conventional for Autotools projects to ship the generated > ./configure script *as well* (for example this is what `make dist` > outputs), to allow the project to be compiled on systems that do not > have the complete A

Re: xz backdoor

On Mon, Apr 01, 2024 at 04:47:05PM +0100, Colin Watson wrote: > On Mon, Apr 01, 2024 at 08:13:58AM -0700, Russ Allbery wrote: > > Bastian Blank writes: > > > I don't understand what you are trying to say. If we add a hard check > > > to lintian for m4/*, set it to auto-reject, then it is fully ir

Re: Validating tarballs against git repositories

On Mon, Apr 01, 2024 at 06:36:30PM +0200, Vincent Bernat wrote: > > I think that if Debian was using git instead of the generated tarball, this > part of the backdoor would have just been included in the git repository as > well. If we were able to magically switch everything to git (and we won't,

Re: Validating tarballs against git repositories

On Sat, Mar 30, 2024 at 08:44:36AM -0700, Russ Allbery wrote: > Luca Boccassi writes: > > > In the end, massaged tarballs were needed to avoid rerunning autoconfery > > on twelve thousands different proprietary and non-proprietary Unix > > variants, back in the day. In 2024, we do dh_autoreconf b

Re: 64-bit time_t transition in progress in unstable

On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote: > > Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I > actually would expect unstable to be dist-upgradeable on non-32-bit archs: > either the existing non-t64 library will be kept installed because nothing

Re: Policy: should libraries depend on services (daemons) that they can speak to?

On Mon, Jan 08, 2024 at 11:18:09AM +, Simon McVittie wrote: > On Mon, 08 Jan 2024 at 08:21:08 -, Sune Vuorela wrote: > > Maybe the question is also a bit .. "it depends". > ... > > So that users actually likely get a system that works? > > I think the fact that we argue about this every fe

Re: Linking coreutils against OpenSSL

On Sat, Nov 11, 2023 at 09:32:46AM +0200, Julian Andres Klode wrote: > > WRT dlopen(), this is never an appealing solution because you do not > get any type-checking, you have to make sourceful changes for an soname > bump. It is an interface you can use for loading plugins (that is, you > should

Re: Linking coreutils against OpenSSL

On Thu, Nov 09, 2023 at 11:13:51PM +, Luca Boccassi wrote: > > Alternatively, what would you think about making sha256sum etc. > > divertible and providing implementations both with and without the > > OpenSSL dependency? > > Please, no, no more diversion/alternatives/shenanigans, it's just hu

Re: lpr/lpd

On Fri, Sep 22, 2023 at 11:07:39PM +0900, Simon Richter wrote: > Yes and no. We're providing a better service than pulling the rug under the > users, but we could do better by communicating that these packages are in > need of new maintainers instead of waiting for them to bit-rot to a point > wher

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

On Tue, Aug 08, 2023 at 10:26:09AM +0200, Helmut Grohne wrote: > As a minor data point, I also do not rely on `debian/rules clean` to > work for reproducing the original source tree, because too many packages > fail it. > > Let me point out though that moving to git-based packaging is not the > pr

Re: snapshot.d.o has been in a bad state for several months

On Wed, Aug 09, 2023 at 08:31:09AM +0200, Bjørn Mork wrote: > "Theodore Ts'o" writes: > > > I was curious about this, since I rely on snapshots.debian.org in > > order to create repeatable builds for a file system test appliance, so > > I started digging a

Re: snapshot.d.o has been in a bad state for several months

On Wed, Aug 02, 2023 at 01:33:11PM +0200, Johannes Schauer Marin Rodrigues wrote: > Hi, > > snapshot.debian.org is getting worse again. There is not a single snapshot for > August yet and the last days of July are spotty: > > http://snapshot.debian.org/archive/debian/?year=2023&month=7 > > None

Re: /usr-merge: continuous archive analysis

On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > ## No good solution for bookworm-backports > > There is one major issue where I don't have a good answer: > bookworm-backports. When this originally surfaced, Luca Boccassi > suggested that we do not canonicalize in backports. That's

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

On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote: > > I would be VERY disappointed if Debian would abandon people who do NOT have > the means to just buy new equipment whenever they feel like it. Debian is a Do-ocracy. Which is to say, it's a volunteer project. People work on wh

Re: Consultation on license documents

On Fri, Mar 17, 2023 at 09:09:22PM +0800, 刘涛 wrote: > Hello, I have the following questions to consult and look forward to your > authoritative answers. > > 1. Must various software packages in the Debian community contain a > license file "license.txt"? Without this file, how does the users > kn

Re: Help trying to debug an sbuild failure?

On Wed, Dec 28, 2022 at 12:10:51AM +0100, Johannes Schauer Marin Rodrigues wrote: > Note, that if you keep upgrading a Debian unstable chroot across multiple > releases, it will end up looking slightly different than a freshly > debootstrapped Debian unstable chroot. So I think there is value in >

Re: Help trying to debug an sbuild failure?

On Mon, Dec 26, 2022 at 08:45:53PM +0100, Santiago Vila wrote: > El 26/12/22 a las 20:29, Theodore Ts'o escribió: > > I: The directory does not exist inside the chroot. > > This is really a problem with schroot. I guess that this will not work either: > > schroot -c

Help trying to debug an sbuild failure?

Hi, I'm trying to figure out an sbuild failure on my laptop. The sbuild environment from replicated from my desktop where things work perfectly well. But in my laptop, things are failing at the "Setup apt archive" step with E: Failed to change to directory ‘/<>’: Permission denied And I'm c

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

On Fri, Oct 14, 2022 at 03:37:29PM +0200, Marco d'Itri wrote: > On Oct 14, Vincent Lefevre wrote: > > > > This is obviously convenient on Guillem's part, but we have to optimize > > > systems by default for the general case and not just for dpkg -i. > > This dpkg FAQ says that this is not benefi

Re: Bug email is not getting to me

On Sun, Sep 25, 2022 at 07:00:38PM -0700, Russ Allbery wrote: > Steven Robbins writes: > > On Sunday, September 25, 2022 4:57:19 P.M. CDT Russ Allbery wrote: > > >> If someone sends mail from a domain that says all mail from that domain > >> will always have good DKIM signatures, and if the signa

Re: Firmware - what are we going to do about it?

On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote: > FWIW, as a 10+ years user (first time caller :p) I strongly support > sticking with the status quo. There are plenty of systems that don't > require firmware to work, and often when people say it doesn't "work" > they really mean that its fun

Re: NEW processing friction

On Mon, Feb 07, 2022 at 07:05:59PM -0700, Sean Whitton wrote: > Hello, > > On Mon 07 Feb 2022 at 12:00PM -05, Theodore Ts'o wrote: > > > On Mon, Feb 07, 2022 at 12:06:24AM -0700, Sean Whitton wrote: > >> > >> When we treat any of the above just like oth

Re: NEW processing friction

On Mon, Feb 07, 2022 at 12:06:24AM -0700, Sean Whitton wrote: > > When we treat any of the above just like other RC bugs, we are accepting > a lower likelihood that the bugs will be found, and also that they will > be fixed Another part of this discussion which shouldn't be lost is the probab

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

On Fri, Jan 21, 2022 at 01:28:54PM -0500, Scott Kitterman wrote: > > 1. When the SO name changes and the binary package name is adjusted > accordingly, it is not super rare for the maintainer to mess something up in > the renaming and end up with an empty binary package, which does no one any

Re: dpkg taking a bit too long ...

On Tue, Oct 05, 2021 at 04:09:12PM +0200, Jonathan Carter wrote: > real 0m37.751s > user 0m7.428s > sys 0m12.374s > > That's on ext4/nvme with no eatmydata. Perhaps time to perform a smart test > on your disk? Except Norbert was reporting 100% (and 15 minutes) of CPU time Norbert, what f

Re: next steps after usrmerge

On Fri, Aug 27, 2021 at 07:34:06PM +0200, Bastien ROUCARIES wrote: > > See the proposal here of guillem: > https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking This proposal doesn't directly address usrmerge, and the fact that new Debian installs have been installing systems with top-level sy

Re: next steps after usrunmess

On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote: > > - reverting the changes in deboostrap in sid, bullseye (and ideally > > in buster too), > > - reverting the notion that split-/usr is unsupported (which includes > > the extremely confusing interpretation about this apply

Re: Debian choice of upstream tarballs for packaging

On Wed, Aug 25, 2021 at 04:11:37PM +0200, Thomas Goirand wrote: > > It's been *years* since I encounter a PyPi package that doesn't have a > Git repo as its homepage (and unfortunately, 99% on Github). > > I wrote this many times, but I don't see why we should use any "upstream > tarball" when th

Re: Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms)

On Tue, Aug 24, 2021 at 11:57:27AM +0200, Simon Richter wrote: > Hi, > > On 8/24/21 2:48 AM, Theodore Ts'o wrote: > > > So in theory, if we had a program which looked for the top-level > > symlinks /{bin,lib,sbin} -> /usr/{bin,lib,sbin}, and if they exist, &g

Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms)

I want to ask a potentially stupid question. As I understand things, the problem is that in a usrmerge'd file system where we have the top-level symlinks /{bin,lib,sbin} which point at /usr/{bin,lib,sbin}, the problem is if we have a package which contains the file in /sbin/blart, it gets installe

Re: merged /usr vs. symlink farms

On Sun, Aug 22, 2021 at 12:26:46PM +0200, David Kalnischkies wrote: > > So, when did you last log into your build chroot to upgrade dpkg and > apt first? And while at that, did you follow the release notes – from > the future, as they have yet to be written for the release you are > arguably upgra

Re: merged-/usr vs. partially-symlink-farmed-root

On Sun, Aug 22, 2021 at 10:24:56PM +0100, Luca Boccassi wrote: > The point of the migration is that /usr/bin will be identical to /bin, > etc. If they are not identical, then it's not usrmerge as it is > understood and has been adopted by many upstreams for a decade, it's > something else that is i

Re: merged /usr vs. symlink farms

On Sun, Aug 22, 2021 at 02:15:31AM +0200, Simon Richter wrote: > > The latter is what brought us into a situation where it is no longer safe to > move files between packages and between aliased directories in the same > upgrade, and because users will be expected to upgrade in a single step > betw

Re: merged /usr vs. symlink farms

On Sat, Aug 21, 2021 at 10:26:13AM +0200, Wouter Verhelst wrote: > It bothers me that you believe "we've been doing this for a while and it > didn't cause any problems, so let's just continue doing things that way > even if the people who actually wrote the damn code say that path is > littered wit

Re: merged /usr vs. symlink farms

On Fri, Aug 20, 2021 at 07:56:33AM -0600, Sam Hartman wrote: > As you know, one of the ways we can see how close we are on consensus > is to look at what happens when someone proposes a summary like you did. Thanks, that was my goal: trying to see if we could move the discussion towards some kind

Re: merged /usr vs. symlink farms

On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote: > > I think no one likes that idea, but it's the only solution that doesn't > immediately fail because it requires a dpkg update that hasn't shipped with > the current stable release, breaks local packages (kernel modules, firmware, >

Re: merged /usr vs. symlink farms

On Thu, Aug 19, 2021 at 11:17:17AM +0100, Simon McVittie wrote: > In this specific case, I think the thing you're having a problem with is > the gradual, file-by-file migration of executables into /usr by individual > packages and individual packages' maintainers. That's not merged-/usr: > merged-/

Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system

On Thu, Aug 19, 2021 at 11:46:21AM +0200, Michael Biebl wrote: > Am 19.08.21 um 08:27 schrieb Michael Biebl: > > I'll check later today, if i-s-h (init-system-helpers) does properly > > handle this new path. If so, I'd say the bug should be reassigned to > > lintian and we should start transitionin

WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system

There appears to be a rather major regression in debhelper 1.13.4 and 1.13.4nmu1, which is forcing unit files to go in /usr/lib/systemd/system, instead of /lib/systemd/systemd (where sytemd will actually pay attention to them). On systems with ursmerge, things should still work, thanks to the comp

Re: A summary of where I think we are on the technical side of the merged /usr discussion

Simon, Thanks so much for your comprehensive answer. It's a great summary that I think would be really useful for those of us who are package maintainers who don't have a strong position one way or another vis-a-vis usrmerge vs merged-/usr-via-symlink-farms, but just want to do what is best for o

Re: A summary of where I think we are on the technical side of the merged /usr discussion

On Tue, Aug 17, 2021 at 05:19:06PM +0100, Simon McVittie wrote: > On Tue, 17 Aug 2021 at 08:08:15 -0600, Sam Hartman wrote: > > In order to build packages that work on a non-usrmerge system, you need > > a build chroot that is not usrmerge. > > Well. That's not 100% true: it's more accurate to say

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

On Wed, Aug 11, 2021 at 04:08:13PM +0200, Vincent Bernat wrote: > I think we have more systemic issues. I am quite impressed how Nix/NixOS > is able to pull so many packages and modules with so few people. But > they use only one workflow, one way to package, one init system, etc. > Looking at Arch

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

On Mon, Apr 19, 2021 at 02:05:20PM +0100, Jonathan Dowland wrote: > On Mon, Apr 19, 2021 at 11:30:48AM +0800, Benda Xu wrote: > > The winning option "Debian will not issue a public statement on this > > issue" implies that the majority of DDs is not interested in such > > non-technical affairs. >

Re: freeipa is in trouble for the next release (again)

On Wed, Mar 24, 2021 at 12:33:53PM +0100, Harald Dunkel wrote: > On 3/24/21 11:05 AM, Andrey Rahmatullin wrote: > > On Wed, Mar 24, 2021 at 10:02:37AM +0100, Harald Dunkel wrote: > > > For my own part, I run freeipa-server on CentOS 7. I am not affected > > > by #970880. I would be very happy with

Re: Making Debian available

On Fri, Jan 15, 2021 at 09:35:01AM -0800, Russ Allbery wrote: > > The point is to make things easier for our users. Right now, we're doing > that for you but not for the users who don't care whether firmware is > non-free. I think the idea is that we should consider making things > easier for bo

Re: Is it the job of Lintian to push an agenda?

On Sun, Jul 14, 2019 at 11:10:36AM -0300, Chris Lamb wrote: > Theodore Ts'o wrote: > > > P.S. I'm going to be adding an override in e2fsprogs for > > package-supports-alternative-init-but-no-init.d-script because it > > has false positives > > Regard

Re: systemd services that are not equivalent to LSB init scripts

On Sun, Jul 14, 2019 at 07:23:31PM +0100, Simon McVittie wrote: > micro-httpd appears to be an example of this - I'm a bit surprised > there aren't more. Perhaps this indicates limitations in the infrastructure > around inetd services making it hard to implement "use systemd.socket(5) > under syste

Re: How to adopt a dead package?

On Sun, Jul 14, 2019 at 02:34:50PM -0400, Perry E. Metzger wrote: > On Sun, 14 Jul 2019 23:11:46 +0500 Andrey Rahmatullin > wrote: > > > If I wanted to adopt the package and get it back into Debian, what > > > would I need to do? I haven't been a package maintainer before. I > > > presume there's

Re: libfuse3-dev is a virtual package?

On Sun, Jul 14, 2019 at 07:12:59PM +0200, Sven Joachim wrote: > This can happen if you have assigned a negative Pin-Priority to > libfuse3-dev. According to apt_preferences(5), a Priority < 0 "prevents > the version from being installed", and apparently apt achieves this by > pretending that the p

libfuse3-dev is a virtual package?

So this is weird. I can't install libfuse3-dev on my buster system: # apt install libfuse3-dev Reading package lists... Done Building dependency tree Reading state information... Done Package libfuse3-dev is not available, but is referred to by another package. This may mean that the packa

Re: Is it the job of Lintian to push an agenda?

On Sat, Jul 13, 2019 at 02:22:01PM -0700, Russ Allbery wrote: > Matthias Klumpp writes: > > > With two Debian stable releases defaulting to systemd now, I think a > > solid case could be made to at least relax the "must" requirement to a > > "should" in policy (but that should better go to the re

Using dh causes configure to be run twice?

In my attempt to convert e2fsprfogs's debian/rules to use dh, I'm running into yet another frustration with dh, which is that it insists on running the configure script twice. The problem is that dh is trying to use build-arch and build-indep: % dh build --no-act debian/rules build-arch deb

Re: Could we generate d/control instead of working with "assembly level code" directly (was: Re: The noudeb build profile and dh-only rules files)

On Tue, Jul 09, 2019 at 12:24:40PM +0200, Simon Richter wrote: > Your proposal of generating some of the fields doesn't affect the API > itself, as long as the fields are populated at the right time. We don't > have a mechanism for updating the control file at build time, because any > part of the

Re: The noudeb build profile and dh-only rules files

On Mon, Jul 08, 2019 at 07:28:50PM +0100, Colin Watson wrote: > > Per my other reply, you may find that it isn't that painful after all > once you find the right approach. For instance, while a separate udeb > build pass does make > https://salsa.debian.org/ssh-team/openssh/blob/master/debian/rul

Re: The noudeb build profile and dh-only rules files

On Mon, Jul 08, 2019 at 07:36:30PM +0200, Samuel Thibault wrote: > Hello, > > Theodore Ts'o, le lun. 08 juil. 2019 13:25:32 -0400, a ecrit: > > How important is noudeb, and why is defined in the first place? > > My usage of noudeb is mostly to avoid the two-times-longer

The noudeb build profile and dh-only rules files

I'm the middle of an effort to simplify the debian/rules file for e2fsprogs so that someday, maybe, I'll be able to convert it to use dh. One of the things which I noticed while trying to rip things out of debian/rules to make the dh conversion easier (possible?) was the support for noudeb. How i

Re: Survey: git packaging practices / repository format

On Fri, Jun 21, 2019 at 05:59:52PM +0100, Ian Jackson wrote: > > There's a variant of this which is to grab updates from upstream using > > "git cherry-pick -x COMMIT_ID ; git format-patch -o debian/patches -1 > > COMMIT_ID". > > > > At the moment I'm updating debian/patches/series by hand, but I

Re: Stalls due to insufficient randomness in cloud images

On Mon, Jun 03, 2019 at 02:37:48PM +0200, Marco d'Itri wrote: > On Jun 03, Bastian Blank wrote: > > > Does anyone know what RHEL8 (which should have this problem as well) > > does to "fix" this problem? > RHEL8 enables by default rngd from rng-tools, which looks much better to > me than haveged.

Re: ZFS in Buster

On Tue, May 28, 2019 at 06:43:55PM +0200, Dan wrote: > > The ZFS developers proposed the Linux developers to rewrite the whole > ZFS code and use GPL, but surprisingly the linux developers didn't > accept. See below: > https://github.com/zfsonlinux/zfs/issues/8314 I've read the thread, and there

Re: Survey: git packaging practices / repository format

On Tue, May 28, 2019 at 04:51:10PM +0100, Ian Jackson wrote: > > Modified Direct changes git merge > upstream files,to upstream files (.dsc: 1.0-with-diff or > plus debian/*. single-debian-patch) > Maybe d/patches, depending.

Re: Buster/XFCE unlock screen is blank

On Sat, Jun 01, 2019 at 06:16:58AM +0530, Raj Kiran Grandhi wrote: > > In a fresh install of Buster with XFCE desktop, locking the screen > blanks the monitor and the monitor enters a power save state. After > that, neither moving the mouse nor typing on the keyboard would turn > the monitor back

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

On Sat, Jan 06, 2018 at 02:25:55AM +0100, Manuel A. Fernandez Montecelo wrote: > 2018-01-02 03:10 Theodore Ts'o: > > My only real concern is whether this might complicate building the > > latest version of e2fsprogs for stable and old-stable for > > debian-backports. &

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

On Tue, Jan 02, 2018 at 12:38:55AM +0100, Manuel A. Fernandez Montecelo wrote: > > Lately architectures tend to use automatic bootstrapping at least for > some of the initial dependencies. Adding support for build profiles > (would be something like pkg.e2fsprogs.nofuse in this case) can help to

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

On Wed, Jan 03, 2018 at 08:16:35PM +, Simon McVittie wrote: > > Has there been any thought about having the build > > profiles framework support for having the rules file autoselect a > > build profile based on the build environment? > > I suspect that might be a "considered and rejected" sort

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

On Mon, Jan 01, 2018 at 11:43:23PM +, Simon McVittie wrote: > > Perhaps you could convert this into a pkg.e2fsprogs.nofuse build profile? > > This would look something like the attached (untested!) patches. Thanks, I'll give this a try. From the Bui

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

On Tue, Jan 02, 2018 at 12:38:55AM +0100, Manuel A. Fernandez Montecelo wrote: > Lately architectures tend to use automatic bootstrapping at least for > some of the initial dependencies. Adding support for build profiles > (would be something like pkg.e2fsprogs.nofuse in this case) can help to > b

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

On Mon, Nov 13, 2017 at 08:35:10PM +0100, Helmut Grohne wrote: > > To to be clear, the key metric for your specific goal is the reduction > > of the _source_ package count since the goal is to reduce the number > > of packages which have to be built by "hand" (or by script), before > > you can crea

Re: recommends for apparmor in newest linux-image-4.13

On Wed, Dec 06, 2017 at 11:24:45AM +0100, Laurent Bigonville wrote: > The SELinux policy could be altered to either run everything that we know is > not ready to be confined in an unconfined domain or put that domain in > permissive (which would result in a lot of denials being logged), so it's > p

Re: recommends for apparmor in newest linux-image-4.13

On Mon, Dec 04, 2017 at 05:56:45PM +, Ian Jackson wrote: > Theodore Ts'o writes ("Re: recommends for apparmor in newest > linux-image-4.13"): > > [something about] security-weenies > > IMO this language is completely inappropriate in any formal Debian >

Re: recommends for apparmor in newest linux-image-4.13

On Wed, Nov 29, 2017 at 11:51:55AM -0800, Russ Allbery wrote: > Michael Stone writes: > > On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote: > > >> Ubuntu has successfully shipped with AppArmor enabled. > > > For all the packages in debian? Cool! That will save a lot of work. > > Yes

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

On Sat, Dec 02, 2017 at 11:59:08AM +, Sue Spence wrote: > On 2 December 2017 at 11:49, Holger Levsen wrote: > > > On Sat, Dec 02, 2017 at 12:32:29PM +0100, Geert Stappers wrote: > > > URL is https://cdimage.debian.org/cdimage/unofficial/non-free/ > > cd-including-firmware/ > > > > so who will

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

On Mon, Nov 13, 2017 at 03:28:32PM +0100, Helmut Grohne wrote: > > On Sun, Nov 12, 2017 at 02:18:45PM -0500, Theodore Ts'o wrote: > > 1) If people really want to make e2fsprogs non-essential, I'm not > > going to object seriously. It's the downgrade of e2fspro

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

On Mon, Nov 13, 2017 at 01:14:01AM +0100, Guillem Jover wrote: > I think that trying to trim down the pseudo-Essential set is an > extremely worthwhile goal, because it has visible effects on several > areas, at least: > > - Possibly making bootstrapping a port way easier. > - Making it possible

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

On Sun, Nov 12, 2017 at 09:13:42PM +0100, Mathieu Parent wrote: > > There is another way to trim the locales: Use dpkg's "--path-exclude=". > > This also allows one to keep some locales. This is what we use at work > [1]. The problem is that debootstrap doesn't handle those options, so > we need

  1   2   3   >