[gentoo-user] Gnome 2.16?
I see Gnome 2.16 is released - http://www.gnome.org/start/2.16/ Anyone got a timescale for when it will be in ~x86? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gnome 2.16?
On Thu, 7 Sep 2006 14:51:00 +0100 (BST), Peter Campion-Bye wrote: I see Gnome 2.16 is released - http://www.gnome.org/start/2.16/ Anyone got a timescale for when it will be in ~x86? http://packages.gentoo.org/packages/?category=gnome-base shows ebuilds for most of the packages already, but they are still hard-masked. you could install them now if you added them to /etc/portage/package.unmask. Yes I saw that, but I thought it would be wise to wait until there's a 2.16 meta-package for gnome-base/gnome itself, hopefully it won't be too long. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge without download
I download first all the files and put them in /usr/portage/distfiles. After that, I can make an emerge package. So you download them manually? If so, its better to use emerge -f package. It automatically downloads the files and all dependencies to /usr/portage/distfiles, and you can be 100% sure that when you emerge them for good it will use those files. Or, if you must download them manually, try using overlays, and ebuild package digest so that portage knows to use THAT file and it doesnt return md5 errors (size and so on, if Portage uses different tars) Or, as a workaround, you could set up http-replicator (there's a package for it) and put your downloaded ebuilds into the replicator cache then change your make.conf rsync settings to emerge from the replicator. The replicator log will show you anything it thinks it needs to download that it can't serve from the cache. -- gentoo-user@gentoo.org mailing list
[gentoo-user] emerge --resume question
Hi, Trying to do an 'emerge -e world' I come up against the odd package that doesn't build without some intervention. I know I can do 'emerge --resume --skipfirst' and carry on, but sometimes the broken package could be built ok with a little intervention, for example, my build breaks on pilot-link, which can be simply fixed with 'FEATURES=-sandbox emerge pilot-link'. Problem is, I can't do a resume after this as the emerge list from the world build has been blatted when I emerged pilot-link. So, is there any way I can preserve the state of the world build, so that after building the breaking package I can do a --resume --skipfirst and carry on with the world build? Any other suggestions for workarounds? thanks -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --resume question
This is resilient to the single merge between resumes case in 2.1_pre. For 2.0, you can manually back up and restore /var/cache/edp/mtimedb. -- Jason Stubbs Thanks Jason, I'll give that a try. Regarding the original problem with pilot-link, there is AFAIK no way to specify FEATURES on an individual package basis (ie put 'app-pda/pilot-link -sandbox' into a file named package.features, in the style of the package.use file) - is that correct? Thanks -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --resume question
Regarding the original problem with pilot-link, there is AFAIK no way to
specify FEATURES on an individual package basis (ie put
'app-pda/pilot-link -sandbox' into a file named package.features, in
the style of the package.use file) - is that correct?
You can use /etc/portage/bashrc to set anything on a per-package basis.
Put this in /etc/portage/bashrc
for MY_ENV in ${PN} ${P} ${PF}; do
if [ -f /etc/portage/env.d/${CATEGORY}/${MY_ENV} ]; then
source /etc/portage/env.d/${CATEGORY}/${MY_ENV}
fi
done
And put 'FEATURES=-sandbox in /etc/portage/env.d/app-pda/pilot-link
Very neat solution Neil, thanks.
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --resume question
On Monday 03 April 2006 16:45, Peter Campion-Bye wrote: Regarding the original problem with pilot-link, there is AFAIK no way to specify FEATURES on an individual package basis (ie put 'app-pda/pilot-link -sandbox' into a file named package.features, in the style of the package.use file) - is that correct? You can do this from the command line: FEATURES=-sandbox emerge app-pda/pilot-link Thanks, I know that, the question was how to arrange for specific features to apply only to an individual package in the middle of an 'emerge -e world'. It would be nice if the package.use functionality could be mirrored with a package.features file, but I suppose it's needed so rarely that it's not worth the effort on the part of the portage devs. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge --sync
I find that temporarily putting a line: FEATURES=-strict in your make.conf usually gets around this problem. hi, got this error not the first time, shouldnt there be a sync option to sync part of portage not the whole thingy? 002617 !!! Digest verification Failed: 002618 !!!/usr/portage/dev-python/pyrex/pyrex-0.9.3.1.ebuild 002619 !!! Reason: Filesize does not match recorded size 002620 002621 Please ensure you have sync'd properly. Please try 'emerge sync' and 002622 optionally examine the file(s) for corruption. A sync will fix most cases. martins -- Linux 2.6.13 AMD Athlon(tm) 64 Processor 3200+ 09:08:42 up 23 min, 4 users, load average: 0.18, 0.31, 0.57 -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
[gentoo-user] CONFIG_PROTECT problem
Hi, Apologies if I've misunderstood the use of CONFIG_PROTECT, but I think I've found a hole in it. As I have lots of stuff under /var/www/localhost/htdocs which contains configuration files mixed in with the code ( phpmyadmin, phpldapadmin, phpwiki, squirrelmail, gallery etc ) I have put the path /var/www/localhost/htdocs into CONFIG_PROTECT in make.conf. When one of these packages is upgraded this seems to work fine. Last night, after upgrading PHP to 4.4.0 my wiki was broken. I thought a good place to start would be to re-emerge phpwiki, so I did. During the emerge it flashed up a message about this being a package that it couldn't upgrade, so it would be unmerged it first. It appears that this bypassed the CONFIG_PROTECT mechanism, as when the new files were installed the original had been removed, so no ._cfg_ files were created for the changed files. Having no recent backup (lesson learned!) I had to recreate the phpwiki config, which is a non-trivial job. So the question is, how can config files be protected in this kind of situation (other than backing them up) - is there another mechanism to protect files from being overwritten, and how many packages are likely to do an unmerge before re-emerging, and is there ay way of knowing? I believe the default behaviour on umnerging a package is to leave its configuration files in place, this doesn't seem to apply to the web apps. -- gentoo-user@gentoo.org mailing list
