| *** noah has quit IRC | 00:55 | |
| *** mcatanzaro has joined #buildstream | 01:16 | |
| *** noah has joined #buildstream | 01:34 | |
| *** noah has quit IRC | 01:35 | |
| *** noah has joined #buildstream | 01:37 | |
| *** noah has quit IRC | 01:50 | |
| *** xjuan has quit IRC | 01:54 | |
| *** mcatanzaro has quit IRC | 03:34 | |
| kailueke[m] | Since questions on running binaries came up on desktop-devel I wonder what the contents of ~/.cache/buildstream/build/core-.../root/ are - simply hardlinks or does BuildStream/OSTree make advanced use of btrfs? But they do contain the last build artifacts, right? Then maybe if bst shell is too confined for certain applications, a manual bwrap command could help? | 04:14 |
|---|---|---|
| *** noisecell has joined #buildstream | 07:29 | |
| *** valentind has joined #buildstream | 08:43 | |
| *** jonathanmaw has joined #buildstream | 09:14 | |
| csoriano | hey all, trying to make my first build with bst I get this error just at the start: | 09:34 |
| csoriano | https://www.irccloud.com/pastebin/aXNWbbS2/ | 09:34 |
| juergbi | hi csoriano, i'm looking into this right now | 09:57 |
| juergbi | buildstream 1.0 should work fine. and strict builds should also work in master | 09:57 |
| juergbi | however, non-strict builds in master trigger an issue | 09:58 |
| csoriano | juergbi: ah thanks, I'm just following the instructions at https://wiki.gnome.org/Newcomers/BuildSystemComponentBst | 09:58 |
| juergbi | yes, bad timing that we have this issue right now | 10:01 |
| juergbi | i expect a fix today | 10:01 |
| juergbi | i'm wondering whether we should generally recommend buildstream master as we do now, or whether the latest stable branch or release would make more sense | 10:02 |
| * tlater figures that stable is stable because we recommend it | 10:02 | |
| juergbi | yes, i think it would make sense to also recommend this in the instructions | 10:03 |
| juergbi | but we currently don't | 10:03 |
| juergbi | https://buildstream.gitlab.io/buildstream/install.html | 10:03 |
| tlater | I guess we forgot about that in the excitement of finally releasing 1.0 | 10:04 |
| *** valentind has quit IRC | 10:05 | |
| * tlater amends that while waiting for his CI to finish | 10:05 | |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 10:06 |
| *** ssam2 has joined #buildstream | 10:07 | |
| *** tristan has joined #buildstream | 10:07 | |
| ltu | should the current master be considered our unstable branch? | 10:10 |
| ssam2 | yes | 10:10 |
| tlater | I assume we would like to recommend 1.0.1 currently, and update that whenever we make a new bugfix release? | 10:13 |
| juergbi | we could also recommend bst-1.0 branch | 10:13 |
| juergbi | and leave releases to packagers | 10:13 |
| juergbi | not sure what tristan prefers | 10:13 |
| persia | I think recommendation of stable branch is better than recommendation of stable artifact, as stable branch can receive bugfixes. | 10:14 |
| juergbi | i agree | 10:17 |
| * tlater waits for the final word from tristan, but now also prefers the above | 10:20 | |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 10:21 |
| juergbi | ssam2: i've added comments to your MR and pushed an alternative branch juerg/202 | 10:23 |
| ssam2 | ok, great | 10:23 |
| ssam2 | let me give it a test | 10:23 |
| juergbi | we definitely need to improve test coverage for the combination of non-strict builds and artifact caches | 10:23 |
| ssam2 | yeah, I guess it's the presence of remote artifacts that meant we weren't covered here | 10:24 |
| juergbi | yes, non-strict builds on their own should be tested ok already, afaik | 10:24 |
| juergbi | looking at this closer, i want to change the queue API a bit | 10:24 |
| csoriano | btw, not sure if here is where I should mention this. I realized https://wiki.gnome.org/Newcomers/BuildSystemComponentBst is now the canonical way to develop system components at GNOME, but some of them cannot be build. Should this page still point to JHBuild? | 10:32 |
| csoriano | or should there be a list of components that needs to use JHBuild to work properly and point to JHBuild for those in that same page?> | 10:32 |
| ssam2 | can't be built, or can be built but not tested effectively ? | 10:33 |
| csoriano | developed/tested | 10:33 |
| csoriano | I wrote 'build' by mistake | 10:34 |
| ssam2 | understood | 10:34 |
| ssam2 | we should add at least a note pointing out that we don't yet have a good way of testing certain components | 10:34 |
| csoriano | ssam2: that note is there already. There is no written solution though | 10:35 |
| ssam2 | ah, ok | 10:35 |
| ssam2 | yeah maybe link to jhbuild then | 10:35 |
| ssam2 | i guess it's possible newcomers will want to try out a new gnome-shell, in particular | 10:35 |
| csoriano | there should be a list of components that would need this, hopefully, developers should add them while they find out | 10:35 |
| csoriano | yes, and gnome-boxes | 10:36 |
| csoriano | and gnome-usage | 10:36 |
| csoriano | those are going to be part of GSoC | 10:36 |
| ssam2 | right | 10:36 |
| csoriano | and this is now already | 10:36 |
| csoriano | just a few details that couldbe improved: | 10:41 |
| csoriano | https://buildstream.gitlab.io/buildstream/install.html#adjust-path -> write down the command that actually does that | 10:41 |
| csoriano | https://buildstream.gitlab.io/buildstream/install.html#user-installation-with-pip -> use different heading format to separate the "download packages" and the "installation phase" | 10:42 |
| ssam2 | we could, the issue is not everyone uses Bash | 10:42 |
| ssam2 | but we could give an example command, indeed | 10:42 |
| csoriano | it was confusing if I should continue once I completed the fedora part | 10:42 |
| csoriano | ssam2: yeah, I assume most people use bash. Those who doesn't probably aren't newcomers or begginers in Linux world | 10:43 |
| ssam2 | i'm not sure how we could fix that with headings | 10:43 |
| csoriano | I'm thinking this from a perpestive of someone trying to develop for first time with bst | 10:43 |
| ssam2 | in general i don't like those instructions at all | 10:43 |
| csoriano | :D | 10:43 |
| ssam2 | we are hoping soon to generate .rpm and .deb packages as part of our CI | 10:43 |
| csoriano | alright, then that would be it | 10:44 |
| csoriano | for https://wiki.gnome.org/Newcomers/BuildSystemComponentBst I can modify a few things myself, specially at FOSDEM where we will switch the newcomers guide to GitLab workflow, and will take a look at the components side too in preparation for GSoC, etc. | 10:44 |
| ssam2 | i just spotted that it also says 'we have some instructions below which can get you started using BuildStream within a Docker container.' which are also on a diferent page :-) | 10:45 |
| ssam2 | ok, cool | 10:45 |
| ssam2 | most of us our at FOSDEM, so we could discuss in person at some point | 10:45 |
| csoriano | does someone from here will be at FOSDEM? | 10:45 |
| ssam2 | *are at FOSDEM | 10:45 |
| csoriano | amazing | 10:45 |
| ssam2 | tristan is doing a talk on Sunday lunchtime | 10:45 |
| csoriano | we can meet for a bit with bastianilso for this part | 10:45 |
| ssam2 | sure | 10:45 |
| ssam2 | juergbi, are you going to do an MR for your #202 fix ? | 10:48 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 10:49 |
| ssam2 | juergbi, it seems to work for me, only issue I spotted was the comment which says 'Update __cached in non-strict builds now that the weak cache key is available' which is now inaccurate (as we are waiting for the strict key now before updating __Cached) | 10:50 |
| juergbi | ssam2: thanks. yes, i'll open an MR | 10:51 |
| juergbi | right, will improve the comment | 10:51 |
| juergbi | i'm changing the Queue API a bit to make things clearer and ensure we also solve similar potential issues in other queues | 10:51 |
| tlater | Hrm, I've learned that setting TMPDIR to anything that isn't /tmp breaks a lot of applications | 10:55 |
| nexus | Do we have a prefered wat of concatinating strings? | 10:57 |
| nexus | way* | 10:57 |
| juergbi | nexus: we normally use format() | 10:58 |
| juergbi | if that makes sense in the context | 10:58 |
| tlater | nexus: For path strings you probably want os.path.join though | 10:58 |
| nexus | sorry, i should have been clearer, i want to store it in a variable, not print it | 10:59 |
| nexus | and thanks tlater | 10:59 |
| jmac | ssam2: I've been looking into your comment on my patch !248 - it seems Python don't specify a return value for unhandled exception, so anything our test harness tests is a bit of a fiction | 10:59 |
| ssam2 | right | 11:00 |
| ssam2 | i imagine there's no way to test that then | 11:00 |
| jmac | Which probably means I need to write a test that parses stderr or something | 11:00 |
| ssam2 | also a possibility | 11:00 |
| ssam2 | I wonder if we could support all existing jhbuild use cases with current buildstream | 11:04 |
| nexus | ssam2: i remember you bringing up the clarity of the "closing non-existing workspace" error message. Do you remember what the outcome of that discussion was? | 11:04 |
| ssam2 | nexus, what does the gitlab issue say ? | 11:05 |
| ssam2 | if we built everything in gnome-build-meta with prefix of /opt/gnome instead of /usr/local ... | 11:05 |
| ssam2 | you could `bst checkout core/gnome-shell.bst /opt/gnome` | 11:05 |
| ssam2 | and then all the existing hacks would work | 11:05 |
| ssam2 | i guess i can open an issue on the gnome-build-meta repo to discuss this | 11:06 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 11:06 |
| nexus | ssam2: It was brought up, but not continued as it was the existing error message at the time. I wasn't sure if we had discussed it further outside of the ticket, or if you had any further thoughts on it | 11:06 |
| gitlab-br-bot | buildstream: issue #203 ("BuildStream crashes if the dependency tree is too deep") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/203 | 11:06 |
| ssam2 | nexus, what's the issue number ? | 11:10 |
| nexus | https://gitlab.com/BuildStream/buildstream/issues/182 | 11:10 |
| nexus | i just came across the error message again when doing other things and thoguht it was a bit unclear, so i brought it back up for discussion | 11:11 |
| ssam2 | the current error is ok for me | 11:14 |
| ssam2 | the error from your MR is, anyway | 11:15 |
| ssam2 | which is not yet mergedf | 11:15 |
| ssam2 | *merged | 11:15 |
| *** cs_shadow has joined #buildstream | 11:15 | |
| nexus | ` Workspace '[element] - 0' is currently not defined` | 11:15 |
| nexus | that one? | 11:15 |
| ssam2 | that's the one in master, yeah | 11:16 |
| ssam2 | the one proposed in the current version of your MR is better as it says "does not exist" | 11:16 |
| nexus | ah yes, i was more refering to the ` - 0' ` bit | 11:16 |
| nexus | i have no idea what that means | 11:16 |
| ssam2 | right, that's because elements can have multiple sources | 11:17 |
| nexus | ah i see | 11:17 |
| ssam2 | and workspaces are per source | 11:17 |
| ssam2 | it's not very obvious though | 11:17 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 11:18 |
| nexus | where can i look, to see if a workspace was actually removed after running `close`? | 11:20 |
| tlater | nexus: in .bst/<something> | 11:21 |
| tlater | Or with `bst workspace list`, I think? | 11:21 |
| tlater | By default the workspace directory will still be there, to remove that you need to specify --rm, iirc | 11:21 |
| *** ernestask has joined #buildstream | 11:36 | |
| gitlab-br-bot | buildstream: merge request (sam/fix-202->master: Fix breakage when running in no-strict mode with --track-all and an existing remote cache) #250 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/250 | 11:49 |
| gitlab-br-bot | buildstream: merge request (sam/install-tweaks->master: doc/source/install.rst: Clarify install instructions) #252 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/252 | 11:53 |
| ssam2 | csoriano, here are some minor tweaks to the install docs: https://gitlab.com/BuildStream/buildstream/merge_requests/252 | 11:54 |
| csoriano | ssam2: cool. I'm happy if for us we will have a rpm/deb package in the distros, we can just say to install that | 11:55 |
| ssam2 | yeah, that will be much better. not sure of exactly when it'll be done, though | 11:56 |
| *** tristan has quit IRC | 12:10 | |
| *** tristan has joined #buildstream | 12:11 | |
| *** noah has joined #buildstream | 12:23 | |
| gitlab-br-bot | buildstream: merge request (juerg/202->master: Element state handling fixes) #253 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/253 | 12:36 |
| *** tristan has quit IRC | 13:21 | |
| jmac | The way the test process works (calling buildstream._frontend.main rather than subprocess) is causing a lot of problems testing this exception handler - is there any reason I shouldn't just execute `bst` as a subprocess in a test? | 13:55 |
| *** xjuan has joined #buildstream | 13:58 | |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 14:02 |
| gitlab-br-bot | buildstream: merge request (version-read-no-pkg_res->master: WIP: Get version number w/o pkg_resources) #234 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/234 | 14:05 |
| tlater | jmac: If there's a specific need for your test to do so, it should be fine. It would be nice if you could stick to the helpers though, what's the problem with the handler? | 14:06 |
| * tlater has to step away for a bit, will see if I can help untangle this a bit later - maybe we need a different helper for this kind of case | 14:08 | |
| jmac | I haven't investigated thoroughly yet, but I suspect the execption handling in invoke() is having problems since I overrode the global exception handler | 14:09 |
| jmac | Also, it lies about the exit code (but since Python doesn't appear to specify the code, I can't rely on it anyway) | 14:09 |
| tlater | jmac: Could you link me to the branch? I'm curious why this happens, I think the exception handler in invoke() should be able to catch any exception | 14:31 |
| tlater | Except if of course you override python's global exception handler, which sounds like an ugly hack... | 14:31 |
| jmac | Sure, https://gitlab.com/BuildStream/buildstream/merge_requests/248 is the MR | 14:38 |
| jmac | I can't push the actual branch to gitlab as I don't have rights | 14:38 |
| tlater | Right, clone is fine :) | 14:38 |
| tlater | Yeah, I see the issue... | 14:42 |
| tlater | jmac: Honestly, I think this is a very specific edge case. It's probably fine to avoid the usual path and use a subprocess specifically for this test. | 14:43 |
| * tlater does wonder if there's a better way to handle this though | 14:43 | |
| jmac | I'm open to suggestions | 14:44 |
| tlater | Could you parse the stderr for the 'BUG' message? | 14:44 |
| jmac | That's my plan at the moment. As it stands, if you run it through the test harness, that BUG message doesn't appear. | 14:44 |
| tlater | Ah, right, I do expect that to work | 14:45 |
| *** jude has quit IRC | 14:47 | |
| tlater | jmac: Have you tried looking for those messages in a non-interactive buildstream run? | 14:48 |
| tlater | Some UI features are disabled, it's possible they are ignored through sheer bad luck - the tests run buildstream non-interactively afaik | 14:48 |
| jmac | tlater: Yes, it still prints if you run with --no-interactive from the command line | 14:49 |
| *** HollowRiddler has joined #buildstream | 14:50 | |
| * tlater sits down and figures out how to clone jmac's repo | 14:52 | |
| jmac | I think you can clone git@gitlab.com:jmacarthur/buildstream.git | 14:53 |
| tlater | I added it as a remote | 14:53 |
| tlater | Man, I wish git could manage multiple directories | 14:53 |
| tlater | Would make running multiple branches so much easier | 14:53 |
| tlater | (It probably can and I'm too ignorant to read up on it) | 14:54 |
| tlater | jmac: If I disable pytest's capturing, I see an error traceback instead of a BUG message | 14:56 |
| * tlater wonders if pytest is screwing with the exception handler | 14:57 | |
| jmac | Possibly | 14:57 |
| tlater | jmac: It looks like your exception handler simply isn't called in the test harness for some reason | 15:05 |
| tlater | Yeah, manually feeding the exception to the exception handler results in the expected message | 15:08 |
| * tlater suspects pytest overrides sys.__excepthook_ | 15:10 | |
| tlater | And somehow forces writing to that | 15:10 |
| jmac | That would make sense | 15:11 |
| * tlater attempts overriding an absolutely-do-not-touch variable | 15:11 | |
| tlater | Doesn't work, unsurprisingly | 15:14 |
| tlater | Hrm, it's probably somewhere in pytest's exception handling code | 15:22 |
| * tlater can't find what hides it, sorry :| | 15:22 | |
| jmac | It's no problem, I think subprocess will work fine | 15:23 |
| jmac | Thanks for looking into it | 15:23 |
| tlater | nw | 15:23 |
| gitlab-br-bot | buildstream: merge request (version-read-no-pkg_res->master: Get version number w/o pkg_resources) #234 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/234 | 15:24 |
| gitlab-br-bot | buildstream: merge request (monkey-patch-setuptools->master: WIP: Modify the generated CLI script by monkey patching) #231 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/231 | 15:25 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 15:25 |
| *** mcatanzaro has joined #buildstream | 15:26 | |
| *** jude has joined #buildstream | 15:45 | |
| *** noisecell has quit IRC | 15:52 | |
| *** adds68 has joined #buildstream | 16:09 | |
| gitlab-br-bot | buildstream: merge request (juerg/202->master: Element state handling fixes) #253 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/253 | 16:24 |
| gitlab-br-bot | buildstream: merge request (issue-191_relative_workspaces->master: WIP: Patch for issue #191 support relative workspaces) #251 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/251 | 16:46 |
| gitlab-br-bot | buildstream: merge request (jmac/exception-hook->master: WIP: Add a handler for otherwise unhandled exceptions in the main BuildStream app) #248 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/248 | 17:00 |
| jmac | Can you change the branch on a gitlab merge request? | 17:04 |
| ssam2 | i think not | 17:05 |
| ssam2 | which is annoying | 17:05 |
| jmac | Do you prefer to force push or open a new MR? | 17:06 |
| ssam2 | if the old stuff doesn't matter, force push | 17:07 |
| ssam2 | the UI handles that reasonably well | 17:08 |
| jmac | OK. | 17:08 |
| gitlab-br-bot | buildstream: merge request (jmac/exception-hook->master: WIP: Add a handler for otherwise unhandled exceptions in the main BuildStream app) #248 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/248 | 17:09 |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: WIP: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 17:10 |
| jmac | ^ changed the test on this so it fails on existing code | 17:10 |
| gitlab-br-bot | buildstream: issue #202 ("Build of gnome-build-meta.git is broken") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/202 | 17:15 |
| gitlab-br-bot | buildstream: merge request (juerg/202->master: Element state handling fixes) #253 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/253 | 17:15 |
| *** HollowRiddler has quit IRC | 17:17 | |
| *** jonathanmaw has quit IRC | 17:29 | |
| tlater | Hrm | 17:35 |
| * tlater found an odd bug - it seems I need to pause and continue twice to get my child process to continue after I ^C | 17:36 | |
| tlater | But only if I do it too quickly? | 17:36 |
| ssam2 | weird | 17:37 |
| tlater | It happens pretty consistently, fun to play with | 17:38 |
| * tlater proposes it as a feature | 17:38 | |
| *** valentind has joined #buildstream | 17:43 | |
| *** ssam2 has quit IRC | 17:46 | |
| *** ssam2 has joined #buildstream | 17:49 | |
| *** HollowRiddler has joined #buildstream | 17:50 | |
| *** tristan has joined #buildstream | 17:50 | |
| *** HollowRiddler has quit IRC | 17:54 | |
| gitlab-br-bot | buildstream: merge request (175-refactor-integration-tests->master: Resolve "Refactor integration tests") #233 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/233 | 17:54 |
| *** HollowRiddler has joined #buildstream | 17:55 | |
| *** ssam2 has quit IRC | 17:59 | |
| *** HollowRiddler has quit IRC | 18:13 | |
| *** tristan has quit IRC | 18:21 | |
| *** jude has quit IRC | 18:27 | |
| *** HollowRiddler has joined #buildstream | 19:17 | |
| *** cs_shadow has quit IRC | 20:28 | |
| *** ernestask has quit IRC | 20:54 | |
| *** noah has quit IRC | 20:54 | |
| *** tristan has joined #buildstream | 21:22 | |
| *** HollowRiddler has quit IRC | 22:07 | |
| *** HollowRiddler has joined #buildstream | 22:07 | |
| *** valentind has quit IRC | 22:25 | |
| *** noah has joined #buildstream | 22:29 | |
| *** noah has quit IRC | 22:32 | |
| *** noah has joined #buildstream | 22:34 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!