Re: [gentoo-dev] Re: mbox -- looks sort of interesting
Aleksandr 2014-02-14 13:50 GMT+06:00 Greg Turner g...@malth.us: Holy crap, that looks awesome! How does one pronounce your name, Александр? On Thu, Feb 13, 2014 at 11:28 PM, Александр Берсенев b...@hackerdom.ru wrote: Ok, I'll work on it. 2014-02-13 23:00 GMT+06:00 Rich Freeman ri...@gentoo.org: On Thu, Feb 13, 2014 at 11:07 AM, Brian Dolbec dol...@gentoo.org wrote: Yes, if you can please work on updating it. Please contact us on the gentoo-portage-dev mail list or irc #gentoo-portage for changes to portage that will help keep it working in the future. I started development of a public_api branch long ago just for having a stable API for apps to use. Perhaps some of what you need can be integrated there. Seems like a valuable tool. It would be best if it could either use portage APIs where available, or if effort could be directed at incorporating the necessary features into portage or its APIs so that you're not stuck maintaining a fork. I'm sure the portage team will help where they can. Rich
Re: [gentoo-dev] dev-lang/go
On Thu, 13 Feb 2014 11:59:16 -0600
William Hubbs willi...@gentoo.org wrote:
Hi all,
I responded to this a while back, but I guess my email didn't go out
for some reason.
As the primary go maintainer, I do want to be involved in this. :-)
On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
On Mon, 30 Dec 2013 15:48:17 -0500
Emery Hemingway em...@vfemail.net wrote:
I really like working with Go, and would like to see a means of
merging Go packages with Portage. In short I am asking if anyone
else is interested in a Go project.
I might be. I have packaged something for private use but it just a
bunch of hacks. Anyway, I have some production go code.
For those who aren't familiar with Go, I will sumarise why
Portage and Go do not play well together.
Go is static linked by default.
The Go compiler creates static libraries and binaries. Libraries
compilied with different versions of Go (1.1/1.2) may not be
linked into the same binary.
Haskell is staticaly linked as well (by default) and you can see the
gentoo haskell project. I don't see this as a problem, we just will
have all dependencies in DEPEND and will have to scope on the go
compiler version under something like /usr/lib/go-1.{1,2}/...
That could be done easily enough, but what about the tools in /usr/bin
(there aren't many, but there are a couple), and these do not change
name with each version of go.
Please see what python does for different python versions (which you
omitted from my previous email).
Go libraries are usually unversioned.
Libraries outside the system library are resolved with an import
statement that specifies a source code repository, such as a git
or mecurial repository. Most often Go libraries are installed
using the 'go get' tool that clones a repository, and simply
assumes HEAD/tip is the best revision to build against. There is
some support for using git tags but it is not well documented.
Often these libraries are very small for the sake of reuse and to
keep APIs simple.
My understanding is that a library repo will have branches based on
the version of go, so for example, it might have a branch called go-1
which will be where go get will look to find the latest version of
the code that works with go-1.x.
In this case we just have to require upstream to make releases or
publish either live ebuilds, or ebuilds versioned something like
0_pre-MM-DD.ebuild [1]
I don't think we are going to be able to require upstream to make
releases, so that leaves us with:
1) using live ebuilds, which will never be allowed to have keywords by
gentoo policy, or
2) publishing snapshots, which also means we have to create tarballs
to match them. This will be a lot of work for us as maintainers.
Also, the only way we will know when a new version of the library
is released is to closely monitor the upstream git repository.
As I said in previous email, I think at least part of go community sees
this as an issue and this is something we can not solve right now but
rather need to work on this on case-by-case basis.
Some upstreams may be willing to do releases / follow semver.org or
something like that. But there will also be upstream which won't and
that's fine, we should be able to handle both cases.
Anyway, asking the upstream to do a release is simple enough and you
won't know until you ask.
The other concern, which I believe zero was talking about is, once a
library is installed in GOPATH, I don't think the go build system
rebuilds it. In other words, go get will see that it is already
there and I don't think it goes back out to the net to check for any
changes.
I think when doing a `go build` it will check if newer version is
available and print a warning.
William
--
Jan Matějka| Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH] mysql-cmake.eclass respect flags wrt #497532
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
https://bugs.gentoo.org/show_bug.cgi?id=497532
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJS/in3AAoJEFpvPKfnPDWzEMIH/2SKfnSBDkl5k5ReodLf4iGF
tx7kGjKgmgAbpkJLxsbL+4oZrwo7mbbU8tb0tghuk6JJDzuMqUD19ynSw2fB6WyU
QBRkht3v7knN6M0AB447B9ca5skgV6Ylr8yJvS1EDJluwr76WzlO7mxHFy1APcGC
ZMcVJfn0/DyiNIW8NtgMU7VLvxoIG2uZoJ7fHJPAImyLajNdfIwsKsN9qt4WpMmX
WR16Xw3WpVryPwIQsXRUw5yLo80rxOuTB09s9ZFk5f/tBU2H5eU5HLRuKWmkS32B
R6+UH3ooc/pJkA5yg6KCgrUODHvFVdAuw29QHIZzBXqWMylb4EVPgSK5II77M9o=
=qoS7
-END PGP SIGNATURE-
--- eclass/mysql-cmake.eclass
+++ eclass/mysql-cmake.eclass
@@ -239,6 +239,8 @@
CMAKE_BUILD_TYPE=RelWithDebInfo
mycmakeargs=(
+ -DCMAKE_C_FLAGS_RELWITHDEBINFO=$(usex debug -DNDEBUG)
+ -DCMAKE_CXX_FLAGS_RELWITHDEBINFO=$(usex debug -DNDEBUG)
-DCMAKE_INSTALL_PREFIX=${EPREFIX}/usr
-DMYSQL_DATADIR=${EPREFIX}/var/lib/mysql
-DSYSCONFDIR=${EPREFIX}/etc/mysql
[gentoo-dev] Re: [PATCH] mysql-cmake.eclass respect flags wrt #497532
On 02/15/2014 01:36 AM, hasufell wrote: https://bugs.gentoo.org/show_bug.cgi?id=497532 Is there a good reason to set CMAKE_BUILD_TYPE=RelWithDebInfo at all? Changing the build type is not generally recommended, and may cause other flags to be set automatically. If you are using the default build type, adding debug to IUSE will cause cmake-utils to automagically handle it.
Re: [gentoo-dev] Re: [PATCH] mysql-cmake.eclass respect flags wrt #497532
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/14/2014 04:06 PM, Michael Palimaka wrote: On 02/15/2014 01:36 AM, hasufell wrote: https://bugs.gentoo.org/show_bug.cgi?id=497532 Is there a good reason to set CMAKE_BUILD_TYPE=RelWithDebInfo at all? Changing the build type is not generally recommended, and may cause other flags to be set automatically. I have no idea. File a bug for the eclass if you like, I am not the author. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS/jQhAAoJEFpvPKfnPDWzHq8H/0Wp9Gz8b6rAB5MUdYuG8wB2 JjQaqrnWCvUSl002jBZZEtGd0JcGaAfuoq3UxmFDjx4xHbESZL0PPiR3VLa8z/sX Z/2tgG/IyWsxA8Go0A7pJ0qKX7XG5TAJYh10JU7uc35hv9jHaou6Grd1zaFu0To+ J5hkFQyJF+vnR3SAAPyDvM269sHENZu7dSBPo5rTYxdTxR5wnjLfVPu0rADR9k0S KkLeePwsPbSN7pZg8vW46NUMsPJ+oUWfKDPp/TYxIxOx3AT15Q/AcdmUlyRGkwXE QCBo/gsU0NJzXSJbpzRNVZYpSjL+jZUuDaT36lOh87zqCCHMBi6kLnRGQx7KR+c= =QIUy -END PGP SIGNATURE-
Re: [gentoo-dev] dev-lang/go
On Fri, 14 Feb 2014 13:30:10 +0100
Jan Matejka y...@gentoo.org wrote:
On Thu, 13 Feb 2014 11:59:16 -0600
William Hubbs willi...@gentoo.org wrote:
Hi all,
I responded to this a while back, but I guess my email didn't go out
for some reason.
As the primary go maintainer, I do want to be involved in this. :-)
On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
On Mon, 30 Dec 2013 15:48:17 -0500
Emery Hemingway em...@vfemail.net wrote:
I really like working with Go, and would like to see a means of
merging Go packages with Portage. In short I am asking if anyone
else is interested in a Go project.
I might be. I have packaged something for private use but it just
a bunch of hacks. Anyway, I have some production go code.
For those who aren't familiar with Go, I will sumarise why
Portage and Go do not play well together.
Go is static linked by default.
The Go compiler creates static libraries and binaries. Libraries
compilied with different versions of Go (1.1/1.2) may not be
linked into the same binary.
Haskell is staticaly linked as well (by default) and you can see
the gentoo haskell project. I don't see this as a problem, we
just will have all dependencies in DEPEND and will have to scope
on the go compiler version under something
like /usr/lib/go-1.{1,2}/...
That could be done easily enough, but what about the tools
in /usr/bin (there aren't many, but there are a couple), and these
do not change name with each version of go.
Please see what python does for different python versions (which you
omitted from my previous email).
I've modified the go-1.2 ebuild to install to usr/lib/go1.2 and I'm
working on an eselect module to manage the symlink to usr/bin/[go,gofmt]
The default GOROOT that go looks at for base libraries seems to be
compiled in so this should be pretty easy, like python but simplier.
An eclass could look at a GO_MINIMUM variable and install for each
version go that is present and matches. Dropping old versions of go
will be easy because linking wont break, and new releases should be
forwards compatible. Maybe 3rd party library sources could be stored in
a version agnostic directory and symlinked in to usr/lib/goX.X/gentoo
to deduplicate the files?
Go libraries are usually unversioned.
Libraries outside the system library are resolved with an import
statement that specifies a source code repository, such as a git
or mecurial repository. Most often Go libraries are installed
using the 'go get' tool that clones a repository, and simply
assumes HEAD/tip is the best revision to build against. There is
some support for using git tags but it is not well documented.
Often these libraries are very small for the sake of reuse and
to keep APIs simple.
My understanding is that a library repo will have branches based on
the version of go, so for example, it might have a branch called
go-1 which will be where go get will look to find the latest
version of the code that works with go-1.x.
In this case we just have to require upstream to make releases or
publish either live ebuilds, or ebuilds versioned something like
0_pre-MM-DD.ebuild [1]
I don't think we are going to be able to require upstream to make
releases, so that leaves us with:
1) using live ebuilds, which will never be allowed to have keywords
by gentoo policy, or
2) publishing snapshots, which also means we have to create tarballs
to match them. This will be a lot of work for us as maintainers.
Also, the only way we will know when a new version of the library
is released is to closely monitor the upstream git repository.
As I said in previous email, I think at least part of go community
sees this as an issue and this is something we can not solve right
now but rather need to work on this on case-by-case basis.
Some upstreams may be willing to do releases / follow semver.org or
something like that. But there will also be upstream which won't and
that's fine, we should be able to handle both cases.
Anyway, asking the upstream to do a release is simple enough and you
won't know until you ask.
The other concern, which I believe zero was talking about is, once a
library is installed in GOPATH, I don't think the go build system
rebuilds it. In other words, go get will see that it is already
there and I don't think it goes back out to the net to check for any
changes.
I think when doing a `go build` it will check if newer version is
available and print a warning.
We may have to make some sort of utitilty to parse sources and check
for updates, and roll tarballs to mirror.
William
--
Jan Matějka| Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B
Re: [gentoo-dev] Re: Re: Re: dropping redundant stable keywords
On Thu, 13 Feb 2014 21:28:18 + Steven J. Long sl...@rathaus.eclipse.co.uk wrote: Much better for the arch in question to field the bug, than tell the user there is no problem, and we don't care. That way you can get the user involved in stabilisation and AT via that bug, instead of turning them away with priggishness. Problems should be visible instead of hidden, as well as resolved. A move in work means a move in work, further implications are yours... Very gnomic: nothing's being hidden in the above approach. Filing a bug but not telling the user about it is hiding the problem. I can't make sense of the rest so I'll move on, noting only that it's up to the arch team, as to what _they_ decide to kick back to unstable. They need manpower to decide it, which they don't have. And that can work without a problem if we have a mechanism in place to relieve maintainers of those bugs. Such mechanism could be to assign those bug to the arch team, this idea came up at FOSDEM; it won't solve the lack of manpower, but it will at least relieve the maintainers and make the problem more visible. Personally I'd do it after 45 days to speed things up, and let the ATs concerned, take the bug as and when (eg turn the stabilisation into a tracker for the slow archs concerned, if there are multiple.) Since this is a soft measure I've seen a lot of people want the time to be longer; if it still continues to be a problem, then shortening it might be a solution but I think we'll want to avoid a too hard approach for now. 45 days are over before you know it... The part about ATs taking the bug sounds like what came up at FOSDEM. +1 The arguments and headaches at the user, bug and AT sides are causing more work (or detracting from real work) too. Yes, the less work that we can do, the more work the user has to do as a natural consequence; discussions like these are there to prevent those headaches way in advance, as we can proper adapt and/or respond to the situation. And if needed, bring out news such that the user is well informed. Not sure which argumentation this is about though. Perfectly simple: instead of having this row repeatedly, or borking archs, let's use the solution proposed by the ARM AT: provide a technical reason why it won't work, rather than a conceptual problem with the hack. Searching for such technical reasoning is a leeway for hacking hoping. Er what? Solutions were provided, a policy has been made; we are exactly avoiding to row repeatedly, and this is yet another solution I propose: Provide a technical reason why it will work? Kinda sums up your discussion for me. And your answer to tell us what it breaks is tell us why it works? Pfft. We are searching for solutions that work. You further demonstrate this solution that I propose we should use: The history of computing is littered with hacks that turned out to shed new light on a problem: it's called exploring the problem domain. It's only when you have idiomatic knowledge of the language/tools *and* the specific domain, that you can envision oddball solutions and more importantly _know_ that they will work (perhaps with a bit of tweaking.) It is called prototyping. That's just another word: exploring the problem domain is much more useful to keep in mind. We already know the problem, thus it is rather just called prototyping. Further, the solution steev brought up is much much better than simply dropping the ebuild. snip The -* keyword is special. It is used to indicate package versions which are not worth trying to test on unlisted archs. [1] Finally: some actual content. It works. You can keep rehashing about winning, but all it does is break policy. *sigh* The wonderful thing about policy is that it reflects (or is supposed to) consensus opinion with light to contemporaneous circumstance. Since circumstances change, so too must policy be open to change or adaptation, in line with basic principles. In this case -* works fine for what it intends to work; changing the policy to redefine it to fit another purpose, while no longer reflecting its original purpose is what we should avoid at all cost. So let's look at extending it, since there is *no* technical problem: You have colons after the above quoted sentence with nothing after it. (An eye for an eye... :D) 'The redundant -* keyword is a metadata marker. The keyword has a meaning, therefore it is not redundant. It is used to indicate, in line with the semantic of strip all, that the ebuild in question can only be used for the specific archs noted for one of two reasons: 1) The package-maintainer has stabilised a newer version on at least one arch personally, the ATs for the archs listed have taken longer than XX days to test and stabilise, and the maintainer would otherwise drop the ebuild
Re: [gentoo-dev] dev-lang/go
On Fri, Feb 14, 2014 at 11:02:49AM -0500, Emery Hemingway wrote:
On Fri, 14 Feb 2014 13:30:10 +0100
Jan Matejka y...@gentoo.org wrote:
On Thu, 13 Feb 2014 11:59:16 -0600
William Hubbs willi...@gentoo.org wrote:
Hi all,
I responded to this a while back, but I guess my email didn't go out
for some reason.
As the primary go maintainer, I do want to be involved in this. :-)
On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
On Mon, 30 Dec 2013 15:48:17 -0500
Emery Hemingway em...@vfemail.net wrote:
I really like working with Go, and would like to see a means of
merging Go packages with Portage. In short I am asking if anyone
else is interested in a Go project.
I might be. I have packaged something for private use but it just
a bunch of hacks. Anyway, I have some production go code.
For those who aren't familiar with Go, I will sumarise why
Portage and Go do not play well together.
Go is static linked by default.
The Go compiler creates static libraries and binaries. Libraries
compilied with different versions of Go (1.1/1.2) may not be
linked into the same binary.
Haskell is staticaly linked as well (by default) and you can see
the gentoo haskell project. I don't see this as a problem, we
just will have all dependencies in DEPEND and will have to scope
on the go compiler version under something
like /usr/lib/go-1.{1,2}/...
That could be done easily enough, but what about the tools
in /usr/bin (there aren't many, but there are a couple), and these
do not change name with each version of go.
Please see what python does for different python versions (which you
omitted from my previous email).
I omitted it, because thinking about it, we don't need to worry about
this. There isn't a reason you would want go 1.1 and go 1.2 on your
system. Source level compatibility is guaranteed for all go1 programs
[1].
I've modified the go-1.2 ebuild to install to usr/lib/go1.2 and I'm
working on an eselect module to manage the symlink to usr/bin/[go,gofmt]
I would just install to /usr/lib/go1 and not worry about the eselect
module; there should not be a need to keep several versions of go1
around, again, because go1.x releases will be source compatible.
We could even just leave this as /usr/lib/go, because upstream doesn't
even know if a go-2 specification will happen.
The default GOROOT that go looks at for base libraries seems to be
compiled in so this should be pretty easy, like python but simplier.
It looks for standard libraries in GOROOT_FINAL which is set in the
ebuild and compiled into the binaries.
Third party libraries are interesting in this case, because, all of the
third party libraries we install will not be usable once the user
upgrades from say go-1.2 to go-1.3. However, rebuilding those libraries
from source will work.
William
[1] http://golang.org/doc/go1compat
signature.asc
Description: Digital signature
Re: [gentoo-dev] dev-lang/go
On Fri, 14 Feb 2014 11:02:49 -0500
Emery Hemingway em...@vfemail.net wrote:
On Fri, 14 Feb 2014 13:30:10 +0100
Jan Matejka y...@gentoo.org wrote:
On Thu, 13 Feb 2014 11:59:16 -0600
William Hubbs willi...@gentoo.org wrote:
Hi all,
I responded to this a while back, but I guess my email didn't go
out for some reason.
As the primary go maintainer, I do want to be involved in
this. :-)
On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
On Mon, 30 Dec 2013 15:48:17 -0500
Emery Hemingway em...@vfemail.net wrote:
I really like working with Go, and would like to see a means
of merging Go packages with Portage. In short I am asking if
anyone else is interested in a Go project.
I might be. I have packaged something for private use but it
just a bunch of hacks. Anyway, I have some production go code.
For those who aren't familiar with Go, I will sumarise why
Portage and Go do not play well together.
Go is static linked by default.
The Go compiler creates static libraries and binaries.
Libraries compilied with different versions of Go (1.1/1.2)
may not be linked into the same binary.
Haskell is staticaly linked as well (by default) and you can see
the gentoo haskell project. I don't see this as a problem, we
just will have all dependencies in DEPEND and will have to scope
on the go compiler version under something
like /usr/lib/go-1.{1,2}/...
That could be done easily enough, but what about the tools
in /usr/bin (there aren't many, but there are a couple), and these
do not change name with each version of go.
Please see what python does for different python versions (which you
omitted from my previous email).
I've modified the go-1.2 ebuild to install to usr/lib/go1.2 and I'm
working on an eselect module to manage the symlink to
usr/bin/[go,gofmt]
The default GOROOT that go looks at for base libraries seems to be
compiled in so this should be pretty easy, like python but simplier.
I'm not sure what you are trying to solve here. Afaik GOROOT is used to
determine where to install and it can be overriden from env.
An eclass could look at a GO_MINIMUM variable and install for each
version go that is present and matches.
It might be good idea to learn from others who'd been through this and
I think the new python eclasses are good ones, going with something
like PYTHON_TARGETS array (GOLANG_TARGETS ?)
Dropping old versions of go
will be easy because linking wont break, and new releases should be
forwards compatible.
So far yes I think but I guess that may be quite different with in the
future with 1.x, and should be so there may be corner cases where the
user does need to use earlier version.
Maybe 3rd party library sources could be stored
in a version agnostic directory and symlinked in to
usr/lib/goX.X/gentoo to deduplicate the files?
I'm not sure this is a good idea either. Disk space is cheap and
doing this would only require adding special case handling code which
would get even more complicated when doing upgrades or the situation
changes (eg. main golang version).
Also keep in mind, the main golang version should not be just 1.1 but
rather go1.1 as you may also want to choose gccsomething.
Go libraries are usually unversioned.
Libraries outside the system library are resolved with an
import statement that specifies a source code repository,
such as a git or mecurial repository. Most often Go libraries
are installed using the 'go get' tool that clones a
repository, and simply assumes HEAD/tip is the best revision
to build against. There is some support for using git tags
but it is not well documented. Often these libraries are very
small for the sake of reuse and to keep APIs simple.
My understanding is that a library repo will have branches based
on the version of go, so for example, it might have a branch
called go-1 which will be where go get will look to find the
latest version of the code that works with go-1.x.
In this case we just have to require upstream to make releases
or publish either live ebuilds, or ebuilds versioned something
like 0_pre-MM-DD.ebuild [1]
I don't think we are going to be able to require upstream to make
releases, so that leaves us with:
1) using live ebuilds, which will never be allowed to have
keywords by gentoo policy, or
2) publishing snapshots, which also means we have to create
tarballs to match them. This will be a lot of work for us as
maintainers. Also, the only way we will know when a new version
of the library is released is to closely monitor the upstream git
repository.
As I said in previous email, I think at least part of go community
sees this as an issue and this is something we can not solve right
now but rather need to work on this on case-by-case
Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)
On Fri, 14 Feb 2014 19:59:58 +0100 Tom Wijsman tom...@gentoo.org wrote: And that can work without a problem if we have a mechanism in place to relieve maintainers of those bugs. Such mechanism could be to assign those bug to the arch team, this idea came up at FOSDEM; it won't solve the lack of manpower, but it will at least relieve the maintainers and make the problem more visible. Assigning bugs so arch teams is cosmetic at best. Also note that it used to be that way long ago, and it didn't do any good for anyone involved. It really doesn't matter who is assigned a bug report, as long as it's not a (theoretically) transiently involved party like an arch team on a stabilisation bug. Recently I've seen a few keywording/stabilisation bug reports assigned to arch teams again. It's really annoying. If you've started doing this, then please stop before people start to think it's a good idea. It's not. jer
Re: [gentoo-portage-dev] [PATCH] Implement --newrepo flag.
Am 14.02.2014 21:43, schrieb David James: Uploaded here: https://chromium-review.googlesource.com/#/c/186651/ You should be able to cherry-pick using this command: git fetch https://chromium.googlesource.com/chromiumos/third_party/portage_tool refs/changes/51/186651/1 git cherry-pick FETCH_HEAD The patch has conflicts in depgraph.py. I haven't added automated tests yet. Cheers, David
