Re: [gentoo-user] Re: trying to upgrade some old, never upgraded image for an embedded system …
On 2019-12-19, Thomas Schweikle wrote: >>> > On 2019-12-18, (Nuno Silva) < >>> > nunojsi...@ist.utl.pt> wrote: >>> > >>> > > The EAPI problem is in a package that is pulled as a dependency of >>> > > portage. >>> > > >>> > > Unless there's a simple hack to solve this, you will need to use older >>> > > ebuilds or split the update in several steps, using older versions of >>> > > the portage tree. The following notes show a way of achieving this: >>> > > >>> > > https://wiki.gentoo.org/wiki/User:NeddySeagoon/HOWTO_Update_Old_Gentoo [...] > So I've tried now to upgrade in various ways: > 1. the one given in https://anongit.gentoo.org/git/repo/sync/gentoo.git > But this fails as soon as I try to emerge git. python-exec is at version > 2.4.6 now. Without any 2.0.1 packed, legal versions left. Same for all > other dependencies. Not really a way to go ... Looking at this again, the installed version of portage says (in the output quoted in your initial post) that it supports EAPI 6, which is also used by the python-exec-2.4.6 ebuild (not in the tree anymore, the one using EAPI 7 is 2.4.6-r1). So you could give the 2.4.6 ebuild a try: https://gitweb.gentoo.org/repo/gentoo.git/plain/dev-lang/python-exec/python-exec-2.4.6.ebuild?id=20664dd65ec565233f460b94efc0337249b84550 Hopefully this will allow you to upgrade portage, unless there are more dependencies of portage in similar situations. If this ebuild is not enough, any chance you have another machine where you could do the date-based checkout and then copy the entire portage tree? -- Nuno Silva
Re: [gentoo-user] Re: trying to upgrade some old, never upgraded image for an embedded system …
On Thu, Dec 19, 2019 at 6:45 PM Thomas Schweikle wrote: > > So I've tried now to upgrade in various ways: > 1. the one given in https://anongit.gentoo.org/git/repo/sync/gentoo.git > But this fails as soon as I try to emerge git. python-exec is at version > 2.4.6 now. Without any 2.0.1 packed, legal versions left. Same for all other > dependencies. Not really a way to go … Not sure what you mean by this. Not really questioning it. It is just hard to provide responses to one-liners on technical issues. What python-exec is at 2.4.6? The one in the repo as of a few years ago? The one that is current (which will almost certainly not work)? A quick check of the log for that repo says that 2.0.1 was removed in Feb 2017, so as long as you check out a version from before then you should be fine as far as that is concerned. You might want to check out an even older version though depending on how old your system is. You still haven't mentioned that, and it matters. I'm not sure if you read my post but I wasn't suggesting just syncing that repo's current HEAD as if that was going to fix things. You need to check out an old commit from it. 6e534e02ec5a71c676dfbae1e9eb6041ef9316ab was the last commit before 2.0.1 was removed, for example - I don't think the tree that far back has metadata so you might need to build that too. > Since there isn't a stage3 and some portage tree matching, I'd ask: armv7 and > others have gone unsupported? Mentioning the arch in your first email probably wouldn't have hurt either. I'm not sure what the state of armv7 support is but somebody else might be able to comment on that. -- Rich
Re: [gentoo-user] Consolekit and elogind switch questions
Mick wrote: > On Monday, 28 October 2019 08:25:06 GMT Neil Bothwick wrote: >> On Mon, 28 Oct 2019 02:46:45 -0500, Dale wrote: >>> Thanks much for the info. Maybe the switch will go well for me too. >> If it works for you it will be good news for the rest of us ;-) > If hald's list of devices has anything to do with it, Dale is bound to nail > it > on the first (re)boot! :-) > > The consolekit framework is responsible switching between users on a system. > As I understand it, when you go to 'Plasma/Leave/Switch User' menu option, > console kit daemon is responsible for: > > 1. Looking at PAM and any processes you own as a user in a login session. > 2. Checking which seat (local or remote) you are logged in as and associating > the hardware you are using with it (e.g. keyboard, mouse, monitor, etc.). > 3. Connecting to the d-bus system bus to manage the local login session and > pass control of hardware devices to the new user. > 4. When the new user enters their credentials at the Display Manager, check > with PAM what processes the new user is authorised to access/use in their > login session. > > I should have the above mostly correct. You may ask if any of this control > framework complexity is *necessary* for a single user called Dale, who won't > allow anyone else to take his 'seat' at the PC without a fight. The answer > is > probably no, and this is why simpler desktop environments like *box, > Enlightenment, etc. do not offer the facility to switch users and therefore > do > not ultimately need consolekit. > > There are no screenshots of consolekit/elogind because AFAIK neither offer a > GUI application. However, when you run 'ck-list-sessions' in a terminal > you'll see your local session, as well as any other login sessions you may be > running at the time, e.g. /dev/tt1, remote logins over ssh and which of these > are active at the time. > > Since consolekit is no longer under development and systemd appears to have > taken over most of the Linux distros, elogind is the current service which > can > run as stand alone on openrc (just as udev of systemd does). > > When elogind is running you can use 'loginctl list-sessions' in a terminal to > see who's running a session. The man page gives more options. > > You don't *have* to add elogind as a boot service, because any applications > which need it will launch it themselves. However, don't be surprised if some > desktop functions are not working as expected. For example, the SDDM Display > Manager's shutdown/reboot buttons may not be displayed and even if they are > displayed they'll do nothing when you click on them after a reboot. If after > a reboot you login/out into your Plasma desktop, then elogind will be running > and the SDDM buttons should function again normally. > > I have converted a number of systems to elogind. It should be as easy as > setting in your make.conf: > > USE="elogind -consolekit" > > grep consolekit -r /etc/portage > > to find and remove/replace any USE flags still asking for consolekit to be > emerged. Then, > > emerge --depclean -v -a consolekit > > emerge -uaNDv @world > > emerge @preserved-rebuild -v -a > > rc-update del consolekit > rc-update add elogind boot > > reboot > > >From memory that's all there is to it. I just switched. I kept forgetting to do this when the puter was actually idle. Anyway, I changed the USE flags and did a emerge -uaDN world which updated/installed as new several packages and took about 30 minutes on my rig. Once that was done, I went to the boot runlevel and used the old checkrestart to see what needed restarting. Sadly, the init process, process #1, was in the list. While everything went well enough, so it seems anyway, I'm adding the reply to say this. It seems one does have to reboot. So, if anyone runs up on this thread, be ready for a reboot. I'm not sure what it is that made init need a restart but that's what it showed and I've never seen it listed before. Thanks to all, Mick for sure since he posted a general guide, for the help. Dale :-) :-)
Re: [gentoo-user] Re: trying to upgrade some old, never upgraded image for an embedded system …
I've created a bug report out of this. Stage3-files shall be upgraded at least every time an EAPI-Bump would have had been done. EAPI versions of stage3-files and therefore portage-tools shall match what files within the portage-tree give. If the is not the case, it will be nearly impossible to set up an upgradeable system. On Wed, Dec 18, 2019 at 7:15 PM Rich Freeman wrote: > On Wed, Dec 18, 2019 at 11:03 AM Grant Edwards > wrote: > > > > On 2019-12-18, (Nuno Silva) < > nunojsi...@ist.utl.pt> wrote: > > > > > The EAPI problem is in a package that is pulled as a dependency of > > > portage. > > > > > > Unless there's a simple hack to solve this, you will need to use older > > > ebuilds or split the update in several steps, using older versions of > > > the portage tree. The following notes show a way of achieving this: > > > > > > https://wiki.gentoo.org/wiki/User:NeddySeagoon/HOWTO_Update_Old_Gentoo > > > > In my experience of situations like this, it's often a lot less work > > to just backup /etc and user home directories and re-install from > > scratch. > > > > That wiki article seems a bit dated, though it has the right general > concept. IMO it is way simpler than that. You could of course do a > reinstall and move your /etc and /home - that will certainly be the > cleanest approach. You'll probably clear out a lot of orphans or > things that are config-protected that have moved that way (well, less > so if you keep /etc whole). > > I think some of this hinges on just HOW old that system is. What was > the date that it was last updated on? > > Assuming it isn't older than 2015 I think the simplest safe approach > is to switch to a git repo, and then update it by date. > > You can use https://anongit.gentoo.org/git/repo/sync/gentoo.git as it > has the metadata cache included, but that didn't really start until > Aug 2018. Commits before that date won't include metadata, though you > can build that yourself. It also uses CI checks so in theory every > merge commit is clean and consistent. > > You can do date-based checkouts. I'd try jumping one year at a time > updating @system or at least portage+toolchain. If one of those > updates fails you can do a shorter update interval. > > You probably don't need to update @world until you get up to the > current date. As long as @system is updated it should be able to > bootstrap everything else. > > You can't just jump to the current portage as the current portage > ebuild is going to use an EAPI that isn't supported by the version of > portage you already have. Portage is usually updated in EAPI > conservatively to minimize this issue, but if you want to jump > multiple years at a time it won't work. Jumping 6-12mo at a time will > minimize this issue. > > -- > Rich > > -- Thomas
Re: [gentoo-user] Re: trying to upgrade some old, never upgraded image for an embedded system …
So I've tried now to upgrade in various ways: 1. the one given in https://anongit.gentoo.org/git/repo/sync/gentoo.git But this fails as soon as I try to emerge git. python-exec is at version 2.4.6 now. Without any 2.0.1 packed, legal versions left. Same for all other dependencies. Not really a way to go … 2. I've tried downloading a recent stage3 file, unpack it, then go and upgrade from there. The recent stage3 file, I had to find out is, dating from 29th, September 2016, way outdated.It isn't even useful to compile anything. It will fail with any of the packages from portage as well. Upgrading portage-tree from there works, but – EAPI version mismatches make it impossible to compile anything. Since there isn't a stage3 and some portage tree matching, I'd ask: armv7 and others have gone unsupported? Just because nobody ever created a new stage3 file matching EAPI changes? On Wed, Dec 18, 2019 at 7:15 PM Rich Freeman wrote: > On Wed, Dec 18, 2019 at 11:03 AM Grant Edwards > wrote: > > > > On 2019-12-18, (Nuno Silva) < > nunojsi...@ist.utl.pt> wrote: > > > > > The EAPI problem is in a package that is pulled as a dependency of > > > portage. > > > > > > Unless there's a simple hack to solve this, you will need to use older > > > ebuilds or split the update in several steps, using older versions of > > > the portage tree. The following notes show a way of achieving this: > > > > > > https://wiki.gentoo.org/wiki/User:NeddySeagoon/HOWTO_Update_Old_Gentoo > > > > In my experience of situations like this, it's often a lot less work > > to just backup /etc and user home directories and re-install from > > scratch. > > > > That wiki article seems a bit dated, though it has the right general > concept. IMO it is way simpler than that. You could of course do a > reinstall and move your /etc and /home - that will certainly be the > cleanest approach. You'll probably clear out a lot of orphans or > things that are config-protected that have moved that way (well, less > so if you keep /etc whole). > > I think some of this hinges on just HOW old that system is. What was > the date that it was last updated on? > > Assuming it isn't older than 2015 I think the simplest safe approach > is to switch to a git repo, and then update it by date. > > You can use https://anongit.gentoo.org/git/repo/sync/gentoo.git as it > has the metadata cache included, but that didn't really start until > Aug 2018. Commits before that date won't include metadata, though you > can build that yourself. It also uses CI checks so in theory every > merge commit is clean and consistent. > > You can do date-based checkouts. I'd try jumping one year at a time > updating @system or at least portage+toolchain. If one of those > updates fails you can do a shorter update interval. > > You probably don't need to update @world until you get up to the > current date. As long as @system is updated it should be able to > bootstrap everything else. > > You can't just jump to the current portage as the current portage > ebuild is going to use an EAPI that isn't supported by the version of > portage you already have. Portage is usually updated in EAPI > conservatively to minimize this issue, but if you want to jump > multiple years at a time it won't work. Jumping 6-12mo at a time will > minimize this issue. > > -- > Rich > > -- Thomas
Re: [gentoo-user] CUPS/administration gives a blank window [RESOLVED]
On 2019-12-16 16:48, n952162 wrote: After starting apache2 and cups, when I select the add-a-printer selection item, a blank screen is displayed. Does anybody know why? Because I don't have javascript enabled ... Interestingly enough, I was able get a lot farther with w3m.
Re: [gentoo-user] Mounting USB sticks automagically.
On Thursday, 19 December 2019 11:08:30 GMT Dr Rainer Woitok wrote: > Mick, > > On Wednesday, 2019-12-18 18:10:07 +, you wrote: > > ... > > OK, are you running consolekit, or elogind? > >$ equery --no-color list -F '$mask2,$location $fullversion:$slot $cp' > consolekit elogind * Searching for consolekit ... >amd64,IP- 1.2.1:0 sys-auth/consolekit > >!!! No installed packages matching 'elogind' > * Searching for elogind ... >$ > > Sincerely, > Rainer consolekit will work for this purpose - is it running? It should be in your default runlevel. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Mounting USB sticks automagically.
Mick, On Wednesday, 2019-12-18 18:10:07 +, you wrote: > ... > OK, are you running consolekit, or elogind? $ equery --no-color list -F '$mask2,$location $fullversion:$slot $cp' consolekit elogind * Searching for consolekit ... amd64,IP- 1.2.1:0 sys-auth/consolekit !!! No installed packages matching 'elogind' * Searching for elogind ... $ Sincerely, Rainer
