Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#25011 closed defect (fixed)

Better fix to "GCC is installed multiple times"

Reported by: embray Owned by: embray
Priority: major Milestone: sage-8.4
Component: build Keywords:
Cc: fbissey, vbraun Merged in:
Authors: Erik Bray Reviewers: Julian Rüth, Dima Pasechnik
Report Upstream: N/A Work issues:
Branch: dc56a6c (Commits, GitHub, GitLab) Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by embray)

#24907 added some code to configure.ac that may remove files from $SAGE_LOCAL when running ./configure. This is at best a bit sketchy. Instead it should modify something in the Makefile--e.g. enable some rule to clean up GCC. I haven't fully considered the details yet. Ideally a fix to this would also not conflict too much with #24919.

Configure tarball: https://trac.sagemath.org/attachment/ticket/25011/configure-280.tar.gz

Attachments (2)

configure-273.tar.gz (96.8 KB) - added by embray 3 years ago.
configure-280.tar.gz (96.8 KB) - added by embray 3 years ago.

Download all attachments as: .zip

Change History (70)

comment:1 Changed 4 years ago by jdemeyer

I fully agree that #24907 is ugly by the way :-)

comment:2 Changed 4 years ago by embray

Yep--I don't mind either--I understand it was needed as a quick fix. I just wish I'd had like 1 hour to give it a look and try something else, but it's fine to fix it later.

comment:3 Changed 4 years ago by embray

  • Milestone changed from sage-8.2 to sage-8.3
  • Owner changed from (none) to embray

comment:4 Changed 4 years ago by embray

  • Authors set to Erik Bray
  • Branch set to u/embray/build/ticket-25011
  • Commit set to 829f199c2a54e18f97774ec5df8ee15522e4153c
  • Status changed from new to needs_review

