| *** tristan has joined #buildstream | 06:37 | |
| *** ChanServ sets mode: +o tristan | 06:37 | |
| *** brejoc has joined #buildstream | 07:28 | |
| *** jonathanmaw has joined #buildstream | 08:22 | |
| *** ssam2 has joined #buildstream | 09:23 | |
| tristan | chrispolin, So, did you ever get passed the hurdle of installing ? | 10:38 |
|---|---|---|
| chrispolin | I did indeed. | 10:38 |
| tristan | chrispolin, I'm trying to rewrite the user story for getting started and make virtualenv the "right way" | 10:38 |
| tristan | Nice | 10:38 |
| tristan | curiously, how did you get passed the initial problems ? | 10:39 |
| chrispolin | It was an issue with ruamel.yaml, as you suggested. Was getting that error that ironfoot and I posted when trying to install with pip. | 10:39 |
| tristan | Hmmm | 10:40 |
| tristan | Ok, curiously, did you do _any_ system wide installation with pip ? | 10:40 |
| tristan | Did you `sudo pip` at all ? | 10:40 |
| ironfoot | I'm intereseted in knowing the solution to the problem too | 10:41 |
| tristan | its a god damned mess | 10:41 |
| tristan | pip and setuptools are just awful | 10:41 |
| tristan | ironfoot, so what distro do you run and were you ever able to run buildstream without the docker crazy ? | 10:42 |
| chrispolin | I didn't 'sudo pip', but I did end up having to use apt-get to get over that initial issue. Which I realise contradicts what buildstream is for, but I wanted to get it built first and readdress issues afterwards. | 10:43 |
| tristan | chrispolin, I dont think it's contradictory to use your package manager to install buildstream's base dependencies no | 10:43 |
| tristan | but what did you install with the package manager btw ? | 10:43 |
| tristan | ruamel ? | 10:44 |
| chrispolin | ruamel.yaml | 10:44 |
| tristan | I see | 10:44 |
| tristan | yeah that should be OK | 10:44 |
| tristan | but it should not be required | 10:44 |
| ironfoot | tristan: what do you mean. What distro I used to install buildstream? | 10:44 |
| ironfoot | (note, i always used docker) | 10:44 |
| tristan | chrispolin, what distro do you have and what version of python ? | 10:44 |
| tristan | ironfoot, yes, what distro is running on the machine where you can run buildstream, and what python version is there ? | 10:45 |
| ironfoot | but distro used was debian stretch, (which is debian testing) | 10:45 |
| ironfoot | python 3.5 | 10:45 |
| tristan | ironfoot, oh, then you should have no problem _at all_ to just run buildstream locally | 10:45 |
| tristan | What was the reason you reached for a docker in the first place ? | 10:45 |
| chrispolin | Debian 8.7, Python 3.4 | 10:45 |
| ironfoot | locally i use debian jessie | 10:45 |
| chrispolin | (jessie) | 10:46 |
| tristan | ironfoot, Oh, OK so your docker image is that | 10:46 |
| tristan | stretch | 10:46 |
| tristan | I see | 10:46 |
| tristan | ironfoot, and in stretch you have 3.4, as does chrispolin | 10:46 |
| ironfoot | in jessie, i have 3.4, as chrispolin | 10:46 |
| tristan | ironfoot, but at the time we required 3.5, and only recently I patched some things so that jonathanmaw could run on 3.4 | 10:46 |
| tristan | So that's why | 10:47 |
| tristan | Alright, that explains that, but it also makes you an interesting candidate | 10:47 |
| tristan | to test something :) | 10:47 |
| tristan | ironfoot, can you try a few commands for me ? | 10:47 |
| ironfoot | sure | 10:47 |
| tristan | ironfoot, A.) ensure that you have virtualenv, pygobject, ostree and bubblewrap installed with package manager | 10:48 |
| tristan | ostree and bubblewrap are available through jessie-backports | 10:48 |
| tristan | cd /path/to/buildstream | 10:48 |
| tristan | virtualenv --system-site-packages -p python3.4 sandbox | 10:49 |
| tristan | source sandbox/bin/activate | 10:49 |
| tristan | pip install -e . | 10:49 |
| tristan | ~~~~~~~~~~~~~ | 10:49 |
| tristan | Thats all | 10:49 |
| tristan | That should install buildstream (and any dependencies it needs) entirely inside the virtualenv sandbox, without littering your system at all with pip | 10:50 |
| ironfoot | hm.. is it python-gi the package for pygobject? | 10:50 |
| tristan | it's either python-gi | 10:51 |
| tristan | Or its pygobject3 | 10:51 |
| tristan | weird, I dont find it | 10:51 |
| tristan | on my stretch, python-gi title says it's for python2 :-S | 10:52 |
| tristan | ironfoot, python3-gi | 10:52 |
| tristan | that's what it is, python3-gi | 10:52 |
| ironfoot | true, py3 | 10:52 |
| tristan | So what I'm thinking now, is I want to be able to remove --system-site-packages from that user story | 10:54 |
| tristan | But for that, I need to be able to get pygobject via pip | 10:55 |
| tristan | into the virtual env :-S | 10:55 |
| tristan | But it should work without that... the --system-site-packages only makes it fragile, in case the user has already garbaged their system with `sudo pip` in the past | 10:55 |
| ironfoot | tristan: http://paste.baserock.org/upumuqokep | 10:56 |
| ironfoot | i may need to install some ostree python library first, maybe | 10:56 |
| tristan | yes | 10:56 |
| tristan | gir1.2-ostree-1.0 | 10:57 |
| tristan | Should be it | 10:57 |
| tristan | lemme check what it is here | 10:57 |
| tristan | that's exactly what it is here | 10:57 |
| tristan | ironfoot, sorry I did not mention that; the important part is to not only have the library, but also have the introspection data for PyGObject to access the library | 10:58 |
| tristan | that is the "gir" | 10:58 |
| ironfoot | installed | 10:58 |
| tristan | So from there you can run bst right ? | 10:58 |
| ironfoot | yep | 10:58 |
| tristan | Ok, good to know | 10:58 |
| tristan | Now, what should we do | 10:59 |
| ironfoot | xD | 10:59 |
| tristan | I also have a trick for generating man pages | 10:59 |
| tristan | If you install in that same venv: pip install click-man | 11:00 |
| tristan | (or click_man) | 11:00 |
| ironfoot | `which bst` spits pwd/sandbox/bin/bst, which is good | 11:00 |
| tristan | Then you can do: python3 setup.py --command-packages=click_man.commands man_pages | 11:00 |
| ironfoot | http://paste.baserock.org/ivizafuxeb | 11:01 |
| tristan | seriously ?! | 11:02 |
| tristan | crap | 11:02 |
| tristan | Well, man pages aside | 11:03 |
| tristan | I have an idea that I may (ugh, I hate this), just commit generated man pages | 11:04 |
| tristan | because with that, I can tell setup.py to distribute them as data_files | 11:04 |
| tristan | and they will "just work" the moment this is actually installed on a real system | 11:04 |
| tristan | But for the time being... | 11:04 |
| tristan | ironfoot, I think maybe a helper script for running bst in a venv would be helpful ? | 11:05 |
| tristan | Or... just some instructions on using venv ? | 11:05 |
| ironfoot | tox helps with the creation of venvs, not sure if we can use it nicely here | 11:06 |
| tristan | I was thinking, if I wrap it up with our own script | 11:06 |
| ironfoot | is more tests oriented | 11:06 |
| tristan | Then I can additionally set MANPATH in it | 11:06 |
| tristan | and when you enter the env you also have the man pages | 11:06 |
| tristan | The helper script could create a venv only if it doesnt exist, and activate it | 11:07 |
| * albfan[m] sent a long message: albfan[m]_2017-04-12_12:11:35.txt - https://matrix.org/_matrix/media/v1/download/matrix.org/hyETClapyQWdlXrokFLJUgzx | 12:11 | |
| tristan | albfan[m], the thing is, with flatpak-builder you are leveraging build metadata that exists | 12:14 |
| tristan | i.e. org.gnome.Todo.Test.json | 12:15 |
| tristan | albfan[m], it's planned that we create a conversion script for those which should work pretty much seamlessly, but there are a couple blockers to that | 12:15 |
| tristan | i.e. jonathanmaw is working on the Source implementation that would be needed | 12:15 |
| albfan[m] | tristan: Let me know If I can go on that blockers or test anything | 12:16 |
| tristan | right now, without that, you would need to A.) Build everything from git (no tarballs or hg/bzr Sources) and B.) Manually translate the build instructions | 12:17 |
| tristan | Similar to what I did for the gedit demo | 12:17 |
| tristan | which pulls in the flatpak runtime/sdk required, and builds some stuff | 12:17 |
| tristan | Now lets assume that there is a conversion script; to run tests there would be a manual or an automated approach | 12:18 |
| jonathanmaw | tristan: speaking of which, I finally have a merge request for you https://gitlab.com/BuildStream/buildstream/merge_requests/18 | 12:18 |
| tristan | manual approach would be `bst shell --deps runtime gnome-todo.bst`, and then run the tests | 12:18 |
| tristan | automated approach would be to create an element which includes instructions for running the tests, and then `bst build gnome-todo-tests.bst` | 12:19 |
| tristan | jonathanmaw, yay ! | 12:19 |
| tristan | At least your day was productive, while mine was lost in a mine field of pip and virtual env :'( | 12:19 |
| jonathanmaw | tristan: one thing that surprised me while testing my tar implementation is that having "track: false" in the yaml doesn't work for me, I guess because it was treating it as a string, not a boolean. | 12:20 |
| tristan | jonathanmaw, I'm curious how your tarball plugin fares with suspend/resume/terminate btw, have you tried that ? | 12:20 |
| jonathanmaw | tristan: I have not | 12:20 |
| jonathanmaw | I might have to fetch a pretty big tarball to get the opportunity. | 12:21 |
| tristan | There is a bug with ostree that I should file, which is a bit awkward and corner case; seems to suspend/resume alright, but when terminating a long standing ostree fetch; other processes (like ongoing git clones) become orphaned | 12:21 |
| jonathanmaw | tristan: I assume if I wanted track to be a true/false, then I ought to pass a different type into node_get_member. | 12:22 |
| tristan | jonathanmaw, Oh | 12:23 |
| albfan[m] | tristan: got it | 12:23 |
| tristan | jonathanmaw, what would track true/false do ? | 12:23 |
| jonathanmaw | tristan: I have no use for setting "track" to anything specific, because there's no specific tracking ref to fetch and set the ref to. So it might as well be a binary true/false. | 12:23 |
| tristan | jonathanmaw, sorry I missed that part yesterday; I think that 'track' as a configuration option of the tar Source was not needed | 12:23 |
| tristan | and we would just not have it... just that the _behaviour_ of tracking a tarball would be to get the sha256sum | 12:24 |
| tristan | automatically | 12:24 |
| tristan | jonathanmaw, what would it mean if track were false ? | 12:24 |
| tristan | disable the feature ? | 12:24 |
| jonathanmaw | tristan: yep. but it looks nicer for it to be set to false, than to be commented-out | 12:25 |
| tristan | jonathanmaw, what about if it's just not there at all ? | 12:25 |
| tristan | instead of commented out :) | 12:25 |
| jonathanmaw | tristan: true, it's fair to expect that they're working in git, so don't lose anything by deleting the track line | 12:26 |
| tristan | jonathanmaw, I have some ideas how we *could try* to implement a more meaningful track experience in the future (i.e. most tarball release servers have some structure, could be that track could eventually point to a subdir on an ftp server, and we resolve to the latest available tarball of a given release directory) | 12:27 |
| tristan | but I think its a bit crack | 12:27 |
| tristan | anyway probably not something to spend time worrying about now | 12:27 |
| jonathanmaw | ok, I should probably update the comments pointing out that _any_ value for track is treated as true. | 12:28 |
| tristan | jonathanmaw, rather I think we should just remove it entirely for the tar plugin for now | 12:28 |
| tristan | It could become a feature in the future, for right now, the behavior of tracking a tarball is just to automatically update the sha256sum | 12:29 |
| jonathanmaw | tristan: ok, so "bst track foo" should happen unconditionally, for the time being? | 12:30 |
| tristan | Yes, if the user asks to track an element with tarball sources, the way a tarball source handles that is to update the sha256 sum | 12:30 |
| tristan | better to not provide additional API unless it's meaningful | 12:31 |
| tristan | jonathanmaw, note that tracking is not something that happens unconditionally | 12:32 |
| tristan | it's something the user asks for | 12:32 |
| tristan | And it doesnt really fit with tarballs the way it does with VCSs, only that tarballs are a thing, and it seems to me that automatically updating the sha256sum is a useful thing to do :) | 12:33 |
| jonathanmaw | tristan: up until someone tries to update all refs by running 'bst track' on every element, but with many disparate source types, that's a risky thing to do, anyway. | 12:33 |
| tristan | Not entirely I think | 12:34 |
| tristan | Well, I would assume that you generally revision your BuildStream project | 12:34 |
| tristan | So it's really up to you what you commit as a result of tracking | 12:34 |
| tristan | Of course, it's true that it's undesirable to repeatedly update the sha256sum over time | 12:35 |
| jonathanmaw | especially because you have to fetch the entire tar each time to do it :) | 12:35 |
| tristan | and if it ever changes for a tarball, it may be an indication of some evil | 12:35 |
| tristan | jonathanmaw, I think you don't, though | 12:36 |
| tristan | I mean, it will mirror unconditionally, for either track or fetch | 12:37 |
| tristan | Once it's been mirrored, it's there, and track will only calculate the checksum of the downloaded tarball | 12:37 |
| tristan | Right ? | 12:37 |
| jonathanmaw | aha, sloppy wordage. I was using "fetch" to mean all kinds of downloading. | 12:37 |
| tristan | Yes I think I understood, but in any case... `bst track foo.bst` twice... will only download foo.bst's tarballs once | 12:38 |
| tristan | This is correct right ? | 12:38 |
| tristan | I think so | 12:39 |
| tristan | looking at _ensure_mirror() | 12:39 |
| jonathanmaw | tristan: I don't think there's any way of knowing whether the sha256sum of the file has changed between downloads without actually downloading it. | 12:39 |
| tristan | :-/ | 12:39 |
| tristan | I dont think that is the desire, though | 12:40 |
| tristan | right now it looks like it works well enough | 12:40 |
| tristan | jonathanmaw, there is a strange case in which a remote tarball being served has changed, or a mitm attack occurs | 12:40 |
| tristan | in which case an sha256sum changes | 12:40 |
| tristan | jonathanmaw, it's pretty standard practice to hold on to tarball shas | 12:41 |
| tristan | exactly to prevent against this kind of mitm | 12:41 |
| tristan | or ensure you've got the right thing | 12:41 |
| tristan | So, track is something you do, because you are either creating a new element, or you are updating to a new tarball | 12:41 |
| tristan | After which point you've committed your sha | 12:42 |
| tristan | The next person who fetches, should get an error if the sha is a mismatch | 12:42 |
| tristan | (i.e. they never mirrored that tarball before) | 12:42 |
| tristan | So far so good | 12:43 |
| tristan | jonathanmaw, that said, it *may* be of interest to add a warning if track() is called, and self.ref is not None, and the resulting ref is *different* than what was already there ? | 12:44 |
| tristan | That is A.) It could be the user changed the tarball URI (new tarball is intended anyway, so it's not a problem) .. or B.) User was refreshing all branches in a larger project, and for _some reason_ they have obtained a different checksum this time around ? | 12:45 |
| tristan | Where (B) may be an attack ? | 12:45 |
| tristan | I dont know, I think it's overkill | 12:45 |
| tristan | to consider this right now: tracking a tarball is only a convenience for updating the for you, so that you dont have to | 12:46 |
| tristan | something jjardon[m] will be happy about when crawling through huge moduleset files and updating to latest release tarballs | 12:46 |
| jonathanmaw | tristan: I think it's something we should look at again if we ever expect track to be used automatically | 12:47 |
| tristan | Sure | 12:48 |
| tristan | I do expect it to be used automatically, by surrounding scriptage | 12:48 |
| jonathanmaw | and if instructions ever appear to run `bst track` on every tar source, just before building, they need to be chastised for blatantly ignoring security. | 12:49 |
| tristan | For instance: A CI server does `bst track --deps all target.bst && bst build target.bst` | 12:49 |
| tristan | And if the build passes, it submits a candidate branch for review | 12:49 |
| tristan | I.e. that's the regular case: Get me the latest of everything on their tracking branches and try it | 12:50 |
| tristan | if it's good, lets commit | 12:50 |
| tristan | it's true, tarballs are a bit different in that regard | 12:50 |
| jonathanmaw | tristan: review gives a chance to check whether the changes to sha256sums are trustworthy, at least. | 12:50 |
| tristan | at least yeah, and thats why I wonder if a warning can be good | 12:50 |
| tristan | i.e.: If you change the tarball url and delete the ref, you dont get a warning | 12:51 |
| jonathanmaw | hmm, AIUI, an element can have multiple sources, and those sources can be of varying types. Will we have to worry about different sources treating track slightly differently? | 12:51 |
| tristan | If you change the tarball url and _dont_ delete the ref, track produces a warning saying this sha256sum you already had may have changed | 12:51 |
| jonathanmaw | I suppose it makes sense to make these changes now, rather than forget about them when they're needed later :) | 12:52 |
| tristan | jonathanmaw, I'm not really worried about sources treating that differently, although we can never be certain for sources that are not first class citizens | 12:52 |
| tristan | I.e. projects are free to include their own Source implementations in a subdir, and those can go an hack the fbi database and automatically send out personal information about the president in their track() implementations for all I care :) | 12:53 |
| tristan | https://gitlab.com/jonathanmaw/buildstream/commit/1653dac7c9baf591dfbcc9776c0f3917880f9e41#f352dc2162c6fa9a9e75c276dd143ab3270b9063_0_101 | 12:54 |
| tristan | jonathanmaw, I dont really like this line ^^^^^^ | 12:54 |
| tristan | try: ... raise SourceError() ... except Exception as e: ?? | 12:55 |
| tristan | looks like that surrounding try/except is just noise | 12:55 |
| tristan | jonathanmaw, rather, _ensure_mirror() should be normalizing the errors it produces at the source of the error | 12:56 |
| tristan | jonathanmaw, would you rather I comment this in the MR than chatting about it here ? | 12:56 |
| jonathanmaw | tristan: on the MR makes it a bit more transparent, I think | 12:56 |
| tristan | Sure | 12:56 |
| jonathanmaw | tristan: is preflight the right place to check whether ref has been set? I don't know whether `bst track` sidesteps that | 12:58 |
| jonathanmaw | I suppose it can't, because preflight is used to check that necessary binaries exist. | 12:58 |
| tristan | Added some comments | 13:03 |
| tristan | jonathanmaw, I suppose that could be better documented for plugin authors indeed | 13:04 |
| tristan | jonathanmaw, What's going to happen, is I believe fetch will never be called if the Source is INCONSISTENT | 13:04 |
| tristan | if it's INCONSISTENT, then it's considered that track() is required, the user will be told they must track at this point | 13:05 |
| tristan | if its RESOLVED but not CACHED, then fetch() is needed | 13:05 |
| jjardon[m] | someone mentioned me here :) currently we use scripts that grab the tarballs for the locations specify in jhbuild + a control file (https://git.gnome.org/browse/releng/tree/tools/smoketesting/tarball-conversion.config) to then generate new modulesets using tarballs instead. Script here: https://git.gnome.org/browse/releng/tree/tools/smoketesting/convert-to-tarballs.py | 13:05 |
| jjardon[m] | tristan: jonathanmaw in case Its useful ^ | 13:06 |
| tristan | jjardon[m], yeah I was just talking about how it can be a convenience for someone who has to update a bunch of tarballs, that we can automatically update the sha256 sums | 13:06 |
| tristan | jjardon[m], so maybe you have some thoughts on the topic | 13:07 |
| tristan | jjardon[m], The question we're asking... is: When you have a big project and you want to automatically "track" the latest of everything | 13:07 |
| tristan | jjardon[m], and some of your sources are tarballs | 13:08 |
| jjardon[m] | the current script do exactly that: they generate new modulesets with reference to the tarballs and the sha256: https://www.mirrorservice.org/sites/ftp.gnome.org/pub/GNOME/teams/releng/3.24.0/gnome-suites-core-3.24.0.modules | 13:08 |
| jjardon[m] | ah | 13:08 |
| tristan | jjardon[m], now there is a weird, rare chance, that your tarball already had an sha256sum specified... but `bst track` found a DIFFERENT sha256sum | 13:08 |
| tristan | that can be because the ftp server is fubar | 13:09 |
| tristan | or corrupted | 13:09 |
| tristan | Or because there was some mitm attack | 13:09 |
| jjardon[m] | in GNOME we only use tarballs for releases; that can change in the future | 13:09 |
| jjardon[m] | some prople is pushing to simply use git tags instead | 13:09 |
| jjardon[m] | not sure if this reply to your questions? | 13:10 |
| tristan | jjardon[m], Right now, we prefer the convenience that `bst track` will update an sha256sum of a tarball in the project inline, but we dont really know if A.) The user just change the tarball URL to a new release, and WANTS a new sha256sum ... or B.) The user wanted to track/update everything else, and a new sha256sum was *inadvertently* added | 13:10 |
| tristan | jjardon[m], it does not, you wont be able to reply unless you read everything I wrote and understand it :D | 13:11 |
| tristan | jjardon[m], So, we are considering; perhaps BuildStream should issue a warning, in the case that an sha256sum was *already specified* and does *not match* the introspected checksum | 13:12 |
| tristan | I.e. something bad *could* have happened | 13:12 |
| tristan | jjardon[m], see what I'm getting at now ? | 13:12 |
| jjardon[m] | yep, Id error in that case; but let me read all first | 13:12 |
| tristan | If the user wants to update to new releases, they go and change a bunch of urls, and run `bst track` to update the checksums... if they did not *remove* the previous checksums, is it an error ? or just a warning ? | 13:13 |
| tristan | With an error, it would mean that you have to also delete the previous checksums whenever you update tarball uris | 13:14 |
| tristan | With a warning, you would just be warned that an existing sha256sum changed | 13:15 |
| jjardon[m] | maybe Im misubdaerstanding some buildstreamsemantics here, but can "track" somehow means "track the latest tarballs in this folder", so when you run the tool, the sha256 gets updated to the latest tarball available in that repo? | 13:17 |
| tristan | jjardon[m], We discussed that earlier in the backlog, I think it would be an interesting feature but also I think it's a bit fragile and 'crack' | 13:19 |
| tristan | at the moment | 13:19 |
| tristan | jjardon[m], I'm not averse to adding something crazy like that in the future, but an ftp server really is not a VCS | 13:19 |
| jjardon[m] | yup, only wanted to explain how our current tools work atm | 13:20 |
| tristan | jjardon[m], it might for example, involve some kind of pattern matching semantics which might need to go into the configuration | 13:20 |
| tristan | GNOME's tarball server works one way, it may not match exactly with how sourceforge's tarballs are served, etc | 13:21 |
| tristan | jjardon[m], in your case I guess, you would want the 'uri' to be a base ftp.gnome.org/pub/somemodule | 13:22 |
| tristan | And then 'track' would be a release subdir, and finally the 'ref' would be a tuple of release tarball itself and sha256sum | 13:23 |
| tristan | jjardon[m], anyway yeah, it's feasible, but fragile... and I'd rather not spend time on that right now | 13:23 |
| jjardon[m] | tristan: yeah, those heuristics are in https://git.gnome.org/browse/releng/tree/tools/smoketesting/convert-to-tarballs.py (some tarballs are not in gnome repos as you pointed out) | 13:24 |
| tristan | yeah, heuristics is exactly the word for something not exactly reliable :) | 13:25 |
| jjardon[m] | :) (for example, we have had problems before with tarballs named 1.a and 1.b and the script crashes because it didn't know whats bigger) | 13:26 |
| tristan | I also had the thought that with ftp protocol you can probably get the datestamp before download | 13:27 |
| tristan | Also GNOME servers offer a feature of providing a LATEST symlink | 13:27 |
| tristan | they are all sorta different (tarball hostings) | 13:27 |
| tristan | jonathanmaw, anyway yeah, ultimately what we are discussing would be a full blown, more accurate interpretation of what "track" means; but lets not go down this crazy path "just yet" | 13:29 |
| tristan | :D | 13:29 |
| tristan | brejoc, I wanted to find time to chat with you, and thanks for the comments on the blog, it sounds very interesting... but alas for today I have run out of time | 13:30 |
| tristan | ironfoot, maybe you, as the official "docker dude", may have some more concrete ideas regarding the last comments on: https://blogs.gnome.org/tvb/2017/02/06/introducing-buildstream-2/ | 13:31 |
| tristan | ironfoot, sounds interesting to me, a deployment element to generate a docker image ? | 13:31 |
| tristan | And maybe coupled with some Source plugins which could implement our Source sementics for "importing a debian runtime" or such | 13:32 |
| tristan | Would allow to take someone's already build deterministic sysroot, build some things on top of it for a web hosting, and finally deploy it as a cloud ready docker image ? | 13:33 |
| tristan | sounds pretty nice actually :) | 13:33 |
| ssam2 | like Nix and GUIX but without the totalitarian approach | 13:36 |
| tristan | pizza time | 13:37 |
| *** tristan has quit IRC | 13:40 | |
| *** brejoc has quit IRC | 13:40 | |
| *** tristan has joined #buildstream | 14:04 | |
| *** ChanServ sets mode: +o tristan | 14:05 | |
| jonathanmaw | tristan: it looks like I'm having some trouble when converting an urllib.URLError into a SourceError using "raise foo from bar" | 15:01 |
| jonathanmaw | I get "TypeError: __init__() missing 1 required positional argument: 'message'" | 15:02 |
| jonathanmaw | "message" appears to be an argument passed into the SourceError's constructor. | 15:03 |
| *** ssam2 has quit IRC | 15:08 | |
| jonathanmaw | I think It worked it out. raise foo from bar still needs foo to be constructed with args like normal. | 15:16 |
| jonathanmaw | s/It/I/ | 15:16 |
| *** ssam2 has joined #buildstream | 15:25 | |
| jonathanmaw | tristan: merge request updated https://gitlab.com/BuildStream/buildstream/merge_requests/18 | 15:55 |
| jonathanmaw | I'm going to disappear for today, as I have to disappear to prepare for some nerd-wrangling (roleplaying games) | 15:55 |
| *** jonathanmaw has quit IRC | 15:57 | |
| tristan | right... 'from' was added in python3 and allows reraising new errors whilst preserving the originals they came from (but I see I got here late) :) | 16:00 |
| chrispolin | Running into this issue, appears to be a problem involving gcc. http://paste.baserock.org/oyokinejev | 16:11 |
| chrispolin | I have gcc 4.9.2, so I don't think it's to do with the problem here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 | 16:13 |
| ssam2 | it looks like something fails when buildstream tries to unpack the artifact, at a glance | 16:15 |
| ssam2 | I don't think it's to do with gcc at all | 16:15 |
| *** brejoc has joined #buildstream | 16:41 | |
| *** xjuan has joined #buildstream | 16:41 | |
| *** ssam2_ has joined #buildstream | 17:02 | |
| *** ssam2 has quit IRC | 17:04 | |
| *** ssam2 has joined #buildstream | 17:10 | |
| *** ssam2_ has quit IRC | 17:12 | |
| *** ssam2 has quit IRC | 17:16 | |
| *** tiagogomes has quit IRC | 17:16 | |
| *** chrispolin has quit IRC | 17:16 | |
| *** chrispolin has joined #buildstream | 17:17 | |
| *** tiagogomes has joined #buildstream | 17:17 | |
| *** tiagogomes_ has joined #buildstream | 17:22 | |
| *** ssam2 has joined #buildstream | 17:22 | |
| *** tiagogomes has quit IRC | 17:24 | |
| *** tiagogomes_ has quit IRC | 17:25 | |
| *** chrispolin has quit IRC | 17:25 | |
| *** ssam2 has quit IRC | 17:25 | |
| tristan | whats with the gaps ? | 17:26 |
| tristan | is weird JS pastebin to blame for that ? | 17:26 |
| *** brejoc has quit IRC | 17:29 | |
| *** chrispolin has joined #buildstream | 17:31 | |
| *** tiagogomes_ has joined #buildstream | 17:31 | |
| tristan | chrispolin, your paste seems to have messed up, there are weird gaps, maybe weird JS pastebin is to blame | 17:32 |
| tristan | that or, the output really contains gaps ? | 17:32 |
| tristan | chrispolin, it looks however like you hit the race and we're casing the wrong error | 17:34 |
| tristan | chrispolin, maybe this line should be EEXISTS ? | 17:34 |
| tristan | https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_artifactcache.py#L114 | 17:35 |
| * tristan thinks that's what's happening, and if you relaunch the build, you wont get that error again | 17:35 | |
| *** Chris has joined #buildstream | 18:28 | |
| *** chrispolin has quit IRC | 18:30 | |
| *** brejoc has joined #buildstream | 20:02 | |
| *** xjuan has quit IRC | 21:31 | |
| *** brejoc has quit IRC | 21:47 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!