Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Updating Gentoo x86 (x32), harfbuzz emits error
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
sevilla.larry
n00b
n00b


Joined: 09 Nov 2015
Posts: 30

PostPosted: Mon Jun 01, 2020 12:58 pm    Post subject: Updating Gentoo x86 (x32), harfbuzz emits error Reply with quote

I'm updating my Gentoo desktop with:

emerge --sync
emerge -juDN --with-bdeps=y @world

but "harfbuzz" emits error and updating stopped.

log file - https://pastebin.com/FnjBQ5Gk
Back to top
View user's profile Send private message
alamahant
Guru
Guru


Joined: 23 Mar 2019
Posts: 550

PostPosted: Mon Jun 01, 2020 1:18 pm    Post subject: Reply with quote

Hi

From your log:
Quote:

configure.ac:12: error: version mismatch. This is Automake 1.16.1,
configure.ac:12: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:12: comes from Automake 1.16.2. You should recreate
configure.ac:12: aclocal.m4 with aclocal and run automake again.
WARNING: 'automake-1.16' is probably too old.

You can maybe run
Code:

 emerge -1av =sys-devel/automake-1.16.1-r2

This will downgrade automake to the 1.16.1 version.
Then maybe your package will compile.
Later you can re-update your system and automake will again be upgraded to 1.16.2..
Do you have mixed stable and unstable packages in your system?
Ab by the way the more traditional way to update your system is
Code:

env-update
emerge -uDUav --keep-going --with-bdeps=y @world

Please first try to update with the above command and if you still have trouble please try downgrading automake.
:D
Back to top
View user's profile Send private message
Adarion
n00b
n00b


Joined: 22 Aug 2005
Posts: 63

PostPosted: Mon Jun 01, 2020 2:12 pm    Post subject: Reply with quote

I have a very similar problem with harfbuzz

configure.ac:12: error: version mismatch. This is Automake 1.16.1,
configure.ac:12: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:12: comes from Automake 1.16.2. You should recreate
configure.ac:12: aclocal.m4 with aclocal and run automake again.
WARNING: 'automake-1.16' is probably too old.

# eix automake
leads to
(1.16) 1.16.1-r1^t
which is currently stable (amd64).

So if automake 1.16 is too old (which is the latest stable) why does it seem that harfbuzz 2.6.5 (stable in amd64, upgrading from 2.6.4) wants an automake >1.16.1 ?
Sounds more like a bug to me.
_________________
stop tcpa, swpatents, corrupt politicians and other scary stuff
Back to top
View user's profile Send private message
flyerone
n00b
n00b


Joined: 19 Nov 2019
Posts: 34
Location: 127 0 0 1

PostPosted: Mon Jun 01, 2020 4:22 pm    Post subject: Reply with quote

The automake-1.16.2 was needed to proceed, my error was also as harbfuzz.

The request was in since 5/25th, make it happen. https://bugs.gentoo.org/725354

I use the silent way to build which is genious, 'emerge -DNuq @world'. Peace!
Back to top
View user's profile Send private message
remywang
n00b
n00b


Joined: 01 Jun 2020
Posts: 7

PostPosted: Mon Jun 01, 2020 6:11 pm    Post subject: Reply with quote

Getting the same error on a fresh install.
Back to top
View user's profile Send private message
flyerone
n00b
n00b


Joined: 19 Nov 2019
Posts: 34
Location: 127 0 0 1

PostPosted: Mon Jun 01, 2020 7:14 pm    Post subject: Reply with quote

The dependant package is waiting for an update.

If you're so willing it's possible to grab the update in advance. It might take a week or something.

Here's what to do right now (supposed you have the amd64):

ACCEPT_KEYWORDS="~amd64" emerge -1 automake
Back to top
View user's profile Send private message
remywang
n00b
n00b


Joined: 01 Jun 2020
Posts: 7

PostPosted: Mon Jun 01, 2020 8:34 pm    Post subject: Reply with quote

flyerone wrote:

Here's what to do right now (supposed you have the amd64):

ACCEPT_KEYWORDS="~amd64" emerge -1 automake

Thank you! I also needed to do `emerge harfbuzz` before emerging world again. Otherwise emerging world would downgrade automake back to 1.16.1 before installing harfbuzz.
Back to top
View user's profile Send private message
flyerone
n00b
n00b


Joined: 19 Nov 2019
Posts: 34
Location: 127 0 0 1

PostPosted: Mon Jun 01, 2020 8:49 pm    Post subject: Reply with quote

