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
On Wed Nov 27, 2024 at 4:30 AM GMT, Otto Kekäläinen 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.
First of all may I ask you to not use terms like 'not good' as it may
come off negative towards th
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
"Theodore Ts'o" writes:
> Perhaps we could avoid talking past we formally had a list of
> requirements, and then match possible alternative approachs with how
> well they meet the agreed-upon requirements, and which requirements
> proponents want to dispense with because (at least for them), It's
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
On Thu, Nov 28, 2024 at 10:35:49AM +0100, Simon Josefsson wrote:
>
> 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
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
* Marc Haber [241127 13:52]:
> On Wed, Nov 27, 2024 at 01:48:33PM +0100, Chris Hofstaedtler wrote:
> > * Marc Haber [241127 13:28]:
> > > On Wed, Nov 27, 2024 at 04:58:00PM +0500, Andrey Rakhmatullin wrote:
> > > > Yup, as I said it makes sense. It just feels fragile to me when the
> > > > "prist
On Wed, Nov 27, 2024 at 01:48:33PM +0100, Chris Hofstaedtler wrote:
> * Marc Haber [241127 13:28]:
> > On Wed, Nov 27, 2024 at 04:58:00PM +0500, Andrey Rakhmatullin wrote:
> > > Yup, as I said it makes sense. It just feels fragile to me when the
> > > "pristine" tarball for a given upstream tag in
* Marc Haber [241127 13:28]:
> On Wed, Nov 27, 2024 at 04:58:00PM +0500, Andrey Rakhmatullin wrote:
> > Yup, as I said it makes sense. It just feels fragile to me when the
> > "pristine" tarball for a given upstream tag in a given repo is not
> > determined until someone uploads it.
>
> I would l
On Wed, Nov 27, 2024 at 04:58:00PM +0500, Andrey Rakhmatullin wrote:
> Yup, as I said it makes sense. It just feels fragile to me when the
> "pristine" tarball for a given upstream tag in a given repo is not
> determined until someone uploads it.
I would love to have a possibility to just push a n
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
On 27/11/24 04:30, Otto Kekäläinen wrote:
Secondly, it is perfectly valid for evey single package to have a
debian/gbp.conf and I would in fact prefer that. For every upstream we
need to have metadata on:
- do they have tarball releases (pristine-tar true/false)
- do they have git tags and what i
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
Hi!
On Wed, 27 Nov 2024 at 00:47, wrote:
>
> 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
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 packaging repo t
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 they want to do.
>
> I'd
Quoting Simon Josefsson (2024-11-22 12:54:02)
> Doesn't 'gbp import-orig --uscan' work if you have a watch-file like this:
>
> version=4
> opts="mode=git, pgpmode=none,\
> dversionmangle=s/\+ds\d*$//,repacksuffix=+ds" \
> https://github.com/withfig/autocomplete-tools.git \
> HEAD debian
Johannes Schauer Marin Rodrigues writes:
> 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
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'm happy that
> > works for them
Otto Kekäläinen writes:
>> in addition to the above: gbp is great if it works, if it doesn't I can
>> start to learn to debug a complex system, while on the contrary, if I use
>> git and debuild/pbuilder/sbuild manually all the time, I know those tools,
>> they are rather easy to debug etc.
>
> P
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 that works for them but I don'
On 18/11/2024 18:16, Kari Pahula wrote:
> I'm thinking that it's the merging of debian and upstream branches and
> maintaining it that really causes the warts in gbp and I'm not at all
> sure if there are any actual workflows that require having that.
> "upstreamless" as I described it may be a bit
Hi,
> > and you seem to think adding another Debian specific complex tool will
> > attrack new people? Most people^wcontributors out there know git already,
> > for them a simple git only workflow is *much* more inviting than having
> > to learn gbp *only* to contribute to Debian.
>
> This. Exactl
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-buildpackage commands fo
On Thu, Nov 21, 2024 at 11:26:15AM +, Holger Levsen 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 Kari (2024.11.18_15:40:55_+)
> - Only store debian/ in the repository and use origtargz for the rest.
I used to feel strongly this way, too. However,
A big advantage of storing the upstream sources in git is that you can
use git to manage the quilt patch queue. I used to be pretty good at
* Holger Levsen [241121 12:26]:
> and you seem to think adding another Debian specific complex tool will
> attrack new people? Most people^wcontributors out there know git already,
> for them a simple git only workflow is *much* more inviting than having
> to learn gbp *only* to contribute to Debi
On Wed, Nov 20, 2024 at 08:10:30PM -0800, Otto Kekäläinen wrote:
> > 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
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 a happy user. However, it
too
Hello Kari,
Have you seen:
https://wiki.debian.org/GitPackagingSurvey
You may find something suitable for what you want there.
--
Sean Whitton
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.
just as another data point. (the above.)
please dont enforce git-buildpackage
Hi!
> With all the recent talk about increasing the use of git for
> packaging, I'd like to address one thing: git-buildpackage is very
> complex to use. As an alternative, I'd like to propose a simpler
> setup:
..
> sick of it and I can tell you it only makes me want to ignore you. If
> you ask
On Mon, Nov 18, 2024 at 05:40:55PM +0200, Kari Pahula wrote:
> With all the recent talk about increasing the use of git for
> packaging, I'd like to address one thing: git-buildpackage is very
> complex to use. As an alternative, I'd like to propose a simpler
> setup:
>
> - Only store debian/ in
On Mon, Nov 18, 2024 at 08:16:59PM +0200, Kari Pahula wrote:
> > However... different people are used to different workflows.
> > I personally really, really like the fact that I have the Git history of
> > all the upstream files in the same repo and I don't have to go over to
> > a different repo
On Mon, Nov 18, 2024 at 06:19:58PM +0200, Peter Pentchev wrote:
> However... different people are used to different workflows.
> I personally really, really like the fact that I have the Git history of
> all the upstream files in the same repo and I don't have to go over to
> a different repo to fi
On Mon, Nov 18, 2024 at 05:40:55PM +0200, Kari Pahula wrote:
> With all the recent talk about increasing the use of git for
> packaging, I'd like to address one thing: git-buildpackage is very
> complex to use. As an alternative, I'd like to propose a simpler
> setup:
We want fewer allowed setups
Kari,
On Monday, November 18, 2024 8:40:55 AM MST Kari Pahula wrote:
> I've been a DD longer than git-buildpackage has been around and I've
> been looking at using it at various times but pretty much every time
> my reaction's been "must I?" I know a lot of people do use gbp daily
> for work with
With all the recent talk about increasing the use of git for
packaging, I'd like to address one thing: git-buildpackage is very
complex to use. As an alternative, I'd like to propose a simpler
setup:
- Only store debian/ in the repository and use origtargz for the rest.
- One branch per distribu
99 matches
Mail list logo
