Re: [gentoo-dev] help needed: net-irc/weechat
2014-11-12 12:39 GMT+01:00 Alice Ferrazzi alice.ferra...@gmail.com: i use weechat everyday :) glad to help Great, just take look on the bugs, and sent me patches. I shall gladly include them in cvs :) Tom
Re: [gentoo-dev] Re: The request to abolish games team policy
2014-07-08 14:42 GMT+02:00 Ulrich Mueller u...@gentoo.org: On Tue, 8 Jul 2014, Michał Górny wrote: In fact, they did remove ebuilds from the tree in the past for this reason [1]. Given that this was a live ebuild that failed to compile [2] and was dumped onto the games team few weeks after it was committed to the tree [3], I can even understand their reaction, in this particular case. [2] Clear upstream bug, we remove live versions when from time to time upstream break their repo? If you take look on 1.0 it IS almost the same ebuild? [3] I remved myself from maitnainership as I found out I don't have enought time to work on stuff in Gentoo to keep myself only in office and to make them working... So if they didn't want the live version it is perfectly sane reasoning for pruning that before, but removing the 1.0 commited few weeks ago it is just utter stupid approach and reason why I avoid to have to touch anything with games team in Gentoo. Tom Ulrich [2] https://bugs.gentoo.org/show_bug.cgi?id=431552 [3] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/metadata.xml?hideattic=0r1=1.1r2=1.2
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/bug-cleaners: index.xml
2013/11/16 Tom Wijsman tom...@gentoo.org On Sat, 16 Nov 2013 11:29:20 + Markos Chandras hwoar...@gentoo.org wrote: I think this is unnecessary. Infra requested all new projects to be in the Wiki so I don't think that you are supposed to add a proj/en page anymore just so you can redirect it to the Wiki True, GLEP 39 does still require it so a 11 lines file doesn't hurt; not sure what the right approach to update that GLEP is, especially given that its authors are no longer have commit access to it. We could raise this at the open floor call of the Council meeting. On a side note, while we're at it we could mark the authors there as retired or update their e-mail address; whichever way fits better. Yay, lets update the glep. As we councilmen continue the favorite weekly meetings ;-) we could update it next tuesday if somebody writes patch and it is triv. enough to handle there :) Cheers Tom
[gentoo-dev] Changes in libreoffice ebuild
As per my comment in bugzilla [1] I said that the patch should be submitted upstream prior having it in cvs. Yet you decided to completely ignore my statement and just smash in the patch anyway [2]. Please don't do this ever again. We had shitload of distro patches before and it is hell to strip away later on. For your statement of lacking documentation, when I google gerrit libreoffice first two links lead directly to the instance and 3rd to wiki [3], which no suprise is guide how to set it up and submit request, so stop lying. As you like to ignore maintainer requests I now expect you to submit it to the gerit, since now you have the guide and you can proceed without an issue right? Note that I have nothing against other devs submitting fixes to ebuilds maintained by me, but directly ignoring what I said on a bug and doing whatever you see fit does not match that at all. Tomas [1] https://bugs.gentoo.org/show_bug.cgi?id=479604#16 [2] https://bugs.gentoo.org/show_bug.cgi?id=479604#19 [3] https://wiki.documentfoundation.org/Development/gerrit
Re: [gentoo-dev] unmasking USE=system-ffmpeg for stable www-client/chromium ebuilds
2013/7/26 Diego Elio Pettenò flamee...@flameeyes.eu Does this still allow me to use libav? If not I'd like to veto it. You can use testing version. Stable is too old, be happy I fixed all those buildcrashes so we can have it in testing. If you want start some tracker to get it stable tho, i would not mind, as all my machines have it unmasked anyway. Tom
Re: [gentoo-dev] Last time touched bugs by year
2013/6/21 Pacho Ramos pa...@gentoo.org Could maintainer-wanted assigned bugs be filtered? Otherwise we see a ton of that kind of bugs that, I think, we already know can become really old ;) Thanks! You can do such yourself. Just clone the repo [1] and commit the updated links. Also my plan was to list even m-w bugs, because even those suckers get obsoleted often so we should close them. Cheers Tom [1] http://git.overlays.gentoo.org/gitweb/?p=proj/qa-scripts.git;a=summary
Re: [gentoo-dev] app-dict team needs help
2013/6/7 Dennis Lan (dlan) dennis.y...@gmail.com stardict: trivial bugs around but i don't use stardict. Hi Tomas I'm a stardict user, let me know what I can help Hello Dennis, Currently there are 18 open bugs [1], so just looking into them would be nice. Checking if the ebuilds could be moved to latest eapi and cleaned up might be good. Opening stabilisation bug requests for various dictionaries that are for 3+ years in testing is also good idea :-) Also if you have any diffs just sent the mail to me or proxy-maint@g.o and we shall include it in cvs (gosh I want git and gerrit). Cheers Tom [1] https://bugs.gentoo.org/buglist.cgi?quicksearch=stardict
[gentoo-dev] app-dict team needs help
Hello guys, the app-dict team is almost-non existent altho it provides one of the most core features for our daily desktop usage as without dictionaries and spell checking we could not imagine much work nowdays. So what is needed there: aspell - all various bugs around, per language file bumps here and there, cleanup and provide new eclass for aspell packages, current one is needlesly complex. myspell(hunspell): finish migration to myspell-r1 on the remaining packages, find more upstreams and include the lang files into the distribution. Most important here is that we have dicts for english from 2007 and they were updated a lot in last 6 years when i check the git in libreoffice dicts (but there is no upstream indication). stardict: trivial bugs around but i don't use stardict. I check this herd as I need it for nice and compfy libreoffice usage, but mostly I am not devoting much to it, so if you guys happen to have spare cycles, please take look for your languages/etc and updatedcleanup, also if you happen to fill stablereq, just cc arches directly there. Cheers Tom signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Review Board for Gentoo
He is probably thinking about buildtests and automatic commit merges which are not possible with reviewboard. Dne 29.5.2013 9:09 Michael Palimaka kensing...@gentoo.org napsal(a): On 29/05/2013 02:07, Alexey Shvetsov wrote: Hi! Cool! I didnt use RB before, but i use gerrit. Do you pan to integrate it to g.o.g.o? It seems can be done by git commit hooks What sort of integration did you have in mind?
Re: [gentoo-dev] PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
Is there actually list of current offenders? It would be pretty nice to have bugs opened if someone forgot to set it. Tom
[gentoo-dev] Removal of office-ext.eclass
As per summary this eclass should be removed in 30 days from now. It is replaced by office-ext-r1 in cvs. Cheers Tom
Re: [gentoo-dev] Packages using -Werror
Dne Pá 3. května 2013 10:39:29, Rich Freeman napsal(a): On Fri, May 3, 2013 at 10:15 AM, hasufell hasuf...@gentoo.org wrote: We don't need that. We already get QA warnings for severe compiler warnings with a note that it should be reported upstream. Turning them into errors does not improve anything. Yup - you can't really compare Gentoo build workflows with those for virtually any binary distro. On Gentoo building is an operation that impacts end-users. On Debian they can run some super-fragile build system 2000x until they actually manage to get a clean build, and then they can just package that up and nobody will be the wiser. On Gentoo a fragile build system means an endless stream of bugs. Even binary distros don't want the werror. Trust me on that ;-) Anyway FWIW, if upstream wants werror in their build and use autotools you can grab code that is in libwp* libvisio libcdr and others we use in libreoffice, where it is configure switch, you can mess with and having default off or on based on prefferences. Cheers Tom signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How shall we name the EAPI 6 patch applying function?
Dne St 3. dubna 2013 16:29:48, Ciaran McCreesh napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 03 Apr 2013 14:33:30 +0200 hasufell hasuf...@gentoo.org wrote: You also have to rename the PATCHES array, because base.eclass already uses that name with epatch. base.eclass should have died a horrible death a long time ago. A new EAPI is an excellent opportunity to ban it. This is actually good idea to ban the base.eclass usage, but wonder how complex it would make all the eclasses that currently inherit it. Tom signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Collecting items for EAPI 6
Dne Čt 28. března 2013 19:15:59, Michał Górny napsal(a): Hello, As discussed with ulm, I'd like to start a thread for collecting initial items for EAPI 6. Preferably items which are either almost ready or are easy to implement and are non-controversial. In other words, thing which are practically ready to get on the actual list. As usual, each item should have a corresponding 'Future EAPI' bug which blocks the tracker [1]. [1]:https://bugs.gentoo.org/show_bug.cgi?id=future-eapi As it goes we have lafile removal scripts in eclass already and there seems to be no harm done to users anymore with by-default punting with new eapi. https://bugs.gentoo.org/show_bug.cgi?id57561 Patches array from base eclass to default as it is last thing in base eclass that has some relevant stuff. https://bugs.gentoo.org/show_bug.cgi?idF3692 Other than that I would like to see some improvements on binary packages (no bugs). Something like different binary pkgs for various IUSE (so they are not always rewritten)... so the tinderbox can get more usefull :-) Cheers Tom signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] C++ TR1 virtuals
2013/3/4 Diego Elio Pettenò flamee...@flameeyes.eu: virtual/c++-tr1-functional virtual/c++-tr1-memory virtual/c++-tr1-type-traits Given that these will have a (bad) GCC dependnecy and a boost dependency on them, should we just drop them? Sounds like best solution, so i would go for it. Cheers Tom
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
If I remember correctly the damn rule is to put it for 30 days into testing, and as you said there was no previous version on arm so users could've reported some issues, i agree that sometimes you have to ignore the rules to really fix stable, but was this such case for sure? Dne 3.3.2013 3:43 Mike Frysinger vap...@gentoo.org napsal(a): On Saturday 02 March 2013 21:01:39 Markos Chandras wrote: On Mar 3, 2013 1:55 AM, Mike Frysinger vap...@gentoo.org wrote: complain to me when all these arm systems that totally had confuse already installed go down in fire. it literally makes 0 difference here. Why would they have it installed (in stable) if it had no keywords? and if it is such an important package why it didn't have testing keywords in the first place? I did't say it broke something, it just feels strange and this is why I asked sounds like there's no further clarification necessary -mike
Re: [gentoo-dev] Re: linux-firmware
2013/2/20 Rich Freeman ri...@gentoo.org: There is a current QA policy that anything using an scm to download sources cannot be stabilized, because there is no way to verify the manifest. I'm actually wondering if that makes sense with git when a specific commit is referenced, since everything is content-hashed anyway. Perhaps we just need to confirm that git actually checks the hash. If you checkout some revision or tag just create the darn tarball yourself as it is much cleaner solution and you don't force user to install git or other scm tools unless they need them.
Re: [gentoo-dev] app-dicts herd needs new people
2013/2/16 Pacho Ramos pa...@gentoo.org: As it's now empty Thanks for joining, I am unsure about releasing its packages for up for grabs and removing the herd if nobody joins :/ I did some work there wrt myspell dictionaries that are to be ported to new official layout so if anyone wants to finish that it would be cool. Also the aspell dicts needs to be updated and sorted out... so anyone wanting to join this herd there is quite a work ahead :-) The good thing is that I try to keep it at least bit checked because libreoffice is using it so I close few bugs here and there. Cheers Tom
Re: [gentoo-dev] Last time touched bugs by year
2013/2/14 Agostino Sarubbo a...@gentoo.org: Probably we don't need to see maintainer-wanted stuff.. Oh but we need to see them, quite few of those can be closed as invalid because the upstream is long ago dead. Tom
Re: [gentoo-dev] Last time touched bugs by year
2013/2/15 Alec Warner anta...@gentoo.org: I was under the impression we just left those bugs open forever...are we closing them now? Why should we keep them opened forever. They should be closed when the package is no longer provided anywhere or obsoleted by something else.
Re: [gentoo-dev] Last time touched bugs by year
2013/2/15 Markos Chandras hwoar...@gentoo.org: On 14 February 2013 19:26, Tomáš Chvátal tomas.chva...@gmail.com wrote: Dne Čt 14. února 2013 18:34:10, Markos Chandras napsal(a): Why not 2011 and 2012 as well? Feel free to add more, its on qa-scripts git repository. Ok I was just wondering if there was a reason you did not add them along with the others. I was just too lazy and i was only curious for the long open bugs :P
Re: [gentoo-dev] Last time touched bugs by year
2013/2/15 Gilles Dartiguelongue e...@gentoo.org: On another note, I just saw a report for EAPI per eclass which is super nice but unfortunately, EAPI=5 is listed but actually unsupported by the result of the scan :) This can't be done better right now, as we use pkgcore to gather these stats and it is still not supporting eapi5. At the point it gets interpreted by pkgcore it will sort itself out. Tom
[gentoo-dev] Last time touched bugs by year
Hi, I added the bug queries to http://qa-reports.gentoo.org/ based by year of last being touched. Take look, try to close the oldest ones/invalid ones and so on. I think it is lame we have bugs last touched in 2k5 :-P Cheers Tom
Re: [gentoo-dev] Last time touched bugs by year
Dne Čt 14. února 2013 18:34:10, Markos Chandras napsal(a): Why not 2011 and 2012 as well? Feel free to add more, its on qa-scripts git repository.
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
Dne Ne 10. února 2013 19:47:58, Patrick Lauer napsal(a): On 02/10/2013 05:01 PM, Pacho Ramos wrote: # Pacho Ramos pa...@gentoo.org (10 Feb 2013) # Fails with gcc-4.7, crashes (#301946, #312073), problems with # boost (#319921), problems with python-2.7 (#338826), really old # version in the tree, people should move to sci overlay one (#424659). # Removal in a month. sci-visualization/paraview So instead of moving things from random overlays to the tree we remove packages now, remove features from other packages because of that (openfoam) and then ... tell users to use an overlay? Agreed this is pretty bad idea. The teams should actually have their top priority to include user contributions to main tree as much as possible. If the team does not have time to maintain the named package, just add some contributors as maintainers and do proxy-commits for them... The greatest problem at least from my PoV is that we can't just simply git am loads of stuff users are contributing and must convert to cvs (thats actually what takes me most of the time). Having nice mailinglist where users can contribute simple patches would be briliant thing to use :-) Cheers Tom
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
Dne Ne 10. února 2013 13:51:16, Alexander Berntsen napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/02/13 12:47, Patrick Lauer wrote: So instead of moving things from random overlays to the tree we remove packages now, remove features from other packages because of that (openfoam) and then ... tell users to use an overlay? Somehow this appears not well thought out to me. +1 On 10/02/13 13:11, Rich Freeman wrote: There is nothing wrong with having an overlay that provides a better experience than the main tree. Most distros actually operate this way Most distros aren't very good. - just look up your average non-core piece of FOSS software and the first thing their Ubuntu install instructions will tell you to do is to add some repository to your list. And the second search result is the Ubuntu troubleshooting broken installs as a result of adding other repositories. I accept that there may exist reasons for using overlays. Ubuntu do it! is not one. Don't worry, no matter what are Richs opinions he is not the one crating global policies for this, so the defaults still are that we encourage adding all stuff to main tree where possible. Even the overlays are supposed to be just plaingrounds where we train upcoming devs, or pose as live ebuild/huge experimantal changes storage space. Even the excuse that it is not maintained so it is to stay in overlay is false, because when somebody mess with the package in overlay they can became maintainers in the main tree too without much fuzz. But I suppose this problem is created simply because people not wanting to work with cvs (and I purely agree that git workflow is much easier wrt this)... Cheers Tom
Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
2013/2/8 Diego Elio Pettenò flamee...@flameeyes.eu: On 08/02/2013 18:53, Samuli Suominen wrote: Then intrested parties get to fix what they want and unmask? I would say that we might want to review linux-firmware, and if the newest firmware _is_ there, just get rid of the split one. That should be probably the best approach, to actually kill of the lone ones and keep the linux-firmware only. Tom
Re: [gentoo-dev] Removals reply
Dne So 2. února 2013 12:44:30, Vaeth napsal(a): When I came to Gentoo many years ago, this was a very rare problem, but the removal of packages has tremendously increased, and it is not only me who is observing this problem - there were already some threads in the forums, and people planning to but not coming back to Gentoo for this reason. Awesome so they could've get involved and maintain it themselves if they seen it so crushial for their lives. When looking on Robins automated packages addition/removal tracker it seems that the removal trend does not change much, the only thing that changed is that now with tinderbox we see way earlier that package is broken to build and thus removed rather than being in tree uninstallable. Also on the additions side we are quite getting more and more stuff in tree. Also there is proposal to create git repository with patches exactly for this purposes. This might solve the problem of the patches but not of the lost tarballs. It was suggested in this thread to put up some server with the tarballs. This might be a solution, but for such isolated solutions there is always the danger that the same could happen as did once to the Gentoo Wiki: It would be better if the old tarballs are also on the mirrors (at least on some of them); maybe one could make some optional directory which not every mirror is supposed to have. As I said in my first mail, distro mirroring system is not to pose for upstream. You have to set up some webpage and download on some site. I mentioned fedorahosted because that one is managed by rh so it won't diappear, but you can put it on github or elsewhere if you feel like it. You still can count the packages using huge patchsets using just your hands. Again, the number is not so important, but counting by using your hands I did not expect to be meant binary ;) %grep -l http.*:.*patch.*\..*z.* /srv/portage/gentoo/*/*/*.ebuild|wc -l 421 Yay, now lets see what are biggest consumers on your list: kernel, coreutils, netbeans, postgres Sweet this leaves around 200 versioned ebuilds with 2 versions in tree each. So 100 not critical ebuids of all the in-tree ebuilds use custom patchsets... I agree that we should track the patches in some git repository so feel free to open bugreport for infra team to fire up some structure that everyone will be required to use. Also thinking about it we still have this nice policy where we should open upstream bugreports and contribute all patches back, so they should in theory be always somewhere else too :-) so we can say someone get hardware that is at least decade old, honestly just obtain distros build around such HW (like debian stable). Gentoo is about choice. I bet, many Gentoo users have at least some old hardware device which they want to use. Maybe occasionally, they also inherit some which they want to use. You really want to scare all these users away? Yes gentoo is about choice but the choice does not mean to contain everything possible in the tree. We keep the tree maintainable and working for everyone, it is not just some junkyard of whatever did compile few years back for lucky people. Actually suse/fedora and others remove packages way more than us, they just do it with each release so it does not happen here and there but just once every 6 months (or whatever is their release cycle). Or if he was not yet a gentoo user at the time when the package was removed (or absent/busy for a long period)? Well he would found out after sync Perhaps there was a misunderstanding: How can someone who starts to use Gentoo in a year find out after sync? Or another one know a year in advance that he will have the need for some special software (e.g. to support a device which he inherits in a year)? So when he starts using Gentoo he can look up if the sw he needs is supported and go elsewhere if it is not, or actually contribute and do some stuff about it to make it work for himself. Basically our goal is to create good distribution for us. There is no goal to dominate market or something like that. Take a look on ubuntu, tons of people are using it but it does not help the development team because not much of those contribute back. We rather preffer people that actually can and contribute back. When looking on our stats the user counts seem quite same so we are not losing any user share lately, but on contributors side seems like people are just consuming than contributing back. And contributors are the only ones that are important as they help you in our job. Gentoo is not a distro with bigger resources I agree: If none of the developers is interested in a package, it is completely fine to declare it as unsupported and to require the user to maintain it himself (or hire somebody) if he wants to use it. Masking it is perfectly fine (maybe another idea would be to introduce some new state for such
[gentoo-dev] Removals reply (I am not going to figure out which tread of those all should i reply to)
Hello guys, just to be sure here Removals are completely up to the maintainer to decide, with expection of QA removal where the package must be already broken to get punted. If you as developers and users find some package useful you can retake the maintainership (or became proxy-maint) which also expects you to take care of the bugs (QA can prune it even if you take the maintainership but ignore failures [even if your personal feeling is that it is corner case, it is for QA to deicde]). For dead upstream packages there are quite few problems you, who support keeping it in tree, seem not to notice. The distro patches will blob up (with each distro having different stuff) as things break with shiny new updates (and no saying it builds with older xyz does not make it work), users have no chance to report problems with the package elsewhere than to our bugzilla, etc, etc. This is the reason why the fedorahosted.org was fired up. So if you care about the package, take your time, fire up VCS/homepage/tracker there and try to work on it or find someone else interested to help you with becaming at least pseodo-upstream. Cheers Tom
Re: [gentoo-dev] Removals reply (I am not going to figure out which tread of those all should i reply to)
2013/2/1 Rich Freeman ri...@gentoo.org: On Fri, Feb 1, 2013 at 8:53 AM, Tomáš Chvátal tomas.chva...@gmail.com wrote: If you as developers and users find some package useful you can retake the maintainership (or became proxy-maint) which also expects you to take care of the bugs (QA can prune it even if you take the maintainership but ignore failures [even if your personal feeling is that it is corner case, it is for QA to deicde]). Citation? I don't see any GLEPs or other Council-approved policies to that effect. You my friend are slowly pissing me of as I read through all the flames you cause on -dev. There is no council vote required as it is already defined within qa team specs (and glep too when i think of it, so yep there is glep for you). And this is of course why nobody actually wants to maintain these packages - everybody is going to be looking over your shoulder because they've already decided that the existence of the package bothers them. No, they won't get anyone looking over their shoulder unless they decide to neglect the bugs as few maintainers did. I didn't see a lot forced removals caused by qa, did you? The existence of the package usually does not bother anyone, maintainer just decided that its burden so it will be removed, he could've put it to m-n but its up to every maintainer to decide what to do if the package has bugs he deem serious. If anyone else decide to pick up where they left, it is his job to ensure the package gets fixed and up-par to work nicely. Bit ago we had this discussion about keeping broken shit in tree masked or just prune it, and obvious solution was to remove it as there is just few of us and if anyone wants to start where we left he can pick out the ebuild from attic and put into his own overlay where it might work for him or even put it back to tree fixed. Honestly, threads like this bug me so much that I'm half-tempted to take over maintainership of one of these packages just to be a test case... Ugh - time for an email break... Go for it, i wrote exactly what to do, create vcs/tracker/homepage and it can stay.
Re: [gentoo-dev] Removals reply
Dne Pá 1. února 2013 18:40:32, Vaeth napsal(a): [...] and if anyone wants to start where we left he can pick out the ebuild from attic and put into his own overlay where it might work for him or even put it back to tree fixed. And this is exactly what *cannot* be done after a while: The ebuild is still available by CVS (or maybe git in future), but if there were already a lot of gentoo patches, the tarball with these patches is lost forever. If even upstream is dead, not even the main tarball will be available anymore. Oh but it can mostly these archaic packages do not have patchsets. You still can count the packages using huge patchsets using just your hands. Also there is proposal to create git repository with patches exactly for this purposes. So bribe infra people with cookies to focus on it and you will get your stuff done :-) Go for it, i wrote exactly what to do, create vcs/tracker/homepage and it can stay. And what if somebody decides to do so in a year? If you are person who didn't touch his Gentoo box within a year hire some guy to maintain it. Seriously after a year without syncing and checkign the masks it is just walking security hole. E.g. if somebody gets some hardware in a year and needs support of a package which was removed? Well we never remove stuff right away, so we can say someone get hardware that is at least decade old, honestly just obtain distros build around such HW (like debian stable). Or if he was not yet a gentoo user at the time when the package was removed (or absent/busy for a long period)? Well he would found out after sync that it is removed, but he still can have it on his system, not available package does not mean that you have to uninstall it from that box. Then he is lost unless a distribution with bigger resources as gentoo has decided to keep the package. Not really a selling point for gentoo. Gentoo is not a distro with bigger resources, there is only few developers working on everything (yeah we show that 250 devs are still around, but question is how much of those are active). If you want real support you can always go for paid distros (thats their purpose, to support stuff where OSS is out of loop). PS: threading is broken in your mail client. or I dunno why this reply appeared out of thread.
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
Dne Čt 24. ledna 2013 21:33:45, Pacho Ramos napsal(a):
El mar, 22-01-2013 a las 19:42 +0100, Tomáš Chvátal escribió:
Dne Út 22. ledna 2013 19:37:12, Pacho Ramos napsal(a):
I agree, thanks for pointing it. Just attached patch should handle it.
Still not nice enough for me :D
Use the ECLASS_VARIABLE to describe it @DEFAULT_UNSET is what you seek,
see
git-2.eclass.
Tom
What about this one?
- if ! [[ ${REPLACING_VERSIONS} ]] || [[ ${FORCE_PRINT_ELOG}
]]; then
+ if ! [[ -n ${REPLACING_VERSIONS} || -n ${FORCE_PRINT_ELOG}
]]; then
But thats just cosmetic
Tom
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Subslots progress in main tree
Hi guys, do we have some scans that report libraries converted to subslots and lists their rdeps checked if they are updated accordingly? It might be pretty usefull to actually see where the deps needed to be updated so we can take use of this feature where possible (also its a hint for lib maintainers to update their libs and see real impact). Cheers Tom
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
2013/1/22 Pacho Ramos pa...@gentoo.org: El mar, 22-01-2013 a las 08:16 +0100, Tomáš Chvátal escribió: Would'nt be better to just set some variable in the ebuild, rather than call function that touches empty file? Tom I think it can be done in either way... but I don't see the advantage of any over the other :/ Just few I can think of right now: You can set the variable in the ebuilds global scope somewhere on top easily. You can actually do more magic later based on what content user puts to the variable if we want to (all msgs, important ones only, ...) You actually allow user to enforce this behaviour in make conf for all packages if he desires to do so. Also I never seen this being handled by touching files in any other eclasses :-) Tom
Re: [gentoo-dev] January stabilization candidates
2013/1/22 Petteri Räty betelge...@gentoo.org: I have an RSS feed for this purpose at: http://gentoo.petteriraty.eu/stable.rss Sources are available here: https://github.com/betelgeuse/scripts/blob/master/rss-changelog Maybe this is something that should be pushed to official Gentoo infrastructure so more people know about it and use it? Yup that would be nice. Also we could really finegrain it based on metadata.xml settings if someone really wants to exclude his packages, and also we could think if it should be opt-out or opt-in. Cheers Tom
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
Dne Út 22. ledna 2013 19:37:12, Pacho Ramos napsal(a): I agree, thanks for pointing it. Just attached patch should handle it. Still not nice enough for me :D Use the ECLASS_VARIABLE to describe it @DEFAULT_UNSET is what you seek, see git-2.eclass. Tom signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
Dne St 16. ledna 2013 17:09:07, Alexis Ballier napsal(a): On Wed, 16 Jan 2013 12:40:02 + (UTC) Tomas Chvatal (scarabeus) scarab...@gentoo.org wrote: scarabeus13/01/16 12:40:02 Modified: ChangeLog Added:ffmpeg-9.ebuild Removed: ffmpeg-0.10.2-r1.ebuild Log: Add new virtual for 1.1/9 series. Masked. Also it has switched dep order as will be announced upon unmasking. ... and since we are committing silently without any real discussion I will switch the dep order again and announce it much later without leaving room for discussion :) Did you read the msg, announced later on, i am just preparing that shit because now I have time. Given that its masked and does not affect existing installs it can stay like this forever. Also if you read planet you would see I stated it on a blog yesterday, preparation of all moves take some time. Also it will be discussed on the dev in near future. I don't have too much of the time and sending mails to -dev takes some preparations if you don't want them turn into huge bikeshed. More seriously: Why ? Who decided this ? Let's be realistic, both upstreams claim they're better than the other in one way or another, and let's think like serious downstreams, not like upstream playground. I do think like serious downstream. Thus tracking what major distros do. Given fedora switched and debian too we ough to do it at some point too. Also quite few upstreams are migrating and few staying so there is a tie. But we have to work on supporting both which currently you don't (see bellow). As a downstream, I can see plenty of reasons against, but none in favor of this change: - There are still a couple of non-trivial packages that need to be fixed to work with libav while I don't know any that works with libav but not ffmpeg. Nice from you that you didnt bother to check out if it works or not because I do it quite often, so does tinderbox from Diego. Every time i bump shit I have to compile it in two virtuals just to please both camps. Lets not forget how carefull you were when commiting to xbmc where you completely fucked stable ebuild without even letting anyone know [1]. From my checking only package right now not building with stable libav is again XBMC (in testing only). If there is something more open bugs in bugize. - All (but the one discovered in Nov. 2012) of the security issues fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May 2012 (!!) for ffmpeg according to the website... 8 months before... So what? Checking their importance yea we ride it straight to stable on Gentoo, but security relevance would not deem any maintenance update only to be done with next proposed maintenance one (eg when there is something important to fix) because most of them look . I can waste time to look the other way around and show you broken code in ffmpeg which happened after broken merge from libav but lets not turn this into a piss contest. Basically this having two libraries hurt everyone, but both forks are on par and we as gentoo will provide both while preffered default will be what major distros use. If you disagree with that and you don't want your lead to make that decision, which you and I both don't want. I don't want Luca being blamed that he is evil libav dev who does this just to make more share for his pet project. We can wait with dealing this for a bit and propose it for council meeting. We vote about lots and lots of stuff there and another thread about two ffmpeg implems on g-dev will do just fine, but it will be hell of a bikeshed :-) Tom [1] https://bugs.gentoo.org/show_bug.cgi?id=443006
Re: [gentoo-dev] January stabilization candidates
Dne So 12. ledna 2013 14:49:52, Paweł Hajdan, Jr. napsal(a): Please review attached automatically generated stabilization candidates for January. I don't want to annoy people with automatically filed bugs, and at the same time I also received lots of positive feedback about the effort to keep the stable tree more up-to-date. I think the best way to proceed is to listen to that feedback and continue the effort, while also keeping an updated list of exclusions for packagers/herds that are actively stabilized by maintainers. Paweł Hmm, nice idea but how about expanding metadata.xml with something like info for stabilisations so they can be automatically grabbed for it. Quite few software is just nice enough that it can go automatically for stable in 30 days, and someone could just go then and open new bugs (with assigned arches) based on it (of course it expects brain from the guy reporting it that he checks if there are no open bugs). Because mails to -dev are frankly annoying. :-) Tom signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
2013/1/21 Pacho Ramos pa...@gentoo.org: This can be useful when, for example, doc contents are modified. You can then rely on using REPLACING_VERSIONS in your ebuild to print messages when people updates from versions using old docs Patch to review attached Would'nt be better to just set some variable in the ebuild, rather than call function that touches empty file? Tom
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
2013/1/17 Markos Chandras hwoar...@gentoo.org: On 16 January 2013 20:09, Alexis Ballier aball...@gentoo.org wrote: On Wed, 16 Jan 2013 12:40:02 + (UTC) Tomas Chvatal (scarabeus) scarab...@gentoo.org wrote: scarabeus13/01/16 12:40:02 Modified: ChangeLog Added:ffmpeg-9.ebuild Removed: ffmpeg-0.10.2-r1.ebuild Log: Add new virtual for 1.1/9 series. Masked. Also it has switched dep order as will be announced upon unmasking. ... and since we are committing silently without any real discussion I will switch the dep order again and announce it much later without leaving room for discussion :) More seriously: Why ? Who decided this ? I agree. This is a big change so there should be a discussion about this or at least an announcement that this is going to happen on the Xth of February. Did you actually test that the tree is ready for libav as the default ffmpeg provider? Yep I did test it. On stable there is nothing broken and right now even mplayer1 compiles fine. On testing there should be nothing broken apart from xbmc, where Alexis is one of upstream devs and he seems not to give fuck about making it work under both. Also Samuli broke it yesterday because he seems not to be bothered about fixing reverse dependencies with cdio update (but again it seems simple to test and fix which will be done when I am not working and have time to test it properly). So yes it works and should not pose any issues to user. I also announced it over blog to get people report more issues they find out so I can be really sure it works out. It turned out the mplayer1 really needs to work under both, which I patched yesterday for stable libav and Luca today for masked libav to work. So overall we are in green numbers if few people didn't break it on purpose or just for the ignorance. The only weird stuff might be for migrating users that they have to use emerge -C ffmpeg emerge -1v libav libpostproc as a postproc is not yet split out of ffmpeg. But even that could be discussed and we can switch to split libpostproc under both libs to have matching deps (even ffmpeg has --disable-postrpoc switch :)). Tom
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
2013/1/17 Ben de Groot yng...@gentoo.org: On the other hand I have used libav and mplayer2 for a long time, and have not run into any problems. The only thing missing is mencoder. Which is sovled by the mplayer1 supporting libav since yesterday. :-)
[gentoo-dev] Defaulting for debug information in profiles
Hi lads, lately I am having bit of problems from getting relevant debug info from users. Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. This results in 2 gb data in /usr/lib/debug for my system which is not that bad with current disk sizes and it saves users quite some time when i have to request them to recompile half of their system with debug info just to get idea how to fix their issue. I would go even for compressdebug feature but that one needs more time as some packages like glibc fails to merge with it and you need newer gdb to work with it. Cheers Tom
[gentoo-dev] Moving our/portage stuff to var
Currently we put portage into /usr/portage and all related stuff is to be in the subfolders there (distfiles, binpkg). I've always myself override these defaults in make.conf to point for /var/portage/ (not /var/lib because I never bothered enough how to make world and config files to be put elsewhere :P). The only reason why we have this currently in usr is that bsd ports put their stuff in there and I suppose Daniel just did the same. With respect to reality how stuff is done in the linux land all the variable data should be in /var so we should adjust and move it in there too. What would you think? Cheers Tom
Re: [gentoo-dev] Defaulting for debug information in profiles
2012/12/17 Diego Elio Pettenò flamee...@flameeyes.eu: On 17/12/2012 11:11, Tomáš Chvátal wrote: Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. Why, somebody uses default cflags? I silently hope they copy the default cflags to their make.conf and then set march and add more stuff, rather than starting from scratch. Also we can pop-up newsitem asking them to put it into cflags ;-)
Re: [gentoo-dev] Moving our/portage stuff to var
2012/12/17 Diego Elio Pettenò flamee...@flameeyes.eu: On 17/12/2012 11:19, Tomáš Chvátal wrote: I've always myself override these defaults in make.conf to point for /var/portage/ (not /var/lib because I never bothered enough how to make world and config files to be put elsewhere :P). I would say let's work on that so that portage can keep them there. Although I'm more for /var/cache/portage myself, as both distfiles and tree can be re-generated. Thats right, it should be even better location. :-)
Re: [gentoo-dev] Defaulting for debug information in profiles
2012/12/17 Sven Eden sven.e...@gmx.de: Hello Tomáš, on my system I have set up everything with splitdebug enabled. My CFLAGS use - march=native, -O2 and -ggdb. And this is the result: (Yes, I have a dedictated partition for that.) ~ $ LC_ALL=C df -h /usr/lib/debug/. Filesystem Size Used Avail Use% Mounted on /dev/sda10 25G 22G 1.7G 93% /usr/lib64/debug This is a full KDE-4.9.4 system with a total of 1,807 packages installed. I guess the regular user would end up somewhere between your 2G and my 22G. But I bet it will be slightly more likely my end, wouldn't it? Well your problem is using -ggdb, that adds ton of stuff that makes things large exponencialy in most cases, i bet you would be around 5-6 on -g usage. Cheers Tom
Re: [gentoo-dev] Defaulting for debug information in profiles
2012/12/17 Alexandre Rostovtsev tetrom...@gentoo.org: The bigger problem is not disk space but memory usage at link time. Try building something like *-webkit-* or firefox with debugging CFLAGS on a machine with limited memory. That ain't problem, we acutally can patch in those packages to strip the debug by default and add there useflag to not strip those for those really needing it. Also the culprit is again -ggdb rather than -g.
Re: [gentoo-dev] Defaulting for debug information in profiles
2012/12/17 Ben de Groot yng...@gentoo.org: Please don't. For most users this is a waste of resources. On first look it seems like waste of resources. On second hand it makes stuff easy wrt bugreports provided by users. And believe me when I say most upstreams are pissed by gentoo reports because they lack any good debuginfo features, nor they know how to tell users how to make their systems contain debug informations. I have seen quite few upstreams rejecting all by Gentoo reported issues because of this, plus they were quite suprised that I actually can generate any sane debug informations with it.
Re: [gentoo-dev] Cleaning tree of outdated packages
2012/12/13 Jory A. Pratt anar...@gentoo.org: As many of us are aware the tree is growing to a size that is really unacceptable for many. We have many packages that have excessive amounts of versions laying around that are not used any more. Many of these packages with excessive revisions most likely do not work with modern code any longer, or have security exploits or just dead upstreams that do not support them any longer that have been replaced with newer packages. Well these packages are around for stable at the moment when a newer package replaces the old and makes stable branch we need to remove the dead package. This is nothing but an attempt to start reducing the size of the tree and supported packages as a whole to improve the quality of Gentoo as a WHOLE. All packages of course need to be handled in a manner that works with maintainers/herd and the community as a whole. Jory Please press enter more often when sending mails :P So we can in-post rather than bottom/top post to your mails. I totaly agree that we should reduce amount of versions we provide in main tree and I tried to adhere to this policy in all herds I am member of or whenever I found some insane stuff in cvs. But there is one big ass but. We have some packages that were stabilised last time few year back and they provide multiple testing versions on top of that. Who is the one to deterimine which one should go stable and which to get rid of? We had some humble tryouts to create automatic stabilisation request which didn't turn out exactly well as most of the maintainers had to actually do more work ;-) Long story short for to have some sane policy wrt amounts of the stable packages. Testing packages can't be handled easily by some rule because the development differs everywhere. Packages should provide only one stable version per branch/slot by default. Exception for this rule are base-system packages where requirement is to provide two stable versions at any given time.
Re: [gentoo-dev] Cleaning tree of outdated packages
2012/12/13 Tomáš Chvátal tomas.chva...@gmail.com: But there is one big ass but. We have some packages that were stabilised last time few year back and they provide multiple testing versions on top of that. Who is the one to deterimine which one should go stable and which to get rid of? We had some humble tryouts to create automatic stabilisation request which didn't turn out exactly well as most of the maintainers had to actually do more work ;-) I did not ment to send this! It is mail WIP I wanted to store in draft folder... anyway so let me expand here: We need some metadata.xml tag that would allow automatic stabilisations without maintainer step so we can speed up things at some pace. Then we need some nice page displaying results of possible stabilisations, where members of Arch teams or AT guys would open up new bugs where ccing the respective archs. Apart from that I dunno what exactly ATs would strive for so Ago, or anyone else please show up some ideas :-) Cheers Tom
Re: [gentoo-dev] [RFC] Global USE=systemd
Does it really have to be useflag? Can't we simply just install the file every time like we do with everything else? Logrotate/normal initscripts/etc/etc. There should be no issue with that if we install the service files every time, they just take few kbs in /etc/
Re: [gentoo-dev] games.eclass: handle verbose build log for egamesconf in EAPI5
There are better ways to do this. For example you can just grep through the configure file, not having to invoke it, see the xorg-2.elass Tom 2012/12/2 hasufell hasuf...@gentoo.org: already filed a bug, but no response so far https://bugs.gentoo.org/show_bug.cgi?id=78 any comments? This is sane imo, cause some games herd developers don't agree with the always latest EAPI thing which is no official policy anyway.
Re: [gentoo-dev] [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
2012/12/2 Michał Górny mgo...@gentoo.org: And when was poppler split a library/server split? I think it was 2k8 or so, before the kde team took over its maintenance.
Re: [gentoo-dev] Packages up for grabs due lavajoe retirement
Dne So 1. prosince 2012 06:42:13, Rich Freeman napsal(a): On Fri, Nov 30, 2012 at 4:13 PM, Tomáš Chvátal tomas.chva...@gmail.com wrote: Dne Pá 30. listopadu 2012 20:37:22, Pacho Ramos napsal(a): media-sound/logitechmediaserver-bin - this package is special, it's maintained by a proxy maintainer but it was reassigned to maintainer-needed instead of proxy-maint herd. Was reviewing to reassign it when I saw: https://bugs.gentoo.org/show_bug.cgi?id=251494 that I have no idea about how to handle :| Simple, add hardmaks explaining possible secuirty issues due to bundling earthheaven, and then let the proxymaintainer play with it if he wants. The mask will be lifted only under condition these issues are fixed. People can unmask quite easily if they want, we don't need everything in stable :-) I can't say that I agree with this needing to be masked. If it HAS a known security issue, then mask it. If the only issue is that it bundles too many libs, well, then just stick an ewarn in there or something but make it the user's call. Bundling few libs and bundling 40 of them is bit of difference, will YOU do the audit? Also other teams actively work on the unbundling, while there is track of no will to actually make it buildable with system libs. Also the security is not the only problem here, it can also cause runtime issues. Like bundled lib does not work with xyz because it does not apply patch X that we have in main tree. Should we mask chrome while we're at it (and yes, I'm aware that the chromium team is doing their best to remove these, but there are MANY left)? How about mythtv - that bundles ffmpeg? Mythtv and its bundling is really horrible and actually not needed at all by upstream.. This is the reason why it for example is not included in debian at all (external repos of course have it). Yes, it is lousy practice, but our options are to change the world, practically fork upstream, or refuse to include useful packages. It is admirable when we can remove bundled libs, but this should not be mandatory for having a package in the tree. Actual security issues should be fixed, of course, or masked. Sure, it ain't perfect or pretty, but it works. And when dealing with outsiders, whether they are proxy maintainers or our founder, can we at least try to be polite? Yes we should be polite and nice, and I think explaining the guy why it will be masked is enough. He can still work on it in main tree where it will for sure get way larger audience than if it would be sitting in some overlay, and users would have to read the mask before using it so they will have to use their brains at least a bit. Still keep in mind most distros won't allow inclusion of such software into main repositories at all, so we allow something fishy others avoid a lot.
Re: [gentoo-dev] Packages up for grabs due lavajoe retirement
Dne Pá 30. listopadu 2012 20:37:22, Pacho Ramos napsal(a): media-sound/logitechmediaserver-bin - this package is special, it's maintained by a proxy maintainer but it was reassigned to maintainer-needed instead of proxy-maint herd. Was reviewing to reassign it when I saw: https://bugs.gentoo.org/show_bug.cgi?id%1494 that I have no idea about how to handle :| Simple, add hardmaks explaining possible secuirty issues due to bundling earthheaven, and then let the proxymaintainer play with it if he wants. The mask will be lifted only under condition these issues are fixed. People can unmask quite easily if they want, we don't need everything in stable :-) Tom signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 1/2] Set default EGIT_SOURCEDIR to point to standard ${WORKDIR}/${P}. It allows ${S} overriding in user's code as other eclasses do:
Why not use tools already in the eclass? The egit_sourcedir is exactly for
this... also you can just define s after the inherit...
Dne 27.11.2012 20:27 Sergei Trofimovich sly...@gentoo.org napsal(a):
Before the patch I had to move subdir(not very reliable):
EGIT_REPO_URI=git://github.com/UU-ComputerScience/uhc.git
src_prepare() {
mv EHC/* ./ || die
}
After the patch i can define it the usual way:
EGIT_REPO_URI=git://github.com/UU-ComputerScience/uhc.git
S=${WORKDIR}/${P}/EHC
Original ebuild:
https://github.com/gentoo-haskell/gentoo-haskell/blob/master/dev-lang/uhc/uhc-.ebuild#L27
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
git-2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-2.eclass b/git-2.eclass
index 1ecc633..1a96978 100644
--- a/git-2.eclass
+++ b/git-2.eclass
@@ -21,7 +21,7 @@ DEPEND=dev-vcs/git
# This variable specifies destination where the cloned
# data are copied to.
#
-# EGIT_SOURCEDIR=${S}
+# EGIT_SOURCEDIR=${WORKDIR}/${P}
# @ECLASS-VARIABLE: EGIT_STORE_DIR
# @DESCRIPTION:
@@ -132,7 +132,7 @@ git-2_init_variables() {
local esc_pn liverepo livebranch livecommit
esc_pn=${PN//[-+]/_}
- : ${EGIT_SOURCEDIR=${S}}
+ : ${EGIT_SOURCEDIR=${WORKDIR}/${P}}
:
${EGIT_STORE_DIR:=${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/egit-src}
--
1.8.0
Re: [gentoo-dev] [PATCH 2/2] Allow user mangle distfiles' ${EGIT_DIR} after actual git fetch.
This is bad idea. It breaks live rebuild and other stuff. You should just
clone each repo yourself, see how i did in libreoffice ebuild
Dne 27.11.2012 20:28 Sergei Trofimovich sly...@gentoo.org napsal(a):
EGIT_REPO_URI=https://github.com/ghc/ghc.git;
requires user to run './sync-all fetch / ./sync-all pull'
after actual 'git pull', which fetches 20 more repos for code changes.
Upstream does not use submodules.
The patch injects user's callback right before 'git-2_move_source'.
Currently I abuse 'git-2_gc':
Original ebuild:
https://github.com/gentoo-haskell/gentoo-haskell/blob/master/dev-lang/ghc/ghc-.ebuild#L180
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
git-2.eclass | 24
1 file changed, 24 insertions(+)
diff --git a/git-2.eclass b/git-2.eclass
index 1a96978..1bacef5 100644
--- a/git-2.eclass
+++ b/git-2.eclass
@@ -569,6 +569,29 @@ git-2_cleanup() {
unset EGIT_LOCAL_NONBARE
}
+
+# @FUNCTION: git-2_fetch_user
+# @DESCRIPTION:
+# User-overridable callback allow user to update
+# sources in ${EGIT_DIR} (current location).
+# Does nothing by default
+git-2_fetch_user() {
+ :
+}
+
+# @FUNCTION: git-2_post_fetch
+# @INTERNAL
+# Internal function calling user's callback
+# when ${EGIT_DIR} needs more actions, than
+# simple fetch.
+git-2_post_fetch() {
+ debug-print-function ${FUNCNAME} $@
+
+ pushd ${EGIT_DIR} /dev/null
+ git-2_fetch_user
+ popd /dev/null
+}
+
# @FUNCTION: git-2_src_unpack
# @DESCRIPTION:
# Default git src_unpack function.
@@ -581,6 +604,7 @@ git-2_src_unpack() {
git-2_fetch $@
git-2_gc
git-2_submodules
+ git-2_post_fetch
git-2_move_source
git-2_branch
git-2_bootstrap
--
1.8.0
[gentoo-dev] New global useflag proposals
Hi guys, wayland: Enable dev-libs/wayland backend vdpau: Enable the Video Decode and Presentation API for Unix acceleration interface. Cheers Tom
Re: [gentoo-dev] gstreamer eclass review
Hi Gilles, The eclass itself looks fine, I would just ask if you would not mind to use the bash += syntax rather than VAR=VAR something as it is shorter and easier to read. Cheers Tom
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
2012/10/31 Dirkjan Ochtman d...@gentoo.org: That's rather unsurprising... If you're going to file bugs in a semi-automated manner, might as well try to assign to the correct maintainer? Yep he should've assign them, but anyway the annoying elog messages are an issue. And quite few packages suffer from it :-) Tom
Re: [gentoo-dev] [RFC] Dropping slotted boost
Dne Út 30. října 2012 20:24:26, Michał Górny napsal(a): On Tue, 30 Oct 2012 11:30:16 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: Given the amount of headaches that Boost seems to give us all, now thanks to the recent changes even more because Gentoo's boost is different from all others and no upstream default check seem to work correctly with it, I'm questioning the usefulness of having it slotted. Could you elaborate on that? I don't remember having problems with boost.m4 or cmake's default checks unless I'm missing something which is obvious to you. Michal, given my affiliation with libreoffice I am handling quite few sh*t about buildsystems there. Currently we have orcus/wps/visio and libreoffice itself checking for internal components of boost in the configure scripts. You basically want me to add 1 kB m4 file from some github site (aside from fact it is nicely licensed GPLv3) and change all those checks we have to confor with this m4 so they work again for Gentoo. Here let me put the emphasis on FOR GENTOO because no other distro on to this day had problem with the boost setup lo projects are using, and we include stuff like win and mac. My alternative for this work is to do this on gentoo side and add append cflags and libs in each pkg using the boost-utils eclass and again add more shit i have to maintain into each ebuild. So given that it's a PITA for the maintainers, a PITA for the users, eselect boost has been shown to be a bad idea and so on ... can we just go back to just install it and that's about it? How are you going to solve the issue of a lot of packages being broken with new boost versions? Are you volunteering to keep fixing them with each release? Simple, as any other lib, depend on older version and possibly port it forward. If that does not work then mask and wipe. Life goes on. Do we have at least some good use case on split boost requirement? Tomas
Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
2012/9/29 Michał Górny mgo...@gentoo.org: Hello, Instead of the floating patches and p-d-ng modifications I sent earlier, here are the two complete (so far, well, initial :P) eclasses for review. They are designed as 'mostly' drop-in python-distutils-ng replacement. Hi, the eclasses look pretty, so good job, just one question tho, would it be possible to use more debug-something calls so the log file would be populated automatically with whats going on (same like eg git-2 eclass)? Cheers Tom
Re: [gentoo-dev] [RFC] new vala.eclass
2012/8/25 Alexandre Rostovtsev tetrom...@gentoo.org:
Hi man,
*snip*
case ${EAPI:-0} in
0|1|2)
die EAPI=${EAPI} is not supported
;;
*)
EXPORT_FUNCTIONS pkg_setup
;;
esac
Any reson for not supporting ALL known eapis?
*snip*
if [[ -z ${VALA_API_VERSION} ]]; then
die VALA_API_VERSION not set
fi
You can use the instead of conditional as you have longer lines in
the file anyway
*snip*
if ! [[ -d ${T}/pkgconfig ]]; then
mkdir ${T}/pkgconfig || die mkdir failed
fi
Same as above
*snip*
local p
You should put the var defs on the top, I know this aint ansi C but i
found that we tend to loose the variable declarations in long run
otherwise.
Cheers
Tom
Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly
2011/11/11 Alec Warner anta...@gentoo.org: Like it is not enough there is version bump every few days... Just alter only live ebuild and branch of it with each release and do not alter the releases unless really critical bug is there. People are patient and they can wait for bugfixes. I actually like that chromium releases at a high rate of speed. Does that mean it sucks for Gentoo? Sure. However if I want to stay on a particular rev (so I don't recompile all the time) I can pmask it (and so can you.) I am not bitching about that updates, I am pissed that even if I update the ebuild is altered afterwards so I again have to recompile it for no obvious benefits. Even those bugfixes can wait for next damn release that will happen in few days... Imagine that I would adopt your approach with libreoffice. I suppose people would chain me to some wall and use as target practice as result fo my actions :) Well one; I care a lot less about having an up to date libre office since it is not typically a target for attacks (unlike my browser which has a large attack surface.) That being said; if upstream did an actual release every week I wouldn't be offended if those releases made it into the tree; again it is up to me as a user to decide if i am recompiling or not. You would be suprised how much people try to exploit your documents and how interesting that gets :) Tom
Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly
2011/11/11 Brian Harring ferri...@gmail.com: On Fri, Nov 11, 2011 at 08:58:14AM +0100, Tom Chv??tal wrote: Hi guys, In last 3 days i recompiled chromium 3x 1x rebuild for cups useflag 1x update 1x rebuild for cups useflag snip Chromium moves fast and you're obviously running unstable keywording. Meaning you're *intentionally* getting every beta channel release. I am getting dev releases... Nicely phrased, your complaint is that having ran unstable keywords, it's moving too fast for your taste. Stable keywords seem like an obvious solution to it. It already happened multiple times in the past and i am not bitching about the updates but to updates to ebuild without bump... One thing that is less obvious is that there are essentially two flavors of unstable chromium- dev and beta. Currently beta is 17.*, dev is 16.*. If you don't want bleeding edge, but want faster than stable, pmask 17.*. As i said i am on 16 which is in testing, beta series is masked. That said... you're complaining that having ran unstable, you're having to rebuild too much. Stable exists for a reason. Either way, I suggest folks flip through the changelog- not seeing anything egregious in bumping, refactoring appears to go out during upstream version bumps. For the cups rebuild referenced above is a build compilation failure that was rolled out in existing versions (or in version bumps). It may be an annoyance to Tommy that emerge -N picked it up, but for folks hitting the build failure, they obviously view it a bit differently (as evidenced by a fair amount of bitching on the bug in question). If you really, really want to keep running bleeding edge, rebuilding for every change that occurs on it but selectively slowing down certain builds... well, patch portage and mangle the existing vcs rebuild code to be usable for other packages, adding a feature along the lines of I want to run bleeding edge X, but rebuild it only weekly. Barring that, the solutions for your user configuration problem are above. The build issue was with -cups so useflag was removed and hard dependency enabled, fine with me. But why the fuck the bump was issued next day still hard-depending on it and in day after that this commit arrived in: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/chromium/chromium-16.0.912.32.ebuild?r1=1.1r2=1.2 You are telling me this is build time failure fix, you are telling me that people that already had pulled in that cups could not sleep thanks to it and survive for another week to get the flag back with bump?
[gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly
Hi guys, In last 3 days i recompiled chromium 3x 1x rebuild for cups useflag 1x update 1x rebuild for cups useflag If you screw the ebuild up then always think if the change is worth the stupid long recompile time. Like it is not enough there is version bump every few days... Just alter only live ebuild and branch of it with each release and do not alter the releases unless really critical bug is there. People are patient and they can wait for bugfixes. Imagine that I would adopt your approach with libreoffice. I suppose people would chain me to some wall and use as target practice as result fo my actions :) Cheers Tom
[gentoo-dev] Shutdown of berlios
Hi guys,
as you probably know berlios is going to be shut down at the end of
the year so we should probably find/create alternative download
locations for the packages in the main tree.
The attached list provide all those with mirror://berlios so if you
are interested in some of those packages, or know upstream try to
convince them to use sourceforge or other hosting that should suit
their needs.
If the upstream is dead I have no clear idea what to do, but maybe
infra could set-up something download.gentoo.org where we could keep
all the files with their sums and gpg sign from us gentoo devs to
ensure their validity.
I am sending this mail now because from now on we should have 60 days
to prepare - just ~2 packages day should solve the issue :)
Cheers
Tom
app-accessibility/festival-ru/festival-ru-0.5.ebuild:SRC_URI=mirror://berlios/festlang/${MY_PN}-${PV}.tar.bz2
app-cdr/b5i2iso/b5i2iso-0.2.ebuild:SRC_URI=mirror://berlios/${PN}/${PN}.tar.bz2
app-cdr/cuecue/cuecue-0.2.2-r1.ebuild:SRC_URI=mirror://berlios/cuecue/${P}.tar.gz
app-cdr/cuetools/cuetools-1.3.1.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.gz
app-cdr/cuetools/cuetools-1.3.1-r2.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.gz
app-cdr/iat/iat-0.1.3.ebuild:SRC_URI=mirror://berlios/iat/${P}-src.tar.bz2
app-cdr/iat/iat-0.1.7-r1.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.bz2
app-cdr/serpentine/serpentine-0.9-r2.ebuild:SRC_URI=mirror://berlios/serpentine/${P}.tar.bz2
app-crypt/gringotts/gringotts-1.2.10.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.gz
app-crypt/tpm-emulator/tpm-emulator-0.5.ebuild:SRC_URI=mirror://berlios/tpm-emulator/${MY_P}.tar.gz
app-crypt/tpm-emulator/tpm-emulator-0.5.1.ebuild:SRC_URI=mirror://berlios/tpm-emulator/${MY_P}.tar.gz
app-dicts/qvortaro/qvortaro-0.4.1.ebuild:SRC_URI=mirror://berlios/qvortaro/${P}.tar.gz
app-emulation/xen-tools/xen-tools-3.4.2-r3.ebuild:# vtpm? (
mirror://berlios/tpm-emulator/${TPMEMUFILE} )
app-emulation/xen-tools/xen-tools-3.4.2-r5.ebuild:# vtpm? (
mirror://berlios/tpm-emulator/${TPMEMUFILE} )
app-emulation/x48/x48-0.4.3-r1.ebuild:SRC_URI=mirror://berlios/x48/${P}.tar.gz
app-emulation/x48/x48-0.6.3.ebuild:SRC_URI=mirror://berlios/x48/${P}.tar.gz
app-i18n/xsim/xsim-0.3.9.4-r5.ebuild:SRC_URI=mirror://berlios/xsim/${P}.tar.gz
app-misc/lcd-stuff/lcd-stuff-0.1.2-r1.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.bz2
app-misc/lcd-stuff/lcd-stuff-0.1.5.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.bz2
app-misc/lcd-stuff/lcd-stuff-0.1.6.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.bz2
app-office/rubrica/rubrica-2.1.6-r1.ebuild:SRC_URI=mirror://berlios/${PN}/${MY_PN}-${PV}.tar.bz2
app-portage/conf-update/conf-update-1.0.1.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.bz2
app-portage/eix/eix-0.22.11.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.xz
app-portage/eix/eix-0.22.5.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.xz
app-portage/eix/eix-0.23.1.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.xz
app-portage/eix/eix-0.23.2.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.xz
app-portage/etc-proposals/etc-proposals-1.4.3-r2.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.gz
app-text/unpaper/unpaper-0.3.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.gz
app-text/u2ps/u2ps-0.8.1.ebuild:SRC_URI=!fonts? (
mirror://berlios/${PN}/${P}.tar.gz )
app-text/u2ps/u2ps-0.8.1.ebuild:fonts? (
mirror://berlios/${PN}/${PN}-full-${PV}.tar.gz )
app-text/u2ps/u2ps-0.8.2.ebuild:SRC_URI=!fonts? (
mirror://berlios/${PN}/${P}.tar.gz )
app-text/u2ps/u2ps-0.8.2.ebuild:fonts? (
mirror://berlios/${PN}/${PN}-full-${PV}.tar.gz )
app-text/winefish/winefish-1.3.3-r1.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tgz
dev-cpp/libebt/libebt-1.3.0.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.bz2
dev-embedded/bitbake/bitbake-1.10.2.ebuild:
SRC_URI=mirror://berlios/${PN}/${P}.tar.gz
dev-embedded/bitbake/bitbake-1.12.0.ebuild:
SRC_URI=mirror://berlios/${PN}/${P}.tar.gz
dev-embedded/bitbake/bitbake-.ebuild:
SRC_URI=mirror://berlios/${PN}/${P}.tar.gz
dev-embedded/openocd/openocd-0.3.1-r1.ebuild:
SRC_URI=mirror://berlios/${PN}/${P}.tar.gz
dev-embedded/openocd/openocd-0.4.0.ebuild:
SRC_URI=mirror://berlios/${PN}/${P}.tar.gz
dev-embedded/usbprog/usbprog-0.2.0.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.bz2
dev-libs/libsmtp/libsmtp-0.8.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.gz
dev-python/iconvcodec/iconvcodec-1.1.2.ebuild:SRC_URI=mirror://berlios/cjkpython/${P}.tar.gz
dev-python/utidylib/utidylib-0.2-r1.ebuild:SRC_URI=mirror://berlios/${PN}/${MY_P}.zip
dev-ruby/ncurses-ruby/ncurses-ruby-1.2.4-r1.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.bz2
dev-ruby/ncurses-ruby/ncurses-ruby-1.2.4-r2.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.bz2
dev-ruby/ncurses-ruby/ncurses-ruby-1.3.1.ebuild:SRC_URI=mirror://berlios/${PN}/${P}.tar.bz2
dev-tex/qtexengine/qtexengine-0.2.ebuild:SRC_URI=mirror://berlios/qtiplot/${MY_PN}-${PV}-opensource.zip
Re: [gentoo-dev] Shutdown of berlios
2011/10/29 Kacper Kowalik xarthis...@gentoo.org: Would be easier if you told us who should fix what you lazy bum. Fixed in attached list. Prolly I should have opened a bug instead, but I'm lazy too :P I did it on purpose, I wanted anyone interested in those packages to work on them, not just the named herds/maintainers :) But yea I probably should post it along with the unordered list. Tom
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild
2011/10/23 Samuli Suominen ssuomi...@gentoo.org:
On 10/23/2011 04:27 PM, Rich Freeman wrote:
On Sun, Oct 23, 2011 at 8:39 AM, Samuli Suominen ssuomi...@gentoo.org
wrote:
On 10/23/2011 03:00 PM, Tomas Chvatal (scarabeus) wrote:
scarabeus 11/10/23 12:00:55
Modified: ChangeLog cdparanoia-3.10.2-r3.ebuild
Log:
Bump to eapi4 and punt static libs.
Time to revert this commit as I don't see anything in the ebuild that
disables building the static archives at compile phase.
This is same as hiding the problem, not solving it. Not the way we do
things at sound@.
+ use static-libs || find ${ED} -name '*.a' -exec rm -f {} +
Doesn't reverting this seem a bit like shooting yourself in the foot
to remove an ingrown toenail?
Unless I'm missing something this DOES get rid of the unneeded
archives. Now, sure, you'd save a few milliseconds of CPU if they
weren't built in the first place. However, you're proposing replacing
an ebuild that builds but doesn't install undesired files with one
that builds them AND installs them (since the hypothetical ebuild that
does neither doesn't exist yet).
Perfection shouldn't hold us back from improvement. By all means open
up a bug asking for the next level of improvement if it really bothers
people.
Now, if there is some subtle issue that causes issues during build if
the files are there and only removed at the last minute then clearly
that is a bigger problem.
If you only wanted to remove these files, you are free to use
INSTALL_MASK locally instead of downgrading the quality of tree.
Do you have any idea how much time me, and aballier spent to make
cdparanoia's build system as clean as it is now? And then to coordinate
them with upstream xiph.org?
Then I see this... Not acceptable by any standards.
So you would rather see me patch the makefile to drop the slib targets
conditionaly or alter whole src_compile to not run all but just lib on
the required options?
Both will take more space in the ebuild
Or should I actually make the build system correct and rewrite it into
automake to use libtool?
Both take quite a lot time and since you state that you waste so much
on the build system anyway why didn't you fix it even before?
Anyway Since you are in the herd feel free to revert it as you already did so.
For that I have question, WHY THE FUCK DID YOU REVERT IT NOT USING ANY
CHANGELOG MESSAGE? If you would log this you would prevent others from
doing the same commit as me in the future, but yeah they are
developers they should use cvs log on the directory to see what samuli
had on his mind this time...
Anyway for they yajl i tried to submit patches for the build system
once and upstream is not interested so this is clear solution to solve
the issue without me having to patch half of the CMakeLists.txt.
Re: [gentoo-dev] Moving more hardening features to default?
2011/10/20 Anthony G. Basile bluen...@gentoo.org: USE=hardened refers to only toolchain hardening. The problems there are mostly packages which break with PIE because they (ab)use assembly. Things like virtualbox and some codecs. This can become a thorny mess. It would probably be nearly painless to bring in -D_FORTIFY_SOURCES=2 and ssp into mainstream though. Packages which break because of either of those two features are broken and should be fixed anyhow. This sounds like good idea to do so, I would say that most hardened features should be merged to to main profile as soon as they won't cause major PITA for the regular users. Cheers Tom
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in app-admin/chrpath: ChangeLog chrpath-0.13-r2.ebuild
2011/10/12 Mike Frysinger vap...@gentoo.org:
On Wednesday 12 October 2011 15:44:53 Alec Warner wrote:
If I want to add a patch to the list I might forget to to add the \
admittedly, i hit this every once in a while, and with all the || die being
implicit, it doesn't get caught right away. fortunately latest portage will
issue a QA warning at the end along the lines of command not found:
${FILESDIR}/${P}-my-new.patch. so one can hope the maintainer tests their
ebuilds and reviews QA output before committing ;).
-mike
That is the reason for the patch array implemented in the base eclass
and why i want it in eapi5.
PATCHES=(
patch1 # mycomment
patch2 # another bug number
)
Example from wild:
PATCHES=(
${FILESDIR}/${PN}-includes-libs-perl.patch
${FILESDIR}/${PN}-fix_wrong_linker_opts.patch
${FILESDIR}/${PN}-1.0.2-no_harfbuzz_tests.patxh
)
See the typo on last patch.
Preparing source in
/var/tmp/portage/media-gfx/graphite2-1.0.3/work/graphite2-1.0.3 ...
* Applying graphite2-includes-libs-perl.patch ...
[ ok ]
* Applying graphite2-fix_wrong_linker_opts.patch ...
[ ok ]
* QA: File or directory
/home/scarabeus/gentoo/gentoo-x86/media-gfx/graphite2/files/graphite2-1.0.2-no_harfbuzz_tests.patxh
does not exist.
* QA: Check your PATCHES array or add missing file/directory.
* ERROR: media-gfx/graphite2-1.0.3 failed (prepare phase):
* Some patches failed. See above messages.
Which is why i really avoid calling epatch myself, the only reason is
to have conditional patches, which are root of all evil, because they
can be broken with update and you won't notice anyway.
Cheers
Tom
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in app-admin/chrpath: ChangeLog chrpath-0.13-r2.ebuild
Hmm for the command-not-found, it should be fatal not just warning I suppose. I was not even aware of this fancy portage feature :) Tom
Re: [gentoo-dev] Lastrite: media-gfx/pngcrush
Guys, the policy makes perfect sense, there are people that sync just monthly, so they might want to get some headsup why their packages are going away, and not just remove them. Thats why the recommended value is 60 days, 30 for urgent cases, lately we just moved to 30 for everything, but please stick with that, do not make it lower. This is not about waiting for maintainer, or slowing up distro, but letting our users to catch up with what we do. As a side note masked packages CAN be broken, so the stab can proceed from the point you mask all the broken ones. Tom
Re: [gentoo-dev] [RFC] obs eclasses
2011/9/20 Michał Górny mgo...@gentoo.org: On Tue, 13 Sep 2011 13:11:28 +0200 Michal Hrusecky mi...@gentoo.org wrote: please take a look at attached eclasses. Purpose is to make installation of obs services (plugins for osc) easier. Comments and improvements are welcome. I don't get the concept of having two eclasses for this. The first one looks more like a thirdpartymirrors entry. Not really, you can't use variables in third-party mirrors, and storing there all opensuse releases or opensuse projects to check is REALLY insane as the package is usually just on one project. So it is not a mirror at all, rather one download url with really complex path. Tom
Re: [gentoo-dev] git-2: a bunch of patches to review
0001 - i had reason to put local definitions on the top, it is way more readable to see right away what local vars function has, so please stick to it. 0004 - Did you ever hear that executing another code in condition is damn annoying to trace? :) 0007 - I placed it into the conditionals to be clear what is happening, what if there will be added another if without the push... 0010 - 0011 - I was serious with getting crashes on some packages with this approach (suprisingly i first really tried to make the eclass backcompat as much as possible), did you get anyone else to ack this thing? FWIW it is like fetching new packages, I can agree that dowloading whole qt or libreoffice can make someone sad, but it is just few megs compared to the rest of your weekly world update. - You are introducing possibility to nicely fail without any simple resolution why for almost no benefit. Cheers Tom
[gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages
Hi guys, as I am now messing around libreo I am meeting a lot packages that none bothered to stablereq since 2009 or so, the versions in ~ are cleaner, more up to date, and possibly contain less bugs. The issue here is that if some part of the tree looses lots of its maintainers we as devs usually manage to shape it up enough for us in testing but nobody ever bothers to wait that 30 days and open stablereq. So, the issue is obvious, we have packages in testing that are in better shape than stable ones. Testing requests for bumps are now handled by euscan +-, cool job for that website by Iksaf, and I thing we need something similary scanning the main tree for stables and instead of bugreports the arch teams would have queue. How would such thing work? Well it would be something like priority based queue with maximum 60 points value. Each update after the month in main tree would get 0 points for stabilisation, any-developer / maintainer would be able to add up to 40 points to any package and security team members would be able to add all 60 points. Security team/any developer would also have possibility to add new packages to queue manualy. Each user could vote for any package giving out 1 point up to 10 points (eg max voteup for 10 concurent packages). For each folowing month the package would gain another 10 points, unless disqualified by qa/maintainer where it has to be off the queue for 1 month (or disqualified indefinetly based on some version range, eg beta series is 2.5 so we don't want to stable). Then arch team would just go and stabilise based up on the queue where each AT or arch dev could mark it as working. If there are 3 acks from Arch testers then even maintainer can proceed with the addition of the keyword not having to wait for arch dev to test the package, reducing the workload on arch devs (hopefully). The key problem for whole app is that you need to make sure the queue is a) properly sorted b) each request has proper depgraph so things does not break for AT/devs. This could be achieved by running the script and solving the depgraph prior creating the request. Example: We have stable possibility for harfbuzz and libreoffice, libreoffice depends on harfbuzz. The application would open just one stablerequest for libreoffice where it would put everything pulled in by its depgraph including harfbuzz and no separate request for harfbuzz is opened. If harfbuzz would not be ready yet for stabilisation then the libreoffice would not be YET added to the queue untill the harfbuzz passes the 30 days too. Here the queue of course have to differ for other arches as sparc have keyword for harfbuzz but not libreoffice. So do you thing it is possible to write such web app/ do you know if anyone would be able to write so? If no I think I have proposal for next GSoC as mentor :P but I would really like to see it sooner. Cheers Tom PS: no i can't write it, I seriously lack a time for such thing so I am just trying to find out if anyone is interested to work on it or if you even thing this is a good idea.
Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages
2011/9/20 Tony Chainsaw Vroon chain...@gentoo.org: On Tue, 2011-09-20 at 23:18 +0200, Tomáš Chvátal wrote: Well it would be something like priority based queue with maximum 60 points value. Each update after the month in main tree would get 0 points for stabilisation, any-developer / maintainer would be able to add up to 40 points to any package and security team members would be able to add all 60 points. Security team/any developer would also have possibility to add new packages to queue manualy. This sounds to me like you are trying to automate common sense. If you see packages that have good ~arch ebuilds that appear to be fermenting, please file a bug. Rumours of unresponsive arch teams have been greatly exaggerated! The worst that could happen is that a more exotic arch sees your bug and decides sorry, we would rather unkeyword it rather than okay, we will stable that. Either way seems a valid outcome though? I can't speak for other arches than AMD64, but we are happy to receive more than the current influx of bugs, particularly if you are willing to take suggestions to heart (a lot of QA niggles get shaken out in AT reports lately). Regards, Tony V. I am not saying that Archs are unresponsive (well they are on ppc for example sometimes) but I try to solve other problem about finding what packages CAN go stable and nobody ever bothered to do a bugreport. Yeah we can do it by hand like robot and open bugs for zilions of packages just to get all the spell packages stable etc etc, but look on the euscan, it is quite usefull to have automatically generated report of what can you bump and what did you miss to update. Instead of waiting on maintainer/anyone to notice that you can stable something this would give you nice report itself. And usually when i update and qa clean some package in 30 days I don't even really remember which one it was :) Tom
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.2.ebuild ChangeLog wireshark-1.4.9.ebuild wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wireshark-1
2011/9/13 Markos Chandras hwoar...@gentoo.org: On 12/09/2011 09:55 μμ, Peter Volkov (pva) wrote: pva 11/09/12 18:55:52 Modified: ChangeLog Added: wireshark-1.6.2.ebuild wireshark-1.4.9.ebuild Removed: wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wireshark-1.4.4.ebuild wireshark-1.4.6-r1.ebuild Log: Version bump. Fixes security bug #381551, thank GLSAMaker/CVETool Bot. Added 1.6.2, bug #370683. 1.6.2 also fixes bug 373545 wrt Francesco Lamonica. Drop old. ... !!net-analyzer/wireshark-1.6.0_rc1 Why is wireshark blocking itself on DEPEND? is this a known bug that prevents normal update from old to new version? It is a bit odd to have to remove the existing installation in order to update to a new one - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 Actually this s**t happens a lot, due to broken build system the package links to the already in-system packages and use headers from system. So one has to block the major versions to avoid the breakages during the build Cheers Tom
Re: [gentoo-dev] [RFC] obs eclasses
2011/9/13 Ulrich Mueller u...@gentoo.org: On Tue, 13 Sep 2011, Donnie Berkholz wrote: Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. I would really like if we do it properly this time. So it is done for goot and does not reappear from time to time. If you read the quoted council log, you'll find that the retroactive change was done because usage of bash 3.2 features in the tree was already widespread at that time. This is very different from the current situation, therefore it is not at all a precedent. As is Ulrich saying, it was done because everyone at that point was using such features. Not because we wanted those features to be used. Cheers Tom
Re: [gentoo-dev] Re: Committing packages with unfetchable sources [sys-devel/gdb-7.3.1]
2011/9/9 Mike Frysinger vap...@gentoo.org: On Wednesday, September 07, 2011 03:20:01 Tomáš Chvátal wrote: please stop committing packages that is not possible to fetch right away. You can pick from three options: a) stop using mirrors://gentoo/ and put it on dev.gentoo.org to your public_html like most of us do b) mask the package until the file is propagated to the mirrors and then unmask it c) commit it after few hours you pushed the tarball to mirrors so you can be sure it is fetchable you're confusing things. the issue has nothing to do with transient delay of hitting the mirrors but me forgetting to upload it off my machine. This is more than annoying to have failing build on your update just because of your lazyness. you might want to learn how to file bugs and refrain from personal attacks. -mike Mike you did this multiple times, that you just commit it off at the time when you added it on pecker, which led to sources not being fetchable. So it was quite safe assumption that you did it again. My apologies since you say that it was not the case this time.
Re: [gentoo-dev] Rewriting bash-completion.eclass
2011/9/8 Michał Górny mgo...@gentoo.org: Done. Also, added an example. If nobody has further objections, I'll commit this today. -- Best regards, Michał Górny Dunno but shouldn't there be two fields one for AUTHOR and one for MAINTAINER, Also in the code do not use the autotols-utils... but just plain default.
[gentoo-dev] Re: Committing packages with unfetchable sources [sys-devel/gdb-7.3.1]
Resending as i sent it from gmail instead of google acc so it didn't hit the list. Dne 7. září 2011 9:20 Tomáš Chvátal tomas.chva...@gmail.com napsal(a): Hi, please stop committing packages that is not possible to fetch right away. You can pick from three options: a) stop using mirrors://gentoo/ and put it on dev.gentoo.org to your public_html like most of us do b) mask the package until the file is propagated to the mirrors and then unmask it c) commit it after few hours you pushed the tarball to mirrors so you can be sure it is fetchable This is more than annoying to have failing build on your update just because of your lazyness. Tom
[gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
Resending as i sent it from gmail instead of google acc so it didn't hit the list. -- Přeposlaná zpráva -- Od: Tomáš Chvátal tomas.chva...@gmail.com Datum: 5. září 2011 18:08 Předmět: Re: [gentoo-dev-announce] Call for items for September 13 council meeting Komu: gentoo-dev@lists.gentoo.org Start collecting ideas for EAPI5. I myself would like PATCHES array to be default in src_prepare phase and some solution for runtime optional deps, Instead of elog in postinst something like Recommended from rpm. Cheers Tom
Re: [gentoo-dev] Autodep project
Hi, really cool thing you create :) Would it be possible to move that package to main tree, and merge or possibly add new FEATURES option to portage like autobuildchecks that would be set by -dev profile? Cheers Tom
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
2011/9/7 Ulrich Mueller u...@gentoo.org: On Wed, 7 Sep 2011, Tomáš Chvátal wrote: Start collecting ideas for EAPI5. I suggest that EAPI 5 should include the two features that have been omitted from EAPI 4 [1,2]. Apart from this, I think we should be more careful for the next EAPI, in order to avoid such long delays as we had with EAPI 4. One possible solution would be to only accept features where a preliminary implementation in Portage is available. Agreed the wait last time was really bad. I myself would like PATCHES array to be default in src_prepare phase and some solution for runtime optional deps, Instead of elog in postinst something like Recommended from rpm. Looks reasonable (if an implementation is ready). Although I don't understand how it is related to rpm. Well the patches code is in base eclass. For Recommended it works like this: blabla.spec Recommended: xf86-video-ati zypper in blabla ... You might consider installing these additional packages: xf86-video-ati It for sure needs more thinking as this is just basic idea. It might even take into account that if you install the recommended patckage with oneshot it should not be depcleaned unless all recommending packages are gone too, and so on.
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
Dne 1.9.2011 09:44, Corentin Chary napsal(a): On Thu, Sep 1, 2011 at 9:23 AM, Alex Leglera...@gentoo.org wrote: On Wednesday 31 August 2011 15:41:51 Corentin Chary wrote: Hi, some news about euscan (still available at http://euscan.iksaif.net) - New design (yay !) Glad you like it. Be sure to credit where you got it from, though. Sorry, that was done in the dev version, but I forgot to push it (http://euscan.iksaif.net/about/). Thanks, So now we just need to put this onto gentoo infrastructure and make you dev :P Btw I have feature request, could it remember the sorting method i set? (so I don't have to click and reorder it every time i refresh) Cheers Tom
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
Dne 1.9.2011 09:55, Corentin Chary napsal(a): Btw I have feature request, could it remember the sorting method i set? (so I don't have to click and reorder it every time i refresh) Per-page or globally ? I would say globaly i smore sane here Tom
Re: [gentoo-dev] [RFC] check-reqs.eclass.patch
Addressed last bunch of suggestions :)
Tom
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v 1.8 2011/08/22
04:46:31 vapier Exp $
# @ECLASS: check-reqs.eclass
# @MAINTAINER:
# QA Team q...@gentoo.org
# @AUTHOR:
# Bo Ørsted Andresen z...@gentoo.org
# Original Author: Ciaran McCreesh ciar...@gentoo.org
# @BLURB: Provides a uniform way of handling ebuild which have very high build
requirements
# @DESCRIPTION:
# This eclass provides a uniform way of handling ebuilds which have very high
# build requirements in terms of memory or disk space. It provides a function
# which should usually be called during pkg_setup().
#
# The chosen action only happens when the system's resources are detected
# correctly and only if they are below the threshold specified by the package.
#
# @CODE
# # need this much memory (does *not* check swap)
# CHECKREQS_MEMORY=256M
#
# # need this much temporary build space
# CHECKREQS_DISK_BUILD=2G
#
# # install will need this much space in /usr
# CHECKREQS_DISK_USR=1G
#
# # install will need this much space in /var
# CHECKREQS_DISK_VAR=1024M
#
# @CODE
#
# If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is not
# carried out.
#
# These checks should probably mostly work on non-Linux, and they should
# probably degrade gracefully if they don't. Probably.
inherit eutils
# @ECLASS-VARIABLE: CHECKREQS_MEMORY
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much RAM is needed? Eg.: CHECKREQS_MEMORY=15M
# @ECLASS-VARIABLE: CHECKREQS_DISK_BUILD
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much diskspace is needed to build the package? Eg.:
CHECKREQS_DISK_BUILD=2T
# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space in /usr is needed to install the package? Eg.:
CHECKREQS_DISK_USR=15G
# @ECLASS-VARIABLE: CHECKREQS_DISK_VAR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M
EXPORT_FUNCTIONS pkg_setup
case ${EAPI:-0} in
0|1|2|3) ;;
4) EXPORT_FUNCTIONS pkg_pretend ;;
*) die EAPI=${EAPI} is not supported ;;
esac
# @FUNCTION: check_reqs
# @DESCRIPTION:
# Obsolete function executing all the checks and priting out results
check_reqs() {
debug-print-function ${FUNCNAME} $@
echo
ewarn QA: Package calling old ${FUNCNAME} function.
ewarn QA: Please file a bug against the package.
ewarn QA: It should call check-reqs_pkg_pretend and
check-reqs_pkg_setup
ewarn QA: and possibly use EAPI=4 or later.
echo
check-reqs_pkg_setup $@
}
# @FUNCTION: check-reqs_pkg_setup
# @DESCRIPTION:
# Exported function running the resources checks in pkg_setup phase.
# It should be run in both phases to ensure condition changes between
# pkg_pretend and pkg_setup won't affect the build.
check-reqs_pkg_setup() {
debug-print-function ${FUNCNAME} $@
check-reqs_prepare
check-reqs_run
check-reqs_output
}
# @FUNCTION: check-reqs_pkg_pretend
# @DESCRIPTION:
# Exported function running the resources checks in pkg_pretend phase.
check-reqs_pkg_pretend() {
debug-print-function ${FUNCNAME} $@
check-reqs_pkg_setup $@
}
# @FUNCTION: check-reqs_prepare
# @DESCRIPTION:
# Internal function that checks the variables that should be defined.
check-reqs_prepare() {
debug-print-function ${FUNCNAME} $@
if [[ -z ${CHECKREQS_MEMORY}
-z ${CHECKREQS_DISK_BUILD}
-z ${CHECKREQS_DISK_USR}
-z ${CHECKREQS_DISK_VAR} ]]; then
eerror Set some check-reqs eclass variables if you want to use
it.
eerror If you are user and see this message fill a bug against
the package.
die ${FUNCNAME}: check-reqs eclass called but not actualy
used!
fi
}
# @FUNCTION: check-reqs_run
# @DESCRIPTION:
# Internal function that runs the check based on variable settings.
check-reqs_run() {
debug-print-function ${FUNCNAME} $@
# some people are *censored*
unset CHECKREQS_FAILED
[[ -n ${CHECKREQS_MEMORY} ]] \
check-reqs_memory \
${CHECKREQS_MEMORY}
[[ -n ${CHECKREQS_DISK_BUILD} ]] \
check-reqs_disk \
${T} \
${CHECKREQS_DISK_BUILD}
[[ -n ${CHECKREQS_DISK_USR} ]] \
check-reqs_disk \
${EROOT}/usr \
${CHECKREQS_DISK_USR}
[[ -n ${CHECKREQS_DISK_VAR} ]] \
check-reqs_disk \
${EROOT}/var \
${CHECKREQS_DISK_VAR}
}
# @FUNCTION: check-reqs_get_megs
# @DESCRIPTION:
# Internal function that returns number in mebibytes.
# Converts from 1G=1024 or 1T=1048576
check-reqs_get_mebibytes() {
Re: [gentoo-dev] Rewriting bash-completion.eclass
Dne 1.9.2011 14:48, Michał Górny napsal(a): Hello, Our bash-completion.eclass is awful and ugly. I'm not even talking about flags and stuff now but dobashcompletion() itself. That function doesn't follow do*() argument scheme; it matches rather one used by new*() funcs. Sadly, a number of ebuilds is using that scheme to rename installed file. Furthermore, it uses two eclass variables to switch the behavior. BASHCOMPFILES allows it to install multiple files (but works only if no arguments are passed). BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is not used) and makes it ignore the second argument. I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? I would go with the eutils.eclass update, but remember that you have to keep backcompat for the old call :( Tom
Re: [gentoo-dev] Rewriting bash-completion.eclass
Dne 1.9.2011 15:15, Michał Górny napsal(a): On Thu, 01 Sep 2011 14:56:42 +0200 Tomáš Chvátalscarab...@gentoo.org wrote: That function doesn't follow do*() argument scheme; it matches rather one used by new*() funcs. Sadly, a number of ebuilds is using that scheme to rename installed file. Furthermore, it uses two eclass variables to switch the behavior. BASHCOMPFILES allows it to install multiple files (but works only if no arguments are passed). BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is not used) and makes it ignore the second argument. I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? I would go with the eutils.eclass update, but remember that you have to keep backcompat for the old call :( Ah, forgot about stats. dobashcompletion() with two args is used a lot of times. BASHCOMPFILES is used in ONE ebuild in gx86. BASHCOMPLETION_NAME is used in 4-5 ebuilds. We can either go with a new func and retroactively replace the eclass, or retroactively fix all uses and fix the old funcs. how about new calls completely? dobashcomp newbashcomp As even if you fix main tree you can't ensure that you won't mess with some overlay (silently as it would not be seen by default). I would then go proactively and fix the packages inheriting the bashcomp eclass and when done just mark the eclass as dead. Tom
Re: [gentoo-dev] Re: [RFC] office-ext.eclass
Dne 31.8.2011 01:09, Jonathan Callen napsal(a):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Tomáš Chvátal wrote:
die Unable not determine libreoffice/openoffice implementation!
Unable to determine ...
- --
Jonathan Callen
Thanks, replaced.
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: office-ext.eclass
# @AUTHOR:
# Tomáš Chvátal scarab...@gentoo.org
# @MAINTAINER:
# The office team openoff...@gentoo.org
# @BLURB: Eclass for installing libreoffice/openoffice extensions
# @DESCRIPTION:
# Eclass for easing maitenance of libreoffice/openoffice extensions.
case ${EAPI:-0} in
4) OEXT_EXPORTED_FUNCTIONS=src_install pkg_postinst pkg_prerm ;;
*) die EAPI=${EAPI} is not supported ;;
esac
EXPORT_FUNCTIONS ${OEXT_EXPORTED_FUNCTIONS}
unset OEXT_EXPORTED_FUNCTIONS
inherit eutils multilib
UNOPKG_BINARY=${EPREFIX}/usr/bin/unopkg
# @ECLASS-VARIABLE: OO_EXTENSIONS
# @REQUIRED
# @DESCRIPTION:
# Array containing list of extensions to install.
[[ -z ${OO_EXTENSIONS} ]] die OO_EXTENSIONS variable is unset.
if [[ $(declare -p OO_EXTENSIONS 2/dev/null 21) != declare -a* ]]; then
die OO_EXTENSIONS variable is not an array.
fi
DEPEND=virtual/ooo
RDEPEND=virtual/ooo
# @FUNCTION: office-ext_flush_unopkg_cache
# @DESCRIPTION:
# Flush the cache after removal of an extension.
office-ext_flush_unopkg_cache() {
debug-print-function ${FUNCNAME} $@
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} list --shared /dev/null
${UNOPKG_BINARY} list --shared /dev/null
}
# @FUNCTION: office-ext_get_implementation
# @DESCRIPTION:
# Determine the implementation we are building against.
office-ext_get_implementation() {
debug-print-function ${FUNCNAME} $@
local implementations=(
libreoffice
openoffice
)
local i
for i in ${implementations[@]}; do
if [[ -d ${EPREFIX}/usr/$(get_libdir)/${i} ]]; then
debug-print ${FUNCNAME}: Determined implementation is:
\${EPREFIX}/usr/$(get_libdir)/${i}\
echo ${EPREFIX}/usr/$(get_libdir)/${i}
return
fi
done
die Unable to determine libreoffice/openoffice implementation!
}
# @FUNCTION: office-ext_add_extension
# @DESCRIPTION:
# Install the extension into the libreoffice/openoffice.
office-ext_add_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$1
local tmpdir=$(mktemp -d --tmpdir=${T})
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} add --shared \${ext}\
ebegin Adding extension: \${ext}\
${UNOPKG_BINARY} add --shared ${ext} \
-env:UserInstallation=file:///${tmpdir} \
-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1
eend $?
rm -rf ${tmpdir}
}
# @FUNCTION: office-ext_remove_extension
# @DESCRIPTION:
# Remove the extension from the libreoffice/openoffice.
office-ext_remove_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$1
local tmpdir=$(mktemp -d --tmpdir=${T})
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} remove --shared \${ext}\
ebegin Removing extension: \${ext}\
${UNOPKG_BINARY} remove --shared ${ext} \
-env:UserInstallation=file:///${tmpdir} \
-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1
eend $?
flush_unopkg_cache
rm -rf ${tmpdir}
}
# @FUNCTION: office-ext_src_install
# @DESCRIPTION:
# Install the extension source to the proper location.
office-ext_src_install() {
debug-print-function ${FUNCNAME} $@
local i
# subshell to not pollute rest of the env with the insinto redefinition
(
insinto
$(openoffice-ext_get_implementation)/share/extension/install/
for i in ${OO_EXTENSIONS[@]}; do
doins ${i}
done
)
einfo Remember that if you replace your office implementation,
einfo you need to recompile all the extensions.
einfo Your current implementation location is:
einfo $(openoffice-ext_get_implementation)
}
# @FUNCTION: office-ext_pkg_postinst
# @DESCRIPTION:
# Add the extensions to the libreoffice/openoffice.
office-ext_pkg_postinst() {
debug-print-function ${FUNCNAME} $@
local i
for i in ${OO_EXTENSIONS[$@]}; do
openoffice-ext_add_extension ${i}
done
}
# @FUNCTION: office-ext_pkg_prerm
# @DESCRIPTION:
# Remove the extensions from the libreoffice/openoffice.
office-ext_pkg_prerm() {
debug-print-function ${FUNCNAME} $@
local i
for i in ${OO_EXTENSIONS[@]}; do
openoffice-ext_remove_extension ${i}
done
}
Re: [gentoo-dev] [RFC] check-reqs.eclass.patch
Thanks for all the pointers, hopefully I addressed all issues raised by
both of you :)
Good pointer is that we should probably check if the MERGE_TYPE=binary
and not check-reqs ram and disk_build in that case.
But there is slight problem how to do it in older eapis.
Also Michal if you want to have that DISK array thingu there could you
write a patch?
Tom
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v 1.8 2011/08/22
04:46:31 vapier Exp $
# @ECLASS: check-reqs.eclass
# @MAINTAINER:
# QA Team q...@gentoo.org
# @AUTHOR:
# Bo Ørsted Andresen z...@gentoo.org
# Original Author: Ciaran McCreesh ciar...@gentoo.org
# @BLURB: Provides a uniform way of handling ebuild which have very high build
requirements
# @DESCRIPTION:
# This eclass provides a uniform way of handling ebuilds which have very high
# build requirements in terms of memory or disk space. It provides a function
# which should usually be called during pkg_setup().
#
# The chosen action only happens when the system's resources are detected
# correctly and only if they are below the threshold specified by the package.
#
# @CODE
# # need this much memory (does *not* check swap)
# CHECKREQS_MEMORY=256M
#
# # need this much temporary build space
# CHECKREQS_DISK_BUILD=2G
#
# # install will need this much space in /usr
# CHECKREQS_DISK_USR=1G
#
# # install will need this much space in /var
# CHECKREQS_DISK_VAR=1024M
#
# # go!
# pkg_pretend() {
#check-reqs_pkg_pretend
# }
#
# # Run once again to ensure that environment didn't
# # change since the pretend phase.
# pkg_setup() {
#check-reqs_pkg_setup
# }
# @CODE
#
# If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is not
# carried out.
#
# These checks should probably mostly work on non-Linux, and they should
# probably degrade gracefully if they don't. Probably.
inherit eutils
# @ECLASS-VARIABLE: CHECKREQS_MEMORY
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much RAM is needed?
# @ECLASS-VARIABLE: CHECKREQS_DISK_BUILD
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much diskspace is needed to build the package?
# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space in /usr is needed to install the package?
# @ECLASS-VARIABLE: CHECKREQS_DISK_VAR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space is needed in /var?
EXPORT_FUNCTIONS pkg_setup
case ${EAPI:-0} in
0|1|2|3) ;;
4) EXPORT_FUNCTIONS pkg_pretend ;;
*) die EAPI=${EAPI} is not supported ;;
esac
# @FUNCTION: check_reqs
# @DESCRIPTION:
# Obsolete function executing all the checks and priting out results
check_reqs() {
debug-print-function ${FUNCNAME} $@
echo
ewarn QA: Package calling old ${FUNCNAME} function.
ewarn QA: Please file a bug against the package.
ewarn QA: It should call check-reqs_pkg_pretend and
check-reqs_pkg_setup
ewarn QA: and possibly use EAPI=4 or later.
echo
check-reqs_pkg_setup $@
}
# @FUNCTION: check-reqs_pkg_setup
# @DESCRIPTION:
# Exported function running the resources checks in pkg_setup phase.
# It should be run in both phases to ensure condition changes between
# pkg_pretend and pkg_setup won't affect the build.
check-reqs_pkg_setup() {
debug-print-function ${FUNCNAME} $@
check-reqs_prepare
check-reqs_run
check-reqs_output
}
# @FUNCTION: check-reqs_pkg_pretend
# @DESCRIPTION:
# Exported function running the resources checks in pkg_pretend phase.
check-reqs_pkg_pretend() {
debug-print-function ${FUNCNAME} $@
check-reqs_pkg_setup $@
}
# @FUNCTION: check-reqs_prepare
# @DESCRIPTION:
# Internal function that checks the variables that should be defined.
check-reqs_prepare() {
debug-print-function ${FUNCNAME} $@
if [[ -z ${CHECKREQS_MEMORY}
-z ${CHECKREQS_DISK_BUILD}
-z ${CHECKREQS_DISK_USR}
-z ${CHECKREQS_DISK_VAR} ]]; then
eerror Set some check-reqs eclass variables if you want to use
it.
eerror If you are user and see this message fill a bug against
the package.
die ${FUNCNAME}: check-reqs eclass called but not actualy
used!
fi
}
# @FUNCTION: check-reqs_run
# @DESCRIPTION:
# Internal function that runs the check based on variable settings.
check-reqs_run() {
debug-print-function ${FUNCNAME} $@
# some people are *censored*
unset CHECKREQS_FAILED
[[ -n ${CHECKREQS_MEMORY} ]] \
check-reqs_memory \
${CHECKREQS_MEMORY}
[[ -n ${CHECKREQS_DISK_BUILD} ]] \
check-reqs_disk \
${T} \
${CHECKREQS_DISK_BUILD}
[[ -n ${CHECKREQS_DISK_USR} ]] \
check-reqs_disk \
${EROOT}/usr \
[gentoo-dev] [RFC] category for openoffice/libreoffice extensions
Hi, would it be sane to create new category for the extensions of the libreoffice? There will be more than handful of them when we add the office-ext eclass and start adding them to the main tree. I think it could go to office-plugins/ category, any other suggestions? Cheers Tom
Re: [gentoo-dev] [RFC] check-reqs.eclass.patch
Dne 31.8.2011 12:14, Michał Górny napsal(a):
On Wed, 32 Aug 2011 10:57:08 +0200
Tomáš Chvátalscarab...@gentoo.org wrote:
Good pointer is that we should probably check if the
MERGE_TYPE=binary and not check-reqs ram and disk_build in that case.
But there is slight problem how to do it in older eapis.
We simply don't. Life is hard :P.
Meh in that case i will make it same on all eapis and just won't check
for that :)
gibibytes, mebibytes, tebibytes.
I preffer binary units over this fancy standard :)
Even our tools return the binary calculated ones not the decadic ones.
actual_memory=$(sed -n -e '/MemTotal:/s/^[^:]*:
*\([0-9]\+\) kB/\1/p' \ /proc/meminfo)
awk '/MemTotal/ { print $2 }' /proc/meminfo
Just raw copy from old eclass, didn't feel like updating it, but since
you did it I incorporated it :)
space_megs=$(df -Pm ${1} 2/dev/null | sed -n \
'$s/\(\S\+\s\+\)\{3\}\([0-9]\+\).*/\2/p' 2/dev/null)
OMFG.
space_megs=$(df -Pm ${1} 2/dev/null | awk 'FNR == 2 {print $4}')
I guess.
Hehe same as above
Rest I hopefully applied. Lemme know if you find something else.
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v 1.8 2011/08/22
04:46:31 vapier Exp $
# @ECLASS: check-reqs.eclass
# @MAINTAINER:
# QA Team q...@gentoo.org
# @AUTHOR:
# Bo Ørsted Andresen z...@gentoo.org
# Original Author: Ciaran McCreesh ciar...@gentoo.org
# @BLURB: Provides a uniform way of handling ebuild which have very high build
requirements
# @DESCRIPTION:
# This eclass provides a uniform way of handling ebuilds which have very high
# build requirements in terms of memory or disk space. It provides a function
# which should usually be called during pkg_setup().
#
# The chosen action only happens when the system's resources are detected
# correctly and only if they are below the threshold specified by the package.
#
# @CODE
# # need this much memory (does *not* check swap)
# CHECKREQS_MEMORY=256M
#
# # need this much temporary build space
# CHECKREQS_DISK_BUILD=2G
#
# # install will need this much space in /usr
# CHECKREQS_DISK_USR=1G
#
# # install will need this much space in /var
# CHECKREQS_DISK_VAR=1024M
#
# @CODE
#
# If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is not
# carried out.
#
# These checks should probably mostly work on non-Linux, and they should
# probably degrade gracefully if they don't. Probably.
inherit eutils
# @ECLASS-VARIABLE: CHECKREQS_MEMORY
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much RAM is needed? (15M)
# @ECLASS-VARIABLE: CHECKREQS_DISK_BUILD
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much diskspace is needed to build the package? (13G)
# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space in /usr is needed to install the package? (2T)
# @ECLASS-VARIABLE: CHECKREQS_DISK_VAR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space is needed in /var? (3000M)
DEPEND=sys-apps/gawk
EXPORT_FUNCTIONS pkg_setup
case ${EAPI:-0} in
0|1|2|3) ;;
4) EXPORT_FUNCTIONS pkg_pretend ;;
*) die EAPI=${EAPI} is not supported ;;
esac
# @FUNCTION: check_reqs
# @DESCRIPTION:
# Obsolete function executing all the checks and priting out results
check_reqs() {
debug-print-function ${FUNCNAME} $@
echo
ewarn QA: Package calling old ${FUNCNAME} function.
ewarn QA: Please file a bug against the package.
ewarn QA: It should call check-reqs_pkg_pretend and
check-reqs_pkg_setup
ewarn QA: and possibly use EAPI=4 or later.
echo
check-reqs_pkg_setup $@
}
# @FUNCTION: check-reqs_pkg_setup
# @DESCRIPTION:
# Exported function running the resources checks in pkg_setup phase.
# It should be run in both phases to ensure condition changes between
# pkg_pretend and pkg_setup won't affect the build.
check-reqs_pkg_setup() {
debug-print-function ${FUNCNAME} $@
check-reqs_prepare
check-reqs_run
check-reqs_output
}
# @FUNCTION: check-reqs_pkg_pretend
# @DESCRIPTION:
# Exported function running the resources checks in pkg_pretend phase.
check-reqs_pkg_pretend() {
debug-print-function ${FUNCNAME} $@
check-reqs_pkg_setup $@
}
# @FUNCTION: check-reqs_prepare
# @DESCRIPTION:
# Internal function that checks the variables that should be defined.
check-reqs_prepare() {
debug-print-function ${FUNCNAME} $@
if [[ -z ${CHECKREQS_MEMORY}
-z ${CHECKREQS_DISK_BUILD}
-z ${CHECKREQS_DISK_USR}
-z ${CHECKREQS_DISK_VAR} ]]; then
eerror Set some check-reqs eclass variables if you want to use
it.
eerror If you are user and see this message fill a bug against
the package.
die ${FUNCNAME}: check-reqs eclass called but not actualy
used!
fi
}
# @FUNCTION:
Re: [gentoo-dev] [RFC] check-reqs.eclass.patch
Dne 31.8.2011 14:38, Michał Górny napsal(a):
On Wed, 31 Aug 2011 12:32:03 +0200
Tomáš Chvátalscarab...@gentoo.org wrote:
gibibytes, mebibytes, tebibytes.
I preffer binary units over this fancy standard :)
Even our tools return the binary calculated ones not the decadic ones.
These are binary units, rather those fancy misnamed binary units of
yours. It's not fancy standard, it's the ONLY standard :P.
# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space in /usr is needed to install the package? (2T)
Not this looks like a insane default :D.
[G]) echo $((1024 * ${size})) ;;
just 'G)', 'M)', 'T)'.
ebegin Checking for at least ${sizeunit} ${3}
What ${3} there? I think you should decide whether to name all vars, or
use numeric ones.
# @FUNCTION: check-reqs_unsattisfied
docstring not updated.
How about now?
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v 1.8 2011/08/22
04:46:31 vapier Exp $
# @ECLASS: check-reqs.eclass
# @MAINTAINER:
# QA Team q...@gentoo.org
# @AUTHOR:
# Bo Ørsted Andresen z...@gentoo.org
# Original Author: Ciaran McCreesh ciar...@gentoo.org
# @BLURB: Provides a uniform way of handling ebuild which have very high build
requirements
# @DESCRIPTION:
# This eclass provides a uniform way of handling ebuilds which have very high
# build requirements in terms of memory or disk space. It provides a function
# which should usually be called during pkg_setup().
#
# The chosen action only happens when the system's resources are detected
# correctly and only if they are below the threshold specified by the package.
#
# @CODE
# # need this much memory (does *not* check swap)
# CHECKREQS_MEMORY=256M
#
# # need this much temporary build space
# CHECKREQS_DISK_BUILD=2G
#
# # install will need this much space in /usr
# CHECKREQS_DISK_USR=1G
#
# # install will need this much space in /var
# CHECKREQS_DISK_VAR=1024M
#
# @CODE
#
# If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is not
# carried out.
#
# These checks should probably mostly work on non-Linux, and they should
# probably degrade gracefully if they don't. Probably.
inherit eutils
# @ECLASS-VARIABLE: CHECKREQS_MEMORY
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much RAM is needed? Eg.: CHECKREQS_MEMORY=15M
# @ECLASS-VARIABLE: CHECKREQS_DISK_BUILD
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much diskspace is needed to build the package? Eg.:
CHECKREQS_DISK_BUILD=2T
# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space in /usr is needed to install the package? Eg.:
CHECKREQS_DISK_USR=15G
# @ECLASS-VARIABLE: CHECKREQS_DISK_VAR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M
DEPEND=sys-apps/gawk
EXPORT_FUNCTIONS pkg_setup
case ${EAPI:-0} in
0|1|2|3) ;;
4) EXPORT_FUNCTIONS pkg_pretend ;;
*) die EAPI=${EAPI} is not supported ;;
esac
# @FUNCTION: check_reqs
# @DESCRIPTION:
# Obsolete function executing all the checks and priting out results
check_reqs() {
debug-print-function ${FUNCNAME} $@
echo
ewarn QA: Package calling old ${FUNCNAME} function.
ewarn QA: Please file a bug against the package.
ewarn QA: It should call check-reqs_pkg_pretend and
check-reqs_pkg_setup
ewarn QA: and possibly use EAPI=4 or later.
echo
check-reqs_pkg_setup $@
}
# @FUNCTION: check-reqs_pkg_setup
# @DESCRIPTION:
# Exported function running the resources checks in pkg_setup phase.
# It should be run in both phases to ensure condition changes between
# pkg_pretend and pkg_setup won't affect the build.
check-reqs_pkg_setup() {
debug-print-function ${FUNCNAME} $@
check-reqs_prepare
check-reqs_run
check-reqs_output
}
# @FUNCTION: check-reqs_pkg_pretend
# @DESCRIPTION:
# Exported function running the resources checks in pkg_pretend phase.
check-reqs_pkg_pretend() {
debug-print-function ${FUNCNAME} $@
check-reqs_pkg_setup $@
}
# @FUNCTION: check-reqs_prepare
# @DESCRIPTION:
# Internal function that checks the variables that should be defined.
check-reqs_prepare() {
debug-print-function ${FUNCNAME} $@
if [[ -z ${CHECKREQS_MEMORY}
-z ${CHECKREQS_DISK_BUILD}
-z ${CHECKREQS_DISK_USR}
-z ${CHECKREQS_DISK_VAR} ]]; then
eerror Set some check-reqs eclass variables if you want to use
it.
eerror If you are user and see this message fill a bug against
the package.
die ${FUNCNAME}: check-reqs eclass called but not actualy
used!
fi
}
# @FUNCTION: check-reqs_run
# @DESCRIPTION:
# Internal function that runs the check based on variable settings.
check-reqs_run() {
debug-print-function
Re: [gentoo-dev] [RFC] check-reqs.eclass.patch
Dne 31.8.2011 17:30, Michał Górny napsal(a):
DEPEND=sys-apps/gawk
gawk is in the system set. If you really want to DEP on it explicitly,
maybe we should create a virtual, as any POSIX-compliant awk will
handle this.
# Temporary workaround for unset units.
# Backcompat.
[[ ${unit//*([[:digit:]])} ]] || unit=M
case ${unit} in
G) echo Gibibytes ;;
M) echo Mebibytes ;;
T) echo Tebibytes ;;
*)
die ${FUNCNAME}: Unknown unit: ${unit}
;;
esac
}
case ${unit} in
[M0-9]) echo mebibytes ;;
...
And yes, they actually shall be written lowercase [1].
[1]:http://www.bipm.org/en/si/si_brochure/chapter5/5-2.html
Wonder if it would not be easier just to talk on irc so we don't bother
everyone :P
Anyway addressed :)
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v 1.8 2011/08/22
04:46:31 vapier Exp $
# @ECLASS: check-reqs.eclass
# @MAINTAINER:
# QA Team q...@gentoo.org
# @AUTHOR:
# Bo Ørsted Andresen z...@gentoo.org
# Original Author: Ciaran McCreesh ciar...@gentoo.org
# @BLURB: Provides a uniform way of handling ebuild which have very high build
requirements
# @DESCRIPTION:
# This eclass provides a uniform way of handling ebuilds which have very high
# build requirements in terms of memory or disk space. It provides a function
# which should usually be called during pkg_setup().
#
# The chosen action only happens when the system's resources are detected
# correctly and only if they are below the threshold specified by the package.
#
# @CODE
# # need this much memory (does *not* check swap)
# CHECKREQS_MEMORY=256M
#
# # need this much temporary build space
# CHECKREQS_DISK_BUILD=2G
#
# # install will need this much space in /usr
# CHECKREQS_DISK_USR=1G
#
# # install will need this much space in /var
# CHECKREQS_DISK_VAR=1024M
#
# @CODE
#
# If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is not
# carried out.
#
# These checks should probably mostly work on non-Linux, and they should
# probably degrade gracefully if they don't. Probably.
inherit eutils
# @ECLASS-VARIABLE: CHECKREQS_MEMORY
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much RAM is needed? Eg.: CHECKREQS_MEMORY=15M
# @ECLASS-VARIABLE: CHECKREQS_DISK_BUILD
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much diskspace is needed to build the package? Eg.:
CHECKREQS_DISK_BUILD=2T
# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space in /usr is needed to install the package? Eg.:
CHECKREQS_DISK_USR=15G
# @ECLASS-VARIABLE: CHECKREQS_DISK_VAR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M
EXPORT_FUNCTIONS pkg_setup
case ${EAPI:-0} in
0|1|2|3) ;;
4) EXPORT_FUNCTIONS pkg_pretend ;;
*) die EAPI=${EAPI} is not supported ;;
esac
# @FUNCTION: check_reqs
# @DESCRIPTION:
# Obsolete function executing all the checks and priting out results
check_reqs() {
debug-print-function ${FUNCNAME} $@
echo
ewarn QA: Package calling old ${FUNCNAME} function.
ewarn QA: Please file a bug against the package.
ewarn QA: It should call check-reqs_pkg_pretend and
check-reqs_pkg_setup
ewarn QA: and possibly use EAPI=4 or later.
echo
check-reqs_pkg_setup $@
}
# @FUNCTION: check-reqs_pkg_setup
# @DESCRIPTION:
# Exported function running the resources checks in pkg_setup phase.
# It should be run in both phases to ensure condition changes between
# pkg_pretend and pkg_setup won't affect the build.
check-reqs_pkg_setup() {
debug-print-function ${FUNCNAME} $@
check-reqs_prepare
check-reqs_run
check-reqs_output
}
# @FUNCTION: check-reqs_pkg_pretend
# @DESCRIPTION:
# Exported function running the resources checks in pkg_pretend phase.
check-reqs_pkg_pretend() {
debug-print-function ${FUNCNAME} $@
check-reqs_pkg_setup $@
}
# @FUNCTION: check-reqs_prepare
# @DESCRIPTION:
# Internal function that checks the variables that should be defined.
check-reqs_prepare() {
debug-print-function ${FUNCNAME} $@
if [[ -z ${CHECKREQS_MEMORY}
-z ${CHECKREQS_DISK_BUILD}
-z ${CHECKREQS_DISK_USR}
-z ${CHECKREQS_DISK_VAR} ]]; then
eerror Set some check-reqs eclass variables if you want to use
it.
eerror If you are user and see this message fill a bug against
the package.
die ${FUNCNAME}: check-reqs eclass called but not actualy
used!
fi
}
# @FUNCTION: check-reqs_run
# @DESCRIPTION:
# Internal function that runs the check based on variable settings.
check-reqs_run() {
debug-print-function ${FUNCNAME} $@
# some people are
Re: [gentoo-dev] [RFC] check-reqs.eclass.patch
Dne 31.8.2011 21:03, Ulrich Mueller napsal(a):
On Wed, 31 Aug 2011, Alec Warner wrote:
Also it is my understanding that all tokens in $(()) go through
expansion, so for instance:
$(( 1024 * 1024 * size ))
and
$(( 1024 * 1024 * ${size})) are equivalent.
Is this only in bash4?
It's like this since bash 2.05 at least.
Do we have a style preference?
Personally, I'd prefer the first variant.
Ulrich
I thought it is mandatory to use the second variant, otherwise i preffer
the first myself as it is from bash 2 or so :)
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [WTH] bash-completion useflag
Hi, what is the purpose of this fancy useflag, it controlls install of at best one or more small sh scripts. As we do not bother with the logrotate useflag this thing should fall into the same category. It is mostly added by the eclass for the feature. Which I for example didn't notice and forced newuse update for all poor souls using libreoffice... Cheers Tom signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] office-ext.eclass
Dne 29.8.2011 21:24, Nathan Phillip Brink napsal(a):
On Mon, Aug 29, 2011 at 10:35:41AM +0200, Tom Chv??tal wrote:
How about this attachment? :)
# @FUNCTION: openoffice-ext_add_extension
# @DESCRIPTION:
# Install the extension into the office suite.
openoffice-ext_add_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$1
local tmpdir=$(mktemp -d --tmpdir=${T})
Isn't it just as important to doublequote ${T} as it is to doublequote
${D}?
Good catch,
See the attachment for the latest version :)
Tom
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: office-ext.eclass
# @MAINTAINER:
# The office team openoff...@gentoo.org
# @BLURB: Eclass for installing libreoffice/openoffice extensions
# @DESCRIPTION:
# Eclass for easing maitenance of libreoffice/openoffice extensions.
case ${EAPI:-0} in
4) OEXT_EXPORTED_FUNCTIONS=src_install pkg_postinst pkg_prerm ;;
*) die EAPI=${EAPI} is not supported ;;
esac
EXPORT_FUNCTIONS ${OEXT_EXPORTED_FUNCTIONS}
unset OEXT_EXPORTED_FUNCTIONS
inherit eutils multilib
UNOPKG_BINARY=${EPREFIX}/usr/bin/unopkg
# @ECLASS-VARIABLE: OO_EXTENSIONS
# @REQUIRED
# @DESCRIPTION:
# Array containing list of extensions to install.
[[ -z ${OO_EXTENSIONS} ]] die OO_EXTENSIONS variable is unset.
if [[ $(declare -p OO_EXTENSIONS 2/dev/null 21) != declare -a* ]]; then
die OO_EXTENSIONS variable is not an array.
fi
DEPEND=virtual/ooo
RDEPEND=virtual/ooo
# @FUNCTION: office-ext_flush_unopkg_cache
# @DESCRIPTION:
# Flush the cache after removal of an extension.
office-ext_flush_unopkg_cache() {
debug-print-function ${FUNCNAME} $@
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} list --shared /dev/null
${UNOPKG_BINARY} list --shared /dev/null
}
# @FUNCTION: office-ext_get_implementation
# @DESCRIPTION:
# Determine the implementation we are building against.
office-ext_get_implementation() {
debug-print-function ${FUNCNAME} $@
local implementations=(
libreoffice
openoffice
)
local i
for i in ${implementations[$@]}; do
if [[ -d ${EPREFIX}/usr/$(get_libdir)/${i} ]]; then
debug-print ${FUNCNAME}: Determined implementation is:
\${EPREFIX}/usr/$(get_libdir)/${i}\
echo ${EPREFIX}/usr/$(get_libdir)/${i}
return
fi
done
die Unable not determine libreoffice/openoffice implementation!
}
# @FUNCTION: office-ext_add_extension
# @DESCRIPTION:
# Install the extension into the libreoffice/openoffice.
office-ext_add_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$@
local tmpdir=$(mktemp -d --tmpdir=${T})
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} add --shared \${ext}\
ebegin Adding extension: \${ext}\
${UNOPKG_BINARY} add --shared ${ext} \
-env:UserInstallation=file:///${tmpdir} \
-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1
eend $?
rm -rf ${tmpdir}
}
# @FUNCTION: office-ext_remove_extension
# @DESCRIPTION:
# Remove the extension from the libreoffice/openoffice.
office-ext_remove_extension() {
debug-print-function ${FUNCNAME} $@
local ext=$@
local tmpdir=$(mktemp -d --tmpdir=${T})
debug-print ${FUNCNAME}: ${UNOPKG_BINARY} remove --shared \${ext}\
ebegin Removing extension: \${ext}\
${UNOPKG_BINARY} remove --shared ${ext} \
-env:UserInstallation=file:///${tmpdir} \
-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1
eend $?
flush_unopkg_cache
rm -rf ${tmpdir}
}
# @FUNCTION: office-ext_src_install
# @DESCRIPTION:
# Install the extension source to the proper location.
office-ext_src_install() {
debug-print-function ${FUNCNAME} $@
local i
# subshell to not polute rest of the env with the insinto redefinition
(
insinto
$(openoffice-ext_get_implementation)/share/extension/install/
for i in ${OO_EXTENSIONS[$@]}; do
doins ${i}
done
)
einfo Remember that if you replace your office implementation,
einfo you need to recompile all the extensions.
einfo Your current implementation location is:
einfo $(openoffice-ext_get_implementation)
}
# @FUNCTION: office-ext_pkg_postinst
# @DESCRIPTION:
# Add the extensions to the libreoffice/openoffice.
office-ext_pkg_postinst() {
debug-print-function ${FUNCNAME} $@
local i
for i in ${OO_EXTENSIONS[$@]}; do
openoffice-ext_add_extension ${i}
done
}
# @FUNCTION: office-ext_pkg_prerm
# @DESCRIPTION:
# Remove the extensions from the libreoffice/openoffice.
office-ext_pkg_prerm() {
debug-print-function ${FUNCNAME} $@
[gentoo-dev] [RFC] check-reqs.eclass.patch
Hi,
I got enough annoyed by check-reqs.eclass using epause and other nasty
things so I updated it to do this things:
* eclassdoc
* use pkg_pretend and pkg_setup phases to run the checks
* warn if ebuild use deprecated calls and keep backompat
* remove duplicated/unused code
* support for metrics 1G 15T instead of requiring all values to be
entered in megabytes.
Cheers
Tom
Index: check-reqs.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v
retrieving revision 1.8
diff -u -b -B -r1.8 check-reqs.eclass
--- check-reqs.eclass 22 Aug 2011 04:46:31 - 1.8
+++ check-reqs.eclass 30 Aug 2011 06:56:43 -
@@ -4,8 +4,9 @@
# @ECLASS: check-reqs.eclass
# @MAINTAINER:
-# Bo Ãrsted Andresen z...@gentoo.org
+# QA Team q...@gentoo.org
# @AUTHOR:
+# Bo Ãrsted Andresen z...@gentoo.org
# Original Author: Ciaran McCreesh ciar...@gentoo.org
# @BLURB: Provides a uniform way of handling ebuild which have very high build requirements
# @DESCRIPTION:
@@ -13,49 +14,34 @@
# build requirements in terms of memory or disk space. It provides a function
# which should usually be called during pkg_setup().
#
-# From a user perspective, the variable CHECKREQS_ACTION can be set to:
-#* warn (default), which will display a warning and wait for 15s
-#* error, which will make the ebuild error out
-#* ignore, which will not take any action
-#
# The chosen action only happens when the system's resources are detected
# correctly and only if they are below the threshold specified by the package.
#
-# For ebuild authors: only use this eclass if you reaaally have stupidly
-# high build requirements. At an absolute minimum, you shouldn't be using this
-# unless the ebuild needs 256MBytes RAM or 1GByte temporary or install space.
-# The code should look something like:
-#
# @CODE
-# pkg_setup() {
-# # values in MBytes
-#
# # need this much memory (does *not* check swap)
-# CHECKREQS_MEMORY=256
+# CHECKREQS_MEMORY=256M
#
# # need this much temporary build space
-# CHECKREQS_DISK_BUILD=2048
+# CHECKREQS_DISK_BUILD=2G
#
# # install will need this much space in /usr
-# CHECKREQS_DISK_USR=1024
+# CHECKREQS_DISK_USR=1G
#
# # install will need this much space in /var
-# CHECKREQS_DISK_VAR=1024
+# CHECKREQS_DISK_VAR=1024M
#
# # go!
-# check_reqs
+# pkg_pretend() {
+#check-reqs_pkg_pretend
+# }
+#
+# # Run once again to ensure that environment didn't
+# # change since the pretend phase.
+# pkg_setup() {
+#check-reqs_pkg_setup
# }
# @CODE
#
-# Alternatively, the check_reqs_conditional function can be used to carry out
-# alternate actions (e.g. using a much slower but far less memory intensive
-# build option that gives the same end result).
-#
-# You should *not* override the user's CHECKREQS_ACTION setting, nor should you
-# attempt to provide a value if it is unset. Note that the environment variables
-# are used rather than parameters for a few reasons:
-# * easier to do if use blah ; then things
-# * we might add in additional requirements things later
# If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is not
# carried out.
#
@@ -66,80 +52,234 @@
# @ECLASS-VARIABLE: CHECKREQS_MEMORY
# @DESCRIPTION:
-# How much RAM is needed in MB?
+# @DEAULT_UNSET
+# How much RAM is needed?
# @ECLASS-VARIABLE: CHECKREQS_DISK_BUILD
# @DESCRIPTION:
-# How much diskspace is needed to build the package? In MB
+# @DEAULT_UNSET
+# How much diskspace is needed to build the package?
# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DESCRIPTION:
-# How much space in /usr is needed to install the package? In MB
+# @DEAULT_UNSET
+# How much space in /usr is needed to install the package?
# @ECLASS-VARIABLE: CHECKREQS_DISK_VAR
# @DESCRIPTION:
-# How much space is needed in /var? In MB
+# @DEAULT_UNSET
+# How much space is needed in /var?
+
+CHECKREQS_EXPORTED_FUNCTIONS=pkg_setup
+case ${EAPI:-0} in
+ 0|1|2|3) ;;
+ 4) CHECKREQS_EXPORTED_FUNCTIONS=${EXPORTED_FUNCTIONS} pkg_pretend ;;
+ *) die EAPI=${EAPI} is not supported ;;
+esac
# @FUNCTION: check_reqs
# @DESCRIPTION:
-# Checks the requirements given in the specific variables. If not reached,
-# either prints a warning or dies.
+# Obsolete function executing all the checks and priting out results
check_reqs() {
- [[ -n ${1} ]] die Usage: check_reqs
+ debug-print-function ${FUNCNAME} $@
+
+ echo
+ ewarn QA: Package calling old ${FUNCNAME} function.
+ ewarn QA: Please file a bug against the package.
+ ewarn QA: It should call check-reqs_pkg_pretend and check-reqs_pkg_setup
+ ewarn QA: and possibly use EAPI=4 or later.
+ echo
+
+ check-reqs_pkg_setup $@
+}
- export CHECKREQS_NEED_SLEEP= CHECKREQS_NEED_DIE=
- if [[ $CHECKREQS_ACTION != ignore ]] ; then
- [[ -n $CHECKREQS_MEMORY ]] check_build_memory
- [[ -n $CHECKREQS_DISK_BUILD ]] check_build_disk \
- ${T} ${CHECKREQS_DISK_BUILD}
- [[ -n
