Simon Josefsson writes:
> Having some mechanism to create package-specific users seems like one
> useful goal, and I don't understand why each package has to write
> scripts to invoke 'adduser' and deal with all the complexity around
> that on their own.
systemd-sysusers does this?
On Mon, 12 May 2025 09:54:38 +0200, Gioele Barabucci
wrote:
>On 12/05/25 09:49, Holger Levsen wrote:
>> On Sun, May 11, 2025 at 03:58:12PM -0700, Otto Kekäläinen wrote:
>>> Regardless of what branch names packages use today or in the future,
>>> they should all have a debian/gbp.conf file that def
Package: wnpp
Severity: wishlist
Owner: Roger Shimizu
X-Debbugs-Cc: debian-devel@lists.debian.org, r...@debian.org
* Package name: linux-board-support-package-rb3gen2
Version : 1.1
Upstream Author : Linaro
* URL :
https://artifacts.codelinaro.org/ui/native/qli-ci/flash
On 11/05/25 at 23:40 +0200, Bálint Réczey wrote:
> While this is accurate considering the latest DEP-14 version, it
> should be noted that the first DEP-14 draft allowed 'master' as the
> main branch for native packages and up to 2020-11-29 DEP-14
> recommended debian/master instead of debian/lates
Holger Levsen writes:
> On Sun, May 11, 2025 at 03:58:12PM -0700, Otto Kekäläinen wrote:
>> Regardless of what branch names packages use today or in the future,
>> they should all have a debian/gbp.conf file that defines what
>> branches and packaging practices are being used *right now*.
>
> I
On 12/05/25 09:49, Holger Levsen wrote:
On Sun, May 11, 2025 at 03:58:12PM -0700, Otto Kekäläinen wrote:
Regardless of what branch names packages use today or in the future,
they should all have a debian/gbp.conf file that defines what branches
and packaging practices are being used *right now*.
On May 12, Simon Josefsson wrote:
Having some mechanism to create package-specific users seems like one
useful goal, and I don't understand why each package has to write
scripts to invoke 'adduser' and deal with all the complexity around that
on their own. There could be a declarative interfac
On Mon, May 12, 2025 at 08:32:24AM +, Holger Levsen wrote:
> debian/README.source as described in the developers-reference.
and even in
https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|la
> debian/README.source as described in the developers-reference.
It would be great also to have an easy way to cherry peak from the upstream git
repository in order to prepare patch series.
Do we have a tool around DEP-14, which allows this ?
Bill Allombert writes:
> Le Sun, Apr 20, 2025 at 11:22:04PM +0500, Andrey Rakhmatullin a écrit :
>> On Sun, Apr 20, 2025 at 06:25:53PM +0100, Josh Triplett wrote:
>> > What I'm suggesting here is that if every individual package that needs
>> > awk has a Depends on it (via a package that allows s
On Mon, May 12, 2025 at 09:54:38AM +0200, Gioele Barabucci wrote:
Regardless of what branch names packages use today or in the future,
they should all have a debian/gbp.conf file that defines what branches
and packaging practices are being used *right now*.
I dont want to use git-buildpackage a
On Mon, May 12, 2025 at 09:09:23AM +0100, Richard Lewis wrote:
> > I dont want to use git-buildpackage and I don't want a
> > gpb.conf. Please accept this. Thanks.
> is there another way people can use to understand how to build the
> package?
debian/README.source as described in the developers-re
On Sun, May 11, 2025 at 03:58:12PM -0700, Otto Kekäläinen wrote:
> > > I think this significantly underestimates the annoyance involved in
> > > renaming
> > > existing long-lived branches (in that all clients have to re-clone or
> > > manually adjust), which is certainly why I generally avoid doi
On Mon, May 12, 2025 at 11:58:45AM +0200, Santiago Vila wrote:
El 12/5/25 a las 9:49, Holger Levsen escribió:
I dont want to use git-buildpackage and I don't want a gpb.conf. Please accept
this. Thanks.
I also don't like the idea of adding a gpb.conf to each and every package.
Yes, in most c
On Sat, 10 May 2025 at 11:20:41 +0100, Wookey wrote:
ITM Modernise ITU Update
ITR Revamp
move-to-collective-maintainership (failing to think a good short name here -
maybe:)
ITC Collectivise ?
ITPM Publically Maintain
Whichever conventional name is chosen (one of these or something else),
m
On Mon, 12 May 2025 15:04:38 +0200, Lucas Nussbaum wrote:
Regarding "I don't want a gbp.conf", I think that we should aim for DRY,
and that adding a gbp.conf in every package doesn't sound too great for
teams that maintain hundreds or thousands of packages...
Yes, please.
Cheers,
gregor, who
Le lun. 12 mai 2025 à 18:09, Enrico Zini a écrit :
> Hello,
>
> I would like to try out podman in Debian, but I would like it to be
> configured to only use officially built Debian images[1].
>
> By default podman in Debian will not access remote repositories.
>
> Following the podman page in the
Hi Simon,
On 06/05/2025 16:24, Simon Josefsson wrote:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104784
Nice catch. That's an interesting failure mode, probably another one
that was not completely anticipated by sponsors of /bin -> /usr/bin
directory aliasing, and it's likely to affe
Hi,
Sean Whitton ezt írta (időpont: 2025. máj.
12., H, 13:11):
>
> Hello,
>
> On Mon 12 May 2025 at 10:37am +02, PICCA Frederic-Emmanuel wrote:
>
> >> debian/README.source as described in the developers-reference.
> >
> > It would be great also to have an easy way to cherry peak from the upstream
On 12/05/25 at 07:49 +, Holger Levsen wrote:
> > Regardless of what branch names packages use today or in the future,
> > they should all have a debian/gbp.conf file that defines what branches
> > and packaging practices are being used *right now*.
>
> I dont want to use git-buildpackage and I
Hi Andreas,
Am Fri, May 09, 2025 at 07:15:09PM +0200 schrieb Andreas Metzler:
>
> How do you go about that? Do you poll the respective team whether they
> are committing to maintain it?
I'm a member of several Debian teams, including Debian Science, Games,
Multimedia, Perl, and Java. Many of the
Am Sat, May 10, 2025 at 11:20:41AM +0100 schrieb Wookey:
> On 2025-05-08 10:00 +0200, Andreas Tille wrote:
> > Am Wed, May 07, 2025 at 10:27:03PM +0200 schrieb Jonas Smedegaard:
>
> > > Can we please stop calling it an intent to NMU when it is invasive?
> >
> > You're right--"Intent To NMU" is a
Hello,
On Mon 12 May 2025 at 03:04pm +02, Lucas Nussbaum wrote:
> On 12/05/25 at 07:49 +, Holger Levsen wrote:
>> > Regardless of what branch names packages use today or in the future,
>> > they should all have a debian/gbp.conf file that defines what branches
>> > and packaging practices are
Marco d'Itri writes:
> On May 12, Simon Josefsson wrote:
>
>>Having some mechanism to create package-specific users seems like one
>>useful goal, and I don't understand why each package has to write
>>scripts to invoke 'adduser' and deal with all the complexity around that
>>on their own. There
tl;dr:
- Can you read Python fluently?
- Are you available for a small code-reading task in the next week?
- Would you like to help with tag2upload?
If so, please get in touch! No knowledge of tag2upload needed.
No actual programming involved - unless you want to :-).
Hi. It looks like
On 12/05/2025 21:52, Simon Josefsson wrote:
Marco d'Itri writes:
On May 12, Simon Josefsson wrote:
Having some mechanism to create package-specific users seems like one
useful goal, and I don't understand why each package has to write
scripts to invoke 'adduser' and deal with all the complexi
On Mon, 12 May 2025 at 19:58:10 +0200, Cyril Brulebois wrote:
For various reasons, I'll be trying to get D-I Trixie RC 1 out this
week, and I might freeze udeb-producing packages right away, or in the
very next few hours/days.
As a general rule, would you prefer maintainers of udeb-producing
p
> >Regarding "I don't want a gbp.conf", I think that we should aim for DRY,
> >and that adding a gbp.conf in every package doesn't sound too great for
> >teams that maintain hundreds or thousands of packages...
>
> Yes, please.
That could have been an option 10 years ago when people were creating
> > >> debian/README.source as described in the developers-reference.
> > >
> > > It would be great also to have an easy way to cherry peak from the
> > > upstream
> > > git repository in order to prepare patch series.
> > >
> > > Do we have a tool around DEP-14, which allows this ?
> >
> > Well,
Hello,
On Mon 12 May 2025 at 10:37am +02, PICCA Frederic-Emmanuel wrote:
>> debian/README.source as described in the developers-reference.
>
> It would be great also to have an easy way to cherry peak from the upstream
> git repository in order to prepare patch series.
>
> Do we have a tool aroun
Hello,
On Mon 12 May 2025 at 01:27pm +02, Bálint Réczey wrote:
> Hi,
>
> Sean Whitton ezt írta (időpont: 2025. máj.
> 12., H, 13:11):
>>
>> Hello,
>>
>> On Mon 12 May 2025 at 10:37am +02, PICCA Frederic-Emmanuel wrote:
>>
>> >> debian/README.source as described in the developers-reference.
>> >
Hello,
I would like to try out podman in Debian, but I would like it to be
configured to only use officially built Debian images[1].
By default podman in Debian will not access remote repositories.
Following the podman page in the Debian wiki[2], I set up `docker.io` as
a registry, so it can fin
El 12/5/25 a las 9:49, Holger Levsen escribió:
I dont want to use git-buildpackage and I don't want a gpb.conf. Please accept
this. Thanks.
I also don't like the idea of adding a gpb.conf to each and every package.
Most of my packages don't have such file and Salsa CI is able to build them.
M
On 12/05/25 10:31, Andrey Rakhmatullin wrote:
On Mon, May 12, 2025 at 09:54:38AM +0200, Gioele Barabucci wrote:
Regardless of what branch names packages use today or in the future,
they should all have a debian/gbp.conf file that defines what branches
and packaging practices are being used *righ
34 matches
Mail list logo
