Re: [gentoo-dev] [gsoc-status] portage backend for PackageKit
On Monday 15 June 2009, Petteri Räty wrote: > If there are interactive ebuilds that don't declare > PROPERTIES="interactive", you can just compile a list and post it to > gentoo-dev-announce telling maintainers to add it or you will do it at > some date X a week from the announcement or later at your choosing. I'm no Python programmer, and I haven't even read the code involved, but in the interests of minimising duplication of effort, I thought you'd be interested to know that Sabayon, a Gentoo based binary distro, look like they may be one step ahead of you on this one: http://gitweb.sabayon.org/?p=playground/packagekit-entropy.git;a=summary Cheers, Steve.
[gentoo-dev] Re: [GSoC status] Web-based image builder
This week has gone pretty well and I'm hoping to get a testing server up soon, though it looks like it will be running the backend in a virtual machine due to the root privileges requirement. I've added support for several more output formats: ext2 image, jffs2, and two different styles of bootable ISO - one that's just a standard weekly Gentoo minimal CD with a tarball of the system, and one that replaces the minimal CD's environment with the generated system (the CDs are at a fairly primitive stage, but I did succeed in booting both of them with qemu). I also changed around the frontend so that rather than configuring each build individually, configuration is done on reusable configurations, which can then be used any number of times to request actual builds. I also added an invitations system to allow a more closed environment, especially for testing before it's ready for release. Both the frontend and backend are now set up to use modules (presently I'm only worrying about modules for Gentoo/portage) so that in the future, support can be added for other distributions or package managers. I also did some work to provide more high-level functions for these modules so they will be easy to write and modify. The portage backend now caches the generated image after the base system has been installed, providing a huge reduction in the time it takes to generate an image for large profiles once the cache exists. Lastly, the backend can now upload completed images to the frontend for a case when they are on separate machines and it is not desirable to have users download their finished images directly from the backend machines on which they were compiled. To do: -Make the frontend more user-friendly (particularly the selection of packages to install) -Allow editing of configurations after they are initially completed -Wrinkle out the rest of the issues with separating frontend and backend -Make sure no race conditions exist when using more than one backend to serve one frontend -Figure out a (safe) system for updating the package repositories, particularly with backend and frontend split and with multiple backends -Perhaps more important of all, provide more options to configure the image produced (see http://etherpad.com/BJkgXcMkwJ for current list of options, http://forums.gentoo.org/viewtopic-p-5830406.html if you have suggestions) Thanks to those who have been giving support and offering suggestions so far. Eudyptula
Re: [gentoo-dev] Re: A Little Council Reform Anyone?
On Fri, 3 Jul 2009 02:08:48 -0700 Brian Harring wrote: > Actually pkgcore folk have pushed for stuff. mtime preservation is a > simple example of things I've pushed for- at the time implemented by > portage/pkgcore, eliminates the orphan potential for .pyc and other > generated files (iow, very useful). The mtime preservation implemented by (recent -- earlier versions mirror what Paludis still does) Portage versions has problems that you're fully aware of. We're looking at fixing it properly, including addressing the problems you're trying to brush under the carpet, for EAPI 4 rather than EAPI 3 simply because the Council chose to freeze EAPI 3 before a full solution had been proposed. > My personal opinion on what goes into PMS is that it's typically only > stuff that paludis supports already (or is a direction paludis wants > to go towards). Could be wrong, but that's my opinion of it via > watching/involvement in it from it's public inception. Er, not in the least bit. Out of the 7 features in EAPI 2: * One was a last minute workaround for a Portage behaviour change that broke things. * Five were feature requests from Gentoo developers. * One was a response concocted by Paludis people in response to a common problem described by Gentoo developers. Out of the 18 features in EAPI 3: * 14 were feature requests from Gentoo developers. * 1.5 were directly from Portage. * 1.5 were technicalities worked out based upon real world testing of proposed features by Paludis people. * One was a colaboration between the Portage and Paludis people. Paludis had support for nine of these beforehand. > In terms of involvement in PMS, frankly it's not worth it from where > I'm sitting due to ciarans behaviour. Simplest explanation possible > there is that w/ ciaran being effectively the loudest voice PMS wise, ...because I do most of the work, and I'm not interested in spending weeks discussing proposals I think are a really bad idea with the Council. There's nothing to stop you from doing that if you believe something should be in an EAPI -- you're welcome to champion your own feature requests. Also, I'll remind you that our current "rejected patches" list is sitting at approximately one item... > combined w/ behaviour involving sitting on bugs in competing managers I've given up looking at pkgcore's code or trying to test it. The only bugs I'm aware of in pkgcore are those that've been reported by other people. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Manifesto archive
Hi Torsten. Torsten Veller wrote: > * "Jorge Manuel B. S. Vicetto" : >> http://www.gentoo.org/proj/en/elections/council/2009/council-200906-nominees.xml > > Please archive the manifestos somewhere under the project space > like it was done the last years. > Looking back at the 2005 list of nominees, all external links are dead. > Only the archived parts are still available. Yes, that is another thing I was planning to do. The only reason I haven't done it yet, is that older manifestos were stored as txt files and this year the candidates mostly opted for html/xml files. I'll probably just go ahead, "ignore the looks" and copy their manifestos to txt files. If any of the nominees would be kind enough to do it for us and send us the file, it would be greatly appreciated. > I can help if needed. > > Thanks > -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE
Re: [gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
Luca Barbato wrote: Jorge Manuel B. S. Vicetto wrote: I have a few ideas about this that I'll have to put in writing and share later, but let me start by proposing that for such a change we require the support of at least 2/3 of the devs that vote *and* a minimum of 1/3 of all devs. I'd use absolute majority even if it is more strict. The only concern I have with these kinds of approaches is that right now we tend to be pretty liberal with allowing people to be devs even if they aren't heavily involved in gentoo. As long as their commits are of sufficient quality that isn't a big deal. However, it does allow the voting rolls to get pretty big with people that don't have a huge stake in the outcome of an election. Organizations that tend to have supermajority policies tend to have other kinds of requirements on dues or activity, and they also tend to routinely clean out their rolls. A supermajority policy might work fine if we also had a policy that a dev who fails to vote in two consecutive elections gets the boot. I'm not sure that we really want that kind of a policy, however. My feeling is that if you don't care enough to vote, you should have to live with the consequences. Now, all elections of any kind should be announced well in advance, and should span a period of a few weeks (as they currently do). If an issue is particularly critical and nobody can get around to voting for it in a 2 weeks span while there are hundreds of arguments raging in IRC and the lists, then I'm not sure we can take their silence as a vote of disapproval.
Re: [gentoo-dev] Re: New eselect news item for kdeprefix
On Wed, Jul 1, 2009 at 9:17 AM, Petteri Räty wrote: > Ciaran McCreesh wrote: >> On Wed, 1 Jul 2009 17:00:35 +0300 >> Theo Chatzimichos wrote: >>> On Wednesday 01 July 2009 16:25:11 Ciaran McCreesh wrote: On Wed, 1 Jul 2009 15:45:29 +0300 Theo Chatzimichos wrote: > Display-If-Installed: kde-base/kdelibs Really? Anyone who has any version of kdelibs ever? >>> Yes, this affects kde3 and kde4 users. >> >> Will it also affect kde5 users? >> > > "News items can be removed (by removing the news file from the main > tree) when they are no longer relevant, if they are made obsolete by a > future news item or after a long period of time. This is the same as the > method used for updates entries." > > I would say the news item is not relevant when kde 5 comes out but of > course it doesn't hurt to have a version specification there. Just > noting that in general atoms without version restrictions shouldn't be a > problem. I think getting news items that don't apply to me is a pretty big UI problem; it would be nice to recommend to people writing items to make sure their atoms are bounded. -A > > Regards, > Petteri > >
Re: [gentoo-dev] Re: A Little Council Reform Anyone?
On Thu, Jul 02, 2009 at 09:43:53PM +0100, Ciaran McCreesh wrote: > On Thu, 2 Jul 2009 22:29:39 +0200 > Christian Faulhammer wrote: > > > Which groups who would like to be able to contribute currently feel > > > that they can't, why do they feel that and why haven't they said so? > > > > For example people from the other package managers apart from > > Paludis. > > Zac's said he's not particularly interested in the deciding upon new > features part, and despite that there was considerable Portage > influence upon all three new EAPIs. The Pkgcore people haven't tried > pushing for anything as far as I know. The option's there for them, but > they haven't expressed any interest. Actually pkgcore folk have pushed for stuff. mtime preservation is a simple example of things I've pushed for- at the time implemented by portage/pkgcore, eliminates the orphan potential for .pyc and other generated files (iow, very useful). My personal opinion on what goes into PMS is that it's typically only stuff that paludis supports already (or is a direction paludis wants to go towards). Could be wrong, but that's my opinion of it via watching/involvement in it from it's public inception. In terms of involvement in PMS, frankly it's not worth it from where I'm sitting due to ciarans behaviour. Simplest explanation possible there is that w/ ciaran being effectively the loudest voice PMS wise, combined w/ behaviour involving sitting on bugs in competing managers (including instances where that manager isn't compliant w/ PMS) and popping them out at random times on the ML to rip on the manager, it's not worth dealing with it. It's not a matter of having thicker skin- it's literally a question of worth. Is it worth trying to have a voice if it means exposing yourself to BS behaviour? Via that line of thought y'all should be able to understand my personal choice involvement wise. It's basically a happier existance to just implement the spec, and keep the head down ;) My two cents on it, for what it's worth. ~brian pgpNF1BWasHyA.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
Jorge Manuel B. S. Vicetto wrote: > I have a few ideas about this that I'll have to put in writing and share > later, but let me start by proposing that for such a change we require > the support of at least 2/3 of the devs that vote *and* a minimum of 1/3 > of all devs. I'd use absolute majority even if it is more strict. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Exim and Sendmail need a maintainer
On 02-07-2009 22:06:33 +0100, AllenJB wrote: > Fabian Groffen wrote: > > On 24-06-2009 13:51:37 +, Torsten Veller wrote: > >> | mail-mta/exim. > > > > I'm looking for users that want to help maintaining Exim. Especially if > > you feel like becoming a Gentoo developer at some time, contact me > > directly. > > > I recommend you post this to planet, the forums, maybe the -user mailing > list and Gentoo's Newsletter... oh wait! Maybe not the newsletter then. =P > > It might be useful to include a summary of what you expect the users to > do, what knowledge they need and what help is available (Don't forget > that what's obvious to you may not be obvious to them!) > > More than 2 users might actually see it then =P Thanks for your suggestions, however, it seems there are more than two users reading -dev, so I'm not in need for more PR at the moment :) -- Fabian Groffen Gentoo on a different level
