Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Hi, On 5/21/24 15:54, Andrey Rakhmatullin 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 mandated. The

Re: Any volunteers for lintian co-maintenance?

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

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Hello, On Sun 19 May 2024 at 10:05am +02, Paul Gevers wrote: > > PS: I've always wondered if the dgit server shouldn't track history, even if > uploads don't happen via it. A dgit clone could (should?) already provide > available history, even if no upload happened via it yet. Well, 'dgit

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Hello, On Sun 19 May 2024 at 12:32pm -07, Otto Kekäläinen wrote: > You could go to > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and > conduct a code review? > > You might discover that GitLab is useful and is not duplicating > Debbugs or anything else in Debian - it is

Re: finally end single-person maintainership

On Tue, May 21, 2024 at 12:05:59PM +0200, Philip Hands wrote: > >> > All these things should make it much more easy for other people or > >> > automated tools to send merge requests or keep maintaining a > >> > package in > >> > case the original maintainer becomes MIA. > >> > >> > >> Mandating

Re: finally end single-person maintainership

On Mon, 20 May 2024 at 19:10:00 -0700, Otto Kekäläinen wrote: > Exact quote: "These commits have intentionally no debian/changelog > updates as it causes every single rebase or cherry-pick of a commit to > always have a merge conflict. It is much better to have all commits > as-is, and then right

Re: finally end single-person maintainership

On Tue, 21 May 2024 at 03:16, Simon Richter wrote: > > Hi, > > On 5/21/24 10:43, Luca Boccassi wrote: > > >> The ecosystem, however, does not support our workflows, and adapting it > >> to do that is even more effort than maintaining our own tools. [...] > > > That's a problem of our workflows,

Re: finally end single-person maintainership

Bernd Zeimetz writes: > On Mon, 2024-05-20 at 20:47 +, Scott Kitterman wrote: >> > >> > All these things should make it much more easy for other people or >> > automated tools to send merge requests or keep maintaining a >> > package in >> > case the original maintainer becomes MIA. >> >>

Re: About i386 support

Andrey, On Tue, May 21, 2024 at 3:31 AM Andrey Rakhmatullin wrote: > > On Mon, May 20, 2024 at 07:16:54PM -0300, Leandro Cunha wrote: > > > > > which is good news. The end of support for 32 bits will not > > > > > affect the lives of almost anyone who has machines purchased after > > > > > 2011

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote: > > My concern about Gitlab is not its *additions* to existing services, but > > its *duplications* of core services already in Debian. > > I agree, that's the key problem. > > The Debian archive itself is a VCS, so git-maintained

Re: finally end single-person maintainership

On Tue, May 21, 2024 at 12:32:52AM +0200, Bernd Zeimetz wrote: > > > All these things should make it much more easy for other people or > > > automated tools to send merge requests or keep maintaining a > > > package in > > > case the original maintainer becomes MIA. > > > > > > Mandating a

Re: About i386 support

On Mon, May 20, 2024 at 07:16:54PM -0300, Leandro Cunha wrote: > > > > which is good news. The end of support for 32 bits will not > > > > affect the lives of almost anyone who has machines purchased after > > > > 2011 and who bought them after that > > > > > > Does this also mean he support for

Re: finally end single-person maintainership

Simon Richter writes: > A better approach would not treat Debian metadata as git data. Even the > most vocal advocate of switching everything to Salsa writes in his MR > that the changelog should not be touched in a commit, because it creates > conflicts, and instead a manual step will need to

Re: finally end single-person maintainership

Hi, On 5/21/24 10:43, Luca Boccassi wrote: The ecosystem, however, does not support our workflows, and adapting it to do that is even more effort than maintaining our own tools. [...] That's a problem of our workflows, which are horrible. The solution is not to double down on them. Our

Re: finally end single-person maintainership

Hi Simon! > > A better approach would not treat Debian metadata as git data. Even the > > most vocal advocate of switching everything to Salsa writes in his MR > > that the changelog should not be touched in a commit, because it creates > > conflicts, and instead a manual step will need to be

Re: Bug#1071528: ITP: hardinfo2 -- Hardinfo2 offers System Information and Benchmark for Linux Systems

