| *** alatiera has quit IRC | 00:19 | |
| *** dftxbs3e has quit IRC | 00:26 | |
| gitlab-br-bot | jjardon opened MR !1361 (jjardon/pygobject3-devel->master: .gitlab-ci.yml: ostree plugin depends on ostree/python3-gobject-base) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1361 | 01:16 |
|---|---|---|
| gitlab-br-bot | jjardon closed issue #1035 (overnigth test are failing: failed to import ostree plugin) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1035 | 01:54 |
| gitlab-br-bot | jjardon merged MR !1361 (jjardon/pygobject3-devel->master: .gitlab-ci.yml: ostree plugin depends on ostree/python3-gobject-base) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1361 | 01:55 |
| *** dftxbs3e has joined #buildstream | 02:08 | |
| *** kapip has quit IRC | 03:13 | |
| gitlab-br-bot | jjardon opened issue #1037 (overnigth test are failing: bst2 client is not compatible with bst1 cache server) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1037 | 04:33 |
| *** tristan has quit IRC | 06:11 | |
| *** tristan has joined #buildstream | 06:37 | |
| *** kapip has joined #buildstream | 06:45 | |
| *** bochecha has joined #buildstream | 07:51 | |
| *** tristan has quit IRC | 08:35 | |
| *** raoul has joined #buildstream | 08:38 | |
| laurence | damn, first spam on the list | 08:51 |
| *** tristan has joined #buildstream | 08:56 | |
| *** phil has joined #buildstream | 09:05 | |
| *** jonathanmaw has joined #buildstream | 09:16 | |
| raoul | Updating the architecture docs for artifact/source caches and services, does anyone think it'd be worthwhile adding a section on the CAS? Don't think anywhere explains how that works | 09:16 |
| *** toscalix has joined #buildstream | 09:39 | |
| *** toscalix has quit IRC | 09:40 | |
| *** lachlan has joined #buildstream | 09:42 | |
| *** lachlan has quit IRC | 09:55 | |
| *** lachlan has joined #buildstream | 09:55 | |
| *** lachlan has quit IRC | 10:00 | |
| gitlab-br-bot | raoul.hidalgocharman opened MR !1362 (raoul/1024-artifact-docs->master: Update docs regarding artifact and source caches) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1362 | 10:38 |
| laurence | jennis, I think this MR (https://gitlab.com/BuildStream/buildstream/merge_requests/1344) would close off this ticket (https://gitlab.com/BuildStream/buildstream/issues/943) | 10:41 |
| laurence | sound right ? | 10:41 |
| laurence | just doing some ticket clean up stuff | 10:41 |
| jennis | It would, I'll change the MR description now | 10:41 |
| laurence | thanks | 10:42 |
| jennis | Done | 10:42 |
| *** verdre has joined #buildstream | 10:44 | |
| *** lachlan has joined #buildstream | 10:45 | |
| verdre | Hey, I'm trying to set up buildstream right now and I'm being confused by two websites with documentation: There's docs.buildstream.build and buildstream.gitlab.io/buildstream/ | 10:45 |
| verdre | Which one is the recommended one? | 10:45 |
| verdre | Also, let's get rid of the non-official one please... | 10:46 |
| Kinnison | verdre: the former is the docs for the released version (1.2) whereas the latter is for the current master version | 10:48 |
| Kinnison | We should perhaps make it more clear in the latter case that the docs are for an unreleased dev version | 10:48 |
| verdre | Kinnison: Okay, so the former is recommended, we should make that more clear. Also the docs for the released version should not tell you to checkout master in the instructions :/ | 10:50 |
| Kinnison | I concur | 10:50 |
| *** lachlan has quit IRC | 10:50 | |
| verdre | great! Next issue I'm seeing is this error message when trying to build stuff: Failed to load Source plugin 'git_tag': The 'buildstream-external' distribution was not found and is required by the application | 10:51 |
| raoul | verdre, you need to install plugins in this repo https://gitlab.com/BuildStream/bst-external | 11:04 |
| verdre | raoul: Thanks, would be great if that was also mentioned in the docs. | 11:06 |
| verdre | I should note that I'm coming from jhbuild (to build gnome-shell) hoping for a build system that "just works", so please let's not make the same mistakes jhbuild made. It should be possible to build stuff without having to ask around on IRC | 11:09 |
| benschubert | verdre: BuildStream does work without bst-external. Those are a set of plugins that some projects might want. It's in the doc about plugins :) | 11:10 |
| benschubert | I'm surprised gnome doesn't have docs for them. If you have ideas on how to improve our docs, please post some issues and we'll look into them! | 11:13 |
| verdre | benschubert: Okay, turns out I've just overseen that part in the gnome wiki, sorry... | 11:13 |
| *** ChanServ sets mode: +o tristan | 11:14 | |
| tristan | The right place to document how to build GNOME using BuildStream is: https://wiki.gnome.org/Newcomers/BuildSystemComponent | 11:14 |
| tristan | fwiw | 11:14 |
| tristan | That could probably use some updates | 11:14 |
| benschubert | No worries :) I agree the docs are not ideal, but we need fresh eyes on them, don't hesitate to suggest improvements | 11:14 |
| tristan | Of course BuildStream docs themselves can always be improved :) | 11:14 |
| tristan | Just saying, there should also be a getting started for specifically GNOME (although I'd really like to get to a place where we can just say "Just install BuildStream on your distro, checkout this BuildStream project, and build it, and not have users mess around with external plugin repositories themselves) | 11:15 |
| verdre | tristan: Sadly, all build-related wiki pages could use updates, IMO build instructions belong into each projects readme and ideally there shouldn't be any wiki page | 11:16 |
| *** bochecha_ has joined #buildstream | 11:17 | |
| verdre | Maybe the gnome-shell README should tell you to install buildstream and gnome-build-meta, and gnome-build-meta should bundle bst-external | 11:18 |
| *** bochecha has quit IRC | 11:18 | |
| *** bochecha_ is now known as bochecha | 11:18 | |
| tristan | verdre, I think bst-external should be a submodule indeed, that would bind the specific version of it used to the project using it | 11:19 |
| verdre | yeah, good idea | 11:19 |
| tristan | verdre, anyway for the moment, there is nothing much that gnome-shell wins from instructing people to use BuildStream (it's a bit of an outlier that way I think... using BuildStream implicitly means "not your host", so I'm not sure how running gnome-shell inside a `bst shell` could work) | 11:20 |
| tristan | verdre, BUT... I've just today launched my first image (with much help from abderrahim[m]) which successfully launches gnome-initial-setup through gdm | 11:20 |
| tristan | so, we're getting very close to something very useful for developers | 11:21 |
| tristan | (for developers of core system modules I mean) | 11:21 |
| *** lachlan has joined #buildstream | 11:21 | |
| verdre | So the exact steps would be: Go to docs.buildstream.build/install, git clone --recurse-submodules gnome-build-meta, cd gnome-build-meta, gst build blabla | 11:22 |
| tristan | verdre, right | 11:22 |
| verdre | oh, so you launched the shell inside the sandbox? | 11:23 |
| tristan | verdre, that would also mean that if we add anything new to bst-external, nobody has to care about any upgrades - the project's reference to the git submodule would automatically capture it | 11:23 |
| verdre | exactly, you'd only have to git pull in gnome-build-meta... | 11:24 |
| tristan | verdre, `bst shell` launches a shell in the sandbox (which means not your host, and some holes poked so that you can run graphical apps)... no what I did today was `bst build vm/desktop-vm-image-x86_64.bst` in gnome-build-meta (tristan/gnome-boot branch), and then `bst checkout` of the same element | 11:25 |
| tristan | verdre, giving me a script and an sdk.img, then running the script launches qemu | 11:25 |
| tristan | s/sdk.img/sda.img/ | 11:25 |
| verdre | ohh, so you built the whole stack? That would be to much for my passively cooled laptop :D | 11:26 |
| tristan | verdre, once we get it in CI, most of it will already be on the artifact server | 11:26 |
| verdre | ahh, interesting, I see | 11:27 |
| tristan | verdre, which means that even on a small laptop, you can tweak pretty much anything in the stack | 11:27 |
| tristan | assuming you use `--no-strict` | 11:27 |
| tristan | or the equivalent config option | 11:27 |
| tristan | Which means "don't rebuild reverse dependencies every time something changes" | 11:27 |
| tristan | Then the work you do is (A) Rebuild the one thing you want to change... (B) Wrap up the actual image | 11:28 |
| verdre | and then to develop you'd have to restart qemu though, that wouldn't be very fast | 11:28 |
| tristan | Currently (B) is still pretty expensive | 11:28 |
| verdre | yeah, I can imagine that | 11:28 |
| tristan | I think a next step will be to be able to launch qemu without an image, but directly on the FS | 11:28 |
| abderrahim[m] | tristan: I'm thinking we can speed that up by using guestfish | 11:28 |
| tristan | abderrahim[m], I tried building that waaaaaaaay long ago | 11:29 |
| tristan | abderrahim[m], my plan was to use it to virtual mount the filesystem inside a build sandbox so that we could create images as regular user | 11:30 |
| tristan | but then I ended up just following what the yocto folks did | 11:30 |
| tristan | still sounds interesting this guestfish | 11:30 |
| tristan | havent worked with it much | 11:30 |
| verdre | I always heard the future of shell developement was running mutter nested, any idea if that could work somehow? | 11:32 |
| tristan | I don't have any clue honestly | 11:32 |
| *** lachlan has quit IRC | 11:33 | |
| tristan | verdre, with a BuildStream hat on, I kind of have to be a proponent of "Test your software how it is actually intended to run, and not in tricked up dev environments which differ from a production setting" | 11:33 |
| tristan | verdre, on the other hand, I know we're not quite as close to the quick edit/compile/test cycles that people need | 11:34 |
| verdre | I see your point, but with a developer hat on, it already takes long enough to restart your session to test stuff :) | 11:34 |
| abderrahim[m] | I think nested is actually easier from bst shell | 11:34 |
| tristan | abderrahim[m], It's possible, but then the question arises: How much does your host resemble the stack which is in the sandbox ? | 11:35 |
| tristan | For most graphical applications, it's not such a problem, everything mostly communicates with fairly up to date and standard dbus APIs and such | 11:35 |
| tristan | X sockets, etc | 11:36 |
| abderrahim[m] | nested behaves as another app IIUC | 11:36 |
| *** bochecha_ has joined #buildstream | 11:37 | |
| abderrahim[m] | anyway, will have to test it and see | 11:37 |
| verdre | abderrahim[m]: Yeah, although it's not the greatest way to do testing, for real testing you'd need to start a session using the compiled binaries, I think there's no way around that | 11:39 |
| *** bochecha has quit IRC | 11:39 | |
| *** bochecha_ is now known as bochecha | 11:39 | |
| *** tristan has quit IRC | 11:39 | |
| abderrahim[m] | while you wait for the VM image to be generated :p | 11:42 |
| *** pointswaves has joined #buildstream | 11:45 | |
| *** lachlan has joined #buildstream | 11:47 | |
| *** lachlan has quit IRC | 11:51 | |
| *** lachlan has joined #buildstream | 11:52 | |
| *** lachlan has quit IRC | 12:00 | |
| *** verdre[m]1 has joined #buildstream | 12:03 | |
| *** verdre has quit IRC | 12:03 | |
| *** tristan has joined #buildstream | 12:04 | |
| *** kapip has quit IRC | 12:26 | |
| raoul | Are the runners down or something atm? getting a lot of "ERROR: Preparation failed: exit status 1" | 12:34 |
| benschubert | ^ same problem here. Runners taking long to pick up jobs too | 12:42 |
| gitlab-br-bot | raoul.hidalgocharman opened issue #1038 (Move source cache to proto based service) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1038 | 12:48 |
| *** alatiera has joined #buildstream | 13:09 | |
| *** lachlan has joined #buildstream | 13:10 | |
| aevri | +1 also seeing "ERROR: Preparation failed: exit status 1" | 13:24 |
| *** phildawson_ has joined #buildstream | 13:31 | |
| *** phil has quit IRC | 13:32 | |
| *** lachlan has quit IRC | 13:36 | |
| *** lachlan has joined #buildstream | 13:38 | |
| *** lachlan has quit IRC | 13:42 | |
| WSalmon | juergbi, if i do self.index.keys() in a casbaseddirectory this should give be eqivelent to `ls` in a real directory? and should have all the symlinks etc in it? | 13:52 |
| juergbi | yes | 13:53 |
| WSalmon | thanks | 13:56 |
| *** phildawson_ has quit IRC | 14:01 | |
| *** phildawson_ has joined #buildstream | 14:02 | |
| *** alatiera has quit IRC | 14:09 | |
| *** alatiera has joined #buildstream | 14:10 | |
| *** alatiera has quit IRC | 14:15 | |
| laurence | runners for buildstream CI - valentind, is this you ? | 14:42 |
| laurence | Possibly jjardon, but he may not be awake yet if he's west coast | 14:42 |
| valentind | laurence, some of it | 14:43 |
| valentind | Is something down? | 14:43 |
| jjardon | laurence: I do not maintain buildstream runners anymore for long time; happy to help if needed though | 14:45 |
| laurence | jjardon, ok sorry for the noise | 14:45 |
| laurence | valentind, please see: | 14:45 |
| laurence | <raoul> Are the runners down or something atm? getting a lot of "ERROR: Preparation failed: exit status 1" | 14:45 |
| laurence | Example: | 14:46 |
| laurence | https://gitlab.com/BuildStream/buildstream/-/jobs/221513262 | 14:46 |
| laurence | Running with gitlab-runner 11.11.1 (5a147c92) | 14:46 |
| laurence | on buildstream-bastion a334e492 | 14:46 |
| laurence | ERROR: Preparation failed: exit status 1 | 14:46 |
| laurence | Will be retried in 3s ... | 14:46 |
| laurence | ERROR: Preparation failed: exit status 1 | 14:46 |
| laurence | Will be retried in 3s ... | 14:46 |
| laurence | ERROR: Preparation failed: exit status 1 | 14:46 |
| laurence | Will be retried in 3s ... | 14:46 |
| laurence | ERROR: Job failed (system failure): exit status 1 | 14:46 |
| valentind | laurence, OK, looking at it now. | 14:48 |
| jjardon | Seems to be a problem with docker-machine; "too many files open" | 14:48 |
| valentind | Right. | 14:48 |
| jjardon | valentind: I think you fixed that some time ago? | 14:48 |
| valentind | Did I make it restart now and then? | 14:49 |
| valentind | AH no | 14:49 |
| valentind | There are too many files not deleted. | 14:49 |
| valentind | It was simple | 14:49 |
| laurence | valentind, do we have anyone else who shares this responsibility with you ? if not then let's get that sorted | 14:49 |
| *** lachlan has joined #buildstream | 14:50 | |
| valentind | Many files in /root/.docker/machine/machines | 14:51 |
| jjardon | the DO account has a lot of zombie runner machines; maybe a good idea to remove them | 14:51 |
| laurence | isn't there a infra repo or something? | 14:54 |
| laurence | or maybe a detailed wiki page? | 14:54 |
| *** lachlan has quit IRC | 14:55 | |
| laurence | struggling to locate a repo | 14:55 |
| valentind | I am deleting manually the rogue files. | 14:57 |
| valentind | It is a bug in gitlab-ci-runner | 14:57 |
| valentind | I can make a timer to cleanup automatically every day | 14:58 |
| valentind | But it does not cleanup the zombie machines on DO. | 14:58 |
| jjardon | Looking to the bill, maybe is better to have a couple of big permanent machines instead using docker-machine and risk having a lot of zombies around for a long time | 15:01 |
| valentind | jjardon, I noticed that some docker-machine have status "stopped". | 15:03 |
| *** lachlan has joined #buildstream | 15:03 | |
| valentind | Maybe I can try to delete those automatically in the cleanup script I am making. | 15:03 |
| jjardon | Or delete any runner- machine older than 2 days; no job is that long and it should not stay for that long | 15:05 |
| valentind | Right. Maybe we should use the DO api. | 15:05 |
| *** lachlan has quit IRC | 15:07 | |
| valentind | I have created "cleanup-docker-machine.timer" to remove the old files on docker-machine | 15:10 |
| jjardon | valentind: maybe worth to propose that upstream? | 15:11 |
| valentind | I think upstream should just fix it. | 15:11 |
| valentind | Instead of working around it. | 15:11 |
| valentind | But I am not going to spend more time on that. | 15:11 |
| jjardon | Not sure is gitlab-runner fault or docker-machine though | 15:12 |
| jjardon | Sure | 15:12 |
| valentind | Both | 15:12 |
| valentind | docker-machine first should not keep all the files opened. It should close them once it has read them. | 15:13 |
| valentind | Though, maybe gitlab-runner is OK. | 15:14 |
| valentind | Docker-machine for sure is broken. | 15:14 |
| valentind | It seems it cannot parse its own files. | 15:14 |
| valentind | I will destroy the containers by hand now. | 15:14 |
| valentind | But we should look at making some script that does it automatically. | 15:15 |
| *** lachlan has joined #buildstream | 15:15 | |
| laurence | valentind, are you the only person looking after this? | 15:17 |
| *** lachlan has quit IRC | 15:19 | |
| valentind | laurence, I do not know. | 15:20 |
| laurence | we should get you some assistance, for sure. a single point of failure is never good | 15:27 |
| laurence | leave it with me | 15:27 |
| *** Kinnison has quit IRC | 15:36 | |
| *** pointswaves has quit IRC | 15:38 | |
| *** pointswaves has joined #buildstream | 15:38 | |
| *** pointswaves has quit IRC | 15:42 | |
| *** Kinnison has joined #buildstream | 15:46 | |
| gitlab-br-bot | jennis opened (was WIP) MR !1344 (jennis/push_based_pipeline->master: Push based pipeline) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1344 | 15:54 |
| *** bochecha has quit IRC | 15:55 | |
| gitlab-br-bot | BenjaminSchubert opened MR !1363 (bschubert/iterative-loader->master: Make the loading process iterative) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1363 | 16:01 |
| benschubert | tristan: I know we talked about making the loading iterative to remove the problems with recursions. ^ is a first step to that (a few other places are concerned, but this one was blowing up when I am adding Cython, so fixing that first) | 16:02 |
| *** alatiera has joined #buildstream | 16:03 | |
| *** phil has joined #buildstream | 16:05 | |
| *** phildawson_ has quit IRC | 16:06 | |
| *** lachlan has joined #buildstream | 16:17 | |
| *** ChanServ sets mode: +o tristan | 16:20 | |
| tristan | benschubert, looks straight forward to me, I think it would be nice to clean up the first pass, second pass; have better control on the junction loads etc (i.e. would be nice to parallelize fetching of multiple junctions when running the scheduler to fetch those junctions)... but this MR looks like a step in the right direction anyway | 16:20 |
| *** lachlan has quit IRC | 16:21 | |
| benschubert | tristan: agreed with the parallel loading per junction :) I'll put that on my list for the future :) | 16:21 |
| benschubert | tristan: I'll go ahead and merge this then | 16:22 |
| gitlab-br-bot | marge-bot123 merged MR !1363 (bschubert/iterative-loader->master: Make the loading process iterative) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1363 | 16:32 |
| benschubert | https://gitlab.com/BuildStream/website/merge_requests/121 < for updating documentaiton on the website. "-e" mode will not be possible once using Cython. Moreover, that should really only be used by developers. | 16:35 |
| tristan | Oh that is indeed a bit sad | 16:37 |
| *** xjuan has joined #buildstream | 16:40 | |
| benschubert | tristan: It is slightly more work, but has the added advantage of forcing the correct dependencies too now :) | 16:45 |
| benschubert | So less confusing updates | 16:45 |
| *** lachlan has joined #buildstream | 16:46 | |
| benschubert | ah to be clear, "--user -e" is not possible with cython anymore. You can still use -e alone | 16:48 |
| benschubert | but that might be suprising :) | 16:48 |
| *** lachlan has quit IRC | 16:52 | |
| *** jonathanmaw has quit IRC | 17:04 | |
| gitlab-br-bot | BenjaminSchubert opened (was WIP) MR !1350 (bschubert/cython->master: Introduce Cython for better performances) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1350 | 17:13 |
| benschubert | tristan: would you mind looking at the documentation update in ^ ? I'm too entangled in Cython to know if they are understandable or not | 17:14 |
| *** phil has quit IRC | 17:17 | |
| *** raoul has quit IRC | 17:25 | |
| *** lachlan has joined #buildstream | 17:38 | |
| *** lachlan has quit IRC | 17:48 | |
| *** lachlan has joined #buildstream | 18:03 | |
| *** lachlan has quit IRC | 18:11 | |
| *** xjuan has quit IRC | 18:33 | |
| *** xjuan has joined #buildstream | 18:51 | |
| *** lachlan has joined #buildstream | 18:53 | |
| *** xjuan has quit IRC | 18:55 | |
| *** lachlan has quit IRC | 18:58 | |
| *** xjuan has joined #buildstream | 19:11 | |
| *** dftxbs3e has quit IRC | 19:17 | |
| *** dftxbs3e has joined #buildstream | 19:20 | |
| *** lachlan has joined #buildstream | 19:26 | |
| *** lachlan has quit IRC | 19:32 | |
| *** kapip has joined #buildstream | 19:37 | |
| *** xjuan has quit IRC | 20:10 | |
| *** xjuan has joined #buildstream | 20:27 | |
| *** xjuan has quit IRC | 20:32 | |
| *** xjuan has joined #buildstream | 20:49 | |
| *** mintuser has joined #buildstream | 21:15 | |
| *** kapip has quit IRC | 21:47 | |
| *** xjuan has quit IRC | 22:00 | |
| *** xjuan has joined #buildstream | 22:15 | |
| *** xjuan has quit IRC | 23:48 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!