Hi, welcome. I just saw it was your first post.

In my situation it failed at the 82nd package of 210 updates.

So the harfbuzz package failed concerning the automake, waiting for an update.

Then I've rectified that automake and made a 'emerge --resume' to finish the portage updates.

My apologies if I've assumed too much Gentoo-y knowledge. With the command I've issued previously the automake package would be downgraded at a later @world upgrade. I didn't ask to keyword a single package, if that makes sense. If you have a new chroot build that would downgrade the automake but in my instance it wasn't pulled, so I was done..

If I would keyword a package I would touch a file in /etc/portage/package.accept_keywords and fill in the changes there, but for this example I've decided not to. The harfbuzz would alreade have been built and the automake would update at its leisure.

BTW I'm going to bed while it finishes, it's getting too late here in Norway.
Back to top
View user's profile Send private message
remywang
n00b
n00b


Joined: 01 Jun 2020
Posts: 7

PostPosted: Mon Jun 01, 2020 9:06 pm    Post subject: Reply with quote

That makes sense. Turns out nothing else needed automake 1.16.2, so the upgrade finished even with automake downgraded. My gentoo experience has been 10/10 so far thanks to the wonderful community :D
Back to top
View user's profile Send private message
Adarion
n00b
n00b


Joined: 22 Aug 2005
Posts: 63

PostPosted: Mon Jun 01, 2020 9:16 pm    Post subject: Reply with quote

I confirm:
=sys-devel/automake-1.16.2 worked for me with =media-libs/harfbuzz-2.6.5. :)
_________________
stop tcpa, swpatents, corrupt politicians and other scary stuff
Back to top
View user's profile Send private message
flyerone
n00b
n00b


Joined: 19 Nov 2019
Posts: 34
Location: 127 0 0 1

PostPosted: Mon Jun 01, 2020 10:25 pm    Post subject: Reply with quote

Quote:
My gentoo experience has been 10/10 so far thanks to the wonderful community


Sorry for the bumpy road. As Linus himself says, if it breaks you'd get to keep the two parts, the source and the compiler. It's good it works out. I was just trying to say, mend the part temporarily (I didn't have further use for the upgrade either but I'll guess the change is imminent).

Regards.
Back to top
View user's profile Send private message
figueroa
l33t
l33t


Joined: 14 Aug 2005
Posts: 749
Location: Lower right-hand corner USA

PostPosted: Mon Jun 01, 2020 11:58 pm    Post subject: Reply with quote

Adarion wrote:
I confirm:
=sys-devel/automake-1.16.2 worked for me with =media-libs/harfbuzz-2.6.5. :)


Ditto. That was kind of extreme. Don't package maintainers keep stable systems?
_________________
Andy Figueroa
andy@andyfigueroa.net Working with Unix since 1983.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15969

PostPosted: Tue Jun 02, 2020 2:20 am    Post subject: Reply with quote

Adarion wrote:
So if automake 1.16 is too old (which is the latest stable) why does it seem that harfbuzz 2.6.5 (stable in amd64, upgrading from 2.6.4) wants an automake >1.16.1 ?
Sounds more like a bug to me.
Specifically, media-libs/harfbuzz: broken due to messing with build system timestamps, which is already fixed.
flyerone wrote:
The request was in since 5/25th, make it happen. https://bugs.gentoo.org/725354
That is just a version bump request, and is not related to harfbuzz. It is also not necessary for this problem.
flyerone wrote:
ACCEPT_KEYWORDS="~amd64" emerge -1 automake
As discussed later in the thread, you should never do this. Keyword overrides in the environment should only be used with --pretend, because:
remywang wrote:
Thank you! I also needed to do `emerge harfbuzz` before emerging world again. Otherwise emerging world would downgrade automake back to 1.16.1 before installing harfbuzz.
Correct. If the package had been properly accepted via /etc/portage/package.accept_keywords, this would not be an issue.
figueroa wrote:
Ditto. That was kind of extreme. Don't package maintainers keep stable systems?
Package bumps for promotion to stable are supposed to be tested on a stable system, but this problem was not caused by a version bump. It was caused by an attempt to fix a different problem. The fix for media-libs/harfbuzz-2.6.5: tests/macos.tests fails incorrectly and unnecessarily triggered automake to want to rebuild the generated files. If not for that attempted rebuild, the presence of an older automake would have been fine.
Back to top
View user's profile Send private message
figueroa
l33t
l33t


