* Santiago Vila [250421 14:51]:
El 21/4/25 a las 14:02, Chris Hofstaedtler escribió:
I would suggest you hit up some of the current maintainers of Essential: yes
packages, and leave the naysayers on d-devel to themselves.
Note that there might be some overlap in those two sets of people
he current maintainers of
Essential: yes packages, and leave the naysayers on d-devel to
themselves.
Chris
GNOME desktop users could also use Fedora, and the work of
maintaining GNOME in Debian would be saved.
People like to use Debian for a lot of different reasons. Very large
and very small installs are "just" usecases too. When there are enough
people interested (and so on...) in it, it will happen.
Chris
believe all relevant people are in CC:, and they can figure this
out. Details can be found in the bug.
Chris
diff -Nru git-2.49.0/debian/changelog git-2.49.0/debian/changelog
--- git-2.49.0/debian/changelog 2025-03-15 18:48:53.0 +0100
+++ git-2.49.0/debian/changelog 2025-04-13 22:18
ure. But the developers at upstream
of wtmpdb persist in the opinion that wtmp has nothing to do with
utmp before merging PR#36.
They are correct.
Now, I have not the guts to ask them, if they would like to implement
an own who(1) utility.
I think that would be wrong.
Chris
roducing utmp will just hide the problem, and we'll be in the
same situation when releasing forky, or forky+1, ...
Chris
PS: I never understood why there's both w and who, and why they are
different implementations.
de maintainer scripts and challenging to
automatically analyze.
Yup. dumat has a lot of code to deal with diversions. But overall it
seems totally doable/reusable.
live-tools also seems to divert files from initramfs-tools, which is
how I found out about this mail thread.
Best,
Chris
gt; and I do not understand why it becomes a priority to change them now.
Please provide real examples of science packages and numbers of
affected science packages that were affected by this change.
Chris
iven I ran into this discrepancy today (in util-linux, buildd and
my local build are fine, salsa ci and pbuilder are not), I would
appreciate it if the default would change.
It's probably too late for trixie now, but maybe for forky?
Thanks,
Chris
ore uploading a new
upstream version?
Chris
On Sun, Feb 16, 2025 at 05:44:34PM +0100, наб wrote:
> On Sun, Feb 16, 2025 at 05:29:26PM +0100, Chris Hofstaedtler wrote:
> > On Sun, Feb 16, 2025 at 05:18:39PM +0100, наб wrote:
> > > Quoting the relevant:
> > > > It is recommended to choose between one of the tw
e two of my packages in the list would
support this interpretation.
I don't see how this is a meaningful prioritization.
Chris
to "packages that are not
uptodate wrt to upstream".
ddpo already has my list of packages that I should be updating.
Chris
t scheme can either
experience that again or, better, will ignore whatever the DEP will
say in the future.
Chris
:
>
> * Merge requests are disabled for that project
>
> * Merge requests are actively watched at least as closely as the BTS
I agree. Projects that do not want MRs on salsa should have the
feature turned off.
BTW, a lot of other gitlab features should probably be off for most
packaging repositories.
Chris
d it effectively rules out devscripts for that
> purpose. Is there any existing "bootstrap essential" package that wasn't yet
> approached by Helmut and that could be interested in hosting that new tool?
Please just put it into a new package.
Chris
On 1/16/25 14:50, Andrey Rakhmatullin wrote:
On Thu, Jan 16, 2025 at 01:54:05PM -0500, Chris Knadle wrote:
atomic operations require linking against libatomic — always have. Some
architectures inline a few functions, which is how you get away with
omitting the library on amd64 most of the
an fix the build for armel too. Nice.
Thanks.
-- Chris
Chris Knadle
chris.kna...@coredump.us
On 1/16/25 11:10, Ben Collins wrote:
On Thu, Jan 16, 2025 at 09:48:53AM -0500, Chris Knadle wrote:
Greetings.
I have a situation with mumble where the build is breaking on armel
architecture. Upstream has identified that this bug is due to the mumble
"link" plugin containing ato
e has a better solution, please let me know.
Thanks much.
[1] https://lists.debian.org/debian-devel/2006/11/msg01005.html
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
Debian developer
Anyone else while we are at it?
Actually, yes. It's really unclear to me what you are trying to
achieve here, with the continuation of this communication style.
Chris
that is older than 6 months. But I don't know how that will
fare for the Janitor MRs.
Frustrated,
Chris
(*) there's a limit to "boring but someone needs to do it" where
I'll step in.
ball.
The name for the remote could easily have been "upstream" like
various packages are already set up and documented today. But
apparently gbp picked the IMO unwieldly name in the meantime?
Meh. But what's done is done, I guess. We'll see who will adopt that
name.
Chris
m date/time in that namespace.
Chris
allable packages.
>
> for experimental: yes, please!
> for unstable: what Helmut said & does.
My thoughts too.
Cutoff date could be more aggressive, but I don't have a strong
opinion on it.
Chris
* Andreas Metzler [241231 06:59]:
> On 2024-12-29 Helmut Grohne wrote:
> > On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> [...]
> >> I would also like to do something similar to unstable; maybe start with
> >> packages uploaded before some arbitrary date that are also not included
>
ue for various container workloads.
(And yeah, there are strategies to improve these scenarios, but it's
not "it just works" territory.)
Chris
ible.
The difference seems to boil down to "this package can be adopted
into the classic maintainership model" ('orphaned') and "this
package is someone-else-does-it-maintained and if its actually
orphaned nobody will notice".
Probably fine until actually nobody cares anymore, and then we have
a bigger mess than we already have today with actually-orphaned
packages.
Anyone who wants to introduce this concept should also describe how
these packages will be maintained/QAed/removed when all interested
people vanish.
Chris
* Julian Andres Klode [241223 12:49]:
> Something still pulls in gpgv there
> which is unfortunate, we lack a 5MB savings.
dpkg-dev Depends: gpgv | sq | ...
That seems odd. Maybe it wants gpgv | sqv | ...
instead?
If its not dpkg-dev, I don't see whats pulling gpgv.
Chris
e gone away from the "thank
> > you for using unstable, if it breaks you may keep both pieces"-approach.
>
> I think it's both? But that's for a different discussion.
I agree on both points in this line, and nevertheless stand by my
original message.
Chris
unsubscribe
On Sat, Dec 21, 2024 at 11:17 AM Debian FTP Masters <
ftpmas...@ftp-master.debian.org> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Sat, 16 Nov 2024 18:35:32 +
> Source: systemd
> Architecture: source
> Version: 252.32-1~deb12u1
> Distribution
e really wants to), but problematic uploaded
> packages to the archive are irreversible and might cause broader
> damages.
Uploads to the archive are not irreversible. You can just as well
upload a new version reverting whatever was done.
Please everybody stop treating the archive as the holy thing that
only blessed maintainers can touch. This stance helps nobody.
ITS solely for QA work is in the same boat of wrong. Just NMU.
Chris
On Thu, Dec 19, 2024 at 04:28:52PM -0500, Noah Meyerhans wrote:
> On Thu, Dec 19, 2024 at 09:53:27PM +0100, Chris Hofstaedtler wrote:
> > > > > In theory, if we don't want to explicitly install the package in d-i,
> > > > > another possibility might be to
g iputils-ping into "most" systems, why
not use the same mechanism to install linux-sysctl-defaults?
Systems that want iputils-ping likely also want
linux-sysctl-defaults.
Chris
* Marc Haber [241209 21:21]:
> On Mon, 9 Dec 2024 18:08:33 +0100, Chris Hofstaedtler
> wrote:
> >I echo Alejandro's concerns. We should stop having the flag
> >completely, not encourage using it.
>
> I violently disagree. But I have to accept this.
>
> >IO
However, I reject the idea that it is on you to apologize for LWN
covering this discussion and the harm that might have come out of
it. This is something we need to address on a wider floor. Otherwise
we lose our ability to discuss anything (and then changing anything
ever).
Best,
Chris
ill introduce bugs in all sorts of
places.
IOW: if we move towards better character support, we need to do that
by allowing it always. Same for longer names.
Chris
dd (but not adduser) that can
> be triggered by usernames beginning with "../".
It's not a bug if you disable the guard rails.
Chris
se
NAME="Fedora Linux"
VERSION="40 (Container Image)"
...
[root@cc65635fbf00 /]# useradd för
useradd: invalid user name 'för': use --badname to ignore
Not sure if mjt brought it up yet, but the sendmail interface will
also need some solution for utf8 usernames (=email address local
parts). However, it seems some sendmail implementations already
cannot cope with utf8 gecos fields.
Chris
ntially useful to any user), but that shiny future has not arrived yet,
> and in the meantime, all it does is annoy console users.
In the meantime I've added /usr/sbin to my PATH, so I get working
tab completion in my terminals for my daily work.
Good luck,
Chris
change in the tools to silently download the tarball from
> the archive will make this easy.
Obviously these hyptothetical tools will also deal with all
previously uploaded versions correctly.
SCNR,
Chris
* Paul Gevers [241128 12:52]:
> Hi,
>
> On 11/28/24 10:56, Pirate Praveen wrote:
> > pristine-tar almost always fail when there are multiple orig tar files.
> > I did not report bugs since the limitation of not working 100% is a
> > known issue already.
>
> I'm surprised to hear this. src:cacti
al way?
Yes. Looking at hardware trends, machines will be more
RAM-constrained per CPU core than ever.
IMO it would be good to support dealing with this earlier than
later.
Chris
* Marc Haber [241127 13:52]:
> On Wed, Nov 27, 2024 at 01:48:33PM +0100, Chris Hofstaedtler wrote:
> > * Marc Haber [241127 13:28]:
> > > On Wed, Nov 27, 2024 at 04:58:00PM +0500, Andrey Rakhmatullin wrote:
> > > > Yup, as I said it makes sense. It jus
o -2?).
I imagine each package can do this today, by producing an
+dfsg-1 version for each upload ...
Chris
building source packages as part of the
> process, conceptually I prefer it having all the information in the
> repository rather than having to go out to an upstream site that might
> be unreliable.
Yeah.
Chris
* Simon Josefsson [241126 16:27]:
> Chris Hofstaedtler writes:
>
> > * Jonathan Dowland [241126 12:59]:
> >> On Tue Nov 26, 2024 at 10:50 AM GMT, Andrey Rakhmatullin wrote:
> >> > Yes, as they don't enable pristine-tar
> >>
> >> Is prist
values for these as described in DEP-14. In that same ideal world, we'd
> have DEP-14 out of Draft status.
IIRC gbp has an open bug for that in the state of "please send
patches that do not break backwards compat".
DEP14 also IMO needs to make a call on the layout, and not leave
options, for any tooling to support it.
Chris
l
> >.gz ~150MB 38,51s user 6,13s system 83% cpu 53,423 total
> >.zst ~139MB 22,68s user 6,28s system 74% cpu 38,868 total
IIRC these times are for tarball creation (incl. downloading and
apt). Unpacking is AFAICT a lot faster in many cases. Locally it
feels like <1s.
Chris
ine.
Chris
from the fullname, approximating
it by a reduction to an (apparently) ASCII character set.
macOS is at least nice enough to try very hard to hide pw_name in
all graphical interfaces and show the full name instead. (IIRC you
can type the pw_name in if necessary.)
Chris
* Iustin Pop [241124 14:41]:
> On 2024-11-24 14:37:24, Chris Hofstaedtler wrote:
> > * Bjørn Mork [241124 11:45]:
> > > Johannes Schauer Marin Rodrigues writes:
> > >
> > > > But my 2 cents on the topic are: Lets please allow more than ascii in
> >
andom 32byte
string as their username. Enough humans however, do have
preferences. In some countries humans even have a right to choose
how they are being adressed.
Chris
ch might be interested
in Debian?
To maybe make the argument the other way 'round: if Google switches
to zlib-ng tomorrow, should Debian be required to switch to zlib-ng?
I just don't see that's how it works.
Chris
rustc
> C) disable all optimizations for Rust code on i386 (not really an option I
> think, just here for completeness sake)
D) follow the other teams and stop building Rust on i386.
Chris
* Jonas Smedegaard [241122 18:01]:
> > All release architectures support Rust. We should not accept
> > release architectures without Rust support.
> >
> > A minor set of ports architectures does not have Rust support
> > yet.
>
> Rust is unsupported on i386 and patched to silently assume i686
Time to get build people where they are, and not where we are.
Chris
e won't disturb his circles, more than necessary, in the meantime.
Chris
knot-module-geoip-dbgsym | 3.3.9-1 | unstable-debug | armel
and will need to be requested to be removed by filing an RM bug.
Chris
the Debian Hamradio Maintainers (I spoke with
Hibby about sponsoring the package)
Thank you!
--Chris
o fix those.
***
Having now drawn attention to the state of s390x, I hope there will
be productive outcomes.
Maybe, motivated porters will show up and maintain the architecture and
its key packages (like s390-tools).
Otherwise I suggest we save us all a lot of time and stop carrying
an in-Debian-unmaintained architecture.
Chris
g updates for bookworm is
affected, when building them on an unstable/trixie host.
It would be great if the fix could be backported to bookworm
and maybe bullseye. Aurelien Jarno mentioned that the buildds will
needs this too.
Do you have the bandwidth to drive this as a stable-update sometime
soon?
Many thanks,
Chris
e a 100% thing.
If we want the 100% solution, IMO we cannot continue with the
duality. I guess someone who knows more about distributed systems
theory probably could explain on theoretical grounds why it can't
work (or why I'm wrong).
Best,
Chris
Until
then, all sorts of setup need multipath-tools.
There is a kernel component (dm-multipath) and some integration with
lvm2 and systemd that one should also at least kinda know about.
Whoever wants to help, probably best to join the salsa group and start
making changes.
Thanks,
Chris
T
hat the machinery is working.
An interesting research topic is probably what is the non-key key
package depending on nose, and can that be fixed soon. A good
starting point might be "pkg-perl-tools", which is affected but
seems unlikely to directly depend on nose...
Chris
effort, and it often works. I think both are true for
almost all of the discussed options :-)
Chris
o work on
it needs to be found.
https://bugs.debian.org/1074250
Upstream has applied the trivial fix, but somehow that needs to flow
into Debian too.
Chris
phs/contributors
could be indicative.
But I guess the reason ifupdown2 is absent from the discussion is,
because nobody in the discussion so far was seriously looking
forward to ifupdown2 becoming one of the defaults?
Chris
* Marc Haber [240922 13:08]:
> On Sun, 22 Sep 2024 12:22:50 +0200, Chris Hofstaedtler
> wrote:
> >The "server" group supposedly wants (and I agree) networkd,
> >but they also want the configuration interface of networkd.
>
> Ack. I'd love networkd to
hen what does netplan
help here?
Given d-i then will have to make a choice, *none* of the networking
stack packages should have a "Priority:" higher than optional. As
in, even if we would go with netplan in d-i, there is no "default"
anymore and people have to make choices.
Best,
Chris
Thing doesn't break all of the
> existing systems that are running perfectly well with ifupdown and which
> clearly don't need a new thing.
Existing install can stay on ifupdown as long as it exists or maybe
even longer. Changing priorities (at least to "standard") of a
package does not magically install it on existing systems.
Chris
* László Böszörményi (GCS) [240829 20:55]:
> On Sun, Aug 25, 2024 at 11:14 PM Chris Hofstaedtler wrote:
> > Yeah, I agree. Do you want to upload a new src:fuse package dropping
> > the fuse binary package?
> > fuse3 already Provides: fuse, so that should be fine.
> T
rs sites are currently
migrating away from ifupdown to networkd, and they don't need or
want an intermediate layer.
For the desktop(-like) systems, NetworkManager works nicely, again
without a need for an intermediate layer.
Again, having the option is nice. But I don't see netplan as a
useful default.
Chris
Hi,
* László Böszörményi (GCS) [240825 18:30]:
> Thanks for adding me, I can't follow -devel.
Sorry for not thinking about that earlier
> On Wed, Aug 21, 2024 at 11:24 PM Chris Hofstaedtler wrote:
> > Updated MBF text proposal:
> [...]
> > Does that sound good?
> enabler for good production operations practices.
Don't get me wrong. Yes, we should use git to do what git is good
for (tracking changes, etc).
We should not invent new ways of using git that no one else uses.
I'd like to reduce the delta of "how Debian uses git" to "how
everyone else uses git" to, hopefully, zero.
Chris
new ways of representing Debian stuff in git, I
think it would be a good idea to learn from all the other distros
and distro-like systems successfully using git [1]. Debian is not
the only distro that wants to use git to capture changes and
encourage contributions to its packages.
Chris
[1] alpi
gt; which is what the majority of new installs already have [1].
>
> [1] compare https://qa.debian.org/popcon.php?package=fuse
> and https://qa.debian.org/popcon.php?package=fuse3
Does that sound good?
Chris
oint out that often I picked packages that saw no
maintainer uploads for many years (think 5 or more).
I suspect that many maintainers do not actually receive bug mails at
all.
For the usrmerge NMUs (all with 10 day delay and nmudiff mail etc),
a lot of maintainers were surprised to find out about the bug via
the ACCEPT mail.
Chris
latest?
Packaging for unstable? For experimental? What if both evolve in
parallel? Yes, some packages do that.
Chris
the face of the DEP18
spirit.
Maybe there is no issue with changing git-buildpackage after all
then.
Chris
hundreds of developer machines [git fails horribly
> on the upstream/ → upstream/latest change].
I want to echo this pain. When changing the layout it seems almost
better to start from scratch.
Additionally, in my opinion debian/latest is a mistake we should not
recommend.
Chris
Fellow developers,
fuse (2.x) is long obsolete, yet we still have a long tail of packages
(Build-)Depending on it. Given fuse and fuse3 are not coinstallable,
IMO we should get packages off fuse.
Below is my proposed MBF wording, and a dd-list.
Chris
---
Subject: SOURCE: move from fuse to
t analyzed what rwho(d) implementations are out there. I see
> NetBSD/FreeBSD has one still in -current, but OpenBSD removed it during
> 5.x. Are people aware of any other implementations worth considering?
IMO we should follow OpenBSD's 2015 (or earlier) decision.
Chris
if programs that are not
login-equivalents should write to wtmp in the first place.
wtmpdb upstream leans - in my vague reading - towards "no".
Chris
status is
> that one cannot have both: installing wtmpdb forces the upgrade of
> util-linux to 2.40.1-3 (at least), where "last" is no longer installed.
wtmpdb takes over the "last" name. Unfortunately without support for
reading the old files. Nobody wrote tooling to import them or so.
Chris
t sure which of the checks would be
applicable. For checks that do not rely on the implications of the
old file structure, you can probably use libwtmpdb or use
libsqlite3-0 directly.
Chris
y gaps, to provide insights on feasability and further
related comments.
I'm hoping that we can build consensus on this plan.
Please keep #1068017 in CC: when discussing substantial matters
about this plan but drop it for only vaguely related sub-threads.
Chris
[0] https://wiki.debian.o
Package: wnpp
Severity: wishlist
Owner: Chris Hofstaedtler
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: wtmpdb
Version : 0.11.0
Upstream Contact: Thorsten Kukuk
* URL : https://github.com/thkukuk/wtmpdb
* License : BSD
Programming Lang: C
ed to happen at the same time.
Chris
signature.asc
Description: PGP signature
Package: wnpp
Severity: wishlist
Owner: Chris Keller
* Package name: golang-github-mazznoer-csscolorparser
Version : 0.1.2-1
Upstream Author : Nor Khasyatillah
* URL : https://github.com/mazznoer/csscolorparser
* License : Expat
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Chris Keller
* Package name: golang-github-mazznoer-csscolorparser
Version : 0.1.1-1
Upstream Author : Nor Khasyatillah
* URL : https://github.com/mazznoer/csscolorparser
* License : Expat
Programming Lang: Go
uot;/dev/sd...", O_DIRECT | ...).
[1]
https://github.com/torvalds/linux/commit/603e4922f1c81fc2ed3a87b4f91a8d3aafc7e093
[2] https://github.com/karelzak/util-linux/issues/1442
Chris
1.45:
Upstream change:
https://github.com/hreinecke/sg3_utils/commit/b0042ccf801d0008c0f9f090ea93b3871e8a542e
("add ${PACKAGE_VERSION} to '.so' name")
*Maybe* libsgutils2-2 should now also carry the version in its
package *name* :-(
Chris
Control: reopen 989370
Control: reassign 989370 ifupdown
Reassigning to ifupdown, which is the package having the
/etc/network/interfaces conffile.
Chris
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-v...@lists.debian.org
Let's make a petition about a google employee
Put their name in the subject line and attack them every day for a month
stop taking the google money you pathetic hypocrites
stop telling us a
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-v...@lists.debian.org
Matthias Kirschner sacked Susanne Eiswirt and Galia Mancheva when they spoke
about wage equality
They went public in December 2020
Nobody started a petition against the FSFE fascists
www.g
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-v...@lists.debian.org
Paul Tagliamonte betrayed Jacob Appelbaum while working at the White House
He sent multiple (leaked) messages on debian-private whinging and whining that
he doesn't feel safe
How can somebo
Package: wnpp
Severity: wishlist
Owner: Chris Keller
* Package name: golang-github-leemcloughlin-jdn
Version : 0.0~git20201102.6f88db6-1
Upstream Author : Lee McLoughlin
* URL : https://github.com/leemcloughlin/jdn
* License : Expat
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Chris Keller
* Package name: wsjtx-go
Version : 1.1.0-1
Upstream Author : Chris Keller
* URL : https://github.com/k0swe/wsjtx-go
* License : Apache-2.0
Programming Lang: Go
Description : Golang binding for the
Package: wnpp
Severity: wishlist
Owner: Chris Keller
* Package name: kel-agent
Version : 0.0~git20201103.9b8976a-1
Upstream Author : K0SWE
* URL : https://github.com/k0swe/kel-agent
* License : Apache-2.0
Programming Lang: Go
Description : An agent
1 - 100 of 1085 matches
Mail list logo
