On Thu, May 29, 2025 at 01:15:23PM +0100, Jonathan Dowland wrote:
> On Thu May 29, 2025 at 9:58 AM BST, Holger Levsen wrote:
> But their contribution is the thing that's valuable to us, more so than
> their email address.
no, it's the combination. we need to interact.
--
che
On Thu, May 29, 2025 at 01:40:33AM +0100, Colin Watson wrote:
> > I've also seen very very few complaints about the fact that the BTS shows
> > email addresses if submitters and contributors. And I'm definitly not aware
> > that we identified this as a problem!
> owner@bugs gets complaints about th
On Thu, May 29, 2025 at 01:30:58PM +0530, Pirate Praveen wrote:
> > I've also seen very very few complaints about the fact that the BTS shows
> > email addresses if submitters and contributors. And I'm definitly not aware
> > that we identified this as a problem!
> It definitely attracts huge amoun
On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote:
> If you suggest that using "debian/latest" should *not* be done by
> default, then it seems that requires reverting changes to DEP-14.
yes. dep14 currently says "that uploads to unstable and experimental should
be prepared either
On Wed, May 28, 2025 at 10:05:44PM +, Holger Levsen wrote:
> I appreciate and applaus Otto's posts too, but can we please agree on
> debian/unstable, debian/experimental, debian/trixie, ... as our *default*?
> while still "allowing" debian/latest and and also debian/3.
On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
> does it make sense to work in debian/latest and only last before pushing for
> review create another branch next/debian/latest? I'd always intuitively work
> in next/debian/latest directly.
I appreciate and applaus Otto's posts too, bu
Hi Julien,
thanks and applause for this initiative of yours! I agree the bts could
see several improvements..!
On Tue, May 27, 2025 at 06:46:29PM +0200, Julien Plissonneau Duquène wrote:
> We would like debbugs to:
> 0. keep all the e-mail features it currently offers
> 1. process new requests an
On Sun, May 25, 2025 at 10:56:14AM +0100, Richard Lewis wrote:
> It would be really nice if there was an easy way to link a bug report to a MR
> on salsa
> you can try
> forwaded NN
> https://salsa.debian.org/debian-team/package-name/-/merge_requests/MMM
> but eg gmail will break the long lin
On Tue, May 20, 2025 at 12:42:20AM +0500, Andrey Rakhmatullin wrote:
> > so you have gwh, calling gbp, calling sbuild?, calling dpkg-buildpackage?,
> > calling debian/rules, calling dh, calling dh_auto_build?, calling
> > upstream's build system (which may itself often include layers)
> > i know
hi,
seriosuly, I would not bother about the epoch, and just live with
it. iirc 10% of the archive has an epoch, so meh.
Removing over two releases is risky and errorprone, eg. you need
to make sure not to reuse versions etc pp.
An epoch might be a bit ugly, but overall it's completly harmless.
On Wed, May 14, 2025 at 09:30:25AM +0200, Simon Josefsson wrote:
> Are there any guarantees on semantics for package removals? Will the
> user/group be removed from /etc/{passwd,group} or not? Will it remove
> the home directory? What happens if the home directory is not empty?
> Will it remove
On Mon, May 12, 2025 at 08:32:24AM +, Holger Levsen wrote:
> debian/README.source as described in the developers-reference.
and even in
https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-bui
On Mon, May 12, 2025 at 09:09:23AM +0100, Richard Lewis wrote:
> > I dont want to use git-buildpackage and I don't want a
> > gpb.conf. Please accept this. Thanks.
> is there another way people can use to understand how to build the
> package?
debian/README.source as described in the developers-re
On Sun, May 11, 2025 at 03:58:12PM -0700, Otto Kekäläinen wrote:
> > > I think this significantly underestimates the annoyance involved in
> > > renaming
> > > existing long-lived branches (in that all clients have to re-clone or
> > > manually adjust), which is certainly why I generally avoid doi
On Fri, May 09, 2025 at 07:15:03PM +0200, Vincent Lefevre wrote:
> > jas@kaka:~$ ls /usr/games/|wc -l
> > 21
> Indeed. I thought that there were a lot more in /usr/games.
$ apt-file search /usr/games|wc -l
1184
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|lay
On Fri, May 09, 2025 at 12:43:54PM +0200, Lucas Nussbaum wrote:
> On 09/05/25 at 10:27 +0200, Andreas Tille wrote:
> > > However, I have doubts about (4), since there's still so many different
> > > workflows to use Git+Salsa.
same here.
> > Which brings us back to DEP-14 as a baseline recommenda
On Thu, May 08, 2025 at 09:01:54PM +0200, Andreas Tille wrote:
> Just a short comment: In the Bug of the Day effort the majority of
> packages will be moved into team maintenance using the ITS procedure or
> packages removed via (pre-)removal bugs.
fwiw, I think that's great. Thank you!
--
chee
On Thu, May 08, 2025 at 08:24:57PM +0200, Lucas Nussbaum wrote:
> The developers-reference has this sentence:
> > Fixing cosmetic issues or changing the packaging style in NMUs is
> > discouraged.
>
> Maybe it could be changed to:
> > Using NMUs to make changes that are likely to be non-consensua
On Thu, May 08, 2025 at 01:42:34PM +0500, Andrey Rakhmatullin wrote:
> On Thu, May 08, 2025 at 08:06:03AM +0000, Holger Levsen wrote:
> > > I think your reaction to this is a bit harsh. I see this ITN proposal as
> > > a way how to handle pacakges that are effectively unmainta
On Thu, May 08, 2025 at 10:26:08AM +0200, Andreas Tille wrote:
> > again, orphaning means doing a QA upload. a gentler path would be an NMU.
> > again, I don't why we need a new process here.
> Orphaning is something typically done by the maintainer themselves[1].
that is true and it's also true t
On Thu, May 08, 2025 at 10:00:10AM +0200, Andreas Tille wrote:
> >From my point of view, orphaning would be a more forceful step--closer
> in spirit to a QA upload, as Holger suggested. I prefer a gentler path
> that allows space for maintainers to re-engage if they wish.
again, orphaning means d
On Wed, May 07, 2025 at 07:34:17PM -0300, Antonio Terceiro wrote:
> I think your reaction to this is a bit harsh. I see this ITN proposal as
> a way how to handle pacakges that are effectively unmaintained, but
> where one is not necessarily interested in becoming the maintainer.
we have a procedu
On Wed, May 07, 2025 at 05:42:39PM +0200, Jonas Smedegaard wrote:
> Since you asked: I respectfully find ITN a very bad idea.
+1
> ITS is a process where you intend to take over responsibility.
>
> ITN is a process where you intend to put pressure on the existing
> maintainer for changing their
On Wed, May 07, 2025 at 03:28:42PM +0200, Vincent Lefevre wrote:
> Yes, but then, shouldn't the severity be raised (as without
> a fix, they will no longer work in Trixie)?
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bl...@debian.org;tag=missing-systemd-service
says they are already at pri
On Mon, Apr 28, 2025 at 12:31:24PM +0200, Marc Haber wrote:
> Not that I know of. I was just told off-the-records that it does not
> make sense to spend any more time on adduser since it's going to be
> forbidden soon anyway.
don't believe everything they say?
and many thanks for maintaining add
On Sun, Apr 20, 2025 at 12:48:08PM +0200, Simon Josefsson wrote:
> Right -- has anyone considered if Debian should have official containers
> without apt and dpkg? I think that for many use-cases for containers,
> apt and dpkg will not be used and just take up space. Guix packs
> (containers) doe
On Thu, Apr 17, 2025 at 09:45:53AM +0200, Santiago Vila wrote:
> > > I wish reproducible-builds people would activate DEB_BUILD_OPTIONS=nocheck
> > > for the second build, I think it would help. I don't think anybody will
> > > use that as an excuse to file more RC bugs.
> > They mentioned earlier
package: releasenotes
x-debbugs-cc: debian-devel@lists.debian.org
On Tue, Apr 01, 2025 at 03:27:05PM -0400, Michael Stone wrote
Message-ID: <70ba7152-0f2e-11f0-9b6a-00163eeb5...@msgid.mathom.us>
to debian-devel@l.d.o stating:
> /run/utmp is no longer provided in trixie, which means that the mech
On Sat, Mar 22, 2025 at 08:24:34AM +0100, Jonas Smedegaard wrote:
> Some of us (me included) prefer Salsa over Github or Sourcehut or other
> forges, but what we use is its git hosting service without its optional
> web-centric services (regardless if accessed via a web browser or a web
> CLI tool)
On Thu, Mar 20, 2025 at 01:14:57PM +0100, Guillem Jover wrote:
> So «certificate» should be taken as a synonym with what was previously
> known as «Transferable Public Key» (or «public key»), in contrast to
> a «key» which is understood as a «Transferable Secret Key» (or
> «secret key»). Which shou
On Thu, Mar 06, 2025 at 02:54:32PM +0530, Pirate Praveen wrote:
> On 3/6/25 2:09 PM, Holger Levsen wrote:
> > so if the/a team says they cannot handle new members right now and thus
> > there should be no big announcement asking for new members, I very much
> > think this sh
On Fri, Mar 07, 2025 at 04:40:04PM -0700, Soren Stoutner wrote:
> My question is, is there any other decision making process that would be
> preferable to a GR to decide this issue?
another outcome would be to leave things like they are. of course we could
have a GR to get to that result too.
-
On Tue, Mar 04, 2025 at 08:39:43PM -0500, Helmut K. C. Tessarek wrote:
> Both network "outages" could have been prevented by adding a note at the end
> of the dist-upgrade output.
they could also have been prevented by reading the release notes and following
their advice.
that would also have pre
On Thu, Mar 06, 2025 at 08:58:48AM +0100, Marc Haber wrote:
> Marc. I'll take my Popcorn with salt please.
yeah, it's pretty funny to see a team burn out and have the same silly
& salty discussion about this again and again.
or maybe not.
also talking about how NEW is a bottleneck will be reall
On Mon, Mar 03, 2025 at 10:44:35PM +, Jeremy Sowden wrote:
> On 2025-03-03, at 14:26:36 -0800, Russ Allbery wrote:
> > [snip] I am getting nerd-sniped here [snip]
> I did not know that there was a word for this. I have learnt
> something fun to-day. Thanks, Russ (and Randall). :)
xkcd.com/35
On Thu, Feb 27, 2025 at 09:48:44AM -0700, Soren Stoutner wrote:
> Given the above four points, I propose the line from the code of conduct
> quoted above be
> changed to read:
lol, 22h after proposing to change 20 year old habbits, you still agree with
your idea. i'm not impressed. also you seem
On Thu, Feb 27, 2025 at 12:50:30PM +0100, Tino Didriksen wrote:
> Wholeheartedly agree. Forced line wrapping is archaic, and not just in
> emails. Any viewer or editor worth anything can display long lines in a way
> that flows and indents with surroundings.
>
> format=flowed would be neat, if it
On Wed, Feb 19, 2025 at 05:05:49PM +0100, Lucas Nussbaum wrote:
> Yes. At some point it would be nice to design a real service that
> exposes all build logs with their context, similar to what is done on
> ci.debian.net.
ah, nice! thanks for clarifying!
> But for now that's just a storage space
On Tue, Feb 18, 2025 at 06:19:45PM +0100, Lucas Nussbaum wrote:
> that looks useful:
> $ curl http://qa-logs.debian.net/2025/02/16/00res.amd64exp | grep "multiple
> definition of \`QtPrivate::IsFloatType_v<_Float16>'"
qa-logs.debian.net! never heard of this before! what is it? seems to be very
On Mon, Feb 17, 2025 at 10:47:04PM +0100, Julien Puydt wrote:
> Yes. Most upstream have little clue on what a best practice is, and
> need to be explained at length.
TBH I basically stopped reading here, this assumption is so flawed, the
(upstream) world is way more diverse.
--
cheers,
On Tue, Feb 18, 2025 at 12:32:08PM +, Colin Watson wrote:
> I for one appreciate this sort of early warning. It's much easier to
> deal with failures like this promptly before they become a serious
> problem, rather than having to disentangle things later when several
> different failures have
On Thu, Feb 13, 2025 at 08:34:07PM +0100, Jonas Smedegaard wrote:
> Hi Santiago,
> It would probably be helpful to also share the result of somehow running
> the compiled list through dd-list, to raise attention for involved
> maintainers.
I want to say: yes. :) please do.
--
cheers,
Ho
hi,
about https://salsa.debian.org/lumin/gr-ai-dfsg/-/blob/main/README.txt
On Sun, Feb 02, 2025 at 12:56:59AM -0500, M. Zhou wrote:
> (2) are the options clear enough for vote? Considering lots of the readers may
> not be faimiliar with how AI is created. I tried to explain it, as well as
> the i
On Tue, Jan 28, 2025 at 12:50:43PM +0100, Guillem Jover wrote:
> > I'd point out that "debian/main" also refers to the part of the Debian
> > package archive that is not "contrib" or "non-free".
> > I therefore perceive "debian/main" as ambiguous.
> I think this has been mentioned in the past, and
On Fri, Jan 24, 2025 at 12:18:18PM +, Colin Watson wrote:
> > Otto> Could you give it a try please? Salsa isn't that bad :)
> > Can you please respect people who have different positions than you?
> > I'm this close to turning off MRs for all my packages and promising to
> > be the last per
On Thu, Jan 23, 2025 at 02:28:00PM +, Matthew Vernon wrote:
> I'd much much rather MRs were associated with bug reports; that way I
> only have to remember to check one place for outstanding issues in my
> packages, and years down the line when I wonder "why did this change get
> made" I can lo
On Sat, Jan 11, 2025 at 11:25:20AM -0500, M. Zhou wrote:
> On Sat, 2025-01-11 at 13:49 +0100, Fabio Fantoni wrote:
> >
> > Today trying to see how a new person who wants to start maintaining new
> > packages would do and trying to do research thinking from his point of
> > view and from simple s
On Wed, Jan 08, 2025 at 09:11:02PM +0100, Serafeim (Serafi) Zanikolas wrote:
> hi Holger,
as you have addressed me here and...
> On Wed Jan 8, 2025 at 11:57 AM CET, Holger Levsen wrote:
> > (actually adequate is run on many more binary packages on piuparts.d.o,
> > becaus
On Wed, Jan 08, 2025 at 08:22:22PM -0800, Otto Kekäläinen wrote:
> There have been discussions about adding adequate to Salsa CI and run
> it by default as part of the piuparts job. If you are now preparing to
> have adequate by default in piuparts, then it would make sense to have
> it by default
On Tue, Jan 07, 2025 at 11:55:30PM +0100, Serafeim (Serafi) Zanikolas wrote:
> two things: first, what is a "core component of Debian" is very much up to
> debate, but I'd be quite surprised if anybody made the case that adequate is.
adequate is run on all 7 binary packages on piuparts.debian.
On Tue, Jan 07, 2025 at 11:21:36PM +0100, tho...@goirand.fr wrote:
> > I think that being able to host the primary git repository of packages
> > elsewhere is a freedom worth maintaining for many reasons.
same here.
> I don't think we should continue to allow the "freedom" to be annoying for
On Sun, Jan 05, 2025 at 11:58:40PM +0100, Chris Hofstaedtler wrote:
> Maybe you can consider using a time namespace (unshare -T) and
> change the system date/time in that namespace.
I'd also strongly suggest to do a full archive rebuild in such namespace
comparing that with a full archive rebuild
On Sun, Jan 05, 2025 at 09:28:24PM +0100, Santiago Vila wrote:
> > Did you use libfaketime in this round of rebuilds?
> No, I did not use libfaketime yet (sorry).
so what did you use?
setting the system time to the future (like we've been doing for
tests.reproducible-builds.org/debian for many
On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> I'm wondering how we can clean up suites like experimental and
> unstable. They tend to slowly accumulate cruft that nobody cleans up,
> including no longer installable packages.
for experimental: yes, please!
for unstable: what Helmut sa
On Mon, Dec 23, 2024 at 12:48:50PM +0100, Julian Andres Klode wrote:
> i.e. we see a 9MB saving for essential+apt, and a 4MB saving
> for a default mmdebstrap.
very nice!
> Something still pulls in gpgv there
> which is unfortunate, we lack a 5MB savings.
>
> More savings can be achieved by bui
On Tue, Dec 17, 2024 at 06:17:47PM -0800, Otto Kekäläinen wrote:
> I changed my personal preference from DEP-0 to DEP0 as I now consider
> DEP0 the best option based as I have seen so much of RFC822, dep3,
> dep8 and DEP14 in use in many places. However, that +22 for DEP-0 is
> pretty large majorit
On Sun, Dec 15, 2024 at 09:50:17AM +0100, Daniel Baumann wrote:
> both sound good (dropping mandatory priority is nice and consistent,
> fixing unknown section behaviour too), thanks!
indeed! thank you both!
> ideally these changes would be in dpkg in trixie, but maintainers would
> start dropp
On Thu, Dec 12, 2024 at 08:57:57AM +0100, Matthias Urlichs wrote:
> On 04.12.24 18:08, Andreas Tille wrote:
> > in the
> > absence of a debian/dont_touch_my_package file, any Debian Developer is
> > permitted to upload the package.
> I like this idea.
so you like reality. good.
--
cheers,
On Wed, Dec 11, 2024 at 09:29:08PM +0900, Charles Plessy wrote:
> Last time I had to write a removal request I asked ChatGPT and it worked
> well!
is this debian-devel@ or -curiosa@? (&scnr)
that said, I do realize that the verb "to google" slowly is becoming "to
ask $chatgpt" or rather, that als
On Sat, Dec 07, 2024 at 10:39:43PM +0500, Andrey Rakhmatullin wrote:
> No, there is clearly no consensus on unifying any workflows. Everyone
> thinks their workflow is superior and canneeds to stay.
I agree with the first sentence but I think the 2nd sentence is too much drama.
Those many workflo
On Fri, Nov 22, 2024 at 01:53:11PM +0100, Julian Andres Klode wrote:
> We currently see a size increase of 8% (9MB uncompressed, 4MB gzipped) in an
> essential + apt bootstrap:
^^ that's trixie, in sid they're a bit smaller now and will probably soon
shrink further:
user@debian-work:/tmp $ schroo
On Thu, Nov 28, 2024 at 10:54:37AM +0100, Helmut Grohne wrote:
> I think this demonstrates that we probably have something between 10 and
> 50 packages in unstable that would benefit from a generic parallelism
> limit based on available RAM. Do others agree that this is a problem
> worth solving in
On Tue, Nov 26, 2024 at 09:44:31PM +0500, Andrey Rakhmatullin wrote:
> Currently gbp by default generates a broken tarball, which is also a
> source of confusion for many.
I'd dare to even call this a bug.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-ac
On Sun, Nov 24, 2024 at 06:23:00PM +0100, Paul Gevers wrote:
> [Putting my Release Team hat off] Personally I think Debian should be
> raising the baseline for i386. I'm not sure about to which level, but I've
> seen proposals in this thread.
same here.
> [Release Team hat on] I would take conse
On Fri, Nov 22, 2024 at 06:25:58PM +0100, Julian Andres Klode wrote:
> If you want to learn more about Sequoia and the Chameleon
> in particular, watch Holger's talk at this year's DebConf:
> https://debconf24.debconf.org/talks/16-chameleon-the-easy-way-to-try-out-sequoia-openpgp-written-in-rust/
On Fri, Nov 22, 2024 at 06:46:10AM +0900, Simon Richter wrote:
> Because there is no coordination between gpgv and gpgv-sq packages,
that's not entirely true.
> and
> dependent packages should have no reason to care. gpgv-sq unilaterally
> claims compatibility, and if something breaks as a resul
On Wed, Nov 20, 2024 at 08:10:30PM -0800, Otto Kekäläinen wrote:
> > fwiw, I'm also not using git-buildpackage and I don't want to. (Step
> > learning
> > curve, too much magic, hard to debug and I dont see benefits for the
> > packages
> > I maintain.) I'm also not a beginner. And I love gbp-dch
hi,
fwiw, I'm also not using git-buildpackage and I don't want to. (Step learning
curve, too much magic, hard to debug and I dont see benefits for the packages
I maintain.) I'm also not a beginner. And I love gbp-dch.
just as another data point. (the above.)
please dont enforce git-buildpackage
On Thu, Nov 14, 2024 at 12:48:18AM -0800, Otto Kekäläinen wrote:
> As the original DEP-0 used that in the title, I suggest we agree to
> consistently spell it with a dash going forward. Anyone seconds?
I'm all for consistancy too, thus I would suggest dep0, as this is what's
written in the URLs.
On Sun, Nov 10, 2024 at 08:48:21AM +0900, Charles Plessy wrote:
> Our mailing lists were a ground-breaking technological avance in the
> past that would open Debian to the whole World, but now are they not
> working exactly against that?
first: citation needed.
second: summaries written by applie
On Wed, Nov 06, 2024 at 06:03:45PM +0100, IOhannes m zmölnig wrote:
> Afaict, the problem is that we have 3 options to pick from, and it's hard for
> people to decide which is the "right one".
> I do not see how adding a 4th option will make this decision any easier (esp.
> since that new option
On Wed, Nov 06, 2024 at 05:28:38PM +0500, Andrey Rakhmatullin wrote:
> "Let's at least force rebuilds all packages not rebuilt since stable
> before every freeze starts" is a popular opinion.
true. and "let's not do that" is even more popular, else why haven't we
done this in three decades?
--
On Mon, Oct 28, 2024 at 10:55:57PM +0100, Sebastian Ramacher wrote:
> since dpkg 1.22.0 the additional hardening flags to enable Pointer
> Authentication (PAC) and Branch Target Identification (BTI)
> on arm64 are enabled by default. See [1] for the discussion to enable
> these flags.
/me likes
On Fri, Oct 25, 2024 at 03:03:53PM +, Holger Levsen wrote:
> the current expectation is that an NMU bug is opened, which contains
> the debdiff.
>
> https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#when-and-how-to-do-an-nmu
>
> "..
On Fri, Oct 25, 2024 at 10:06:56AM -0400, Noah Meyerhans wrote:
> Honestly I'd be happy if we could just establish some expectation that
> the NMUer open a merge request for their changes. It can be merged
> later without losing anything or requiring additional work. Enforcement
> of this expecta
On Sun, Oct 13, 2024 at 11:37:11PM +0900, Charles Plessy wrote:
> Le Sun, Oct 13, 2024 at 03:21:11PM +0100, Paul Gevers a écrit :
> > https://lists.debian.org/debian-devel-announce/2023/12/msg3.html
> Thanks, I read it at the time but I did not understand the meaning:
> do you really expect tha
On Mon, Sep 23, 2024 at 11:04:06AM +0200, Marco d'Itri wrote:
> > ifupdown2 is like ifupdown, just rewritten in python.
> Yes, that's the problem: there was a consensus that it is not an
> appropriate dependency for the base system.
ah! thanks for pointing this out.
> ifupdown2 will still be aro
On Mon, Sep 23, 2024 at 10:14:39AM +0200, Chris Hofstaedtler wrote:
> * Holger Levsen [240923 10:06]:
> > I miss ifupdown2 in this discussion.
> In the older thread, it was pointed out that ifupdown2 might be
> currently in a bad place maintenance-wise;
> https://github.c
hi,
I miss ifupdown2 in this discussion.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
Change is coming whether you like it or not.
signature.asc
Description: PGP signature
Dear Phil,
On Fri, Sep 20, 2024 at 12:34:18PM +0100, Phil Wyett wrote:
> xindy (2.5.1.20160104-11.1) unstable; urgency=medium
>
> * Non-maintainer upload.
> * 'd/clean' - add files:
> - make-rules/alphabets/norwegian/latin1.pl
> - user-commands/texindy.1
> - user-commands/xindy.1
On Wed, Sep 04, 2024 at 08:21:04AM +0200, Lucas Nussbaum wrote:
> After lintian.debian.org went unmaintained (beginning of 2022)
[...]
> After providing stale data for a long time, which confused many people,
> lintian.debian.org was shutdown in September 2023.
in Debian timeframes, this is basica
Hi,
I also like us to remove more broken and unused packages from unstable.
On Tue, Aug 20, 2024 at 11:20:10AM +0200, Lucas Nussbaum wrote:
> Maybe we could also reduce the cost of removals for users and potential
> new maintainers, by improving the information provided in various places
> on how
On Tue, Aug 20, 2024 at 10:44:30PM -0700, Otto Kekäläinen wrote:
> > Advertise widely and frequently that there is a pool of people which is
> > happy to help investigating the failed CI jobs.
> > Then start personally advocating the benefits of CI to the maintainers
> > of these packages: I expect
On Fri, Aug 09, 2024 at 10:32:13PM -0700, Otto Kekäläinen wrote:
> Nicolas' implementation (https://lintian.club1.fr/) to list all tags
> on one page and link to UDD seems like a reasonable compromise in
> functionality and maintenance effort.
any DD can point lintian.debian.net to that machine (o
hi Alec,
please stop mailing this thread and just use an epoch.
Before adding^wintroducing an epoch one should consult debian-devel@l.d.o,
you have done this, arguments were exchanged and (IMNSHO) no better
solution was found, so please do what has done to >1000 source packages
in the archive alr
On Mon, Jul 01, 2024 at 05:17:09PM -0700, Russ Allbery wrote:
> I would use an epoch.
yes.
[...]
> Basically, you'd be burning a lot of social capital with upstream for no
> really good reason and you probably still wouldn't be able to convince
> them. I don't think it's worth it.
yes.
> I wo
hi,
On Tue, Jun 25, 2024 at 02:02:11PM +0100, Simon McVittie wrote:
> I have to ask:
>
> Could we use a container framework that is also used outside the Debian
> bubble, rather than writing our own from first principles every time, and
> ending up with a single-maintainer project being load-bear
On Fri, Jun 07, 2024 at 02:32:14PM +0200, Guillem Jover wrote:
> And I think forcing a locale on buildds makes perfect sense, because
> we want easy access to build logs. But forcing LC_ALL from the build
> tools implies that no tool invoked will get translated messages at
> all, and means that use
On Thu, Jun 06, 2024 at 07:11:46PM +0200, Michael Biebl wrote:
> I would prefer that dpkg-buildpackage provides a "sane" build environment by
> default (which I think includes a LC_ setting pointing at a .UTF-8 locale)
> and fewer packages explicitly setting those things via debian/rules.
same her
On Sat, Jun 01, 2024 at 09:52:32AM +0200, Andreas Tille wrote:
> in connection with MiniDebConf Berlin there was some discussion about
> what expense per attendee of some in person meeting is OK. Quoting
> Chris Lamb from his "Bits from the DPL (March 2018)"[meet1]:
>
> Debian is willing to rei
On Wed, May 22, 2024 at 12:25:49AM +0200, Salvo Tomaselli wrote:
> > I would rather see a small but very stable base distribution, with the
> > option to add features on top.
> Doesn't this conflict with debian being universal?
for some it surely does, while for others it's needed to make Debian
On Wed, May 22, 2024 at 07:18:04AM +0200, Andreas Tille wrote:
> IMHO this is a hen-egg-problem: If NMUer could expect packages beeing on
> Salsa we could require the NMUer to add at least a MR.
those are two things:
- mandating salsa (for git)
- mandating to have MRs enabled on salsa for that
On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:
> The Debian archive itself is a VCS, so git-maintained packaging is also a
> duplication, and keeping the official VCS and git synchronized is causing
> additional work for developers, which is why people are opposed to having it
> man
On Mon, May 20, 2024 at 01:00:00PM -0700, Otto Kekäläinen wrote:
> Regarding this discussion in general, I get the sense that
> participants haven't actually tried Debputy and are not aware of its
> capabilities. If you have Podman/Docker you can effortlessly run this
> little check to get some exp
On Tue, May 07, 2024 at 04:24:06PM +0300, Hakan Bayındır wrote:
> Consider a long running task, which will take days or weeks (which is the
> norm in simulation and science domains in general). System emitted a warning
> after three days, that it'll delete my files in three days. My job won't be
>
clone 966621 -1
reassign -1 release-notes
thanks
On Mon, May 06, 2024 at 10:40:00AM +0200, Michael Biebl wrote:
> We have two separate issues here:
>
> a/ /tmp-on-tmpfs
> b/ time based clean-up of /tmp and /var/tmp
>
> I think it makes sense to discuss/handle those separately.
very much agreed.
On Fri, Apr 12, 2024 at 09:53:29AM +0100, Jonathan Dowland wrote:
> On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote:
[...]
> I agree with everything you say here!
:)
> Wrt git-buildpackage, I'd like to add that personally, I respect the gbp
> authors and maintainers and i
hi,
just adding some random data points to this thread:
- I love git.
- I very much dislike git-buildpackage, too much magic. I try to avoid it
where I can.
- I like salsa. (though I think for many new contributors this is rather
a barrier "why not use github" directly. Also salsa is Debian o
On Thu, Apr 04, 2024 at 01:32:11PM +0200, Marc Haber wrote:
> So you have dedicated packet filters on every machine you run, even if
> sshd is the only network-facing service?
on most machines and it was as simple as doing:
apt install ufw
ufw allow ssh
ufw enable
voila, done. rules configured l
On Thu, Mar 21, 2024 at 10:47:21AM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug?
> [and 1 more messages]"):
> > Steve, could you please do this for *all* the time_t transition RC
> > bugs?
> IMO things are currently ON FIRE.
I'd rather call
1 - 100 of 1319 matches
Mail list logo
