Thanks for the effort! I've been using update almost since the beginning. Still works great!

Thanks :D that's always the best feeling, when someone says they like your work.

Jennel wrote:

Good but not enough! need more improvement!

You realise that error was due to it being run under sh and not bash? And that it was _ages_ ago? ;)

Anyway, there's a new version linked on front page.

Sorry I haven't been about and that the DNS was down. It's now pointing at a new server, so hopefully it'll stay up. We'll sort the bug tracker out soon as well.

Be aware that you can't set -j or --jobs in EMERGE_DEFAULT_OPTS as it messes with the output displayed by update. That option is next on the agenda; rather than just masking it, I'd like to use it properly, along with --keep-going.

I've added an eixSyncFlags config variable (to git) as unstable eix doesn't like -m any more; use eixSyncFlags='-MN' or eixSyncFlags='-M0 -N' in /etc/update if you're on unstable eix.

One of those will become the default when current (0.22.5) eix is no longer around. I'm not sure what -M0 vs -M does, as I'm still on stable; the error message from the new versions says to use -M0 instead of -m. We'll leave that config variable as an option, since things might change in the future, and you might want to change how eix-sync is run.

BTW don't add -q (unless you really want to;) as that's normally added when -q or -x is used to update.

Another thing to note is that (in git) we now install to /usr; the script has been changed to allow its install anywhere and it looks for the lib file (libIgli;) in /usr/share or /usr/lib (old) or current directory (or you can export libIgli='/some/path' before running.) So, I recommend:
rm -f /lib/libIgli /usr/lib/libIgli
after you've installed from either the ebuild or make install in the git checkout, if you have an existing version.

edit: now installs to /usr/share

Last edited by steveL on Mon Oct 14, 2013 10:01 pm; edited 1 time in total

Just noticed your new page with a regular ebuild. Is there any chance you might consider putting this in an overlay (e.g., git.overlays.gentoo.org) so we could just pick it up by adding the overlay in layman instead of needing to put it in our own local overlay?

yes update is getting some long overdue loven
as to overlay, the 9999 ebuild is the prefered so an overlay isn't needed, but if specific releases occur (as well as other weaver projects) then yes an overlay is worth concidering

https://weaver.gentooexperimental.org/trac/update_________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

Just to let you know I've pushed a new release to help with the libpng-1.5 ABI upgrade, for those who haven't done it already. This also brings in quite a few bugfixes since last release in August, if you're not using the live ebuild.

Portage --jobs support is much better, tho it still needs a bit of tweaking as I haven't had a package fail on me yet while using it, so I'm not even sure what that looks like. It also needs to pick up on config updates, which I'll fix in next few days; I just wanted to get the ABI fix out to people who don't upgrade every day or two.

Meantime the libpng upgrade is handled pretty effectively imo. The only bit you'll need, after the whole shebang including world update (after ABI and its revdep) and main depclean/ revdep (ie: after update -s or update -r has run to completion), is to run the command from the forum post about it (slightly modded; all on one line):

If that outputs any package:slot's (there were only two here, after all the packages update had already sorted out) then run:

Code:

update $pkg

I'd run another update -CR after that, just to make sure (for some reason kword didn't get picked up til then here.)

