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
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 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
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
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 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
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 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 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 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 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 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 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
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 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
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
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
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 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 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 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 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 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 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
201 - 229 of 229 matches
Mail list logo