Em 20/05/2024 22:53, xiao sheng wen(肖盛文) escreveu: Hi,   I had report bug #1070830[1], hardinfo package change upstream repo to hardinfo2 also is a better way. IMHO, hardinfo2 only is the new version of hardinfo, it's not necessary to ITP a new hardinfo2 src package in Debian. The new

Re: Bug#1071528: ITP: hardinfo2 -- Hardinfo2 offers System Information and Benchmark for Linux Systems

Hi,   I had report bug #1070830[1], hardinfo package change upstream repo to hardinfo2 also is a better way. IMHO, hardinfo2 only is the new version of hardinfo, it's not necessary to ITP a new hardinfo2 src package in Debian. The new version has a new binary package named hardinfo2 is no

Re: finally end single-person maintainership

On Tue, 21 May 2024 at 02:08, Simon Richter wrote: > > Hi, > > On 5/21/24 07:43, Bernd Zeimetz wrote: > > > Also its a gitlab instance. There are all kinds of documentation, > > tutorials, videos and software for/about gitlab, including lots of > > beginner friendly options. There is a whole

Re: finally end single-person maintainership

Hi, On 5/21/24 07:43, Bernd Zeimetz wrote: Also its a gitlab instance. There are all kinds of documentation, tutorials, videos and software for/about gitlab, including lots of beginner friendly options. There is a whole ecosystem around gitlab, it does not depend on a few (two?) developers.

Re: finally end single-person maintainership

On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote: > > When a change leads to a RC bug a month or three after having be > part of a package, fixing the problem falls on the maintainer and not > on the change author. Even correct changes can trigger latent bugs > in software. Yet another

Re: finally end single-person maintainership

On Wed, 2024-04-10 at 23:16 +0200, Johannes Schauer Marin Rodrigues wrote: > Quoting Andreas Tille (2024-04-10 22:44:25) > > > I do understand the argument that lots of different workflows > > > adds > > > friction. But I'm just still using what used to be _the_ standard > > > one > > > (insofar

Re: finally end single-person maintainership

On Tue, 2024-04-09 at 20:51 +0200, Gioele Barabucci wrote: > > Salsa is a forge, i.e. a combination of a Web interface, a git > server, > and a set of integrated features. In comparison to dgit, salsa has, > like > most forges: > > [] Also its a gitlab instance. There are all kinds of

Re: finally end single-person maintainership

On Mon, 2024-05-20 at 20:47 +, Scott Kitterman wrote: > > > > All these things should make it much more easy for other people or > > automated tools to send merge requests or keep maintaining a > > package in > > case the original maintainer becomes MIA. > > > Mandating a specific git

Re: About i386 support

On Mon, May 20, 2024 at 6:11 PM Andrey Rakhmatullin wrote: > > On Mon, May 20, 2024 at 10:57:58PM +0200, William Bonnet wrote: > > > which is good news. The end of support for 32 bits will not > > > affect the lives of almost anyone who has machines purchased after > > > 2011 and who bought them

Re: About i386 support

On Mon, May 20, 2024 at 10:57:58PM +0200, William Bonnet wrote: > > which is good news. The end of support for 32 bits will not > > affect the lives of almost anyone who has machines purchased after > > 2011 and who bought them after that > > Does this also mean he support for armhf will be

Re: About i386 support

Hi all On 20/05/2024 22:27, Leandro Cunha wrote: which is good news. The end of support for 32 bits will not affect the lives of almost anyone who has machines purchased after 2011 and who bought them after that Does this also mean he support for armhf will be dropped ? Cheers William

Re: finally end single-person maintainership

On May 20, 2024 7:54:46 PM UTC, Bernd Zeimetz wrote: >Hi, > >On Sun, 2024-04-07 at 16:44 +0200, Andreas Tille wrote: >> >> Do you think that mandating Salsa is a sensible step in this >> direction? > > >Absolutely. > >Also I think requiring a common git layout and the usage of recent

Re: About i386 support

Hello, On Mon, May 20, 2024 at 5:15 PM Paul Gevers wrote: > > Hi, > > On 20-05-2024 4:50 p.m., Ben Hutchings wrote: > > There is a tension here between the interests of (a) users that want to > > run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to > > keep using 32-bit CPUs.

Re: About i386 support

Hi, On 20-05-2024 4:50 p.m., Ben Hutchings wrote: There is a tension here between the interests of (a) users that want to run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to keep using 32-bit CPUs. If i386 is meant for group (a) then the baseline should be raised to include