Be careful to let the ABI upgrades run to completion; only start again with update -r once you've seen [ABI Stage N] running. We need to make it more robust; at the moment it'll get rid of the ABI files if you start another update: if libpng has been upgraded (and it's only the second in a whole load that do) then it won't come to the program's attention again.

Just to let you know I've pushed an update to the git repo which deals with new default --quiet-build=y setting in emerge. This only affects the output when you're not using --jobs or -j in default-opts, or you run update with -j1 (or --jobs=1 if you like that sorta thing;)

I've also improved the list editor, primarily so we can reselect packages skipped by the configuration. There are a couple of display tweaks; eg package description in USE editor as well as main list (check the status bar if you don't know what I'm on about.)

In addition useless C++ rebuilds are skipped along with the usual suspects (ie: if you have not set skipUseless=0 in /etc/update and don't pass --build-useless to update.) This is for the recent removal of nocxx flag in favour of cxx across the board. Don't worry: it's perfectly safe! It's tied to a very tight formula, of the only change being cxx%* addition at the same time as (-nocxx%) or -nocxx. The latter is for gcc which is keeping the flag during the transition precisely for people like us who don't want to rebuild it for no use.

I'd like to roll this into a release so please try it out if you're using the git ebuild and shout if something breaks. If you want anything fixed bug reports are better, especially if you want something unusual done for your own needs (file as 'enhancement') or you want to be able to chase it along. ;-)

Sorry I've been offline last couple of months. I don't have java on my system but I've looked at what subversion wants, and I'll play with it now. I'm going to use the opportunity to add a rough ebuild data thing to the dialog, so I can look at deps for virtual/java as I'd like to be able to quickly see what my options are without having to dig out the ebuild.

I pushed an update to git yesterday that deals with SLOT-blockers as I was getting hit on the KDE upgrade. (I was in the middle of other stuff, so it took a while to sort it out.)

There's also a small fix to deal with the new kernel-3 series. Effectively all 2.6 and 3.x kernels are the same for purposes of system upgrades, so linux-headers 2.6.39 is fine on kernel 3.1 and linux-headers 3.1 are fine on 3.2. (This doesn't affect versioning, so 3.1 headers will still not be allowed on a 2.6.39 kernel as usual, to avoid headers which provide symbols the kernel doesn't know about.)

then you'd get a similar error. I reckon it's to with the command being run without a terminal on stdout or stderr, in other words.

I'm guessing that's why the python textrap.py script is getting a negative self.width for the width of the window. Really it should default to a sane value like 80, as this means java-config can't be run as part of a script. java-config could check for it itself, I suppose, but it's something I'd fix at the lower layer, as that's what is allowing the value in.

If the above does give you an error (I'll know in a while when I get through all the preliminary installation) then we'll probably best file a bug against java-config which devs can punt upstream if they agree. Even if I work round it for update (which I'm kinda wondering about, given that parallel builds would need to be broken up) it's going to stop any script which wraps emerge as above from working; and I know zmedico takes scripting with emerge seriously.

Yeah, sorry about that, I tend to just work on the git version. I have been feeling for a while I should put out a release, so thanks for prodding me (I couldn't believe it's been over a year though ;) Anyhow, here it is: update-20121210.ebuild

I haven't made any changes and been using that version quite happily for a couple of weeks, so it's a good time to release it. God only knows what bugs have been fixed in that time :-)

Also, I have some changes I've been wanting for ages, to sort out gcc-config on upgrade (there's an old code branch in the git repo that has a prior attempt at it, that I completely forgot about til I reviewed recently) which I haven't put in (they're sitting in a WIP branch locally) as I haven't had a gcc upgrade to test them with. I'll push them to git though, now that a release is out, as it's disabled by default atm, til I can be sure it does the right thing.

Bear in mind that you need to use repoman manifest nowadays to get the digest. I guess we really should think about doing an overlay, but I have nfc how to set up what iMike suggested, if I'm honest about it.

Anyway, HTH, and thanks again for prodding me. It's nice to know people are using it :-)

Yeah that one's fixed in git: I didn't realise it was that recently, I thought it was before that version went out. Maybe it was just on my mind for ages (the code was really crufty, practically from when update started.)

Quote:

I do not know if I found a bug or feature running

Quote:

# update -acuD @world

and: edit the list, deselect all entries with space, press enter results in update of all packages.

Hehe I'd definitely call that a bug. There are checks in a couple of places to ensure we haven't skipped everything, or bail out, so clearly something's not right. It should be smarter if you've skipped them all in edit list, so I'll take a look at that today or tomorrow, and put out a fixed version. There's been a couple of other bugfixes in git recently so it's needed. Thanks for letting me know, geki.

Quote:

anyway, thank you for the console-based package selection. that will save a bit of my time updating my box! :)

I'm glad you like it :-) It's my favourite part of update; though I don't use it that often, when I do, I really appreciate it, especially USE editing.

Hmm reminds me we still need to handle a package.use directory instead of file. It's just such a PITA to do properly, since we need to account for the same package in several places, possibly with conflicting settings. But it is more and more common; crossdev for instance requires it.

So, I am asking should the assignment be appended to make.conf in the same fashion as the "source" statement?

