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] 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] Re: trying to upgrade some old, never upgraded image for an embedded system …
On Wed, Dec 18, 2019 at 11:03 AM Grant Edwards wrote: > > On 2019-12-18, (Nuno Silva) > 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
