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

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

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

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

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

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

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

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

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 >

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 >

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

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=7 > > None for

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.

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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 > > Regardless of th

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

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

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

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

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 >

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 b

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

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

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

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"

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

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

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 >

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

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

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

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

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

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

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

On Mon, Oct 02, 2017 at 01:34:47PM +0200, Adam Borowski wrote: > But, we're discussing changes to e2fsprogs behind its maintainer's back. I > believe he reads debian-devel, but, being nowhere like a frequent poster, > apparently doesn't watch new threads immediately as they appear (and this > one

Re: How does one include the original upstream signature?

On Fri, Aug 04, 2017 at 10:28:54AM -0400, Chris Lamb wrote: > > https://lists.debian.org/debian-devel/2017/07/msg00451.html Thanks! Turns out the problem was operator error. I dropped e2fsprogs_1.43.4.orig.tar.gz.asc into the top-level directory, instead of

How does one include the original upstream signature?

I'm getting the following lintian error message: E: e2fsprogs changes: orig-tarball-missing-upstream-signature e2fsprogs_1.43.5.orig.tar.gz N: N:The packaging includes an upstream signing key but the corresponding N:.asc signature for one or more source tarballs are not included in your

Re: Can we kill net-tools, please?

On Wed, Dec 28, 2016 at 01:38:48PM +1000, Russell Stuart wrote: > I don't know whether "crap" is the right word, but it is certainly > baggage from a bygone era. "Baggage" here means that if we are nice to > our users (ie, Debian sysadmins), we should not force them to know two > tools. We only

Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.

On Wed, Oct 26, 2016 at 08:42:07AM +0200, Philipp Kern wrote: > > To the extent that we could easily support this particular use case, > > it might be a good thing. (I doubt Debian is going to want to get > > into the business of verifying and then resigning firmware blobs.) > > Depends if you

Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.

On Tue, Oct 18, 2016 at 07:52:13PM +0800, Paul Wise wrote: > > It was posted to bug #820036, which is tracking Debian support for > secure boot. Peter was advocating quite correctly that as well as > having our copy of shim (the first-stage bootloader on secure boot > systems) signed by

Re: GPL debate on kernel mailing list

On Tue, Sep 06, 2016 at 02:29:56AM +0200, Zlatan Todorić wrote: > You're just fueling myths you stand behind for some reason. You take > data from one year (did you even verify it on your own?) and you don't > look at historical development of situation. The data was compiled primarily by Jon

Re: GPL debate on kernel mailing list

On Tue, Aug 30, 2016 at 12:09:35PM +0200, Zlatan Todorić wrote: > For years and years companies are using community hard work and creating > their "great" products without turning back > > People all over the world created Free software for decades and just > small number of those people got

Re: support for noatime

On Fri, Aug 26, 2016 at 01:50:51PM +0200, Adam Borowski wrote: > > For mbox files (and possibly similar cases), there's only a handful of > interested readers, thus they can be patched to touch atime by hand instead > of relying on a system-wide mount option. Something that could be done is to

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

On Thu, Jul 14, 2016 at 01:57:13PM +1000, Peter Hutterer wrote: > libinput is a lot smarter than synaptics when it comes to palm > detection. Question about libinput? The main reason why I'm using synclient because I have a Thinkpad T540p which doesn't have hard buttons for the "mouse buttons".

Re: DEB_BUILD_MAINT_OPTIONS=hardening=+pie breaks shared library builds

On Sat, May 21, 2016 at 09:21:55PM +0200, Christian Seiler wrote: > ><<> > > Hope that helps. Yes, that was incredibly helpful. Thanks!!! - Ted

DEB_BUILD_MAINT_OPTIONS=hardening=+pie breaks shared library builds

If the pie hardening option is enabled, then dpkg-buildflags --get LDFLAGS emits: -fPIE -pie -Wl,-z,relro According to the dpkg-buildflags man page: LDFLAGS Options passed to the compiler when linking executables or shared objects Unfortunate

Re: Empty Contents and Packages files in http://deb.debian.org/debian-debug?

One other thought. Since someone might be trying to debug a core file for an executable belonging to a package which has since been superceded by a newer version in unstable or in testing, it would be useful if there was a Redis (or some other NoSQL) database where you can look up a Build-ID and

Re: Empty Contents and Packages files in http://deb.debian.org/debian-debug?

On Sat, May 21, 2016 at 04:34:19AM +, Niels Thykier wrote: > > Also, does anyone know if someone is working on a FUSE client that > > could be mounted on top of /usr/lib/debug/.build-id so that the > > debuginfo files could be automatically made available as needed when > > gdb tries to access

Empty Contents and Packages files in http://deb.debian.org/debian-debug?

Hi, is it intended that the Contents and Packages file in the dbgsyms archive are empty? I was hoping to be able to add http://debug.mirrors.debian.org/debian-debug/ to my apt.sources list so I could easily download the dbgsyms packages. Also, does anyone know if someone is working on a FUSE

Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction

On Thu, May 12, 2016 at 02:10:17AM +0100, Ben Hutchings wrote: > > If you discover that the package hoses your system then to rollback, > > shutdown the system to single-user mode, and remount the file system > > to be read-only, and then use the command lvconvert --merge to restore > > your file

Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction

On Mon, May 09, 2016 at 10:21:21AM -0700, Nikolaus Rath wrote: > > Another way is to use btrfs (or zfs or perhaps LVM snapshots): whenever > > something goes south in a way that's not trivial to recover, you can > > restore with a couple commands and reboot. And if unbootable because, > > for

Re: The state of cross building

On Sat, Jan 30, 2016 at 08:08:09PM +0100, Helmut Grohne wrote: > > We have cross compilers and crossbuild-essential-* packages in unstable > for quite a while now. (Thanks to Matthias Klose.) I see these haven't entered testing because: * 183 days old (needed 5 days) *

Re: Being part of a community and behaving

On Mon, Nov 17, 2014 at 10:21:13AM +0100, Marco d'Itri wrote: On Nov 17, Steve Langasek vor...@debian.org wrote: This is what many still (retorically) wonder about: we the systemd maintainers did not reject that change, https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;bug=746578

Re: Being part of a community and behaving

On Sun, Nov 16, 2014 at 09:02:12AM -0500, The Wanderer wrote: I would, for example, have classified the discussions / arguments in the systemd-sysv | systemd-shim bug which appears to have recently been resolved by TC decision as being an example of what I thought was being referred to by

Re: Being part of a community and behaving

On Thu, Nov 13, 2014 at 08:25:57AM -0800, Russ Allbery wrote: What do you think we should have done instead? debian-devel was becoming the standing debian-canonical-is-evil vs. debian-systemd-sucks standing flamewar. (I think people are already forgetting the whole Canonical is evil flamewar

Re: A concerned user -- debian Guidelines

On Mon, Nov 10, 2014 at 02:34:33PM +0100, Matthias Urlichs wrote: The Wanderer: Unfortunately, as far as I can tell, no one seems to be remotely interested in trying to address or discuss that disagreement directly... The problem is that, apparently, any 'support' short of remove systemd

Re: bash exorcism experiment ('bug' 762923 763012)

On Sat, Oct 11, 2014 at 10:37:26AM -0700, Russ Allbery wrote: You have convinced me that in this case it's going to have to be that way, so my prejudices notwithstanding. I've rationalised the pain away by deciding it's no so bad as any competent programmer could see that is it only

  1   2   >