[gentoo-dev] KDE Team meeting, June 2009
Hi, yay this time i forgot to sent the mail sooner, hope you won't be angry on me. Important info: Where: #gentoo-kde @ freenode.net When: 18.6.2009 19:00 UTC This time topics: - Solving the final question about kdeprefix. - KDE 4 Stabilisation. - handle the PyQt3 qscintilla dependencies - Progress of kde3 mess and way how anyone can help (here we call even for non-kdeteam devs) - Solving the python issues within KDE4, currently with +kdeprefix KDE 4.2 and 4.3 cant live next to each other due to packages installed into site-packages for python. Meeting is mandatory for kde team members and HTs. Anyone else is highly welcomed, especialy constructive ideas will be warmly accepted :] If you would like to add something else to meeting topics just reply to this mail. Cheers Tomas signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Review a new (unofficial) eclass
Hi there, I've been working on an eclass and associated ebuilds for the linux-libre [1] kernels. It's just linux with bits which they consider unfree are removed. It's a project of FSFLA. The reason I chose to do most of the work in an eclass rather than the ebuild is so I can very easily take other kernel versions in the tree and combine them with the linux-libre kernel (I've written an ebuild for the vanilla libre kernel, and one including the gentoo patcheset). Also it means the ebuilds can remain almost unchanged from their official kernel counterparts. Please can you let me know what you think of the eclass & ebuilds; any suggestions, criticisms, questions etc? This is my first time writing an eclass, and to me it all feels quite nice and solid, but that's the sort of thing which could quickly and harshly disproved ;-) I'll then attach the eclass & ebuilds to bug #266157 [2]. URLs: kernel-libre.eclass [3] libre-sources.eclass [4] libregentoo-sources.eclass [5] Many thanks, in advance, for anything you have to offer. Nick White [1] http://www.fsfla.org/svnwiki/selibre/linux-libre/ [2] http://bugs.gentoo.org/show_bug.cgi?id=266157 [3] http://git.njw.me.uk/cgit/cgit.cgi/njw-gentoo-local/plain/eclass/kernel-libre.eclass [4] http://git.njw.me.uk/cgit/cgit.cgi/njw-gentoo-local/plain/sys-kernel/libre-sources/libre-sources-2.6.30.ebuild [5] http://git.njw.me.uk/cgit/cgit.cgi/njw-gentoo-local/plain/sys-kernel/libregentoo-sources/libregentoo-sources-2.6.30-r1.ebuild -- GPG : 0x04E4653F / 9732 D7C7 A441 D79E FDF0 94F6 1F48 5674 04E4 653F IM /OTR : n...@jabber.org / 7E3C82CC D6AB2CEA E8000300 E429A122 D984111B SIP/ZRTP: n...@ekiga.net WWW : http://www.njw.me.uk pgp0BsqtUOLO3.pgp Description: PGP signature
[gentoo-dev] Progress on Universal Select Tool
Hello, Current State of Universal Select Tool - uselect Proposal link: http://socghop.appspot.com/student_project/show/google/gsoc2009/gentoo/t124022356237 uselect implementation started a few weeks before SoC officially started to "de-rust" myself on python programming. Here follows a checklist of what it already does right now. * modules syntax defined * modules support any scripting language * module conversion from eselect to uselect are very easy (even when not symlinking) * per-user/system-wide actions * simple symlinking actions are defined in 1 line only. uselect does all the job. * changing a user python interpreter through adding ~/.uselect/bin to PATH through /etc/profile (is this the better way?) Next steps: * look deeper into eselect already implemented functions that most modules use (by using inherit) and see what is uselect still lacking * define profiling system (nice thread on gentoo-dev on this) * start the profile system implementation * start using gentoo's git Further Notes: * At this point I am ahead on schedule because of my early start. With this I have plenty of time to implement features that were not described on the proposal. * Soon I will push the code into gentoo's git. If you have time, take a look at it. Hope these reports are taken also as a "call for ideas". Hope I'm not lacking any information. I'm loving working with Gentoo on this. Learned a lot until now. Cheers, Sérgio -- Sérgio Almeida - meph...@gmail.com mephx @ freenode signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Review a new (unofficial) eclass
Hi, Nick : > Please can you let me know what you think of the eclass & ebuilds; > any suggestions, criticisms, questions etc? This is my first time > writing an eclass, and to me it all feels quite nice and solid, but > that's the sort of thing which could quickly and harshly disproved > ;-) You could make it EAPI 2 safe and use the src_prepare function for all your tarball magic. See other eclasses that handle EAPI case switching. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Review a new (unofficial) eclass
Dne úterý 16 Červen 2009 18:34:46 Christian Faulhammer napsal(a): > You could make it EAPI 2 safe and use the src_prepare function for all > your tarball magic. See other eclasses that handle EAPI case switching. Specialy x-modular, git or cmake-utils It has most readable output, when we get to more eapis :] Tomas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Review a new (unofficial) eclass
On Tue, 16 Jun 2009 15:06:02 +0100 Nick wrote: > Please can you let me know what you think of the eclass & ebuilds; > any suggestions, criticisms, questions etc? This is my first time > writing an eclass, and to me it all feels quite nice and solid, but > that's the sort of thing which could quickly and harshly disproved > ;-) You *really* shouldn't be messing around with things in DISTDIR the way you are. That's just plain horrible. The only reason DISTDIR isn't forcibly read-only is that the scm eclasses need to write to subdirectories of it. Just do your own unpack if you can't handle it. Also, is that really the best way of generating SRC_URI? Can't you remove the need to put anything in ebuilds? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Review a new (unofficial) eclass
Quoth Ciaran McCreesh: > You *really* shouldn't be messing around with things in DISTDIR the way > you are. That's just plain horrible. The only reason DISTDIR isn't > forcibly read-only is that the scm eclasses need to write to > subdirectories of it. > > Just do your own unpack if you can't handle it. Good plan. That's how I was doing it, then I got a bit carried away with trying to not duplicate any of the kernel-2 eclass, but you're right, it turned out horrible. I've replaced the relevant kernel-2 function now, which is much nicer. > Also, is that really the best way of generating SRC_URI? Can't you > remove the need to put anything in ebuilds? I think it is the best way, unless you have a specific reason not to. This way the different kernel ebuilds need very little modification to use the libre base. Thanks for the feedback. Anything else at all would be welcome. Nick -- GPG : 0x04E4653F / 9732 D7C7 A441 D79E FDF0 94F6 1F48 5674 04E4 653F IM /OTR : n...@jabber.org / 7E3C82CC D6AB2CEA E8000300 E429A122 D984111B SIP/ZRTP: n...@ekiga.net WWW : http://www.njw.me.uk pgpfC4WwSPOMq.pgp Description: PGP signature
Re: [packagekit] [gentoo-dev] Inviting you to project "PackageMap"
I start to understand the real benefits of moving a larger part of the maintenance down to the distro level as you proposed. Okay, let's add support for CPEs at distro package level and sync up and down with the central packagemap database. Please contact me for collaboration on sync scripts and "modeling" of details. Sebastian
[gentoo-dev] Re: [gentoo-dev-announce] net-misc/l7-filter removal
This package is hard masked now finally. Another reference to count: https://bugs.gentoo.org/show_bug.cgi?id=274341 В Втр, 28/04/2009 в 17:24 +1000, Daniel Black пишет: > This package relies on disabling of essential package management features > (collision-protection) to achieve installation. It has done so for years > however its increased complexity and my diminishing time to maintain it mean > its even less maintainable. > > It is an ideal candidate for a rewrite if a generic kernel patching framework > is developed. > > Until then it can be removed or be maintained by person other than me. > > https://bugs.gentoo.org/show_bug.cgi?id=254086 > > Feel free to take over if you want it. > > Daniel > -- Peter.
