| *** toscalix has joined #baserock | 05:24 | |
| *** toscalix has quit IRC | 05:39 | |
| jjardon_matrix | Yeah, " they eat their own food" | 05:53 |
|---|---|---|
| *** gtristan has joined #baserock | 06:34 | |
| *** ctbruce has joined #baserock | 07:25 | |
| jjardon | Hi, any idea why deployment start failing? https://gitlab.com/baserock/definitions/builds/5083556 maybe some misconfiguration in the python PATHS? the strange thing is that the build step work with no problem | 08:06 |
| gtristan | jjardon, am I to understand that the extension is being run *inside* the sandbox ? is that a new behavior ? | 08:16 |
| gtristan | A wild guess, is that yaml is not installed in the sandbox where some python code is expected to run | 08:17 |
| jjardon | Mmmm, no changes in ybd I think, but we are now running the install_dependencies script from ybd in the ci, instead install the steps manually | 08:19 |
| *** CTtpollard has joined #baserock | 08:22 | |
| *** tiagogomes has joined #baserock | 08:23 | |
| gtristan | odd indeed, clearly yaml was there to get up to that point | 08:24 |
| gtristan | jjardon, ok so it's running inside the sandbox, clearly | 08:28 |
| gtristan | jjardon, ybd deployment.py is running the install-files configure extension in a sandbox, that sandbox must then have a python environment with yaml installed for that to work | 08:28 |
| gtristan | not sure where whatever changed to cause that, but that seems to be happening | 08:29 |
| gtristan | install-files.configure imports writeexts which ends up indirectly importing yaml, and that all happens in the sandbox | 08:30 |
| gtristan | if that is really happening, which is quite seems to be, then that is quite wrong imo | 08:30 |
| gtristan | looking at the ybd/deployment.py and extensions/install-files.configure, it looks like it was this way forever | 08:33 |
| gtristan | jjardon, so indeed some pathing thing seems to be the problem, and the requirement is that: If thou useth baserock to deploy any system using extensions, thou must deployeth thine python in there as well | 08:34 |
| * gtristan believes the proper and expensive fix to end all of these problems is to never depend on a python environment in the sandbox (probably by using virtualenv) and to have extensions run outside of the sandbox as python scripts which are allowed to link to defslib and use all the same ybd tooling to do things inside the same sandbox | 08:37 | |
| tiagogomes | I am not sure what is the problem where. Why can't we run deployments the same way the build essential chunks are built? | 08:47 |
| gtristan | tiagogomes, you mean with build-mode: bootstrap ? | 08:58 |
| gtristan | those parts of build essential ? | 08:59 |
| gtristan | oh wait | 08:59 |
| gtristan | as I return, I see that I can be reading that code completely wrong sorry | 09:00 |
| *** edcragg_ has quit IRC | 09:00 | |
| gtristan | it's not sandbox.run_in_sandbox(), rather it's sandbox.run_extension() | 09:00 |
| gtristan | sandbox.run_extension() does not do any chroot | 09:02 |
| tiagogomes | I was talking about the fact that when build-mode == bootstrap, the sandbox root is '/' mounted as read-only. | 09:02 |
| *** edcragg has joined #baserock | 09:02 | |
| gtristan | well, it should not make a huge difference, but indeed it seems strange to have a separate codepath for that | 09:03 |
| gtristan | sandbox.run_extension just changes the CWD to the sandbox and runs the extension | 09:04 |
| gtristan | but it also messes with PYTHONPATH to put the extensions in the path | 09:04 |
| *** ctbruce has quit IRC | 09:04 | |
| gtristan | actually runs it in defdir ... this codepath is very confusing | 09:06 |
| *** ctbruce has joined #baserock | 09:08 | |
| SotK | iirc it runs in the definitions repo because some extensions expect to be run from there | 09:16 |
| * SotK may be totally making that up as its a long time since I worked on that code and its friday | 09:16 | |
| gtristan | SotK, most probably the install-files want that | 09:17 |
| gtristan | the extensions is quite limited and rigid in terms of what context can be passed from the builder to the extension | 09:18 |
| SotK | indeed | 09:18 |
| * SotK assumes there was some reason for the limitedness, but doesn't know what it was (if there was one) | 09:18 | |
| pedroalvarez | all my pipelines are stuck at fetching a docker container | 09:42 |
| pedroalvarez | fist attempt failed when cloning ansible | 10:02 |
| tiagogomes | I can clone it locally | 10:10 |
| tiagogomes | jjardon, is there a special reason why you are merging /usr/bin and /usr/sbin in your jjardon/usr-merge branch? | 10:11 |
| pedroalvarez | I asked about that, no answer yet ^ | 10:11 |
| tiagogomes | ostree seems to do that. But because ostree does it, it doesn't mean we should do it. | 10:12 |
| tiagogomes | Fedora, for example, keeps them separate. | 10:12 |
| tiagogomes | I am looking at the artifact dir populated by ybd, but I can't find the stage2 artifacts | 10:52 |
| paulsher1ood | tiagogomes: if it has the rest of the build-essential artifacts, it doesn't download stage1* and stage2* | 10:53 |
| pedroalvarez | how does that work? it ignores the "bootstrap" chunks? | 10:54 |
| * gtristan wonders if it makes sense to cache the stage1/stage2 artifacts on the artifact server, do they work when shared ? | 10:54 | |
| tiagogomes | ah ok. morph used to download them all I believe | 10:54 |
| tiagogomes | An Internals.md document for ybd would be mint | 10:55 |
| gtristan | pedroalvarez, I believe it's a question of dependency, the stage1/stage2 are not required to build a stratum above build-essential (as nobody asks for them to be staged -> built, nobody asks them to be downloaded) | 10:55 |
| gtristan | bootstrap happens to cause this dependency circumvention, but I dont like this; V10 will improve semantics around that | 10:55 |
| pedroalvarez | everything depends on built essential, so I assume that it works as I said, by ignoring the bootstrap flagged chunks | 10:56 |
| paulsher1ood | pedroalvarez: correct | 10:56 |
| tiagogomes | That looks a good idea to cut down download speeds, but I'd like that there was a way to download them all. | 10:57 |
| * gtristan is very skeptical that stage1 or stage2 gcc would be useful to anyone who has to use them to build the rest of build essential | 10:58 | |
| gtristan | i.e. the built gcc outside of the sandbox used to build the real gcc would be sysrooted, so if I download tiagogomes's stage1, it will look for things in /home/tiago/baserock... | 10:59 |
| paulsher1ood | the build-essential artifact contents exclude bootstrap chunks. all other artifacts depend on the build-essential artifact | 10:59 |
| pedroalvarez | gtristan: should be easy to test. Trigger a build of a chunk that depends on gcc stage2 | 11:00 |
| pedroalvarez | or on gcc stage1 | 11:00 |
| pedroalvarez | the lack of people reporting bugs about that makes me think that it works | 11:02 |
| * paulsher1ood is confident ybd's approach for this works, with or without pre-cached kbas/local artifacts | 11:03 | |
| paulsher1ood | so... folks are pushing to make ybd run with python3, and drop support for python2 | 11:04 |
| paulsher1ood | does anyone object to that? | 11:04 |
| * gtristan has not ever run a build with a working connection to the artifact server... but I can try a simple test locally | 11:04 | |
| paulsher1ood | i'm considering that if we do this, i'll tag one final release of ybd that supports python2, before the move | 11:05 |
| tiagogomes | gtristan unless the sysroot on morph was always a fixed path, but I don't think so | 11:06 |
| gtristan | I have a build-essential that works, now modify ybd.conf to put the tmp dir in a new location, and trigger a rebuild of gcc, actually it should break even without changing the config (because of tmp file staging dir path) | 11:06 |
| pedroalvarez | ERROR: Build failed: execution took longer than 3600 seconds | 11:33 |
| pedroalvarez | is this new? | 11:33 |
| pedroalvarez | (only 1h of CI in gitlab) | 11:34 |
| leeming | well that isn't helpful for some things right now :P | 11:36 |
| * leeming wonders what the state of these private runners is | 11:36 | |
| pedroalvarez | add to that wondering if the private runners allow you to increase that limit | 11:37 |
| locallycompact | Is anyone else tackling gcc6? I can't make any progress without it | 11:37 |
| leeming | pedroalvarez, im sure they do, as other projects have run for longer than 1hr builds | 11:37 |
| pedroalvarez | leeming: seems to be configurable in the project (the timeout) | 11:38 |
| pedroalvarez | given that I've forked it, I need to configure mine | 11:38 |
| leeming | never messed about directly with the runner configs, so wouldn't really know | 11:39 |
| pedroalvarez | I can't find where to configure the timeout though | 11:40 |
| leeming | locallycompact, might know? | 11:40 |
| locallycompact | repo? | 11:40 |
| pedroalvarez | found it | 11:41 |
| tiagogomes | locallycompact, what do you need gcc6 for? | 11:42 |
| locallycompact | I can't bootstrap on my laptop | 11:42 |
| locallycompact | getting this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 | 11:42 |
| locallycompact | this seems to be the problem with gcc6 https://gitlab.com/baserock/definitions/builds/4789018 | 11:43 |
| pedroalvarez | locallycompact: I looked into it a while ago, but hit a problem with libffi | 11:43 |
| pedroalvarez | http://git.baserock.org/cgit/baserock/baserock/definitions.git/log/?h=baserock/pedroalvarez/gcc6 | 11:43 |
| pedroalvarez | runtime problem, making python really broken | 11:44 |
| tiagogomes | meh! | 11:44 |
| tiagogomes | can gcc-5 build gcc-6? | 11:44 |
| locallycompact | yes | 11:44 |
| locallycompact | 6 can not build 5.3 | 11:45 |
| * locallycompact overwhelms | 11:45 | |
| tiagogomes | it would be worst if 5 couldn't build 6. I don't know if debian already uses 6 yet for example | 11:45 |
| leeming | why wouldn't you be able to build an older version? | 11:46 |
| leeming | assuming it defines the libs+versions correctly | 11:46 |
| locallycompact | <locallycompact> getting this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 | 11:47 |
| locallycompact | don't assume rhyme nor reason with gcc, it will break because you looked at it funny | 11:47 |
| * leeming has broken bwrap | 11:48 | |
| * locallycompact looks for something to smash | 11:48 | |
| leeming | my brain, i dont think im using it right now | 11:48 |
| tiagogomes | leeming, I will have a look at the bbrwap PR today. Also, it would be nice that future PRs would go to gitlab | 11:49 |
| leeming | i wasn't sure what had been agreed on with lab vs hub | 11:50 |
| leeming | I updated the PR btw, just trying to get it working with ybd | 11:50 |
| leeming | github's interface for your suggested change confused me, as i couldn't see what was proposed | 11:51 |
| pedroalvarez | nah, trove is still broken | 11:55 |
| pedroalvarez | http://paste.baserock.org/jofolifoya | 11:55 |
| pedroalvarez | I guess we need these deps: http://git.baserock.org/cgit/delta/python-packages/yoyo.git/tree/setup.py#n22 | 11:55 |
| * SotK is very confused as to how his trove was lorrying from g.b.o | 11:56 | |
| * leeming assumes when building in bootstrap mode host /dev sound be mounted | 12:00 | |
| leeming | s/sound/must/ | 12:00 |
| *** gtristan has quit IRC | 12:01 | |
| leeming | ah.. seems to get getting past my previous blocking point... ybd was missing a mount for dev (clearly bwrap is pickier than linux-user-chroot) | 12:05 |
| * leeming lunches and hopes not to see an error message on his return | 12:05 | |
| paulsher1ood | https://blogs.gnome.org/tvb/2016/10/13/software-build-topologies/ | 12:17 |
| *** tiagogomes has quit IRC | 12:35 | |
| pedroalvarez | lorry-controller lorrying from yaml http://cache.baserock.org/lc-status.html | 12:38 |
| pedroalvarez | SotK: it works :) | 12:38 |
| pedroalvarez | although I wonder how did you manage to get it working with some of the yoyo dependencies needed | 12:38 |
| pedroalvarez | we need to integrate these before I can upgrade git.baserock.org | 12:39 |
| SotK | yeah, I have no idea what I did that caused that not to happen | 12:40 |
| pedroalvarez | `pip install yoyo` :P | 12:42 |
| leeming | update: looks like ybd+bubblewrap (root) are working. still on stage2 though | 12:42 |
| locallycompact | nice | 12:42 |
| leeming | I guess what tiago said the other day to me was true then. that I had a cached stage1/2 artifact | 12:42 |
| leeming | thus why it seemed to work previously | 12:42 |
| leeming | once this is done. I will nuke the cache and run non-root to see | 12:43 |
| SotK | pedroalvarez: oh, that could actually have been what I did | 12:43 |
| * SotK admonishes himself | 12:43 | |
| leeming | glibc is so huge :P | 12:44 |
| pedroalvarez | you haven't met webkit | 12:44 |
| leeming | :) | 12:44 |
| CTtpollard | ha! | 13:08 |
| *** tiagogomes has joined #baserock | 13:27 | |
| tiagogomes | leeming I reviewed your PR | 13:30 |
| paulsher1ood | leeming: are you testing the sandboxlib bubblewrap implementation with ybd? | 13:36 |
| leeming | tiagogomes, thanks. Reasonable suggestions. not sure why it isn't picking up the logger config tho | 13:37 |
| leeming | paulsher1ood, yes, see above :) | 13:37 |
| leeming | still running the root version | 13:38 |
| leeming | then will check with non-root | 13:38 |
| paulsher1ood | ah, perfect | 13:38 |
| paulsher1ood | so looks like you've found a bug in ybd also? | 13:38 |
| leeming | not sure if it is a bug persay | 13:39 |
| leeming | just probs differences between how bwrap and other sandboxes deal with /dev | 13:39 |
| locallycompact | per se | 13:39 |
| leeming | what he said, extertragh | 13:40 |
| pedroalvarez | someone should investigate what's going on with ybd+ansible | 13:51 |
| pedroalvarez | i haven't managed yet to test my changes using gitlab | 13:52 |
| paulsher1ood | pedroalvarez: what's the problem with ybd+ansible? | 14:13 |
| *** CTtpollard has quit IRC | 14:13 | |
| pedroalvarez | paulsher1ood: this one: http://paste.baserock.org/utofupabiy | 14:14 |
| pedroalvarez | in gitlab ci pipelines, all the time :/ | 14:14 |
| paulsher1ood | warning: remote HEAD refers to nonexistent ref, unable to checkout. | 14:19 |
| *** CTtpollard has joined #baserock | 14:21 | |
| pedroalvarez | paulsher1ood: is that regarding the same issue? I can't find that warning in my logs | 14:23 |
| paulsher1ood | that's what happens when i run 'git clone --no-hardlinks git://git.baserock.org/delta/ansible.git' | 14:24 |
| paulsher1ood | which is what ybd does | 14:24 |
| locallycompact | there's no master in cgit... | 14:26 |
| locallycompact | is that normal | 14:26 |
| paulsher1ood | it's not 'normal' but it's not impossible | 14:26 |
| locallycompact | for ansible | 14:26 |
| pedroalvarez | paulsher1ood: can reproduce the warning, but that is not a failure | 14:26 |
| pedroalvarez | http://paste.baserock.org/jowixaware | 14:27 |
| paulsher1ood | pedroalvarez: strange, then. https://gitlab.com/baserock/ybd/blob/master/ybd/repos.py#L202 | 14:29 |
| * paulsher1ood wonders how come 'call' returns something non-false if the git command returns 0 | 14:30 | |
| tiagogomes | is the gitdir argument a git repo URL or a bare local directory? | 14:31 |
| paulsher1ood | git repo url | 14:31 |
| paulsher1ood | oh, sorry | 14:31 |
| pedroalvarez | regarding 'master' not present, it's normal for ansible project | 14:32 |
| paulsher1ood | yup | 14:32 |
| rjek | The docs for subprocess.call say it has the same fingerprints as subprocess.Popen, which returns a Popen object. | 14:32 |
| paulsher1ood | gitdir is the bare local directory | 14:32 |
| jmacs | No they don't https://docs.python.org/2/library/subprocess.html | 14:33 |
| jmacs | (Same for Python3) | 14:34 |
| jmacs | "return the returncode attribute" | 14:34 |
| * rjek was looking at https://docs.python.org/2/library/subprocess.html#subprocess.call | 14:34 | |
| rjek | "The full function signature is the same as that of the Popen constructor" | 14:35 |
| jmacs | Ah, signature | 14:35 |
| jmacs | Yes, I suppose they don't include the return type in that | 14:35 |
| rjek | The docs are rather ambiguous tbh | 14:36 |
| jmacs | At least in Python 3 they say "mostly the same as" | 14:36 |
| rjek | hah | 14:37 |
| jmacs | Are you sure it's failing on the git clone, and not the git checkout? | 14:38 |
| *** jude_ has joined #baserock | 14:39 | |
| paulsher1ood | i believe so. the error reported from the app.log(name, 'Git clone failed for', ref, exit=True) line | 14:40 |
| leeming | subprocess.Popen seems to pass the CWD env though | 14:40 |
| leeming | even when you do not include it as an arg | 14:41 |
| *** gtristan has joined #baserock | 14:42 | |
| pedroalvarez | nitpick: the error string is confusing given that it's not cloning that ref | 14:43 |
| paulsher1ood | true | 14:44 |
| paulsher1ood | https://gitlab.com/baserock/ybd/commit/c24b2c96c3732fcd6d0677583feb9dab10f68d32 | 14:47 |
| tiagogomes | I think ybd is innocent in this ansible problem | 15:08 |
| pedroalvarez | tiagogomes: anything else to add? | 15:10 |
| pedroalvarez | or just a feeling | 15:10 |
| tiagogomes | HEAD in ansible from git.baserock.org points to refs/heads/master | 15:11 |
| tiagogomes | HEAD in ansible from git://github.com/ansible/ansible points to refs/heads/devel | 15:12 |
| pedroalvarez | <pedroalvarez> can reproduce the warning, but that is not a failure | 15:12 |
| pedroalvarez | <pedroalvarez> http://paste.baserock.org/jowixaware | 15:12 |
| * SotK notes that morph built ansible fine for me last weekend :) | 15:14 | |
| tiagogomes | the warning can be an indication why it would fail later | 15:18 |
| tiagogomes | My point is that the ansible repo in gbo is somewhat damaged | 15:19 |
| *** toscalix has joined #baserock | 15:20 | |
| pedroalvarez | I don't think that lorry also replicates the HEAD | 15:22 |
| SotK | that'd be my guess as to the cause | 15:22 |
| pedroalvarez | so, I don't think that anything has changed in gbo to make it fail | 15:23 |
| SotK | also the repo still works except for not being able to checkout HEAD when cloning | 15:23 |
| *** ctbruce has quit IRC | 15:24 | |
| tiagogomes | oh I can't reproduce the problem with ybd | 15:38 |
| pedroalvarez | then the problem is gitlab? :/ | 15:39 |
| tiagogomes | don't think so, yesterday I reproduced the problem | 15:48 |
| pedroalvarez | tiagogomes: maybe you need to clean your git cache? | 15:58 |
| tiagogomes | I did that :) | 15:58 |
| tiagogomes | will try again | 15:59 |
| pedroalvarez | :/ | 15:59 |
| *** CTtpollard has quit IRC | 16:22 | |
| paulsher1ood | :/ | 16:53 |
| *** locallycompact has quit IRC | 16:58 | |
| jjardon | pedroalvarez; Is this definitions in gitlab? The timeout there is set to 1200 minutes | 17:00 |
| jjardon | Go to ci/CD settings if you are working on a personal repo and you want to change it | 17:01 |
| *** locallycompact has joined #baserock | 18:11 | |
| *** inara` has joined #baserock | 18:43 | |
| *** tiagogomes has quit IRC | 18:45 | |
| *** paulsherwood has joined #baserock | 18:46 | |
| *** toscalix has quit IRC | 18:51 | |
| *** inara has quit IRC | 18:51 | |
| *** leeming has quit IRC | 18:51 | |
| *** paulsher1ood has quit IRC | 18:51 | |
| *** ChrisPolin has quit IRC | 18:51 | |
| *** leeming has joined #baserock | 18:57 | |
| *** ChrisPolin has joined #baserock | 18:57 | |
| *** locallycompact has quit IRC | 21:45 | |
| *** gtristan has quit IRC | 21:53 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!