[gentoo-dev] Re: Problems with the current bzr eclass.
Hi, Harley Peters har...@thepetersclan.net: Because the numbers don't look so good for Gnash. bzr branch http://bzr.savannah.gnu.org/r/gnash/trunk They look similar on my system to that of Emacs, although I have to try with new revisions added. Having said that it's only a two line change to the bzr.eclass code to get it to work the way I want. And I can live with that. :) But in the end I need to justify the changes not only for you. :) V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness
On Wed, 8 Jul 2009 05:02:34 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: IUSE_IMPLICIT=build debug Are people wanting to make those implicit? IMHO they shouldn't be implicit. I should probably explain the rationale behind those two... Back in the day, various eclasses would do 'if use build' and 'if use debug' and the like, and at one point eutils had a DEPEND=!build? ( patch ) in there. I *think* all the major offenders there are gone now. On the other hand, if they're not, and IUSE_IMPLICIT doesn't include those, it means EAPI 3 won't be usable with certain fairly common eclasses. Historically, IUSE was purely a visual thing, and didn't affect package manager behaviour. With the introduction of the newuse stuff, and later, use dependencies, that slowly stopped being true, and IUSE started to matter a lot more. (And maybe IUSE_IMPLICIT shouldn't be supported at all.) Personally I hate the whole implicit thing, and would rather everyone stuck absolutely everything in IUSE. But a majority of developers thought otherwise. There were also calls for some fancy prefix use flags to go in IUSE_IMPLICIT at some point. Alas, it doesn't look like something we could have excluded from the specification entirely... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Problems with the current bzr eclass.
On Fri, 10 Jul 2009 08:50:26 +0200 Christian Faulhammer fa...@gentoo.org wrote: Hi, Harley Peters har...@thepetersclan.net: Because the numbers don't look so good for Gnash. bzr branch http://bzr.savannah.gnu.org/r/gnash/trunk They look similar on my system to that of Emacs, although I have to try with new revisions added. Having said that it's only a two line change to the bzr.eclass code to get it to work the way I want. And I can live with that. :) But in the end I need to justify the changes not only for you. :) V-Li I'm getting good numbers from the command line but in the ebuild it's much different. I haven't timed it but it takes about 25 minutes to do a full checkout and about a third that to do the light weight checkout. The update takes less than a minute with the full checkout. And it takes ten's of minutes with a lightweight checkout. Is there something else in the ebuild I need to specify besides EBZR_REPO_URI=http://bzr.savannah.gnu.org/r/gnash/trunk; ? You can download the ebuild at: http://overlays.biterror.net/files/gnash-.ebuild
Re: [gentoo-dev] Re: Re: A Little Council Reform Anyone?
On Thu, 2009-07-09 at 22:50 -0400, Andrew D Kirch wrote: Ciaran McCreesh wrote: trelane ciaranm: I want Paludis to fail. It's unhealthy (or at least the loudest and most visible of it's devs are) for Gentoo. trelane lets be VERY clear on that point. So long as Paludis, and the culture it creates are unhealthy for Gentoo I want it to fail. trelane ciaranm: that's put in a manner that seems to be a somewhat knee-jerk reaction. It should be clear that opposing you and everything you do was an initiative I started only after careful consideration. Ciaran, you are killing Gentoo. You wrote a demonstrably error prone GLEP 39, then tried to exploit it to ram through GLEP 55, and you got caught. You've created a huge amount of red tape, needless bickering argument, and have utterly hamstrung every council ever convened. Ciaran, you will not be doing this again. Actually, GLEP39 was written by Grant and Ciaran, and it was voted on by the entire developer community (I don't recall in which order these happened, but certainly it was not Ciaran who approved it). --- snip --- I am wearing my userrel hat here. I don't see anything here that contributes to the discussion --- it looks like a personal attack and a threat to me. As Jorge stated a day or so ago, please stop this now. You may consider this to be a final warning. Andrew D Kirch Funtoo.org PS: Ciaran, Thank you for comparing me to Rush Limbaugh, I consider it a compliment. Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrite: dev-util/efence (replaced by dev-util/duma)
# Samuli Suominen ssuomi...@gentoo.org (10 Jul 2009) # efence doesn't build wrt #262528, or work wrt #128814 # masked for removal. please use dev-util/duma instead. dev-util/efence actually, also dev-util/duma is entirely broken and doesn't build at all.. but it's supposed to be the successor
[gentoo-dev] Stepping back from being treecleaners lead to being a member
And darkside is our new lead, so he'll have more say on matters. Clear majority of members agreed on IRC. Wish him luck ;) -Samuli
[gentoo-dev] Re: Python 2.6.* stabilization plans
2009-05-18 06:47:56 Arfrever Frehtes Taifersar Arahesis napisał(a): I'm planning to request stabilization of Python 2.6.* in August. s/August/July/ I will also request stabilizations of other packages which need to be stabilized before Python 2.6.*. Please test various packages with Python 2.6.*. If you find a package which fails to build or doesn't work with Python 2.6.*, please report a bug and make it block bug #230205 [1]. [1] https://bugs.gentoo.org/show_bug.cgi?id=230205 -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Lastrite: media-video/mpeg4ip
# Víctor Ostorga vosto...@gentoo.org (10 Jul 2009) # media-video/mpeg4ip doesn't build wrt #274284 # mpeg4ip is obsolete, libmp4v2 got new upstream. # Removal scheduled in 2009-09-10 media-video/mpeg4ip mpeg4ip is obsolete. libmp4v2 got new upstream and it's shipping a set of utils too.
Re: [gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness
On Wed, Jul 08, 2009 at 05:02:10AM +0200, Arfrever Frehtes Taifersar Arahesis wrote: 2009-07-07 01:01:11 Ciaran McCreesh napisał(a): ... IUSE_IMPLICIT=build debug Are people wanting to make those implicit? IMHO they shouldn't be implicit. Agreed. They shouldn't be implicit, if only because you really want emerge --newuse (or equivalent) to pick up on changes in USE=build or USE=debug. Also, are USE dependencies possible with implicit IUSE? If not, things like DEPEND=dev-lang/python[-build] would have to be changed even though they're probably a good idea.
Re: [gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness
On Fri, 10 Jul 2009 19:32:02 +0200 Harald van Dijk true...@gentoo.org wrote: Also, are USE dependencies possible with implicit IUSE? If not, things like DEPEND=dev-lang/python[-build] would have to be changed even though they're probably a good idea. Use dependencies are possible. Use dependency defaults are not. So: DEPEND=dev-lang/python[-build] would be ok so long as all versions of python either have build in IUSE or are EAPI 3 and have build in IUSE_IMPLICIT. DEPEND=dev-lang/python[-build(-)] would be ok so long as build is not in IUSE_IMPLICIT, regardless of build's status in IUSE. As you can see, implicit flags mess things up lots... No big deal for USERLAND et al, but they're a pain in the ass for 'normal' flags. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [GSoC status] Web-based image builder
According to my original time line, which I've largely ignored since I started coding, I'm about a week ahead of schedule, though I've also left out things that I'd planned on finishing by now and implemented things . This is how my week went: Sunday: Copied the client-side searching of available packages from the mockup I did for my proposal Monday: Made modifications to allow the frontend to function when the package repositories that backend is using are not available to it; wrote script for taking into account updates to package repositories; made final changes to allow multiple backends to serve one frontend Tuesday: Added a logo and favicon; began major restructuring of configuration wizard to be object-oriented and provide a simple API for defining configuration items/steps Wednesday: Did most of the conversion of the searchable package selection interface into a very configurable class available through the frontend API Thursday: Finished the package selection class, began separating the code that bundles the final image from the code that builds it Friday: Finished bundler separation in backend, added metadata for better handling of frontend modules, changed system configuration file to have default values and be easier to work with To be done: -Get Ingenue ready for deployment on a real server - check that authentication is present wherever necessary, add administrative functions and the capability to automatically clean up stale data -Add more build options, as listed on the features list [0] -Do some testing, preferably with real users on a testing server (get a testing server up and running) More distant: -Spice up the frontend and add some documentation to it -Create a live development ebuild for the project -Have the project generate images containing itself to run as backend slaves As always, feedback welcome. [0] http://etherpad.com/BJkgXcMkwJ
Re: [gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness
Ciaran McCreesh wrote: On Tue, 07 Jul 2009 02:08:01 -0400 Andrew D Kirch trel...@trelane.net wrote: Given that your stated intention is for Paludis to fail, and that opposing [me] and everything [I] do was an initiative [you] started only after careful consideration, I'll kindly ask you to stop randomly jumping out and flinging turds, since it adds nothing to the discussion at hand and only serves to make it harder for Gentoo to function as a community. [response censored by fmmcor and devrel] Andrew D Kirch Funtoo.org (though I'd note the timing of Ciaran's response is 5.5 hours after a clear Mea Culpa that I had misspoken) http://archives.gentoo.org/gentoo-dev/msg_ff98cc6ecb9054a2938d1379d2c78d1f.xml @ 09:24 http://archives.gentoo.org/gentoo-dev/msg_a933ccf75960bba6d0a133d64454ebff.xml @ 14:52
[gentoo-dev] app-portage/deltup needs help
Hello devs, It has been brought to my attention that deltup is in need of some lovin' via a treecleaner bug (bug 246916). Both deltup and app-portage/getdelta are used in combination to provide smaller tarballs. If anyone is interested in helping out the Gentoo dial-up users, please consider picking these up. These will eventually have to leave the tree soonish for security reasons (bundling vulnerable bzip versions). I'm not interested in these packages, just spreading the word. They use to be maintained by genstef. %% bugz search deltup 218901 genstefapp-portage/deltup need support of lzma compression 234990 genstefdeltup deletes patches for sys-libs/db-4.6.21_p3-r1: 240121 genstefapp-portage/deltup: CFLAGS are ignored 246189 genstefapp-portage/deltup-0.4.4 does not respect LDFLAGS 246916 genstefapp-portage/deltup: fails with forced --as-needed %% bugz search getdelta 212012 tools-portageGetdelta.sh compares wrong files before delta fetch 239439 genstef[PATCH] app-portage/getdelta-0.7.8 breaks with EAPI= -Jeremy
[gentoo-portage-dev] unsubscribe
unsubscribe
Re: [gentoo-portage-dev] Portage API questions
in case anybody wants to have a look what i made of that you can find my current sources over here: http://git.goodpoint.de/?p=smolt-gentoo.git;a=tree;f=client/distros/gentoo;hb=refs/heads/gentoo thanks again to andy for his code and zac for help on IRC. any feedback and code review is very welcome, better off-list though. sebastian
[gentoo-portage-dev] portage.settings.profiles
Hello! In my current code for GSoC/Gentoo/Smolt I access the list of folders that /etc/make.profile and parents are resolved to: portage.settings.profiles I do this to be able access - profile package.mask, - user package.mask, and - user package.unmask independently, which portage.settings._getMaskAtom portage.settings._getProfileMaskAtom seem not be able to at the moment, besides looking quite private :-) Rationale: Among other things I want to find out if the user unmasked a certain package in the past even if the related mask entry for it was removed in the meantime. Also, I want to be able to distinct between a a stable on stable package and an unmasked masked package. What I would like to ask for is we could decide that portage.settings.profiles is declared part of the public API and not allow to change anymore or if we could introduce some getter for now so I could surround the current access to portage.settings.profiles by a portage API version check and use the getter from a certain version on. Integrating my code for portage related code into smolt does not seem reasonable to me as it would require depending on a version of portage that will not be stable before 2010 or so. Please share your thoughts with me. Sebastian
Re: [gentoo-portage-dev] portage.settings.profiles
Sebastian Pipping wrote: Hello! In my current code for GSoC/Gentoo/Smolt I access the list of folders that /etc/make.profile and parents are resolved to: portage.settings.profiles I do this to be able access - profile package.mask, - user package.mask, and - user package.unmask independently, which portage.settings._getMaskAtom portage.settings._getProfileMaskAtom seem not be able to at the moment, besides looking quite private :-) Rationale: Among other things I want to find out if the user unmasked a certain package in the past even if the related mask entry for it was removed in the meantime. Also, I want to be able to distinct between a a stable on stable package and an unmasked masked package. What I would like to ask for is we could decide that portage.settings.profiles is declared part of the public API and not allow to change anymore Go ahead and use it. It's safe. Most attributes that aren't marked with an underscore are pretty safe. If there has to be a change then typically I do it under a new name and leave the old one for compatibility. or if we could introduce some getter for now so I could surround the current access to portage.settings.profiles by a portage API version check and use the getter from a certain version on. Integrating my code for portage related code into smolt does not seem reasonable to me as it would require depending on a version of portage that will not be stable before 2010 or so. Please share your thoughts with me. Sebastian -- Thanks, Zac