away from our mailing lists and other
venues.
Chris
isable the "Allow edits
and access to secrets by maintainers" checkbox.
Also works on GitLab / salsa.
The documentation about this is, as usual, crap.
Chris
rg/t/troubles-with-keyboad-layout-switching/28491
>
> Generally problem solved, but by indirect way
Chris
Control: reassign -1 src:linux
On Sun, Oct 24, 2021 at 09:13:54AM -0300, Antonio Terceiro wrote:
> There is https://gitlab.freedesktop.org/drm/intel/-/issues/3510 which
> looks similar, and happens to me.
Apparently this is a bug in the i915 drm driver, reassigning to
src:linux.
Chris
by default with other Linux distributions like
> Fedora.
> It is useful to optimize performances for gaming.
> This setting increases memory allocated to the game.
Thanks,
Chris
(graphical) desktop you were using, and in which programs this
problem appears.
If possible please reassign this bug to the package you suspect
changed and caused the problem to appear.
If you need help with this, please see
https://www.debian.org/support for user support venues.
Chris
Control: reassign -1 src:linux
Hi Linux maintainers,
sorry for reassigning bugs to you, but this sounds like a driver
issue. There's lspci and dmidecode output in the bug.
Chris
On Mon, Jun 03, 2024 at 05:09:18PM +0200, Christian Böck wrote:
> On Mon, 3 Jun 2024 12:42:17 +0200 Andriu
Control: reassign -1 kde-plasma-desktop
Hi Plasma maintainers,
this looks like a bug for you.
Chris
On Tue, Jun 24, 2025 at 07:01:20PM +0200, Hoareau J.P. wrote:
> Here's a serious password rejection issue affecting sleep, lock, log out, and
> hibernation on my desktop and lapto
works ok.
Given this appears to be a kernel problem, I'm reassigning this bug
to src:linux.
I'd appreciate it if you could close the bug, if you deem it solved.
Chris
Control: reassign -1 xserver-xorg
On Mon, May 22, 2023 at 09:48:31AM +0200, Tomas Pospisek wrote:
> Since this seems to be a xserver problem, could you please reassign the
> ticket to the correct xserver package?
Doing that.
Chris
Control: reassign -1 virtualbox-guest-dkms
Hi VirtualBox maintainers,
this is apparently a bug for you, which was filed against "general".
Chris
On Wed, Jun 14, 2023 at 01:12:42PM -0400, Bert Nijhof wrote:
> Debian was a fresh install. I tried to install VBox Guest Addtions like
On Thu, Jul 24, 2025 at 02:43:27AM +0200, Chris Hofstaedtler wrote:
> On Sun, Jul 13, 2025 at 10:29:25AM +0200, Helmut Grohne wrote:
> > Hi Chris,
> >
> > On Sat, Jul 12, 2025 at 12:36:20AM +0200, Chris Hofstaedtler wrote:
> > > I was somewhat hoping this is caused
ebian itself it is beneficial if such packages don't land
in unstable. For one, it avoids other packages using them to build
(when they then cannot migrate). And it keeps the QA list down.
Thanks,
Chris
On Sun, Jul 13, 2025 at 10:29:25AM +0200, Helmut Grohne wrote:
> Hi Chris,
>
> On Sat, Jul 12, 2025 at 12:36:20AM +0200, Chris Hofstaedtler wrote:
> > I was somewhat hoping this is caused by the existing upgrade issue which
> > Helmut is working on AFAIU. Was it proven that
ill also install a program names "sr" into a
PATH component, then you will need to find a solution together with
surfraw.
Maybe one or both of the packages will need to rename their
programs.
Chris
systems actually running this init system?
The debhelper helpers always guard deb-systemd-invoke invocations by
a systemd check.
Maintainers directly calling deb-systemd-invoke need to write the same
code.
Chris
sting upgrade issue
which Helmut is working on AFAIU. Was it proven that this is not the
same problem?
Chris
* Richard Lewis [250703 23:18]:
Cyril Brulebois writes:
Chris Hofstädtler (2025-07-02):
in a discussion today on IRC #debian-devel, it was mentioned that
cron is "important". However during the trixie development cycle,
many more packages started installing systemd timer unit
On Wed, Jul 02, 2025 at 05:29:58PM +0200, Cyril Brulebois wrote:
> Hi,
>
> Chris Hofstädtler (2025-07-02):
> > in a discussion today on IRC #debian-devel, it was mentioned that
> > cron is "important". However during the trixie development cycle,
> >
Aurélien COUDERC schreef op za 21-06-2025 om 22:57 [+0200]:
> If you could share the bits of the system logs before sleep / after
> wake that would probably be useful.
I have installed Opensuse Tumbleweed now on my laptop.
I have reported these 'problems' on discuss.kde.org since it does not
seem
running KDE/Plasma 5.x.
So it seems like a regression in KDE/Plasma 6.x
My appologies that I can not be more specific as I really do not know what is
causing this.
Thank you for your time,
Chris Maaskant.
namespace has a different "default" for
package repositories. Other groups get (I think) the GitLab default,
which is to do notify.
Chris
elped them:
https://support.yubico.com/hc/en-us/articles/4819584884124-Resolving-GPG-s-CCID-conflicts
Chris
's the status of such packages?
They have open bugs that need fixing.
For example:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039171
Chris
gradle), and
then be baked into it (and maybe also be configurable at runtime).
Chris
Master override, see
http://ftp.debian.org/debian/indices/override.sid.extra.main.gz.
Double-Thanks! (This seems likely true for all packages with
Build-Essential: yes)
Does anything actually _use_ the Build-Essential: yes line?
Chris
e on src:shadow.
Thanks,
Chris
handles core dumps.
Chris
nclear how that should look like, and what
it powers should or even could be.
So we end up with informal SIGs (to not use "cabals"), and at best a
post to d-devel.
Chris
* Marc Haber [250428 08:40]:
On Sun, 27 Apr 2025 15:13:00 +0200, Chris Hofstaedtler
wrote:
As long as people want to use adduser, I think/hope they'd be
grateful for its existence and continued maintenance?
As far as I was told, using sysusers is going to be mandatory soon, to
help
sysusers files?
As long as people want to use adduser, I think/hope they'd be
grateful for its existence and continued maintenance?
Best,
Chris
r creation?
Unsure about users, but a general thing I'm seeing is: moving away
from (adhoc) maintainer scripts to declarative configuration.
Now these also often use (automatically generated) maintainer script
fragments, but it seems to be a step towards having no maintainer
scripts o
* 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
1 - 100 of 1118 matches
Mail list logo
