* Vincent Lefevre [250507 11:06]:
I can see in journalctl output:
May 07 10:25:13 qaa systemd-sysv-generator[1476564]: SysV service
'/etc/init.d/dictd' lacks a native systemd unit file, automatically generating
a unit file for compatibility.
May 07 10:25:13 qaa systemd-sysv-generator[1476564]
* Simon Josefsson [250506 11:35]:
I'm doing archive-wide package rebuilds in GitLab CI/CD and my toolchain
uses 'setpriv --reset-env' to drop privileges and reset the environment
variables, which results in:
PATH=/usr/local/bin:/bin:/usr/bin
This unusual ordering appears to be intentional for
* Jonathan Dowland [250428 18:02]:
On Mon Apr 28, 2025 at 4:46 PM BST, Sven Joachim wrote:
On 2025-04-28 15:57 +0100, Jonathan Dowland wrote:
Thanks! For reasons I cannot explain, installing build-essential (in a
Salsa CI environment) did not pull in perl.
The tag is coming from an FTP Mast
* Marc Haber [250428 12:31]:
On Mon, 28 Apr 2025 11:34:18 +0200, Andreas Tille
wrote:
Am Mon, Apr 28, 2025 at 11:02:13AM +0200 schrieb Marc Haber:
That's my biggest gripe about Debian. It strongly influences the only
voice I have in that regard, the DPL vote.
... speaking as DPL I was also
* Bastien Roucaries [250501 17:41]:
Le jeudi 1 mai 2025, 17:26:34 heure d’été d’Europe centrale Jochen Sprickerhof
a écrit :
mmdebstrap --variant=apt --arch=i386 --chrooted-customize-hook=bash unstable
/dev/null
Do not get my core file in container /var/lib/systemd/coredump/ but in host /
var/
* Marc Haber [250428 08:52]:
This is one more example of Debian lacking technical leadership, with
small groups taking technical decisions for the entire distribution
without even mentioning.
Yeah. There's always talk about some form of technical leadership
group, but it's always unclear how
* 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
* Marc Haber [250427 14:18]:
On Sun, 27 Apr 2025 12:52:57 +0200, Geert Stappers
wrote:
For what it is worth: I use `adduser` outside maintainer script.
I think I'm not alone in that.
Useradd has grown most of that functionality in the last two decades.
That leaves no space for adduser betwe
* Marc Haber [250427 08:16]:
On Sat, 26 Apr 2025 22:29:07 +0200, Bastian Blank
wrote:
While you are at it, please switch to sysusers (see dh_installsysusers).
While we're at this, I would like to ask the developer commiunity
whether it is true that we have dedided to go away from having
pers
* 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
* Josh Triplett [250421 03:07]:
Let's rather talk about what Debian should officially support,
and how Josh Triplett plans to implement it.
I would be more than happy to work on it, in collaboration with others
proposing such changes. I expect that such work consists of 10% doing
careful archi
* Michael Stone [250419 15:47]:
On Fri, Apr 18, 2025 at 10:17:12PM +0100, Jonathan Dowland wrote:
They likely lack perl, as well. Most/all awk usage in maintainer
scripts could probably be replaced with perl. But, if you are in the
minimizing game, perhaps you'd rather remove perl from the ess
:18.0 +0200
@@ -1,3 +1,11 @@
+git (1:2.49.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Disable building with libcurl.
+
+ -- Chris Hofstaedtler Sun, 13 Apr 2025 22:18:18 +0200
+
git (1:2.49.0-1) unstable; urgency=low
* new upstream release (see RelNotes/2.48.0.adoc
* Dirk Lehmann [250408 17:20]:
in relation to the discussion of 'utmp in trixie'
* https://lists.debian.org/debian-devel/2025/04/msg00011.html
It looks like, that wtmp is an well alternative to who(1). For that
the command
$> last -p now
should be able to use in the future. But the devel
* Michael Stone [250403 23:42]:
On Thu, Apr 03, 2025 at 07:52:12PM +0200, Marco d'Itri wrote:
On Apr 03, Michael Stone wrote:
The issue isn't making a change, the issue is what change is the
right thing to do. IMO, dropping utmp without any kind of a
transition or deprecation period is the w
* Otto Kekäläinen [250306 19:57]:
> Salsa CI has had for many years the job 'missing-breaks' that
> complements piuparts by checking that the files a package introduce
> don't clash with files shipped by any other package in the
> distribution without having proper Breaks/Replaces in the
> `debi
* Charles Plessy [250227 10:12]:
> Le Thu, Feb 27, 2025 at 03:02:08PM +0800, Sean Whitton a écrit :
> >
> > Packages that already install programs to /usr/games, where another
> > package installs a program of the same with different functionality
> > to a different directory on the d
Hi,
> I think a way forward could be to make the sanitizing the default, and
> finally drop debian/rules as a supported (user) build entry point, I had in
> mind re-proposing this already, but the above kind of gives it more urgency,
> so
> I'll try to do that soon.
Given I ran into this discrep
* Charles Plessy [250218 01:07]:
> On the other hand, we also rely on "the ecosystem" to do the work by
> themselves so that the packages eventually start to build fine with GCC
> 15 them after we upgrade them to newer upstream versions. But who will
> close the hundreds of bugs? I mean, query t
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
* Colin Watson [250214 18:13]:
> On Fri, Feb 14, 2025 at 03:28:35PM +0100, Marc Haber wrote:
> > Especially if the list just goes the (wrong) way of so many commercial
> > security tools and/or consultants who just compare version numbers and
> > flag our stable versions as vulnerable regardless w
* Santiago Ruano Rincón [250213 20:21]:
> Here attached you can find a list of packages that have ever had a
> security issue **and** whose packaged version is not "up to date",
> according to the uscan results. It is sorted by the number of currently
> open CVEs in sid (the first "column"), and b
* Charles Plessy [250128 01:44]:
> Hello everybody,
>
> How about debian/default or debian/devel?
Yes please do a few more changes to the names, so everybody can pick
whatever they like ("it was fine back then"), and everone who went
under a painful migration to the current scheme can either
exp
* Sam Hartman [250123 23:47]:
> > ...
> >> > Numerous people are posting Merge Requests on Salsa. Please
> >> help review them!
>
> I think it would improve collaboration a lot if we could make an effort
> to get salsa projects into one of two states:
>
> * Merge requests are disabled fo
* Julien Plissonneau Duquène [250116 19:09]:
> Le 2025-01-16 18:36, Niels Thykier a écrit :
> > Putting the scripts into `devscripts` package would imply that
> > `devscripts` becomes part of the `bootstrap essential` set of packages.
>
> I didn't think about that and it effectively rules out dev
* Jonas Smedegaard [250115 11:40]:
> Quoting Andrej Shadura (2025-01-15 11:24:31)
> > Hello,
> >
> > On Tue, 14 Jan 2025, at 18:01, Jonas Smedegaard wrote:
> > >> >> >Then let's move to the tinker team mailinglist:
> > >> >> >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-d
* Otto Kekäläinen [250114 23:14]:
> Numerous people are posting Merge Requests on Salsa. Please help review them!
>
> There is no single dashboard to show all Merge Requests for all Debian
> packages, but here are the largest teams listed to show how many they
> have open (and total count in pare
* Raphael Hertzog [250107 08:39]:
> 1/ https://salsa.debian.org/dep-team/deps/-/merge_requests/9
> (see mr9.patch attached if you don't want to look up on the web)
>
> We had a couple of revisions already and it seems fine to me to merge
> this, if anyone has valid objections (i.e. with good rati
Hi,
* Otto Kekäläinen [250105 21:54]:
> Thanks for encouragement. I filed
> https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/411 and will
> continue research on libfaketime/datefudge in CI there.
as we've seen in the time_t-64 transition, programs that interpose
library calls like this a
* Holger Levsen [250102 13:03]:
> 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 experiment
* 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
>
* Simon Richter [241226 13:24]:
> My feeling is that this is becoming less and less relevant though, because
> it does not matter with SSDs.
This might be true on SSDs backing a single system, but on
(otherwise well-dimensioned) SANs the I/O-spikes are still very much
visible. Same is true for va
* Andreas Metzler [241224 11:53]:
> On 2024-12-23 Gioele Barabucci wrote:
> > On 22/12/24 06:56, Andreas Metzler wrote:
> >> On 2024-12-22 Sean Whitton wrote:
> >>> On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:
>
> We have a mechanism for when you feel responsible: "Maintainer
* 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
* Andrey Rakhmatullin [241222 10:15]:
> On Sun, Dec 22, 2024 at 07:26:15AM +0100, Andreas Metzler wrote:
> > >> 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 h
* Boyuan Yang [241221 18:10]:
> 在 12/21/2024 12:02 PM, Jeremy Sowden 写道:
> > On 2024-12-21, at 17:55:39 +0100, Marc Haber wrote:
> > > On Sat, 21 Dec 2024 12:08:35 +0100, Tobias Frost wrote:
> > > > We DO already have the debian namespace on salsa, everything in this
> > > > namespace is "team mai
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
On Thu, Dec 19, 2024 at 12:12:13PM -0500, Noah Meyerhans wrote:
[..]
> > > In theory, if we don't want to explicitly install the package in d-i,
> > > another possibility might be to bump it to Priority: standard and let
> > > tasksel install it. I'm not sure what the tradeoffs might be that would
* 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
* Marc Haber [241205 18:06]:
> P.S.: Sadly, this has gotten less than positive coverage on LWN. I
> apologize for the harm this discussion has done.
Marc, my thank you for collecting the info on the wiki, and starting
this discussion. I'm sorry I was not able to participate more.
However, I reje
* Marc Haber [241203 22:06]:
> On Tue, Dec 03, 2024 at 08:41:06PM +0100, Étienne Mollier wrote:
> > Marc Haber, on 2024-12-03:
> > > I'll probably deprecate --allow-bad-names in favor of something that
> > > doesn't use the word "bad" (suggestions appreciated). Otoh, adduser in
> > > the Red Hat W
* Ben Kallus [241208 21:35]:
> I second calling it "allow-unsafe-names"
This was never on the table, and shadow upstream might even drop the
entire "support" for having bad names.
> for the following reasons:
[..]
> 2. There's a path traversal bug in useradd (but not adduser) that can
> be tri
* Marc Haber [241202 09:43]:
> On Sun, Dec 01, 2024 at 06:55:09PM -0500, nick black wrote:
> > Marc Haber left as an exercise for the reader:
> > > > * any upstream tool could say "bad idea" and refuse patches,
> > > >requiring their long term management,
> > >
> > > Depending of how importa
* Simon Richter [241202 12:20]:
> Hi,
>
> On 12/2/24 18:39, Jonathan Dowland wrote:
>
> > This is not correct. Whether any of /usr/bin,/usr/sbin,/bin or /sbin
> > share a partition or not has no relationship to whether a user can
> > invoke a command, or whether that path is searched for unquali
* Andrey Rakhmatullin [241128 11:06]:
> On Thu, Nov 28, 2024 at 10:49:09AM +0100, gregor herrmann wrote:
> > > > As person B I don't want to go hunting for a tarball and place it in
> > > > the right place, I want gbp to re-create it from the pristine-tar
> > > > branch.
> > > Who cares? gbp expor
* 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
* Helmut Grohne [241128 10:59]:
> 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 a more general way?
Yes. Loo
* 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
* 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 just feels fragile to me when the
> > "pristine" tarball for a given upstream tag in a given repo is not
> > determined until someone uploads it.
>
> I would l
* Colin Watson [241126 23:34]:
> On Tue, Nov 26, 2024 at 09:25:12PM +0100, Simon Josefsson wrote:
> > Colin Watson writes:
> > > CI for a new-upstream-release commit you've pushed but haven't uploaded
> > > to the Debian archive yet, because you're waiting for CI.
> > >
> > > pristine-tar certain
* 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
* 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 pristine-tar still valuable these days?
Unfortunately yes. AFAIK the two options for fixing this that are
usually proposed are:
1) treat it as a
* Soren Stoutner [241125 18:30]:
> > > In principle, unshare mode can also work with directories. Helmut is
> working
> > > on something in that direction. But for me personally, one second of
> unpack
> > > time is not enough of a motivation for me to put time into
> > > directory+overlayfs sup
* Paul Gevers [241124 18:51]:
> [Release Team hat on] I would take consensus for a decision on the topic.
Based on my casual reading up on what other distros did before us,
many years ago, ISTM raising the baseline to at least SSE2 would be
a very good idea.
Next up: raising the amd64 baseline.
* Simon McVittie [241124 15:20]:
> As a data point, in our default GNOME desktop, System Settings
> (gnome-control-center) prompts for a "Full Name" first (behind the
> scenes that's the full name part of the pw_gecos field), and a "Username"
> second (this is the pw_name); and the default display
* 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
> >
* 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
> > usernames. I find it very uncomfortable every time I have to tell my
> > students
> > that sorry, you somehow have to manage writing your name
* Fay Stegerman [241123 19:58]:
> I agree that it *should not* be Debian's responsibility to ensure
> compatibility
> with Fedora/Windows/etc., but the reality is that if "you need the same tools
> to
> generate the same output" -- which right now means using the same JDK and
> Android toolchain
* Fabian Grünbichler [241123 15:31]:
> A) move i386 rustc to Rust's i586 target (which doesn't have SSE out of the
> box), instead of the i686-with-SSE2-disabled it currently uses
> B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2
> there in rustc
> C) disable all opt
* 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
* Holger Levsen [241121 12:26]:
> and you seem to think adding another Debian specific complex tool will
> attrack new people? Most people^wcontributors out there know git already,
> for them a simple git only workflow is *much* more inviting than having
> to learn gbp *only* to contribute to Debi
* M Hickford [241109 12:45]:
> On Mon, 1 Apr 2024 at 21:42, M Hickford wrote:
> >
> > Hi. It'd be great to package Git credential helper
> > git-credential-libsecret in Debian. There's a patch prepared, but it
> > needs the attention of a Debian developer. Is anyone here able to
> > help? https:
* Niels Thykier [241108 14:12]:
> Jakub Ružička:
> > I've fixed #1081191 through changelog entry in knot/3.4.0-3 and it's
> > marked as Done but the bug still blocks knot migration for reasons I
> > don't understand:
> > https://qa.debian.org/excuses.php?package=knot
>
> The problem is that the B
Hello!
I want to draw attention to, from my point of view, open
questions/problems with the s390x architecture.
In short, it seems to me, that:
a) there are no porters left (to fix serious problems)
b) various packages already ignore s390x (gnome? others?)
c) general, including upstreams, interes
Control: found 1072521 fakeroot/1.25.3-1.1
Control: found 1072521 fakeroot/1.31-1.2
(CCing d-devel@ for awareness)
Hi Clint,
On Wed, Jun 05, 2024 at 07:54:07PM +, Debian Bug Tracking System wrote:
> fakeroot (1.35-1) unstable; urgency=medium
> .
>* New upstream version.
> - Use cl
* Andreas Henriksson [241025 08:56]:
> > I wanted to check if anyone knows any better techniques or mechanisms
> > than trying to remember to run this command manually before working on
> > a package?
>
> I would very much prefer if it was possible in Debian to not allow
> the archive to get out
Package: wnpp
Severity: normal
X-Debbugs-Cc: multipath-to...@packages.debian.org,
debian-devel@lists.debian.org, team+linux-blo...@tracker.debian.org,
a...@debian.org, r...@debian.org, mitchell.dzur...@canonical.com
Control: affects -1 + src:multipath-tools
I request assistance with maintaining
* Alexandre Detiste [240927 10:07]:
> "nose" is RC buggy. It was until a few days ago in the "key packages set".
[..]
> What was not expected is that nose started the autoremoval counter of
> seemingly ~700 unrelated packages.
>
> How this does work :-| ?
I imagine exactly like you are seeing it
* Pierre-Elliott Bécue [240923 11:34]:
> Lukas Märdian wrote on 20/09/2024 at 13:12:36+0200:
> > # Why
> > The ifupdown package is a Debian only solution that is becoming a
> > maintenance
> > burden. We've had plenty of discussions over the years and consensus is
> > that we
> > want to get ri
* Holger Levsen [240923 12:05]:
> > ifupdown2 will still be around for anybody who wants to install it.
>
> sure.
Except that right now it has an open r-c bug since June 25, and is
missing from testing since August 6th.
If people want to continue having it, somebody who wants to work on
it need
* 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.com/CumulusNetworks/ifupdown2/pulse/monthly and
https://github.com/CumulusNetworks/ifupdown2/graphs/cont
* 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
* Lukas Märdian [240920 13:13]:
> I've repeated the reasons why I think a hybrid stack using Netplan is a
> feasible solution many times in previous threads, therefore I'd like to refer
> to a list of frequently asked questions, instead of spreading more reasons
> across more replies: https://wiki
* Michael Stone [240916 05:04]:
> On Tue, Jul 09, 2024 at 10:57:39AM +0200, Matthias Urlichs wrote:
> >Agreed: either it's drop-in compatible or we may as well switch the
> >default to NM and/or systemd-networkd.
> >
> > Well, here's a heretical thought: why don't we do that anyway, at le
* 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
* Marco d'Itri [240903 14:04]:
> My position is that I am happy for Debian to have the option of netplan
> but I do not think that it should be installed by default, because it is
> an abstraction which adds complexity and that nobody asked for other
> than its developers.
>
> And this is an o
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?
* rsbec...@nexbridge.com [240822 01:21]:
> >> Any feelings/objections/missed requirements?
> >
> >In the current DEP14/DEP18 discussions a lot of discussion was had about how
> >we
> >should represent Debian things in git; your mail also goes into this
> >direction.
> >
> >My *feeling* is we sho
Hi Simon,
* Simon Richter [240820 09:11]:
> One of the long-standing issues is that there are multiple ways Debian
> packaging can be represented in a git tree, and none of them are optimal.
[..]
> A possible implementation would be a type of Git "user extension" object
> that contains
>
> - an
Stephen,
and everyone else who pointed out that coinstallability is a
non-issue - thanks!
About the additional work in fuse/fuse3, #918984 and #927291, I
wonder if they are relevant to the libfuse consumers. Anyway, if we
believe fuse3 works just fine with libfuse2-* consumers, then it
seems like
* Scott Kitterman [240820 14:35]:
> On August 20, 2024 12:16:47 PM UTC, Andrey Rakhmatullin
> wrote:
> >On Tue, Aug 20, 2024 at 12:12:33PM +, Scott Kitterman wrote:
> >> There are people doing this, we could use more, but it does
> >> happen. I've processed lots of these and it's virtually
> > Additionally, in my opinion debian/latest is a mistake we should not
> > recommend.
>
> Please elaborate why you consider it a mistake. That's not obvious to
> me.
"latest" is illnamed. What do you expect to find in a branch thats
called debian/latest?
Packaging for unstable? For experiment
> That's correct but the teams I'm working in recommend something
> like:
> Add the following to the configuration file ~/.gbp.conf or
> debian/gbp.conf:
Putting per-repository relevant settings into a global config and
not into the per-repo config seems to fly into the face of the DEP18
On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote:
> IMO, and from discussions in the Debian Perl Group, the blocker is
> the conversion of existing repos, both on salsa (which should be
> doable via the API as suggested in the sketches mentioned above) and
> also locally for hundreds of de
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 fuse
On Fri, Jul 05, 2024 at 09:24:18AM +0200, Simon Josefsson wrote:
> First, I think we need to understand the rationale for doing anything
> about 'netkit-rwho': do we want to do something because 1) it is not
> maintained upstream? or 2) because it is an insecure design?, or 3)
> something else?
At
* Jun MO [240530 19:09]:
> On Thu, 30 May 2024 13:18:17 +0200, Vincent Lefevre wrote:
> > I agree, this may be useful. Unfortunately, the current 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 instal
* Vincent Lefevre [240530 13:21]:
> On 2024-05-08 16:53:53 +0800, Jun MO wrote:
> > For last(1) my concern is that it will be helped to keep the original
> > last(1) for back-compatibility to read old wtmp files.
>
> I agree, this may be useful. Unfortunately, the current status is
> that one can
On Fri, Apr 26, 2024 at 08:06:15PM +0100, RL wrote:
> the chkrootkit package provides several utilities for examining some of
> these files: chkutmp chkwtmp and check_wtmpx and chklastlog [a] -- it does
> not use pam but reads the files in /var/log
>
> How would I test these against the new files
Fellow Developers,
you are probably aware of the time_t-64bit migration :-)
However, this does not magically transition all data formats to 64bit
times. One such instance is the set of utmp/wtmp and lastlog files.
Thorsten Kukuk and others have been working on replacements for the
existing file f
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
Hi Helmut,
speaking with my util-linux in Debian hat...
* Helmut Grohne [230912 20:16]:
[..]
> I request that affected maintainers reply to this mail:
> * Are you ok with the proposed changes in principle?
>+ Moving all files from / to /usr leaving no files in aliased
> locations
>
Hi everyone,
Linux 5.14 dropped the "raw" block/char driver [1], and removedthe
userspace API. This driver has been deprecated since 2005.
util-linux used to ship an /sbin/raw binary to setup raw character
devices. Given the userspace API has been removed, the binary cannot
be built anymore [2] (
* Hsieh-Tseng Shen [210920 16:54]:
> The ledmon package was reported by
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994521 to cause ledmon
> service was unable to run due to the broken dependency of libsgutils2-2.
>
> It seems like the softlink will keep changing since 1.45:
Upstream cha
Control: reopen 989370
Control: reassign 989370 ifupdown
Reassigning to ifupdown, which is the package having the
/etc/network/interfaces conffile.
Chris
Hello Ryan Goodfellow,
thank you for your report. However, please see below.
* Ryan Goodfellow :
> Video playback does not seem to be working in any browser in Debian
> Bullseye.
>
>* What led up to the situation?
> apt update
> apt dist-upgrade
[..]
>- Chromium crashes, which seems to be re
Control: reassign -1 jackd
Reassigning to jackd (metapackage), as it's not clear (to me) which
version of jack is involved, and further details are likely needed.
Hopefully the jack / Debian Multimedia maintainers can figure
something out from here.
Please do not reassign this bug back to general
Control: reassign -1 libx11-6
XCompose appears to be a libX11 feature, reassigning there.
Best,
Chris
Hi,
thanks for your interest in making Debian better and filing
this report:
* G Bradsly :
> In Debian 9 I had 4 analog inputs, 2 analog outputs, an in and out s/pdif and
> an in and out midi
> In Debian 10 I have only 2 analog inputs, the analog outputs, s/pdif i/o and
> midi i/o are the same.
>
Control: reassign -1 linux-image-4.19.0-6-amd64
Control: retitle -1 i915 workqueue issue / i915_hotplug_work_func
__flush_work.cold.53
Hi sanshu,
thank you for your interest in making Debian better and filing this
report:
* sanshu [200830 22:46]:
> [2.158101] [ cut here ]--
1 - 100 of 106 matches
Mail list logo
