On 24/01/18 21:45, Michael Stapelberg wrote:
> I filed a wishlist bug for the remote configuration:
> https://bugs.debian.org/888313
Thanks!
> To import it, AIUI, I should tag the latest upstream branch commit
> (7cafcd837844e784b526369c9bce262804aebc60) with tag
> upstream/0.0_git20160503.7cafcd
On 23/01/18 21:48, Michael Stapelberg wrote:
> Status update: I now have tooling to perform the “delete existing
Yay!
> Also, I’m wondering how we can accomplish automated git remote
> configuration, i.e. how do people obtain an upstream branch which tracks
> the correct upstream remote branch? A
I filed a wishlist bug for the remote configuration:
https://bugs.debian.org/888313
My tooling is now able to work with almost all repositories — there are
about 20 which still require some fixes, I’ll send out emails where I can’t
do the fix myself.
I have a beginner question regarding the git u
Status update: I now have tooling to perform the “delete existing upstream
branch, create a tracking upstream branch in correct version from Go import
path” step. The tooling still fails on about 60 of 901 repositories. I’ll
take a look at the failures and give another status update.
The VCS compo
Status update: I discovered (and documented) gbp’s postclone=origtargz
option. Also, I prepared (and documented/referenced) two git hooks.
I’m still not entirely certain about how to approach the “upstream
branch contains upstream git history” change in the best way.
Suggestions/tips welcome.
On
On Thu, Nov 9, 2017 at 6:44 AM, Martín Ferrari wrote:
> On 09/11/17 04:24, Michael Stapelberg wrote:
>
>> At least for our transition period, we’ll have to use origtargz.
>
> Yes, but only for -2 and up releases. For -1, origtargz would do the
> same as gbp (AFAIK).
Yes, for -1 releases, users su
On 09/11/17 04:24, Michael Stapelberg wrote:
> At least for our transition period, we’ll have to use origtargz.
Yes, but only for -2 and up releases. For -1, origtargz would do the
same as gbp (AFAIK).
> I’m happy to pro-actively add compression algorithm/level options and
> evaluate at a later
Thanks for looking into this.
I think mandating compression algorithms and levels is necessary for
this approach indeed, but I’m not sure if it’s sufficient.
At least for our transition period, we’ll have to use origtargz.
I’m happy to pro-actively add compression algorithm/level options and
eva
On 08/11/17 21:01, Martín Ferrari wrote:
> The best test would be to use gbp to create the tarballs under different
> conditions (machine, user name, path, manually touch()ing files locally)
> and see if they are really reproducible.
For one data point, I just tried this on two different machines
On 08/11/17 17:55, Michael Stapelberg wrote:
> Quote from the commit message
> (https://anonscm.debian.org/git/pkg-go/website.git/commit/?id=866810cfeea8086dbdfc0176b148f7a063e3ac0b):
One comment on this:
+NOTE: Using `--git-upstream-tree=TAG` (the default) is not sufficient
to obtain
+a byte-for
On 08/11/17 17:55, Michael Stapelberg wrote:
> I started a document describing the changes we agreed on, the
> rationale behind them, the old/new workflows and the migration
> strategy.
Thanks!! I am very glad we are moving forward with this!
> I hope I can make some progress on this in the next
I started a document describing the changes we agreed on, the
rationale behind them, the old/new workflows and the migration
strategy.
Quote from the commit message
(https://anonscm.debian.org/git/pkg-go/website.git/commit/?id=866810cfeea8086dbdfc0176b148f7a063e3ac0b):
> Quite a number of points
On 06/11/17 15:04, Martín Ferrari wrote:
> I have added something that I think it is widely accepted, but was not
> explicitly discussed, and that I would like to be set on policy: should
> we mandate merging of upstream code in debian branch?
Just to clarify: I don't think this new point should
On 06/11/17 04:04, Michael Stapelberg wrote:
> Reminder: The deadline is approaching in a few hours. Please have a final
> look.
Thanks!
I have added something that I think it is widely accepted, but was not
explicitly discussed, and that I would like to be set on policy: should
we mandate mergi
Reminder: The deadline is approaching in a few hours. Please have a final look.
You’ll hear from me this evening,
On Wed, Oct 25, 2017 at 10:03 AM, Michael Stapelberg
wrote:
> Everyone, thanks for your updates, that helped clarify things!
>
> I have updated the document to reflect the new positi
Everyone, thanks for your updates, that helped clarify things!
I have updated the document to reflect the new positions. It seems
like we’re agreeing on having the upstream git history in the upstream
branch, and that also means importing new upstream versions no longer
needs special tooling.
Rem
On 21/10/17 17:10, Michael Stapelberg wrote:
> Please give it a look at
> https://oasis.sandstorm.io/shared/l4YsLYdwUgnhzzwmKS_TGwWyVQ9Ol8EKiMR8qhpHaS2
> and add any remaining discussion points you would like to bring up
> within the next 14 days, i.e. no later than 2017-11-04.
I added my comment
Sorry for taking so long to reply with this, but I’ve had little time recently.
I think that, at this point, it makes sense to structure the
discussion a little bit more. To that end, I would like to step up as
moderator, and have also created an etherpad, which should allow for a
more pleasant fo
On Tue, Aug 15, 2017 at 11:02:39PM +0200, Michael Stapelberg wrote:
> 6. I have come to appreciate pristine-tar, as it is the only reliable way
> (that I know of) to prepare uploads for packages which already have their
> orig tarball in Debian. Whenever I come across a package which isn’t using
>
On 20/08/17 19:21, Michael Stapelberg wrote:
>> Gccgo has many quirks. One is that it does not use the vendor directory
>> (I need to check if this is true with the latest version), so you might
>> need to copy vendor into the builddirectory.
>
> …hopefully only temporarily, though, right? Ideall
On Sun, Aug 20, 2017 at 7:18 PM, Martín Ferrari wrote:
> On 20/08/17 17:35, Martín Ferrari wrote:
>> So, my turn to describe workflows.
>
> Some things I forgot in my previous email:
>
> * I am not married to the idea of dch + debcommit, specially when I have
> merge conflicts. I understand the me
On Sun, Aug 20, 2017 at 7:05 PM, Martín Ferrari wrote:
> On 20/08/17 18:46, Michael Stapelberg wrote:
>
>> Side note, not meant to persuade anyone one way or the other: I just
>> realized why I never saw any appeal in that argument: I find git
>> packaging (or git in general?) too brittle and conf
On 20/08/17 17:35, Martín Ferrari wrote:
> So, my turn to describe workflows.
Some things I forgot in my previous email:
* I am not married to the idea of dch + debcommit, specially when I have
merge conflicts. I understand the merits of git commit + gbp dch.
* The export=WC option in gbp.conf is
On 20/08/17 18:46, Michael Stapelberg wrote:
> Side note, not meant to persuade anyone one way or the other: I just
> realized why I never saw any appeal in that argument: I find git
> packaging (or git in general?) too brittle and confusing to keep what
> I consider are multiple projects in the s
While we’re on the topic:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859867 discusses
making sbuild easier to install/use :)
On Sun, Aug 20, 2017 at 6:56 PM, Martín Ferrari wrote:
> On 20/08/17 18:36, Michael Stapelberg wrote:
>> I use gbp with sbuild, and I do see different behavior with/
On 20/08/17 18:36, Michael Stapelberg wrote:
> I use gbp with sbuild, and I do see different behavior with/without
> exporting. Take for example the freeradius repository, where the build
> fails without git-export-dir: https://paste.debian.net/982241/
I guess the difference is with not having an
On Sun, Aug 20, 2017 at 5:35 PM, Martín Ferrari wrote:
> So, my turn to describe workflows.
>
> I use gbp, pristine-tar, cowbuilder (but planning to move to sbuild),
> dch, debcommit as my main tools. I have not really used dh-make-golang much.
>
> My global gbp configuration is as follows:
>
> [D
On Sun, Aug 20, 2017 at 2:30 PM, Martín Ferrari wrote:
> Hi Mickael,
>
> I haven't yet got the time to write down properly my workflow, but I
> will still reply to some points. :)
>
> On 15/08/17 23:02, Michael Stapelberg wrote:
>
>> 1. I store packaging in e.g. ~/d/pkg/gocryptfs and build using `
So, my turn to describe workflows.
I use gbp, pristine-tar, cowbuilder (but planning to move to sbuild),
dch, debcommit as my main tools. I have not really used dh-make-golang much.
My global gbp configuration is as follows:
[DEFAULT]
pristine-tar = True
sign-tags = True
[buildpackage]
export =
Hey,
On 16/08/17 04:54, Michael Hudson-Doyle wrote:
> I think I /slightly/ prefer the upstream branch to be upstream's git
> history not a series of imports of tarballs. But I'm not set on it, and
> gbp doesn't really get on with this approach if you're just packaging a
> random commit rather tha
Hi Mickael,
I haven't yet got the time to write down properly my workflow, but I
will still reply to some points. :)
On 15/08/17 23:02, Michael Stapelberg wrote:
> 1. I store packaging in e.g. ~/d/pkg/gocryptfs and build using `gbp
> buildpackage --git-export-dir=~/d/out/gocryptfs`. By using
> -
On Tuesday, 15 August 2017 11:02:39 PM AEST Michael Stapelberg wrote:
> 6. I have come to appreciate pristine-tar, as it is the only reliable way
> (that I know of) to prepare uploads for packages which already have their
> orig tarball in Debian.
Then perhaps you should learn about `origtargz` ut
Hi all,
just a quick comment to one of Michael's questions:
> Satta requested an option to disable SSL verification for badly
> configured redirection sites.
>
>
> Which sites are affected? Did we try contacting the maintainers and fix
> their config? In the days of LetsEncrypt, it seem
On Sat, Aug 12, 2017 at 4:01 AM, Martín Ferrari wrote:
> Git workflows
> -
>
> It was discussed about the problem of having so many different
> workflows, as it makes it difficult to work on packages prepared by
> other team members.
>
> The agreement was to find one standard and make
On 12 August 2017 at 08:01, Martín Ferrari wrote:
> Pkg-go BoF meeting minutes
> ==
>
> On Tuesday, we had the first in-person meeting of the team. We met for 2
> hours to discuss our current issues and to plan for the future.
>
> People present
> --
>
> Alexan
Thanks for sending these out. Comments inline:
On Fri, Aug 11, 2017 at 10:01 PM, Martín Ferrari wrote:
> Pkg-go BoF meeting minutes
> ==
>
> On Tuesday, we had the first in-person meeting of the team. We met for 2
> hours to discuss our current issues and to plan for the
36 matches
Mail list logo