*** vil has joined #buildstream | 00:48 | |
*** Prince781 has quit IRC | 01:05 | |
*** xjuan has quit IRC | 01:06 | |
*** Prince781 has joined #buildstream | 01:06 | |
*** xjuan has joined #buildstream | 01:23 | |
*** Prince781 has quit IRC | 01:31 | |
*** xjuan has quit IRC | 01:34 | |
*** bochecha has quit IRC | 02:02 | |
*** tristan has joined #buildstream | 06:50 | |
juergbi | tristan: while it's still marked WIP, I'd appreciate your thoughts about the API additions to allow command batching: https://gitlab.com/BuildStream/buildstream/merge_requests/915 | 07:10 |
---|---|---|
*** ChanServ sets mode: +o tristan | 07:58 | |
tristan | juergbi, On it... | 07:58 |
tristan | Hmmm, how do you remove the '+r' ? | 07:58 |
tristan | juergbi, Done | 08:18 |
juergbi | ta | 08:19 |
*** Exterminador^TL has joined #buildstream | 08:55 | |
*** Exterminador^TL has quit IRC | 08:55 | |
*** tristan has quit IRC | 09:10 | |
*** benschubert has joined #buildstream | 09:27 | |
*** TinkerT has joined #buildstream | 09:33 | |
*** raoul has joined #buildstream | 09:44 | |
*** jonathanmaw has joined #buildstream | 09:54 | |
*** tristan has joined #buildstream | 09:57 | |
*** bochecha has joined #buildstream | 10:20 | |
*** lachlan has joined #buildstream | 10:27 | |
*** anahuelamo has quit IRC | 10:34 | |
*** anahuelamo has joined #buildstream | 10:34 | |
lachlan | Hi, I posed a query yesterday about storing benchmarking data - has anyone on channel any thoughts on the topic? | 10:44 |
jmac | ISTR last time this was discussed there was resistance to storing data, and people felt it would be better to make sure tests can be re-run in the future to get comparative results | 10:48 |
jmac | I don't agree with that, and personally I'd use a relational database, but that's just my preference | 10:48 |
lachlan | jmac: Thanks for your input. | 10:51 |
lachlan | Getting historical comparisons for recent changes by simply re-running tests against specific points in Master seems very onerous to me, true you should be able to re-run the tests in this fashion, but it's not particularly practical on a day-to-day basis. | 10:55 |
*** jonathanmaw_ has joined #buildstream | 10:55 | |
*** jonathanmaw has quit IRC | 10:56 | |
jmac | It's not the computing power required that worries me, I don't think you'll be able to reliably regenerate historic data | 10:58 |
lachlan | jmac: I think computing power is an issue, to make results comparable my thinking is that it would be best to run benchmarks on a specific machine and make the jobs serial, as it stands running the current pipeline (using my dev branch) takes 26 minutes to get one set of results across all tests. | 11:03 |
lachlan | For any statistically valuable set it would take many hours to generate them. | 11:05 |
jmac | Oh, it is an issue, certainly | 11:06 |
*** alatiera_ has joined #buildstream | 11:08 | |
lachlan | As it stands, I don't think we stamp the results with the current benchmarking commit, I think it might be a good idea to add this. | 11:14 |
*** finn_ is now known as finn | 11:18 | |
finn | What does BuildStream do better than Nix? | 11:18 |
benschubert | Could some people have a look at https://gitlab.com/BuildStream/buildstream/issues/727 and give me their opinion? Thanks! | 11:23 |
persia | finn: Different problem space, mostly. If you want to construct lots of filesystem snippets from some sources, both tools do well. If you want to compose those into a single filesystem, BuildStream has stronger support. If you want to compose those into a collection of namespaced virtual filesystems, Nix has stronger support. | 11:30 |
persia | I suspect the relevant missing features could be added to either tool, but generally folk look at tools with their outcome in mind, rather than their mechanism, so there isn't that much overlap in the userbases. | 11:32 |
finn | what's the difference between composing something into a "single filesystem" and "collection of namespaces virtual filesystems"? | 11:40 |
persia | Mostly disk layout and kernel overhead. | 11:43 |
*** lachlan has quit IRC | 11:45 | |
persia | More specifically, most of the buildstream compositions I've seen produced end up being something akin to a tarball containing a bunch of files, which can be unpacked into a single filesystem. | 11:45 |
persia | Hrm, except Nix has that but with a different layout. | 11:46 |
* persia tries to describe this better | 11:46 | |
persia | So, with BuildStream composition elements, files are usually stored in a location in the filesystem that matches any internal references to the filesystem that may be in the files (e.g. config file locations, rpath entries, etc.). | 11:47 |
persia | With Nix, users usually deploy all the build elements in separate special directories, and then create symlink farms representing execution filesystems, such that the paths of the symlinks match the internal references in the files, rather than the files themselves. | 11:48 |
finn | This sounds more like an implementation detail. Why would I care about if something is a single filesystem vs a collection of namespaced virtual filesystems? | 11:48 |
persia | Some software interacts with symlinks badly, but that's just an implementation detail as well: implementing the virtual filesystems with hardlinks or FUSE avoids that problem. | 11:49 |
persia | With a real filesystem, there's slightly less overhead at runtime, although except in tightly constrained systems, this isn't that important. | 11:50 |
finn | They sound to me like they're very similar. | 11:50 |
persia | If you don't care about the ultimate representation, yes, they are very similar. Surprisingly, lots of folk care. | 11:50 |
finn | So the fact you have to use a functional language vs YAML and plugins | 11:51 |
*** lachlan has joined #buildstream | 11:51 | |
persia | I know that some of the folk involved in the intiiation of BuildStream found the way in which Nix delivers things to be incredibly confusing, but that might be personal preference. | 11:51 |
persia | If you want to build systems that need real files (e.g. a bootable image), it gets a bit more complex with Nix, but that sort of thing can be done with an external script (and often is). | 11:52 |
persia | Well, also, that Nix permits one to compose a system with multiple virtual filesystems: I believe this would be hard in BuildStream. | 11:53 |
persia | So, if you want to have two versions of some software, using the same filenames, and have those each be dependencies of two other pieces of software, which run simultaneously, Nix is probably the better choice. | 11:54 |
persia | On the other hand, changing the version of a specific piece of software that is a dependency of several other pieces of software (e.g. for a security update), is easier in BuildStream. | 11:55 |
finn | In what way? | 11:58 |
persia | Because Nix permits each component to depend on an arbitrary version of each other component, one often has to update the version in several places, or force-rebuild the reverse dependency tree. BuildStream does this automatically. Alternately said, BuildStream forces a complete rebuild just because you fixed a typo in the gcc documentation. | 11:59 |
*** lachlan has quit IRC | 12:02 | |
*** lachlan has joined #buildstream | 12:04 | |
jmac | I've moved https://gitlab.com/BuildStream/buildstream/merge_requests/911 (Direct CAS-to-CAS imports) out of WIP. It's a fairly complicated change, but isolated to one file (and one test). If anyone has time to review it, that would be welcome. | 12:15 |
*** gitlab-br-bot has joined #buildstream | 12:44 | |
gitlab-br-bot | jmacarthur opened MR !923 (jmac/execution-architecture-docs->master: Docs: Add remote execution architecture documentation.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/923 | 12:45 |
*** brlogger` has joined #buildstream | 12:49 | |
*** brlogger has quit IRC | 12:50 | |
*** jonathanmaw_ has quit IRC | 12:50 | |
*** gitlab-br-bot has quit IRC | 12:50 | |
*** gitlab-br-bot has joined #buildstream | 12:50 | |
*** jonathanmaw has joined #buildstream | 12:50 | |
*** brlogger has joined #buildstream | 12:54 | |
*** gitlab-br-bot has quit IRC | 12:55 | |
*** gitlab-br-bot has joined #buildstream | 12:55 | |
Kinnison | jmac: You have an unticked "performance test" - do you anticipate doing that before merge? | 13:04 |
Kinnison | jmac: Oh never mind, I see your comment now | 13:05 |
* Kinnison can scroll, oh yes | 13:05 | |
*** Prince781 has joined #buildstream | 13:06 | |
*** gitlab-br-bot has quit IRC | 13:08 | |
*** gitlab-br-bot has joined #buildstream | 13:08 | |
ironfoot | #1 | 13:08 |
gitlab-br-bot | Issue #1: sphinx docs fail on python2-default systems https://gitlab.com/BuildStream/buildstream/issues/1 | 13:08 |
ironfoot | tristan: ^ | 13:08 |
persia | !1 | 13:12 |
gitlab-br-bot | MR !1: Artifact Cache https://gitlab.com/BuildStream/buildstream/merge_requests/1 | 13:12 |
gitlab-br-bot | jonathanmaw opened MR !924 (jonathan/workspace-fragment-create->master: Support invoking buildstream from a workspace outside a project) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/924 | 13:18 |
cs-shadow | does it work when #1 is mentioned in a sentence? | 13:18 |
cs-shadow | apparently not | 13:18 |
ironfoot | cs-shadow: it does work, but it has some anti-spam tricks in place | 13:21 |
ironfoot | so it currenlty waits for another 15 messages in the channel before reminding you what that issue (#1) was | 13:22 |
cs-shadow | ironfoot: that's neat. | 13:22 |
cs-shadow | let's try with #2 | 13:22 |
gitlab-br-bot | Issue #2: Support mounting the host filesystem read-only in the sandbox https://gitlab.com/BuildStream/buildstream/issues/2 | 13:22 |
cs-shadow | yay! that worked | 13:23 |
ironfoot | also if #2 was mentioned recently by the bot (maybe new issue created), the bot won't reply either | 13:23 |
ironfoot | happy to take any feature request | 13:24 |
cs-shadow | that makes sense. Is the source for the bot also on GitLab somewhere? :) | 13:24 |
ironfoot | https://gitlab.com/palvarez89/gitlabirced | 13:25 |
cs-shadow | thanks! | 13:25 |
ironfoot | It's not the best code, and there are a few cleanups I want to do | 13:25 |
*** dopE has joined #buildstream | 13:27 | |
*** Prince781 has quit IRC | 13:41 | |
* persia tests whether the 15-message boundary includes messages from gitlab-br-bot by asking about !1 | 13:42 | |
persia | Apparently not :) | 13:43 |
ironfoot | cheeky | 13:46 |
*** Prince781 has joined #buildstream | 14:26 | |
*** anahuelamo has quit IRC | 14:32 | |
*** anahuelamo has joined #buildstream | 14:32 | |
adds68 | Is it ever possible for a git source to have no url ? | 14:41 |
adds68 | When parsing sources in a plugin, i can am getting an error "AttributeError: 'GitSource' object has no attribute 'url'" | 14:41 |
adds68 | can | 14:42 |
finn | Which plugin are you using? | 14:43 |
finn | I don't think I've ever seen a plugin with no url - for local files I use something like `url: file://my/local/adam.file` | 14:44 |
finn | As in a source plugin sorry | 14:44 |
tpollard | adds68: I think that's correct, the object has no .url attr | 14:45 |
adds68 | finn, it's one i'm extending/making | 14:46 |
adds68 | tpollard, but shouldn't all git sources have urls? | 14:46 |
tpollard | adds68: looks at the gitsource class | 14:46 |
adds68 | good idea | 14:46 |
tpollard | you'll want .original_url | 14:47 |
tpollard | more than likely | 14:47 |
adds68 | tpollard, 0_0 i shall look | 14:49 |
adds68 | and thanks :) | 14:49 |
tpollard | adds68: or see what public api the source.py has | 14:50 |
adds68 | tpollard, i can't see anything about urls in the plugin reference | 14:53 |
adds68 | tpollard and in the Git source documentation the yaml states "url" | 14:53 |
tpollard | link? | 14:54 |
adds68 | tpollard, https://docs.buildstream.build/sources/git.html?highlight=git#module-sources.git | 14:55 |
tpollard | yeh, it's url in yaml, but it looks like whatever you've written is trying to access that via an attribute it's not assigned to | 14:55 |
tpollard | adds68: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/plugins/sources/git.py#L363 | 14:57 |
adds68 | Hmmm that seems a bit odd, but i guess i will have to use that! | 14:58 |
adds68 | It's strange, because GitMirror is still using "self.url" | 14:59 |
*** jonathanmaw_ has joined #buildstream | 15:02 | |
*** jonathanmaw has quit IRC | 15:03 | |
*** Prince781 has quit IRC | 15:35 | |
raoul | Done the changes mablanch suggested on https://gitlab.com/BuildStream/buildstream/merge_requests/900, so if anyone with write access wants to do a final review and merge that'd be grand | 16:12 |
*** anahuelamo has quit IRC | 16:22 | |
*** lachlan has quit IRC | 16:38 | |
laurence | tristan, jennis, tlater[m], and anyone else who is interested, re the BuildStream Architecture, 101 and 102 sessions from the gathering, I am just doing some final bits of editing, hope to have them on the website next week. | 16:48 |
jmac | I keep getting an error about 'tmp_path' being a missing fixture when running the test suite: https://paste.gnome.org/puib7b6or | 16:49 |
jmac | That's the only test which uses that fixture apparently | 16:50 |
tpollard | hmm, that's recently landed? | 16:51 |
jmac | About a week ago | 16:51 |
tpollard | gitlab is telling me it was 1 day ago | 16:52 |
tpollard | https://gitlab.com/BuildStream/buildstream/merge_requests/912/diffs | 16:52 |
jmac | Right, the commit was written a week ago, merged yesterday | 16:53 |
jmac | CI has a more recent version of pytest than me | 16:54 |
jmac | Fixed | 16:54 |
tpollard | yep, looks very recent too | 16:54 |
*** lachlan has joined #buildstream | 16:55 | |
tpollard | 21 days even | 16:55 |
gitlab-br-bot | cs-shadow merged MR !914 (chiaratolentino/fix-pip-source-regex->master: plugins/sources/pip.py: Accomodate characters '-','.','_' for packages) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/914 | 17:09 |
*** ChunkyPuffs has quit IRC | 17:22 | |
*** tpollard has quit IRC | 17:22 | |
*** abderrahim3 has joined #buildstream | 17:24 | |
*** abderrahim2 has quit IRC | 17:25 | |
*** finn has quit IRC | 17:42 | |
*** raoul has quit IRC | 17:45 | |
gitlab-br-bot | knownexus opened MR !925 (issue-638-validate-all-files->master: WIP: Added --all functionality to `bst show`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/925 | 17:58 |
Nexus | When did the gitlab bot start saying names? | 17:58 |
*** tiagogomes has quit IRC | 17:59 | |
gitlab-br-bot | jmacarthur closed issue #745 (Reimplementation of `utils._force_rmtree()`) on buildstream https://gitlab.com/BuildStream/buildstream/issues/745 | 18:00 |
gitlab-br-bot | knownexus opened MR !926 (issue_640-Build-All->master: WIP: Added build all functionality to `bst build`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/926 | 18:01 |
gitlab-br-bot | jmacarthur opened MR !927 (jmac/make_writable_combination->master: WIP: Use _force_rmtree instead of custom code.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/927 | 18:04 |
*** jonathanmaw_ has quit IRC | 18:21 | |
*** xjuan has joined #buildstream | 18:42 | |
*** Prince781 has joined #buildstream | 19:05 | |
*** xjuan has quit IRC | 19:09 | |
*** Prince781 has quit IRC | 19:49 | |
*** xjuan has joined #buildstream | 20:07 | |
*** lachlan has quit IRC | 20:23 | |
*** ChunkyPuffs has joined #buildstream | 20:23 | |
*** benschubert has quit IRC | 20:36 | |
*** Prince781 has joined #buildstream | 20:41 | |
*** Alexwall has joined #buildstream | 21:00 | |
*** xjuan has quit IRC | 21:20 | |
*** xjuan has joined #buildstream | 21:39 | |
*** Prince781 has quit IRC | 23:15 | |
*** flatmush has quit IRC | 23:15 | |
*** flatmush has joined #buildstream | 23:16 | |
*** mohan43u has quit IRC | 23:18 | |
*** mohan43u has joined #buildstream | 23:21 | |
*** tristan has quit IRC | 23:37 | |
*** bochecha has quit IRC | 23:37 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!