| *** juergbi has quit IRC | 00:12 | |
| *** mcatanzaro has quit IRC | 03:21 | |
| *** tristan has joined #buildstream | 06:23 | |
| persia | tristan: I'm watching a presentation on Kubernetes, and the speaker mentioned that they currently have a 2-week window in each quarterly release before feature freeze. Features to be included in the next release need to be submitted and agreed prior to the close of that window in order to be included. For a biannual release cycle, that would map to about a month. | 07:43 |
|---|---|---|
| persia | The idea being that features proposed early in the cycle would be expected to be able to mature by end of cycle. I don't know if that would be a useful tool, but figured I'd share in case you liked it as a model. | 07:44 |
| *** juergbi has joined #buildstream | 07:52 | |
| * paulsherwood wonders when 1.0 is | 07:59 | |
| persia | paulsherwood: When it's ready. We've agreed that it isn't part of the GNOME release, but there are still a couple outstanding blockers. | 08:01 |
| paulsherwood | ack | 08:01 |
| persia | https://gitlab.com/BuildStream/buildstream/issues?label_name[]=Blocker is the current outstanding list of blockers | 08:01 |
| persia | From the meeting yesterday (http://meetbot.gnome.org/buildstream-meetings/2017/buildstream-meetings.2017-11-14-14.04.html), I had the impression that these were close to being resolved. | 08:02 |
| persia | Full meeting log at http://meetbot.gnome.org/buildstream-meetings/2017/buildstream-meetings.2017-11-14-14.04.log.html if you want more context | 08:02 |
| paulsherwood | thanks, persia | 08:06 |
| tristan | persia, I think our feature freeze is one month, two weeks seems a bit tight no ? | 08:19 |
| * tristan checks the schedule | 08:19 | |
| tristan | paulsherwood, the idea is to follow the GNOME release schedule, but to ignore some of the freezes which dont really apply to us (i.e. string freeze is pointless unless we implement i18n first) | 08:20 |
| tristan | That, and to skip the next release in February/March, since we're late to the table anyway; relaxing the first cycle a bit | 08:20 |
| tristan | persia, We can make exceptions for special cases, it's not set in stone - but indeed our feature freeze -> code freeze period is 1 month; https://wiki.gnome.org/Schedule | 08:22 |
| tristan | GNOME will have feature freeze Feb 5 until March 5 | 08:22 |
| * tristan is in the midst of buildstream smoke testing the first GNOME dev release to be made with buildstream; 3.27.2 | 08:23 | |
| tristan | its a bit scary ;-) | 08:23 |
| tristan | nexus, I said I wouldnt be available to "talk" today, and it's true; but if you're around and you want to get started on the docs stuff you were going to do... I have some suggestions | 08:24 |
| tristan | nexus, first of all; we are most in need of better guidance on the user side | 08:25 |
| tristan | nexus, the first project I think jonathan started on was more focused on creating docs about how to author projects, I think that is a separate activity | 08:25 |
| tristan | nexus, so I *think* a good place to start; would be human readable breakdown of stuff in: http://buildstream.gitlab.io/buildstream/invoking.html#invoking | 08:26 |
| tristan | nexus, that is currently generated by: https://gitlab.com/BuildStream/buildstream/blob/master/doc/source/invoking.rst | 08:27 |
| tristan | (click the little </> sign to view the page source instead of the rendered rst) | 08:28 |
| *** jude has joined #buildstream | 08:28 | |
| tristan | nexus, note that it does :show-nested:, I suggest that we remove :show-nested: from there, and refer to the autogenerated docs for each command separately; allowing us to add some free form text and explanations of what can be done | 08:29 |
| tristan | However, that might be backwards | 08:29 |
| tristan | nexus, a different approach is to drill down from what kind of activity the user wants to achieve; and refer to the commands from a separate page | 08:29 |
| tristan | like "How do I develop my module", think about the questions csoriano was asking the other day, the meaning of tracking sources; how developer workspaces work, etc | 08:30 |
| tristan | nexus, it's probably extremely early in the morning wherever you are... but just leaving this text for you when you get a chance to read it; as I had a moment to scribble it down whilst things build in the background | 08:31 |
| tristan | ... and WebKit starts to build ... | 09:07 |
| gitlab-br-bot | buildstream: issue #155 ("Stack trace encountered when staging a tarball") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/155 | 09:22 |
| *** bethw has joined #buildstream | 09:26 | |
| *** nexus has left #buildstream | 09:40 | |
| *** nexus has joined #buildstream | 09:41 | |
| csoriano | hey, what' the name of gtk4? | 09:41 |
| csoriano | well, just gtk master | 09:41 |
| csoriano | I'm trying bst track --deps all --except base.bst core-deps/gtk+.bst | 09:43 |
| csoriano | but it says module not found | 09:43 |
| tristan | It doesnt appear to be in the conversions | 09:43 |
| tristan | That would be because the conversions currently need to take targets | 09:44 |
| tristan | So the targets currently used are the meta ones | 09:44 |
| tristan | A fix would be to include GTK+ master in meta-gnome-core, or; to add some things to https://gitlab.com/BuildStream/jhbuild2bst/blob/master/autoconvert/autoconvert.sh#L213 | 09:45 |
| csoriano | argh.... | 09:45 |
| csoriano | I was convinced I could use buildstream so show gtk+ in a presentation I do in 1 hour :D | 09:45 |
| tristan | In fact, just adding them to that file, will cause the next conversion (every 10 minutes I think), will cause it to appear | 09:46 |
| tristan | Well | 09:47 |
| tristan | csoriano, what do you need to build, just GTK+ ? or something that depends on the new GTK+ that is already in the modulesets ? | 09:47 |
| csoriano | tristan: just gtk+, so show the recorder basically | 09:47 |
| *** anahuelamo has joined #buildstream | 09:47 | |
| csoriano | the GktInspector recorder | 09:47 |
| tristan | You could easily `cp elements/core-deps/gtk+-3.bst elements/core-deps/gtk+.bst` and edit the file | 09:48 |
| tristan | just make it `track: master` | 09:48 |
| tristan | and do `bst track core-deps/gtk+.bst` and `bst build core-deps/gtk+.bst` | 09:49 |
| tristan | Assuming it doesnt depend on anything new | 09:49 |
| *** bethw has quit IRC | 09:49 | |
| tristan | Ok some few issues with first time building the dang tarballs | 09:58 |
| tristan | https://gitlab.com/BuildStream/buildstream/issues/155 probably the worst of it | 09:58 |
| tristan | I can work around for this release, the rest I'll have to inspect and see; but probably just the fact that we always build from git, and now that we try the tarballs, many things are just totally different | 09:59 |
| *** ssam2 has joined #buildstream | 09:59 | |
| *** tpollard has joined #buildstream | 10:03 | |
| *** jonathanmaw has joined #buildstream | 10:05 | |
| *** givascu has joined #buildstream | 10:14 | |
| jonathanmaw | tristan: is https://gitlab.com/BuildStream/buildstream/merge_requests/127 fixed to your satisfaction? | 10:15 |
| tristan | jonathanmaw, no time right now | 10:20 |
| jonathanmaw | tristan: okie doke. I'll focus on the errors in overlaps stuff for now, then. | 10:21 |
| *** bethw has joined #buildstream | 10:28 | |
| tlater | I think the base-system element in the current gnome-modulesets might bebroken. | 11:06 |
| ssam2 | jonathanmaw, did you get anywhere with https://gitlab.com/BuildStream/buildstream/merge_requests/125 ? | 11:08 |
| tristan | tlater, why would you think that ? | 11:09 |
| jonathanmaw | ssam2: I haven't picked it up | 11:09 |
| tlater | tristan: Just pulling a fresh copy it gave me the 'no sources' error - it looks like buildstream doesn't resolve the conditional before it checks that | 11:09 |
| ssam2 | jonathanmaw, so you didn't start work on it in the end ? | 11:09 |
| tlater | But my buildstream may be outdated, not sure what this docker image runs | 11:10 |
| ssam2 | the docker image has a really old version of buildstream | 11:10 |
| jonathanmaw | ssam2: no. tbh I don't remember opening the merge request. maybe I mis-clicked. | 11:10 |
| tlater | Ah, right | 11:10 |
| * tlater attemtps with master | 11:10 | |
| ssam2 | in CI we manually install a specific (and newer) version | 11:10 |
| ssam2 | jonathanmaw, ah ok | 11:11 |
| tlater | Yeah, nevermind, the current version of buildstream handles it just fine | 11:12 |
| ssam2 | hmm, the Docker image was supposed to auto update though | 11:12 |
| bethw | ssam2, jonathanmaw, is one of you able to pick up MR!125? From what I understand, it's necessary for 1.0, but please correct me if I'm wrong | 11:13 |
| jonathanmaw | bethw: the attached issue is a blocker, so that's my understanding, too | 11:13 |
| * tlater can also pick it up once I get around to finishing the two I'm on right now - I wrote the external plugin support in the first place | 11:14 | |
| ssam2 | jonathanmaw, could you look at that before starting errors on overlaps? better to fix bugs before doing new features | 11:15 |
| ssam2 | review of https://gitlab.com/BuildStream/bst-external/merge_requests/7 would also be appreciated | 11:15 |
| jonathanmaw | ssam2: yep, errors on overlaps isn't a blocker, AIUI | 11:15 |
| bethw | jonathanmaw, that would be great, thanks | 11:16 |
| bethw | And cheers ssam2 | 11:16 |
| ssam2 | It turns out the Docker image is being updated perfectly fine | 11:17 |
| ssam2 | but for some reason I thought `docker run` checked for updates, when it actually doesn't | 11:18 |
| ssam2 | so tlater you just need to `docker pull buildstream/buildstream-fedora` | 11:18 |
| ssam2 | I should note this in the bst documentation too | 11:18 |
| * tlater forgot that docker didn't do that, ta ssam2 | 11:18 | |
| tristan | fwiw: GNOME 3.27.2 released: https://mail.gnome.org/archives/desktop-devel-list/2017-November/msg00059.html | 11:22 |
| tristan | Now with snapshot project: https://download.gnome.org/teams/releng/3.27.2/gnome-3.27.2.tgz | 11:22 |
| tristan | So interestingly; that tarball gives you an exact project state from which GNOME was released from BuildStream | 11:23 |
| * tristan will write up how he did this release, and what needs taking care of, in a blog post tomorrow I guess | 11:23 | |
| tristan | Also, since this release: https://gitlab.com/BuildStream/buildstream/issues/155 | 11:24 |
| tristan | The above is a pretty serious bug | 11:24 |
| tristan | It's not technically blocker to 1.0, but it's a blocker for GNOME to seriously use BuildStream - And I worry that it is in fact a symptom of python's subpar tarball handling | 11:25 |
| tristan | It may mean we need to override some of python's tar internals; because fixing that upstream and waiting years for a fix to trickle down is not reasonable | 11:25 |
| ssam2 | wow, i didn't realise you were actually doing that release :-) | 11:26 |
| tristan | Aha ! | 11:26 |
| tristan | You thought I was all talk and no walk ! | 11:26 |
| tristan | :) | 11:26 |
| ssam2 | i didn't even hear much talk :-) | 11:26 |
| tlater | The gnome-release ninjas strike again! | 11:27 |
| tristan | well, there was admittedly only this: https://mail.gnome.org/archives/desktop-devel-list/2017-November/msg00032.html | 11:27 |
| tristan | ssam2, you would have heard more talk, if people were actively resisting the change | 11:27 |
| ssam2 | true ! | 11:28 |
| tristan | But, looks like we're on track :D | 11:28 |
| ssam2 | building that snapshot project seems to happily pulling everything from the cache for me | 11:28 |
| inigomartinez | congrats tristan for the successful .2 release :) | 11:35 |
| tristan | inigomartinez, :) | 11:37 |
| tristan | thanks ! | 11:37 |
| tristan | Its my first; I was a bit worried but luckily https://wiki.gnome.org/ReleasePlanning/MakingARelease didnt present issues which take hours to figure out :D | 11:37 |
| tristan | what I did not do though, is run around and fix upstream things in modules | 11:38 |
| tristan | I dont think really the current approach is reasonable for that work, which is why I feel like we should be moving to releasing from git | 11:39 |
| tristan | Either that, or we need to be running some CI on the tarball conversion yada yada thing | 11:39 |
| tristan | cause you just never know until the last moment what's going to happen; building from released tarballs is different | 11:40 |
| tlater | ssam2: This is the issue I found when googling the error I get on my machine: https://github.com/projectatomic/bubblewrap/issues/134 | 11:55 |
| tlater | It's possible your machine is a bit different because it has selinux enabled | 11:55 |
| tlater | Running the suggested test: `bwrap --ro-bind / / --unshare-user --unshare-pid --proc /proc /bin/bash` *does* result in a permission denied inside docker | 11:57 |
| tlater | But there is no trace of a /proc/xen or anything | 11:57 |
| ssam2 | I get: bash: /dev/null: Permission denied | 11:57 |
| * tlater also doesn't know what /proc/xen even is supposed to be | 11:57 | |
| ssam2 | that's irrelevant here | 11:57 |
| tlater | ssam2: That's outside the container | 11:58 |
| tlater | Run that command in a docker container | 11:58 |
| ssam2 | no, this is in a container | 11:58 |
| tlater | How did you launch that? | 11:58 |
| ssam2 | I started it on that VM with: sudo docker run --privileged --volume /home/fedora/src/baserock/definitions/.cache/:/root/.cache --volume /home/fedora/src/:/src -i -t docker.io/buildstream/buildstream-fedora /bin/bash | 11:58 |
| tlater | Huh | 11:59 |
| tlater | That works | 11:59 |
| tlater | Ah, got it | 12:01 |
| tlater | bst-here doesn't run with --privileged | 12:01 |
| ssam2 | oh | 12:01 |
| tlater | But just with --cap-add SYS_ADMIN | 12:01 |
| ssam2 | hmmm, right | 12:01 |
| tlater | Looks like that isn't enough, perhaps anymore | 12:01 |
| ssam2 | i wonder how we work out what else is needed | 12:03 |
| ssam2 | `man capabilities` is the first stop i guess | 12:04 |
| tlater | CAP_SYS_CHROOT? | 12:07 |
| ssam2 | oh, is this with the UNIX backend ? | 12:07 |
| ssam2 | perhaps the issue is we only tested bst-here with the normal backend! | 12:07 |
| tlater | No, this is the normal backend | 12:08 |
| ssam2 | ah | 12:08 |
| tlater | But maybe bubblewrap requires that for some reason? | 12:08 |
| tlater | Actually, I suppose the question is what bubblewrap needs | 12:08 |
| ssam2 | true. its code is pretty simple | 12:08 |
| *** tristan has quit IRC | 12:16 | |
| tlater | bubblewrap seems to need these: (CAP_SYS_ADMIN) | (CAP_SYS_CHROOT) | (CAP_NET_ADMIN) | (CAP_SETUID) | (CAP_SETGID) | 12:17 |
| ssam2 | wow, so how did this ever work | 12:18 |
| ssam2 | i'm sure i ran builds through bst-here. but i am really bad at testing stuff thoroughly, so maybe i didn't | 12:18 |
| * tlater tries setting those caps and runs the command again | 12:19 | |
| tlater | On selinux it also needs to mount the user directory with :Z | 12:21 |
| tlater | Nope, still not enough :| | 12:23 |
| ssam2 | maybe selinux is the issue ? | 12:42 |
| ssam2 | i've double checked if bst-here used to have the --privileged flag, but it never did | 12:42 |
| *** anahuelamo has quit IRC | 12:47 | |
| tlater | ssam2: selinux isn't the issue, same thing happens on my local machine which definitely doesn't have it enabled | 13:20 |
| *** jonathanmaw has quit IRC | 13:32 | |
| *** jonathanmaw has joined #buildstream | 13:35 | |
| *** jonathanmaw has quit IRC | 14:01 | |
| *** jude has quit IRC | 14:02 | |
| *** jude has joined #buildstream | 14:04 | |
| gitlab-br-bot | push on buildstream@except_intersections (by Tristan Maat): 7 commits (last: Refactor, remove some unused imports) https://gitlab.com/BuildStream/buildstream/commit/cc6e09ce63c7576bd3f258515946e38a945903f4 | 14:09 |
| gitlab-br-bot | push on buildstream@131-behavior-of-except-argument-is-frustrating-and-confusing (by Tristan Maat): 6 commits (last: Refactor, remove some unused imports) https://gitlab.com/BuildStream/buildstream/commit/cc6e09ce63c7576bd3f258515946e38a945903f4 | 14:09 |
| gitlab-br-bot | buildstream: merge request (131-behavior-of-except-argument-is-frustrating-and-confusing->master: WIP: Resolve "Behavior of --except argument is frustrating and confusing") #147 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/147 | 14:09 |
| gitlab-br-bot | push on buildstream@131-behavior-of-except-argument-is-frustrating-and-confusing (by Tristan Maat): 1 commit (last: Disable coverage temporarily) https://gitlab.com/BuildStream/buildstream/commit/8879768a05d4c8ed213c1b0527f6b376d26e2f9c | 14:33 |
| gitlab-br-bot | buildstream: merge request (131-behavior-of-except-argument-is-frustrating-and-confusing->master: WIP: Resolve "Behavior of --except argument is frustrating and confusing") #147 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/147 | 14:33 |
| tlater | Well, it turns out that the segfault is caused by coverage | 15:04 |
| tlater | No wonder I can't reproduce it | 15:05 |
| * tlater wonders if we are misusing coverage | 15:05 | |
| gitlab-br-bot | push on buildstream@131-behavior-of-except-argument-is-frustrating-and-confusing (by Tristan Maat): 1 commit (last: Maybe this fixes it) https://gitlab.com/BuildStream/buildstream/commit/69faaec4756c9c4715d7a23e8e85caa8826b7a0c | 15:12 |
| gitlab-br-bot | buildstream: merge request (131-behavior-of-except-argument-is-frustrating-and-confusing->master: WIP: Resolve "Behavior of --except argument is frustrating and confusing") #147 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/147 | 15:12 |
| gitlab-br-bot | push on buildstream@131-behavior-of-except-argument-is-frustrating-and-confusing (by Tristan Maat): 1 commit (last: Maybe this fixes it) https://gitlab.com/BuildStream/buildstream/commit/777dc820dcbe187d8c9b3edb708c09a943080c5c | 15:17 |
| gitlab-br-bot | buildstream: merge request (131-behavior-of-except-argument-is-frustrating-and-confusing->master: WIP: Resolve "Behavior of --except argument is frustrating and confusing") #147 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/147 | 15:17 |
| *** tristan has joined #buildstream | 15:31 | |
| * tlater puts cache management commands on his christmas wish list | 15:40 | |
| nexus | tlater: what do you want to manage about your cache? | 15:42 |
| tlater | nexus: I'd like to remove individual artifacts without needing to find my way through ostree - only really useful to buildstream developers though ;) | 15:43 |
| tristan | like this https://gitlab.com/BuildStream/buildstream/issues/135 ? | 15:43 |
| * nexus is working on that issue ;-; | 15:43 | |
| tlater | Yeah, that would already be pretty handy :) | 15:43 |
| *** mcatanzaro has joined #buildstream | 15:58 | |
| *** semanticdesign has joined #buildstream | 16:00 | |
| gitlab-br-bot | push on buildstream@131-behavior-of-except-argument-is-frustrating-and-confusing (by Tristan Maat): 1 commit (last: Well, maybe if we just run the cmake-test...) https://gitlab.com/BuildStream/buildstream/commit/23604f38f6f70dc514852a92d83ddbe4b0a3d4d0 | 16:00 |
| gitlab-br-bot | buildstream: merge request (131-behavior-of-except-argument-is-frustrating-and-confusing->master: WIP: Resolve "Behavior of --except argument is frustrating and confusing") #147 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/147 | 16:00 |
| tlater | So, coverage segfaults... But only in the GitLab CI | 16:28 |
| tlater | Locally I can't get it to crash, even when running the exact same test :| | 16:28 |
| ssam2 | bah | 16:31 |
| ssam2 | out of memory ? pure guess | 16:32 |
| ssam2 | probably wouldn't lead to a segfault, either | 16:32 |
| tlater | ssam2: It continues running other tests just fine after | 16:32 |
| ssam2 | we've never seen this outside your branch, right? so we should be able to work out what change has caused this, at least | 16:32 |
| tlater | I suppose, yeah. I just have no idea what would effect this, since it wasn't even related to the test that causes it | 16:33 |
| tlater | Hm, I guess I can start rolling back commits | 16:33 |
| gitlab-br-bot | push on buildstream@test_coverage_segfault (by Tristan Maat): 4 commits (last: main.py: Fix app initialization) https://gitlab.com/BuildStream/buildstream/commit/60307b9b2096eeb5a3f221af2f58e38b7d7e9153 | 16:39 |
| *** jonathanmaw has joined #buildstream | 16:44 | |
| gitlab-br-bot | push on buildstream@test_coverage_segfault (by Tristan Maat): 1 commit (last: Well, maybe if we just run the cmake-test...) https://gitlab.com/BuildStream/buildstream/commit/70f2e355731fe955857c36f9e30b43c6bff2ee2a | 16:46 |
| gitlab-br-bot | buildstream: merge request (provenance_fmt->master: WIP: De-dup brackets around provenance in error messages) #134 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/134 | 16:47 |
| gitlab-br-bot | push on buildstream@test_coverage_segfault (by Tristan Maat): 1 commit (last: Well, maybe if we just run the cmake-test...) https://gitlab.com/BuildStream/buildstream/commit/4c4b18902bb5faeb6289f3b7dbab74fcc3d87bb6 | 16:48 |
| gitlab-br-bot | push on buildstream@test_coverage_segfault (by Tristan Maat): 1 commit (last: Well, maybe if we just run the cmake-test...) https://gitlab.com/BuildStream/buildstream/commit/858a0c6ab639f59e6be2a53cf0442163682684b3 | 16:48 |
| gitlab-br-bot | push on buildstream@test_coverage_segfault (by Tristan Maat): 1 commit (last: Well, maybe if we just run the cmake-test...) https://gitlab.com/BuildStream/buildstream/commit/1f868ba4b2a14652a25ffed9eb4a9d39afd87720 | 17:04 |
| *** jude has quit IRC | 17:18 | |
| gitlab-br-bot | push on buildstream@test_coverage_segfault (by Tristan Maat): 1 commit (last: Fix tests) https://gitlab.com/BuildStream/buildstream/commit/76730dcb20ceff348f9f629b1aa29825eb6775ee | 17:20 |
| ssam2 | would anyone miss these push notifications if i disabled them, and just had notifications for merge requests and issue updates ? | 17:21 |
| * tlater definitely wouldn't | 17:21 | |
| tlater | Although I suppose I really should be doing this on a separate repo | 17:23 |
| tristan | ssam2, what I really always wanted, was notifications of push to *master* | 17:24 |
| ssam2 | oh yeah. seems we can either have all or nothing | 17:24 |
| tristan | ssam2, couldnt it take like < 5 min if we just added hard code to the script to ignore pushes to not master ? | 17:25 |
| tristan | without messing with the config or anything ? | 17:25 |
| tristan | if someone is like, already there... | 17:25 |
| ssam2 | the script serves a few different projects though | 17:25 |
| ssam2 | https://gitlab.com/palvarez89/gitlab-to-irc | 17:25 |
| ssam2 | maybe we could add a push-master condition | 17:25 |
| tristan | none of which enable the notifications for pushes, except buildstream | 17:25 |
| ssam2 | right | 17:26 |
| tristan | well, if it's too troublesome, just disable it | 17:27 |
| tristan | I'm also annoyed, but would like to have them for master | 17:27 |
| *** tpollard has quit IRC | 17:27 | |
| ssam2 | ok | 17:28 |
| ssam2 | i can file a bug :-) | 17:28 |
| tristan | heh | 17:28 |
| tristan | that might be better than a hack, I think ironfoot wants to upstream some of the changes to the original project | 17:29 |
| tristan | which was the most featurefull gitlab bot I could find at the time | 17:29 |
| tristan | but there are a lot of other ones, I dont think anyone is really taking gitlab irc bots to the serious level of considering them "project worthy" | 17:29 |
| tristan | just rather an afternoon hack that joe random publishes on their gitlab | 17:30 |
| ironfoot | I started looking at it, but lack of time :S | 17:32 |
| ironfoot | also, javascript :) | 17:33 |
| ironfoot | I still want to finish it | 17:33 |
| tlater | This commit somehow causes coverage to crash: https://gitlab.com/tlater/buildstream/commit/6af10543455272c28da12d8538b4eed4b3d25cf2 | 17:34 |
| tlater | Now just to find what actually causes it... | 17:34 |
| ssam2 | heh, nothing jumps out of that to say "crash me!!" | 17:38 |
| tlater | It's a fluke in coverage that gets triggered specifically while building something with cmake after this change | 17:39 |
| * tlater has no clue how any of those things are related x) | 17:40 | |
| *** bethw has quit IRC | 17:53 | |
| tristan | ironfoot, javascript is ridiculously just like python, they are both very lispy | 17:54 |
| *** jonathanmaw has quit IRC | 18:02 | |
| csoriano | tristan: I'll try that, doesn't sounds too complex | 18:05 |
| csoriano | (too late for the presentation though, jhbuild failed and I didn't read your message in time :( ) | 18:05 |
| csoriano | in any case, congrats for the 3.27.2 release 👏 | 18:06 |
| gitlab-br-bot | buildstream: issue #156 ("`bst-here` capabilities are too narrow") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/156 | 18:08 |
| *** jude has joined #buildstream | 18:22 | |
| *** valentind has joined #buildstream | 18:34 | |
| *** ssam2 has quit IRC | 18:49 | |
| gitlab-br-bot | buildstream: merge request (compose-integration-delete->master: Handle removed files from integration in compose plugin) #142 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/142 | 21:17 |
| *** givascu has quit IRC | 21:25 | |
| *** valentind has quit IRC | 22:00 | |
| *** valentind has joined #buildstream | 22:00 | |
| persia | tristan: Apologies for the miscommunication: the period I was talking about was release -> feature proposal freeze, not feature submission freeze -> code freeze. 1 month for the latter seems fine. The other project uses the equivalent of one month for the former as well, as a means to ensure features are well understood when development begins. | 22:26 |
| persia | Actually, thinking about it more, that might be uncomfortable, as sometimes one has a great idea for something that can be implemented safely and quickly, and such a freeze would force delay: it might make more sense for projects that release more often. | 22:26 |
| *** valentind has quit IRC | 22:36 | |
| *** jude has quit IRC | 23:21 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!