Jan 30, 2009

a snake in regen2

I'm sure you're thinking I'm talking about me ;) nope first order of business, add more stuff which should be in gentoo.

I'm pleased to announce that I've added py3k also know as Python 3.0 to Regen2. It will remain hardmasked as unmasking could create stability issues on a gentoo based system given it's reliance on python.

Jan 29, 2009

Forking Funtoo - Regen2 project born

So, I won't be the Tree Maintainer for Funtoo anymore. In light of the new situation I'm forking Funtoo. I'm not going into details why I'm not the tree maintainer anymore on this blog, except to point out how Regen2 will differ.

I'll be continuing to maintain a tree with all the overlays I had added and more to come. you can get a copy of my version of portage at git://github.com/regen2/portage.git my private repo is where I test updates first. I'll be maintaining a gentoo.org and funtoo.org branch as well as my own regen2.org branch. The regen2.org branch doesn't currently differ much from funtoo.org, however I intend to keep it up daily and at some point I may even be able to update it more than once a day.

I've already got mailing lists and I'm working on having permanent channels on IRC. lists are on google groups at regen2-user and regen2-dev I don't mind discussions of gentoo, funtoo, and sabayon in addition to regen2 on these lists.

Regen2 unlike Funtoo is not about 'fun' it's about making Regen2 the easiest, fastest, most secure, most configurable, most stable and bleeding edge source distro, and probably a few other things, too.

funtoo wants as little red tape for developers as possible, to the point of zero red tape and zero accountability on whether things break. If I had continued with funtoo it would have been my job to fix patches that came in with problems on simple things like manifests. It's assumed it takes 1 minute to fix manifest or less when in reality it takes about 10. 2 minutes to catch the error, another 5 to regenerate the manifest make a new commit, and another 2 to test and 1 more to push. This may or may not be a time exaggeration. Now imagine I have to generate every manifest on every ebuild that comes in. This takes time, for me it's easier to ask the person who's submitting the patch to fix there patch. When I sent a patch to git and got a 1 page reaming response about everything I did wrong submitting it, I didn't complain, cry, or quit, I licked my wounds fixed my problems and my patch and resent. I had implemented some red tape to prevent simple broken commits and make better commit logs, these added very little overhead to the actual patch process, and some of them had actually caught what would have been otherwise missed bad patches going into the tree. I will continue checking commits coming into the regen2.org tree.

It has been brought to my attention, that it appears like I'm trying to create a rift between funtoo and regen2. Not at all, I will be sending drobbins bugfix patches, and I will be cherry-picking from funtoo.org. I will not be maintaining overlays, or the tree for him however, this is impractical via email patches, I've noted that he's welcome to pull from me. My primary concern will be the regen2.org tree, however. I'd also like to note that the reason I'm maintaining my own tree is the same reason I agreed to be tree maintainer in the first place. At the time I started tree maintainership it had been 5 days since the tree had been merged. This is too long in my opinion and if I don't maintain my own tree it could happen again. Barring extenuating circumstances the tree will be merged daily.

I'd also like to note that the original vision of funtoo was in part, a distro to build other distro's. So I'm merely fulfilling that vision by starting this.

Hopefully with in a couple of weeks I'll start building stage3's on the funtoo tree, and eventually iso's and stage4's as well. I most likely will not have processor specific or stage1's and stage2's, due to my lack of hardware and the fact that I think stage1/2 is rather pointless.

I will be adding emerge-ng to funtoo, which at first will just be a portage (and some other tools) wrapper, however, as time goes on I will be replacing portage with new code to make it faster. emerge-ng should also be a bit simpler to use and it'll have a better name. More on it to come. For my long term visions of it see the emerge-ng tag.

regen2.org will be the official home, I hope to have something operational there by the end of the weekend.

I hope you all enjoy regen2.


I realize this may not be the most professional, gracious, or diplomatic of partings, and beginnings. I'm not a diplomat, although, perhaps I shouldn't have said this as I did... perhaps it doesn't matter... or perhaps I said what needed to be said. I've nothing to hide, and anyone is welcome to call me out.

Jan 23, 2009

Funtoo News

