Re: [gentoo-user] Update blocked by kdebase-startkde:4
On Sunday 14 August 2016, Daniel Frey wrote: > On 08/14/2016 05:12 AM, Robin Atwood wrote: > > 'layman -L' finds no kde-sunset. > > I had that problem too, it's not listed there. > > If you want to use it, create /etc/portage/repos.conf/kde-sunset.conf > with these contents: > > [kde-sunset] > auto-sync = yes > location = /var/local/overlays/kde-sunset > masters = gentoo > sync-type = git > sync-uri = https://anongit.gentoo.org/git/proj/kde-sunset.git > > Dan Dan- Thanks, I will try that. Robin -- -- Robin Atwood. "Ship me somewheres east of Suez, where the best is like the worst, Where there ain't no Ten Commandments an' a man can raise a thirst" from "Mandalay" by Rudyard Kipling -- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [gentoo-user] Update blocked by kdebase-startkde:4
On 08/14/2016 05:12 AM, Robin Atwood wrote: > 'layman -L' finds no kde-sunset. > I had that problem too, it's not listed there. If you want to use it, create /etc/portage/repos.conf/kde-sunset.conf with these contents: [kde-sunset] auto-sync = yes location = /var/local/overlays/kde-sunset masters = gentoo sync-type = git sync-uri = https://anongit.gentoo.org/git/proj/kde-sunset.git Dan
Re: [gentoo-user] EAPI packages
On 08/13/2016 10:09 AM, hw wrote: >> >> Not the whole system, only portage. It should still be your last resort, >> but on the bad-idea scale it's only a 1 or a 2. > > And how would I know which of all the files affect only portage and nothing > else, and what about the dependencies of portage? > equery f portage Chances are, portage will be happy with whatever dependencies you already have installed. If not, you can repeat the process on those dependencies. Booting into a liveCD on another machine and making a quickpkg would save you from having to overwrite the files manually. But, I think Andreas's was the best suggestion so far.
Re: [gentoo-user] Update blocked by kdebase-startkde:4
On Sunday 14 Aug 2016 19:12:43 Robin Atwood wrote: > On Sunday 14 August 2016, Peter Humphrey wrote: > > Well, either you can try it to see what happens, maybe putting it back > > afterwards, or you can remove that line from the ebuild - again, > > temporarily. Or try the kde-sunset overlay as Dan suggests. > > > > It's becoming steadily harder to stick with KDE-4 in Gentoo. I gave up a > > few weeks ago, once I'd found a desktop arrangement to suit me. > > Using -wallpapers worked and I still have wallpapers. USE=wallpapers is not the same thing as installing a wallpapers package. It looks in this case as though setting the flag will cause packages to be installed as part of *-meta, but I dare say it's just a convenience to save one operation. > 'layman -L' finds no kde-sunset. Google suggests it's in git nowadays. > I suppose I will at some stage have to install KDE5 on a > laptop; will KMail 4.4 still work? It does here, though not on a laptop - well, as well as can be expected, that is. -- Rgds Peter
Re: [gentoo-user] Question about genkernel's default kernel config
On 14/08/2016 13:45, Raymond Jennings wrote: > Hey, just curious about something: > > How is genkernel's "default" kernel config maintained? Is it fixed, or > is it maintained as a diff against upstream, or what? it's mysterious magic > > I'm curious because I'm considering if I should just go straight to the > kernel's own built in defaults. do this. build code for the hardware you have, not for hardware you don't have > > I know a lot of it sets up most things as modules instead of > builtin/disabled. genkernel builds a kernel like for a binary distro or a LiveCD - works everywhere (by enabling everything). You can customized it with a config somehwow (I forget the details). But this is gentoo: cd /usr/src/ make menuconfig -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] EAPI packages
Hello, On Sat, 13 Aug 2016, Andreas K. Hüttel wrote: >Am Mittwoch, 10. August 2016, 12:54:37 schrieb hw: >> I?m trying to upgrade portage because I?m getting a message that it >> needs to be able to work with EAPI 6 packages and can only do EAPI 5. [..] >If you see this now, your production server hasn't been updated for a long >time... > >As a last resort, you should be able to run a "non-installed" portage version >to update your system once. Manually download and unpack a recent portage >tarball somewhere temporary and then run as root something like > >porto tmp # ./portage-2.3.0/bin/emerge -uDNav world > >This can update your system to the newest state, including updating the >installed portage. Afterwards you won't need the temporarily unpacked portage >anymore. Yep. BTDT. I had a then 4-4.5 year old gentoo quite broken by being partly updated until portage/emerge broke and much else didn't work anymore (gcc/make/python/emerge). So, I booted something else, mounted gentoo somewhere (say /mnt), unpacked a fresh stage3 _into_ that mountpoint into /stage3 (i.e. "/mnt/stage3"), chrooted there (with the usual /sys, /proc, /dev bind-mounts) and then ran stuff from the /stage3/ tree[1] until the basic stuff (mainly above mentioned 4) was fixed. From then on it mostly went "smooth", by the "textbook", considering. Yeah, lots of conflicts and whatnot because of moves, renames and new deps etc.pp. It was a bit tedious, but not difficult. And this general tip came out of it: unmerging stuff helps to break tangles. Like slashing the Gordian Knot ;) Before you yourself get stuck in the same tangles that emerge did, be bold, take note and switch to a "unmerge + reemerge" strategy! I.e. take one offender, note it down (textfile and/or paper), unmerge it, try a re-emerge of that offender or a @world without it. Keep adding to the "offenders" list until emerge comes up "clean". Then try re-emerging the offenders one by one. It's one of the first things I do when weird stuff/conflicts crop up. Before I mess with useflags and masks and whatnot, I unmerge both tangled packages (and keep track of anything I unmerge in a textfile or so!) and then try to merge only those (with '--pretend --tree' at first). Emerge IMO handles the "install" case much better and the conflicts are often much clearer, "obsolete" deps can be ignored and/or handled later by "emerge @preserved-rebuild". And once I've figured out what's going on, it often is just one useflag, or one (un)mask or something else in /etc/portage/package* to clear it all up. And finding that is much easier doing it one-by-one. Of course, you can't unmerge stuff like gcc/make/python/portage just like that, that's when an unpacked /stage3 comes into play. But you should not need that until your system is _way_ outdated (as was mine). Anyway: so, yes, you can use a unpacked up-to-date /stage3 for bootstrapping an update once your system is so (ridiculously) outdated that a normal update breaks, and not only for installing a new system :) Of course, you'll have to deal with new/renamed/moved/gone packages and such stuff, but that's to be expected[3]. And IIRC that strategy had me upgrading quite smoothly to the new perl-5.24 (from 5.20 or .22?) just recently. At times, emerge _does_ get somewhat stuck. And it's output gets confusing to match. But! Usually, when your system is not too much out of date, emerge does a _very_ good job, it's output is a bit hard to read though, something IIRC the devs are the first to admit, but as Neil and others prove here often (I'll try to get more into helping too), you can get used to it and pinpoint the actual reason for emerge barfing tons of text on you. -dnh [1] IIRC by adjusting PATH and LD_LIBRARY_PATH until I got the tools. Once that was done, I (rebooted and?) re-emerged those "natively" from the actual gentoo with "/stage3" "removed" from PATH. PS: I've done similar stunts with other distros... install only a 64bit kernel/glibc/rpm[2] while the repos still pointed to i586 because you updated the repos to the new version but not the repo-config to x86_64? Bad idea! But "fun"! (boot something, mount target as /mnt and an ISO under /ISO) and then cd /ISO/../x86_64/; rpm --root=/mnt --test -ivh package_manager.rpm \ more_and_more_rpms ../noarch/even_some_more_rpms until the package_manager ran. Much like emerge in my gentoo case. And yes, I still run both systems, updated since then quite a bit, everything checks out, I even got rid of leftover i586 packages on that at-first-fouled-up-switch-to-x86_64 system. [2] or the other way round? Anyway: basically nothing but the kernel itself ran. So, boot something else, and ... [3] and which is why I like stable stuff like TeX, WindowMaker, mutt, tin, mc, joe, (X)Emacs, lynx/links/w3m or even netscape/seamonkey that does not get incompatibly rewritten from scratch every couple of
Re: [gentoo-user] Update blocked by kdebase-startkde:4
On Sunday 14 August 2016, Peter Humphrey wrote: > On Saturday 13 Aug 2016 22:54:19 Robin Atwood wrote: > > On Saturday 13 August 2016, Peter Humphrey wrote: > > > On Saturday 13 Aug 2016 20:56:50 Robin Atwood wrote: > > > > And the next problem: > > > > > > > > !!! All ebuilds that could satisfy > > > > "kde-plasma/plasma-workspace-wallpapers:5" have been masked. > > > > !!! One of the following masked packages is required to complete your > > > > request: - kde-plasma/plasma-workspace-wallpapers-5.7.3::gentoo > > > > (masked > > > > by: package.mask, ~amd64 keyword) > > > > - kde-plasma/plasma-workspace-wallpapers-5.6.5::gentoo (masked by: > > > > package.mask) > > > > > > > > (dependency required by "kde-base/kdebase-startkde-4.11.22- > > > > r2::gentoo[wallpapers]" [installed]) > > > > (dependency required by "@selected" [set]) > > > > (dependency required by "@world" [argument]) > > > > > > > > Why does kdebase-startkde:4 want plasma-workspace-wallpapers:5? has > > > > anyone solved this yet? > > > > > > I don't know, but the ebuild calls version 5 explicitly. > > > > > > What happens if you add USE=-wallpapers to startkde in package.use? > > > > I wondered about that but thought I might end up with no wallpapers. :( > > Well, either you can try it to see what happens, maybe putting it back > afterwards, or you can remove that line from the ebuild - again, > temporarily. Or try the kde-sunset overlay as Dan suggests. > > It's becoming steadily harder to stick with KDE-4 in Gentoo. I gave up a > few weeks ago, once I'd found a desktop arrangement to suit me. Using -wallpapers worked and I still have wallpapers. 'layman -L' finds no kde-sunset. I suppose I will at some stage have to install KDE5 on a laptop; will KMail 4.4 still work? Cheers Robin -- -- Robin Atwood. "Ship me somewheres east of Suez, where the best is like the worst, Where there ain't no Ten Commandments an' a man can raise a thirst" from "Mandalay" by Rudyard Kipling -- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
[gentoo-user] Question about genkernel's default kernel config
Hey, just curious about something: How is genkernel's "default" kernel config maintained? Is it fixed, or is it maintained as a diff against upstream, or what? I'm curious because I'm considering if I should just go straight to the kernel's own built in defaults. I know a lot of it sets up most things as modules instead of builtin/disabled.
Re: [gentoo-user] Update blocked by kdebase-startkde:4
On Saturday 13 Aug 2016 22:54:19 Robin Atwood wrote: > On Saturday 13 August 2016, Peter Humphrey wrote: > > On Saturday 13 Aug 2016 20:56:50 Robin Atwood wrote: > > > And the next problem: > > > > > > !!! All ebuilds that could satisfy > > > "kde-plasma/plasma-workspace-wallpapers:5" have been masked. > > > !!! One of the following masked packages is required to complete your > > > request: - kde-plasma/plasma-workspace-wallpapers-5.7.3::gentoo > > > (masked > > > by: package.mask, ~amd64 keyword) > > > - kde-plasma/plasma-workspace-wallpapers-5.6.5::gentoo (masked by: > > > package.mask) > > > > > > (dependency required by "kde-base/kdebase-startkde-4.11.22- > > > r2::gentoo[wallpapers]" [installed]) > > > (dependency required by "@selected" [set]) > > > (dependency required by "@world" [argument]) > > > > > > Why does kdebase-startkde:4 want plasma-workspace-wallpapers:5? has > > > anyone solved this yet? > > > > I don't know, but the ebuild calls version 5 explicitly. > > > > What happens if you add USE=-wallpapers to startkde in package.use? > > I wondered about that but thought I might end up with no wallpapers. :( Well, either you can try it to see what happens, maybe putting it back afterwards, or you can remove that line from the ebuild - again, temporarily. Or try the kde-sunset overlay as Dan suggests. It's becoming steadily harder to stick with KDE-4 in Gentoo. I gave up a few weeks ago, once I'd found a desktop arrangement to suit me. -- Rgds Peter