Re: Any volunteers for lintian co-maintenance?

Hi! > > If I am successful, then lintian can specialize its efforts into issues only > > visible in packaged artifacts and thereby reduce it scope a bit. > > Perfect. I'd love to have some policy checking at "the right point in > time". I'd love to support this but as far as I understand even

Re: finally end single-person maintainership

Hi, On Sun, 2024-04-07 at 16:44 +0200, Andreas Tille wrote: > > Do you think that mandating Salsa is a sensible step in this > direction? Absolutely. Also I think requiring a common git layout and the usage of recent versions of dh should be required. Using merge requests instead of sending

Re: About i386 support

On Mon, 20 May 2024 00:30:13 +0200, Thomas Goirand wrote: > For example, *I* don't care at all about 32 bits arch, and would prefer if > these were to be sent to ports.debian.org. I really mean *all* 32 bits arch, > including armhf for example. I agree with you. No one really needs

Re: About i386 support

: Victor Gamper > > Sent: Sunday, May 19, 2024 08:03 > > To: debian-devel@lists.debian.org > > Subject: Re: About i386 support > > > > I believe I could swap out the processor on my T60, > > however, I'd both need to have that processor and > > make

Re: About i386 support

Hi, On Sun, 2024-05-19 at 10:30 -0500, r...@neoquasar.org wrote: > I have an N270 system I can use to contribute, if someone is willing > to explain what I need to do to make it useful.  > > From: Victor Gamper > Sent: Sunday, May 19, 2024 08:03 > To: debian-devel@lists.debian

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

On Sun, May 19, 2024 at 08:38:58PM -0700, Don Armstrong wrote: > On Sun, 19 May 2024, Bill Allombert wrote: > > Also debbugs is a special case: > > The debbugs Debian package (as opposed to the debbugs software) have never > > been > > really maintained. I am actually one of the very few users of

gzip --rsyncable (was: Re: De-vendoring gnulib in Debian packages)

"Theodore Ts'o" writes: > On Sun, May 12, 2024 at 04:27:06PM +0200, Simon Josefsson wrote: >> Going into detail, you use 'gzip -9n' but I use git-archive defaults >> which is the same as -n aka --no-name. I agree adding -9 aka --best is >> an improvement. Gnulib's maint.mk also add

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

> > Ideally debbugs should be made non-native so that some else could > > maintain the Debian package. > > I'm happy to review patches that get the 2.6 branch of debbugs in shape > where it can be released into Debian again if someone wants to take that > effort. I've just assumed that anyone

Re: Suggestions about i386 support

On Sun, 19 May 2024 20:19:12 +0200, Ben Hutchings wrote: >The plan is to keep i386 as a partial architecture that can be used as >a "foreign architecture" on systems where amd64 is the main >architecture. Many people using ancient hardware such as a T60 thinkpad say that's not enough for them. I

Re: Debian 10 "buster" moved to archive.debian.org

Hi Otto, In Buster's case, it would be becoming an ELTS soon and would have to use Freexian's repositories. It would no longer be the security team with DLAs that would take care of CVEs for ELTS, but the Frexian team. So much so that if I look at the links below I didn't find anything (about

Re: Debian 10 "buster" moved to archive.debian.org

On Sat, 23 Mar 2024 at 01:32, Ansgar  wrote: > > Hi, > > Debian 10 "buster" has moved to archive.debian.org in order to free > space on the main mirror network. We plan to start removing files for > non-LTS architectures in about two weeks; the existing Release files > will then refer to no

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

On Sun, 19 May 2024, Bill Allombert wrote: > Also debbugs is a special case: > The debbugs Debian package (as opposed to the debbugs software) have never > been > really maintained. I am actually one of the very few users of this package > and I tried several times to get the maintainers to do a

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

or search for a string, I need to download it as a zipfile, and re-running commands inside the same environment to test them is completely out. You could go to https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and conduct a code review? At first glance, looks good to me

Re: About i386 support

Hi, Looking at projects like Arch, Manjaro, Ubuntu, Fedora and other operating system projects developed to use Linux as the kernel, we realize that none of them provide ISO for 32 bits. A brief search led me to Debian as the only one I've seen so far (

Re: About i386 support