Joined: 14 Aug 2005
Posts: 749
Location: Lower right-hand corner USA

PostPosted: Tue Jun 02, 2020 4:26 am    Post subject: Reply with quote

Success in the end. I needed this update to fully complete the transition from Python 3.6 to 3.7 on my last local x86 machine. Since that machine spends it's life as a server, I could (and maybe should) have just unmerged the gui apps that caused harfbuzz and icu to be dependencies in the firs place, but I consider that server my emergency backup desktop machine, just in case. And, it's a sentimental thing. It used to be my main desktop PC.

I know that's silly, and I could have re-installed those gui apps in just a few hours if it had been necessary. On the other hand, I learned some new tricks thanks to the community in these forums.

Don't do as I did, do as I should have done.
_________________
Andy Figueroa
andy@andyfigueroa.net Working with Unix since 1983.
Back to top
View user's profile Send private message
sevilla.larry
n00b
n00b


Joined: 09 Nov 2015
Posts: 30

PostPosted: Tue Jun 02, 2020 7:03 am    Post subject: Reply with quote

harfbuzz seems fixed...

thx to all responses.

I got some insights.
Back to top
View user's profile Send private message
flyerone
n00b
n00b


Joined: 19 Nov 2019
Posts: 34
Location: 127 0 0 1

PostPosted: Tue Jun 02, 2020 10:10 am    Post subject: Reply with quote

hu,

if harfbuzz wasn't the correct problem, how would one proceed the emerge world for this instance?

The cheeky fix worked for the particular problem and I've tried to convey that in the solution. That it fails at an automake is odd to me, that's really not the setup.

I was curious as to the correct fix when harfbuzz failed, what was it? I was tempted to go with --resume --skipfirst but packages sees it as a dependency.

I have a low post count but when I've started with Linux pre release on HD floppies I've bought myself, the 386 was fresh off the shelves (32 bits was a faint dream that drove the reacher up da wall). We could only look at Linux when the teacher was away..

Came back to Slackware to compile my own 3dfx driver (Windows didn't want any files changed). I've bought a boxed set of Red Hat in order to set up Flightgear, then Gentoo. :)

Regards.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15969

PostPosted: Wed Jun 03, 2020 1:34 am    Post subject: Reply with quote

flyerone wrote:
if harfbuzz wasn't the correct problem, how would one proceed the emerge world for this instance?
The bug report requesting stabilization of automake was not the correct problem. It would work, but there was a simpler and less invasive fix, which is what the maintainer did instead: change the harfbuzz ebuild not to provoke the attempt to re-run automake.
flyerone wrote:
The cheeky fix worked for the particular problem and I've tried to convey that in the solution. That it fails at an automake is odd to me, that's really not the setup.

I was curious as to the correct fix when harfbuzz failed, what was it? I was tempted to go with --resume --skipfirst but packages sees it as a dependency.
Installing a newer automake is a valid solution, although in the general case updating to an unstable package may cause more problems than it solves. That seems unlikely here, but should be a consideration when facing this type of problem. My critique here is that you should not use an environmental override to install an unstable package, because the override is not remembered and because the override applies to any dependent packages that Portage tries to install to satisfy your request. As the requester discovered, that lack of memory caused Portage to try to downgrade automake again. If the unstable package had been unlocked via /etc/portage/package.accept_keywords, then the override would be remembered and Portage would not try to downgrade automake.
Back to top
View user's profile Send private message
flyerone
n00b
n00b


Joined: 19 Nov 2019
Posts: 34
Location: 127 0 0 1

PostPosted: Wed Jun 03, 2020 12:02 pm    Post subject: Reply with quote

I've pulled the update. Brilliantly, it was another update later on June 1th.

At 18:16 hours:

Code:
   sed -i \
      -e 's:tests/macos.tests::' \
      test/shaping/data/in-house/Makefile.sources || die # bug 726120


at 23:47 hours the source changes:

Code:
   sed -i \
      -e 's:tests/macos.tests::' \
      test/shaping/data/in-house/Makefile.sources \
      test/shaping/data/in-house/Makefile.in || die # bug 726120


... hence the confusion. I've used to update each 14th day or so and I didn't see the change the same day.

The xfce4 didn't want to start and I've wiped all the settings so I had fun setting up. It was also late and I was well fed as the 1st is a holiday here. That's another story and no excuse, the update ground to a halt on package 81 of 210 so I took an easy way out. Hey it worked.

Regards.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum