Go Debian/Ubuntu packages announcement
Jan Mercl
development environment (compiler/standard tools and Go packages/...)
for x86 and x86_64 is now available for Ubuntu in PPA (personal
package archive) at launchpad.net. Soon to be followed by Debian
packages in unstable branch. The packages reflect the current release
Go version and the PPA is going to be maintained, as the new releases
will come, by CZ.NIC Labs.
Please be aware that those packages are work-in-progress and they are
not meant to be included in the standard stable Debian releases
because the language is still a fast moving target. However with the
inclusion to Debian unstable the language will be given much wider
audience of testers and developers.
Debian packages will be available from Debian unstable after our ftp-
masters will let them through.
Packages for Ubuntu: http://launchpad.net/~cz.nic-labs/+archive/golang
Gustavo Niemeyer
> Easy installation with automated updates of the Go language
> development environment (compiler/standard tools and Go packages/...)
> for x86 and x86_64 is now available for Ubuntu in PPA (personal
FWIW, there were packages available already, as announced:
http://groups.google.com/group/golang-nuts/t/a378126d7d061f0e
I hope to eventually get these into Ubuntu, once we sort out a few
other issues which will make using a packaged Go installation more
practical.
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter
Ondřej Surý
On 22.2.2011 14:03, Gustavo Niemeyer wrote:
> Hi Jan,
>
>> Easy installation with automated updates of the Go language
>> development environment (compiler/standard tools and Go packages/...)
>> for x86 and x86_64 is now available for Ubuntu in PPA (personal
>
> FWIW, there were packages available already, as announced:
>
> http://groups.google.com/group/golang-nuts/t/a378126d7d061f0e
Sorry I don't follow golang-nuts, so I was not aware of your effort.
There was a long standing ITP (Intent To Package) bug in Debian Bug
Tracker (http://bugs.debian.org/574371) which I took over (and I have
announced it before to the owner of the ITP).
> I hope to eventually get these into Ubuntu, once we sort out a few
> other issues which will make using a packaged Go installation more
> practical.
I agree that the go needs some polishing to support $GOPATH (among other
things - I have filled some issues in the golang tracker along the way[1]).
Please be aware (and really please do not take it personally) that
packages which go to Debian needs to comply with Debian policy, which
imposes at least a minimum level of standards (including the FHS). As
far as I can tell your package is just archive of $GOROOT + /usr/bin/,
which mixes the binary-dependent and binary-independent files into one
huge pile of mess (not to mention that you probably don't want to
include whole source directory including Makefiles, testdata for
archive/tar, etc.). The need to set $GOROOT by hand is also not
necessary - there's $GOROOT_FINAL (which will work after there will be
release with fix for #1527) which could be used to override build time
$GOROOT to something more sensible. So to sum it up, I don't really
think your package is ready for inclusion to Ubuntu (or Debian). Also I
don't think Ubuntu should include the go packages in the releases, since
AFAIK the language is not stable enough yet and you definitely don't
want to have different versions in different Ubuntu releases.
You're of course welcome to join the packaging effort in the Debian. The
package uses git-buildpackage and the git repo is hosted at alioth[2],
so feel free to propose any patch to improve the packaging.
The result is far from perfect and there are some outstanding issues
with godoc (not following the symlink - #1540) and goinstall (#1539).
Ondrej
Links:
1. http://code.google.com/p/go/issues/list?can=1&q=reporter:ondrej,sury.org
2. http://git.debian.org/?p=pkg-google/golang.git;a=summary
--
Ondřej Surý
vedoucí výzkumu/Head of R&D department
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:ondre...@nic.cz http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------
Gustavo Niemeyer
> things - I have filled some issues in the golang tracker along the way[1]).
That's being worked on already.
(...)
> tell your package is just archive of $GOROOT + /usr/bin/, which mixes the
> binary-dependent and binary-independent files into one huge pile of mess
> (not to mention that you probably don't want to include whole source
> directory including Makefiles, testdata for archive/tar, etc.). The need to
My focus is to create a very good Go package for people to develop with,
and then eventually a reasonable Ubuntu package that follows the policy,
so the "pile of mess" is a non-issue at the moment.
I included the source code on purpose, for instance, because godoc
depends on it, and I didn't split out files because Go developers expect
$GOROOT like this.
Eventually, we'll improve both the package and Go's expectations so that
we can get to an agreement and make everyone happy. Meanwhile, please
accept my apologies for breaking some rules.
> it up, I don't really think your package is ready for inclusion to Ubuntu
I've made that very clear in the announcement.
> (or Debian). Also I don't think Ubuntu should include the go packages in
> the releases, since AFAIK the language is not stable enough yet and you
That's not being debated at this point. There's a lot to work on.
> You're of course welcome to join the packaging effort in the Debian. The
I already have enough to deal with for the moment, so I'll have to skip
the offer. I honestly appreciate it, though.
Andrew Gerrand
On 23 February 2011 01:28, Ondřej Surý <ondre...@nic.cz> wrote:
> Please be aware (and really please do not take it personally) that packages
> which go to Debian needs to comply with Debian policy, which imposes at
> least a minimum level of standards (including the FHS). As far as I can
> tell your package is just archive of $GOROOT + /usr/bin/, which mixes the
> binary-dependent and binary-independent files into one huge pile of mess
Please be aware that Gustavo has made (and continues to make) a great
effort to gradually shape the Go build and packaging systems so that
they may be better packaged in the future. His approach is the way it
should be done: get involved with the project and become an evangelist
for the needs of your distribution.
We're very open to being worked with proactively on these issues, but
swinging by to drop a deb, file some bugs, and call our tree a "pile
of mess" borders on insulting.
I'm a Debian user. I want to ensure that Go works well under Debian in
a way that is _consistent_ to other platforms and distributions. I'm
happy to work with you directly on this.
Andrew
Ondřej Surý
On 22.2.2011 22:18, Andrew Gerrand wrote:
> Hi there,
>
> On 23 February 2011 01:28, Ondřej Surý<ondre...@nic.cz> wrote:
>> Please be aware (and really please do not take it personally) that packages
>> which go to Debian needs to comply with Debian policy, which imposes at
>> least a minimum level of standards (including the FHS). As far as I can
>> tell your package is just archive of $GOROOT + /usr/bin/, which mixes the
>> binary-dependent and binary-independent files into one huge pile of mess
>
> Please be aware that Gustavo has made (and continues to make) a great
> effort to gradually shape the Go build and packaging systems so that
> they may be better packaged in the future. His approach is the way it
> should be done: get involved with the project and become an evangelist
> for the needs of your distribution.
Well, there are several already working approaches to packaging. Some
packagers are involved in upstream, some are not, some upstreams are
cooperative, some less. I don't think there's one approach that fits all.
> We're very open to being worked with proactively on these issues, but
> swinging by to drop a deb, file some bugs, and call our tree a "pile
> of mess" borders on insulting.
Andrew, I didn't call your tree a "pile of mess" per se, but it's a mess
when put into a Debian package which installs a mix of binary files
(.a), sources, Makefiles, test files under /usr/lib/go. I am deeply
sorry if my wording had offended you, it was not my intent.
> I'm a Debian user. I want to ensure that Go works well under Debian in
> a way that is _consistent_ to other platforms and distributions. I'm
> happy to work with you directly on this.
Great, I am looking forward to it. I already wrote to the Fedora guy
and will try to have the same structure as much as possible. But still
there are requirements on the Debian (and other distros) part, which
impose several constraints (complying to FHS is an important part of the
policy).
Ondrej
Andrew Gerrand
>> I'm a Debian user. I want to ensure that Go works well under Debian in
>> a way that is _consistent_ to other platforms and distributions. I'm
>> happy to work with you directly on this.
>
> Great, I am looking forward to it. I already wrote to the Fedora guy and
> will try to have the same structure as much as possible. But still there
> are requirements on the Debian (and other distros) part, which impose
> several constraints (complying to FHS is an important part of the policy).
Okay. Well I have subscribed to both your git repo and the ITP bug so
that I can keep track of what you guys are up to. Is there anything
else I should be aware of?
Andrew
Dougx
Florian Weimer
> I included the source code on purpose, for instance, because godoc
> depends on it, and I didn't split out files because Go developers expect
> $GOROOT like this.
I agree that splitting out the source files is probably overkill.
Just because it is source, it is not guaranteed to be
platform-independent, and figuring that out doesn't seem worth the
trouble. We certainly don't do that for Ada and GNAT.
We will probably end up with multiple Go implementations featuring
different ABIs, and then developers need access to the source code
anyway. A scheme similar to emacsen-common and common-lisp-controller
would also allow us to deal rapidly with ABI changes (many library
packages would not need a binary upload, then). Until then,
availability of source code is just convenient.
Ondřej Surý
I'll already have a request from one user to let golang migrate to
Debian testing and I am seriously considering to do so.
Next stable Debian will have freeze somewhere in December 2012 and
that's a plenty of time to decide whether golang should be part of it.
The other argument is that gccgo-4.6 is already in testing.
So my plan for (near) future is:
1. upload next tag: release to Debian unstable and let it migrate to testing
2. keep up with tag: weekly in Debian unstable, but don't let it migrate
to testing. This rule will be broken if there is a tag: release and it
needs to migrate to testing (10-day period).
Otherwise feel free to use the packages, comment (please use the
Reply-To: address) and/or fill bugs using Debian BTS if you feel there's
a bug caused by Debian packaging.
BTW: I built the packages for GNU/KFreeBSD - it needs some hacking, but
it works. I'll wrap-up the patches and contribute them back as a
GOOS=kfreebsd (or if you want to integrate them earlier, you can pick
them from the git repository).
O.
Brad Fitzpatrick
André Moraes
Maybe you could create a package that contains the source and the
Mercurial repository together.
Then write some shell scripts to compile and create some symlinks in
the /usr/local/{lib,bin}
If the user wants to upgrade their Go instalation, they could wait for
a package or simple
hg update release
cd src
./all.bash
I am not a package mantainer, this is just an idea.
--
André Moraes
http://andredevchannel.blogspot.com/
Ondřej Surý
The question is whether the Go will move so quickly also next year,
the next freeze is planned for December 2012.
And the testing is not that bad - you can get a version to testing in
10 days (unless there is a RC bug in the package) and the official
documentation recommends using "release" anyway.
O.
--
Ondřej Surý <ond...@sury.org>
Russ Cox
> the next freeze is planned for December 2012.
Yes but when does that freeze thaw?
I think it's safe to say that if people still want to use
Go in December 2013 the December 2012 release
will be very out of date by then.
Russ
Ondřej Surý
>> The question is whether the Go will move so quickly also next year,
>> the next freeze is planned for December 2012.
>
> Yes but when does that freeze thaw?
With the time-based freezes the stable release would be with us for ~2 years.
Just to name all the options - we have a Debian unstable for people
who wants to live on the edge, Debian testing for people who wants to
have packages which underwent some testing (in unstable) and
debian-backports for people who wants to use stable release and pick
just a few packages to be updated.
And we also have a people who don't want to live on an edge and like
stuff like API and ABI stability during the releases and wants to care
about updating their code only if there is a new distro release.
I think we can make all those groups happy.
> I think it's safe to say that if people still want to use
> Go in December 2013 the December 2012 release
> will be very out of date by then.
I am not strongly pushing have Go in Debian stable, however I feel
that people who use Debian stable are used to cope with "frozen"
versions and they choose to use Debian because of that (the situation
with php5 is almost identical).
Imagine that you wrote a some part of your system in Go and it works
just fine with whatever version is in the Debian stable. You wouldn't
want to have the runtime upgraded on every release tag, because you
don't need to.
But can I ask for something? Can we decide what to do in December 2012
before the freeze happen? The package is not going to enter any stable
Debian release before then, so this is purely academic discussion now.
Also it's not really Debian specific, you'll face same problem with
all distros around the globe.
https://bugzilla.redhat.com/show_bug.cgi?id=652987
(Fedora have quicker release cycles though...)
And more will come (if the Go is successful and I guess you want that).
Ondřej Surý
> As an alternative, to the "years old problem".
>
> Maybe you could create a package that contains the source and the
> Mercurial repository together.
> Then write some shell scripts to compile and create some symlinks in
> the /usr/local/{lib,bin}
>
> If the user wants to upgrade their Go instalation, they could wait for
> a package or simple
>
> hg update release
> cd src
> ./all.bash
package... but I could probably write a little howto on updating a
package to the latest release.
O.
Gustavo Niemeyer
> all distros around the globe.
Not with Ubuntu. There are new packages every week, and there are
plans to push stable releases of Go into the stable distribution, even
after released.
Ondřej Surý
>> Also it's not really Debian specific, you'll face same problem with
>> all distros around the globe.
>
> Not with Ubuntu. There are new packages every week, and there are
> plans to push stable releases of Go into the stable distribution, even
> after released.
Well, show me the blueprint, that would be a big precedence to break
Ubuntu SRU rules[1]. (Which I very much doubt, but you work for
Canonical, I don't...)
(Unless we are talking about PPAs and/or Ubuntu Backports[2]...which
is situation not much different from Debian has with
unstable/testing/backports.)
O.
1. https://wiki.ubuntu.com/StableReleaseUpdates
2. https://help.ubuntu.com/community/UbuntuBackports
--
Ondřej Surý <ond...@sury.org>
Gustavo Niemeyer
> Ubuntu SRU rules[1]. (Which I very much doubt, but you work for
> Canonical, I don't...)
You don't have to work for Canonical to read the document that you've
pointed to:
https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
Namegduf
Gustavo Niemeyer <gus...@niemeyer.net> wrote:
> > Well, show me the blueprint, that would be a big precedence to break
> > Ubuntu SRU rules[1]. (Which I very much doubt, but you work for
> > Canonical, I don't...)
>
> You don't have to work for Canonical to read the document that you've
> pointed to:
>
> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
>
Would breaking old code be considered a "regression"?
Go tends to do that without much worry.
Gustavo Niemeyer
>
> Go tends to do that without much worry.
Ultimately, it'll be up to the board, and as you can see in the list
in there and in links to conversations about those decisions, it's
very much dependent on the reasoning behind each case.
I've started conversations with some of the members, and given that
there are zero dependent packages right now using Go, and that
compiled Go programs don't depend much on the compiler, there's some
favorable feeling to allowing an SRU exception as a regression
wouldn't really have any significant impact.
It hasn't yet been submitted to the board yet, though, so for now it's
still just a plan.
Ondřej Surý
> > Would breaking old code be considered a "regression"?
>
> > Go tends to do that without much worry.
>
> Ultimately, it'll be up to the board, and as you can see in the list
> in there and in links to conversations about those decisions, it's
> very much dependent on the reasoning behind each case.
>
> I've started conversations with some of the members, and given that
> there are zero dependent packages right now using Go, and that
> compiled Go programs don't depend much on the compiler, there's some
> favorable feeling to allowing an SRU exception as a regression
> wouldn't really have any significant impact.
>
> It hasn't yet been submitted to the board yet, though, so for now it's
> still just a plan.
that. The MinorReleaseExceptions are for minor releases, aka going
from firefox 3.6.1 to 3.62, but not for from firefox 3.6 to 4. And I
don't think the golang project had drawn the line here, f.e. just from
reading the changelog, the r57 broke backwards compatibility (and
don't get me wrong, it's nothing bad in that at this point).
But let's leave it at the fact that the world is full of surprises,
and we'll see what the final decision of the Technical Board will be
after you submit the request.
Generally I think the golang project will have to make a decision
(sooner or later - probably much later) - either the project want
golang to be included in Linux distros with stable release cycles
(which include all the major ones) and provide the packagers at least
some support and help, or not which would be pity because the target
audience would be much smaller.
I don't even think that it's right time to make that decision, but my
view is that if you want to have any impact and more users in a long
term the Go will have to start doing major.minor releases and break
compatibility only in major releases (compare to python, ruby,
etc...).
On not so unrelated note I suggest the we bury the hatchet and sync
the packaging efforts. golang will be pulled automatically to the
oneiric and it just doesn't make sense to have two diverting
approaches in packaging.
O.
Gustavo Niemeyer
> that. The MinorReleaseExceptions are for minor releases, aka going
> from firefox 3.6.1 to 3.62, but not for from firefox 3.6 to 4. And I
If you don't mind, I'll reserve my energy on that debate for the on
going conversation with the board members.
> Generally I think the golang project will have to make a decision
> (sooner or later - probably much later) - either the project want
> golang to be included in Linux distros with stable release cycles
The language will eventually have stable API releases for sure. They
don't exist yet, though, and I don't think it's the task of a Linux
distribution to enforce the decision of when this should happen.
As a Go developer, I'm fascinated by the speed of development of the
language. The API is being broken so often because there are real
improvements being made on a very fast pace. I personally don't want
Ubuntu, or any other distribution for that matter, to be the reason
why that stops.
> On not so unrelated note I suggest the we bury the hatchet and sync
> the packaging efforts.
It sounds good for sure. How do you suggest we do that?
There is a PPA available with new packages shortly after every release
of Go (stable and weekly).
> golang will be pulled automatically to the
> oneiric and it just doesn't make sense to have two diverting
> approaches in packaging.
As we've debated before, there's on going effort towards creating a
good environment for Go developers in Ubuntu. The Debian packages
will not necessarily get pulled automatically.
Ondřej Surý
>> Generally I think the golang project will have to make a decision
>> (sooner or later - probably much later) - either the project want
>> golang to be included in Linux distros with stable release cycles
>
> The language will eventually have stable API releases for sure. They
> don't exist yet, though, and I don't think it's the task of a Linux
> distribution to enforce the decision of when this should happen.
Nor do I, but the danger is there.
> As a Go developer, I'm fascinated by the speed of development of the
> language. The API is being broken so often because there are real
> improvements being made on a very fast pace. I personally don't want
> Ubuntu, or any other distribution for that matter, to be the reason
> why that stops.
And I am not suggesting that.
>> On not so unrelated note I suggest the we bury the hatchet and sync
>> the packaging efforts.
>
> It sounds good for sure. How do you suggest we do that?
The current Debian packaging is kept in git:
http://git.debian.org/?p=pkg-google/golang.git;a=summary
Could you please look at it and list things that are showstopper for
you? I think the packages are in quite good shape, lintian-clean,
adhering to policy, etc... and the upload sitting in the NEW queue
has even more goodies (vim and kate syntax, etc.)
I have tried to look at your changes you did when packaging your
golang-weekly, but failed. Could you please separate upstream and
patches? I am quite interested in getting goinstall $HOME installs and
gorun support into Debian packages.
> There is a PPA available with new packages shortly after every release
> of Go (stable and weekly).
We could keep that... I don't really think there's (should be)
anything really Ubuntu specific, so we can keep one master (called
debian-sid) and do automatic force-uploads to Ubuntu PPA.
So I suggest as a starter you look at 1:57-1 Debian release (in NEW
queue and in GIT) and go from there.
>> golang will be pulled automatically to the
>> oneiric and it just doesn't make sense to have two diverting
>> approaches in packaging.
>
> As we've debated before, there's on going effort towards creating a
> good environment for Go developers in Ubuntu. The Debian packages
> will not necessarily get pulled automatically.
I thought it is automatic process when the development cycle start.
But maybe I am wrong.
I know that this will impose a change of packaging paradigma you have
(using git-buildpackage, lintian, etc.), but please try. I am willing
to provide a packaging support for the things you want to accomplish
and you can bring more goodies from upstream.
Gustavo Niemeyer
> you? I think the packages are in quite good shape, lintian-clean,
+ fmt.Fprintf(os.Stderr, "WARNING: Usage of goinstall is highly
discouraged on Debian system.
This is a blocker, for instance. goinstall is a critical part of Go,
and shouldn't be discouraged.
+ installDeps = flag.Bool("d", false, "install package
prerequisites")
And then you've disabled the ability of installing dependencies by default?
> I have tried to look at your changes you did when packaging your
> golang-weekly, but failed. Could you please separate upstream and
> patches?
Yeah, sorry about that. I'll eventually separate them, but for now
it's easier to handle them this way due to my own workflow. Patches
which go into the package are generally being worked at the same time
to go upstream.
> I am quite interested in getting goinstall $HOME installs and
> gorun support into Debian packages.
You can get gorun at launchpad.net/gorun. $HOME support is being
worked upstream.
> We could keep that... I don't really think there's (should be)
> anything really Ubuntu specific, so we can keep one master (called
> debian-sid) and do automatic force-uploads to Ubuntu PPA.
There's nothing Ubuntu specific indeed, but I appreciate working with
Launchpad PPAs, and also appreciate working on the packages at the
same time I work on the changes upstream. If we are to integrate the
packages, we'll have to create a way for both of us to push changes
into the package on a very timely basis, and will have to keep up with
weekly and stable releases.
> I know that this will impose a change of packaging paradigma you have
> (using git-buildpackage, lintian, etc.), but please try. I am willing
> to provide a packaging support for the things you want to accomplish
> and you can bring more goodies from upstream.
Sounds good. I'm certainly willing to try to integrate the effort,
but we'll have to figure some of those details out.
Ondřej Surý
>> Could you please look at it and list things that are showstopper for
>> you? I think the packages are in quite good shape, lintian-clean,
>
> + fmt.Fprintf(os.Stderr, "WARNING: Usage of goinstall is highly
> discouraged on Debian system.
>
> This is a blocker, for instance. goinstall is a critical part of Go,
> and shouldn't be discouraged.
Well, this will go away, but I hadn't have time to check the new
feature of goinstall to install to home.
> + installDeps = flag.Bool("d", false, "install package
> prerequisites")
>
> And then you've disabled the ability of installing dependencies by default?
Enabling this by default was overwriting package files (trying to
recompile everything every time). This could probably go away together
with goinstall installing to $HOME for users and to /usr/local/lib/go
for root.
> If we are to integrate the packages, we'll have to create a way for both of us to push changes into the package on a very timely basis, and will have to keep up with weekly and stable releases.
After we agree on the workflow I could give you write access to git
repository (well, or you could just clone and send pull requests, but
I don't want you to feel as a second class citizen...).
I have made spin-off for google-weekly-* packages in the git and will
be pushing the changes to weekly-debian-sid and weekly-upstream-sid
shortly.
So to sum up:
release:
Source package: golang
Binary packages: golang-*
Git Debian branch: debian-sid
Git Upstream branch: upstream-sid (make -f debian/rules get-orig-source)
weekly
Source package: golang-weekly
Binary packages: golang-weekly-*
Git Debian branch: weekly-debian-sid
Git Upstream branch: weekly-upstream-sid (make -f debian/rules get-orig-source)
Gustavo Niemeyer
> feature of goinstall to install to home.
> Enabling this by default was overwriting package files (trying to
> recompile everything every time). This could probably go away together
Sounds good, I can fix both problems.
> After we agree on the workflow I could give you write access to git
> repository (well, or you could just clone and send pull requests, but
> I don't want you to feel as a second class citizen...).
Sounds good as well. Let's push that forward then.
Ondřej Surý
On Wed, May 4, 2011 at 16:37, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
>> Well, this will go away, but I hadn't have time to check the new
>> feature of goinstall to install to home.
> (...)
>> Enabling this by default was overwriting package files (trying to
>> recompile everything every time). This could probably go away together
>
> Sounds good, I can fix both problems.
>
>> After we agree on the workflow I could give you write access to git
>> repository (well, or you could just clone and send pull requests, but
>> I don't want you to feel as a second class citizen...).
>
> Sounds good as well. Let's push that forward then.
Have you did any progress on merging the two branches, so we don't
diverge too much?
It's still hard for me to pickup any changes you did to the packages
(vs upstream), since you don't use .orig.tar.gz + debian.tar.gz format
and also your source package contains some generated files.
However I have isolated your changes down to three patches:
1) Small changes to goinstall to not use logfile by default and print
a message about setting $GOPATH
2) skipNetTest in syslog test (cherry picked from weekly)
3) version.bash support for non-hg environment
Is this correct?
Ad 1) I have merged your patch, but made slight modifications to it (I
am changing the logfile to defaultRoot/goinstall.log instead of
disabling it)
Ad 2) I can merge this to 57.1 package, but is it neccessary?
Ad 3) I don't have version.bash in my Debian packages, so no pull here
Anything else which needs merging?
Gustavo Niemeyer
>
> Have you did any progress on merging the two branches, so we don't
> diverge too much?
You never got in touch with further details about access to the
repository, and I ended up not pursuing it further either.
> It's still hard for me to pickup any changes you did to the packages
> (vs upstream), since you don't use .orig.tar.gz + debian.tar.gz format
> and also your source package contains some generated files.
Sorry about that. It's still more practical for me to package this
way because the fixes are generally on their way upstream and I use
the same source control for both the package and the upstream changes.
> Is this correct?
Yes, it was.
> Ad 1) I have merged your patch, but made slight modifications to it (I
> am changing the logfile to defaultRoot/goinstall.log instead of
> disabling it)
Cool.. I have to take some time to integrate that upstream in a good way.
> Ad 2) I can merge this to 57.1 package, but is it neccessary?
No, it has been committed upstream.
> Ad 3) I don't have version.bash in my Debian packages, so no pull here
Is the compiler suite shipping with correct versioning information?
> Anything else which needs merging?
gorun, perhaps? I'll also submit it for inclusion once I get a moment.
Kevin Beckford
Ondřej Surý
>>> Sounds good as well. Let's push that forward then.
>>
>> Have you did any progress on merging the two branches, so we don't
>> diverge too much?
>
> You never got in touch with further details about access to the
> repository, and I ended up not pursuing it further either.
Golang is currently maintainer under pkg-google group (although new
group can be created quite easily):
http://alioth.debian.org/projects/pkg-google/
The git repository resides at:
http://git.debian.org/?p=pkg-google/golang.git
There are links for anonymous access at the top of the page.
You should be interested in debian-sid (contains releases) and
weekly-debian-sid (contains weekly) branches. I keep them in same
repository for easy cherry-picking and merging the changes common to
both branches.
For a write access to the repository, you need to have alioth account,
then request for pkg-google membership (and say something about golang
and myself).
Gustavo Niemeyer
Thanks. I'll keep pushing the Ubuntu packages and sending changes
upstream for the time being.
Ondřej Surý
>> There are links for anonymous access at the top of the page.
>
> Thanks. I'll keep pushing the Ubuntu packages and sending changes
> upstream for the time being.
Hmm, I just wanted to make sure that I did everything I could and the
ball is not on my side.
Unfortunately it's very hard to cherry-pick changes from your
repository since it's a mix of upstream and Ubuntu packaging. So I'll
have to just stick to tag:release and tag:weekly releases.
My offer to cooperate on golang packaging so both Debian and Ubuntu
can profit from the effort is still valid in the case you want to
cooperate in the future...
Gustavo Niemeyer
> can profit from the effort is still valid in the case you want to
> cooperate in the future...
I'd be very happy to collaborate as well. Here are the packages:
https://launchpad.net/~gophers/+archive/go
You can send patches using Bazaar, or simply opening a bug and
attaching specific patches there to the golang project in Launchpad.
Whatever works best for you.