On Sun, 19 May 2024 at 23:30, Thomas Goirand wrote: > > On 5/19/24 17:30, r...@neoquasar.org wrote: > > I have an N270 system I can use to contribute, if someone is willing to > > explain what I need to do to make it useful. > > Hi, > > If you allow me ... I was expecting someone else to write it

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Thanks for reply Jonas, > > You could go to > > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and > > conduct a code review? > > > > You might discover that GitLab is useful and is not duplicating > > Debbugs or anything else in Debian - it is currently the only platform > >

Re: About i386 support

On 5/19/24 17:30, r...@neoquasar.org wrote: I have an N270 system I can use to contribute, if someone is willing to explain what I need to do to make it useful. Hi, If you allow me ... I was expecting someone else to write it before me, but seeing nobody does, let me try. ... The issue

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Quoting Otto Kekäläinen (2024-05-19 21:32:36) > > > My concern about Gitlab is not its *additions* to existing services, but > > > its *duplications* of core services already in Debian. > > > > I agree, that's the key problem. > > I agree that duplication is bad - but I disagree that use of

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

> > My concern about Gitlab is not its *additions* to existing services, but > > its *duplications* of core services already in Debian. > > I agree, that's the key problem. I agree that duplication is bad - but I disagree that use of version control duplicates the use of the Debian archive for

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Hi, On 5/19/24 16:11, Jonas Smedegaard wrote: My concern about Gitlab is not its *additions* to existing services, but its *duplications* of core services already in Debian. I agree, that's the key problem. The Debian archive itself is a VCS, so git-maintained packaging is also a

Re: Suggestions about i386 support

On Sun, 2024-05-19 at 07:26 +, defrag mentation wrote: > I think some of the i386 support policies needs to be reconsidered. > > Here are some suggestions: > > 1. ​Move Wine-32 to amd64, and Wine-32 may be compiled to 64-bit time_t. > > Wine-32 is now in currently dropped i386 DVDs/BDs, not

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