Yes that's fine (and as you have it, after the layman source.) You don't need 'export' in make.conf, as it's actually parsed by python shlex (i think it's called) and portage will export them as needed (eg CFLAGS from make.conf is exported to the ebuild environment.)

Let us know how you get on. :-)

--
I'll push a new release soon, promise. Can't really avoid it, as I accidentally committed all my work-in-progress to master, so have to get it working correctly. Thankfully, Griz verified it still works for normal usage.

Thanx for the quick reply. I'll revise (and test) & update the ticket with the new script. Feel free to add the script to your git repo and/or extract the appropriate lines to use stand-alone, if I dont do it (probably be a while, I got other irons in the fire) lemme know if u think it needs more priority from me.
Best Regards, Bob

Thanks for prodding me. linux-headers is considered "toolchain" so handled specially: for instance you can't downgrade it, nor can you upgrade it to a version newer than the running kernel. Additionally when you upgrade linux-headers, update always adds glibc and does it immediately after. But it sounds like yours is a standard tree issue, to sort out via emerge config.

Anyhow your post prompted me to return my attention to update, so thanks. Unfortunately, I've just hit a new bug: I'm trying to just get my machine upgraded, with the --toolchain option working, so I can look at the other things that need to be done. You can see it's been a while, since I have 516 packages to install ;-) If you look closely, you'll see at the end it's trying to set USE=icu for media-libs/harfbuzz-0.9.18-r1 (a texlive dep: this is the texlive-2013 upgrade.) Somehow it's got the package name with a comment after it, which is new. Looking at unmaskAutoUSE() it's getting the right info from the file for the package and flag name, so I just have to track down where the comment data in the version-specific line has come from, and strip it then.

@anomalyst
I didn't really take in what you were doing, though what I said is still right: you can edit the make.conf externally however you wish. update reloads its settings if the make.conf changes: you can see the settings that we save in /root/emerge/Backup/makeSettings, by default; /root/emerge is the dir=... setting in /etc/update. It checks for both /etc/make.conf and /etc/portage/make.conf. I've just (a week or two ago) added some more support code in git for ROOT and PORTAGE_CONFIGROOT when not '/' which should make the kind of thing you're doing a bit easier.

One thing to be aware of is that directory ordering in PORTDIR_OVERLAY is the reverse to how it reads: ie the last in the list takes priority if all other things are equal (and only if they are equal) for "best-visible" calculation. I'm sure you know that, but it's a caveat that I have to point out, just in case.

chroot support had been on my mind for a while; update has always respected the two variables in terms of reading config, but now all the files it saves will (hopefully) be under the same target ROOT. The reason update has always picked up on those is because we needed to build in chroot when first adding /etc/warning support (ABI upgrades.) They aren't needed so much any more, thankfully, in the full extensive version, which was to get our machines through the expat upgrade, though the mechanism itself is still useful. Nowadays, principally udev, though the forthcoming openrc-0.12 upgrade is going in.

That work led to the installer, that I have to bring up to date. So your script looks interesting, since I've done the other side of it: downloading a stage, using dialogs to setup partitions, then chrooting and running update to bring the base up to date. Once you've done your kernel and rebooted, you just do the rest of the install as usual, though it's a lot nicer when update is the porcelain to emerge, ime. We stopped there because our machines were all done, and the next step was to use lspci -k to start kernel config, which at the time was not in stable. So I found your script most stimulating, as it's doing a similar thing: sfdisk is sweet isn't it? :) though from a totally automated point of view. Our one is much more focussed on being interactive, though you can drop predefined files in, to copy across automatically.

I'm busy for the next couple of days, but I will get some time on Wednesday or Thursday for more complex stuff. The new bug will be fixed by then, I imagine, or it'll be the first thing I sort out. Once my machine is upgraded with a correct toolchain, I'll look at your script and how we might interface: if it helps, there's an (undocumented) -H option for update that we use under the installer: it's short for 'Human' basically, and means "even though you think you're automated (and you are) we need to display our info to a Human" ;) It also means we ignore a couple of dependencies like dialog, since we're in bootstrap.

It's undocumented because it's specifically designed for our installer, and it can change whenever we need it to, without breaking other people's scripts. Try it though: it should make the display a lot nicer for your script. Just be aware it may change; though if you like, those can be changes you helped design. ;-)