Hi!
I'd love to have little help with postfix before trixie.
There are 2 open issues which needs fixing, both involving debconf,
and I haven't dealt with debconf before (despite being a long-term
DD), and my time these days is scarce, - so it would be difficult
for me to complete the task before
On Sunday, December 29, 2024 12:39:59 PM MST Richard Lewis wrote:
> Otto Kekäläinen writes:
> >> >> i think the barrier is likely to be "i didnt know you could do that?"
> >> >> rather than "how do i use that?"
> >> >
> >> > Salsa CI is and has always been opt-in.
> >>
> >> oops - i meant the op
Am 30. Dezember 2024 11:40:31 MEZ schrieb Thomas Goirand :
>On 12/28/24 22:52, Simon Josefsson wrote:
>> Is it possible to configure Salsa so instead of using the GitLab default
>> of .gitlab-ci.yml it uses debian/salsa-ci.yml if that file exists but
>> otherwise falls back to recipes/debian.yml@sa
On 12/28/24 22:52, Simon Josefsson wrote:
Is it possible to configure Salsa so instead of using the GitLab default
of .gitlab-ci.yml it uses debian/salsa-ci.yml if that file exists but
otherwise falls back to recipes/debian.yml@salsa-ci-team/pipeline? That
seems like a sensible global configurat
Richard Lewis writes:
> Otto Kekäläinen writes:
>
>> Hi!
>>
>>> > Salsa CI is a great system for all aspiring Debian packagers to test
>>> > their packages before requesting review from mentors
>>>
>>> > However, as there are still packages not using Salsa CI, I wonder is
>>> > it straightforwar
Richard Lewis
writes:
> Otto Kekäläinen writes:
>
>> Hi!
>>
>>> > Salsa CI is a great system for all aspiring Debian packagers to test
>>> > their packages before requesting review from mentors
>>>
>>> > However, as there are still packages not using Salsa CI, I wonder is
>>> > it straightforwar
Hi,
> >> >> i think the barrier is likely to be "i didnt know you could do that?"
> >> >> rather than "how do i use that?"
> >> >
> >> > Salsa CI is and has always been opt-in.
> >>
> >> oops - i meant the oppposite, ie make people have to opt out of having
> >> it run, rather than have to enable
Otto Kekäläinen writes:
>> >> i think the barrier is likely to be "i didnt know you could do that?"
>> >> rather than "how do i use that?"
>> >
>> > Salsa CI is and has always been opt-in.
>>
>> oops - i meant the oppposite, ie make people have to opt out of having
>> it run, rather than have to
> >> > Salsa CI is a great system for all aspiring Debian packagers to test
> >> > their packages before requesting review from mentors
> >>
> >> > However, as there are still packages not using Salsa CI, I wonder is
> >> > it straightforward enough for everyone?
> >> >
> >>
> >> I think the best s
Otto Kekäläinen writes:
> Hi!
>
>> > Salsa CI is a great system for all aspiring Debian packagers to test
>> > their packages before requesting review from mentors
>>
>> > However, as there are still packages not using Salsa CI, I wonder is
>> > it straightforward enough for everyone?
>> >
>>
>>
> I think the best solution would be to make it opt-in rather than
> opt-out?
>
> i think the barrier is likely to be "i didnt know you could do that?"
> rather than "how do i use that?"
Salsa CI is and has always been opt-in. One needs to add a
`debian/salsa-ci.y
Otto Kekäläinen writes:
> Salsa CI is a great system for all aspiring Debian packagers to test
> their packages before requesting review from mentors
> However, as there are still packages not using Salsa CI, I wonder is
> it straightforward enough for everyone?
>
I think the best solution woul
Il 23/12/2024 18:09, Otto Kekäläinen ha scritto:
Hi!
Salsa CI is a great system for all aspiring Debian packagers to test
their packages before requesting review from mentors, and also for
experienced packagers to ensure there are no easily testable lapses
before uploading to Debian.
Anyone wit
Hi!
Salsa CI is a great system for all aspiring Debian packagers to test
their packages before requesting review from mentors, and also for
experienced packagers to ensure there are no easily testable lapses
before uploading to Debian.
Anyone with a Salsa account can use it. Simply follow the REA
Hello,
I would like to inform you that I am working on the initial packaging of
golang-github-lair-framework-go-nmap. The initial packaging repository is
available on Salsa at the following link:
https://salsa.debian.org/marcos.rcarvalho/golang-github-lair-framework-go-nmap
Once the package is
Hello,
On Sat 07 Dec 2024 at 05:50pm GMT, Holger Levsen wrote:
> On Sat, Dec 07, 2024 at 10:39:43PM +0500, Andrey Rakhmatullin wrote:
>> No, there is clearly no consensus on unifying any workflows. Everyone
>> thinks their workflow is superior and canneeds to stay.
>
> I agree with the first sent
On Sat Dec 7, 2024 at 5:39 PM GMT, Andrey Rakhmatullin wrote:
No, there is clearly no consensus on unifying any workflows. Everyone
thinks their workflow is superior and canneeds to stay.
I'm more optimistic than this. I don't think we'll ever reach *one*
workflow, but I think there may be a s
On Sat, Dec 07, 2024 at 10:39:43PM +0500, Andrey Rakhmatullin wrote:
> No, there is clearly no consensus on unifying any workflows. Everyone
> thinks their workflow is superior and canneeds to stay.
I agree with the first sentence but I think the 2nd sentence is too much drama.
Those many workflo
On 07/12/2024 14:34, Andrea Pappacoda wrote:
It seems that we're all agreeing on trying to unify our different
workflows as much as possible. Why do we have `git deborig`, `gbp
export-orig`, `origtargz`, etc.? Couldn't we decide to unify on a single
"front end" command, which chooses different
On Sat, Dec 07, 2024 at 02:34:20PM +0100, Andrea Pappacoda wrote:
> Hi all, I've tried catching up with the whole thread, but didn't fully yet.
> So excuse me if this has been asked/answered before.
>
> On Tue Dec 3, 2024 at 3:40 AM CET, Sean Whitton wrote:
> > Then just make one: 'git deborig'.
>
Hi all, I've tried catching up with the whole thread, but didn't fully
yet. So excuse me if this has been asked/answered before.
On Tue Dec 3, 2024 at 3:40 AM CET, Sean Whitton wrote:
Then just make one: 'git deborig'.
I appreciate not everyone is happy with this, but it solves the
problem.
On Tue, Dec 03, 2024 at 10:40:03AM +0800, Sean Whitton wrote:
> >> > One possible rebuttal to this is "gbp needs to do the right thing then".
> >> > Currently gbp by default generates a broken tarball, which is also a
> >> > source of confusion for many.
> >>
> >> Do you have a bug report number?
>
Hello,
On Thu 28 Nov 2024 at 10:29am -10, Theodore Ts'o wrote:
> *) As much as possible, we want to be able to use the unmodified
>source files are officially released by upstream. Which might be a
>tarball and/or a signed git tag.
I ignore this completely, and I'm not the only one.
Ev
Hello,
On Tue 26 Nov 2024 at 11:20pm +05, Andrey Rakhmatullin wrote:
> The archive, when the tarball is already there.
>
> These suggestions never discuss what to do when the tarball was never
> uploaded yet, even I didn't discuss that for simplicity.
Then just make one: 'git deborig'.
I apprec
Hello,
On Tue 26 Nov 2024 at 11:28pm +05, Andrey Rakhmatullin wrote:
> On Tue, Nov 26, 2024 at 06:53:01PM +0100, Mechtilde Stehmann wrote:
>> > One possible rebuttal to this is "gbp needs to do the right thing then".
>> > Currently gbp by default generates a broken tarball, which is also a
>> > s
Hub release-derived tarball, is
used instead, *and* the pristine-tar branch duly populated (which again
is independent from whether the maintainers have provided a
debian/gbp.conf with a pristine-tar key value in it.) Likewise there are
package repositories where the packaging is based on an upstream ta
Le 2024-11-29 18:35, Jonas Smedegaard a écrit :
Quoting sre4e...@free.fr (2024-11-29 16:57:23)
opened 15 years and a few days ago.
Great that you took "filing a bugreport" to imply checking first if
the issue was already reported.
Well, the point I wanted to make here was more about the spec
Quoting sre4e...@free.fr (2024-11-29 16:57:23)
> Le 2024-11-29 15:12, Jonas Smedegaard a écrit :
> > Quoting sre4e...@free.fr (2024-11-29 13:29:05)
> >>
> >> Would it be possible to make it the default when there is already an
> >> existing `pristine-tar` branch in the repo being worked on?
> >
>
Le 2024-11-29 10:58, Simon Josefsson a écrit :
The only record of this is
indirectly with the maintainer signing the *.changes file during
package
upload. But that is weak (only successfully uploaded packages are
protected, not work-in-progress) and not widely audited (*.changes
files
aren't
Le 2024-11-29 15:12, Jonas Smedegaard a écrit :
Quoting sre4e...@free.fr (2024-11-29 13:29:05)
Would it be possible to make it the default when there is already an
existing `pristine-tar` branch in the repo being worked on?
Please consider filing that as a bugreport against bit-buildpackage -
Quoting sre4e...@free.fr (2024-11-29 13:29:05)
> Le 2024-11-29 03:17, Otto Kekäläinen a écrit :
>
> > but right now I warmly recommend people use 'pristine-tar = True' in
> > their gbp.confs.
>
> Would it be possible to make it the default when there is already an
> existing `pristine-tar` branc
Hi,
Le 2024-11-29 03:17, Otto Kekäläinen a écrit :
but right now I warmly recommend people use 'pristine-tar = True' in
their gbp.confs.
Would it be possible to make it the default when there is already an
existing `pristine-tar` branch in the repo being worked on?
Cheers,
--
Julien Pliss
2024, നവം 29 7:48:10 AM Otto Kekäläinen :
> Thanks Pirate Praveen for providing the first actual concrete case in
> this thread where pristine-tar had some issue!
>
> I noticed an interesting thing about this case:
>
> ± origtargz --download-only
> pristine-tar: successfully generated
> ../node-ca
quot; first?
>
> I will note that this approach would break backwads compatibility with
> existing Debian source packaging, right? That is, you're proposing
> that the debian/usptream/*SUMS file would replace the
> *.orig.tar.gz.asc file?
I don't think that works: the nice thi
Hello,
On Thu 28 Nov 2024 at 06:17pm -08, Otto Kekäläinen wrote:
> In summary: nothing in this is an argument to stop using pristine-tar
> in all packages. I think Theodore Ts'o also laid out pretty well all
> the benefits of pristine-tar and why it was originally developed, and
> those requireme
Thanks Pirate Praveen for providing the first actual concrete case in
this thread where pristine-tar had some issue!
I noticed an interesting thing about this case:
± origtargz --download-only
pristine-tar: successfully generated
../node-cacache_17.0.3+~cs10.3.7.orig-npmcli-move-file.tar.gz
prist
For bonus points, maybe
also a tool that validates a SHA256SUM file with a git commit id,
again without needing to do a "git checkout" first?
I will note that this approach would break backwads compatibility with
existing Debian source packaging, right? That
On Thu, Nov 28, 2024 at 07:33:27PM +0530, Pirate Praveen wrote:
> 2024, നവം 28 5:46:47 PM Andrey Rakhmatullin :
> >
> >> Same works with
> >>
> >> pravi@mahishi2:/tmp/node-cacache$ gbp export-orig --pristine-tar
> >
> > Not sure what does this imply.
>
> gbp is able to recreate the orig tars when
2024, നവം 28 5:46:47 PM Andrey Rakhmatullin :
>
>> Same works with
>>
>> pravi@mahishi2:/tmp/node-cacache$ gbp export-orig --pristine-tar
>
> Not sure what does this imply.
gbp is able to recreate the orig tars when origtargz fails. So it is a known
work around.
* 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
On Thu, Nov 28, 2024 at 05:37:41PM +0530, Pirate Praveen wrote:
> This can now be reproduced with node-cacache
>
> pravi@mahishi2:/tmp$ gbp clone --pristine-tar
> g...@salsa.debian.org:js-team/node-cacache.git
> gbp:info: Cloning from 'g...@salsa.debian.org:js-team/node-cacache.git'
> pravi@mahish
On 11/28/24 5:29 PM, Pirate Praveen wrote:
On 11/28/24 5:22 PM, Paul Gevers wrote:
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.
On 11/28/24 5:22 PM, Paul Gevers wrote:
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 is us
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 is using multiple orig tar files
(2) for several
On Thu, 28 Nov 2024 15:06:15 +0500, Andrey Rakhmatullin wrote:
> > Often I want to upload it to the archive, that's quite typical in
> > teams: A uploads -1 and B uploads -2 with a bugfix or whatever.
> The hypothetical change in the tools to silently download the tarball from
> the archive will m
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 export-orig takes care of it, unless you need to actua
2024, നവം 28 3:06:13 PM Simon Josefsson :
> I think this is a good example of us talking past each other in this
> thread: some people question the value of pristine in the first place
> (and I've been compelled by those arguments), and some people argue that
> the cost is small and there are no bu
On Thu, 28 Nov 2024 09:41:53 +0100, Marco d'Itri wrote:
> On Nov 27, 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 export-orig takes care of it, unl
"Theodore Ts'o" writes:
> On Tue, Nov 26, 2024 at 04:27:37PM +0100, Simon Josefsson wrote:
>> I have never understood what value there is in duplicating the uploaded
>> tarball in the git repository.
>
> The actual cost of storing the pristine tarball is quite small.
I think this is a good examp
On Thu, Nov 28, 2024 at 09:41:53AM +0100, Marco d'Itri wrote:
> On Nov 27, 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 export-orig takes care of
On Nov 27, 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 export-orig takes care of it, unless you need to actually
upload it to the archive.
--
ciao,
Mar
On Tue, Nov 26, 2024 at 04:27:37PM +0100, Simon Josefsson wrote:
> I have never understood what value there is in duplicating the uploaded
> tarball in the git repository.
The actual cost of storing the pristine tarball is quite small. For
example:
commit 91c7ab39337da63371b4814bef2b2aaf85a9e37c
t 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 love to have a possibility to just push a new upstream tarball
> > > into the ar
uot; tarball for a given upstream tag in a given repo is not
> > > determined until someone uploads it.
> >
> > I would love to have a possibility to just push a new upstream tarball
> > into the archive at the very beginning of the process of packaging the
> >
omeone uploads it.
>
> I would love to have a possibility to just push a new upstream tarball
> into the archive at the very beginning of the process of packaging the
> new upstream version (and without triggering anything else in Debian).
I hear what you're saying, but in the end
lity to just push a new upstream tarball
into the archive at the very beginning of the process of packaging the
new upstream version (and without triggering anything else in Debian).
I have done -0 experimental uploads just for the sake of the
orig.tar.
On Tue, Nov 26, 2024 at 08:30:31PM -0800, Otto Kekäläinen wrote:
> > > > One possible rebuttal to this is "gbp needs to do the right thing then".
> > > > Currently gbp by default generates a broken tarball, which is also a
> > > > source of confusion for many.
> > >
> > > Do you have a bug report n
tream/metadata.
On the same topic, many people have asked in the past for a
machine-readable and tooling-independent way to specify:
a) information about the way upstream does releases and,
b) the packaging workflow used by that package manager.
For some, this documentation would be a step-stop towa
On Tue, Nov 26, 2024 at 08:49:44PM +0100, Simon Josefsson 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:
> >>
On Tue, Nov 26, 2024 at 08:49:44PM +0100, Simon Josefsson wrote:
> Andrey Rakhmatullin writes:
> > On Tue, Nov 26, 2024 at 06:54:18PM +0100, Chris Hofstaedtler wrote:
> >> This is 1). It cannot be done generically as it requires knowing
> >> where to download from, etc.
> >
> > The archive, when t
gregor herrmann writes:
> On Tue, 26 Nov 2024 20:49:44 +0100, Simon Josefsson wrote:
>
>> If you haven't made an upload, then wouldn't you have the tarball
>> locally while working on preparing the upload?
>> And if someone doesn't have the orig.tar.gz locally, then why would
>> anyone want to ge
On Tue, 26 Nov 2024 20:49:44 +0100, Simon Josefsson wrote:
> If you haven't made an upload, then wouldn't you have the tarball
> locally while working on preparing the upload?
> And if someone doesn't have the orig.tar.gz locally, then why would
> anyone want to get it from a random git repository
* 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
this will not change) has DSFG-non-free
> > content
> > in it, then I should not copy that into a git packaging repo that is
> > targeting
> > main. Removing the problematic parts from the upstream git repos would
> > rewrite
> > their history, invalidate tags etc, so t
Hi Johannes,
Le 2024-11-22 12:45, Johannes Schauer Marin Rodrigues a écrit :
That's what I'm doing. But that works with tarballs not with upstream
as git.
If upstream (deliberately, so this will not change) has DSFG-non-free
content
in it, then I should not copy that into a git pack
On Nov 27, Johannes Schauer Marin Rodrigues wrote:
> If the upstream tarball is in the archive, it's probably okay to retrieve one
> from there. It's not always trivial because now you need to have the right
> "deb-src" lines enabled in your apt sources.list but it's possible. But how do
It is t
On Tue, Nov 26, 2024 at 10:31 PM Otto Kekäläinen wrote:
>
> Hi,
>
> (replying in one email to various comments in past 24h)
>
> > How common debian/gbp.conf points at something else: perhaps gbp's
> > defaults are not good, if that many packages need to override them.
>
> First of all may I ask yo
Hi,
(replying in one email to various comments in past 24h)
> How common debian/gbp.conf points at something else: perhaps gbp's
> defaults are not good, if that many packages need to override them.
First of all may I ask you to not use terms like 'not good' as it may
come off negative towards t
Quoting Marco d'Itri (2024-11-26 23:34:24)
> On Nov 26, Jonathan Dowland wrote:
> > 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?
> Not really. The debian branches of all of my packages[1]
On Nov 26, Jonathan Dowland wrote:
> 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?
Not really. The debian branches of all of my packages[1] are based off
the upstream git repository, which i
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 certainly isn't the only way here (it's true that C
Colin Watson writes:
> On Tue, Nov 26, 2024 at 08:49:44PM +0100, Simon Josefsson wrote:
>> If you haven't made an upload, then wouldn't you have the tarball
>> locally while working on preparing the upload?
>>
>> And if someone doesn't have the orig.tar.gz locally, then why would
>> anyone want
On Tue, Nov 26, 2024 at 08:49:44PM +0100, Simon Josefsson wrote:
> If you haven't made an upload, then wouldn't you have the tarball
> locally while working on preparing the upload?
>
> And if someone doesn't have the orig.tar.gz locally, then why would
> anyone want to get it from a random git re
Andrey Rakhmatullin writes:
> On Tue, Nov 26, 2024 at 06:54:18PM +0100, Chris Hofstaedtler 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
>> > > usu
On Tue, Nov 26, 2024 at 06:53:01PM +0100, Mechtilde Stehmann wrote:
> > One possible rebuttal to this is "gbp needs to do the right thing then".
> > Currently gbp by default generates a broken tarball, which is also a
> > source of confusion for many.
>
> Do you have a bug report number?
No.
I've
On Tue, Nov 26, 2024 at 06:54:18PM +0100, Chris Hofstaedtler 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) trea
* 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 pristine-tar still valuable these days?
> >
> > Unfortunately
Hello Andrey,
Am 26.11.24 um 17:44 schrieb Andrey Rakhmatullin:
On Tue, Nov 26, 2024 at 04:27:37PM +0100, Simon Josefsson wrote:
One possible rebuttal to this is "gbp needs to do the right thing then".
Currently gbp by default generates a broken tarball, which is also a
source of confusion for
On Tue, Nov 26, 2024 at 09:44:31PM +0500, Andrey Rakhmatullin wrote:
> Currently gbp by default generates a broken tarball, which is also a
> source of confusion for many.
I'd dare to even call this a bug.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-ac
On Tue, Nov 26, 2024 at 04:27:37PM +0100, Simon Josefsson 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 problem o
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 pristine-tar still valuable these days?
>
> Unfortunately yes. AFAIK the two options for fixing this that are
>
On Tue, Nov 26, 2024 at 11:59:26AM +, Jonathan Dowland wrote:
> > Yes, as they don't enable pristine-tar
>
> Is pristine-tar still valuable these days?
Extremely, unless your workflow requires using something else to get the
upstream tarball from the archive (among other less important
requir
* 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
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?
and cannot guess your branch naming system.
I haven't checked, but in an ideal world gbp would default to the same
values for these as described
On Tue, Nov 26, 2024 at 08:51:43AM +, Jonathan Dowland wrote:
> How common debian/gbp.conf points at something else: perhaps gbp's defaults
> are not good, if that many packages need to override them.
Yes, as they don't enable pristine-tar and cannot guess your branch naming
system.
--
WBR,
On Fri Nov 22, 2024 at 11:29 AM GMT, Simon Josefsson wrote:
I thought about the gbp aspect of the lets-move-things-to-salsa and I
suggest to consider if they are better left orthogonal. Could you make
one DEP for lets-move-to-salsa and one DEP for
lets-document-a-build-workflow?
I haven't read
On Thu Nov 21, 2024 at 4:10 AM GMT, Otto Kekäläinen wrote:
There is a debian/gbp.conf in 13573 packages in Debian
This is an interesting proxy measure for the prevalence of gbp usage. It
probably undercounts: I sometimes use gbp but I've only got this file in
one of my sources (one I recently
Hi,
Quoting Otto Kekäläinen (2024-11-23 00:09:41)
> You can have upstream git and tarballs at the same time, and even have DFSG
> cleanup take place and git show you exactly the differences of all the
> versions.
I'm interested in the DFSG cleanup. How can this be done while having an
upstream gi
Hi!
> > I am contemplating if I should also make videos on Debian packaging best
> > practices, or have start a new Matrix channel specifically to help
> > maintainers setup their git repositories correctly and find the optimal
> > git-buildpackage commands for each thing
hange the source) use
the orig.tar and dsc for their development or should they not use the packaging
git instead if they want to make changes or contribute? If they use the latter,
should what they are using there not adhere to the principles of the DFSG? If I
run "apt-get source tinyusb"
e the upstream git as part of their packaging git. I'm happy that
>> > works for them but I don't see how I can leave my tarball-centered
>> > workflows (even though all my upstream work in git) if all my upstreams
>> > ship DFSG non-free material which I have t
Quoting Simon Josefsson (2024-11-22 12:18:36)
> > I like to read of other people's workflows but then I often do not see how
> > their workflows can possibly fit my packages. There seem to be many people
> > who have the upstream git as part of their packaging git. I
ing, and maybe some other
minor aspects, but don't we have that already in DEP 14?
Compare making packaging contributions to Debian to packaging
contributions to Homebrew, Alpine, OpenWRT, ArchLinux, Guix, etc. There
is a possibility to reach a completely git-based Salsa workflow for
Debian
Johannes Schauer Marin Rodrigues writes:
> I like to read of other people's workflows but then I often do not see
> how their workflows can possibly fit my packages. There seem to be
> many people who have the upstream git as part of their packaging
> git. I'm happy tha
less" as I described it may be a bit too much for general use
> but could there be a case for doing everything with a mergeless model
> instead?
Could we turn the current packaging format:
foo-1.2.3/ -> upstream source
src/
...
debian/ -> Debian inserted things
where debian/
current most common workflows and
elevating them as the recommended baseline for those who are keen to
collaborate more efficiently.
In Debian/DEP-18 for all the normal daily packaging work like pulling
and pushing, making commits, amending commits, creating branches,
rebasing branches etc y
Hi,
> > > fwiw, I'm also not using git-buildpackage and I don't want to. (Step
> > > learning
> > > curve, too much magic, hard to debug and I dont see benefits for the
> > > packages
> > > I maintain.) I'm also not a beginner. And I love gbp-dch.
> > I think git-buildpackage is great, and I am
On Wednesday, November 20, 2024 9:10:30 PM MST Otto Kekäläinen wrote:
> I am not enforcing git-buildpackage on everyone. I am accelerating the
> convergence of workflows so that it is easier for maintainers to
> collaborate, so we can have more code reviews, more new maintainers,
> and in the long
Hi,
Quoting Otto Kekäläinen (2024-11-19 07:34:45)
> I am contemplating if I should also make videos on Debian packaging best
> practices, or have start a new Matrix channel specifically to help
> maintainers setup their git repositories correctly and find the optimal
> git-buildpack
1 - 100 of 3265 matches
Mail list logo