Here's one possible approach to this. I admit it's still kind of ugly. But it fulfills the following (arguable) requirements that I set for the solution:

  1. A broken "sage-gcc" (will use this to refer explicitly to a GCC provided by Sage's gcc SPKG) is detected by configure, which should indicate this state somehow.
  2. If there is a broken sage-gcc it should be cleaned up by make before building any new spkgs.
  3. Once the broken sage-gcc is cleaned up, obviously no further attempt should be made by make to remove sage-gcc (once we rebuild the gcc SPKG we'll want to at least assume that it is no longer broken).
  4. Subsequent calls to configure or just config.status should still double-check that we have a working sage-gcc, and if not re-indicate that to make.

This is accomplished by having configure spit out a little stamp file to build/make/.clean-broken-gcc if a broken sage-gcc is detected. A special target is added to the Makefile _clean-broken-gcc which checks for that stamp file and, if it exists, cleans up the broken sage-gcc and removes the stamp file (the cleanup having been completed). This target is then added as a prerequisite to building all SPKGs.


New commits:

2f97ecfshould still set need_to_install_gcc=yes in configure if Sage's gcc is already installed
f7cb9cebuild/make/Makefile should be rebuild with build/make/Makefile.in is updated
14b6f4dReduce some unnecessary text duplication in the Makefile.
83b9004Clean up a broken GCC in SAGE_LOCAL if it exists.
829f199Ensure that the gcc SPKG always checks for and cleans up a broken gcc if it exists

comment:5 Changed 3 years ago by git

  • Commit changed from 829f199c2a54e18f97774ec5df8ee15522e4153c to d4d7f6de2fdbe3b248424ea3dcec44b249030dc4

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

74173ecshould still set need_to_install_gcc=yes in configure if Sage's gcc is already installed
2e31f57build/make/Makefile should be rebuild with build/make/Makefile.in is updated
755bc58Reduce some unnecessary text duplication in the Makefile.
dd19cc9Clean up a broken GCC in SAGE_LOCAL if it exists.
d4d7f6dEnsure that the gcc SPKG always checks for and cleans up a broken gcc if it exists

comment:6 Changed 3 years ago by embray

Although not explicitly needed, I've rebased this on 8.3.rc0, so that I can also rebase #24919

comment:7 follow-up: Changed 3 years ago by saraedum

  • Reviewers set to Julian Rüth

I find this somewhat confusing and I wonder whether we really need all this special logic for this case (I don't know about the history of this, so I might have the wrong perspective…)

Here are a few questions:

  • Do I understand correctly that we only test GCC if we provided it? Why don't we always test?
  • Do we need the "uninstall" logic? Can't we just tell people that their GCC is broken and they should reinstall Sage, i.e., how frequent is this issue?

comment:8 Changed 3 years ago by saraedum

  • Status changed from needs_review to needs_info

comment:9 in reply to: ↑ 7 Changed 3 years ago by embray

Replying to saraedum:

I find this somewhat confusing and I wonder whether we really need all this special logic for this case (I don't know about the history of this, so I might have the wrong perspective…)

I don't exactly remember all the history myself. But whatever the case, the central issue is that if you install Sage's GCC package (I call it "sage-gcc"), and then somehow or other that gcc is broken (don't ask me how, but apparently it has happened due to past bugs), then you basically can't build any package for Sage anymore because it will try by default to use sage-gcc (since Sage-the-distribution mixes its build environment with its runtime target), and there's no way to force it not to. So sage-gcc is installed but broken it's necessary as soon as possible to remove it.

The immediate background to this ticket, then, is that in #24907 Jeroen added a workaround which "fixes" it by rm -rfing files from sage-gcc if it exists, and is broken. The problem is that this is done by the ./configure script itself, which really ought not to be writing things to $SAGE_LOCAL at all.

This fix then just uses ./configure to test whether sage-gcc exists and is broken, and adds a special make target to clean it up immediately before trying to build anything else. Therefore the existing Sage environment can still keep working, and sage-gcc can even be reinstalled if desired.

Here are a few questions:

  • Do I understand correctly that we only test GCC if we provided it? Why don't we always test?

No, if you look later in the configure.ac there are several compiler-related checks, mostly using standard autoconf macros; however if you have a broken sage-gcc those will fail and the end result is Sage deciding that you need to install sage-gcc even though it's already installed (but broken). This leads to basically an infinite loop of Sage trying to reinstall sage-gcc.

Therefore it's necessary to have an explicit test for this case early on and make note of it.

  • Do we need the "uninstall" logic? Can't we just tell people that their GCC is broken and they should reinstall Sage, i.e., how frequent is this issue?

A few things about this:

  1. I resent that we ship our own GCC at all. I would just as soon not, but enough people think that's important enough that we need to bend over backwards to support it and I don't care to fight that (just make it work a little better I hope, but that's a separate issue).
  1. Personally I would be fine with just saying "do a make dist-clean and try again". But that does kind of suck because for some people building from scratch does take a very long time, and having a broken sage-gcc doesn't necessarily invalidate all the rest of the build.
  1. The uninstall process itself (all the rm -rf's will be improved soon as we have DESTDIR support for sage-gcc. Then we can replace that with just sage-spkg-uninstall gcc and it will be much cleaner overall.
  1. I'd also prefer if ./configure just reported "you have sage-gcc but it's broken; please uninstall it". But for automated builds and stuff like that it is kind of useful to have an automated cleanup.

comment:10 Changed 3 years ago by embray

  • Status changed from needs_info to needs_review

comment:11 Changed 3 years ago by git

  • Commit changed from d4d7f6de2fdbe3b248424ea3dcec44b249030dc4 to 42153c1f7ff4e89b981e14e81211b4a732bfb24f

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

9346272should still set need_to_install_gcc=yes in configure if Sage's gcc is already installed
363bc17build/make/Makefile should be rebuilt when build/make/Makefile.in is updated
d8991c0Reduce some unnecessary text duplication in the Makefile.
d3beac8Clean up a broken GCC in SAGE_LOCAL if it exists.
42153c1Ensure that the gcc SPKG always checks for and cleans up a broken gcc if it exists

comment:12 Changed 3 years ago by embray

(the above was just rebasing on 8.3.rc1 and fixing some typos in a commit message)

comment:13 Changed 3 years ago by embray

Ack, I see why I'm getting mixed up. I keep confusing this ticket with #25188; I seem to be having a serious dyslexic moment right now.

Last edited 3 years ago by embray (previous) (diff)

comment:14 Changed 3 years ago by git

  • Commit changed from 42153c1f7ff4e89b981e14e81211b4a732bfb24f to 52ef4c9cdd74390ecfb6b0c8d455c597f4612410

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

1153d73Reduce some unnecessary text duplication in the Makefile.
1a6f7e5Clean up a broken GCC in SAGE_LOCAL if it exists.
52ef4c9Ensure that the gcc SPKG always checks for and cleans up a broken gcc if it exists

comment:15 Changed 3 years ago by embray

  • Milestone changed from sage-8.3 to sage-8.4

I believe this issue can reasonably be addressed for Sage 8.4.

comment:16 Changed 3 years ago by embray

  • Status changed from needs_review to needs_work

Something about this still isn't right. Adding the _clean-broken-gcc phony target to gcc's dependencies forces make gcc to run even when it shouldn't. I don't think that's how I intended _clean-broken-gcc to be used when I first started working on this issue, so I must have been out of my mind when I did that.

comment:17 Changed 3 years ago by git

  • Commit changed from 52ef4c9cdd74390ecfb6b0c8d455c597f4612410 to 68990b96af2268ab2c9015741868a840bd69dd47

Branch pushed to git repo; I updated commit sha1. New commits:

1eb1f33fix a typo with wildcards and add some gcc-* executables to be removed
68990b9rather than try to make _clean-broken-gcc explicitly a prerequisite of spkg targets

comment:18 Changed 3 years ago by embray

  • Status changed from needs_work to needs_review

I think this does the "right" thing now, so far as any of this is reasonable...

comment:19 Changed 3 years ago by embray

One thing to understand about the gcc spkg which I keep forgetting, but is important to how this works, is that at the end of its spkg-install script it runs touch $SAGE_ROOT/configure. This means before any other package is built, it is forced to re-run ./configure.

When sage-gcc is installed it adds $(SAGE_LOCAL)/bin/gcc as a prerequisite to every spkg when build/make/Makefile is generated. Since sage-gcc was forced to be reinstalled, this means bin/gcc will be newer than any other packages' stamp files, so they are forced to be rebuilt as well (this behavior was implemented partly in #24703).

comment:20 follow-up: Changed 3 years ago by dimpase

The fact that we ship gcc is largely due to the need to provide gfortran (or some other modern fortran) on OSX.

Perhaps we should separate Sage from Sage's build toolchain, this would be a step towards despahgettifying this a bit.

comment:21 Changed 3 years ago by dimpase

  • Reviewers changed from Julian Rüth to Julian Rüth, Dima Pasechnik

looks good to me.

comment:22 Changed 3 years ago by dimpase

  • Status changed from needs_review to positive_review

comment:23 in reply to: ↑ 20 Changed 3 years ago by embray

Replying to dimpase:

The fact that we ship gcc is largely due to the need to provide gfortran (or some other modern fortran) on OSX.

Perhaps we should separate Sage from Sage's build toolchain, this would be a step towards despahgettifying this a bit.

I am 100% in favor of that and have a plan in mind for doing so. But it's yet another herculean task that I'm not prepared to take on until I've made more progress on a few others (though it would certainly make some things I'm trying to do easier--maybe I shouldn't gone with my first instinct of pushing more for that in the first place).

comment:24 follow-up: Changed 3 years ago by vbraun

  • Status changed from positive_review to needs_work

If autotools are not installed:

make[1]: warning: -jN forced in submake: disabling jobserver mode.
make[1]: Entering directory '/home/buildbot/slave/sage_git/build/build/make'
make[1]: *** No rule to make target '@SAGE_GCC_DEP@', needed by '/home/buildbot/slave/sage_git/build/local/var/lib/sage/installed/patch-2.7.5'.
make[1]: Target 'base-toolchain' not remade because of errors.
make[1]: Leaving directory '/home/buildbot/slave/sage_git/build/build/make'

comment:25 in reply to: ↑ 24 Changed 3 years ago by dimpase

  • Status changed from needs_work to positive_review

Replying to vbraun:

If autotools are not installed:

make[1]: warning: -jN forced in submake: disabling jobserver mode.
make[1]: Entering directory '/home/buildbot/slave/sage_git/build/build/make'
make[1]: *** No rule to make target '@SAGE_GCC_DEP@', needed by '/home/buildbot/slave/sage_git/build/local/var/lib/sage/installed/patch-2.7.5'.
make[1]: Target 'base-toolchain' not remade because of errors.
make[1]: Leaving directory '/home/buildbot/slave/sage_git/build/build/make'

This must be a buildbot setup bug, at least I cannot reproduce it. Probably the bot has a stale ./configure (as ./configure is no longer under git, the bot needs to get it somehow, autotools or not).

comment:26 Changed 3 years ago by dimpase

Or it might be I don't understand the workflow for tickets involving modifications to ./configure.

comment:27 Changed 3 years ago by embray

I agree with Dima. Obviously you can't apply this change requires rebuilding the configure script. How do you normally handle tickets that modify configure? In this case both configure.ac and one of the m4/ macros were updated.

comment:28 Changed 3 years ago by embray

It would be good to have answers on this because I have made changes in the past that modified configure, and have many more coming down the pipeline....

comment:29 follow-ups: Changed 3 years ago by dimpase

  • Cc fbissey added

OK, it's came back from my brain swap: e.g. on #12426 one was creating configure-XYZ.tar.gz to be placed in SAGE_ROOT/upstream, containing

configure
config/compile
config/config.guess
config/config.sub
config/install-sh
config/missing
build/make/Makefile-auto.in

with XYZ doing a version bump. I don't know how it was done - perhaps just tar? fbissey should know. IMHO it's a hassle, and ought to be handled by build/patch-bots.

comment:30 in reply to: ↑ 29 Changed 3 years ago by embray

Replying to dimpase:

IMHO it's a hassle, and ought to be handled by build/patch-bots.

I think normally it is. Because the first time I updated configure.ac I also provided a configure tarball (there is actually a script that makes it--you can build it by running ./bootstrap -s).

But somebody (I think either Volker or Jeroen) told me it wasn't necessary, and I haven't needed to bother since, even with tickets that changed much more than this one. So I'm at a loss.

comment:31 in reply to: ↑ 29 Changed 3 years ago by fbissey

Replying to dimpase:

OK, it's came back from my brain swap: e.g. on #12426 one was creating configure-XYZ.tar.gz to be placed in SAGE_ROOT/upstream, containing

configure
config/compile
config/config.guess
config/config.sub
config/install-sh
config/missing
build/make/Makefile-auto.in

with XYZ doing a version bump. I don't know how it was done - perhaps just tar? fbissey should know. IMHO it's a hassle, and ought to be handled by build/patch-bots.

For info, it is produced by a switch of the bootstrap script (-s) that you use to regenerate configure.

comment:32 Changed 3 years ago by embray

I wrote that just above :)

I'll go ahead and do that, but in the past I haven't had to...

comment:33 Changed 3 years ago by embray

  • Cc vbraun added

So, what are we supposed to do about this?

comment:34 follow-up: Changed 3 years ago by vbraun

  • Status changed from positive_review to needs_work

create new confball and add link to ticket

comment:35 Changed 3 years ago by embray

Weird that I never had to do that before. Does that mean some of my configure.ac changes weren't being tested?

comment:36 follow-up: Changed 3 years ago by dimpase

I don't see why the buildbot master cannot run ./bootstrap before going further:

http://docs.buildbot.net/0.8.3/Running-Commands-on-the-Master.html

comment:37 in reply to: ↑ 36 ; follow-up: Changed 3 years ago by embray

Replying to dimpase:

I don't see why the buildbot master cannot run ./bootstrap before going further:

http://docs.buildbot.net/0.8.3/Running-Commands-on-the-Master.html

It does implicitly--the top-level Makefile re-runs ./bootstrap if configure needs to be rebuilt (i.e. configure.ac or any of the m4/ files changed).

However, Volker is pointing out that this does not work for systems that don't have autoconf installed, such that running ./bootstrap fails.

Perhaps it's new that there's a buildbot build where that is the case? I don't remember having any problem with this before. Obviously on a system with no autoconf it's not going to work unless they can download a new configure tarball.

comment:38 in reply to: ↑ 34 ; follow-up: Changed 3 years ago by embray

Replying to vbraun:

create new confball and add link to ticket

Does that mean I have to do that for every ticket that modifies configure? Because I have several like that.

comment:39 in reply to: ↑ 38 Changed 3 years ago by jdemeyer

Replying to embray:

Does that mean I have to do that for every ticket that modifies configure? Because I have several like that.

Only if configure.ac is modified in an incompatible way. Sometimes you can get away with using an old version of configure.

Yes, it's annoying and it should be fixed by changing the release manager workflow.

comment:40 in reply to: ↑ 37 Changed 3 years ago by dimpase

Replying to embray:

Replying to dimpase:

I don't see why the buildbot master cannot run ./bootstrap before going further:

http://docs.buildbot.net/0.8.3/Running-Commands-on-the-Master.html

It does implicitly--the top-level Makefile re-runs ./bootstrap if configure needs to be rebuilt (i.e. configure.ac or any of the m4/ files changed).

However, Volker is pointing out that this does not work for systems that don't have autoconf installed, such that running ./bootstrap fails.

Perhaps it's new that there's a buildbot build where that is the case? I don't remember having any problem with this before. Obviously on a system with no autoconf it's not going to work unless they can download a new configure tarball.

IMHO, buildbot is master-slave, and building happens on slaves, which get jobs from the master. I am saying that master should run ./bootstrap and send it over to slaves.

comment:41 follow-ups: Changed 3 years ago by embray

Unfortunately that's not really how buildbot works. In any case there's no reason the workers can't have autotools installed. My guess is just that there is deliberately one that does not, in order to catch cases where a new configure tarball must be built. I don't think that makes a lot of sense--I think the configure script should just be built automatically every time a release is made and included in the source tarball like most projects do :shrug:

comment:42 in reply to: ↑ 41 Changed 3 years ago by fbissey

Replying to embray:

Unfortunately that's not really how buildbot works. In any case there's no reason the workers can't have autotools installed. My guess is just that there is deliberately one that does not, in order to catch cases where a new configure tarball must be built. I don't think that makes a lot of sense--I think the configure script should just be built automatically every time a release is made and included in the source tarball like most projects do :shrug:

Well I can think of one. Many people don't have autotools installed. Having autotools installed will mask the fact that a package forgot to run it after a change. It may then fail on a end user machine where autotools is not present and the maintainer mode kicks in and trigger a re-run.

comment:43 follow-up: Changed 3 years ago by dimpase

it is clear that Sage installation should not need autotools. What is unclear to me is why the release building process must run without autotools, and need a manually built configure tarball, something that is not only inconvenient, but error prone as well.

by right, package configure must be updated, version bumped, as

https://github.com/sagemath/sage/blob/master/build/pkgs/configure/checksums.ini

should not be ignored. Perhaps all this may be done by trac, automatically, for the lack of better place?

Last edited 3 years ago by dimpase (previous) (diff)

comment:44 in reply to: ↑ 43 Changed 3 years ago by embray

Replying to dimpase:

it is clear that Sage installation should not need autotools. What is unclear to me is why the release building process must run without autotools, and need a manually built configure tarball, something that is not only inconvenient, but error prone as well.

Exactly. There's no reason (at least not obvious) the release process shouldn't just do this automatically, including for "beta" releases, so I don't see why this is being held up by a buildbot that can't build properly.

The fact that I've made past changes to configure but where it "happened" to keep working on those buildbots is a further argument that it's not useful to have in the first place.

It's not that I mind generating and uploading a new configure tarball. That's easy. Of course as I have multiple tickets open that modify configure, and as I have no way to "guess" which ones will or will not "happen" to work without an updated configure tarball, that just means I now have to generate configure tarballs for all of them, which is necessarily going to lead to merge conflicts, and slower acceptance of these tickets (each one is going to have a different new configure tarball go along with it).

Last edited 3 years ago by embray (previous) (diff)

comment:45 follow-up: Changed 3 years ago by vbraun

For the record, the release script generates a new confball for every beta/rc release but not for every merged ticket. Doing it for every ticket has issues with size (every confball is 100k on the mirrors) and, more importantly, would make it more difficult for me to unmerge tickets because the version would always conflict.

An automatted solution would at the very least need to detect when a new confball is needed. E.g. extend ./bootstrap to have a maybe-save option that only saves a new confball if there was a relevant change over the current confball. And use non-consecutive version numbers. Perhaps just use a hash of the content (excluding file timestamps) as version number. Then I could run that with every ticket.

comment:46 in reply to: ↑ 41 ; follow-up: Changed 3 years ago by jdemeyer

Replying to embray:

I think the configure script should just be built automatically every time a release is made and included in the source tarball like most projects do

...and Sage also does this.

However, the buildbots don't build from a release, they build from the git repo. So this is purely a buildbot workflow issue, not a Sage release issue.

comment:47 in reply to: ↑ 45 Changed 3 years ago by jdemeyer

What I (more precisely, my scripts) did when I was release manager: create a fake source release every time you want to test Sage on the buildbot and then build from that fake source release on the buildbots instead of from git.

comment:48 follow-up: Changed 3 years ago by vbraun

I definitely want to leverage git on the buildbots though. Things are much easier to debug if you can easily switch between versions. E.g. if I find a problem that specific to a buildbot I can just log in and compare with the last known-good version, back out tickets, etc.

comment:49 in reply to: ↑ 46 ; follow-up: Changed 3 years ago by embray

Replying to jdemeyer:

Replying to embray:

I think the configure script should just be built automatically every time a release is made and included in the source tarball like most projects do

...and Sage also does this.

However, the buildbots don't build from a release, they build from the git repo. So this is purely a buildbot workflow issue, not a Sage release issue.

I still don't understand. The top-level Makefile ensures that configure is up-to-date by running ./bootstrap.

Why is there even a buildbot that tries to build without autoconf? If the configure tarball is updated when there is a release anyways, what use is this, especially if it produces false negatives?

comment:50 Changed 3 years ago by embray

  • Status changed from needs_work to needs_info

comment:51 Changed 3 years ago by embray

This really ought to be resolved sensibly. You want me to create a configure tarball and upload it, which I'm happy to do. But there are going to be more of them, and likely with conflicting versions, etc--all the problems you described. This shouldn't be needed to get a ticket merged.

comment:52 in reply to: ↑ 49 Changed 3 years ago by jdemeyer

Replying to embray:

Why is there even a buildbot that tries to build without autoconf?

This is a good idea actually. It ensures that Sage can be built on systems without autotools. Otherwise, you might mistakenly add a dependency on autotools and you would only notice that once somebody tries to build Sage on a system without autotools.

comment:53 follow-up: Changed 3 years ago by embray

Okay, I still think it's a bit strange not to just require that as a build dependency but let's say there's a valid reason for that: Such a buildbot should be ignored then for tickets like this one that by requirement need autoconf to make any sense to build.

comment:54 Changed 3 years ago by git

  • Commit changed from 68990b96af2268ab2c9015741868a840bd69dd47 to 92fb34a66068bd4f1651412102c372e8c883754c

Branch pushed to git repo; I updated commit sha1. New commits:

92fb34anew configure tarball I guess

comment:55 in reply to: ↑ 53 Changed 3 years ago by jdemeyer

Replying to embray:

Such a buildbot should be ignored then for tickets like this one

The buildbot doesn't test tickets, it tests releases (before they are releases).

Changed 3 years ago by embray

comment:56 Changed 3 years ago by embray

Yes, I understand that. And releases should just include the built configure script in the first place IMO.

comment:57 Changed 3 years ago by embray

I mean, it's not testing releases if it's building from the git repo.

comment:58 Changed 3 years ago by embray

  • Status changed from needs_info to positive_review

comment:59 Changed 3 years ago by embray

I'll just keep doing this. I don't mind doing it and resolving the conflicts that inevitably emerge. I just wish someone had said it was necessary in the first place. I explicitly recall being told at one point that it wasn't.

comment:60 Changed 3 years ago by embray

  • Description modified (diff)

comment:61 in reply to: ↑ 48 Changed 3 years ago by embray

Replying to vbraun:

I definitely want to leverage git on the buildbots though. Things are much easier to debug if you can easily switch between versions. E.g. if I find a problem that specific to a buildbot I can just log in and compare with the last known-good version, back out tickets, etc.

Use git--make a release from git--build from the release. Otherwise you're not actually testing releasing or building from a release.

comment:62 Changed 3 years ago by vbraun

  • Status changed from positive_review to needs_work

merge conflict

comment:63 Changed 3 years ago by embray

Specifically with build/pkgs/configure/checksums.ini what a surprise. Does this mean I need to rebuild the configure tarball too?

comment:64 Changed 3 years ago by embray

It's really frustrating to do by the way, because apparently my "config.guess" is too old, but when I download a recent one from upstream and place it in config/ it just gets deleted again when I run ./bootstrap. So I have to manually edit ./bootstrap to not do that in order to build the tarball. Can't the release manager just do that?

comment:65 Changed 3 years ago by git

  • Commit changed from 92fb34a66068bd4f1651412102c372e8c883754c to dc56a6cb78c99ce633118748a4aeeab13e445530

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

4e28d39Reduce some unnecessary text duplication in the Makefile.
458399bClean up a broken GCC in SAGE_LOCAL if it exists.
183f937Ensure that the gcc SPKG always checks for and cleans up a broken gcc if it exists
b32c73afix a typo with wildcards and add some gcc-* executables to be removed
eb96c97rather than try to make _clean-broken-gcc explicitly a prerequisite of spkg targets
dc56a6cnew configure tarball I guess

Changed 3 years ago by embray

comment:66 Changed 3 years ago by embray

  • Description modified (diff)
  • Status changed from needs_work to positive_review

Added a new one. I think it's actually identical to the previous one, for some reason, despite the merge conflict. But it has to have a new version number.

comment:67 Changed 3 years ago by vbraun

  • Branch changed from u/embray/build/ticket-25011 to dc56a6cb78c99ce633118748a4aeeab13e445530
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:68 Changed 3 years ago by embray

  • Commit dc56a6cb78c99ce633118748a4aeeab13e445530 deleted

Thanks! On to the next one...

Note: See TracTickets for help on using tickets.