On Sat, May 18, 2024 at 08:25:10PM -0700, Otto Kekäläinen wrote: > Hi Bill and Wookey! > > In a recent long thread on debian-devel you had somewhat negative > sentiments towards the usefulness of Salsa. I am not sure this characterize my position. I have no opposition to Salsa (even though it is

Re: About i386 support

useful. > -- > *From:* Victor Gamper > *Sent:* Sunday, May 19, 2024 08:03 > *To:* debian-devel@lists.debian.org > *Subject:* Re: About i386 support >

Re: About i386 support

I have an N270 system I can use to contribute, if someone is willing to explain what I need to do to make it useful.  Sent from my mobile device. From: Victor Gamper Sent: Sunday, May 19, 2024 08:03 To: debian-devel@lists.debian.org Subject: Re: About i386

Re: About i386 support

On Sun, 19 May 2024 15:03:18 +0200, Victor Gamper wrote: >I believe I could swap out the processor on my T60, >however, I'd both need to have that processor and >make sure that it is actually possible. It still would >not really make sense on a platform that only supports >3G of physical RAM. >

Re: Any volunteers for lintian co-maintenance?

On May 19, 2024 11:00:23 AM UTC, Andrey Rakhmatullin wrote: >On Sun, May 19, 2024 at 12:49:29PM +0200, Andreas Tille wrote: >> > It also fails as an archive QA tool in my view since the FTP masters have >> > been unwilling to upgrade to any recent version of lintian. >> >> Perhaps a ftpmaster

Re: About i386 support

I believe I could swap out the processor on my T60, however, I'd both need to have that processor and make sure that it is actually possible. It still would not really make sense on a platform that only supports 3G of physical RAM. Anyways, if the only reason why i386 cd images are not supported

Re: Any volunteers for lintian co-maintenance?

On Sun, May 19, 2024 at 12:49:29PM +0200, Andreas Tille wrote: > > It also fails as an archive QA tool in my view since the FTP masters have > > been unwilling to upgrade to any recent version of lintian. > > Perhaps a ftpmaster could explain this in detail. As far as I understand, > it's also a

Re: Any volunteers for lintian co-maintenance?

Hi Niels, at first sorry for my late answer. At Thu, May 09, 2024 Niels Thykier wrote: > You are welcome to quote me in public, though I feel it will not help your > cause. This reply is in private to you, so you can choose whether you want > to quote me. I think any answer should be discussed.

Re: Re: Suggestions about i386 support

On Sun, May 19, 2024 at 09:09:10AM +, defrag mentation wrote: > > What will this solve? > > > I don't think this is "needed"? Unless you think all i386 packages will be > > removed from Debian, which is not the plan? > > Case 1: Debian removed i386 DVDs/BDs, and someone jigdo backed the

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Quoting Mathias Behrle (2024-05-19 11:08:58) > * Jonas Smedegaard: " Re: Salsa - best thing in Debian in recent years? (Re: > finally end single-person maintainership)" (Sun, 19 May 2024 10:47:38 > +0200): > > > > i.e. you are being > > asocial if you don'

Re: Re: Suggestions about i386 support

> What will this solve? > I don't think this is "needed"? Unless you think all i386 packages will be removed from Debian, which is not the plan? Case 1: Debian removed i386 DVDs/BDs, and someone jigdo backed the full amd64 DVDs/BDs set will be surprised that it do not contain wine32. Case 2:

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

* Jonas Smedegaard: " Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)" (Sun, 19 May 2024 10:47:38 +0200): > i.e. you are being > asocial if you don't, and can expect your behavior being discussed as a > public-wide issue f

Re: Re: Suggestions about i386 support

On Sun, May 19, 2024 at 07:26:28AM +, defrag mentation wrote: > What will this solve? > I don't think this is "needed"? Unless you think all i386 packages will be removed from Debian, which is not the plan? Case 1: Debian removed i386 DVDs/BDs, and someone jigdo backed the full amd64

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Quoting Paul Gevers (2024-05-19 10:05:38) > In this discussion about mandating things, I've been wondering > > On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote: > > * mandate VCS-tracking > > * Yes > > * mandate the use of one specific VCS > > * Yes: git > > What do people think

Re: Suggestions about i386 support

On Sun, May 19, 2024 at 07:26:28AM +, defrag mentation wrote: > I think some of the i386 support policies needs to be reconsidered. > > Here are some suggestions: > > 1. ​Move Wine-32 to amd64, and Wine-32 may be compiled to 64-bit time_t. What will this solve? > Wine-32 is now in currently

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Two mistakes spotted On 19-05-2024 10:05 a.m., Paul Gevers wrote: I think there's a large majority (maybe even consensus) that believe you *should* have the packaging in VCS I meant "at least should", as in "should or must". I think what pere did [3] [3]

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Hi all, In this discussion about mandating things, I've been wondering On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote: * mandate VCS-tracking * Yes * mandate the use of one specific VCS * Yes: git What do people think this should mean, a *should* or *must* in policy? That

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Quoting Otto Kekäläinen (2024-05-19 05:25:10) > In a recent long thread on debian-devel you had somewhat negative > sentiments towards the usefulness of Salsa. I do see you doing good > technical work for Debian and recently a MR from Bill too, so I was > thinking that maybe you will change your

Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Hi Bill and Wookey! In a recent long thread on debian-devel you had somewhat negative sentiments towards the usefulness of Salsa. I do see you doing good technical work for Debian and recently a MR from Bill too, so I was thinking that maybe you will change your mind when you read more in-depth

Re: About i386 support

@lists.debian.org *Subject:* Re: About i386 support Quoting Victor Gamper (2024-05-17 21:58:58) > Is there a reason to do this? If so, what would be required to keep the i386 > version, seeing as it still is important and used? anything can be done if there are enough contributors who care. Fo

Re: About i386 support

On Sat, 2024-05-18 at 10:28 +, Andrew M.A. Cater wrote: > On Fri, May 17, 2024 at 09:58:58PM +0200, Victor Gamper wrote: > > Hello everyone, > > Is it correct that debian 13 is planned to be released without > > an i386 iso and i386 is planned to be deprecated? > > If so, I'd like to ask to

Re: About i386 support

Hi Andrew, Release team member hat on On 18-05-2024 12:28 p.m., Andrew M.A. Cater wrote: In reality, i386 should probably have been dropped early (or at the last minute) for bookworm; some libraries will be kept for compatibility but it's not realistic to maintain i386 for the whole of the

Re: How to create a custom Debian ISO

+debian-live Hello Aditya, On 11/05/2024 10:21, Aditya Garg wrote: I wanted to create a custom ISO of Debian, with the following customisations: 1. I want to add a custom kernel that supports my Hardware. 2. I want to add my own Apt repo which hosts various software packages to support my

Re: About i386 support

On Fri, May 17, 2024 at 09:58:58PM +0200, Victor Gamper wrote: > Hello everyone, > Is it correct that debian 13 is planned to be released without > an i386 iso and i386 is planned to be deprecated? > If so, I'd like to ask to reconsider this seeing as there is still a > plethora of i386 machines

Re: About i386 support

Hi On 17-05-2024 9:58 p.m., Victor Gamper wrote: Is it correct that debian 13 is planned to be released without an i386 iso and i386 is planned to be deprecated? Our current position is described here: https://lists.debian.org/debian-devel-announce/2023/12/msg3.html Paul

Re: About i386 support

To: Victor Gamper; debian-devel@lists.debian.org Subject: Re: About i386 support Quoting Victor Gamper (2024-05-17 21:58:58) > Is there a reason to do this? If so, what would be required to keep the i386 > version, seeing as it still is important and used? anything can be done if there are

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

> > what would break where, and how to fix it? I only found autopkgtest > so > > far, which uses /tmp/ in the guest and expects it to survive across > > reboots, and I have a MR up already for that. Anything else? > > Perhaps whatever makes these files in /tmp? i think something to do > with >

Re: About i386 support

Victor Gamper wrote: > Is there a reason to do this? If so, what would be required to keep > the i386 version, seeing as it still is important and used?

Re: About i386 support

Quoting Victor Gamper (2024-05-17 21:58:58) > Is there a reason to do this? If so, what would be required to keep the i386 > version, seeing as it still is important and used? anything can be done if there are enough contributors who care. For i386 there is a severe lack of person-power. Do you

Re: Bug#1071126: ITP: battinfo -- cli tool & nim-lang library to query battery info for GNU/Linux

On Fri, May 17, 2024 at 08:52:00PM +0530, Prasanna Venkadesh wrote: > > > On 15 May 2024 12:33:49 am IST, Nilesh Patra wrote: > >On Tue, May 14, 2024 at 06:31:16PM +, Prasanna Venkadesh wrote: > >>It seems, there is no packaging team available yet for Nim lang. > >>I am not looking

Re: Bug#1071126: ITP: battinfo -- cli tool & nim-lang library to query battery info for GNU/Linux

On 15 May 2024 12:33:49 am IST, Nilesh Patra wrote: >On Tue, May 14, 2024 at 06:31:16PM +, Prasanna Venkadesh wrote: >>It seems, there is no packaging team available yet for Nim lang. >>I am not looking for co-maintainers, it's not complex. > >There does exist a nim team. > >

Re: How to create a custom Debian ISO

Hi, > I'm getting error 500 when attempting to open the source code.  just try again later. Salsa seems to be having issues. > Also, I'd prefer an offline install since the wifi firmware for the > t2 Macs is extracted from macOS by the user and copied over to Linux. > It cannot be

Re: How to create a custom Debian ISO

On Sat, 2024-05-11 at 08:21 +, Aditya Garg wrote: > 1. I want to add a custom kernel that supports my Hardware. > 2. I want to add my own Apt repo which hosts various software > packages to support my hardware. Please consider adding that hardware support to the mainline Linux kernel and to

Re: Confused about libnuma1 naming

"J.J. Martzki" writes: > Package 'libnuma1' is built from numactl, and there seems no 'libnuma' > exists. Why does it named as 'libnuma1' rather than 'libnuma'? Shared library packages should be named after the library SONAME, which generally includes a version (as it does here). See:

Re: How to create a custom Debian ISO

Hi I'm getting error 500 when attempting to open the source code. Also, I'd prefer an offline install since the wifi firmware for the t2 Macs is extracted from macOS by the user and copied over to Linux. It cannot be redistributed legally. > On 16 May 2024, at 7:45 PM, Johannes Schauer Marin

Re: How to create a custom Debian ISO

Hi, I'm removing debian-project from the recipients. Quoting Aditya Garg (2024-05-11 10:21:55) > I wanted to create a custom ISO of Debian, with the following customisations: > > 1. I want to add a custom kernel that supports my Hardware. > 2. I want to add my own Apt repo which hosts various

Re: MiniDebConf Toulouse (November 16-17 2024) and Call for Papers (CfP)

Am Donnerstag, 16. Mai 2024 schrieb Gregory Colpart: > Hello, > > We are pleased to announce a MiniDebConf at Toulouse (France) on > November 16-17 2024 and the Call for Papers to submit a talk. > > ## About MiniDebConf Toulouse 2024 > > The Association Debian France [1] organizes a

Re: How to create a custom Debian ISO

Well it's indeed not as easy as I thought as far as Debian ISOs are concerned. I'll try to be more precise. I am a maintainer for Ubuntu on Linux on T2 Macs project: https://t2linux.org/. We work to modify ISOs of commonly used distros by adding a custom kernel with drivers for T2 Macs and

Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED

Quoting Paul Gevers (2024-05-16 11:37:54) > On 16-05-2024 10:35 a.m., Jonas Smedegaard wrote: > > Just to clarify, the package in question does not directly depend on > > rust-ahash 0.8.9-2, that Built-Using information is (as is the general > > purpose of that field, I believe) transitive. > >

Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED

On Thu, May 16, 2024 at 4:35 PM Jonas Smedegaard wrote: > > Hi FTP-masters (cc d-devel list), > > A package, that I had initially introduced to Debian some months ago and > had been pending in NEW queue since, was rejected few days ago, like > this: > > Quoting Debian FTP Masters (2024-05-14

Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED

Hi Jonas, On 16-05-2024 10:35 a.m., Jonas Smedegaard wrote: Just to clarify, the package in question does not directly depend on rust-ahash 0.8.9-2, that Built-Using information is (as is the general purpose of that field, I believe) transitive. Built-Using is used for license compliance so

Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED

Hi FTP-masters (cc d-devel list), A package, that I had initially introduced to Debian some months ago and had been pending in NEW queue since, was rejected few days ago, like this: Quoting Debian FTP Masters (2024-05-14 12:00:12) > > An exception was raised while processing the package: >

Re: systemd-dev package in bookworm?

In days of yore (Wed, 15 May 2024), Sirius thus quoth: > Thank you. I will update later with results for kernel 6.9.0 and Xen > 4.18.2, how they work together. Quick feedback: it works, although I am seeing some weird log-spewing when I run things like aptitude and apt-get search. I will

Re: systemd-dev package in bookworm?

In days of yore (Wed, 15 May 2024), Simon Richter thus quoth: > Hi, Hello Simon, > On 5/15/24 10:31, Sirius wrote: > > >Where is the systemd-dev package for regular Bookworm? The only package > >that show up is systemd-dev/stable-backports 254.5-1~bpo12+3 all and if > >I try and

Re: systemd-dev package in bookworm?

Hi, On 5/15/24 10:31, Sirius wrote: Where is the systemd-dev package for regular Bookworm? The only package that show up is systemd-dev/stable-backports 254.5-1~bpo12+3 all and if I try and install that, it seems like it wants to uninstall most of my system in the process. The

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Am 13.05.24 um 11:42 schrieb Johannes Schauer Marin Rodrigues: If we want to try and weigh cost against benefit, do the benefits really outweigh the cost? How costly is it to carry a patch in Debian and deviate from upstream versus all the problems that participants of this thread now listed? My

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Unless somebody's already put it there, I'm going to move these suggestions to a wishlist bug against systemd. Not sure if it should be one bug or a few, one for each suggestion. Currently discussion about reaping /var/tmp/ is in https://bugs.debian.org/966621 and

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Hi, Quoting Barak A. Pearlmutter (2024-05-13 10:47:43) > > I'd like to hear some arguments *in favour* of making this change. > > Alignment with systemd-upstream, reduced package maintenance burden > > are two that I can think of, but perhaps I've missed more. These two, > > IMHO, are

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

> I'd like to hear some arguments *in favour* of making this change. > Alignment with systemd-upstream, reduced package maintenance burden > are two that I can think of, but perhaps I've missed more. These two, > IMHO, are significantly outweighed by the risks. Let me see if I understand the

Re: Any volunteers for lintian co-maintenance?

Hi Nilesh, On 2024-05-10 21:04, Nilesh Patra wrote: On Fri, May 10, 2024 at 05:58:24PM +0300, Andrius Merkys wrote: Do you mean bugs on bugs.d.o, or are there other issues? As you may have seen in the other emails, there are performance issues. Other than that, there are 2 open RC bugs right

<    1   2   3   4   5   6   7   8   9   10   >