Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Sat, 29 Mar 2014 09:39:06 +1300 Kent Fredric kentfred...@gmail.com wrote: On 25 March 2014 03:55, Damien Levac damien.le...@gmail.com wrote: A lot of people already replied to this question: package search. A trivial example, a user want to know all terminals available in portage. Of course he could try a `emerge --searchdesc terminal`, but then he would get anything mentioning terminal in the description: which would probably include a lot of terminal applications which are not terminals themselves... `emerge --search terminal` just doesn't cut it as konsole wouldn't be a result but is a terminal emulator... On the other hand, terminals are spread through many categories (gnome-terminal in gnome-base konsole in kde-base to name the most obvious example). Thus tags are a nice way for user to find the applications they want. Because looking at this example and the results of `eix -cS terminal`, I see lots of things that may also be ambiguously tagged terminal due to being a terminal based application. Thus, either terminal-emulator or terminal-app or similar tags seem necessary. emerge --search tag:terminal-app tag:jabber-client ( or similar ) should thus result in net-im/mcabber You do this by searching for intersection of tags. terminal ∩ jabber ∩ client --- Jan Matějka| Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B signature.asc Description: PGP signature
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Fri, 28 Mar 2014 20:02:30 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Fri, 28 Mar 2014 15:46:49 -0400 Wyatt Epp wyatt@gmail.com wrote: On Fri, Mar 28, 2014 at 1:14 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 27 Mar 2014 03:53:47 +0100 yac y...@gentoo.org wrote: What I was describing is the difference between fundamental properties of categories and tags. You are trying to redefine categories in terms of a concept that they didn't originally represent. No one's redefining anything. You seem awfully fixated on the history that forced categories to exist, which doesn't really matter in this context. Regardless of any of that, people can and _do_ attempt to use categories as a rudimentary method of attempting to search for packages. Giving something a unique unambiguous name is not a historical issue. It's something we still need, and a core part of how package manglers work. You can't just pretend that categories there for exactly this. I see your point. Resolving ambiguity is certainly needed and categories are prettier than most distributions approach like prefixing the package name with python-. However, it still seems that besides resolving ambiguity categories are in part also used to provide information better expressed with tags, like the genre of a game. jcallen was kind enough to provide a script that finds ambiguous package names and prints them with the categories they are in [1]_ and the output for portage tree [2]_, which supports my suspicion that there indeed are no ambiguities in game names. Maybe more cases like this can be found. .. [1] http://bpaste.net/show/VuEHVqLlLgsfsdL71tuz/ .. [2] http://bpaste.net/show/195029/ --- Jan Matějka| Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B signature.asc Description: PGP signature
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Tue, 25 Mar 2014 18:31:45 +0100 Jeroen Roovers j...@gentoo.org wrote: On Tue, 25 Mar 2014 08:03:08 +0100 Jan Matejka y...@gentoo.org wrote: No, categories are essentially directories. fixed: categories are essentially also directories. Also? No, categories are *essentially* directories: they keep files apart that should not go together. In precisely that way, their names happen to aid in building unique atoms, which you need to be able to tell a package manager (or development tool) which precise bunch of files you want to read/address/target/modify/etc. They are *also* other things, like identifiers for actual categories of packages (hence the name) These are all accidental properties of our categories application. I don't see how they are relevant. What I was describing is the difference between fundamental properties of categories and tags. which may or may not suit someone's needs in finding packages based on keywords. That's where tags comes in. Stating in a GLEP that they're a giant mistake means you'll have to polish the document till you have rephrased that into something true agreed. and acceptable, or until you have purged every mention and reference of the giant mistake because it does not serve the purpose of the GLEP at all. Categories are *essential* to the way the repositories now work, and they're not going away, especially not by way of this GLEP. See below. I was asking about tags, not about categories. The original mails are: On Sun, 23 Mar 2014 15:46:09 +0100 Jeroen Roovers j...@gentoo.org wrote: On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner anta...@gentoo.org wrote: https://wiki.gentoo.org/wiki/Package_Tags This GLEP author would love to blight categories out of gentoo history as a giant mistake. Why? Categories are essentially tags, only less powerful as they can express relationship of 1:N while tags are can express M:N How is this a question about tags and not categories? The GLEP's statements about categories appear to be a straw man. It basically states that: * we introduced categories to aid in finding packages * but it turned out that categories suck at helping us find packages * so now we need to add tags * but we can keep categories because they have proven useful for other stuff Please explain how is the straw man different from real issue. --- Jan Matějka| Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B signature.asc Description: PGP signature
Re: [gentoo-dev] dev-lang/go
On Sat, 15 Feb 2014 16:44:09 -0600 William Hubbs willi...@gentoo.org wrote: On Sat, Feb 15, 2014 at 12:48:44AM +0100, yac wrote: On Fri, 14 Feb 2014 11:02:49 -0500 Emery Hemingway em...@vfemail.net wrote: 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. Not overridden, but extended. See go help gopath. 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 ?) I would prefer go_targets if this becomes an issue, golang is more search friendly but it isn't at this point because there is only one target, go1, and we do not know if there will be a go2 or not. There still are different compilers at least, even if changing minor version would be a non-issue. But I'm not familiar with those, I think those are used for compiling for other than the supported archs (iirc only x86 and x86_64) 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. Highly unlikely in the context of go1, and again, we don't know if there is going to even be a go2 or not. The only reason there will be a go2 is if there needs to be a change at the source level which can only be done in a backward incompatible way. The question really should be, do we want a system-wide workspace to store third-party libraries [1]? and if so, where do we put it -- maybe /usr/lib/go-gentoo should exist along side /usr/lib/go? I assume you are talking about thirdparty packages installed by portage, not by localy/manually by user. Well, without the system-wide workspace to store the libraries, this whole go eclass would be kinda pointless, no? Currently /usr/lib/go/gentoo is used and I see no reason to change it. The catch would be that every time you upgrade dev-lang/go, everything stored in /usr/lib/go-gentoo has to be recompiled because there is no guarantee that the libraries we have there are compatible with each minor release of go1, only the source. Then, the executables we have in /usr/bin will still run, but it would be good to rebuild them as well to get the new libraries linked into them. If we had a work space in, say, /usr/lib/go-gentoo, we could leave the executables in there and symlink them to /usr/bin. If we did that, it would be easy for a user to rebuild everything in the workspace for the new go by doing emerge /usr/lib/go-gentoo/bin Good idea. Thoughts? William [1] http://golang.org/doc/code.html --- 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
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
Re: [gentoo-dev] gentoo-x86 and git
On Mon, 10 Feb 2014 20:33:27 +0800 Patrick Lauer patr...@gentoo.org wrote: Ahoi, I've been looking for a clean git-converted gentoo-x86 repo for ... well ... mostly data mining as cvs / anoncvs.g.o is too slow for some things. While you are it, it would be great if you could get some stats on frequency of commits. Especially with reagrd to the planned cvs - git migration since this might cause some issues/inconvenience if the whole portage will be one git repo. --- 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
Re: [gentoo-dev] dev-lang/go
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}/...
I'd just copy the python herd approach (use flags, filesystem scoping
and having binary wrapper).
It is possible to compile dynamicly and that may involve using the
GCC frontend, which is probably less tested and less optimized.
I'd just skip over this unless someone is really interested in this one,
in which case this could be explicitly enabled by a use flag or
something.
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.
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 know part of the gopher commnity doesn't see this as a problem but I
believe the big players recognize this and there is an effort to come up
with a solution.
If all that sounds bad, thats because it is. Is it worth versioning
many tiny libraries or do we simply cache the repositiories and blame
upstream when things stop compiling?
I'd certainly want to have versions where available.
A have made an eclass for Go and an ebuild for the bitcoin node
written in pure Go to atleast prove that all this is possible. These
are in the 'emery' overlay:
http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=eclass
http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=dev-go
http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=net-p2p/btcd
The eclass it a bit of a mess but it works, having done that, I would
say that making ebuilds for every go library is tedious, but can be
done almost entirely with boilerplate, almost every time.
The eclasss installs go source and static libraries
to /usr/lib/go/gentoo (source code and .a library are required to
link). The problem is when Go is updated, this folder may get wiped
out, and if it isn't, those libraries will be incompatable with the
new release anyway.
How come it gets wiped? That just shouldn't happen.
The other solution I see is to make a Go directory in /var/cache or
I don't think this is a good idea as I think it would be surprising to
users to find libraries elsewhere than /usr/lib and I believe /var/cache
specificaly even violates FHS.
something like it and just manage it as a cache.
Libraries may come and go but that is fine.
I might want to have a library just for development and I'd wouldn't
like it disappearing.
Bare repositories may be cached in DISTDIR
just like the git and mercurial eclasses do. Doing things this way may
require a specific utility for Portage that wraps the Go toolchain,
which I would be willing to create. This utility could probably
automatically resolve and fetch the libraries that are required
Building the library/package shouldn't/mustn't (what does the PMS
say?) require network access once the sources are fetched.
as opposed to making an ebuild for each library, but that raises the
problem of assuming the developers of each library maintain consistant
quality and security.
Every ebuild that gets to gentoo official must meet basic standard of
quality. That's no different for golang.
The problem is Go makes it trivial to build from source, but it does
that in a very different and less precise way than Gentoo. There is
always the option of build bots and installing binaries to /opt...
Emery
I think it would be good idea to start a separate gentoo-golang
repository (github?) and treat it more (to keep it aligned with the way
gentoo works) or less (to speed up the development) as if it were gx86.
In the organization part, I think we could inspire ourself in the way
gentoo-haskell works.
[1]:
Re: [gentoo-dev] Portage QOS
On Thu, 9 Jan 2014 11:24:25 +0400 LTHR lanthrus...@gmail.com wrote: Hi All, What do you think about implementing this: http://forums.gentoo.org/viewtopic.php?p=7477494 I've system design in my head and could write it down with the implementation details. Then may be we could all review it and get to something we all agree upon then I could try getting a team and implement it. Just a brief question - does anyone know how many ebuilds are assembled world wide each second? Hi, There are some ideas that may be worth pursuing and by bottom up approach we (me and mainly naota) started turning gentwoo [1]_ [2]_ into a package usage stats [3]_ .. [1] http://gentwoo.elisp.net/ .. [2] https://github.com/naota/gentwoo .. [3] https://github.com/gentoo/GenTwoo-backend --- 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
Re: [gentoo-dev] Maintainer-needed on many of my packages
On Tue, 31 Dec 2013 11:31:47 +0100 Rémi Cardona r...@gentoo.org wrote: Le dimanche 29 décembre 2013 à 00:19 +, Robin H. Johnson a écrit : sys-apps/vbetool Is this still remotely useful with KMS-enabled kernels ? I believe so. I have used it recently to control the LVDS backlight when not in X. Cheers, Rémi --- 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
Re: [gentoo-dev] python versioned libraries or not
On Thu, 05 Dec 2013 13:32:09 +0900
hero...@gentoo.org wrote:
Dear all,
I have only one python-2.7 on my system. Simple and stupid.
After boost ebuild is converted to python-r1, libboost_python.so is
renamed to libboost_python-2.7.so. This is all cool about python-r1
for multiple python implementation support.
At the same time, I don't need this feature. I have a couple of
Jamroot's which append -lboost_python to LDFLAGS, and I have to
manually specify -lboost_python-2.7. Moreover, libraries depending
on boost.python, e.g. Boost.NumPy[1], searches for boost_python and
boost_python-mt only. I am forced to patch the build system to pass
-${PYVAR} to it, which is tedious.
Shouldn't pkg-conifg --libs handle this?
I am looking for a way out. Candidates are,
1. scan all python versioned libraries and symlink them to
unversioned one. Question: hints to do it systematically in
portage? Is there a helper available like python-exec?
2. python-single-r1 is ready for use, but it requires manipulating
the boost ebuild to change from python-r1, if I want a
python-single-r1 blessed boost. Question: How about merging
python-single-r1 with python-r1 and controlling by a global USE
flag python-single. When python-single is set, all ebuilds
inheriting python-r1 behaves as if being with python-single-r1,
so that all python versionings on executables and libraries are
disabled.
3. or something I missed
Comments?
Benda
1. https://github.com/ndarray/Boost.NumPy
---
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] Local Gentoo User Group community support
Hi What does Gentoo Linux provide for $SUBJ? I know there are mailing lists like gentoo-user-lang. Is there anything else? --- 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
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier aball...@gentoo.org wrote: On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote: However, it's been a long-standing general practise that if there are no deps in the tree older than what is necessary for a package, that package doesn't need to have a minimum version on the dependency atom. As such, issues similar to this are probably lying in wait all other the place in the tree. this is a common misconception: ebuilds must have min. deps matching their requirements (exactly because of this problem) it can be fixed on the user side by 'emerge -uDN world' meanwhile but this doesn't mean the ebuild doesn't have a bug, even if minor Alexis. When I started contributing via sunrise, I've been adding the minimal versions of dependencies as declared by upstream but I met with very strict enforcement of the policy to not specify minimal version if all the ones in current tree satisfies. Is it documented somewhere or is it just unwritten consensus? What I see is only Ebuild Policy [1e] which doesn't deal with this. .. [1e] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1 --- 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
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On Wed, 6 Nov 2013 13:22:13 -0500 Mike Gilbert flop...@gentoo.org wrote: On Wed, Nov 6, 2013 at 1:04 PM, Ian Stakenvicius a...@gentoo.org wrote: On 06/11/13 12:56 PM, yac wrote: On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier aball...@gentoo.org wrote: On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote: However, it's been a long-standing general practise that if there are no deps in the tree older than what is necessary for a package, that package doesn't need to have a minimum version on the dependency atom. As such, issues similar to this are probably lying in wait all other the place in the tree. this is a common misconception: ebuilds must have min. deps matching their requirements (exactly because of this problem) it can be fixed on the user side by 'emerge -uDN world' meanwhile but this doesn't mean the ebuild doesn't have a bug, even if minor Alexis. When I started contributing via sunrise, I've been adding the minimal versions of dependencies as declared by upstream but I met with very strict enforcement of the policy to not specify minimal version if all the ones in current tree satisfies. Is it documented somewhere or is it just unwritten consensus? What I see is only Ebuild Policy [1e] which doesn't deal with this. .. [1e] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1 I searched as well, and couldn't find anything documented one way or the other, either. I concluded that it's unwritten consensus. That's the main reason I wanted to start this discussion -- to effectively start documenting it and get dev's all on the same page. To be honest I think it should be policy or at least a written-down guideline, that dev's should do this within reason -- if an older-than-minimum version of something has been in the tree within the past year. Gone for more than a year should be safe, I expect. I don't think a time limit is necessary here. If there is an identified incompatibility, we should update DEPEND. Note that I do not expect devs to go out of their way to test for the oldest supported version of a dependency; they just shouldn't close bugs as INVALID of someone else has done the work. +1 very much. --- 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
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On Mon, 4 Nov 2013 09:51:32 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Daniel Campbell posted on Mon, 04 Nov 2013 02:50:27 -0600 as excerpted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2013 10:15 PM, yac wrote: On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: [snip] Afaik there is no official way to update gentoo, is there? It's always been emerge -avuND world [snip] Is this documented annywhere? I have a hard time finding it. I can see it mentioned eg. in man emerge in -c option but that's not good enough. Read the handbook lately? =:^) Handbook, part 2, Working with Gentoo, Chapter 1, A Portage Introduction, Doc_chapter 3, Maintaining Software (this is the amd64 link): http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml? part=2chap=1#doc_chap3 Look under the heading Updating your System. That starts with... emerge --update --ask world ... then discusses --deep, --withbdeps=y, and --newuse, so the example full update is ... emerge --update --deep --with-bdeps=y --newuse world --ask and --pretend are discussed in the same doc_chapter as well, as is -v (tho inconsistently, I don't see the long-option --verbose discussed, as it is for the others). --depclean, --search and --unmerge are discussed in that chapter too, as is gentoolkit with equery and revdep-rebuild. About the only thing missing is sets, and they're missing from working with portage (part 3) AFAICT as well, most likely because the handbooks simply haven't been updated for sets yet. Yes, there is describes what are possible ways to update the system and what criteria goes into selection of the packages to update but not which one is recommended, generaly for regular update. Could be helpful for newbs and to avoid doubt even between more experienced users. I think only -u world could be used to do updates. (possible --with-bdeps could be recommended too, for better security until users find out about glsa-check, though I think it is limited to packages that are believed to be widely deployed. Even if it is documented, I think it would be very helpfull to have such a way implemented as kind of option to emerge like `emerge --standard-ugrade` that would just alias to -uaNDv or possibly leverage sets like `emerge @upgrade` This has been discussed before. Zac could give you a summary and possibly point you at the thread, I'm sure. I believe the reason it wasn't done is because the default options setting was added instead. Well that and the fact that (as covered below), I guess most users setup their own scripts/aliases at some point, at which point the existence of something that general-purpose default built-in becomes moot. I expected some people to do this now, but I never found it worth anything unless it could deal with all the (perl|python|haskell|whatnot)-updaters and revdep-rebuild and such. It would be nice-to-have it as part of emerge for the reasons above and not having to You could emulate this yourself by setting up an environment variable to pass to emerge, or use an alias like I do: alias sysupdate='emerge -avuDN --with-bdeps=y @world' (Note: I should probably extend this to accept $1 args, in case I want to add `-t` or something) If you wanted something to cover more bases, you could make a script to do the above in addition to revdep-rebuild, python-updater, etc-update, and so on. Given the power and flexibility of portage/emerge and the extremely broad variety of needs that Gentoo meets, I believe it would be somewhat wasted work to add the option when users are already expected to read manpages and the Handbook. Perhaps -avuND should be made more obvious in a place or two in the documentation as a sort of compromise. ++ FWIW, I have a whole set of short, often 2-4 letter aliases/scripts that take care of the various options, as I'm lazy and find reaching for the - key difficult. Most of them are broken down into ea* and ep* variants, for ask and pretend, and the default is oneshot so as not to pollute the world file (which is normally empty anyway, as is @system for that matter as I negated it in my profile, everything's in sets, tho I sometimes use the worldfile as a sort of package purgatory when I want to try something out and keep it updated, but am not sure I want it in one of my permanent sets yet). Then there's esyn, which syncs both the gentoo tree and layman, as well as automatically handling ebuild patching and redigesting using a tree similar to the /etc/portage/patches/ tree, and does an automatic fetch deep world before its done. Then there's the ead (depclean) and ear (revdep-rebuild) variants, as well as epc to lookup changelogs, ept* for tree, and eal for @smart-live- rebuild. Completing the set are eup (etc-update) and envup (env-update). I have a similar set, but starting with k
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 03/11/2013 01:45, yac wrote: On Sat, 02 Nov 2013 19:19:21 -0400 Anthony G. Basile bluen...@gentoo.org wrote: On 11/02/2013 06:09 PM, yac wrote: I don't know how this releng stuff works. I bet there is lot of devs who don't. This is why you should announce risking commits. Because you may not know what it will cause, but others will. If I don't know in the first place, how do I know it's risky? Assessing risk is somewhat intuitive and relies heavily on experience. python-exec changes python wrapper scripts, emerge is coded in python. You have the makings of a circular dep right there and alarms bells should already be going off in your head. With risk, you almost always already DO have more information than at first appears. Learn to trust the little voice in your head, when it pipes up rather be careful and double check. Afaik there is no official way to update gentoo, is there? It's always been emerge -avuND world I personally got used to -uaNDv and I don't even know what exactly is the difference and it's implications between that and just -uD the difference is -N, it's in man emerge I can read man pages, I know what -N stands for, but I can't say I understand it with it's implications, as the exact behaviour depends on the state of tree at last emerge update and the state the portage tree is currently, which again depends on policies applied to the packages involved in the system and that's pretty non-trivial thing. -- 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
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
On Sun, 03 Nov 2013 10:53:13 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 02/11/2013 17:03, Michał Górny wrote: I was considering writing a news item for it but we discussed it on IRC and decided that users are really expected to be able to handle themselves, especially wrt to: 1. using 'emerge -Du @world' to upgrade their systems, I got a blocker on one system even with -uaNDv world btw, is there a difference betwen world and @world or is just new syntax? 2. reading the blocker output to see that it states 'dev-python/python-exec-1' - which suggests: what if I upgrade to 1? Sadly, it's somewhat common for (newish) users to not know what to do with that. Blocker output can be quite daunting in the beginning, especially if it's in the middle of 20 other things portage is also updating. It's not easy to parse this stuff; I've been using gentoo for what feels like forever and I still haven't managed to hard-wire my head to read blockers like an idiom. I have to study it and usually end up reading the affected ebuild directly. +1 I always have to think hard to get which blocks which and which I want. Especialy in this case with -1 and - The basic problem is that there's a lot of information to convey re a blocker, but to new users it all just looks like noise. One set of questions that were never answered and probably do deserve some kind of notification: 1. What exactly is python-exec anyway? python-exec is the thingie that makes the python thingies install libs and executables with different names/paths as per python major.minor so they are available for all the required versions. 2. Why are there two, in dev-python/ and dev-lang/ ? 3. One has a version of -1, which is *highly* unusual, what is that exactly? 1 more than -? 4. There is some kind of migration going on between an old and new python-exec, but I can't understand it using only standard portage tools. +1 I agree this change was poorly communicated to the users. An advance notice was probably warranted in this case, not to avoid bugs, but just to alert folk that something is coming down the wire and a short description of what it's trying to achieve. Most folks are naturally suspicious of anything that alters their python setup. -- 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
Official way to do rolling update (Was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: [snip] Afaik there is no official way to update gentoo, is there? It's always been emerge -avuND world [snip] Is this documented annywhere? I have a hard time finding it. I can see it mentioned eg. in man emerge in -c option but that's not good enough. Even if it is documented, I think it would be very helpfull to have such a way implemented as kind of option to emerge like `emerge --standard-ugrade` that would just alias to -uaNDv or possibly leverage sets like `emerge @upgrade` -- 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
Official way to do rolling update (Was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: [snip] Afaik there is no official way to update gentoo, is there? It's always been emerge -avuND world [snip] Is this documented annywhere? I have a hard time finding it. I can see it mentioned eg. in man emerge in -c option but that's not good enough. Even if it is documented, I think it would be very helpfull to have such a way implemented as kind of option to emerge like `emerge --standard-ugrade` that would just alias to -uaNDv or possibly leverage sets like `emerge @upgrade` -- 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
Re: Official way to do rolling update (Was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
Please do not reply to this thread. I've resent the mail without the thread context header. On Mon, 4 Nov 2013 01:59:19 +0100 yac y...@gentoo.org wrote: On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: [snip] Afaik there is no official way to update gentoo, is there? It's always been emerge -avuND world [snip] Is this documented annywhere? I have a hard time finding it. I can see it mentioned eg. in man emerge in -c option but that's not good enough. Even if it is documented, I think it would be very helpfull to have such a way implemented as kind of option to emerge like `emerge --standard-ugrade` that would just alias to -uaNDv or possibly leverage sets like `emerge @upgrade` -- 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
Re: [gentoo-dev] Last rites: app-arch/xarchiver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I don't think that upstream deciding to rewrite a package is good enough reason to tree clean the package. Have you done this with eg. bind package which is constantly rewritten and constantly have security issues? The same goes for closing bugs until the versions are removed from portage (either because version deprecation or treeclean with proper reason) as users may find those informational. On Sat, 02 Nov 2013 16:16:53 + Markos Chandras hwoar...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (02 Nov 2013) # On behalf of Treecleaners # Upstream started a complete rewrite of the package # meaning that existing bugs will not be fixed by future # version bumps of the existing code. # It is unclear when/if the new code will be released any time # soon so masked for removal in 30 days. # The package can be re-introduced later on if the new # maintainer feels it is stable enough. # See #483588 and #473692 app-arch/xarchiver - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJSdSV1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88t6UP/RnVftEt5nvWMGTAZeiTVBy+ rc/KdpW4tT7xNlkfoQvtmcBjx7UPXePOUcmRVODaOK/F5R5gCijnwqoENP2r0xVV KX8kmZL2R1oX98p9hRssiZ3a6wiZbvGsy8P/voOvQhKJCu0i1xl/Iio/5ZfyTaQT zFtcMC8nn0LIFH20lQft5ukFQTQdoktb8XL70dfjSU8iCu/lrBrIU19cdOH5psev IEzu39t732aqNiEoXJb6r8l9kpBeeunRQ7pDP3GC8RunME/MxHuNELJPqCUFC4F7 iRJZd6fFyY3pSObhXA6FtEtLPx0xSX+FEOKE/OGOaDnrQ3IMm9nwk5/zLjGZCXhi spW7z970Kv6f9VzUEQmLGBDA8pgRkZo2bfvd4hMjeK/Szzr/v+FU0RjKrYwV0Wxo ncXWFmL/MwWhXo6Nc8LjN+4BDUlZKDNMgf30R+g3LxhCLmX98fHFbVjGvL4nrGkF z/zqVtnk4led1ipGQFQweseaNYbQrkq4nJbgATjLAOcQwsrpZEj3PGs89uI/Eo3f 830YGeleoIZkd1pf1QwVoHdLxbBlIKlVua/PgXtfQLTEqdgxrY5Se9Mqf25xqwfx KejCOHDWWWYFTlfkodKkiM3qsvzwORM0+b6JA2jxw047yeXoDTb1y2q0X0oA+kjT Ri+2zibvoDZJksjRz4xR =Xd15 -END PGP SIGNATURE- - -- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: F97A36A1 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJSdTyBAAoJEIN+7RD5ejah9vcH/2NhbApohR5Bq14fQzHgcne0 YJ7TV3m75ttr4rpb3Ox1HQeRrzDnDJuLuaPY/MzXGw+QuMrA30y5cCc10V08AaFO SfxYY+GwrvdbqMbwxeULbtuIKgTTwdb5gBNL+3gpx+8xdZeZvTd/MHTKnu185ejq wYc2MyS3S1ttSFIcVp550uQ+lMdq9cn/a4T2LN/Pclzmpjh/DsE5eIaEACUMRlSx c76rVunc1CWzgwGwzGsfs0ES/Qv26eL7sf7oL89LKsTCzg07yaSQVMP7eEvB9k5j CJtbhFcaBfunhPSP4bov2sKq8f6Clvn236hFazvL3THsCCr5hH5Ny3IeiE2tFdk= =A1Sm -END PGP SIGNATURE-
Re: [gentoo-dev] Last rites: app-arch/xarchiver
On Sat, 02 Nov 2013 17:57:34 + Markos Chandras hwoar...@gentoo.org wrote: On 11/02/2013 05:55 PM, yac wrote: Hi, I don't think that upstream deciding to rewrite a package is good enough reason to tree clean the package. Have you done this with eg. bind package which is constantly rewritten and constantly have security issues? The same goes for closing bugs until the versions are removed from portage (either because version deprecation or treeclean with proper reason) as users may find those informational. Ok let me clarify this again 1) The original code of the package is gone since upstream started from scratch. What do you mean by gone? I still can `ebuild xarchiver* fetch` the sources. Otherwise this is not a reason to treeclean the package. 2) It has no maintainer. Not a reason for treecleaning. 3) It has open bugs and upstream will never fix them and there is no maintainer to patch the code to fix it properly. In bgo[1] there are two bugs open. Upstream [2] seems to have more bugs but they also seem to be mostly new features or corner cases. There already was discussion on treecleaning bug[3] where you claim the package is broken while several users explain it is broken *partialy*. Eg. c30 says only 2 formats doesn't work. c21 claims it always crashes on passwords, however upstream bug reports indicates it's also true for only some formats. c6 indicates xarchiver will break on unrar-5 when it will go stable but it still is not stable, is it? Given the way this issue is communicated, I have to ask - Is it even true? The rar major version seems to be related to rar format version rather then ABI/API. Even if xarchiver breaks on unrar-5, I see many other packages depending on unrar, do you know these will not break and possibility of having both unrar4 and 5 will not be just due xarchiver? So per treecleaner policy the package will be removed. Or have you just volunteered to become maintainer and fix the bugs? [1] https://bugs.gentoo.org/buglist.cgi?quicksearch=xarchiver [2] https://bugzilla.xfce.org/buglist.cgi?quicksearch=xarchiver [3] https://bugs.gentoo.org/show_bug.cgi?id=483588 -- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: F97A36A1 signature.asc Description: PGP signature
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 02 Nov 2013 15:20:41 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2013 11:03 AM, Michał Górny wrote: Dnia 2013-11-02, o godz. 14:51:26 Tom Wijsman tom...@gentoo.org napisał(a): On Sat, 02 Nov 2013 09:16:45 -0400 Anthony G. Basile bluen...@gentoo.org wrote: This is a followup to a discussion on IRC yesterday regarding breakage that's occurring to catalyst builds as a result of the recent move from dev-python/python-exec to dev-lang/python-exec. This has been happening to users as well, for example: http://forums.gentoo.org/viewtopic-t-973998.html http://forums.gentoo.org/viewtopic-t-974412.html To move forward and get this resolved, some questions: 1. Has this been resolved for users? Do they just need to sync? 2. If not resolved for users, what is the best temporary workaround? 3. Are you able to fix this? Do you need help to fix this? 4. Depending on the nature of the fix: Would a news item be needed? From what I heard, most of people get this working through a plain: emerge -Du @world If someone is really reluctant to world updates, it is enough to upgrade dev-python/python-exec to 1.*: emerge -1v dev-python/python-exec I was considering writing a news item for it but we discussed it on IRC and decided that users are really expected to be able to handle themselves, especially wrt to: 1. using 'emerge -Du @world' to upgrade their systems, 2. reading the blocker output to see that it states 'dev-python/python-exec-1' - which suggests: what if I upgrade to 1? If you believe that a news item would be helpful, I'm happy to write it. Just please make sure that we're all in agreement over the method of handling the issue. A news item isn't enough for breaking autobuilds. If we can't find a way to do this properly so portage knows how to upgrade then it is being done WRONG. Autobuilds break, gentoo can't be installed, the distro dies. I know, sounds like I'm making something out of nothing but every time people look at the stages and notice they are months out of date we find another blog post announcing how gentoo is dead. Honestly, if I knew a way to fix this I would have already made any changes needed to fix it. Please fix this, because if you don't, eventually I'll find a way and I doubt you will like it. I guess you can run a basic QA like that the image boots and gets the network up with openQA (or using the same method) at least to detect such breakage. - -Zero Additionally, the news item would state how to get rid of the old deps. This will presumably involve something like: emerge -1v $( qdepends -NCQ dev-python/python-exec ) Please note that 'equery d' from gentoolkit is currently broken due to some random magic inside portage and doesn't list all the packages correctly. However, for the latter it would be probably preferred to wait with it till python-exec:2 is stable on all arches to avoid rebuilding packages twice in a short time. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSdVCJAAoJEKXdFCfdEflKLiwP/AjlCVUKeHo7wI8FO6W/VE4u 2Pv2VqaRGQ3KDn/yvHfClfXib8Eu4/KE1cc8kUoP4vspRQLiCz3qMqtYqFy9Y3DF fPYbBL5w4Z1V/sAho9pd3f2XHAOYwM/G1cD2GfbEHY5XdR4rk8w3AzK8cTCO5gL4 DmbBS1t/G3fLoNBud4pCpM+QCD1edwHWSptjWS2lQN9hNI9VwOBrXmuBKLPHR05F JyLWiiTbHPD6y/UquVa9uqdcHRJ5uTAyu9CZPu4CDrC3sJuFYuZxYZc2s4VjqyLo YKXhp5RJjFJT23ZNhM1eAUCH2jxiJM8JoTRC1gYY1mKuWqL3gLojPDjTqS5ukya6 C8mZ9dqEtqEisJuUQPBkuhfKfClmk0sDCTwrtEJCe4day7gX9w5uPZO1oFrJ+/8Y 6M0chyaU33XaZBIRLMo/KaCg0MccW3Oob2AVo8pesrPrmQwPnXnGvps8rlbrkpv+ lFdx1yh/phW2oWq3yVHf4LlPgrajDrgLzDgcVXYKByG/Nd2pKkkbzq/JfAwtfzck fpufYDbWF3j8ErVGjzWWQLR4NOzf01NC5Q/U4dCVR+Yy4+a0joSuTB6fz2+eFjz8 6NCr7i+lYPcrnnlvf97XBvXhbsf0NIhwiJtMkLi72LKgI+Wn3D/Xc3H62KqjsXDf Hc3RqAPCSO/GAqf5hqVl =VeiN -END PGP SIGNATURE- - -- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: F97A36A1 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJSdWIUAAoJEIN+7RD5ejahSUgH/1/DJdVBC/4FbLY0iqctdeRr 0nrkTMYM9CSIw9qwakLtxsEHaSStJCOYeOfZ6iMlvpq0mteYBOiTRe69fV37jy/X 72KovFje6Wj1PQwbF1K9jQ47Vw09gaM00HdFz1F6n7pNNHJyujKZaiGN4+jeiBCg vR/sssus8BJOGY0e0kS6gyBH93GIyZVRodgT7s6JBiOp+1+wZukEQSU+WUNjCTHQ 1RZ93zZ8/5WtIaZDphWxMeoRiw4B0lUJE2QCB63ZCbUBc+kg6ysN++t4f9zvHW1r viQ8TYk9+L6gpACTmSzHfhTKExUgcXvakQjbFldb7AJwULQXz8DbxDHZbV1lWFw= =P+Bi -END PGP SIGNATURE-
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 02 Nov 2013 16:57:07 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2013 04:35 PM, yac wrote: On Sat, 02 Nov 2013 15:20:41 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2013 11:03 AM, Michał Górny wrote: Dnia 2013-11-02, o godz. 14:51:26 Tom Wijsman tom...@gentoo.org napisał(a): On Sat, 02 Nov 2013 09:16:45 -0400 Anthony G. Basile bluen...@gentoo.org wrote: This is a followup to a discussion on IRC yesterday regarding breakage that's occurring to catalyst builds as a result of the recent move from dev-python/python-exec to dev-lang/python-exec. This has been happening to users as well, for example: http://forums.gentoo.org/viewtopic-t-973998.html http://forums.gentoo.org/viewtopic-t-974412.html To move forward and get this resolved, some questions: 1. Has this been resolved for users? Do they just need to sync? 2. If not resolved for users, what is the best temporary workaround? 3. Are you able to fix this? Do you need help to fix this? 4. Depending on the nature of the fix: Would a news item be needed? From what I heard, most of people get this working through a plain: emerge -Du @world If someone is really reluctant to world updates, it is enough to upgrade dev-python/python-exec to 1.*: emerge -1v dev-python/python-exec I was considering writing a news item for it but we discussed it on IRC and decided that users are really expected to be able to handle themselves, especially wrt to: 1. using 'emerge -Du @world' to upgrade their systems, 2. reading the blocker output to see that it states 'dev-python/python-exec-1' - which suggests: what if I upgrade to 1? If you believe that a news item would be helpful, I'm happy to write it. Just please make sure that we're all in agreement over the method of handling the issue. A news item isn't enough for breaking autobuilds. If we can't find a way to do this properly so portage knows how to upgrade then it is being done WRONG. Autobuilds break, gentoo can't be installed, the distro dies. I know, sounds like I'm making something out of nothing but every time people look at the stages and notice they are months out of date we find another blog post announcing how gentoo is dead. Honestly, if I knew a way to fix this I would have already made any changes needed to fix it. Please fix this, because if you don't, eventually I'll find a way and I doubt you will like it. I guess you can run a basic QA like that the image boots and gets the network up with openQA (or using the same method) at least to detect such breakage. I think everyone involved knows that manual intervention is needed to resolve this dep. I'm sure that things were tested before they were commited, which leads me to believe that the commiter didn't care that manual intervention is required. Sadly, we at releng do. I am actively seeking a resolution for this, let's see who commits it first. I don't know how this releng stuff works. I bet there is lot of devs who don't. Also I think your response is also completely unrelated to my suggestion. My suggestion is about acting proactively instead of reactively - automatically testing eg. the image of livecd iso that gets built to verify eg. it is bootable and network working to at least detect such breakage and do not publish broken iso instead of hoping for the best and eventualy getting bug reports. - -Zero - -Zero Additionally, the news item would state how to get rid of the old deps. This will presumably involve something like: emerge -1v $( qdepends -NCQ dev-python/python-exec ) Please note that 'equery d' from gentoolkit is currently broken due to some random magic inside portage and doesn't list all the packages correctly. However, for the latter it would be probably preferred to wait with it till python-exec:2 is stable on all arches to avoid rebuilding packages twice in a short time. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSdWcjAAoJEKXdFCfdEflK2vYP/Rf2I3SSAm0ZwxJRqYl2Lv+y TrYscC0ekWn3Z0+FwUz9rhfhWJwoCjCEv7zsxq0UQiQu+xK+DmqXcgw38zYGb6Wv bPvq8JMpcSa4tz1wW+wbepS31fXq/WlV1E03BRAbUrM1bhxyS2qia8S0AkTyN4xt UlleZb8Ep0NrlX1JAx/EgLCBmA61xj5ONdIPlyni5RCtnFZIPnMRTVhlFARaWXQJ coFztk/ke7B43p2Q6wGR6zHRNdnH59gHg6FwDxXsys/AajSDFrR9Id5GoAgOiqPW 9eqbwyR50Csd3H3UKdmit7Tdn80TSt4qWs/NXSrvG+38TVm1U6hY6rVSSHHuUXba b3QqT/jx7GzUa3GtKp7QD5ZcKk/F2d7z/oOeGUodGNJ8P+5cQHHb96z0vKR6D2lU DPpH8v5EWAY01PLW/1240mTljT6/30GPNxEgR1oj2GxOUR+gUnVXFARcorP4R5Ek qv2jLp1SZgQDAht8RfvR1ngXIpQmNyUvYCKQuxu3fwhANxu0T1DqLfO0shxg9FnZ
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
On Sat, 02 Nov 2013 19:19:21 -0400 Anthony G. Basile bluen...@gentoo.org wrote: On 11/02/2013 06:09 PM, yac wrote: I don't know how this releng stuff works. I bet there is lot of devs who don't. This is why you should announce risking commits. Because you may not know what it will cause, but others will. If I don't know in the first place, how do I know it's risky? Afaik there is no official way to update gentoo, is there? I personally got used to -uaNDv and I don't even know what exactly is the difference and it's implications between that and just -uD -- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: F97A36A1 signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Scire project - plans?
You know there are already projects like cfengine and puppet that seems to be way ahead. Also most of the links on the project page are not working anymore. On Tue, 29 Oct 2013 07:25:19 -0700 Brian Dolbec dol...@gentoo.org wrote: On Tue, 2013-10-29 at 17:15 +0400, Sergey Popov wrote: Hello, i just want to raise question: should we add deprecation on project page of Scire[1] or even remove this project entirely? Cause project seems slightly abandonded, leader(agaffney) is in progress of retiring[2], other project member(blackace) has no commit access to tree[3]. CCing all interested parties [1] - http://www.gentoo.org/proj/en/scire/ [2] - https://bugs.gentoo.org/show_bug.cgi?id=68900 [3] - https://bugs.gentoo.org/show_bug.cgi?id=45816 I'll join. Although I do have too many projects on my plate in some ways. I've always thought it would fairly easy to add another backend interface to porthole capable of interfacing with remote machines or groups of machines. It is something I'd like to add. It also goes with a plan to add an extension to eclean to get remote pkg lists from machines for consideration doing distfiles and binpkg cleaning. C'mon, there has to be more people interested in this... signature.asc Description: PGP signature
Re: [gentoo-dev] OT: user-developer/privileges in IRC
On Tue, 22 Oct 2013 13:02:29 +0400 Sergey Popov pinkb...@gentoo.org wrote: 22.10.2013 07:19, Peter Stuge пишет: I should have included bugzilla among mailing lists+IRC, users can indeed also have elevated privileges on IRC, but never equal to developers. It is radical exclusion and I'm reminded of it every time the #gentoo-dev channel mode catches my eye, painfully so if there's a discussion I could perhaps contribute to. Most of the time it is easy enough to say something privately to a relevant developer, but that's still very different from actual participation. Yes, and i think that it was done for a reason. Now I wonder if the +m on IRC was set proactively or reactively. If the former it could be worth a try to -m. But nobody stops you from requesting temporarily voice on #gentoo-dev and when you contributions will be marked as significant - gentoo/contributor cloak, that will give you permanent voice in #gentoo-dev. You should understand that #gentoo-dev is channel for developer's communication primarily and it is not so restricted, as you think. For example, #gentoo-infra is totally restricted to developers only, other interested parties should be added to channel ACLs explicitly or should get invite there. signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
AFAIK this known historical behavior that what you find in `/etc/mtab` are things mounted by mount(8) (if that's what's printed by running just mount). Whereas /proc/mounts is the kernel view on what's mounted. Curiously I don't see any difference on my gentoo box, which I think I should see but I'm not sure. Anyway, I've seen differences when eg. automounter was used, iirc. I wouldn't be surprised if there are things that depends on this behavior or if there are more cases like automounter. On Sun, 13 Oct 2013 14:32:32 -0500 William Hubbs willi...@gentoo.org wrote: All, from what I'm seeing, we should look into converting /etc/mtab to a symlink to /proc/self/mounts [1]. Are there any remaining concerns about doing this? If not, it seems like it would be pretty easy to make baselayout create this symlink in the stages (I'm willing to do this work), but what about on systems that are already installed? Should we send out a news item and have everyone convert their /etc/mtab manually or find a way to automate that? William [1] http://bugs.gentoo.org/show_bug.cgi?id=477498 signature.asc Description: PGP signature
Re: [gentoo-dev] stabilizing libraries without testing reverse deps
On Wed, 2 Oct 2013 10:12:00 +1300 Kent Fredric kentfred...@gmail.com wrote: On 2 October 2013 08:51, Peter Stuge pe...@stuge.se wrote: I agree, but I think the problem is basically that many people consider it impossible for newer to ever be shitty. Even if they are intimately familiar with the details of a package upstream they may still not be capable of determining what is shitty in the context of a distribution. I guess most stabilization requesters as well as actual stabilizers are even less familiar with upstream details, so determining what is shitty and not is really hard.. :\ The other really annoying thing you have to consider, is that most people out there are using all (~ARCH) or all (ARCH) keywording, not a mix of the two. ^ This has the fun side effect of meaning packages that are (~ARCH) and have (ARCH) dependents, where the package that is currently (~ARCH) is pending stabilization, has likely had nobody test it at all except for arch testers. AFAIK this moot since users running testing are expected to expect breakage regardless of what the breakage is, as long as it caused by testing package. btw, I'm one of those running mixed stable/testing system and based on my limited experience I believe this is a rare scenario. So if you're relying on the presence of filed bugs to give some sort of coverage metric, you're going to be out of luck from time to time. For instance, that fun bug where stabilising a version of libraw broke the things depending upon it that were already stable. Its ironic really, thats essentially a hidden bug that exists as a result of having two tiers of testing. https://bugs.gentoo.org/show_bug.cgi?id=458516 I've been long wishing there was a FEATURE I could turn on that would just report installs to a database somewhere, showing success/fail/succcess+tests/fail+tests , with dependencies, useflags, and other relevant context, so you'd at least have a dataset of *success* rates, and you could do more heavy testing on things where there were fail results, or an absense of results. +1 CPAN has a comparable service that leverages end users reporting test runs on code while they install it, and some end users, given this power, go so out and set up mass automated testing boxes, the utility of which I find useful on a daily basis, because a user is far more likely to get an automated success/fail report sent to a server, and far *less* likely to want to set time aside to go through the rigmarole of filing a bug report. Some users are also inclined to just try a few versions either side, and never file a bug report, or try twiddling USE flags or disabling problematic FEATURES to find a version that works for them, and you may never see a bug report for that. An automated X combination failed report at very least lets you know a datapoint where a failure occurred. I'd be cautious about involving users in this as it very often happens to myself that something breaks, I get mad and then figure it was my own fault (eg. messing with cflags I shouldn't mess with) I'm not saying we should make any automated decision making *based* on those reports, but it would be far more useful to have a list of known failure cases up front than to ask a tester to try be lucky and find it by looking for it. ( After all, bugs often arise when you're not looking for them, as opposed to when you are, and some bugs, when looked for, vanish ) signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults
There should not be a collision of the dropin.cache in the first place. By adding the cache files to COLLISION_IGNORE it will just hide the collision problem and create other one (with obsolette caches), harder to debug. On Sat, 10 Aug 2013 11:19:59 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2013-08-09, o godz. 11:32:12 Michał Górny mgo...@gentoo.org napisał(a): Hello, Just a quick one. Currently, the two listed variables are set in make.globals (installed by portage ebuild); COLLISION_IGNORE=/lib/modules/* *.py[co] *\$py.class UNINSTALL_IGNORE=/lib/modules/* I've committed the following values for now: COLLISION_IGNORE=/lib/modules/* *.py[co] *\$py.class */dropin.cache UNINSTALL_IGNORE=/lib/modules/* We can discuss further changes without users suffering. signature.asc Description: PGP signature
Re: [gentoo-dev] Marking of deprecated USE flags
On Fri, 9 Aug 2013 18:40:39 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: Some people want that repoman print warnings for ebuilds, whose effective IUSE contains deprecated USE flags (e.g. USE flags corresponding to old versions of Python/Ruby). I suggest that deprecation of USE flags be specified by (DEPRECATED) suffix in descriptions of given flags in profiles/use.desc and profiles/desc/*.desc files. Any opinions about syntax? Is there a use case for something like (DEPRECATED BY X) ; X being another use flag or maybe bugid ? Example: Index: profiles/desc/python_single_target.desc === RCS file: /var/cvsroot/gentoo-x86/profiles/desc/python_single_target.desc,v retrieving revision 1.5 diff -u -r1.5 python_single_target.desc --- profiles/desc/python_single_target.desc 5 Aug 2013 14:20:47 - 1.5 +++ profiles/desc/python_single_target.desc 9 Aug 2013 16:27:37 - @@ -4,14 +4,14 @@ # This file contains descriptions of PYTHON_SINGLE_TARGET USE_EXPAND flags. -python2_5 - Build for Python 2.5 only +python2_5 - Build for Python 2.5 only (DEPRECATED) python2_6 - Build for Python 2.6 only python2_7 - Build for Python 2.7 only -python3_1 - Build for Python 3.1 only +python3_1 - Build for Python 3.1 only (DEPRECATED) python3_2 - Build for Python 3.2 only python3_3 - Build for Python 3.3 only -jython2_5 - Build for Jython 2.5 only +jython2_5 - Build for Jython 2.5 only (DEPRECATED) jython2_7 - Build for Jython 2.7 only -pypy1_9 - Build for PyPy 1.9 only +pypy1_9 - Build for PyPy 1.9 only (DEPRECATED) pypy2_0 - Build for PyPy 2.0 only pypy2_1 - Build for PyPy 2.1 only Index: profiles/desc/python_targets.desc === RCS file: /var/cvsroot/gentoo-x86/profiles/desc/python_targets.desc,v retrieving revision 1.9 diff -u -r1.9 python_targets.desc --- profiles/desc/python_targets.desc 5 Aug 2013 14:20:47 - 1.9 +++ profiles/desc/python_targets.desc 9 Aug 2013 16:27:37 - @@ -4,15 +4,15 @@ # This file contains descriptions of PYTHON_TARGETS USE_EXPAND flags. -python2_5 - Build with Python 2.5 +python2_5 - Build with Python 2.5 (DEPRECATED) python2_6 - Build with Python 2.6 python2_7 - Build with Python 2.7 -python3_1 - Build with Python 3.1 +python3_1 - Build with Python 3.1 (DEPRECATED) python3_2 - Build with Python 3.2 python3_3 - Build with Python 3.3 python3_4 - Build with Python 3.4 -jython2_5 - Build with Jython 2.5 +jython2_5 - Build with Jython 2.5 (DEPRECATED) jython2_7 - Build with Jython 2.7 -pypy1_9 - Build with PyPy 1.9 +pypy1_9 - Build with PyPy 1.9 (DEPRECATED) pypy2_0 - Build with PyPy 2.0 pypy2_1 - Build with PyPy 2.1 Index: profiles/desc/ruby_targets.desc === RCS file: /var/cvsroot/gentoo-x86/profiles/desc/ruby_targets.desc,v retrieving revision 1.3 diff -u -r1.3 ruby_targets.desc --- profiles/desc/ruby_targets.desc 23 Jun 2013 12:31:14 - 1.3 +++ profiles/desc/ruby_targets.desc 9 Aug 2013 16:27:37 - @@ -6,7 +6,7 @@ rbx - Build with Rubinius jruby - Build with JRuby -ree18 - Build with Ruby Enterprise Edition 1.8.x +ree18 - Build with Ruby Enterprise Edition 1.8.x (DEPRECATED) ruby18 - Build with MRI Ruby 1.8.x ruby19 - Build with MRI Ruby 1.9.x ruby20 - Build with MRI Ruby 2.0.x -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: PGP signature
Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2
I have fully encrypted systems, including /, which requires an initramfs with cryptsetup built staticaly. On Mon, 29 Jul 2013 22:57:58 +0200 Pacho Ramos pa...@gentoo.org wrote: Hello As discussed at: https://bugs.gentoo.org/show_bug.cgi?id=478476 Upstream is dropping static libs from udev and, then, sys-apps/udev is currently reverting that commit downstream (even if upstream says some problems could appear in the future as nobody is taking care of static stuff there). Grepping in the tree, looks like only some old genkernel versions are depending on it. Apart of that, what is requiring static libs in cryptsetup and lvm2? Thanks a lot signature.asc Description: PGP signature
Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 27 Jul 2013 00:13:37 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2013 12:08 AM, Matt Turner wrote: (I sent this to gentoo-releng@. Resending to gentoo-dev@ for a wider audience) Can we make autobuilds go to /experimental and then only move them to /releases when someone actually tests them? Looking at bugzilla and listening in #gentoo-releng, it's kind of embarrassing how often someone downloads a Live CD only to find out that networking is totally broken by a udev upgrade, or something to that effect. We don't commit version bumps straight to stable; I don't see why we do with release media. It's been an odd week for me agreeing with people but yeah, I completely agree. I think we *need* to keep the autobuilds going as often as possible to detect obvious breakage, but there is no reason they shouldn't be marked experimental. The real question is, how realistic can we make a process of testing and moving to stable? openSUSE is using [openQA] for automated testing of installation media which is pretty need something that starts a machine in KVM and then simulates the user via a keyboard events. Last year there was also a talk about it on osc12 [2] [openQA] http://openqa.opensuse.org/ [2] http://www.youtube.com/watch?v=57a9zmpA844 - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR80jxAAoJEKXdFCfdEflKhGYP/At7Xtd4bWcY1wrxl1oPYdNr vVfgqhmnveNqwhdERcp8InGLGoCDt+O3hvSzq4kX8qJXqizxPonP9ef1hJsnz0iw NgjMHiGiYp2NgmU6DB7X/VLH3RNF96WJMK/R2Qtk1tuN+Ftu1D6T5hP4MmTOuvta T2CvfYGFVAPZiY9+GLAmbe1LhjwlbJ8DnhbaamA7bK1D0ZhApWtRVtjk6unu+D5w XRG8tIDml5gUkZRVl4d9Bg1wxuMoPtOuY2ANr+RCJPRVMkexB1XCdAVzPF73EFx+ 0Ns5TKi+vWyhzY6PElvA0xClj2wAK/enAkAmPZ8OvagnCLfmoqZUNyr4+Eupxclt 54pFMzpdR2KntmmFqS5ZBF8Q6nxz8GDhSm0H8+d1xTKxNcwKSlaAI7JkzBByWhKt MjFYNTVz7MD/MFpvpRt2tKg3BI6m/ZcgCQwnAJ9QjdtyhLA8/Km5+AA2tnN457V7 qlpf+ipjDzb3G5Po1JXSMUidy8Uu6SvqHu8TwiJUy/mlKxjmPmrPPGfRpR32pWNT d/jE6IQAmiVjXWTDDBi0uZY8oUl5H0uroLFuA+//NtmGD8DWmV1fK0PYKLjUsE4X nWaCKn2qlF7d16mnJh1RweBjQjMmvRYutg62A3Jb9Ek9jXBIC4bYJa2VS2xoPpWy qZv8oon/9z336E5Uvamj =KaUO -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJR86ybAAoJEIN+7RD5ejah990H/jHk6bDSJeRmkDwj0FLiIc3I FbzwwaTug3DWpa1xegPTOK4Mxa2Nb7aVYfs4bZsQvQYrw+3WzvHmeYhfRiBNlU/B yiVGJ5TcPQpYltrTKx/nOuEvkH9NTcv/woiuTQ/kRedZKmNAmD/iQPwbITzOgE5U vCKyHtXGv9bwQbQBlHGNDHkinasMEGNio5uK/1XMjSxeRS9xmcAn1UNDc4OucEpA ac9EwrJgIzWgVnqD9x/mGY+GwB+dFZWrVyeGlsfEyHrTkDGu7zMBwJPd7swCxGFT ABLqts0EjbPnZIbihe962Tt/E73srEvgoHACib4D7P4sjB+X4leCQMu3D3RQVNs= =yUYu -END PGP SIGNATURE-
[gentoo-dev] New eclass: twisted-r1
Hi,
I'm sending revised twisted-r1.eclass including the ebuild bumps.
You can view the diff either in the included patch or at github [1]
I have tested on amd64 and x86. All packages emerge and tests are
passing, besides nevow, axiom, and mantissa which are failing anyway
with the old eclass too.
Will commit tomorrow if there are no disputers.
[1]
https://github.com/yaccz/gentoo-overlay/commit/1288b7989a156d3e9c3b6b1a0f079c33c9dffc10
commit 1288b7989a156d3e9c3b6b1a0f079c33c9dffc10
Author: Jan (yac) MatÄjka jmate...@suse.cz
Date: Mon Jul 8 13:57:23 2013 +0200
eapi 5/twisted-r1 bumps
* elcass
* twisted-* ebuilds
* twisted depender ebuilds
diff --git a/dev-python/axiom/axiom-0.6.0-r1.ebuild b/dev-python/axiom/axiom-0.6.0-r1.ebuild
index 7291292..8e88ccb 100644
--- a/dev-python/axiom/axiom-0.6.0-r1.ebuild
+++ b/dev-python/axiom/axiom-0.6.0-r1.ebuild
@@ -2,17 +2,11 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-python/axiom/axiom-0.6.0.ebuild,v 1.14 2013/05/12 18:32:59 floppym Exp $
-EAPI=3
-PYTHON_DEPEND=2
-SUPPORT_PYTHON_ABIS=1
-RESTRICT_PYTHON_ABIS=2.5 3.* *-jython
-PYTHON_USE_WITH=sqlite
+EAPI=5
+PYTHON_COMPAT=( python{2_6,2_7} pypy{1_9,2_0} )
+PYTHON_REQ_USE=sqlite
-# setup.py uses epsilon.setuphelper.autosetup(), which tries to use
-# build-${PYTHON_ABI} directories as packages.
-DISTUTILS_USE_SEPARATE_SOURCE_DIRECTORIES=1
-
-inherit eutils twisted
+inherit eutils twisted-r1
MY_PN=Axiom
MY_P=${MY_PN}-${PV}
@@ -23,35 +17,24 @@ SRC_URI=mirror://pypi/${MY_PN:0:1}/${MY_PN}/${MY_P}.tar.gz
LICENSE=MIT
SLOT=0
-KEYWORDS=amd64 ppc ppc64 sparc x86
+KEYWORDS=~amd64 ~ppc ~ppc64 ~sparc ~x86
IUSE=
-DEPEND==dev-python/epsilon-0.6
- =dev-python/twisted-2.4
- =dev-python/twisted-conch-0.7.0-r1
+DEPEND==dev-python/epsilon-0.6.0-r2[${PYTHON_USEDEP}]
+ dev-python/twisted[${PYTHON_USEDEP}]
+ dev-python/twisted-conch[${PYTHON_USEDEP}]
RDEPEND=${DEPEND}
S=${WORKDIR}/${MY_P}
-DOCS=NAME.txt
-PYTHON_MODNAME=axiom twisted/plugins/axiom_plugins.py
-TWISTED_PLUGINS=axiom.plugins twisted.plugins
-
-src_prepare() {
- epatch ${FILESDIR}/${PN}-0.5.30-sqlite3.patch
- epatch ${FILESDIR}/${PN}-0.5.30-sqlite3_3.6.4.patch
- python_copy_sources
-}
-
-src_compile() {
- # Skip distutils_src_compile to avoid installation of $(python_get_sitedir)/build directory.
- :
-}
+DOCS=( NAME.txt )
+PATCHES=(
+ ${FILESDIR}/${PN}-0.5.30-sqlite3.patch
+ ${FILESDIR}/${PN}-0.5.30-sqlite3_3.6.4.patch
+)
-src_test() {
- python_execute_trial -P . axiom
-}
+TWISTED_PLUGINS=axiom.plugins twisted.plugins
-src_install() {
- PORTAGE_PLUGINCACHE_NOOP=1 distutils_src_install
+python_test() {
+ trial -P . axiom || die tests failed with $EPYTHON
}
diff --git a/dev-python/epsilon/epsilon-0.6.0-r2.ebuild b/dev-python/epsilon/epsilon-0.6.0-r2.ebuild
index cc893ad..9462af6 100644
--- a/dev-python/epsilon/epsilon-0.6.0-r2.ebuild
+++ b/dev-python/epsilon/epsilon-0.6.0-r2.ebuild
@@ -2,18 +2,10 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-python/epsilon/epsilon-0.6.0-r1.ebuild,v 1.2 2012/10/12 08:15:00 patrick Exp $
-EAPI=3
-PYTHON_DEPEND=2
-SUPPORT_PYTHON_ABIS=1
-RESTRICT_PYTHON_ABIS=2.5 3.* *-jython
-DISTUTILS_SRC_TEST=trial
-DISTUTILS_DISABLE_TEST_DEPENDENCY=1
+EAPI=5
+PYTHON_COMPAT=( python{2_6,2_7} pypy{1_9,2_0} )
-# setup.py uses epsilon.setuphelper.autosetup(), which tries to use
-# build-${PYTHON_ABI} directories as packages.
-DISTUTILS_USE_SEPARATE_SOURCE_DIRECTORIES=1
-
-inherit eutils twisted
+inherit eutils twisted-r1
MY_PN=Epsilon
MY_P=${MY_PN}-${PV}
@@ -27,14 +19,15 @@ SLOT=0
KEYWORDS=~amd64 ~ppc ~ppc64 ~sparc ~x86
IUSE=
-DEPEND==dev-python/twisted-2.4
+DEPEND=dev-python/twisted[${PYTHON_USEDEP}]
RDEPEND=${DEPEND}
S=${WORKDIR}/${MY_P}
-DOCS=NAME.txt NEWS.txt
+DOCS=( NAME.txt NEWS.txt )
+PATCHES=( ${FILESDIR}/epsilon_plugincache_portagesandbox.patch )
-src_prepare() {
+python_prepare_all() {
# Rename to avoid file-collisions
mv bin/benchmark bin/epsilon-benchmark
sed -i \
@@ -42,27 +35,16 @@ src_prepare() {
setup.py || die sed failed
# otherwise we get sandbox violations as it wants to update
# the plugin cache
- epatch ${FILESDIR}/epsilon_plugincache_portagesandbox.patch
#These test are removed upstream
rm -f epsilon/test/test_sslverify.py epsilon/sslverify.py || die
#See bug 357157 comment 5 for Ian Delaney's explanation of this fix
sed -e 's:month) 2004 9:month) 2004 14:' \
-i epsilon/test/test_extime.py || die
- #These are broken too
- rm -f epsilon/test/test_release.py epsilon/release.py || die
-
- python_copy_sources
-}
-
-src_compile() {
- # Skip distutils_src_compile to avoid installation of $(python_get_sitedir)/build directory.
- :
-}
-
-src_test() {
# Release tests need DivmodCombinator.
- rm -f epsilon/test/test_release.py* epsilon/release.py
+ rm -f epsilon/test/test_release.py* epsilon/release.py || die
Re: [gentoo-dev] New eclass - twisted-r1
On Thu, 11 Jul 2013 08:55:47 +0200
Michał Górny mgo...@gentoo.org wrote:
Dnia 2013-07-10, o godz. 23:40:11
yac y...@gentoo.org napisał(a):
On Wed, 10 Jul 2013 22:25:50 +0200
Michał Górny mgo...@gentoo.org wrote:
First of all: please wrap lines at 72 or 80 chars (even if the
original eclass didn't do that).
if [[ ${CATEGORY}/${PN} == dev-python/twisted* ]]; then
I know you're not responsible for this but it seems wrong to have
two different behaviors depending on PN. Is this used somewhere
actually?
MY_PV=${MY_PV:-${PV}}
MY_P=Twisted${MY_PACKAGE}-${MY_PV}
HOMEPAGE=http://www.twistedmatrix.com/;
#SRC_URI=http://tmrc.mit.edu/mirror/twisted/${MY_PACKAGE}/$(get_version_component_range
1-2 ${MY_PV})/${MY_P}.tar.bz2
SRC_URI=http://twistedmatrix.com/Releases/${MY_PACKAGE}/$(get_version_component_range
1-2 ${MY_PV})/${MY_P}.tar.bz2
LICENSE=MIT
SLOT=0
IUSE=
S=${WORKDIR}/${MY_P}
TWISTED_PLUGINS=${TWISTED_PLUGINS:-twisted.plugins}
fi
That's what I thought when I saw that but I found that all the
dev-python/twisted-* packages are depending on this, so I went with
it.
Now I'm thinking I could instead provide functions
twisted-r1_twisted_src_uri and twisted-r1_twisted_build_dir used as
SRC_URI=$(twisted-r1_twisted_src_uri)
S=$(twisted-r1_twisted_build_dir)
in the depender ebuilds.
I'm more-of wondering if that conditional is really necessary useful.
Unless I'm missing something, the non-twisted ebuilds will replace
those variables anyway, won't them?
The dev-python/twisted-* packages do rely on this. They will set just
MY_PACKAGE=
And the S, SRC_URI, LICENSE, SLOT, IUSE is set by the eclass.
Other than dev-python/twisted-* packages does not match, so they need
not to override it.
I think the main purpose is code deduplication regarding setting the
SRC_URI and S.
signature.asc
Description: PGP signature
Re: [gentoo-dev] New eclass - twisted-r1
On Wed, 10 Jul 2013 22:25:50 +0200
Michał Górny mgo...@gentoo.org wrote:
python_test() {
# TODO: this seems to be used only in dev-python/twisted-*
packages as # dev-python/twisted-13.0.0 have it's own src_test
if [[ ${CATEGORY}/${PN} != dev-python/twisted* ]]; then
die ${FUNCNAME}() can be used only in
dev-python/twisted* packages fi
local sitedir=${EPREFIX}$(python_get_sitedir)
# Copy modules of other Twisted packages from site-packages
directory to temporary directory. mkdir -p ${T}/${sitedir}
cp -R ${ROOT}${sitedir}/twisted ${T}/${sitedir} || die
Copying of modules of other Twisted packages failed with
$(python_get_implementation) $(python_get_version) rm -fr
${T}/${sitedir}/${PN/-//}
Awful and ugly. Try to find a way to run the tests without this
hackery.
What are you referring to?
For the ${CATEGORY}/${PN} match. All the non-twisted packages are
overriding src_test but it's probably be gonna cleaner to rename the
python_test to twisted-r1_twisted_test and call it explicitly for the
twisted packages.
As for the Copy modules, I'm afraid that's inevitable.
signature.asc
Description: PGP signature
[gentoo-dev] New eclass - twisted-r1
Hello everypony In order to bump dev-python/twisted packages to EAPI=5 we also need to bump the twisted eclass to use distutils-r1. I have made this bump (to the eclass and dev-python/twisted*) packages in my yac overlay [1] You can view the actuall changes at [2]. It's merely the existing twisted eclass adapted to distutils-r1. I have tested the packages (merge, module import in python and tests) on python2_7 at amd64. I don't know when I'll get around to testing other pythons and x86. Certainly I'm currently unable to test pypy and eprefix. Besides reviewing the changes, could somepony test these arches? [1] https://github.com/yaccz/gentoo-overlay/tree/twisted-r1 [2] https://github.com/yaccz/gentoo-overlay/compare/5421996...020b0c2 signature.asc Description: PGP signature
Re: [gentoo-dev] New eclass - twisted-r1
On Wed, 10 Jul 2013 22:25:50 +0200
Michał Górny mgo...@gentoo.org wrote:
First of all: please wrap lines at 72 or 80 chars (even if the
original eclass didn't do that).
if [[ ${CATEGORY}/${PN} == dev-python/twisted* ]]; then
I know you're not responsible for this but it seems wrong to have two
different behaviors depending on PN. Is this used somewhere actually?
MY_PV=${MY_PV:-${PV}}
MY_P=Twisted${MY_PACKAGE}-${MY_PV}
HOMEPAGE=http://www.twistedmatrix.com/;
#SRC_URI=http://tmrc.mit.edu/mirror/twisted/${MY_PACKAGE}/$(get_version_component_range
1-2 ${MY_PV})/${MY_P}.tar.bz2
SRC_URI=http://twistedmatrix.com/Releases/${MY_PACKAGE}/$(get_version_component_range
1-2 ${MY_PV})/${MY_P}.tar.bz2
LICENSE=MIT
SLOT=0
IUSE=
S=${WORKDIR}/${MY_P}
TWISTED_PLUGINS=${TWISTED_PLUGINS:-twisted.plugins}
fi
That's what I thought when I saw that but I found that all the
dev-python/twisted-* packages are depending on this, so I went with it.
Now I'm thinking I could instead provide functions
twisted-r1_twisted_src_uri and twisted-r1_twisted_build_dir used as
SRC_URI=$(twisted-r1_twisted_src_uri)
S=$(twisted-r1_twisted_build_dir)
in the depender ebuilds.
signature.asc
Description: PGP signature
Re: TLDR: rant in support of overlays (was: Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays)
On Wed, 12 Jun 2013 15:31:57 -0700 Greg Turner g...@malth.us wrote: Anyhow, isn't the gentoo-x86 tree already plenty big enough, without every single overlay's ebuilds and eclasses in there too? Personally, I'm inclined to wish it was smaller, even if that meant more stuff was pushed into overlays Actually, this is something I expected to happen soon after we got overlays but for some reason it haven't. I imagine we would not have a single gx86 official tree but rather a bunch of official overlays. For basic installation one would need just the system overlay. Then everypony could add official overlay for KDE, or gnome or whatnot as one desires. I haven't thought this through in any way but it feels like better design.
[gentoo-dev] repoman warning on python data_files
Hi I have just noticed that if package is using relative paths in:: setup.py data_files = ... Then the files are installed right into /usr in case of CPython (The exact dest is determined by sys.prefix) So, I'm thinking it could be worthwhile to add a warning to repoman if package is using this method as I can imagine this can be easily overlooked when creating a new package or mostly when bumping one.
[gentoo-dev] CPU use flag detection
Hi, I was recently investigating what cpu flags do I have and how does it work. I have put what I have so far at [1]. So I thought I let you know in case someone wants to chip in. [1] https://github.com/yaccz/cufd
