After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 638188 - Tarball version updates do not propagate to all build slaves
Tarball version updates do not propagate to all build slaves
Status: RESOLVED OBSOLETE
Product: jhbuild
Classification: Infrastructure
Component: general
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: Jhbuild maintainers
Jhbuild QA
Depends on:
Blocks:
 
 
Reported: 2010-12-28 14:39 UTC by Cosimo Cecchi
Modified: 2021-05-17 15:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Cosimo Cecchi 2010-12-28 14:39:45 UTC
It seems that when a module built from tarball changes its version in the moduleset, that change is not correctly propagated automatically to all the build slaves.
This happened for instance with the WebKit bump from 1.3.7 to 1.3.9, which did not get automatically picked up by my build slave (neither by Matthias' AFAICS), see [1].
Manually wiping the relevant checkout/tarball without restarting the build slave is not enough; however the change is picked up if the slave is restarted.

[1] http://mail.gnome.org/archives/build-brigade-list/2010-December/msg00042.html
Comment 1 Frederic Peters 2010-12-28 17:08:37 UTC
Do you have your buildslave set to use local modulesets? If that's the case you need to get updates in another manner (I have a cronjob for this on my slave)
Comment 2 Cosimo Cecchi 2010-12-29 10:29:38 UTC
(In reply to comment #1)
> Do you have your buildslave set to use local modulesets?

Is this something that is enabled by default in the slave configuration or does it need to be turned on using .jhbuildrc? If the latter, then I guess I don't, as my .jhbuildrc is:

moduleset = 'gnome-suites-core-3.0'
modules = [ 'meta-gnome-core' ]
checkoutroot = os.path.expanduser('~/buildbot/Checkouts')
prefix = os.path.expanduser('~/buildbot/Install')
makeargs = 'V=1'
jhbuildbot_master = 'build.gnome.org:9070'
jhbuildbot_slavename = 'cosimoc-deb-i686'
Comment 3 Craig Keogh 2011-02-22 11:40:56 UTC
(In reply to comment #0)
> however the change is picked up if the slave is restarted.

I'm not sure, but I think JHBuild doesn't pick up changes to modulesets whilst JHBuild is running. I don't know how the build slaves work, but if there is only one JHBuild session running continuously, I see how the bug occurs. Then the solution would be 'JHBuild should pickup moduleset changes on-the-fly'. Any one able to confirm or deny?
Comment 4 Frederic Peters 2011-02-22 11:47:43 UTC
jhbuild is executed at all steps; so this is not it. (cf jhbuild/buildbot/steps.py)
Comment 5 Craig Keogh 2011-03-08 11:10:43 UTC
Where you write 'WebKit bump from 1.3.7 to 1.3.9, which did not get automatically picked up' was JHBuild building the old 1.3.7 or was JHBuild not building WebKit at all because JHBuild determined (incorrectly) it wasn't necessary?

JHBuild's default build_policy is 'updated-deps'. Is the bug the updated-deps to-build list is incorrect when a dependency is bumped?

Sorry for the questions, I've having trouble tracking this down.
Comment 6 Cosimo Cecchi 2011-03-08 15:14:09 UTC
(In reply to comment #5)
> Where you write 'WebKit bump from 1.3.7 to 1.3.9, which did not get
> automatically picked up' was JHBuild building the old 1.3.7 or was JHBuild not
> building WebKit at all because JHBuild determined (incorrectly) it wasn't
> necessary?
> 
> JHBuild's default build_policy is 'updated-deps'. Is the bug the updated-deps
> to-build list is incorrect when a dependency is bumped?
> 
> Sorry for the questions, I've having trouble tracking this down.

Yeah, the new tarball did not get downloaded at all, and JHBuild kept building the old one instead.
Comment 7 Craig Keogh 2011-04-03 10:46:17 UTC
Ok, I have another idea. When this bug happens, what is the version number:
1. ~/checkout/gnome/jhbuild/modulesets/gnome-suites-core-deps-3.0.modules
2. http://git.gnome.org/browse/jhbuild/plain/modulesets/gnome-suites-core-deps-3.0.modules
3. ~/.cache/jhbuild/gnome-suites-core-deps-3.0.modules and
4. JHBuild attempts to build?

(adjust paths as necessary for your setup)

Thank you
Comment 8 Tobias Mueller 2011-08-01 08:58:52 UTC
Cosimo, can you answer the questions raised in comment #7?
Comment 9 Cosimo Cecchi 2011-08-01 09:17:11 UTC
Craig: using the recently updated p11-kit tarball as an example, the local checkout of jhbuild, updated to git master, says:

tarball id="p11-kit" version="0.3"

which is the same of upstream git.

The copy in ~/.cache/jhbuild is using 0.2 instead

tarball id="p11-kit" version="0.2"

and the buildbot is trying to build 0.2.

Note that I didn't manually install the latest git master of jhbuild or restart the slave after the module has been updated to 0.3 (which is exactly what I would like to avoid with this bug ;))
Comment 10 Craig Keogh 2011-08-25 12:11:49 UTC
I've committed a patch [1] to close files in httpcache. As Frédéric said in comment 4 a new JHBuild is started so the files were probably auto closed. This is unlikely to fix the issue.

The default cache expiry is 6 hours. Has it been 6 hours since the on-line modules file was updated to when your build started?

If yes, then maybe:
- If-Modified-Since and If-None-Match headers are wrong from the GNOME server.
- Expires header from the server is wrong.

But that doesn't explain why it works for normal JHBuild users and not for buildbot.

[1] http://git.gnome.org/browse/jhbuild/commit/?id=3c0b66aebce41960856963016e3aa43a90d3045d
Comment 11 GNOME Infrastructure Team 2021-05-17 15:50:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/jhbuild/-/issues/110.