I've decided I'm going to start posting a sort of weekly newsletter (I'm not committing to weekly though) merely to document anything I feel important that happened, or is about to, but isn't quite important enough for it's own post.

RA (ra-- on #funtoo) or r_a@lavabit.com submitted quite a few patches this week including 1 that fixes many of my major borkage on non-latin1 changelog breaks. He's become a regular contributor and I'd like to thank him.

perl-5.10 will be unmasked this evening, if you haven't read it yet, read my post on upgrading, you'll need it, because this is more than just an install and forget, other packages need to be rebuilt, and perl-cleaner revdep-rebuild doesn't find them all. Good news is I've been running 5.10 since the beginning of the month no problems since the beginning.

I pushed samba 3.2.7 into the tree this week, gentoo's been sitting on it for a while, it's hard masked, but seems to build fine, I don't operate on a windows network though so can't say how well it works.

Jan 18, 2009

mpd overlay

I'm adding the MPD overlay courtesy of Rullzer who's kind enough to merge and maintain it in tree. Nothing big here, just some more up to date ebuilds, and more clients for MPD.

Jan 9, 2009

Funtoo gets the new Perl

Soon, Dan Robbins will be merging my perl-experimental branch which contains the perl-experimental overlay. This overlay contains a handful of packages, the most important of which is perl-5.10.0 which has been out for about a year now and Gentoo still hasn't put in portage. One nuisance of the perl-experimental overlay is they don't use changelogs which means if you want to know what's going on with a package from this you'll have to check out git log as well as the changelog. I feel this is a minor issue, in the long run we should migrate all package logs to git's internal logging facility.

I've been testing perl-5.10.0 for a week or so now with few problems, and none which I've found to be un-resolvable. It's entirely possible that there are packages I don't use that will break on 5.10. When we merge perl-experimental it will be hardmasked at first, and we're looking for people to test for a couple of weeks before we move it to the testing branch, so we can iron out any problems which we weren't able to account for.

upgrading to perl-5.10

So, in theory, all you have to do is run

perl-cleaner all

after unmasking and emerging dev-lang/perl and sys-devel/libperl. In practice however, I found this didn't work. it seemed to only find packages in world which needed upgrading, so between me and one other person, we came up with this little one liner to fix packages were built against perl-5.8

locate 5.8.8 | grep ^/usr/ | grep -v ^/usr/portage | xargs equery belongs | uniq | sed -e s/^/\=/ | xargs emerge --oneshot

once you've run perl-cleaner and the one-liner, you should be completely upgraded.

Issues specific to perl-5.10 can be reported on the Gentoo bugtracker, in the perl 5.10 bug or to us on #funtoo.

Jan 6, 2009

Sunrise's over Funtoo

Sunrise a Gentoo overlay is being added to Funtoo. So if you've got layman tracking sunrise and you're using funtoo you'll be able to delete sunrise from your overlays as I'll be merging sunrise's reviewed ebuilds daily.

The hardest part of the whole process was merging package.mask, use.local.desc and categories. Since this is new be on the lookout for bugs or problems.

Want to add an overlay to funtoo yourself? First, it'll have to be a git or svn overlay. If it's git you can skip steps involving git svn.

git svn clone uri://mysvnuri.tld

this imports an entire svn repository into git and will take a while, sunrise had import over 7000 commits. Next check to see if any changes need to be made to the structure of the overlay, in sunrise's case it's not branched properly... they had a subdirectory structure including reviewed and non-reviewed ebuilds, I had to remove that so the top level directory was that of a portdir for merging. if it's already in a nice portdir format move to the next step.

start by cd-ing into your funtoo portdir checkout, then run git pull uri://mygit-svn-cloned-repo, this will attempt to merge the 2 and most likely you will have conflicts. Resolve ebuild, and changelog conflicts first, these are easiest with git mergetool, imho, but don't try to use that to merge manifests. Instead of merging manifests just regenerate them with ebuild ebuildWithScrewedManifest digest. once you've resolved all conflicts run git commit. That's it your done. you've now merged an overlay into your local funtoo tree. If you'd like to see it in funtoo you'll have to talk to Dan Robbins. He's on #funtoo on freenode regularly.