Excellent! Thanks for letting me know, Mats. There is a newer version in git, if you feel brave ;-) I'll probably push it out as a pre-release in a few days, barring any surprises. Need to fix the tmpfs thing and then finish on 0.1.4.

New update and portage 2.2. I have updated my portage and ran a script due to installing kde4 but now the update cannot write to my package.mask/unmask as those are now directories as im ran the script to switch from file to directories. does anyone know how to switch update to work with the new sets function in portage 2.2?

thank you for your time.

Grilo[/url]_________________Knowledge is power but the drive to learn is harnessing wizdom

New update and portage 2.2. I have updated my portage and ran a script due to installing kde4 but now the update cannot write to my package.mask/unmask as those are now directories as im ran the script to switch from file to directories. does anyone know how to switch update to work with the new sets function in portage 2.2?

Um it's not the sets (update handles those afaik) so much as the directory use and unmask; did you get an appropriate error message about that?

I don't use directories for those so just left the logic in place to handle them (ie stub functions) when it came up, which would need a bit more code (USE editing has only been what I'd call stable for the last month or so.) If you search for: ((pUseisDir)) (yes it's wrongly capitalised on 'Is', meh we'll fix it soon;) you should find the functions (about line 2000) for that setup. ATM they're pretty much just copies of the single-dir cases. You're welcome to patch those (they haven't been changed in ages and no-one else is working on them) or if you want log on to #friendly-coders on irc.freenode.org and we'll do it collaboratively.

You might want to work from the git version, details are on the trac site; but as I mentioned that part of the code won't change under you if you want to work on it.

Yeah I'm getting some wierd "unexpected" errors; looking at code it calls skipCompile with pkg names and not indexes which is wrong. We reworked all the blocker stuff, so I'll try and fix it myself tonight, if not I'll bug Ranjit tomorrow. Heh he was obviously tired on that part (which is good in one sense, cos now I get to tease him about it;) I have a feeling it might be me "simplifying" skipCompile tho.

Meantime, you need to take sys-libs/ss and sys-libs/com_err out of world file (/var/lib/portage/world) and then portage should get past the block automatically. (It's the bug that was on front page for quite a while.)

[...]Meantime, you need to take sys-libs/ss and sys-libs/com_err out of world file (/var/lib/portage/world) and then portage should get past the block automatically. (It's the bug that was on front page for quite a while.)

Not quite ... I have neither sys-libs/ss nor sys-libs/com_err in my world file and still get those blockers with the latest update (from git). There has to be something else which causes those blockers (no, I don't have mit-krb5 installed).

I have neither sys-libs/ss nor sys-libs/com_err in my world file and still get those blockers with the latest update (from git). There has to be something else which causes those blockers (no, I don't have mit-krb5 installed).

OK this is most likely because you are running stable portage so the blocker won't be resolved automatically. You could try:
update portage-2.2_rc12 and it should give you the option of unmasking just that version.
I'm sorry I didn't do the warning for it, I thought it had all been fixed in the tree, so just took the front-page alert down after a few more weeks. Really we need to allow checks on state of system which I put to one side for a bit.

notHerbert wrote:

I think the -e option is nice, and useful. I always found it rather strange that gcc is emerged near the end of an emerge -e system/@system, or bootstrap.sh.

I shall definitely use this next time I need to do a system emptytree emerge, i.e a new installation.

Thanks a bunch. :)

You're very welcome :-)

Quote:

BTW: your script called me an l33t ricer, you know, because of the tilde. It reminds me of the Sid caveat "If it breaks you get to keep both pieces." 8)

Lol, never heard it with 'both' only as "you get to pick up the pieces." That "leet boy ricer" thing was for jakub; I take it/hope you got the messages about how to disable it? Getting it to allow my funky ld flags was fun. ;-)

I've got the blocker thing working a bit better on 2.2 (the output changed recently) so will get it to handle e2fsprogs-libs for me at least (build the binpkg before uninstalling) ATM it would just uninstall before building, but we might as well try the build of a binpkg first, in the general case, I reckon.
One could poke holes in that, but if it works I'm using it ;p

Yeah I love the -e toolchain stuff, even if I do say so myself :-) It's designed to handle bringing an old system/stage install up to date as well; eg if binutils has been upgraded it'll be built both before and after gcc (look for auxRB in the code if you're interested or want to add something to that list; first occurrence is where to plug in, others are where it gets used, ie the more complex toolchain handling.)

edit: To handle e2fsprogs-libs block, just do emerge -auDN mit-krb5 e2fsprogs on portage 2.2; you can use update portage-2.2_rc13 to unmask just the latest version if you want.

We had that one 2 months ago on tilde boxes, which now leaves us free to help others. :wink:

Heh, I admire the spirit (and the motivation) but think it'd be better be directed into Arch-Testing which needs a mostly-stable box, with selective unmasking. That's also a much nicer way to run a box imo, since you're more reasonably sure about where the bugs are.

I'd heard about that block ages ago too (that's why it was on front-page for so long.) I got told everything was hunky-dory, but it turned out that required unstable portage, and ofc I didn't see it as I'm on stable <most other stuff> and have been worrying more about keeping update working with changing portage versions than some bug that was "fixed in-tree". ;-) Seriously, though, think about becoming an AT if you have time to help; that'll help packages get in quicker.

You can test in a chroot if you really must run a l337-boi system.. ;p

pfft, welp was a dev when he was 16. If you can find and file bugs, especially if you can add a patch (you'd be surprised how minor many of those turn out to be) you'll be useful. You'd need more time to be a full dev, but AT isn't that much work for someone who runs unstable imo.
So long as they can be weaned onto using package.keywords ;) which is what update's supposed to help with. eg update -a --recover if you lose your package.keywords also works for a machine that you've switched profile on. But like I said, you don't need to do that and can use a chroot for AT work.
@all:
NB Do NOT do this for real until you've finished a full update including revdep with no problems. Remember: they're your pieces, don't expect us to stick 'em back together ;-)

I don't know much about zsh completions, just looked at a website online and tried to figure it out. A lot of ideas and code are taken from the already installed completion functions.
To use this completion function, I have appended the following in /etc/zsh/zprofile