On Wed, Jun 25, 2025 at 08:57:42PM -0700, 1...@110110.net wrote:
>
> I personally would like debian to research a version of debian for
> high performance computers, or at least a fork of debian optimized
> for high performance computers; ready to occupy large sets of ram,
> hd space, and complete
On Wed, Jun 18, 2025 at 02:29:49PM +0100, Simon McVittie wrote:
> The typical Github/Gitlab workflow encourages having a separation between
> two categories of branches:
>
> - stable, "public", safe to reference and will not be force-pushed
> (for example "main" or "0.2.x" or "debian/latest")
>
On Tue, Jun 17, 2025 at 11:15:55PM +0300, Otto Kekäläinen wrote:
> You are aware that you can send e-mail to a MR on GitHub and to a PR
> on GitLab and pretty much every Forge supports both email
> notifications and email replies?
>
> The only feature currently missing in GitLab is to have the
> n
On Tue, Jun 17, 2025 at 11:15:55PM +0300, Otto Kekäläinen wrote:
> I've seen some of this same sentiment in discussions about
> bugs.debian.org. People think that having a hard-to-use bug tracker
> will keep the "noobs" away and maintain a higher quality of bug
> reports and discussions among the p
On Tue, Jun 17, 2025 at 07:49:11PM +0300, Otto Kekäläinen wrote:
>
> A person with your seniority surely knows better commands to use than
> review plain diffs. Naturally, it is better to review using the git
> log -p output that shows each commit message individually and related
> changes.
You *
On Tue, Jun 17, 2025 at 08:51:19AM +0300, Otto Kekäläinen wrote:
>
> After a `git fetch` or a `git pull` it is very easy to review what
> the change is or diff it against the current main branch. There are
> a bunch of tolls, including of course the usual gitk and `git
> difftool --dir-diff` + Mel
On Sat, Jun 14, 2025 at 07:09:59PM +0200, IOhannes m zmölnig wrote:
> >
> >I think the other reason why these discussions are a bit frustrating
> >is that there seems to be an implicit assumptions that all
> >contributions from newcomers *must* be good,
>
> dunno.
> I think the implicit assumptio
On Mon, Jun 16, 2025 at 05:43:12PM -0400, Theodore Ts'o wrote:
> The obvious counter example here is Jia Tan[1][2]. Another more recent
> example is the "X11Libre" developer who had to get ejected from
> Freedesk.org after contributing a huge number of questionable
>
On Wed, Jun 04, 2025 at 10:47:35AM -0700, Russ Allbery wrote:
>
> Sorry, yes, Debian discussions around workflow are often frustrating
> because part of the discussion is usually at least a mild request
> for existing maintainers to change their current workflows, and when
> people feel overwhelme
On Fri, May 30, 2025 at 02:39:19PM +0100, Simon McVittie wrote:
>
> This seems like a good opportunity to point out that for non-trivial
> changes, it's often a good idea to have a bug report (or issue, or
> whatever this particular project uses) *anyway*, as a place to put a
> solution-neutral pr
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
>
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-/
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
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
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
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
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
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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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.
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
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.
&
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
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
1 - 100 of 229 matches
Mail list logo
