Funtoo Updates
Some quick updates:
Per request on this blog, I am now building ~pentium4 Funtoo (unstable) stages which can be downloaded here.
For the past few weeks, all my stage3’s have been about 15MB smaller than they were before due to the fact that I only build the en_US ISO-8859-1 and en_US UTF-8 locales by default. If you need to add any additional locales, edit the /etc/locale.gen file appropriately and then run the “locale-gen” command as root.
Starting with the October 1st ~x86 build, all Funtoo (unstable) stage3 builds now include dhcpcd and git. Gentoo stage3’s that I build do not contain any extra packages.
I have updated my git Portage repository at http://github.com/funtoo/portage/tree/master, and it now contains three branches - master, which has a README file and LICENSE file in it, gentoo.org which contains the official Gentoo Portage tree, and funtoo.org which contains the Funtoo tree. I’ve updated my wiki documentation so that it explains how to use it. The only part of the documentation that I haven’t updated is the advanced part that explains how to fork the tree. If you want to fork the tree on GitHub, I recommend creating your own branch. This is as easy as typing “git branch foobar.com” (your domain) with the funtoo.org branch active. I’ll update the docs with instructions on how to get your branch to show up on GitHub real soon now.
Work on Metro has been going along well too.
17 comments:
You write under the forking section:
"# git pull funtoo.org master"
Won't this just pull the master branch, which only contains a README file?
Right, as I stated in my blog post, I haven't updated that section yet.
Regards,
Daniel
It's probably a good idea to change profiles/repo_name to something unique (say, funtoo_gentoo and funtoo) in both repositories. Various tools get upset if different repositories call themselves the same thing.
Ciaran, do you have any additional docs on how Paludis and friends use repo_name so I can put together a plan for how to handle this for forked repos? Alternatively, you could just post info here. Ideally, I would like to use a domain name like funtoo.org. I was thinking of using a URL to the public git repo but I see in "man portage" that ":" is not allowed in there, so I'd like to understand why that is and how these names get used internally.
Thanks!
Things making specific use of repo_name that I can think of:
* GLEP 42 (news items) uses it to distinguish between news items from different repositories. This was the original reason repo_name was introduced -- there has to be a way of identifying news items globally, even if a repository changes its sync URL and a news item's content is updated.
* Tools supporting repository deps use it in package dep specs, like cat/pkg::repo. Paludis supports these in configuration files (you can, for example, unmask accept unstable keywords for a given package only if it's in a certain repository, or all packages in a certain repository using */*::repo) and on the command line (paludis --query cat/pkg::repo and paludis --install cat/pkg::repo, for example). Pkgcore supports some of this too, but for some reason doesn't let you install from a specific repository. This is the primary reason for all the restrictions on what's allowed character-wise -- we're trying to reserve any special characters that don't already have meaning for future EAPIs. The full list of supported characters is in http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git .
* It lets the package manager deal with overlays in a more friendly manner. Rather than saying "foo/bar in /usr/portage/overlays/blah", which quickly gets messy, it can just say "foo/bar::blah". When looking at bug reports, it means developers don't have to ask the user "and where did you get the overlay you have at /usr/portage/overlays/blah?".
* Paludis also has from-repository dependencies, in the form ::repo-> . This lets you do things like 'paludis --query */*::repo->' to show anything installed from a given origin repository.
* It's used by various tools that track all the layman repositories to uniquely identify a repository. For example, to cope with the huge number of overlays out there and the increasing move towards distributed development rather than a single huge repository, Paludis will let you do basic query operations on packages in overlays that you don't have configured (if you do paludis --query gcc, for example, it will show you gcc versions in repositories like toolchain and dirtyepic even if you only use the main Gentoo repository, and if you try to, say, paludis --install omega, Paludis will give you a "no available versions" message that includes a list of overlays you might want to use to get that package). Doing this requires a unique identifier for each repository known to layman, and we use repo_name for that. There's an early example of this in http://ciaranm.wordpress.com/2008/06/12/dealing-with-lots-of-repositories/ .
Hey Daniel, I'm having some problems with yours more recents stages 1 builds, there is some files missing in /etc like make.profile for example, I have downloaded the files
http://www.funtoo.org/linux/i686/funtoo-i686-2008.09.30/stage1-i686-2008.09.30.tar.bz2
and
stage1-i686-2008.09.30.tar.bz2
to compare each other and some importants files like make.conf make.profile are missing in the 2009.09.30 release, this is a bug in metro orits a feature?
There is aothers files that are missing but i don't remember what files are, because when i try compile glibc they fail because there is missing some files.
thanks!
thanks for the bug report. I'll look into it.
Sezaru, yes, it looks like I need to copy over the /etc/make.conf and /etc/make.profile into the stage1 before tarring it up. Thanks for alerting me to this. The stage2 and stage3 tarballs should be fine.
Hey Daniel, i think more files are missing, i have opened side by side the et folder from stage1 ~x86 2008.10.01 and i686 2008.08.26, the 2008.08.26 have 57 objects in /etc and the 2008.10.01 just 49, i can confirm that ld.so.conf are missing, thats the problem i'm getting when compiling glibc, i will try find more missing files and write here.
btw, there is some bugtracker or a place to put bugs? i don't know if this is the right place to submit bugs.
Thanks!
I am in the process of evaluating bug trackers right now.
My stages are experimental and it's possible that some stage1's were not correct. I recommend looking at the ones after October 2nd since they are more recent. For all these stages, if there is a stage2 then the stage1 was "good enough" to allow a stage2 to build. I recommend holding tight until I release metro as then you will be able to see the actual steps used to build the stage2 and you can try these steps to validate the stage1.
Regards,
Daniel
Now if I could tell portage to access git repository directly, no more checkout needed...
Thanks for the git Daniel. It's genius.
Thought I would ask this "just in case" it may apply - though it is a long-shot. I dl'd and just installed your stage3-i686-2008-09-30 tarball and things were going fairly swimmingly but now getting circular dependencies. I don't know enough about it to know if this tarball could have anything to do with but figured it would only be fair to the gentoo users on their forum to inquire here.
The info is in this post by me, charliepoole.
Hopefully someone over there will jump in and help solve it but just thought I would post here in case. thanks much! /jd
Daniel, thank you for the git portage repository, yesterday I changed to funtoo.org as my main portage tree.. =)
Hi Daniel,
I wonder what your plans are. Your building your own Gentoo stages en preparations are in place to fork portage. Your even searching for a good bug reporting system.
Is it safe to assume that this will lead to a fork Gentoo? I am really curious to know your plans and how you envision the future of funtoo/gentoo.
Regards,
Aniruddha
Anirhudda, I am not competing with Gentoo. Anything I do is available to the Gentoo project. We are trying to make improvements to key parts of Gentoo that are needed for more open, distributed development. This is the mission of Funtoo - to empower the community.
In the 90's, a fork was a bad thing. With git, a fork is something that happens every day. To get into the mindset of distributed development, we need to view a "fork" as just creating your own working space so you can do your own thing.
Once you create your own working space, you can do something cool, and then you can share your changesets with others. They can then "merge" your fork. So the goal isn't the fork, the goal is to have a separate workspace so you can try out some cool things that eventually get merged back into the main distribution if appropriate.
We will continue to try to improve Gentoo in our tree. But we are not against collaborating with Gentoo developers. But we do like to have our own environment away from the main Gentoo project to do our work, because it is more pleasant and fun.
So the goal is not political. The goal is to do cool stuff and help others to do cool stuff, in a pleasant environment. Our work is freely avaiable and forkable as well. In fact, we encourage others to fork our work and build on it.
First of all I must say I was wrong in my initial assessment. I find the way you have chosen to enhance Gentoo exciting and promising.
I'm looking forward to see Gentoo evolve.
Post a Comment