On Wednesday, February 12, 2025 10:51:13 AM MST Raphael Hertzog wrote:
> That sounds like what the "debian_pipeline" workflow can do in
> https://debusine.debian.net, except that it is able to do it on multiple
> architectures and also run reverse dependencies autopkgtest (however it
> doesn't supp
Hi,
On Tue, 11 Feb 2025, Kirill Rekhov wrote:
> I wrote a script called chroot-debianizer that automates routine tasks related
> to Debian package management. This tool is designed to facilitate a clean and
> isolated package building process in chroot environments specifically for the
> amd64 arc
Hi, Dear Debian Engineers.
I hope this message finds you well. Sorry for advertising my small project.
I use this script often when working with Debian packages.
I wrote a script called chroot-debianizer that automates routine tasks related
to Debian package management. This tool is designed to
Hi!
Thanks for following up. Based on the feedback about the goal/scope I
decided to rewrite the DEP-18 almost completely, and published a new
draft at https://salsa.debian.org/dep-team/deps/-/merge_requests/12
On Tue, 5 Nov 2024 at 03:14, Jonathan Dowland wrote:
>
> It's been a while since -dev
It's been a while since -devel has heard anything about DEP-18¹, which
(Back in August or so) encouraged a large healthy discussion here, and
got some coverage on LWN².
Is there any news? Where are we at with this (pre-)³proposal?
[1]
https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e160
On Sun Sep 1, 2024 at 6:14 PM BST, Otto Kekäläinen wrote:
> The discussion was summarized in a separate "Summay" email by me on this
> list, and a comment in the MR (which merges the two discussions) and it
> just happened that the next day it was also covered in
> https://lwn.net/Articles/986480/
Hi!
On Wed, Sep 4, 2024 at 12:39 PM PICCA Frederic-Emmanuel
wrote:
>
> Hello,
>
> > Well, I didn't mean we should *give up* decentralization. I mean we
> > shouldn't
> > give up *centralization*. These examples are to prove centralization
> > actually
> > works and is quite common, sometimes ne
On 04/09/2024 17:21, PICCA Frederic-Emmanuel wrote:
> Hello,
>
>> Well, I didn't mean we should *give up* decentralization. I mean we shouldn't
>> give up *centralization*. These examples are to prove centralization actually
>> works and is quite common, sometimes necessary.
>
> It would be great
Hello,
> Well, I didn't mean we should *give up* decentralization. I mean we shouldn't
> give up *centralization*. These examples are to prove centralization actually
> works and is quite common, sometimes necessary.
It would be great if we could run the salsa-ci pipeline localy easily, in
chroo
(Please send To/Cc me if you'd like to continue on this branch of conversation,
I'm not subscribed to -devel, only digests.)
On Wed, 04 Sep 2024 06:42:33 +0200, Jonas Smegegaard wrote:
> Quoting Blair Noctis (2024-09-04 04:33:10)
(...)
>> > PICCA Frederic-Emmanuel writes:
>> >
>> >> What about dog
On Tuesday, 3 September 2024 23.42.33 CDT Jonas Smedegaard wrote:
> I don't say that Debian must work for jungle developers, nor that we
> must all use email and not different forms of collaboration requiring
> better connectivity. My point is that Debian *allows* collaboration
> also without heav
Hi Blair,
Quoting Blair Noctis (2024-09-04 04:33:10)
> On 02/09/2024 06:38, Richard Lewis wrote:
> > PICCA Frederic-Emmanuel
> > writes:
> >
> >> What about dog fooding ?
> >>
> >> for now we can setup a schroot and sbuild very easily and start to build a
> >> local repository in minutes.
> >>
On 02/09/2024 06:38, Richard Lewis wrote:
> PICCA Frederic-Emmanuel
> writes:
>
>> What about dog fooding ?
>>
>> for now we can setup a schroot and sbuild very easily and start to build a
>> local repository in minutes.
>>
>> But when it comes to install gitlab and the CI system it is another
On 03/09/2024 15:36, Otto Kekäläinen wrote:
My information was based on what Salsa admin posted at
https://salsa.debian.org/salsa/support/-/issues/395
Hi Otto,
Thanks for that link,
which took me nearly a minute to open!
Quoting from there.
Could we keep the issue open for now and only clo
Hi!
> Hi Otto,
> Until recently I generally found Salsa response to be adequate,
> but for the last couple of days it has been so
> excruciatingly slow as to be almost unusable.
>
> > In response, Otto Kekäläinen noted that the Salsa admins
> > had posted about upcoming hardware upgrades and other
On 28/08/2024 03:13, Otto Kekäläinen wrote:
## Performance and Reliability
Multiple participants, including Salvo Tomaselli, Johannes Schauer
Marin Rodrigues, Andrea Pappacoda, and Gioele Barabucci, complained
about Salsa/GitLab being slow or unreliable at times, which deterred
contribution. Imp
PICCA Frederic-Emmanuel writes:
> What about dog fooding ?
>
> for now we can setup a schroot and sbuild very easily and start to build a
> local repository in minutes.
>
> But when it comes to install gitlab and the CI system it is another story. So
> we rely on the central salsa instance.
f
What about dog fooding ?
for now we can setup a schroot and sbuild very easily and start to build a
local repository in minutes.
But when it comes to install gitlab and the CI system it is another story. So
we rely on the central salsa instance.
It seems to me that a great strength of Debian i
> My overall impression is that this is a bold attempt, but the document could
> do
> with some copy-editing to whittle it down, make it more focussed, and possibly
> narrow the scope. E.g. perhaps Gitlab CI is too much in one go? Could that be
> done further down the line in a follow-up DEP?
I
Hi Jonathan!
The discussion was summarized in a separate "Summay" email by me on this
list, and a comment in the MR (which merges the two discussions) and it
just happened that the next day it was also covered in
https://lwn.net/Articles/986480/
I am currently writing revision 2 of the proposal.
Thanks for working on this. I finally had a read over it today.
I've found the split in discussion between this list and the Merge Request
comments
hard to manage. It would help a lot, I think, if some of the MR threads were
marked
resolved, assuming the issues they describe are resolved. Tha
Hi!
> NOTE: The following idea might be out-of-scope in DEP-18, but specific
> use-case to improve
> collaboration in Debian, IMHO.
>
> Here is just an idea: put collaboration policy metadata in debian/control.
> (The following idea assumes that non-maintainer DD tend to hesitate to
> commit/merge
Il 28/08/2024 04:13, Otto Kekäläinen ha scritto:
Hi!
While I intend to continue on iterating DEP-18, here is a summary to
those who did not wade through the 140+ messages on the topic.
Unfortunately, the summary itself is also a bit long :)
Big thanks for your work and of other people that are t
Hi!
While I intend to continue on iterating DEP-18, here is a summary to
those who did not wade through the 140+ messages on the topic.
Unfortunately, the summary itself is also a bit long :)
Summary of mailing list
[resending to your correct address]
Hello,
On Mon 05 Aug 2024 at 06:14am +05, Andrey Rakhmatullin wrote:
> It's similar but different: I'm talking about workflows to build a package
> from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs").
> And yeah it could be a metadata field.
Hello,
On Mon 05 Aug 2024 at 06:14am +05, Andrey Rakhmatullin wrote:
> It's similar but different: I'm talking about workflows to build a package
> from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs").
> And yeah it could be a metadata field.
Just to note that once people are u
Hello,
On Sat 03 Aug 2024 at 11:29am -07, Soren Stoutner wrote:
> 1. Debian workflows are too fractured. The project would be better if we
> asked people
> to standardize around a single (or a small number) of workflows. To do so,
> the workflow
> would need to be flexible enough to handle t
Hello,
On Sat 03 Aug 2024 at 09:19am +02, PICCA Frederic-Emmanuel wrote:
> Hello, I like the dgit idea, produce a git repository for people who want to
> use git and let other use whatever they want.
>
> Maybe uploading a paquage to Debian could push automatically into dgit. (maybe
> this is alre
Hello,
On Sat 03 Aug 2024 at 08:26am +02, Jonas Smedegaard wrote:
> My problem with DEP-18 is that people who have zero problem with using
> git and are also not fundamentally against using salsa, but have
> reservations surrounding *which parts* of salsa to use and the
> consequences for related
Il 05/08/2024 10:40, Simon Richter ha scritto:
Hi,
On 8/5/24 17:10, Fabio Fantoni wrote:
currently you find such information from a simple search and/or
looking a bit in the source, in the possible git in a few minutes
only in part of cases, in many other cases instead it requires more
time,
Hi,
On 8/5/24 17:10, Fabio Fantoni wrote:
currently you find such information from a simple search and/or looking
a bit in the source, in the possible git in a few minutes only in part
of cases, in many other cases instead it requires more time, the
possible contact of the maintainer, attempt
Fabio Fantoni:
Il 05/08/2024 03:14, Andrey Rakhmatullin ha scritto:
[...]
Thanks for reply, what I mean is precisely a standard field that points
to a file, inside the package or even an url as already explained can be
very useful in most cases) that contains all the useful information for
c
Il 05/08/2024 03:14, Andrey Rakhmatullin ha scritto:
On Sun, Aug 04, 2024 at 04:15:13PM +0200, Fabio Fantoni wrote:
Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto:
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
one problem I have with NMUs in team-maintained package is th
On Sun, Aug 04, 2024 at 04:15:13PM +0200, Fabio Fantoni wrote:
> Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto:
> > On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
> > > one problem I have with NMUs in team-maintained package is that they
> > > often bypass Salsa… Would it ma
Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto:
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
one problem I have with NMUs in team-maintained package is that they
often bypass Salsa… Would it make sense to add to the DEP a request
that NMUs are started from and pushed to
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
> one problem I have with NMUs in team-maintained package is that they
> often bypass Salsa… Would it make sense to add to the DEP a request
> that NMUs are started from and pushed to the default branch?
Only if DEP-18 also includes
On Sat, Aug 03, 2024 at 10:37:42PM +0200, Salvo Tomaselli wrote:
> > 2. Standardizing around a single (or small number of) workflows will make
> > some people unhappy. But that is an acceptable price to pay because of the
> > general benefit to the project *as long as the correct solution is
> >
Hi all,
On 03-08-2024 22:37, Salvo Tomaselli wrote:
At the bottom, is it ok for a package to have a single maintainer or not?
I have never wanted to be the single maintainer of a package, and here I
am, I'm member of a bunch of teams, but most of my packages uploads (not
a lot luckily) are f
Hi!
> I have three feelings.
>
>
> 1. Debian workflows are too fractured. The project would be better if we
> asked people to standardize around a single (or a small number) of workflows.
> To do so, the workflow would need to be flexible enough to handle the wide
> range of technical needs
On Saturday, August 3, 2024 1:37:42 PM MST Salvo Tomaselli wrote:
> > 2. Standardizing around a single (or small number of) workflows will make
> > some people unhappy. But that is an acceptable price to pay because of
the
> > general benefit to the project *as long as the correct solution is
>
On Friday, August 2, 2024 11:26:01 PM MST Jonas Smedegaard wrote:
> I imagine that some in the silent crowd hesitate to chime in due to that
> lumping together the use of git and the use of Gitlab into an
> all-or-nothing choice. I think you intended that reduction, for the
> purpose of simplifyin
ntent of each
> >>> package repository on salsa.d.o and NMU'ed package source.
> >>> * Because other DD (non package owner) can commit/merge, then ship
> >>> NMU package.
> >>> Cons:
> >>> * Maintainers will be bothered to add
-called package hijack
with incomplete communication in some cases.
Hi, this I think is can be useful (beyond the example use of
salsa/debian packages which is not necessary as replied by Tobias
Frost), I think will be better with only one additional (and optional)
field in d/control, like Collaborat
aboration-Policy-Merge: no policy
> >because DD has maintainer rights on salsa.d.o and can commit/merge
> > it in reality.
> >
> > It might worry too much, but it might be able to block an unfortunate
> > accident, a so-called package hijack
> > with incomplete c
Il 03/08/2024 15:16, Jonas Smedegaard ha scritto:
Quoting Kentaro Hayashi (2024-08-03 14:40:51)
Hi,
Even though +1 for DEP-18 basically, I think that it might be better
to add an option
to formalize package owner's (single person maintainer) collaboration policy
especially about non-team mainta
ond the example use of
salsa/debian packages which is not necessary as replied by Tobias
Frost), I think will be better with only one additional (and optional)
field in d/control, like Collaboration-Policy that point a file or url,
this I think that can decrease the possible annoyance and in the
Quoting Kentaro Hayashi (2024-08-03 14:40:51)
> Hi,
>
> Even though +1 for DEP-18 basically, I think that it might be better
> to add an option
> to formalize package owner's (single person maintainer) collaboration policy
> especially about non-team maintained packages under
> https://salsa.debia
On Sat, Aug 03, 2024 at 09:40:51PM +0900, Kentaro Hayashi wrote:
> Hi,
>
> Even though +1 for DEP-18 basically, I think that it might be better
> to add an option
> to formalize package owner's (single person maintainer) collaboration policy
> especially about non-team maintained packages under
>
Hi, Tobias.
Thank you for kindly advice, I've misunderstood about debian/ namespace.
Please ignore the previous my post. [1]
I felt sorry posting just a noise.
[1] https://lists.debian.org/debian-devel/2024/08/msg00052.html
Regards,
2024年8月3日(土) 21:54 Tobias Frost :
>
> On Sat, Aug 03, 2024 at
afted a new DEP at
> https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> Enable true open collaboration on all Debian packages".
>
> Direct link to raw text:
> https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.md
Il 03/08/2024 01:28, Jonas Smedegaard ha scritto:
Quoting Fabio Fantoni (2024-08-02 23:51:26)
Il 02/08/2024 15:49, Jonas Smedegaard ha scritto:
I think that both email and systems like salsa/github/gitlab etc. are
useful, both with pros and cons. Forcing people to use only one or the
other coul
Hello, I like the dgit idea, produce a git repository for people who want to
use git and let other use whatever they want.
Maybe uploading a paquage to Debian could push automatically into dgit. (maybe
this is already the case)
Is it possible then to mirror this dgit repository in salsa ?
Fred
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
> > I have drafted a new DEP at
> > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> > Enable true open collaboration on all Debian packages".
>
> Hi Otto,
>
>
Le Sat, Jul 27, 2024 at 03:38:40PM -0700, Otto Kekäläinen a écrit :
>
> I have drafted a new DEP at
> https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> Enable true open collaboration on all Debian packages".
Hi Otto,
thank you for your initiativ
On Sat, Aug 3, 2024 at 2:26 PM Jonas Smedegaard wrote:
>
> My problem with DEP-18 is that people who have zero problem with using
> git and are also not fundamentally against using salsa, but have
> reservations surrounding *which parts* of salsa to use and the
> consequences for related already u
Quoting Otto Kekäläinen (2024-08-03 06:38:38)
> > I am not suggesting salsa use because I think it's the best thing since the
> > invention of sliced bread. But personally, I rather use something
> > suboptimal if
> > it means that we can more or less agree on a "default" and I think that the
> >
Hi,
On Fri, 2 Aug 2024 at 16:27, Johannes Schauer Marin Rodrigues
wrote:
> Quoting Otto Kekäläinen (2024-08-02 17:23:51)
> > I agree that Salsa is sometimes a bit sluggish
> > (https://salsa.debian.org/salsa/support/-/issues/395),
>
> what kind of hardware do you have? For people like me who are
Quoting Fabio Fantoni (2024-08-02 23:51:26)
> Il 02/08/2024 15:49, Jonas Smedegaard ha scritto:
> >> I think that both email and systems like salsa/github/gitlab etc. are
> >> useful, both with pros and cons. Forcing people to use only one or the
> >> other could be counterproductive at the moment.
Hi,
Quoting Otto Kekäläinen (2024-08-02 17:23:51)
> I agree that Salsa is sometimes a bit sluggish
> (https://salsa.debian.org/salsa/support/-/issues/395),
what kind of hardware do you have? For people like me who are on slower
hardware, the web experience is absolutely not funny and "a bit slugg
Il 02/08/2024 15:49, Jonas Smedegaard ha scritto:
Hi Fabio,
Quoting Fabio Fantoni (2024-08-02 14:31:04)
One particular thing noticed in some cases (and I hope they are not
many) is the lack of use or especially updates of the Vcs-* fields in
d/control. I think is important point to packaging re
Hi!
On Fri, 2 Aug 2024 at 02:27, Andrea Pappacoda wrote:
..
> Before a certain way of doing things can be mandated or "warmly
> recommended", the technology has to be as flawless as possible - and
> today I wouldn't call Salsa "flawless", would you? Issues with
> Salsa/GitLab:
>
> 1. It is so slo
Hi Fabio,
Quoting Fabio Fantoni (2024-08-02 14:31:04)
> One particular thing noticed in some cases (and I hope they are not
> many) is the lack of use or especially updates of the Vcs-* fields in
> d/control. I think is important point to packaging repository from the
> tracker if present and t
EP-18: Enable true open collaboration on all Debian packages".
Thanks for your work on this. Trying to unify aspects of Debian
development is one of the things I think we need to do to not only
"enable true open collaboration", but also to attract more new
contributors.
While t
On 02/08/2024 06:38, Salvo Tomaselli wrote:
> Also, there's IRC/matrix for more real time communication, but I challenge
> you
> to follow those long threads on d-devel on something like teams or slack.
Discourse. Or some other "forum" software. IMO online forums and mailing lists
are pretty simi
On 02/08/24 11:20, Andrea Pappacoda wrote:
Issues with Salsa/GitLab:
1. It is so slow that it makes me want to close by browser and do
something else instead
[...]
5. Did I mention how slow it is?
Just as a side note: yes, salsa.d.o/GitLab is not the snappiest Web
application ever and somet
Hi Otto, and all the others participating in this thread :)
Il giorno sab 27 lug 2024 alle 15:38:40 -07:00:00, Otto Kekäläinen
ha scritto:
I have drafted a new DEP at
https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled
"DEP-18: Enable true open collaboration on all D
Quoting Salvo Tomaselli (2024-08-02 00:38:15)
> > saying out loud phrases such as "The only right way to
> > collaborate is reading and writing emails is in my terminal"
>
> Please. This feels like trolling.
>
> You're literally making up a quote and then you reply to it.
>
> Nobody said that.
On 2024-08-01 22:10:58 +0100 (+0100), Luca Boccassi wrote:
> On Thu, 1 Aug 2024 at 18:23, Jeremy Stanley wrote:
> >
> > On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote:
> > [...]
> > > To pick a random example, a less well known, less used, less
> > > popular distribution like Nixos has
On Thu, 1 Aug 2024 at 18:23, Jeremy Stanley wrote:
>
> On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote:
> [...]
> > To pick a random example, a less well known, less used, less
> > popular distribution like Nixos has 7000+ contributors listed on
> > Github.
> [...]
>
> Just to pick on th
On Thu, 1 Aug 2024 at 21:57, Marc Haber wrote:
>
> On Thu, 1 Aug 2024 18:36:29 +0100, Luca Boccassi
> wrote:
> >On Thu, 1 Aug 2024 at 18:16, Marc Haber wrote:
> >>
> >> On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi
> >> wrote:
> >> >The vast majority of people who
> >> >are forced to use ema
On Thu, 1 Aug 2024 18:36:29 +0100, Luca Boccassi
wrote:
>On Thu, 1 Aug 2024 at 18:16, Marc Haber wrote:
>>
>> On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi
>> wrote:
>> >The vast majority of people who
>> >are forced to use emails do so for work via a
>> >work-mediated/administered interface
On Thu, 1 Aug 2024 at 18:16, Marc Haber wrote:
>
> On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi
> wrote:
> >The vast majority of people who
> >are forced to use emails do so for work via a
> >work-mediated/administered interface that tries to make it somewhat
> >tolerable, like Outlook or Gma
On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote:
[...]
> To pick a random example, a less well known, less used, less
> popular distribution like Nixos has 7000+ contributors listed on
> Github.
[...]
Just to pick on this particular point, because I see this metric
used all the time by p
On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi
wrote:
>The vast majority of people who
>are forced to use emails do so for work via a
>work-mediated/administered interface that tries to make it somewhat
>tolerable, like Outlook or Gmail.
This must be the least accurate statement about Outlook t
Yes, tag2upload. It’s almost ready :)
Please wait a little longer.
--
Sean Whitton
Please excuse top-posting and brevity. I am writing to you from a mobile phone.
> On 1 Aug 2024, at 20:43, Charles Plessy wrote:
>
> Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a écrit :
>>
>> ru
On Aug 01, Luca Boccassi wrote:
> Emails are actually a barrier against collaboration, and actively
> hinder it by preventing new people from joining in. Please understand
No, email is the only inclusive collaboration platform.
I can use email while traveling and when the least possible connectiv
On Thu, 1 Aug 2024 at 13:43, Charles Plessy wrote:
>
> Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a écrit :
> >
> > run a CI before uploading, even a very basic one is just fine, better
> > than nothing.
>
> Thanks for the remider ! I will have a closer look at Salsa CI instead
> of
Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a écrit :
>
> run a CI before uploading, even a very basic one is just fine, better
> than nothing.
Thanks for the remider ! I will have a closer look at Salsa CI instead
of trying to understand how to run autopkgtests locally.
Would there
On Thu, 1 Aug 2024 at 09:49, Jonas Smedegaard wrote:
> Quoting Otto Kekäläinen (2024-08-01 07:30:18)
> > You have for sure developed an optimal workflow for yourself.
>
> Then I have failed: I have strived towards a collaborative workflow.
>
> Just not a web-centered collaborative workflow, but an
On Thu, 1 Aug 2024 at 10:36, Johannes Schauer Marin Rodrigues
wrote:
>
> Hi Otto,
>
> Quoting Otto Kekäläinen (2024-07-28 00:38:40)
> > I have drafted a new DEP at
> > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> > Enable tr
Hi Otto,
Quoting Otto Kekäläinen (2024-07-28 00:38:40)
> I have drafted a new DEP at
> https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> Enable true open collaboration on all Debian packages".
>
> Direct link to raw text:
> https://salsa.de
Quoting Otto Kekäläinen (2024-08-01 07:30:18)
> > > I have drafted a new DEP at
> > > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> > > Enable true open collaboration on all Debian packages".
> > >
> > > Direct li
Hi!
Thanks for the comments. Responding inline to the questions you raised:
> Then it makes no effort to define communication channels. Before making some
> time consuming change, it's usually better to just ask if that's a good idea
..
> Then the document should enforce a particular commit style
Hi!
> > I have drafted a new DEP at
> > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> > Enable true open collaboration on all Debian packages".
> >
> > Direct link to raw text:
> > https://salsa.debian.org/dep-team/deps/
Quoting Jonas Smedegaard (2024-07-28 01:48:10)
> Hi Otto,
>
> Quoting Otto Kekäläinen (2024-07-28 00:38:40)
> > Hi all,
> >
> > I have drafted a new DEP at
> > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> > Enable tr
Hi Otto,
Quoting Otto Kekäläinen (2024-07-28 00:38:40)
> Hi all,
>
> I have drafted a new DEP at
> https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> Enable true open collaboration on all Debian packages".
>
> Direct link to raw text:
>
Hi all,
I have drafted a new DEP at
https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
Enable true open collaboration on all Debian packages".
Direct link to raw text:
https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/
Programming Lang: Python
Description : Build Debian packages in a docker container
Debpic allows developers to build Debian package in an isolated environment.
Invoke debpic in a repository without any arguments to simply build packages.
The environment is composed from:
* The Debian
"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 --rsyncable,
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 --rsyncable, would you agree
> that this is
Ansgar 🙀 writes:
> In ecosystems like NPM, Cargo, Golang, Python and so on pinning to
> specific versions is also "explicitly intended to be used"; they just
> sometimes don't include convenience copies directly as they have tooling
> to download these (which is not allowed in Debian).
Yeah, thi
a blind eye.
>
> No, there's an explicit exception for cases like gnulib. Policy 4.13:
>
> Some software packages include in their distribution convenience
> copies of code from other software packages, generally so that users
> compiling from source don’t have
y
> we've turned a blind eye.
No, there's an explicit exception for cases like gnulib. Policy 4.13:
Some software packages include in their distribution convenience
copies of code from other software packages, generally so that users
compiling from source don’t have to
d in the beginning of my post. The downsides with not filtering
include (somewhat repeating myself):
- Opens up for bugs causing pre-generated files not being re-generated
even when they are used to build the package. I think this is fairly
common in Debian packages. Making sure all pre-genera
On Sat, May 11, 2024 at 04:09:23PM +0200, Simon Josefsson wrote:
>The current approach of running autoreconf -fi is based on a
>misunderstanding: autoreconf -fi is documented to not replace certain
>files with newer versions:
>https://lists.nongnu.org/archive/html/bug-gnulib/2024-04
On 2024-05-11 07:09, Simon Josefsson via Gnulib discussion list wrote:
I would assume that (some stripped down
version of) git is a requirement to do any useful work on any platform
these days, so maybe it isn't a problem
Yes, my impression also is that Git has migrated into the realm of
cc/gc
Bruno Haible writes:
> Simon Josefsson wrote:
>> Finally, while this is somewhat gnulib specific, I think the practice
>> goes beyond gnulib
>
> Yes, gnulib-tool for modules written in C is similar to
>
> * 'npm install' for JavaScript source code packages [1],
> * 'cargo fetch' for Rust sour
Simon Josefsson wrote:
> Finally, while this is somewhat gnulib specific, I think the practice
> goes beyond gnulib
Yes, gnulib-tool for modules written in C is similar to
* 'npm install' for JavaScript source code packages [1],
* 'cargo fetch' for Rust source code packages [2],
except that
ainst
Debian main policy. Verifying that this happens for all
pre-generated files in an upstream tarball is complicated, fragile
and tedious work. I think it is simple to find examples of mistakes
in this area even for important top-popcon Debian packages. The
current approach of ru
Hi Charles,
* Charles Plessy [2024-05-08 07:27]:
I want to leverage our cluster to automate as much of the rebuilds
as I
can, but could not find the right tool. I tried to run sbuild in a
Singularity image and this failed. However, I do not need the whole
power of engines like sbuild, as non
1 - 100 of 1003 matches
Mail list logo
