| *** david-mora_ has quit IRC | 01:18 | |
| *** bochecha has quit IRC | 02:19 | |
| *** bochecha has joined #buildstream | 02:20 | |
| *** bochecha has quit IRC | 02:24 | |
| *** bochecha has joined #buildstream | 02:24 | |
| *** tristan has joined #buildstream | 02:30 | |
| gitlab-br-bot | buildstream: issue #100 ("Avoid package upgrades during CI") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/100 | 04:54 |
|---|---|---|
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 4 commits (last: exceptions.py: Added USER_ASSERTION load error) https://gitlab.com/BuildStream/buildstream/commit/bf679177ffd3041ad72600a87086bee19807753c | 05:00 |
| juergbi | tristan: do you see a reason why we need/want multiple actual pipeline objects for 'recursive pipelines'? wouldn't it make more sense to handle that all as part of the load process and after loading it's just one big pipeline? | 05:02 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: doc/source/formatintro.rst: Remove reference to architecture conditionals) https://gitlab.com/BuildStream/buildstream/commit/a580a4a032c2e492c5287a976ced1db178467549 | 05:08 |
| tristan | juergbi, Hmmmmmmmmmmmmm | 05:12 |
| tristan | If we load everything in one Pipeline, Elements will still be referring to their own Projects | 05:13 |
| tristan | which I suppose is the more important piece | 05:13 |
| juergbi | yes | 05:13 |
| juergbi | but the scheduler doesn't really care where the elements came from | 05:13 |
| tristan | Indeed, so we care more about the case of sharing artifacts and blending within the build, and it's possible we muck things up by having separate pipelines | 05:14 |
| tristan | onces projects recursively depend on a common project, we may have duplicates we fail to control | 05:14 |
| juergbi | exactly | 05:14 |
| juergbi | we anyway don't have strictly just nested dependencies, elements can (almost) depend on elements of any other project | 05:14 |
| tristan | the other case anyway of not sharing artifacts; can always be achieved with an export/import song and dance | 05:15 |
| juergbi | due to common dependency projects | 05:15 |
| tristan | correct | 05:15 |
| tristan | I'm curious how the initial load and everything is going to happen :) | 05:15 |
| tristan | I suppose if we need to have some kind of derivable consistency state (i.e. not cached state), indicating that "we have all the projects we need to load a pipeline cached in sources" | 05:16 |
| tristan | And if you declare that the user needs to perform an additional step to be "ready to build", it's undesirable but totally acceptable I think | 05:17 |
| juergbi | not sure i follow here | 05:18 |
| tristan | something similar to `git submodule update` I suppose | 05:18 |
| tristan | I mean... when you depend on a project, you will need a Source to refer to it some way | 05:18 |
| juergbi | yes | 05:18 |
| tristan | And then it will need to be downloaded and checked out... but... so will other things | 05:18 |
| juergbi | you don't want to fetch the source implicitly? | 05:18 |
| tristan | No I'm saying the opposite of that | 05:19 |
| juergbi | ah, would be before the main pipeline | 05:19 |
| tristan | I desire to make it implicit, but if it must be explicit for technical reasons, I guess that would be acceptable | 05:19 |
| tristan | juergbi, there *might* be an interesting two birds one stone thing here | 05:20 |
| juergbi | i think we can do it implicitly, however, we may have to do the 'submodule update' before the actual pipeline is initialized | 05:20 |
| tristan | https://gitlab.com/BuildStream/buildstream/issues/5 | 05:20 |
| juergbi | i.e., not like real source fetching | 05:20 |
| tristan | or like source fetching but a pre-stage, outside of the rest of everything | 05:20 |
| tristan | Note that people start to get finicky when buildstream does stuff in advance of the main logging session and initial report | 05:21 |
| tristan | even though we're giving them some feedback of what is going on | 05:21 |
| juergbi | yes, i'm worried about that a bit | 05:21 |
| tristan | So in that case, an explicit command might be more desirable to solve that I'm not sure | 05:21 |
| juergbi | but we also need it for bst show and co | 05:22 |
| tristan | Ah | 05:22 |
| tristan | Well | 05:22 |
| tristan | There I am a bit uncertain | 05:22 |
| tristan | So, we're going to need some kind of core element to declare what we depend on from another project | 05:23 |
| tristan | And when we do bst show, we're looking at a single project by default I think | 05:23 |
| tristan | cache keys should still all work out without having the external project | 05:23 |
| tristan | because of this internal junction element | 05:23 |
| tristan | or whatever we call it | 05:23 |
| juergbi | hm, we can't have strict cache keys without looking at all the dependencies | 05:24 |
| tristan | But indeed, perhaps we want a nice feature that optionally does `bst show --recursive` and requires a buildable project state | 05:24 |
| tristan | Ohhhhh | 05:24 |
| tristan | right they are recursive | 05:24 |
| juergbi | the import/export shortcut might not need it but the blended one will | 05:25 |
| tristan | yeah, I would even leave import/export convenience shortcut out (it can be done with a song and dance outside of buildstream, but can be interesting to have as a convenience too) | 05:26 |
| juergbi | yes, i'm not focusing on that as that concept is pretty clear | 05:26 |
| tristan | Well | 05:27 |
| tristan | BuildStream projects are generally lightweight | 05:27 |
| juergbi | yes, thinking the same | 05:27 |
| tristan | So downloading them should not be that annoying | 05:27 |
| juergbi | in typical cases, 'source' update for that should be very fast | 05:27 |
| tristan | Extra commands are annoying in general, but here we have a lot of cases which will want to have a sane project state | 05:28 |
| juergbi | i think it would be less annoying than failing with 'please manually run bst ... update' | 05:28 |
| tristan | Yeah, so we can immediately know if it needs to happen at all | 05:28 |
| tristan | and the step can be skipped | 05:29 |
| tristan | But bst show is a very tricky sucker here | 05:29 |
| tristan | the other things less so | 05:29 |
| tristan | Mostly because we want to provide nice things for scriptability via bst show | 05:29 |
| juergbi | we could consider to just show the status with bst show | 05:29 |
| juergbi | and don't implicitly update it | 05:29 |
| tristan | (so that means, if my tool is parsing bst show output... I dont want to care about a pre-process and logging) | 05:29 |
| juergbi | but implicitly fetch it for build etc. commands | 05:30 |
| juergbi | e.g., bst show could show that some subproject requires fetching | 05:30 |
| tristan | Well, showing cache keys is something we want to keep for sure | 05:30 |
| juergbi | and due to that, cache keys can't be determined | 05:30 |
| tristan | But showing unknowns for those is also acceptable | 05:30 |
| tristan | yeah | 05:31 |
| juergbi | yes, at least when all project specs are available, all bst show functionality should be there as is | 05:31 |
| juergbi | but if something is missing / out-of-date, maybe just report that | 05:31 |
| juergbi | and have a bst command that just updates that | 05:31 |
| juergbi | but don't require that explicit command for bst build | 05:31 |
| tristan | juergbi, ok so maybe this fits in well with our --deps pattern on multiple commands | 05:31 |
| tristan | Maybe we can use `bst fetch --deps projects` | 05:32 |
| tristan | to *only fetch the projects recursively* or something ? | 05:32 |
| tristan | hmmm weird implementation wise | 05:32 |
| juergbi | possibly but it might not make sense for all commands | 05:32 |
| tristan | yeah well, I think we agree that, we will want an explicit step to be possible, and we dont want it to be required for main operations | 05:33 |
| tristan | like bst build | 05:33 |
| juergbi | ok, sounds good | 05:34 |
| tristan | then we can work out on a case by case basis, what needs to error out if that step is incomplete, and what needs to just function differently | 05:34 |
| juergbi | fair enough | 05:35 |
| tristan | juergbi, so for this... since multiple elements can depend on the same project - there is something somewhere which defines the Source for that project | 05:35 |
| tristan | I guess | 05:35 |
| tristan | ensuring we refer to the same version/uri for that project | 05:35 |
| juergbi | yes, conceptually, project.conf makes most sense. although i don't really like making it bigger and bigger | 05:36 |
| tristan | juergbi, my two birds one stone effect... https://gitlab.com/BuildStream/buildstream/issues/5 ... maybe addressing issue 5 first in some way, will help us with that ? | 05:36 |
| juergbi | maybe, will think about it | 05:37 |
| juergbi | i was planning to have something a bit like aliases | 05:37 |
| juergbi | except that they don't just define a URL but also SHA / tracking ref | 05:37 |
| tristan | yeah, bochecha and I had some not-in-depth discussion but... notice that having sources in the project makes `bst track` semantics very weird | 05:37 |
| juergbi | and then you can refer to them via fooproject:bar.bst | 05:38 |
| juergbi | yes, that's why i initially wanted to use a .bst file but it also doesn't really fit | 05:38 |
| tristan | right, I would not like to make any assumptions of how the user is storing their projects | 05:38 |
| tristan | They might choose git | 05:38 |
| tristan | and in any case, we should be leveraging the Source machinery which already exists in some way | 05:39 |
| juergbi | yes, that definitely makes sense | 05:39 |
| juergbi | the loading process will get even more interesting ;) | 05:39 |
| tristan | A passing thought... perhaps if we had some kind of... element-pretending-to-be-a-source, kind of passthrough | 05:40 |
| tristan | might allow us to have multiple elements refer to the same source | 05:40 |
| juergbi | maybe | 05:40 |
| tristan | and be able to `bst track` it independently, and have junctions to the same project assert it's the same object | 05:40 |
| tristan | anyway yeah - just a passing thought | 05:40 |
| juergbi | yes, could make sense | 05:41 |
| tristan | juergbi, I have one more stick to throw in your wheel ;-) | 05:50 |
| tristan | It's not enough that elements depending on elements in another project share the same Source details | 05:50 |
| tristan | because project options | 05:50 |
| juergbi | yes, they must match as wel | 05:51 |
| juergbi | *well | 05:51 |
| tristan | so that means, various elements can depend on same project with same revision & options... but can depend on any element from that project they want | 05:52 |
| juergbi | yes | 05:52 |
| tristan | This is somewhat simpler than it might have been with variants | 05:52 |
| tristan | but still, devilish details :) | 05:52 |
| *** anahuelamo has joined #buildstream | 07:12 | |
| gitlab-br-bot | push on buildstream@remove-arches (by Tristan Van Berkom): 20 commits (last: tests/format/optionbool.py: Added boolean option specific test cases) https://gitlab.com/BuildStream/buildstream/commit/110396429bd972536217fa5b1a8603db1a950b22 | 07:26 |
| *** jude has joined #buildstream | 07:28 | |
| tristan | So I think that 11pm is a good time for any meetings that we're going to have | 07:33 |
| tristan | Because some people like to be in BST ... and others like to be in EST right ? | 07:33 |
| tristan | after current conversions (with daylight being saved or lost...) that puts western attendees at 3pm in BST and 10am in EST | 07:35 |
| tristan | perhaps 10pm would be better for me depending on meeting length; but I could live with 11pm on a monthly basis | 07:36 |
| juergbi | fyi: daylight saving ends in Europe in a couple of weeks and in the US a week later | 07:38 |
| tristan | anyway ltu please remind me if it's EST we care about... or if we have people further away | 07:39 |
| tristan | that will put people... hmm in which direction do you go ? | 07:39 |
| juergbi | the difference to you increases by an hour | 07:39 |
| tristan | yeah, but thats a matter of perspective right ? | 07:40 |
| juergbi | so 9 hour difference between UK and Korea | 07:40 |
| tristan | increased by one hour, when we talk about the same day :) | 07:40 |
| juergbi | well, obviously | 07:40 |
| tristan | heh, sorry this stuff always confuses me :) | 07:40 |
| juergbi | it is confusing :) | 07:41 |
| tristan | I mean here anyway we have 3 groups, evenly dispersed around the planet | 07:41 |
| tristan | or rather, resisting the urge to all move to east asia :D | 07:41 |
| juergbi | haha | 07:41 |
| tristan | anyway I guess I'll be late at night, but things will be worsened by including people in french polynesia | 07:42 |
| tristan | or california | 07:42 |
| bochecha | when would those meetings be? (I think I missed the beginning of the conversation) :) | 07:42 |
| tristan | bochecha, started outside of this channel, kind of casually bringing it in here :) | 07:42 |
| tristan | So we're thinking of monthly irc buildstream team meetings | 07:42 |
| tristan | and ltu will be maintaining an agenda and minutes on the wiki | 07:43 |
| tristan | The first order of business is boiling down what we consider to be blockers to 1.0 | 07:43 |
| tristan | So I'd like to invite interested parties to come, and allow for others to add to the agenda if they have things related to the project they want to discuss | 07:44 |
| bochecha | I'll probably lurk :) | 07:45 |
| tristan | I dont know how popular it will turn out, but we used to do this with GTK+ a long time ago and it was pretty productive | 07:45 |
| *** anahuelamo has quit IRC | 07:49 | |
| *** jude has quit IRC | 08:02 | |
| *** unittheory has joined #buildstream | 08:07 | |
| *** jude has joined #buildstream | 08:17 | |
| *** jonathanmaw has joined #buildstream | 08:35 | |
| tristan | ltu, ... we said any day that is not friday or monday is good for persia right ? | 08:38 |
| *** tlater has joined #buildstream | 08:46 | |
| *** ssam2 has joined #buildstream | 09:11 | |
| ltu | tristan, currently we don't have any users further west that EST | 09:24 |
| ltu | not that i know of as least | 09:24 |
| ltu | tristan, yeah tues and thurs are the best days i think | 09:25 |
| tristan | ltu, get the email ? | 09:26 |
| * tlater can still reproduce #98 with commits just before the cross platform merge | 09:26 | |
| tristan | Anyway I sent the announcement a little while ago | 09:26 |
| tristan | looking at finishing the rest of the next email.... | 09:27 |
| tristan | tlater, sigh | 09:27 |
| tlater | Afaik I couldn't have accidentally rebased old commits either, so it's probably not a regression. Even if it was possible, well, those commits have been lost to the aeons. | 09:28 |
| tristan | tlater, this was a regression due to file moves in the branch fwiw: https://gitlab.com/BuildStream/buildstream/merge_requests/101 | 09:30 |
| tristan | in case you were unaware | 09:30 |
| tristan | I'm pretty sure anyway | 09:30 |
| tristan | so it was at least a good idea I think to have you look at what _sandboxbwrap.py was before the merge and after | 09:31 |
| tlater | tristan: That one is quite possible, since the artifact cache thing was renamed. | 09:31 |
| tlater | I had a thorough look at sandboxbwrap.py though, and I can't see any changes that would relate to this | 09:31 |
| tristan | thats what I mean yeah, didnt sandbox get renamed too ? | 09:31 |
| tristan | Ah | 09:31 |
| tristan | Ok | 09:31 |
| tristan | Good :) | 09:31 |
| tristan | wanted to make sure because of that anyway | 09:31 |
| tlater | Yeah, I understand :) | 09:33 |
| tristan | hmmm weird... https://gitlab.com/gitlab-org/gitlab-ce/issues/38900 is not a bug | 09:38 |
| tristan | ssam2, wanna explain to me how that works ? | 09:39 |
| ssam2 | it's a checkbox that updates the description | 09:39 |
| ssam2 | i think that's all there is to it | 09:39 |
| * tristan confused, if https://gitlab.com/BuildStream/buildstream/issues/101 is associated to anything called a "task list" or what | 09:39 | |
| ssam2 | i hope not | 09:39 |
| ssam2 | i thought that was just self contained in the issue ... | 09:40 |
| tristan | yeah, the guy says "a task list has been created in the issue" | 09:40 |
| tristan | which, I guess is in the issue | 09:40 |
| tristan | weird, maybe theres some freaky thing about referring to specific tasks in merge requests which automatically update the bug too ? | 09:40 |
| ssam2 | i just saw the checkbox button and thought it looked cool | 09:41 |
| tristan | anyway - hopefully we just dont care | 09:41 |
| tristan | haha | 09:41 |
| tristan | Yeah no worry | 09:41 |
| tlater | tristan: Should I attempt to find the "right" way to solve #98? | 09:44 |
| tristan | tlater, I wouldnt go there that fast really, it's quite possible also that "making a fully functional terminal" will not magically fix this | 09:46 |
| tristan | tlater, rather... what exactly is the undesirable thing that is happening again ? Something terminates under bwrap and the subprocess fails to terminate and join of it's own accord ? | 09:47 |
| tlater | Yup | 09:47 |
| tlater | That subprocess then becomes a zombie if the user goes C-c again | 09:48 |
| *** jude has quit IRC | 09:48 | |
| tristan | right... | 10:01 |
| tristan | tlater, I think we might try... something like `bwrap --die-with-parent` arg, that's a pretty recent addition to bwrap... which I'm not sure would solve the problem | 10:03 |
| tlater | tristan: Isn't the problem that the python subprocess doesn't die with bwrap? | 10:03 |
| tlater | Rather than the other way around | 10:03 |
| tristan | tlater, or... we might try a less sandboxed thing for `bst shell` at least in interim, like not passing --unshare-pid ? | 10:04 |
| tristan | tlater, yeah except I dont know which parent bwrap is talking about | 10:04 |
| tristan | heh | 10:04 |
| tristan | the launcher of it ? the child it creates ? | 10:04 |
| tlater | That... Is a good point | 10:04 |
| * tlater will try these :) | 10:04 | |
| tristan | I guess it's desirable to unshare things in a `bst shell`, but... it has to be a weaker sandbox anyway than a real build sandbox | 10:05 |
| tristan | because it's primary purpose is for testing things, and you wont be able to launch any graphics app or communicate over stdin/stdout if it's a restrictive sandbox | 10:06 |
| tlater | Would it be worth it to attempt using the evil 'shell' argument to Popen? | 10:06 |
| tristan | So... I think it's safe to say that, we can first drop a bit of the bwrap intensity, and look at finer grained control in the future if that is every really desireable | 10:06 |
| tristan | (if the case is that dropping a bit of the sandbox intensity does get us passed this problem) | 10:07 |
| tristan | ummm, you mean the "shell" argument, actually launches whatever you are calling in the host shell ? | 10:08 |
| tristan | That sounds utterly awful | 10:08 |
| tristan | but hey, I mean if you're going to start "trying things", it doesnt hurt at all to know if that works :) | 10:09 |
| tlater | I suppose, yeah, if it does anything useful there can be some discussion later :) | 10:09 |
| *** jude has joined #buildstream | 10:12 | |
| tlater | tristan: Hm, interestingly I can't reproduce this running the bwrap functions outside of buildstream. | 10:22 |
| tlater | In this case the parent process simply receives the C-c | 10:22 |
| tlater | Is there anything strange buildstream does about C-c? | 10:22 |
| *** jude_ has joined #buildstream | 10:26 | |
| *** jude has quit IRC | 10:27 | |
| tlater | Alright, so the problem seems entirely unrelated to bwrap - no matter what command I use the same thing happens. | 10:51 |
| tlater | Replacing the argv with `tr -dc [:print:]` (as a long running process) in interactive shells results in the same behavior. | 10:52 |
| * tlater solved it \o/ | 10:55 | |
| tlater | process.communicate() raises a KeyboardInterrupt that isn't caught, which subsequently causes buildstream not to clean up all its processes. | 10:56 |
| tlater | Just catching that and calling terminate_bwrap() solves #98 :) | 10:57 |
| gitlab-br-bot | buildstream: Tristan Maat created branch 98-ctrl-c-doesn-t-properly-kill-a-non-interactive-shell | 10:58 |
| tristan | Aha! | 11:00 |
| tristan | That actually makes sense too | 11:00 |
| tristan | tlater, so... in the case that you launch a shell... and press ^C... then buildstream is guaranteed to not handle it ? | 11:00 |
| tlater | Currently, yes | 11:01 |
| tristan | Because we just ignore it ? | 11:01 |
| tlater | Yup | 11:01 |
| tristan | Ok - please make sure the ignoring has a nice comment with it (without ever referring to bug numbers in source code comments please)... | 11:02 |
| tristan | And I think that comment should mention that buildstream will receive the ^C as well as the sub process, because of intentionally sharing the session group | 11:02 |
| *** jude_ has quit IRC | 11:04 | |
| *** jude_ has joined #buildstream | 11:05 | |
| gitlab-br-bot | push on buildstream@98-ctrl-c-doesn-t-properly-kill-a-non-interactive-shell (by Tristan Maat): 1 commit (last: Fix keyboardinterrupts caused by subprocesses) https://gitlab.com/BuildStream/buildstream/commit/2618d056171fcd5dc6d640e790ed5edac9c89e52 | 11:18 |
| * tlater added this to each process.communicate() call to be safe | 11:20 | |
| *** bochecha_ has joined #buildstream | 11:21 | |
| * tlater also intentionally avoids "Fixes #<issue_number>" due to the GitLab issue :( | 11:22 | |
| *** bochecha has quit IRC | 11:23 | |
| *** bochecha_ is now known as bochecha | 11:23 | |
| gitlab-br-bot | buildstream: merge request (98-ctrl-c-doesn-t-properly-kill-a-non-interactive-shell->master: Fix keyboardinterrupts caused by subprocesses) #106 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/106 | 11:28 |
| tristan | myeah, I dont like that issue | 11:32 |
| tristan | They should just make that only work in merge request descriptions, that would be better | 11:33 |
| jonathanmaw | hmm, it seems the problem I was having with the external plugins getting monstrously confused was caused by installing the package using `pip3 install --user -e .`. Without -e, it fails for much more sensible reasons (that appear to be dpkg_build related, not plugin loading related) | 11:53 |
| tristan | tlater, is it worth documenting this detail ^^^ ? | 11:54 |
| tristan | maybe | 11:54 |
| tristan | Or, is it a bug that we dont support pip modules from a linked egg ? | 11:55 |
| tristan | (probably wrong terminology I'm using) | 11:55 |
| tristan | from what I recall the `-e` is like, a .egg symlink to the git checkout or smth | 11:56 |
| *** bochecha has quit IRC | 12:04 | |
| *** bochecha has joined #buildstream | 12:04 | |
| tristan | Random thought: How hard would it be, if we wanted to implement least-recently-used artifact expiration on an artifact server; without doing the full on refactor of having a canonical URL for push/pull ? | 12:08 |
| tristan | I think, we just need a more aware HTTP[s] server; an ability to know what ref was pulled from ostree over http | 12:08 |
| tristan | if we have that, it's enough to monitor lru | 12:08 |
| ssam2 | that sounds fiddly though | 12:12 |
| ssam2 | i think we'd be disliked by sysadmins if we mandated a specific http server, for starters | 12:12 |
| ssam2 | and i think LRU is only a solution for certain use cases anyway | 12:13 |
| tristan | ssam2, I'm thinking GNOME here actually and continuous build servers | 12:14 |
| tristan | We *can* zap the whole thing every once and a while, and see how that goes | 12:14 |
| tristan | However having something building every commit, makes it very likely that nobody has to ever build WebKit | 12:14 |
| tlater | ^^^ I'd say it's a bug, there should be a way to make the error messages more sensible. | 12:15 |
| tristan | That is, without following a specific "tracked" branch | 12:15 |
| tristan | tlater, regarding plugins ? | 12:15 |
| ssam2 | for GNOME continuous, oldest commit date should be enough to do cache expiry | 12:15 |
| ssam2 | which ostree already supports with the `ostree prune` command | 12:15 |
| tlater | yup, sorry, was lunching | 12:15 |
| tristan | tlater, please file that bug with your view on how it should work | 12:15 |
| tristan | no worry | 12:15 |
| tristan | ssam2, I'm not talking "GNOME Continuous" yet... lets not get ahead of ourselves :D | 12:16 |
| tristan | just, having a build server that constantly builds and results in populating an artifact share | 12:16 |
| ssam2 | same applies to any continuous build server | 12:16 |
| * ssam2 may be missing the purpose of this discussion | 12:16 | |
| tristan | ostree supports this 'prune' thing yes | 12:17 |
| tristan | I think what it does is only keeps the latest of a branch | 12:17 |
| tristan | something like that | 12:17 |
| tristan | ssam2, but we dont ever have more than one commit on a branch | 12:17 |
| ssam2 | I'm thinking of `ostree prune --keep-younger-than=DATE` | 12:17 |
| tristan | ah | 12:17 |
| tristan | I guess that might be plausible, although it's not really LRU | 12:17 |
| tristan | at all | 12:18 |
| ssam2 | it's not, but LRU looks hard | 12:18 |
| tristan | I guess punt this until we see how things behave, and hope we have some fat ass SSDs | 12:18 |
| tristan | I suppose that fixing it so that we have some central protocol that can talk tarball as well as ostree while storing to ostree, and use canonical push/pull urls... will look something like git protocol and/or git-over-https-or-ssh | 12:20 |
| * tristan is probably around 95% clueless as to how that is implemented with git | 12:20 | |
| tlater | Ugh, my MR CI fails due to time outs :/ | 12:26 |
| gitlab-br-bot | buildstream: issue #110 ("Stacktrace when loading plugin installed in 'develop' mode") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/110 | 12:44 |
| tlater | tristan: I could actually take that issue immediately, I think #98 should be resolved once the CI decides to take less than 60 minutes | 12:45 |
| tlater | Unless there are other more pressing issues? | 12:46 |
| tristan | tlater, I'm falling behind on reviews I intended to do today due to ... lots of concentration on this email, and various other's I've written today | 12:46 |
| tristan | ... that, and the guilty pleasure of implementing (!) directives this morning :-/ | 12:46 |
| tristan | tlater, ummm, sure it looks quite simple | 12:47 |
| tristan | and you're the one who knows it best | 12:47 |
| tristan | was just mentioning that a bug should be filed so it doesnt go wandering off the radar | 12:47 |
| * tlater is just looking for things to fill time atm :) | 12:48 | |
| tristan | general policy: If it aint on the buglist... it never happend | 12:48 |
| ssam2 | tristan, actually that informs what i'm currently doing, which is writing feature proposals ... | 13:22 |
| ssam2 | i feel like the mailing list is a better place to send those because we can have threaded discussions | 13:22 |
| ssam2 | should i open a tracking bug for each that links to the ml discussion ? | 13:23 |
| ssam2 | or, just discuss everything in gitlab issues ? | 13:23 |
| tristan | ssam2, Mailing list for serious feature proposals please | 13:24 |
| ssam2 | good :-) | 13:24 |
| persia | Maybe open a tracking bug once discussion reaches consensus? | 13:25 |
| tristan | its not really contradictory depending how you look at it, feature proposals are also not something that decidedly "happened", until they've been discussed | 13:25 |
| persia | tristan: Can we have the policy be: if it ain't on the mailing list or the bug list, it never happened? | 13:25 |
| tristan | And absolutely | 13:25 |
| persia | Where somehting on the mailing list only "happened" in the sense that information was posted about it (which might not mean much) | 13:25 |
| tristan | As persia says, once discussed, they *must* go on the bug tracking | 13:25 |
| * persia likes that use of "must" :) | 13:26 | |
| tristan | Yes | 13:26 |
| tristan | Put another way: I dont think any amount of resources or work has to be spent on anything, unless it's on the list | 13:26 |
| tristan | And I cant be held responsible for myself, putting everything on the list :D | 13:27 |
| tristan | s/for/by | 13:27 |
| tristan | gah | 13:27 |
| tristan | anyway you get the gist - there are current ongoing exceptions to that policy; but those are definitely erroneous | 13:28 |
| *** tristan has quit IRC | 13:33 | |
| * tlater is struggling to reproduce the exact behavior jonathanmaw saw | 13:33 | |
| tlater | No combination of missing packages/plugins/developer mode is giving me that particular error | 13:34 |
| tlater | Nevermind, I just had to wait for it to finish running, whoops | 13:39 |
| *** jonathanmaw has quit IRC | 13:56 | |
| *** jonathanmaw has joined #buildstream | 13:56 | |
| *** tristan has joined #buildstream | 14:02 | |
| * tlater still can't reproduce it outside the test case | 14:06 | |
| * tlater is very weirded out now | 14:07 | |
| * tlater can't even catch the exception that is thrown :( | 14:14 | |
| tristan | tlater, jonathanmaw is one of those | 14:15 |
| tristan | we're lucky to have him | 14:15 |
| tristan | I had a roommate that was like that for some years | 14:16 |
| tristan | Somehow can reproduce the weirdest bugs, always happens to them | 14:16 |
| tristan | :) | 14:16 |
| tristan | said friend actually ended up getting hired more than once... to restructure a QA department and tell them how to work | 14:17 |
| jonathanmaw | unfortunately, I'm getting unreliable bugs now :/ when I got that sorted, building a dpkg_build element from buildstream-tests started complaining that there wasn't a /buildstream/build/debian/test/DEBIAN/control file. that's now mysteriously gone away, in favour of complaining that /buildstream/install is missing :/ | 14:17 |
| * tristan recalls in contrast... someone who was our "integrator" at the jukebox place... exactly the opposite | 14:19 | |
| tristan | You follow the instructions by the letter, every step of the way, always goes wrong | 14:19 |
| tristan | When he does it, it magically works | 14:19 |
| tristan | Sometimes, there is a magic touch, and no amount of sense can be derived from any of it :D | 14:19 |
| tlater | I wonder which gift is more useful? | 14:19 |
| tristan | I tend to prefer the ability to make things break | 14:20 |
| tlater | Should we have only those people operate computers or have only jonathanmaws? | 14:20 |
| tristan | Magic fingers can mean that you need that guy around or else things start breaking | 14:20 |
| tristan | with a jonathanmaw, we have a chance at identifying things before others do :D | 14:20 |
| persia | everything just working is more useful for a feature developer. Everything always breaking is more useful for an integration developer. | 14:37 |
| *** jude_ has quit IRC | 15:04 | |
| *** jude_ has joined #buildstream | 15:10 | |
| *** jude_ has quit IRC | 15:13 | |
| *** bochecha_ has joined #buildstream | 15:18 | |
| *** bochecha has quit IRC | 15:20 | |
| *** bochecha_ is now known as bochecha | 15:20 | |
| * tlater can't even step through with pdb :( | 15:23 | |
| tlater | I... what? | 15:43 |
| tlater | It succeeds now | 15:43 |
| tlater | I changed nothing | 15:43 |
| jonathanmaw | looks like it wasn't changing to installing without -e that fixed it. I'm not sure what fixed it, because I lost the point where it actually started working, and it stayed working because of caching. | 15:45 |
| jonathanmaw | so I'm back to where I was this morning :S | 15:45 |
| tlater | Aww | 15:45 |
| tristan | I think it must be pip | 15:45 |
| tristan | It probably has a special case for October 12th | 15:45 |
| tristan | Knowing pip, ya know | 15:46 |
| tlater | It's still 11 here | 15:46 |
| tristan | catch up man ! | 15:46 |
| tlater | Could you try it? Maybe it works on 12th! | 15:46 |
| tristan | get with the times | 15:46 |
| tristan | :) | 15:46 |
| * jonathanmaw sets out to push what he's currently got. | 15:47 | |
| jjardon[m] | Hi, I have started this wiki page to use BuildStream to build GNOME (replacing jhbuild): https://wiki.gnome.org/jjardon/BuildSystemComponentBuildstream Can anyone help completing it? | 15:49 |
| tristan | jjardon[m], I'll reply the email tomorrow but certainly having a page like that is something to do before rolling it out beyond internal release-team trying it out | 15:56 |
| tristan | jjardon[m], I expect links to change, or become valid, during the creation of such a wiki page | 15:57 |
| tristan | i.e. we'll want to sort out what is the official artifact server uris and suchlike | 15:57 |
| tristan | but that doesnt stop us from creating a "getting started" kind of /BuildingGnome wiki page | 15:58 |
| jjardon[m] | I think we should not care about about the artifact server for now | 15:58 |
| jjardon[m] | we do not have it in jhbuild, so we are not regressing | 15:58 |
| tristan | I think we should, because it's a low effort | 15:58 |
| tristan | its just machine resource really | 15:58 |
| tristan | and as the project declares it, it doesnt cost users mucking about setting it up either | 15:59 |
| tristan | eh, so in that case we wouldnt need to refer to it in a getting started guide anyway | 15:59 |
| tristan | jjardon[m], we did, I think get an intel machine for contributing to a GNOME artifact cache | 16:00 |
| tristan | didnt start setting up builds on it yet | 16:00 |
| tristan | and I think one of the 8 arm sleds with 100GB SSD is good enough for an artifact cache | 16:01 |
| tristan | if we had *cough* GPG signing of course | 16:01 |
| tristan | then we could use http and downloading artifacts should be better | 16:02 |
| jjardon[m] | tristan: I only said we do not need any artifact server to replace jhbuild because jhbuild doesnt have any at the moment | 16:02 |
| * tristan wonders if it would actually be a worse experience using https for artifact downloads, than building locally | 16:02 | |
| jjardon[m] | No reason to delay the switch waiting for that to be done | 16:02 |
| tristan | jjardon[m], Yeah I know what you mean :) | 16:02 |
| jjardon[m] | :) | 16:03 |
| tristan | I would just enjoy giving the artifact cache more testing | 16:03 |
| tristan | and seeing how it works with a sizable project like GNOME, excites me a bit :) | 16:03 |
| ssam2 | hmm.. but who would be allowed to push artifacts? | 16:03 |
| ssam2 | or would we also set up a jhbuild auto builder ? | 16:04 |
| tristan | ssam2, we have an intel machine I wanted to start continuously crunching bst build --track on | 16:04 |
| ssam2 | ah right | 16:04 |
| ssam2 | that would be amazing if we could get it set up, people would definitely then be sold on how much better this is than jhbuild ;-) | 16:04 |
| tristan | honestly though, I dont know how solid that resource is | 16:05 |
| ssam2 | i think if everything builds from scratch the initial experience will be worse than jhbuild, as there will be extra time spent pulling the base SDK | 16:05 |
| tristan | Also, I wonder if ostree artifact downloads over https rather than http, will be slow enough to be more of a piss off than building most modules | 16:05 |
| tristan | we havent benchmarked enough to know | 16:05 |
| ssam2 | ostree.baserock.org is https | 16:05 |
| ssam2 | it works fine | 16:05 |
| tristan | When you are in the UK | 16:06 |
| ssam2 | actually it doesn't work fine because the certs expired | 16:06 |
| tristan | with http I should have a better experience | 16:06 |
| tristan | because caches and such might mean I dont have to always go 350ms all the way to you guys | 16:06 |
| *** anahuelamo has joined #buildstream | 16:13 | |
| * tlater has managed to reproduce issue w/o test suite! Turns out it's probably something about cache configuration | 16:15 | |
| * tlater has no idea how that could affect anything, but we'll see | 16:15 | |
| * tristan sits down to enjoy the finale of "Blood Drive" | 16:17 | |
| tlater | Alright | 16:33 |
| tlater | So... | 16:33 |
| tlater | The issue seems to be that the plugin is installed with python2 | 16:33 |
| tlater | Rather than python3 | 16:33 |
| ssam2 | lol | 16:33 |
| tlater | \o/ | 16:33 |
| tlater | https://stackoverflow.com/questions/489269/python-super-raises-typeerror | 16:33 |
| tlater | I'm not even sure why it is python2 | 16:34 |
| tlater | But this is the *exact* issue | 16:34 |
| tlater | No, wait, slightly different | 16:36 |
| tlater | Damnit | 16:36 |
| * tlater gives up for today | 16:43 | |
| *** tlater has quit IRC | 16:43 | |
| *** anahuelamo has quit IRC | 16:50 | |
| *** adds68 has quit IRC | 17:00 | |
| *** jonathanmaw has quit IRC | 17:03 | |
| *** adds68 has joined #buildstream | 17:16 | |
| *** ssam2 has quit IRC | 17:42 | |
| *** bochecha has quit IRC | 17:47 | |
| *** givascu has joined #buildstream | 18:16 | |
| *** givascu has quit IRC | 18:21 | |
| *** adds68 has quit IRC | 19:24 | |
| *** tristan has quit IRC | 21:33 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!