Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On 11/21/2010 04:57 AM, Ryan Hill wrote: On Sun, 21 Nov 2010 01:38:23 +0200 Nikos Chantziarasrea...@arcor.de wrote: On 11/21/2010 12:46 AM, Ryan Hill wrote: I'm unmasking sys-devel/gcc-4.5.1 tomorrow. I'd like to recommend everyone who has already unmasked it to rebuild it now as there has been some important patches added recently (see ChangeLog). revbump? We don't do revbumps on masked toolchain packages. Why not? Yeah why not? do you inform users of this?
Re: [gentoo-dev] News item: Dropping Java support on ia64
Any improvements to the text are welcome. I think the following could be written clearer. Reading it made me have to go off and check what week 50 was. If there is no interest the removal of Java support well be done during week 50 of year 2010. why not say 'If there is no interest the removal of Java support well be done during the week starting 13th Dec 2010. (please confirm the date on that) Regards, Petteri
Re: [gentoo-dev] .la files removal news item (GLEP 42)
Hi lads, due to recent situation about .la files status we would like to inform users about this situation. See attached file that we propose to be included as news item. Would it not be a better solution to have this information documented properly under Upgrade Guides or Gentoo System Documentation and then have this news item linked to it. What i'm concerned about is that this is not really a news item. From what I understand this issue could be with us for a rather long time (years even) so... How is this news item going to help ppl in a month from now (till the issue is solved in its entirety). Can we reasonably expect a new user to be aware of this. Do we expect users to read old ( and this could potentially become very old) news items. This is potentually a different situation from someone updating dbus (for example) from y.y.y to =y.y.y and having a once off (fire and forget) migration task. It is for this reason that I think this should be documented. Alistair. Step 2 will be finding global policy how to get rid of them as fast as possible without too much more hassle for our users :) Tomáš Chvátal Gentoo Linux Developer [Clustering/Council/KDE/QA/Sci/X11] E-Mail : scarab...@gentoo.org GnuPG FP: 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587 GnuPG ID: 03414587
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
Hi folks, I'm currently collecting a set of rules which upstream developers should follow to make distro maintainer's life easier. Comments welcomed :) Is this language specific? would you be interested in comments about java, ruby, python, etc, etc, etc or are you only interested in good old C/C++, etc cu
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On 04/24/2010 09:14 PM, Alexis Ballier wrote: On Sat, 24 Apr 2010 20:40:54 +0300 Petteri Räty betelge...@gentoo.org wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. no thanks; we already have the policy to require that major changes to broad impact eclasses have gone through -dev, no need to add more bureaucracy. But the policy is not tested by the quizzes and we have had cases lately where large diffs have been committed without gentoo-dev review. With peer review it's likely that the reviewer is familiar with what should be sent to gentoo-dev as hesitant/new people won't give their approval that easily. 1) Why is it of any relevance whether or not the quizzes test this policy? 2) Where is this policy recorded, and why does devmanual.g.o seem to (possibly) contradict it? [1] I'm not sure of the nature of the commits but were they non-general? - Alistair [1] It is not usually necessary to email the gentoo-dev list before making changes to a non-general eclass which you maintain. Use common sense here. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
1 - requirements In order to choose the best possible wiki implementation, we need to know our requirements. So what features do you think are essential or good to have? What syntax would we prefer to use? I myself am a big fan of reStructuredText, which is quite simple, easy to pick up, highly readable, and has a good featureset. Plus, it is also reusable in other contexts (it is for example widely used in documentation of Python libraries). MediaWiki, MoinMoin and Trac have support for rst. I'm not overly concerned about what wiki we use. But may I suggest we approach gentoo-wiki to see whether they would like to be involved. Some others: - active upstream (bug fixes, security updates) - free open source software - ACLs - spam prevention measures - attachments (to upload screenshots for example) - feeds Other distros and open source projects surely have had the same considerations. Can we find out and learn from them? 2 - maintainers === Who is volunteering for maintaining the wiki? We need editors and moderators, people who look out for quality control and take care of spam removal. So let's get together a team. I'm sure if we ask on the forums we'll get some users interested as well. I would like to help as I may. Hopefully we can get a good body of users to help as well. I'm of the firm belief that it will be users who should make this idea either fly or crash down hard.Dev's have official means of documenting stuff. 3 - edit access === Do we keep to the original free for all model, with all the spam that includes, or do we go with registered users only? I think the latter is the smarter option. I also think we will want to mark certain pages official and lock down editing rights. Registered users only please. Is there anything else we should consider before getting started? What project should we create this under. gdp is for official documentation so I don't think it should be under that but it could very well be under userrel. Or it could be a new project. I also have some other ideas that I would like to implement once I get around to brain-dumping them. So I will simply ask this question. Are there any complimentary services we could offer users besides a wiki? Maybe best to just think about this and not answer it here. Cheers, Alistair
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 4/3/10 3:40 PM, Ben de Groot wrote: Are there any other ideas on how to improve our recruitment process? The idea appeared before, but I think it's worth noting. Either merge the ebuild and end quizzes, or make the split actually meaningful. In my case I just finished both at the same time, but was confused why they are separate. I think I've seen similar comments from other developers. I think I'd rather prefer merging the quizzes. One thing i've noticed is that the ebuild quiz is far more difficult than the eom quiz. We seem to have the biggest hurdle first. What I would like to see is either the quizzes be merged or An easier first quiz that covers the basics which after being answered the user can become a gentoo developer ( ie @gentoo.org email, ssh access to d.g.o, etc) but no access to push directly to the tree. Instead all commits must be pushed thru their mentor, who is responsible for qa'ing and giving advice. Currently I don't think mentors really have much of a role. There is certainly no requirement for a mentor to qa their charges commits, but if they are the ones pushing to the tree the mentor has all the responsibility. This might just make mentors more responsible for the quality of recruits. Some of this could be done regardless of whether there are separate quizzes or not obviously. But I think it creates a nice workflow. - Alistair.
Re: [gentoo-dev] List of User projects
diffball (the basis of y'alls delta compression for tarball snapshots, progenitor of tarsync used by emerge-*webrsync, etc). Thank you Brian for that pkg, its appreciated. My apologies if the rest is a little less kind. ps. I would like the packages to be specifically for gentoo, but there are exceptions to this. as an example openrc (and even paludis to a degree). If you think that there is a package not specifically targetting gentoo that deserves a mention please make it clear why. I'm a bit torn by this proposal; on the one hand, a shout out is nice- from a career angle it certainly would've been useful for getting some attention/exposure when I first was starting out. Not really my aim. Im not planning on listing ppl, just there work. Might not even put a url pointing to it. That said, it has some issues with it: * it'll wind up being a fairly subjective list leading to some debates nobody really wants to be involved in (nice euphemism for flamewars). Well I suppose it would be my project, therefore I would make the call. ppl can flame all they like really. Personally I don't find them a very good way to communicate, would probably miss what they were flaming about anyway. *) the criteria seems to be external projects that are gentoo specific, aparently by non-devs/ex-devs. This raises some questions as to what happens for when it's created by a dev externally (pkgcore went external a long while before I became an exdev), and what happens when the author becomes a dev (I'll be getting my gentoo-x86 +w back soon enough). Firstly that is very good news. Currently I am taking this from Mon, 29 March 19:42 NZ DST. So pkgcore is external, and you are a community member so your in the list. I don't want to bring a whole pile of history into it. Will pkgcore have its own gentoo project, or be considered as part of a gentoo project? Im guessing not anyway. I'm quite happy to consider the corner cases, and will probably include a vast majority of them. Initially I don't even believe I will have a fully complete list of all the projects the fit nicely into my criteria. Thats why you have one of those nice statements that says. While we have attempted to list all package/projects etc we are sure we have missed some, please contact .. if you believe we have missed something blah de blah blah *) PMS was started outside of gentoo, and maintained outside gentoo for a long while. Now it's a gentoo project. A shout out there would've been warranted (spec work isn't exactly sexy, regardless of any extra baggage that came w/ PMS), but at what point does it suddenly fall off this list? Isn't this a bit too bikesheddy. If someone, from now, were to create a project and then have it added to the list before they become a dev then good on them. The project would not be removed. Even if it died. In fact the list would never be cleaned. It may be updated to represent the state of the project, but that project would be there for as long as the page was. (and probably longer the way ppl index the interwebs). *) kind of the packagekit connundrum- at least for pkgcore/paludis, they were written to support multiple distros/formats internally. Yes they've got traction w/in gentoo, but at what point is it no longer a gentoo specific thing, and more of a it gained it's first traction in gentoo ? Openrc I'd argue is in the same boat- yes it can be used elsewhere, but right now we're the owns extracting the most benefit from it. Well I would suggest that a major part of the functionality of both those pkg's are directed towards supporting gentoo. Even if both supported 5-10 completely different distro's that did not resemble gentoo in the slightest I would still put them on the list. Compare this with kmyfirewall that had a single dialog that allowed to be set gentoo specfic executable paths which would not be on the list. *) it slights the tools that started w/in gentoo's vcs; consider scanelf . Very useful tool deserving some credit, but it would be exempted under these rules. Life ain't always perfect. And that goes both ways. This isn't a list to thank developers for their effort, make another thread if you want that. It also doesn't slight that project in the slightest. Instead, if the purpose is a thanks, why not every once in a while put up a news item discussing the tools in question? Such an approach allows folk to focus in on whatever is useful/interesting (regardless of origination) and give the same 'thanks' angle and public exposure for the author in question. Well I was considering this as well. But first before we do this we would need to actually know what packages there are. Therefore this thread. Unless we do all packages from a to z. - Alistair ps. I must say that its a little sad that so far there has been much more effort put into nitpicking than
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Saturday 27 of March 2010 21:58:41 William Hubbs wrote: It's really freaking silly to wait months for stabilization of some random php/perl library that's known to work. Have you ever just considered closing the stabilization bug and ignoring the arch. If they take so long to mark your packages as stable why do you care about them enough to even attempt to stabilize anything on their arch.
Re: [gentoo-dev] Re: List of User projects
So you mention openrc, but don't have it on the list? Yes because openrc isn't really gentoo-specific. I don't want the list blowing out to include ever package in the entire tree. ie. Thanking gcc for contributing to gentoo. Note this doesn't mean that openrc won't be on the list. I think that in this case the dev has worked closely enough with gentoo to deserve acknowledgment. (being a former dev might have helped that :) ) Maybe it will be in a Non-Gentoo specific section of the list, or something. My point at the moment is to distinguish it from something like pkgcore/paludis which were developed with gentoo firmly as the target platform. FWIW, I've not looked, but I think a number of the portage helpers are non-gentoo-dev developed, and certainly a number previously were, that have ultimately been folded back into portage and/or gentoolkit in someway or another now. I'm sure someone from one of those projects can list several of them without even looking. Well i'm more interested in what is being developed verses what were developed. But that is an interesting possibility, not surprising but interesting none the less.
[gentoo-dev] List of User projects
I was just thinking how nice it could be if we acknowledged some of the projects that contribute to gentoo but are actually developed primarily outside of gentoo's dev community. How about a page on gentoo.org So lets me start with a couple of obvious ones. kportagetray pkgcore paludis There must be more than these or else gentoo really is dead. - Alistair ps. I would like the packages to be specifically for gentoo, but there are exceptions to this. as an example openrc (and even paludis to a degree). If you think that there is a package not specifically targetting gentoo that deserves a mention please make it clear why.
Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it
Zac Medico wrote: I think what most people want is for portage not to pull in a package that nothing uses. I'm not a dev nor a programmer but I have yet to see any good reason for installing something that is not being used. It's not being tested to see if it is stable. It would have to be used before that would happen. Basically, it is just one more package to update and taking up hard drive space. It's not doing anything else. As for slots, if something needs it, portage would pull in the new slot. That's what portage does. It just seems in this case it is pulling in a new slot that nothing uses. Have you considered that they might possibly be hundreds of packages that you have installed providing functionality that you never use, but are only there as a fixed dependencies of something that you do. Hell lets take it even further than that, i'm sure there are thousands of lines of code in most packages that you will never hit, so why dont we start masking them as well. I don't recall ever using grep --version, please remove (mask) that code from grep. We will obviously need someway to unmask those code masks so lets create a couple of files for portage. Hows code.mask and code.unmask with a format of package path/to/file line1 line2 line3 line4 Or maybe we could just let users who don't want to install python-3 mask it _locally_. Once they need it portage is more than capable of telling them that. Dale :-) :-)
[gentoo-dev] Last rites: dev-java/kaffe
# Alistair Bush ali_b...@gentoo.org (15 Mar 2010) # Mask for removal (#309459). Does not compile # and Dead upstream. Recommend icedtea jdk's for # a free alternative. dev-java/kaffe -Alistair
Re: [gentoo-dev] The feature patch mess in the webalizer ebuild (and how to deal with it)
Solution 1) Add two new packages to the tree: - app-admin/geolizer (/usr/bin/geolizer) - app-admin/webalizer-xtended (/usr/bin/webalizer-xtended) 2) Bump webalizer to 2.21 while - no longer applying either feature patch - removing use flag xtended - keeping now hollow use flag geoip to reduce breakage 3) Close related bug 231859 https://bugs.gentoo.org/show_bug.cgi?id=231859 I volunteer to do that. Any objections or suggestions? +1 we really should be attempting to keep as close to upstream as possible.
Re: [gentoo-portage-dev] a feature called stabilize wanted
Hello List ans anyone! I'm searching for a feature or an hint how and where to implement it. Mmmm... Im not one of the knowledgable ppl around here but you can have version ranges within files like package.keywords eg cat/A-4.0 which would mean ~arch A-4.0 = arch which is essentially what your asking for. The biggest issue I have with a feature like this is that you seems to be overriding the config files all ready present. That would only last until the next time you ran emerge. I think this could be better solved with tools ( gui or cli ) that allowed a user to manage package.keywords, etc. Now a tool that actually did this would be very interesting indeed. Alistair. The desired feature could be called stabilize or update to stable and would change the selected packages when doing an update (emerge -avuND world). Just to give you an initial idea/example, some packages: package A - (the old_stable) has: 3.0 3.4 3.8 ~3.9 package B - (the young_stable) has: ~1.3 ~1.4 ~1.6 package C - (the unstable) has: ~0.6 ~0.8 ~1.1 So version numbers with the ~ are unstable/~amd64, where numbers without are stable/amd64. Case 1 (amd64): using system wide only stable/amd64 Installing anything would result in a...@3.8 and C,B not installed Case 2 (~amd64): using system wide the unstable/~amd64 keyword Installing anything would result in a...@~3.9 b...@~1.6 c...@~1.1 Case 3 (real world): get it managed with masks and keywords that the major packages are stable, while new features could arrive Installing anything with the result a...@3.8 b...@~1.6 c...@~1.1 Nothing new so far, now new package versions arrive: package A - (the old_stable) has: 3.0 3.4 3.8 ~3.9 NEW: 4.0 ~4.1 package B - (the young_stable) has: ~1.3 ~1.4 ~1.6 NEW: 1.8 ~1.9 package C - (the unstable) has: ~0.6 ~0.8 ~1.1 NEW: ~1.2 ~1.4 So if we now update (emerge -avuND) right now the results are: Case 1 (amd64): Update a...@3.8 to 4.0, B,C not installed Case 2 (~amd64): Update a...@~3.9 to ~4.1, b...@~1.6 to ~1.9, c...@~1.1 to ~1.4 Case 3 (real world): depends on the new set of masks and keywords... much work ahead What I search is the stabilize feature for the update e.g. (emerge -avusND) should result in: Case 1 (amd64): - update a...@3.8 to a...@4.0, because a new stable version updates the old stable version - B, C not installed Case 2 (~amd64): - update a...@~3.9 to a...@4.0 update unstable packages to the stable version when arrived, stop using unstable. - update b...@~1.6 to b...@1.8 update unstable packages to the stable version when arrived, stop using unstable. - update c...@~1.1 to C~1.4 update unstable packages, the never unstable versions. Case 3 (real world): - update a...@3.8 to a...@4.0 update stable package to newer stable version when arrived. - update b...@~1.6 to b...@1.8 update unstable packages to the stable version when arrived, stop using unstable. - update c...@~1.1 to C~1.4 update unstable packages, the never unstable versions. Optional: make is possible to ignore/filter/select the unstable to unstable updates, those might cause trouble. Anyone, could help me? Give me a hint if this would be possible? Any hints where in code this could be implemented? I'm programmer, professional, so if I get the right hints, will invest spare time in this. Also I'll ready to setup and run various tests. But I never before worked at portage... It might be a good start if the people with the Know-How, will start a discussing about this idea, what problems need to be solved, which code parts will need an update and so one. Than I could try to get it working, but right now, I doesn't even know the right questions. Best regards, - Johannes Kellner
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On 5 March 2010 12:24, Zac Medico zmed...@gentoo.org wrote: It won't be pulled in by sys-apps/portage dependencies which look like this: || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6 =dev-lang/python-3 ) If you already have python:2.6 installed then it will not pull in a new slot. That means we would need to fix all packages that depend on python to use this style of dependency notation. Or do some eclass magic with NEED_PYTHON for example. And of course anyone with an unslotted dev-lang/python in their world file will still pull the useless version. Then they shouldn't have dev-lang/python in their world file then should they. Or should we start putting special magic rules around everywhere. Hell i'm sure I have useless crap in my world file, you don't see be bitching about being forced to upgrade some package I never use. If it is in there then it is my responsibility, not yours. Guys you should remember that we like to call gentoo a metadistribution [1]. Our users should be taking an active role in the maintenance of the own distro what we should be doing is saying yes we have determined this package to be stable. The news item should tell users they can safely mask python:3 if they wish. The only concern I have is all the []dev-lang/python [R]DEPENDs there are in the tree. They should be fixed to either be slotted or a dependency range. Thank god this will never happen again now that we have slot deps right? :| Alistair. [1] http://www.gentoo.org/main/en/about.xml [2] and by this I mean looking to see what packages are going to be installed and whether they really want to install them.
Re: [gentoo-dev] Re: QA last rites for x11-wm/ion
Le 15/12/2009 08:09, Ulrich Mueller a écrit : On Tue, 15 Dec 2009, Peter Hjalmarsson wrote: On the other hand this may be something for treecleaners? A package that has not been bumped for 7 years? With at least three releases since, and a bumprequest open for at least one year? A link to a webside that does not exist? And both its sucessors x11-wm/ion2 and x11-wm/ion3 already punted two years ago. Wasn't there some licence issue with this package, too? That was with ion3 IIRC. Something about the author changing the license from GPL to don't patch ion3 ever without telling me about it and showing me your patches so I can approve them. Or something similar, wikipedia/google might know more than me. As far as the original ion is concerned, the masking seems perfectly in order. If someone wants it, that person can step up and do the work (directly or via proxy). Cheers, Rémi http://www.modeemi.cs.tut.fi/~tuomov/ion/ What an angry angry man. Drop it!!
Re: [gentoo-dev] Amount of useflags enabled by default
Hi, i would like to start a discussion about reducing the amount of default-enabled USE flags in profiles, especially in inherited basic profiles. Sounds like a reasonable idea to me, for the base profiles at least. In addition, i see a trend to enabled more more more USE flags (either over profiles or via IUSE +flag). Whats the reason for forcing a big load of default enabled USE flags on every user including more dependencies, more compile time, more wasted disk space and more possible vulnerabilities except some users, who complain about a missing feature and are not able to think and enable a USE flag for that feature? who complain about a enabled feature and are not able to think and disable a USE flag for that feature? What a couple of changes make It would be nice if we actually documented why they were enabled. Does the use flag enable significant functionality that would otherwise make the software less useful. I believe we should be trying to find a nice 'middle of the road' balance. DE related use flags should be enabled in profiles ( unless of coarse they package is already DE related e.g if a kde package has a use flag for kde's sound system, this could be enabled at a package level while a package with a kde use flag should not default enable it.). So, if we were looking at what use flags ppl are enabling/disabling we should be seeing similar numbers for the +'s and the -'s. Not an easy thing to do, I admit. Would be interesting if something like Color Graphing [1] or some algorithm could be used to determine whether a use flag should be enabled in a profile (including which profile)/package. Maybe we should have some addition metadata for use flags. Like a category/type/blah/blee. As an example we could have a category of DE containing kde/gnome/etc. How do we know that the dirac use flag is codec related without knowing what dirac is? Alistair [1] http://en.wikipedia.org/wiki/Graph_coloring
Re: [gentoo-dev] Stabilization of Python 3.1
Stabilization of Python 3.1.* will be requested at the beginning of november. There was a suggestion to create a news item which would inform users that temporarily they shouldn't switch to Python 3 as their main interpreter. Python ebuilds don't automatically activate Python 3, so I'm not sure if the news item is required. What is your opinion about it? Stablise. And to pacify all the cry babies out there could we update portage tools to call /usr/bin/python2.6 directly? (yes I realise this will break, but at least it is a suggestion) Or how about we (remove python3.1 from the menu)/(stick a big fat warning message)/(do something else) on eselect-python. Or create a system-python link that all gentoo core apps use instead of /usr/bin/python (longer term solution?). [rant]Hell maybe we could even start using those slot dep thingy me bobbies to depend only a slot. So ppl don't have python3.1 unless something depends on it. Does portage have support for slots in world? [/rant] Solutions ppl. Thats is what we need. Not oh poor woe is me. Alistair.
Re: [gentoo-dev] Re: Stabilization of Python 3.1
Someone here want people install paludis? because when I've switched to python 3.0 just out of curiosity, it broke totally that python written package manager who is portage. So another package manager was needed to re-install a sane portage. No it wasn't. [1] You just didn't know that ( which is completely understandable ). Just as you must not have understood the implications of emerge -C python:2.6. I don't want to be mean but would you like to enlighten us as to how you managed to unemerge python:2.6 while using python3 when portage didn't work with python3. [1] http://tinderbox.dev.gentoo.org/default-linux/amd64/dev-lang/python-2.6.2- r1.tbz2 Still, do you really want to have it in tree as stable? Really? Yes really.
[gentoo-dev] Patch: java-vm-2.eclass support for java build-only vm's
Simple patch as part of java-config's support for marking EOL and security
vulnerable vm's to be marked as 'build only'. Users setting these as either
their system or user vm will be warned of the risks of doing so.
The release of java-config with this functionality, this eclass and some
associated version bumps will all be in the tree by weeks end.
Any suggestions are welcome.
Alistair.
Index: java-vm-2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/java-vm-2.eclass,v
retrieving revision 1.27
diff -u -b -B -r1.27 java-vm-2.eclass
--- java-vm-2.eclass 17 Apr 2009 22:50:41 - 1.27
+++ java-vm-2.eclass 24 Aug 2009 11:20:04 -
@@ -24,6 +24,7 @@
JAVA_VM_CONFIG_DIR=/usr/share/java-config-2/vm
JAVA_VM_DIR=/usr/lib/jvm
+JAVA_VM_BUILD_ONLY=${JAVA_VM_BUILD_ONLY:-FALSE}
EXPORT_FUNCTIONS pkg_setup pkg_postinst pkg_prerm pkg_postrm
@@ -134,7 +135,10 @@
${source_env_file} \
${env_file} || die sed failed
- echo VMHANDLE=\${VMHANDLE}\ ${env_file}
+ (
+ echo VMHANDLE=\${VMHANDLE}\
+ echo BUILD_ONLY=\${JAVA_VM_BUILD_ONLY}\
+ ) ${env_file}
[[ -n ${JAVA_PROVIDE} ]] echo PROVIDES=\${JAVA_PROVIDE}\ ${env_file}
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] 2009 Council Elections
Ben de Groot wrote: I would think the only thing that matters is the best interest of Gentoo. This is after all the _Gentoo_ Council we're speaking of, not a body that is concerned with non-Gentoo matters. ++ In my opinion it is in the best interest of Gentoo at this point to ignore Exherbo and to silence those people involved with Exherbo that have been so divisive and generated so much conflict in Gentoo channels. Why silence what you can ignore? Also Exherbo is the most similar project we have to compare ourselves too. If drobbins had ignored freebsd where would we be now? We shouldn't ignore anything, debain, suse, fedora, etc, etc, etc all have something to contribute. Ignoring them because we don't like their members will only make Gentoo weaker. We should instead be looking at what they have done that we can use to improve gentoo. As our closest relative ( of any distro ) having Council members that have at least a basic understanding of what (and how) they are attempting to achieve is a good thing. The same goes for Sabayon. To appoint as proxy for a council meeting someone who has been booted from Gentoo is a clear lapse of judgement, and would in my eyes disqualify the involved council member from functioning in that position. I actually look forward to seeing how he goes. While the other candidates certainly have great merits, they tend to only see one side and concentrate too much on Gentoo alone. I would hope so. The people we elect to the council should concentrate on Gentoo, otherwise they'd have a conflict of interest. Maybe we should force Council members to disclose their involvement with other projects? You never know, we might have a ubuntu dev on the council :D Alistair.
Re: [gentoo-dev] 2009 Council Elections
Nirbheek Chauhan wrote: On Fri, Jun 26, 2009 at 12:30 AM, Wulf C. Krueger w...@mailstation.de wrote: between both. This strengthening bridge of understanding can be seen in dev- zero's move to appoint ciaranm as his proxy for today's council meeting. Sorry to rain on your parade, but with ciaranm's consistent history, allowing him to participate in Gentoo's discussions itself is a privilege of patience on the part of the Gentoo community. I would believe that recent history would show the opposite. There seem to be a group of developers at which the mere mention of ciaranm results in setting them off. Regardless of the technical merits of a solution they seem more interested in just derailing anything that might have anything to do with ciaramn. I realise that ciaranm has had a nasty past. But recently I haven't see anything. I for one hope that this continues and that other members of the community take a look at themselves before spouting about the evils of ciaramn. Allowing him to proxy in a council meeting is both disallowed (non-gentoo devs cannot be on the council), and reflects badly on the candidate in question (dev-zero). Not shared by everyone. -- ~Nirbheek Chauhan
[gentoo-dev] java-utils-2.eclass patch. Support for BUILD_DEPEND being recorded within package.env.
Firstly, fellow developer please review this eclass patch and read on if
you are interested in what it actually does.
Java developers:
The following patch adds 3 new values to our package.env
PVR and CATEGORY being the easy ones. These are being added because I
think they should be there and they will help with implementing a
paludis re-emerge-everything-java script.
the 3rd BUILD_DEPEND records the packages/jars that have been passed as
parameters to our java functions ( jar-from, getjars, getjar ) and also
have --build-only specified. The format is exactly like package.env's
DEPEND variable. The main reason for this patch is to allow Serkan to
add --build-only dependencies to the classpath for java-dep-check.
java-config support is not currently planned but this may change if need be.
Here are some example package.env files.
# more
/var/tmp/portage/app-office/hourglass-0.7.2/image/usr/share/hourglass/package.env
DESCRIPTION=A PSP (personal software process) time tracking utility
written in Java
GENERATION=2
SLOT=0
CATEGORY=app-office
PVR=0.7.2
CLASSPATH=/usr/share/hourglass/lib/hourglass.jar
DEPEND=log4j@log4j:jcommon@jcommon-1.0:jdom@jdom-1.0
VM==virtual/jre-1.5
BUILD_DEPEND=ant@ant-core
TARGET=1.5
SOURCE=1.5
JAVADOC_PATH=/usr/share/doc/hourglass-0.7.2/html/api
JAVA_SOURCES=/usr/share/hourglass/sources//hourglass-src.zip
MERGE_VM=sun-jdk-1.7
MERGE_COMPILER=javac
# more /var/tmp/portage/dev-java/sbaz-1.25/image/usr/share/sbaz/package.env
DESCRIPTION=A system used by Scala enthusiasts to share computer files
with each other.
GENERATION=2
SLOT=0
CATEGORY=dev-java
PVR=1.25
CLASSPATH=/usr/share/sbaz/lib/sbaz.jar
DEPEND=scala-library@scala
VM==virtual/jre-1.5
BUILD_DEPEND=servlet-api@servlet-api-2.4:ant-contrib
TARGET=1.5
SOURCE=1.5
MERGE_VM=sun-jdk-1.7
MERGE_COMPILER=javac
--- java-utils-2.eclass.old 2009-06-04 19:46:37.711668962 +1200
+++ java-utils-2.eclass 2009-06-04 22:13:22.694684085 +1200
@@ -874,6 +874,7 @@
local destdir=.
local deep=
local virtual=
+ local record_jar=
[[ ${EBUILD_PHASE} == test ]] build_only=build
@@ -918,7 +919,7 @@
[[ -z ${build_only} ]] java-pkg_record-jar_
${pkg}
done
# setting this disables further record-jar_ calls later
- build_only=build
+ record_jar=true
else
java-pkg_ensure-dep ${build_only} ${target_pkg}
fi
@@ -928,7 +929,7 @@
if [[ -z ${build_only} -n ${virtual} ]]; then
java-pkg_record-jar_ ${target_pkg}
# setting this disables further record-jars_ calls later
- build_only=build
+ record_jar=true
fi
pushd ${destdir} /dev/null \
@@ -946,13 +947,25 @@
[[ -f ${target_jar} ]] rm ${target_jar}
ln -snf ${jar} \
|| die Failed to make symlink from ${jar} to
${jar_name}
- [[ -z ${build_only} ]] java-pkg_record-jar_
${target_pkg} ${jar}
- # otherwise, if the current jar is the target jar, link it
+ if [[ -z ${record_jar} ]]; then
+ if [[ -z ${build_only} ]]; then
+ java-pkg_record-jar_ ${target_pkg}
${jar}
+ else
+ java-pkg_record-jar_ --build-only
${target_pkg} ${jar}
+ fi
+ fi
+ # otherwise, if the current jar is the target jar, link
it
elif [[ ${jar_name} == ${target_jar} ]] ; then
[[ -f ${destjar} ]] rm ${destjar}
ln -snf ${jar} ${destjar} \
|| die Failed to make symlink from ${jar} to
${destjar}
- [[ -z ${build_only} ]] java-pkg_record-jar_
${target_pkg} ${jar}
+ if [[ -z ${record_jar} ]]; then
+ if [[ -z ${build_only} ]]; then
+ java-pkg_record-jar_ ${target_pkg}
${jar}
+ else
+ java-pkg_record-jar_ --build-only
${target_jar} ${jar}
+ fi
+ fi
popd /dev/null
return 0
fi
@@ -1035,12 +1048,13 @@
java-pkg_ensure-dep ${build_only} ${pkg}
done
- # Only record jars that aren't build-only
- if [[ -z ${build_only} ]]; then
- for pkg in ${pkgs//,/ }; do
+ for pkg in ${pkgs//,/ }; do
+ if [[ -z ${build_only} ]]; then
java-pkg_record-jar_ ${pkg}
- done
- fi
+ else
+ java-pkg_record-jar_ --build-only ${pkg}
+
[gentoo-dev] Patch to remove JAVA_PKG_VNEED support from java-utils-2.eclass
This patch removes the functionality within java-utils-2.eclass to
record and pass to java-config old style virtuals.
This functionality is not utilized within any repo that I know about and
is _most probably_ horribly broken anyway.
_ALL_ ebuilds that are using this functionality (aka 0) should instead
be using java-virtuals.
Java Team any issue with this patch? The point of removing this
functionality is so I can cleanup java-config a little.
Thanks
Alistair.
--- java-utils-2.eclass 2009-05-26 19:27:34.381359549 +1200
+++ java-utils-2.eclass 2009-05-31 16:52:09.823087313 +1200
@@ -1310,83 +1310,6 @@
#
--
#
--
-# @ebuild-function java-pkg_need
-#
-# Adds virtual dependencies, which can optionally be controlled by a USE flag.
-# Currently supported virtuals are:
-# javamail
-# jdbc-stdext
-# jaf
-# jdbc-rowset
-# jms
-#
-# @param $1 - Optionally indicate that the dependencies are controlled by
-# a use flag by specifying '--use' Requires $2.
-# @param $2 - USE flag which will enable the dependencies.
-# @param $@ - virtual packages to add depenedencies for
-#
--
-# TODO rewrite to parse a line based declaration file instead -- karltk
-#java-pkg_need() {
-# debug-print-function ${FUNCNAME} $*
-# local useflag
-# if [[ ${1} == --use ]]; then
-# useflag=${2}
-# shift 2
-# fi
-#
-# if [[ -z ${1} ]]; then
-# die Must specify at least one virtual package.
-# fi
-#
-# local depstr newdepstr
-#
-# for virtual in $...@}; do
-# if has ${virtual} ${JAVA_PKG_VNEED}; then
-# debug-print Already registered virtual ${virtual}
-# continue
-# fi
-# case ${virtual} in
-# javamail)
-# debug-print java-pkg_need: adding javamail
dependencies
-# newdepstr=|| ( dev-java/gnu-javamail
dev-java/sun-javamail-bin )
-# ;;
-# jdbc-stdext)
-# debug-print java-pkg_need: adding jdbc-stdext
dependencies
-# newdepstr=|| ( =virtual/jdk-1.4
dev-java/jdbc2-stdext )
-# ;;
-# jaf)
-# debug-print java-pkg_need: adding jaf
dependencies
-# newdepstr=|| ( dev-java/gnu-jaf
dev-java/sun-jaf-bin )
-# ;;
-# jdbc-rowset)
-# debug-print java-pkg_need: adding jdbc-rowset
dependencies
-# newdepstr=|| ( =virtual/jdk-1.5
dev-java/sun-jdbc-rowset )
-# ;;
-# jms)
-# debug-print java-pkg_need: adding jms
dependencies
-# newdepstr=|| ( dev-java/sun-jms
dev-java/openjms )
-# ;;
-# *)
-# die Invalid virtual: ${virtual}
-# esac
-#
-# export JAVA_PKG_VNEED=${JAVA_PKG_VNEED} ${virtual}
-#
-# if [[ -n ${useflag} ]]; then
-# depstr=${depstr} ${useflag}? ( ${newdepstr} )
-# else
-# depstr=${depstr} ${newdepstr}
-# fi
-# done
-#
-# [[ -z ${JAVA_PKG_NV_DEPEND} ]] export JAVA_PKG_NV_DEPEND=${DEPEND}
-# [[ -z ${JAVA_PKG_NV_RDEPEND} ]] export
JAVA_PKG_NV_RDEPEND=${RDEPEND}
-#
-# export DEPEND=${DEPEND} ${depstr}
-# export RDEPEND=${RDEPEND} ${depstr}
-#}
-
-#
--
# @ebuild-function java-pkg_find-normal-jars
#
# Find the files with suffix .jar file in the given directory or $WORKDIR
@@ -2541,16 +2464,11 @@
export GENTOO_VM=${JAVA_PKG_FORCE_VM}
# if we're allowed to switch the vm...
elif [[ ${JAVA_PKG_ALLOW_VM_CHANGE} == yes ]]; then
- debug-print depend-java-query: NV_DEPEND:
${JAVA_PKG_NV_DEPEND:-${DEPEND}} VNEED: ${JAVA_PKG_VNEED}
- if [[ -n ${JAVA_PKG_VNEED} ]]; then
- GENTOO_VM=$(depend-java-query --need-virtual
${JAVA_PKG_VNEED} --get-vm ${JAVA_PKG_NV_DEPEND:-${DEPEND}})
- else
- GENTOO_VM=$(depend-java-query --get-vm
${JAVA_PKG_NV_DEPEND:-${DEPEND}})
- fi
+ debug-print depend-java-query: NV_DEPEND:
${JAVA_PKG_NV_DEPEND:-${DEPEND}}
+ GENTOO_VM=$(depend-java-query
Re: [gentoo-dev] RFC: Gentoo Support Everywhere
Dale wrote: The Gentoo subforum on LQ would help to collect the posts in one place. That would be the point. Gentoo has its own forum so why have two forums? What would be the point in having two places to go look for answers? Better yet, why would Gentoo support both forums? I'm a member at LQ tho I haven't been there in a long while. I just don't see why there has to be two forums when the one forum we have is more than enough. If someone can't find the Gentoo forums, I'm not sure they can find the chair and keyboard either. lol How about we ask for a subforum to be created with a BIG STICKY telling it is better to ask support questions at forums.gentoo.org Could it be possible that users don't know about f.g.o? ( find it highly unlikely actually) Alistair
Re: [gentoo-dev] blocking mixed versions of split QT libraries
Alex Alexander wrote:
QT doesn't work well when mixed versions of its core libraries are
installed. Usually an emerge -avDu world solves the problem, but some
users tend to avoid this.
For example, lets say you have parts of QT 4.4.2 on your system. QT
4.5.1 is available and a user decides to manually update qt-core, or
to install KDE which has a QT dependency on a QT library not
installed. In these cases, portage will update only a part of the
installed QT libraries, leaving the system in a mixed state.
QT based apps don't like that. Others will refuse to build, others
will fail to run.
We've managed to experimentally block partial QT upgrades by adding an
RDEPEND to all QT libraries [1] in qting-edge overlay. Portage
understands this and throws out B blocks if you try to change versions
only in parts of QT, but upgrades/downgrades fine if you do them all
at once (or use -Du world).
This fix also catches stale QT libraries that nothing depends on
anymore because the user has removed whatever required them (and never
ran --depclean).
Unfortunately we've got reports from paludis users stating that they
can't update QT from qting-edge anymore.
From what I understand you are utilizing portages ability to
automagically resolve blockers when all blockers will be resolved within
the current command. Agree?? or is it the fact that you are doing
!x11-libs/qt-assistant-${PV}-r that is causing the paludis problem?
I would suggest that you just tell paludis users to use --dl-blocks
discard when updating qt. After looking at the eclass im not sure
whether it will work or not. im assuming that discarding blocks will
just ignore everything, but I haven't tested it so can't be sure.
What I'd like to discuss is the following:
1) Is there a saner way to achieve our goal of doing whatever is
possible to avoid mixed QT versions?
I don't believe so, not within current ways of declaring dependencies.
2) Is our implementation considered correct and acceptable by the PMS guys?
3) Whats the general Gentoo Policy on mixed versions? Do we care, or
is our policy please -Du world?
I say we should be stopping them from happening.
We've also managed to achieve the same thing by adding PDEPENDs to
each QT library for any other QT libraries that depend on it:
i.e. if qt-xmlpatterns depends on qt-gui, we add the following to qt-gui:
PDEPEND=
|| ( !x11-libs/qt-xmlpatterns ~x11-libs/qt-xmlpatterns-${PV} )
the above (expanded for all libraries) has the same effect as the [1]
RDEPEND but looks a bit more hackish.
And I would agree with the hackish comment.
thanks
Good work btw.
Alistair.
Re: [gentoo-dev] The fallacies of GLEP55
Ben de Groot wrote: Patrick Lauer wrote: For quite some time (over a year, actually) we've been discussing the mysterious and often misunderstood GLEP55. [http://www.gentoo.org/proj/en/glep/glep-0055.html] The proposed solution to a problem that is never refined, This, in my opinion, is the crux of the matter. Most of us apparently are not sufficiently convinced that there actually is a problem. Until the problem is explained with clarity, the rest of the proposal is useless. Obviously you don't understand the issue, because if you did you'd support it! I concur that speaking for myself, I don't understand the issue. And it looks like many others don't either. So if anyone wants to promote this GLEP, their job is clear: make people understand what the issue is here, and convince them it is actually an issue. (Examples, scenarios usually work well, indeed a lot better than calling people names.) Is it really necessary to convince the entire community for every GLEP? I thought that the reason we have the council is so they can make decisions. You know specialization of decision making. If the council is going to expect anyone else, besides themselves, to understand an issue then why have the council. And maybe we can now spend the same amount of council-time (it has been eating time for over a year!) to get important things done ... I want to call on the Council to reject this GLEP in its current form, as the problem has been insufficiently clarified. We should not waste more time on it. I would like the Council to either accept, reject or send the GLEP back to be clarified if _THEY_ believe it has been insufficiently clarified to enable _THEM_ to understand the GLEP. Cheers,
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild
You can't test FEATURES in an ebuild. It's portage-specific.
To 1) try and turn this thread into something a little more constructive
and a little less childish; and 2) help improve the tree. I present one
of the offending ebuilds dev-java/commons-io
Without posting the whole file here it is
src_test() {
if has userpriv ${FEATURES}; then
ANT_OPTS=-Djava.io.tmpdir=${T} -Duser.home=${T} \
ANT_TASKS=ant-junit \
eant test \
-Dgentoo.classpath=$(java-pkg_getjars junit) \
-Dlibdir=libdir \
-Djava.io.tmpdir=${T}
else
elog Tests fail unless userpriv is enabled because they
test for
elog file permissions which doesn't work when run as root.
fi
}
I would assume it would be better to directly test whether the user is
root, than test that userpriv is set?
Alistair
Re: [gentoo-dev] EAPI 3 PMS Draft
Ciaran McCreesh wrote: Unfortunately, it looks like this proposal's one of those things that some people will hate for ideological reasons no matter what. I just hope there're enough people on the Council for whom QA and user systems not breaking is sufficiently important that they'll vote in favour of it. While I support enabling test by default I'm about to do a foot in mouth moment and suggest something that is far too over complicated This is a compromise between those that want tests by default and those who don't and has these simple rules 1) Tests are enabled by default for ~arch ebuilds. 2) Tests are _not_ enabled by default for stable ebuilds. ~arch users will therefore have to explicitly disable tests and run the risks associated with that. My guess is that arch users are also the ones more likely to have CFLAGS or LDFLAGS that are significantly different from the defaults hopefully enabling tests will catch all the issues we know that are going to have. arch users will have to explicitly enable tests, but hopefully by the time a package has been marked stable it has had its unit tests ( oh im pointing that foot in mouth again ) run enough times to verify its correctness.
Re: [gentoo-dev] EAPI 3 PMS Draft
Mart Raudsepp wrote: Enabling tests by default feels like driving users away, because all of a sudden their upgrades taken even more time (possibly unexplained to them, as an EAPI bump in an ebuild introducing it is not visible to them), and they'd just say to hell with it and go to a binary distribution that runs the tests for maintainers only, as we should. Yet we have the _choice_ to take that extra time and double-check on maintainers if they really did their job right. I agree that before EAPI 3 hits the tree we need to do some extensive pr. There should be a howto on the changes and what they mean to users, the benefits and costs etc. How to enable/disable those changes etc etc. But in reality all we need is 1 document, links and news items (yes more than 1 preferably) posted on our homepage, forums, mailing lists. Hell even within ebuilds if it comes to that. If after all that a user still hasn't figured out that they need to go read that document are we really in a position where we can do anything else.
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Michael Haubenwallner wrote: Hi, Reminder (for myself): As long as we want/have to support PMs lacking EAPI detection in '*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI to an '*.ebuild' must be hackish. So we can try to find the least ugly hack, or we need to change the extension. So just another idea, based on the eapi() function one: As inherit() is the only(?) global function provided by old PMs, the first non-commentary/non-blank line in '*.ebuild' could read: inherit eapi Compliant PMs identify 'eapi' as a special eclass name (with or without sourcing the ebuild), to know that this ebuild specifies an EAPI. For non-compliant PMs, we need to provide an 'eapi.eclass', which just spits some 'your PM lacks EAPI support' message and causes the PM to mask this ebuild 'by corruption' or the like. Or - what are old PM's messages when an eclass is missing? Eventually, this line also could finally specify the EAPI and read: inherit eapi 4 Because non-compliant PM's already quit because of (missing or dying) eapi.eclass, there is no need to have a '4.eclass'. How would the 4.eclass determine whether the package manager actually supports the eapi? inherit is a function remember so any special parsing will not change the fact the the inherit function will be called. Will then need to determine whether there is actually a PM that doesn't support the eclasses EAPI and then die. What are the implications of calling inherit multiple times within an ebuild? Im sorry, but this just sounds like a HACK, and a hacky hack at that. /haubi/
Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
Nirbheek Chauhan wrote:
On Sat, Mar 7, 2009 at 3:20 PM, Ulrich Mueller u...@gentoo.org wrote:
On Fri, 06 Mar 2009, Donnie Berkholz wrote:
Any thoughts?
+ *)
+ die Unknown EAPI ${EAPI}
+ ;;
Is is safe to assume that an unknown EAPI will provide a die
function?
If we get all Ciaran-ey about that, then we can't even assume the
existence of a case statement in some future version of bash (which is
required by some EAPI)
I think in these cases we just have to use common sense. If a function
is deprecated or known to be 'on the way out' then using them would
obviously be a bad idea. On the other hand even if they are used,
surely someone would test an ebuild and discover this case pretty quickly.
Re: [gentoo-dev] Regen2 ( was QA Overlay Layout support )
Caleb Cushing wrote: I'd like to start with, I'm not trying to stir up trouble but since questions were asked i'll answer them. If you think neither should exist why do you have an opinion about this at all? I merged the java-overlay into regen2 a couple of weeks ago. as of right now I've no plans to support java-experimental. Please don't. Until less than a month ago, it was a qa nightmare ( even java-overlay was). Im sure both overlays probably still have unresolvable dependencies. And yes they are an example of piss poor qa standards. Even now im sure there is stuff in java-overlay that is be just plain broken. I would hate to think about what java-experimental is like.
Re: [gentoo-dev] QA Overlay Layout support.
Donnie Berkholz wrote: On 11:59 Sun 25 Jan , Alistair Bush wrote: Possible Solution: Merging java-overlay and java-experimental. From my perspective this isn't a good one as we loss most of the benefits of java-experimental. Combine this with package.mask. To me, experimental means masked. Experimental within java means a lot of things, or at least it should. Anything from user contributed and non-dev qa'd to packages with bundled jars to attempts to package projects like maven which are difficult and time consuming ( and which attempts to do so have failed numerous times before might I add ). Asking non-dev contributors to handle package.mask's would be a less than ideal. Resulting in interesting breakages. Currently by adding java-experimental ( which might I add isn't available thru layman ) you are accepting that risk. At least java and kde have need of this, and I could imagine sunrise could also use this ( either now or in the future ). I have implemented a patch [1] tho support this from a repoman perspective but believe its benefits could go much further. Eventually I hope that zmedico will accept it, once he has a chance to consider it and I have time to clean it up. Once repository support is implemented (this is very much depending on the details of the implementation) I will start making a patch to will have portage check whether an overlays parents are before that overlay. ali_bush [1] http://dev.gentoo.org/~ali_bush/portage_parent_repo_support.patch
Re: [gentoo-dev] QA Overlay Layout support.
Donnie Berkholz wrote: On 19:18 Mon 02 Mar , Alistair Bush wrote: Donnie Berkholz wrote: Could you explain what you see as the important difference that makes package.mask bad and a separate overlay good? Contributors sometimes have difficulty following standards (hell even dev's do). I have little confidence that would also be able to actually add packages to package.mask without breaking anything else. As an example we had a contributor break the manifests of a dozen or so packages because he updated the Copyright header then couldn't get the ebuild to manifest. I can imagine someone committing dev-java/ant-core to the file. That and there are 325 ebuilds [1] in java-experimental. Masking even 1/2 of them separately would be a complete nightmare. I also note that sunrise doesn't seem to do this either. Also no ebuilds are ever marked stable, so it should be easy for someone to just add an entry in their package.keywords file. And what is stopping a user from wanting to have their own overlay, that uses java-overlay ( or java-experimental or any other overlay ) packages. Are we to say that we shouldn't allow tools to have support for this. I think that it is a nature progression that if we are to allow overlays to extend the portage tree that we should allow overlays to extend other overlays. [1] java-experimental $ find . -iname '*.ebuild' | wc -l
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Petteri Räty wrote: Let's try something new. I would like to get opinions from as many people as possible about GLEP 55 and alternatives listed here in order to get some idea what the general developer pool thinks. Everyone is only allowed to post a single reply to this thread in order to make it easy to read through. The existing thread should be used for actual discussion about the GLEP and the alternatives. This should be a useful experiment to see if we can control ourselves :) Thank you Petteri. I knew there was a reason I voted for you. 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage b) .eapi.ebuild - current Portage does not work with this c) .eapi.new extension - ignored by current Portage a) then c). I personally think b) is a bad idea that will just slow the implementation of this even more. 3) EAPI in locked down place in the ebuild - Allows changing global scope - EAPI can't be changed in an existing ebuild so the PM can trust the value in the cache - Does not allow changing versioning rules unless version becomes a normal metadata variable * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked a) new extension b) new subdirectory like ebuilds/ - we could drop extension all together so don't have to argue about it any more - more directory reads to get the list of ebuilds in a repository c) .ebuild in current directory - needs one year wait If it really comes to it b)? Tho it leaves a bad taste in my mouth. Regards, Petteri
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Luca Barbato wrote: Luca Barbato wrote: Ciaran McCreesh wrote: Because your proposal addresses none of the underlying problems which GLEP 55 was created to solve. let's get some numbers to have an idea of the dimension of the problem. I just don't think those numbers tell us anything and that should be obvious from anyone who has read GLEP 55[1], we ain't really attempting to solve a problem that exists within the tree currently (well the bash issue does, in a way ). We are trying to solve issues that ware stopping the tree moving forward. Lets evaluate GLEP 55 in the problems it is attempting to solve. [1] Problem The current way of specifying the EAPI in ebuilds is flawed. In order to get the EAPI the package manager needs to source the ebuild, which itself needs the EAPI in the first place. Otherwise it imposes a serious limitation, namely every ebuild, using any of the future EAPIs, will have to be source'able by old package managers and hence there is no way to do any of the following: * Change the behaviour of inherit in any way (for example, to extend or change eclass functionality). * Add new global scope functions in any sane way. * Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1].
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
George Shapovalov wrote: (Ok this thread grew too long, so I gotta chime in :)) We could start using extended attributes or mandate reiser4 for portage dir or some other special in between (the inside of file and its name) feature.. No. 1) I wouldn't use reiser4 so that would be the end of that. 2) how well do rsync and cvs support xattr's. How about linux support verses bsd, or windows even. 3) It is just a bad solution Sorry for the noise and insane implementation suggestion :).. At least you realise it :)
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Luca Barbato wrote: Alistair Bush wrote: I just don't think those numbers tell us anything and that should be obvious from anyone who has read GLEP 55[1], we ain't really attempting to solve a problem that exists within the tree currently (well the bash issue does, in a way ). We are trying to solve issues that ware stopping the tree moving forward. Lets evaluate GLEP 55 in the problems it is attempting to solve. I'm afraid you missed the whole point... - what is in the proposal is a solution looking for a problem: nobody updated the glep with the required sections, nobody put up a list of bugs/rfe from bugzilla it helps to solve. Vague leading to the future change declaration aren't what I'd expect. So im mean't to start committing ebuilds into the tree that expect a certain unimplemented functionality, only to file bugs against portage for it not supporting them? Or can we be smart enough to realise that there are limitation to the current standard and then attempt to fix them before they become a problem. Plus we already know of at least one case where we will encounter a problem in the future, why? because we have already. Not sure if there is a open bug about it tho. This actually eats at me, your basically saying GLEP's should only be reactive. Why don't we all just roll over and die. - Assuming there is an actual reason to move forward (by digging bugzilla yourself or deciding to do so as academic exercise) you could think about the problem and its solutions (my the email starting this thread on dev) I have already considered the problems, and believe GLEP 55 is the **best** solution to them. Is it perfect, no. But I have yet to see anything better. - Given all you need is just to have a way to get the information about EAPI before you actually parse the ebuild since the eapi defines how you parse it, you can come up with various solutions, the simplest being first extract the eapi, being it in a fixed place, and then do the parse. Yes exactly, you need to know the EAPI before you __parse__ the ebuild. At least we agree that nothing should have to read the contents of the file to determine EAPI (doing so would be parsing now wouldn't it). So seeing that we agree with that, where should we stick the EAPI. m 1) How about in a flat txt file: That would become a developers nightmare. 2) In an xml file. Package managers would have to support xml. Not the best thing in the world. also could be a nightmare, adding an entry for every ebuild. 3) As an xattr. Well this idea is novel. I bet it would make the tree nice and stable too. Lets not forget how annoying it will be for devs. 4) Parsing the ebuild. But what are we parsing?, lets not limit ourselves to bash, we might want to change languages completely. If it is bash, what version, what if EAPI is set multiple times, what if its set in an eclass. 5) M...On the file name sounds like a good idea. especially as an extension. provides information to a package manager, person, script/program without them needing to open anything. identifies the contents just like .txt, .c, .o, .jpeg, etc - Extracting such information could have different costs depending on where to place it. I believe it being on the filename would be the least costly, in terms of processor/io at least.
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Tiziano Müller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Doesn't that just add extra complexity for no gain. Personally I don't see what the problem is with simply implementing GLEP-55. It's the best solution. It should be pretty simple to implement too. Certainly it wouldn't be anymore difficult to implement than your solution. Maybe once zmedico finishes his latest development push I will attempt to implement it.
[gentoo-portage-dev] repoman Parent repository support patch
it was suggested to me that I should post my patch to this ml. So here it is. Located at http://dev.gentoo.org/~ali_bush/portage_parent_repo_support.patch you will find a patch for repoman to support a hierarchy of overlays by allowing an overlay to specify its parents. I have recently been using this patch over java-experimental to solve the absolute mess we have created there. I would like to thank zmedico for the help he has given me on this. Thinks to note/discuss. An overlays parents are specified as a space separated list of pkg_names, with a key of masters, located with a file metadata/layout.conf. eg masters = gentoo java-overlay gentoo is implied and assumed so is not necessary ( and is actually filtered out within the code as it isn't an overlay). The reason I have this is to maintain compatibility with other package managers and because being explicit is a good thing. If we were to change this then it would be sensible to also change the file name. Other package managers also store other variables within this file. I propose that they are just ignored. I have not currently implemented the validation classes that can be used by KeyValuePairFileLoader.
[gentoo-dev] QA Overlay Layout support.
Here is an issue that is currently being faced by the java project that
I would like to bring to the attention of everyone. I have already
discussed this will devs from all pm's.
Intro:
Within the java project we have 2 overlays. java-overlay and
java-experimental. java-overlay is mean't to be a stable overlay, is
available through layman while java-experimental is the opposite. We
attempt to not add packages to gentoo unless they are a dependency or an
application to help with maintainability. We allow newbies access to
java-experimental and there are a number of packages that are difficult
to support so are still very much experimental.
The way we are currently using the overlays results in a hierachy of
gentoo java-overlay java-experimental. Where
packages/eclasses/profiles can be inherited from the previous repository.
Problem:
Repoman currently only checks the current repository/overlay and gentoo.
This is a problem for java-experimental.
These are the following problems:-
1) repoman does not find eclasses used to by java-experimental ebuilds
that are located in java-overlay. see [1] for error. Maintaining the
eclass in multiple locations _is not a solution_.(zmedico is expecting
to add repository support at some point with support for specifying
ECLASSDIRS. So this issue may be resolved).
2) repoman does not find packages used to by java-experimental ebuilds
that are located in java-overlay.
Now this might be a result of the package not existing within gentoo or
as a result of a particular version/slot being available within
java-overlay. Now zmedico suggested that the use of repository deps (
aka ::java-overlay ) could be the solution. I would rather this not be
the solution as packages shouldn't need to be edited to more them
between overlays. Also the dependency specified could be moved into gentoo.
Possible Solution:
Now im going to shoot myself in the foot here by mentioning the
unmentionable.
( -- ) paludis ( -- ) currently has support for specifying an
overlays parent(s) (master_repository) within an overlays
metadata/layout.conf file. Now i'm not suggesting that paludis's
implementation is the correct one, but I believe the concept is solid.
By specifying an overlays parent repositories would allow (at least):
1) emerge to error if that repository/overlay is not configured.; and
2) repoman to locate packages by checking the current overlay, gentoo as
well as the parents specified within an overlay metadata file
Possible Solution:
Merging java-overlay and java-experimental. From my perspective this
isn't a good one as we loss most of the benefits of java-experimental.
Discussion:
Do you support the overlay metadata file concept?
Are there any other possible solutions?
Is there anything stopping this from being implemented? another EAPI?
profile EAPI?
Is there anything else that would benefit from an overlay metadata
file? Default conf variables e.g ECLASSDIRS.
Any other comments?
Thanks
ali_bush
Alistair Bush
Gentoo Linux Developer
[1]
* ERROR: dev-java/commons-jelly-tags-util-1.0 failed.
* Call stack:
*ebuild.sh, line 1881: Called source
'/home/alistair/gentoo/overlays/java-experimental/dev-java/commons-jelly-tags-util/commons-jelly-tags-util-1.0.ebuild'
* commons-jelly-tags-util-1.0.ebuild, line7: Called inherit
'commons-jelly-tags-2'
*ebuild.sh, line 1238: Called qa_source
'/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass'
*ebuild.sh, line 37: Called source
'/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass'
* commons-jelly-tags-2.eclass, line 30: Called inherit
'java-pkg-2' 'java-ant-2' 'java-maven-2'
*ebuild.sh, line 1215: Called die
* The specific snippet of code:
* [ ! -e $location ] die ${1}.eclass could not be
found by inherit()
* The die message:
* java-maven-2.eclass could not be found by inherit()
*
* If you need support, post the topmost build error, and the call stack
if relevant.
* This ebuild used the following eclasses from overlays:
*
/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass
*
/home/alistair/gentoo/overlays/java-experimental/eclass/java-pkg-2.eclass
*
/home/alistair/gentoo/overlays/java-experimental/eclass/java-utils-2.eclass
* This ebuild is from an overlay:
'/home/alistair/gentoo/overlays/java-experimental/'
[2]
dev-java/glazedlists/glazedlists-1.7.0-r2.ebuild:
~amd64(default/linux/amd64/2008.0/server) ['dev-java/swingx']
dev-java/swingx is located in java-overlay.
Re: [gentoo-dev] QEMU Sick!
Dale wrote: I don't think Gentoo is broke. It may be a wrong setting or something misconfigured on your system but Gentoo works. I really think you need to take this to -user tho. This thread really needs to be there instead of on -dev. Dale :-) :-) This thread doesn't need to be anywhere. Talk about the wrong approach to solving a problem. Just let this die. There are much more constructive ways of improving Gentoo. Please take full advantage of bugs.gentoo.org, our forums and irc channels. Constructive suggestions/patches/improvements can also be brought up either within gentoo-dev ml or another project specific ml. Alistair
Re: [gentoo-dev] reorganization of /var/lib gentoo-related files
Maciej Mrozowski wrote: On Wednesday 31 of December 2008 17:28:09 Ciaran McCreesh wrote: You could use the same argument to say Gentoo must switch to RPM because LSB says so. No, I would be invalid argumentation - I know it - you know it, so let's not continue with discussion of this kind until one side will EOT seeing it's pointless, while the other side will secretly announce epic victory ;) I actually agreed with Ciaran on this point. especially seeing I would like us to follow the parts of LSB that make sense within the Gentoo ecosystem. (take Init Script Actions as an possible example http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html). It's not the point to blindly follow freedesktop or LSB - the point is to consistently follow one standard across whole distribution - if it's FHS - fine, if not - fine as well - but *only one* at a time. That being said I'd rather propose to force Gentoo news to comply to FHS as FHS is the most commonly used file/directory layout in Gentoo. This really is bikeshedding.. Isn't consistently following a standard also blindly following it. So when you ask us to consistently follow FHS why not ask for us to blindly follow it. Man this is getting boring. cheers in new year
Re: [gentoo-dev] Keyword policy for non standard things
Dawid Węgliński wrote: Hello fellow developers and users. I'd like to know your opinion of bug #243050 [1] 01:18:59 cla @| If user bothers to patch his kernel, he can bother to add proper package.keyword line, imo. ++ 01:21:52 hparker @| Or maybe get the patches added to gentoo-sources or ++ maybe we can get the pm's to implement this as EAPI=999,999,999.99 I suggest a syntax of virtual/kernel:::user_patched On a more serious note, How can we confirm a package is stable when we can't confirm the kernel it depends on is? I would have no problem with gentoo-sources also including a use flag(s) ( or not ) and having it add patches to support software we have within the tree. I have no say in that tho. Alistair
[gentoo-dev] changing EAPI on existing ebuilds. To bump or not?
I was thinking about this a day or 2 ago and just noticed that a similar situation has come up. Please refer to https://bugs.gentoo.org/show_bug.cgi?id=239006 but basically. =dev-java/ant-antlr-1.7.1 was changed from EAPI=1 to EAPI=2 to take advantage of the use flag dep functionality. now, I normally take the approach that if the change I am making to an ebuild effects the installed files then I bump. But what is the best thing to do here. Some things to note is that this ebuild is ~arch and EAPI=2 is also ~arch. Obviously if the ebuild was arch then changing to a ~arch EAPI would be a no-no. Are there any other situations which are definite no-no's? Anyway, would be nice to get some feedback, idea's on this and hopefully also a more detailed explaination from a pm's perspective (if there is one). Thanks. Alistair ps. If changing EAPI is bad then maybe repoman should check for it.
Re: [gentoo-dev] EAPI-2 - Let's get it started
Patrick Lauer wrote: On Tuesday 10 June 2008 16:54:49 Richard Brown wrote: On Tue, Jun 10, 2008 at 17:39, Doug Goldstein [EMAIL PROTECTED] wrote: At this point, we should really only discuss features that all 3 package managers have implemented. I'm not sure that's a good idea, only two have implemented EAPI 1 so far. Yes, but noone cares about Paludis. Now could you please do the rest of us a favour and keep the discussion focussed on improving technical details instead of random insults at others? Isn't that, in itself, an insult and you don't seem to have advanced the discussion at all. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Piotr Jaroszyński wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 2. GLEP55 3. Most wanted changes in future EAPIs 4. Strategies to ensure that gentoo's package manager is able to quickly/smartly/sainly support future EAPI's, GLEP54, GLEP55? [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Removing .la files...
Wulf C. Krueger wrote: Hello! I think flameeyes should have sent this himself in the first place, but since he's clearly not going to do that and prefers to just force it on our users I'm mailing this... Have we not learn't! I hardly think that revdep-rebuild is an obvious solution to this issue. So now we have doomed our users ( and some of our dev's ) to having to search for a solution. I note that within the ebuild there isn't even a elog explaining what to do. If we are going to make changes like this we need to provide an effective news service. I'm sure this was one of the issues that arose during the hot house months. I actually find this incident rather depressing. especially after we (seem to) have done so well with the baselayout/openrc migration. ( I do realise that one is significantly bigger than the other and therefore requires a bigger fan fair ). flameeyes talked about .la files in his blog recently: http://blog.flameeyes.eu/articles/2008/04/14/what-about-those-la-files Im sure everyone will find that Now he decided that simply removing them for several packages, resulting in http://bugs.gentoo.org/show_bug.cgi?id=218286 and its dupes. What a surprise. never could have guessed. This is annoying for quite a few users as they will have to rebuild lots of stuff for KDE, Gnome and other packages and I'm not sure if this is really the way we want to fix --as-needed failures. ++. We sure do like to annoy our users. Furthermore, such things should not be decided and pushed through unilaterally but be agreed upon here prior to doing this change. ++. I actually have no problem with agreeing with it, currently my problem is the complete and utter lack of any _planned_ upgrade path. What do we think users are going to be saying at the end of the year when after every sync they have to revdep-rebuild. Maybe, if we proceed with this, we investigate what can have its la files removed and do it all in one go. therefore ppl won't have to rebuild kde/gnome ( or any other large and time consuming package) over and over and over and over and over and over ... again. Hell it would even be better to batch a few conversions so that each revdep-rebuild fixes multiple breakages in one. Especially since even though removing .la files might make sense (with exceptions, of course) we should think about either doing it distribution-wide or not at all. ++ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Strange behavior of fonts... help :(
This is not a support channel and that, while an interesting picture, provides absolutely no information whatsoever. Please don't post to the gentoo-dev ml. Alistair. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
Tiziano Müller wrote:
Current state: Deferred
Wanted state: Accepted/Implemented (at least by me)
Open questions from last discussion (March 2006):
- Is it possible/should it be possible to have more than one maintainer
entry?
Yes
- Is recording an upstream-status (active/inactive) a good idea?
Maybe, leaning to No.
What about packages that have multiple slots, e.g php-4, php-5? one
slot could be inactive the other not, does that make upstream active?
Possibilities:
An element: status{active/inactive}/status
Status of what? seeing you have proposed a upstream-status and a
maintainer status. what else is there left to status :P
An attribute: maintainer status={active/inactive}...
No. As i'm pretty sure that every inactive maintainer won't go around
updating their packages metadata.xml
- Is an additional doc element needed to link to upstream docs
Interesting. what about the situation where upstream documentation sucks
but there is a better resource provided by a third party, could we
link to that? e.g. http://tldp.org for bash is an excellent resource
Multiple doc links?
docsofficial-doc/official-doc/doc/doc//docs could provide
that. Only concern I see is that this could relate to an endorsement of
thirdparty websites, which may change negatively ( porn on tldp.org ) or
my just become outdated.
Actually without the multiple official/unofficial doc tags I would have
to say No. as 99% of the time it would just be ${HOMEPAGE}/doc or
there would be a big fat link from the homepage and therefore would be
of no real benefit.
Alistair
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] New eclass osgi.eclass
On behalf of Elvanor ( a in the process New Developer ) I would like to
present the osgi.eclass.
What is OSGi, well
Copied directly from wikipedia [1]
The Framework implements a complete and dynamic component model,
something that is missing in standalone Java/VM environments.
Applications or components (coming in the form of bundles for
deployment) can be remotely installed, started, stopped, updated and
uninstalled without requiring a reboot; management of Java
packages/classes is specified in great detail. Life cycle management is
done via APIs which allow for remote downloading of management policies.
The service registry allows bundles to detect the addition of new
services, or the removal of services, and adapt accordingly.
Basically and for all the purposes that you will care about, the eclass
adds information to a jar's Manifest file that can then be used by the
OSGi framework ( aka currently eclipse ). Without this functionality we
will not be able to use system jars for our eclipse package.
you may find an example ebuild that uses the osgi class at
http://overlays.gentoo.org/svn/proj/java/java-experimental/dev-java/swt/swt-3.3-r1.ebuild
and the eclass is attached and located at
http://overlays.gentoo.org/svn/proj/java/java-experimental/eclass/osgi.eclass
Im sure Elvanor can't wait for you constructive feedback on his eclass
and depending on your feedback the eclass will enter the tree this weekend.
ali_bush
[1] http://en.wikipedia.org/wiki/OSGi
# Base eclass for Java packages that needs to be OSGi compliant
#
# Copyright (c) 2007, Jean-Noël Rivasseau [EMAIL PROTECTED]
# Copyright (c) 2007, Gentoo Foundation
#
# Licensed under the GNU General Public License, v2
#
# $Header: /var/cvsroot/gentoo-x86/eclass/java-utils-2.eclass,v 1.92 2007/08/05
08:17:05 betelgeuse Exp $
# -
# @eclass-begin
# @eclass-shortdesc Java OSGi eclass
# @eclass-maintainer [EMAIL PROTECTED]
#
# This eclass provides functionality which is used by
# packages that need to be OSGi compliant. This means
# that the generated jars will have special headers in their manifests.
# Currently this is used only by Eclipse-3.3 - later
# we could extend this so that Gentoo Java system would be
# fully OSGi compliant.
#
# -
inherit java-utils-2
# We define _OSGI_T so that it does not contain a slash at the end.
# According to Paludis guys, there is currently a proposal for EAPIs that
# would require all variables to end with a slash.
_OSGI_T=${T/%\//}
# -
# @ebuild-function _java-pkg_osgi-plugin
#
# This is an internal function, not to be called directly.
#
# @example
# _java-pkg_osgi-plugin JSch
#
# @param $1 - bundle name
#
# --
_java-pkg_osgi-plugin() {
# We hardcode Gentoo as the vendor name
cat ${_OSGI_T}/tmp_jar/plugin.properties -EOF
bundleName=${1}
vendorName=Gentoo
EOF
}
# -
# @ebuild-function _java-pkg_osgijar
#
# This is an internal function, not to be called directly.
#
# @example
# _java-pkg_osgijar dist/${PN}.jar com.jcraft.jsch com.jcraft.jsch,
com.jcraft.jsch.jce;x-internal:=true JSch
#
# @param $1 - name of jar to repackage with OSGi
# @param $2 - bundle symbolic name
# @param $3 - export-package-header
# @param $4 - bundle name
#
# --
_java-pkg_osgijar() {
debug-print-function ${FUNCNAME} $*
[[ ${#} -lt 4 ]] die At least four arguments needed
mkdir ${_OSGI_T}/tmp_jar || die Unable to create directory
${_OSGI_T}/tmp_jar
[[ -d ${_OSGI_T}/osgi ]] || mkdir ${_OSGI_T}/osgi || die Unable to
create directory ${_OSGI_T}/osgi
local jar_name=$(basename $1)
cp $1 ${_OSGI_T}/tmp_jar pushd ${_OSGI_T}/tmp_jar /dev/null
jar xf ${jar_name} rm ${jar_name} popd /dev/null || die
Unable to uncompress correctly the original jar
cat ${_OSGI_T}/tmp_jar/META-INF/MANIFEST.MF -EOF
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %bundleName
Bundle-Vendor: %vendorName
Bundle-Localization: plugin
Bundle-SymbolicName: ${2}
Bundle-Version: ${PV}
Export-Package: ${3}
EOF
_java-pkg_osgi-plugin ${4}
jar cfm ${_OSGI_T}/osgi/${jar_name}
${_OSGI_T}/tmp_jar/META-INF/MANIFEST.MF \
-C ${_OSGI_T}/tmp_jar/ . /dev/null || die Unable to
recreate the OSGi compliant jar
rm -rf ${_OSGI_T}/tmp_jar
}
# -
# @ebuild-function java-pkg_doosgijar
#
# Rewrites a jar, and
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/gnome-python-extras: ChangeLog gnome-python-extras-2.19.1-r1.ebuild
On 13:25 Fri 12 Oct , Remi Cardona (remi) wrote:
1.1
dev-python/gnome-python-extras/gnome-python-extras-2.19.1-r1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/gnome-python-extras/gnome-python-extras-2.19.1-r1.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/gnome-python-extras/gnome-python-extras-2.19.1-r1.ebuild?rev=1.1content-type=text/plain
pkg_postinst() {
python_version
python_mod_optimize
${ROOT}usr/$(get_libdir)/python${PYVER}/site-packages/gtk-2.0
}
pkg_postrm() {
python_version
python_mod_cleanup
${ROOT}usr/$(get_libdir)/python${PYVER}/site-packages/gtk-2.0
}
While you guys are on this subject, I thought I would put in the
experience I just had.
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-java/java-config/java-config-2.1.2.ebuild?rev=1.1view=markup
As you will note in the ebuild above I inherit distutils and then
declare
PYTHON_MODNAME=java_config_2
and have my 2 functions as so
pkg_postrm() {
distutils_python_version
distutils_pkg_postrm
}
pkg_postinst() {
distutils_pkg_postinst
...
...
}
Firstly it is interesting to note that you must call *python_version
before distutils_pkg_postrm while distutils_pkg_postinst handles this
itself.
Is this a good solution? Would it also be a good solution in your case?
PYTHON_MODNAME from my understanding what i've investigated will accept
a list of modules if you need it to.
Anyway, hopefully this helps.
Alistair.
ps. My python experience has not left the realm of java-config and I
have only done 2 releases, 1 1/2 of which I completely screwed up. I am
no expert and have no idea whether the above is correct, valid or
otherwise safe for human consumption. Don't complain!!
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: java-utils-2.eclass java-virtuals-2.eclass
Yes it is cool, and the eclass will be updated.
Thank you dberkholz
Duncan wrote:
Donnie Berkholz [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Thu, 04 Oct 2007
19:00:02 -0700:
You can use a neat trick with a code block here, along these lines:
{
echo foo
echo bar
echo blah
} file
It avoids the possibility of a typo when you're retyping the same
filename multiple times, plus it's just cool.
Wow, that /is/ cool! Learned something new today! =8^)
You are putting an awful lot of work into these lookovers. Just some
thanks from this user, in case you haven't heard enough of it lately.
Gentoo's surely the better for it! =8^)
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] New eclass to support java-virtuals
I would like to commit a new java eclass within the next week.
This eclass is designed to support the functionality that Betelgeuse
outlined within a previous post.[1]
As you will be able to see, this eclass is very simple and only uses
functionality that will be provided by the java-utils-2.eclass (see the
attached patch )
Basically all the happens is that a file is created under
/usr/share/java-config-2/virtuals/
that contains (at present) 3 variables. This file is then read by our
java-config-2 application.
The eclass is currently implemented within the java-virtuals overlay for
those who are interested
https://overlays.gentoo.org/svn/proj/java/java-virtuals/
Any suggestions, improvements and of course approvals will be gladly
accepted
Go the All Blacks!!
Alistair
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/48932/focus=48933
On Sun, 29 Apr 2007 17:00:09 +0200, Petteri Räty wrote:
We want to implement virtuals for Java at some point and for that we
need to know the package that provides the virtual because some virtuals
can be provided by the JDK or normal packages and this affects the JDK
selection at build time. One option is to call into Portage to find this
out, but of course Paludis and Pkgcore people most likely don't like
this approach. One thing that comes to mind is to allow for virtuals to
install files so we can install the provider information in a format
easy for us. We need the information in format ${PN}-${SLOT} because
that's the way we install in /usr/share. So do you think it's ok for
virtuals to install files (we can of course call the category
java-virtual/ too), should we call Portage code, or do you have an
another idea?
--- gentoo/cvs/gentoo-x86/eclass/java-utils-2.eclass2007-08-05
20:17:05.0 +1200
+++ gentoo/overlays/java-virtuals/eclass/java-utils-2.eclass2007-09-12
22:23:53.0 +1200
@@ -2196,6 +2286,8 @@
JAVA_PKG_SHAREPATH=${DESTTREE}/share/${JAVA_PKG_NAME}
JAVA_PKG_SOURCESPATH=${JAVA_PKG_SHAREPATH}/sources/
JAVA_PKG_ENV=${D}${JAVA_PKG_SHAREPATH}/package.env
+ JAVA_PKG_VIRTUALS_PATH=${DESTTREE}/share/java-config-2/virtuals
+
JAVA_PKG_VIRTUAL_PROVIDER=${D}/${JAVA_PKG_VIRTUALS_PATH}/${JAVA_PKG_NAME}
[[ -z ${JAVA_PKG_JARDEST} ]]
JAVA_PKG_JARDEST=${JAVA_PKG_SHAREPATH}/lib
[[ -z ${JAVA_PKG_LIBDEST} ]]
JAVA_PKG_LIBDEST=${DESTTREE}/$(get_libdir)/${JAVA_PKG_NAME}
@@ -2220,58 +2312,71 @@
java-pkg_do_write_() {
debug-print-function ${FUNCNAME} $*
java-pkg_init_paths_
- # Create directory for package.env
- dodir ${JAVA_PKG_SHAREPATH}
- if [[ -n ${JAVA_PKG_CLASSPATH} || -n ${JAVA_PKG_LIBRARY} || -f \
- ${JAVA_PKG_DEPEND_FILE} || -f \
- ${JAVA_PKG_OPTIONAL_DEPEND_FILE} ]]; then
- # Create package.env
- (
- echo DESCRIPTION=\${DESCRIPTION}\
- echo GENERATION=\2\
-
- [[ -n ${JAVA_PKG_CLASSPATH} ]] echo
CLASSPATH=\${JAVA_PKG_CLASSPATH}\
- [[ -n ${JAVA_PKG_LIBRARY} ]] echo
LIBRARY_PATH=\${JAVA_PKG_LIBRARY}\
- [[ -n ${JAVA_PROVIDE} ]] echo
PROVIDES=\${JAVA_PROVIDE}\
- [[ -f ${JAVA_PKG_DEPEND_FILE} ]] \
-echo DEPEND=\$(cat
${JAVA_PKG_DEPEND_FILE} | uniq | tr '\n' ':')\
- [[ -f ${JAVA_PKG_OPTIONAL_DEPEND_FILE} ]] \
-echo OPTIONAL_DEPEND=\$(cat
${JAVA_PKG_OPTIONAL_DEPEND_FILE} | uniq | tr '\n' ':')\
- echo VM=\$(echo ${RDEPEND} ${DEPEND} | sed -e 's/
/\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\ # TODO cleanup !
- ) ${JAVA_PKG_ENV}
-
- # register target/source
- local target=$(java-pkg_get-target)
- local source=$(java-pkg_get-source)
- [[ -n ${target} ]] echo TARGET=\${target}\
${JAVA_PKG_ENV}
- [[ -n ${source} ]] echo SOURCE=\${source}\
${JAVA_PKG_ENV}
-
- # register javadoc info
- [[ -n ${JAVADOC_PATH} ]] echo
JAVADOC_PATH=\${JAVADOC_PATH}\ \
-${JAVA_PKG_ENV}
- # register source archives
- [[ -n ${JAVA_SOURCES} ]] echo
JAVA_SOURCES=\${JAVA_SOURCES}\ \
-${JAVA_PKG_ENV}
-
-
- echo MERGE_VM=\${GENTOO_VM}\ ${JAVA_PKG_ENV}
- [[ -n ${GENTOO_COMPILER} ]] echo
MERGE_COMPILER=\${GENTOO_COMPILER}\ ${JAVA_PKG_ENV}
-
- # extra env variables
- if [[ -n ${JAVA_PKG_EXTRA_ENV_VARS} ]]; then
- cat ${JAVA_PKG_EXTRA_ENV} ${JAVA_PKG_ENV} || die
- # nested echo to remove leading/trailing spaces
- echo ENV_VARS=\$(echo ${JAVA_PKG_EXTRA_ENV_VARS})\ \
-${JAVA_PKG_ENV} || die
-
Re: [gentoo-dev] New eclass to support java-virtuals
Donnie Berkholz wrote:
On 23:20 Thu 20 Sep , Alistair Bush wrote:
-# Create package.env
-(
-echo DESCRIPTION=\${DESCRIPTION}\
-echo GENERATION=\2\
-
-[[ -n ${JAVA_PKG_CLASSPATH} ]] echo
CLASSPATH=\${JAVA_PKG_CLASSPATH}\
-[[ -n ${JAVA_PKG_LIBRARY} ]] echo
LIBRARY_PATH=\${JAVA_PKG_LIBRARY}\
-[[ -n ${JAVA_PROVIDE} ]] echo
PROVIDES=\${JAVA_PROVIDE}\
-[[ -f ${JAVA_PKG_DEPEND_FILE} ]] \
- echo DEPEND=\$(cat
${JAVA_PKG_DEPEND_FILE} | uniq | tr '\n' ':')\
-[[ -f ${JAVA_PKG_OPTIONAL_DEPEND_FILE} ]] \
- echo OPTIONAL_DEPEND=\$(cat
${JAVA_PKG_OPTIONAL_DEPEND_FILE} | uniq | tr '\n' ':')\
-echo VM=\$(echo ${RDEPEND} ${DEPEND} | sed -e 's/
/\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\ # TODO cleanup !
-) ${JAVA_PKG_ENV}
Why not use a code block {} instead of a subshell ()?
You would have to ask the original author about that, but point taken.
-# register target/source
-local target=$(java-pkg_get-target)
-local source=$(java-pkg_get-source)
-[[ -n ${target} ]] echo TARGET=\${target}\
${JAVA_PKG_ENV}
-[[ -n ${source} ]] echo SOURCE=\${source}\
${JAVA_PKG_ENV}
-
-# register javadoc info
-[[ -n ${JAVADOC_PATH} ]] echo
JAVADOC_PATH=\${JAVADOC_PATH}\ \
- ${JAVA_PKG_ENV}
-# register source archives
-[[ -n ${JAVA_SOURCES} ]] echo
JAVA_SOURCES=\${JAVA_SOURCES}\ \
- ${JAVA_PKG_ENV}
-
-
-echo MERGE_VM=\${GENTOO_VM}\ ${JAVA_PKG_ENV}
-[[ -n ${GENTOO_COMPILER} ]] echo
MERGE_COMPILER=\${GENTOO_COMPILER}\ ${JAVA_PKG_ENV}
I don't understand why all these things are done down here instead of in the
same code block as $JAVA_PKG_ENV is created.
That to is also historical, and i'm less inclined to changed it. I've
already broken the tree once with a eclass change, breaking this would
completely break java support. It could be updated as part of our
general QA, but I believe that it should be done separately, and not
bundled in with the changes i've made.
-# Strip unnecessary leading and trailing colons
-# TODO try to cleanup if possible
-sed -e s/=\:/=\/ -e s/:\$/\/ -i ${JAVA_PKG_ENV} ||
die Did you forget to call java_init ?
+
+if [[ $1 != provider ]]; then
Could you explain what the next section is supposed to do, as opposed to
the above section? Are they expected to be mutually exclusive? The
comments suggest so, since both have a 'Create package.env'. But the
tests suggest otherwise, since it's not an if...else pair.
normally java-pkg_do_write_ is called to write the package.env out, as
can be seen, and is the default behavior for the function. What I am
adding is the ability to _do_write of a [virtual|provider].env file.
While at present it only contains 3 variables, I see no reason why
eventually it will not include other vars that are shared between the
package.env and virtual.env ( e.g DESCRIPTION )
Therefore this change can be summarized as
+ if [[ $1 != provider ]]; then
#Do the default package.env behaviour
+ else
+ #Create a virtual.env file. This will only be invoked by
+ #ebuilds that inherit java-virtuals.eclass
+ fi
I could very well reflactor the java-pkg_do_write_ function back to its
current state and create a new function java-pkg_do_write_virtual to be
called by java-virtuals-2.eclass.
The documentation could (and will) be updated to more correctly reflect
whats happening.
+# Create directory for package.env
+dodir ${JAVA_PKG_SHAREPATH}
+if [[ -n ${JAVA_PKG_CLASSPATH} || -n ${JAVA_PKG_LIBRARY} ||
-f \
+${JAVA_PKG_DEPEND_FILE} || -f \
+${JAVA_PKG_OPTIONAL_DEPEND_FILE} ]]; then
+# Create package.env
+(
+echo DESCRIPTION=\${DESCRIPTION}\
+echo GENERATION=\2\
+
+[[ -n ${JAVA_PKG_CLASSPATH} ]] echo
CLASSPATH=\${JAVA_PKG_CLASSPATH}\
+[[ -n ${JAVA_PKG_LIBRARY} ]] echo
LIBRARY_PATH=\${JAVA_PKG_LIBRARY}\
+[[ -n ${JAVA_PROVIDE} ]] echo
PROVIDES=\${JAVA_PROVIDE}\
+[[ -f ${JAVA_PKG_DEPEND_FILE} ]] \
+ echo DEPEND=\$(cat
${JAVA_PKG_DEPEND_FILE} | uniq | tr '\n' ':')\
+[[ -f ${JAVA_PKG_OPTIONAL_DEPEND_FILE} ]] \
+ echo OPTIONAL_DEPEND=\$(cat
${JAVA_PKG_OPTIONAL_DEPEND_FILE} | uniq | tr '\n
Re: [gentoo-dev] New eclass to support java-virtuals
Donnie Berkholz wrote: On 06:58 Fri 21 Sep , Alistair Bush wrote: normally java-pkg_do_write_ is called to write the package.env out, as can be seen, and is the default behavior for the function. What I am adding is the ability to _do_write of a [virtual|provider].env file. While at present it only contains 3 variables, I see no reason why eventually it will not include other vars that are shared between the package.env and virtual.env ( e.g DESCRIPTION ) Therefore this change can be summarized as + if [[ $1 != provider ]]; then #Do the default package.env behaviour + else +#Create a virtual.env file. This will only be invoked by +#ebuilds that inherit java-virtuals.eclass + fi I could very well reflactor the java-pkg_do_write_ function back to its current state and create a new function java-pkg_do_write_virtual to be called by java-virtuals-2.eclass. The documentation could (and will) be updated to more correctly reflect whats happening. I'm concerned about code duplication, because that's what it looks like. Refactoring might be a good idea. Thanks, Donnie Ok, thanks for the input Donnie. I will refactor it before goes into the tree. Any more input ppl? Thanks Alistair -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] USE flag how are they supposed to work?
Firstly... From http://devmanual.gentoo.org/general-concepts/use-flags/index.html Local and Global USE Flags USE flags are categorised as either local or global. A global USE flag must satisfy several criteria: * It is used by many different packages. * It has a general non-specific purpose. The second point is important. If the effect of the thing USE flag upon pkg-one is substantially different from the effect it has upon pkg-two, then thing is not a suitable candidate for being made a global flag. In particular, note that if client and server USE flags are ever introduced, they can not be global USE flags for this reason. Before introducing a new global USE flag, it must be discussed on the gentoo-dev mailing list. Steen Eugen Poulsen wrote: I'm trying to write a Replicator for /etc/portage and that leads me to work with USE flags, trying to design the replication of them among similar systems, but I can't find the golden set of rules for how best to apply USE flags. There seem to be a global/local USE flag system, but many so called global flags has duplicated description marking them as local flags, or they enable unneeded optional support. Unneeded by whom? As for the duplicate local USE flags, They are most probably redundant. Lets take one of the big ones python. This use flag enables optional python support in many packages, I don't see my system ever using the python support in most of these. Seems like it really should be a local pr. packet flag for most, a pythonapi flag perhaps. See above. Also note that you are not enabling support for pythonapi, you are enabling support for python. Would you enable support for linuxheaders when you are without a linux kernel. There is also a few cases where package X requires package Y to be compiled with an USE flag, but no testing is being done in the ebuild for it and the compilation fails. Example gnome-system-tools requires libxml2 to be compiled with python support. If that is the case, then I would suggest you search bugzilla and then file a bug. Then there is flags like alsa, it's marked as a global flag and then virtualbox also has it marked as a local flag. I personally think virtualbox is somewhat right in saying it's a local flag, but perhaps it would be better if the flag didn't have a double meaning. See above. I can only assume that virtualbox doesn't need to have a local alsa use flag. As I see it, Gentoo's USE flag system is one of it's greatest strength, but at the moment seems like there is missing some overall design for how to implement USE flags, making it a lot harder to use USE flags, as there is no clear definition of global or local flags. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] USE flag how are they supposed to work?
Ok, so I think I understand where you are coming from... Firstly, USE flags are not meant to have a specific purpose. Enabling python support is non-specific as it doesn't describe how it is enabled or what python support actually is. Lets compare 2 packages to demonstrate... subversion has a python use flag, this flag will install a subversion api for python. so within python you an interact with subversion. as another example. vim also has a python use flag. this flag enables the ability to execute python commands from within vim. _But_ it is important to note that nowhere does the python use flag attempt to distinguish between the 2 types of support. This is where I believe you are getting stuck. The reason for having non-specific use flags is otherwise we would have hundreds of duplicate local use flags whose descriptions differ only slightly. We are not attempting to document all the functionality of each package. It is up to you to discover what packages you want to have python support. The words is given different meaning depending on whatever I'm looking at the portage tree or working on configuring emerge. The portage trees global flag, is no indication whatever I should put the flag in USE= in make.conf, in many cases a portage tree global flag is more an indication that I should use it locally pr. package. well I would only agree with that if you correlate the global status of a USE flag to the number of packages that use it and you are wanting to only enable the bare minimum use flags for the pacakges that you require. But anyway, in summary If you want to find out what a packages USE flag does, it is better to read the upstream documentation. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] My turn to wear the cursed medalion of retirement
Hi Alexandre. I too would like to hear what your ideas are for the metastructure of gentoo. Please if you dont feel up to officially submitting them then at least submit them to this list. Alistair On 3/19/07, Seemant Kulleen [EMAIL PROTECTED] wrote: Hi Alexandre, Good luck in your new life. My only comment is that I think you copped out by not submitting your proposals for any sort of peer review. You succumbed to the possibility (that you seem to think is more of a probability -- you may be right, I don't know) that it would not be received well. I think it's a shame to succumb to such a fear (or any fear), and I wish you hadn't. I do understand where you're coming from, however, and I tend to agree with most of your ideas on the addition of bureaucratic layers and rules regulations. I struggle with whether or not that's simply a necessary by-product of the size and scope (I use the term loosely) of the project. Thanks, Seemant
Re: [gentoo-dev] Suggestion
On Thursday 08 February 2007 10:38 pm, Jose San Leandro wrote:
Hi all,
A friend of mine and myself are willing to develop some tools to help
ebuild development.
We have some constraints, but we are thinking on something like:
1) A tool to ease writing ebuilds. It would take some parameters, i.e.:
1.1) Where are the sources?
1.2) Decompression algorithm?
1.3) Compile the sources?
1.4) Install man page(s)?
1.5) Install documentation?
1.6) Bind actions to USE flags?
It would probably be interesting to define a set of pre-defined categories:
standard GNU Autotools projects, perl/CPAN modules, python, ...
I see no reason why a good template and/or eclass can't handle this
2) A tool to deal with the unstandarized way to compile and install Java
projects. The idea is to write a tool to try to find out:
2.1) Where are located the main .java sources.
2.2) Where are located the unit tests.
2.3) Where are the jar files generated (in case of Ant-based builds) when
the project is built.
2.4) Where to get the dependencies.
And once this information is available, fill the blanks of a pre-defined
Maven2 pom.xml descriptor, and use it to drive the ebuild. This way it
would allow compilation flags even if the original build mechanism didn't.
We probably will ask for this specific issue to gentoo-java mailing list.
We don't think a fully-automated tool is feasible to cope with all kind of
projects, but we hope it could be of use for Java developers who don't use
Gentoo but find interesting to get an ebuild with little effort.
I apologies as this will be critical.
Firstly I would be very interested in how you would handle to dependencies of
a package within this build system. Maven is natorious for wanting to
download its dependencies (including plugins all its plugins) from a remote
repository. Something that the java team (and me personally) have been
struggling with for sometime.
Secondly the java-*-2 eclasses are now very advanced wrt everything ant.
They abstract a large portion of the functionality away from the ebuild
(without lossing the flexability)
So here an anottated vim template that I currently use and that will hopefully
( bug #164953 ) make it into the tree.
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
JAVA_PKG_IUSE=doc source #this appends the appropriate deps to
#DEPEND(RDEPEND) for
source
inherit java-pkg-2 java-ant-2
DESCRIPTION=
HOMEPAGE=
SRC_URI=${P}.zip
LICENSE=
SLOT=0
KEYWORDS=~amd64
IUSE=
COMMON_DEP=
RDEPEND==virtual/jre-1.4 #this is used by eclasses to determine the target
class version
${COMMON_DEP}
DEPEND==virtual/jdk-1.4#and this determines the source target
app-arch/unzip
${COMMON_DEP}
EANT_BUILD_TARGET=
EANT_DOC_TARGET=
src_install() {
java-pkg_dojar ${PN}.jar
use doc java-pkg_dojavadoc build/javadoc
use source java-pkg_dosrc src
}
I find this ebuild template usually provides everything a java ebuild
requires.
I would suggest you read the dev notes on the gentoo-java project page as well
as reading the wiki.
However, we are just in the definition stage. We haven't decided anything
yet, and would like to know your suggestions, even if they aren't
encouraging :).
Thank you very much.
Jose.
Please don't let me discourage you. I would be very interested in your
solutions for using maven and I believe the when 2.0.5 is released some form
of pom re-writing could be possible (similar to what happens with build.xml
files at the moment), but I dont believe there is a need to mavenify ant
builds. I believe it would be over complicated and have huge problems
handling where the src and libraries within a package reside. When it comes
to ant (at least) I believe the present solution is far more adaptable and
productive.
Alistair
--
gentoo-dev@gentoo.org mailing list
