| *** Prince781 has joined #buildstream | 01:17 | |
| *** Prince781 has quit IRC | 01:24 | |
| *** Prince781 has joined #buildstream | 01:41 | |
| *** Prince781 has quit IRC | 01:53 | |
| *** Prince781 has joined #buildstream | 02:06 | |
| *** mcatanzaro has quit IRC | 02:29 | |
| *** Prince781 has quit IRC | 06:13 | |
| *** noisecell has joined #buildstream | 07:40 | |
| *** valentind has joined #buildstream | 08:08 | |
| valentind | jjardon[m], It did not manage to fully build, but it did pull the bootstrap artifacts: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/50083801 | 08:13 |
|---|---|---|
| valentind | Sorry wrong channel. | 08:15 |
| *** valentind has quit IRC | 09:05 | |
| *** aday has joined #buildstream | 09:42 | |
| *** jonathanmaw has joined #buildstream | 09:50 | |
| *** tristan has quit IRC | 10:07 | |
| *** ssam2 has joined #buildstream | 10:08 | |
| ssam2 | is it intentional that variables can't refer to themselves ? | 11:01 |
| ssam2 | it would be nice if for autotools elements you could do `conf-args: %{conf-args} --disable-foo` | 11:01 |
| ssam2 | currently that triggers a traceback | 11:01 |
| ssam2 | ah, the traceback seems a bit unrelated | 11:04 |
| ssam2 | if I fix that issue I get a better error of: unresolved variable 'conf-args' in declaration of 'conf-args' at: glade.bst [line 21 column 13] | 11:05 |
| ssam2 | i can imagine that the code would get way more complex if we did allow such recursive expansion | 11:05 |
| ssam2 | the traceback seems to be caused by find_references() assuming that all variables are strings, which is not (currently) true | 11:05 |
| juergbi | for the case of conf-args we do have conf-extra, conf-global and conf-local | 11:07 |
| juergbi | maybe a more generic approach would be useful, not sure | 11:07 |
| ssam2 | ah, conf-extra | 11:09 |
| ssam2 | i feel like allowing recursive expansion would be nightmarish as we need to ensure the order of expansion stays stable and is well documented | 11:11 |
| ssam2 | we should document conf-extra better at https://buildstream.gitlab.io/buildstream/elements/autotools.html#module-elements.autotools though | 11:11 |
| *** tristan has joined #buildstream | 11:23 | |
| jjardon[m] | AFAIK, conf-extra is only for compatibility, you should use conf-global and conf-local only | 11:47 |
| ssam2 | why ? | 11:48 |
| tristan | you invented it so you should know :) | 11:48 |
| tristan | Ummm, we originally had conf-extra, but then jjardon[m] saw the need of separation between local/global | 11:48 |
| ssam2 | ah, so conf-global is for project.conf and conf-local is per-element ? | 11:48 |
| ssam2 | that makes sense | 11:48 |
| tristan | I think leaving extra around might serve some purpose one day, also is harmless | 11:48 |
| * ssam2 will do a patch explaining this for https://buildstream.gitlab.io/buildstream/elements/autotools.html#module-elements.autotools | 11:49 | |
| tristan | ssam2, exactly | 11:49 |
| tristan | ssam2, if you do, please clarify cmake/meson also | 11:49 |
| tristan | there are a couple with that pattern | 11:49 |
| ssam2 | OK | 11:49 |
| *** noisecell has quit IRC | 12:21 | |
| ssam2 | `bst shell` seems broken since jonathanmaw's changes | 12:26 |
| ssam2 | if there are overlaps in the dependency tree somewhere above where you try to open the shell | 12:26 |
| *** zalupik has joined #buildstream | 12:27 | |
| ssam2 | seems to be doing Element.search(Scope.BUILD) to find overlapping elements | 12:27 |
| ssam2 | the result is None in my case and then we crash | 12:28 |
| ssam2 | but when doing `bst shell` you only stage the runtime deps, so it seems like that search is going to fail in that case | 12:28 |
| *** csoriano has quit IRC | 12:31 | |
| *** csoriano has joined #buildstream | 12:32 | |
| tristan | ssam2, I dont understand 100%, but sounds like an unhandled None condition that needs fixing regardless of it's side effects ? | 12:37 |
| *** noisecell has joined #buildstream | 12:37 | |
| ssam2 | yeah, the question is whether we should handle None, or avoid this codepath somewhere higher up in situations where it will be broken | 12:40 |
| ssam2 | this is the bad line: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/element.py#L486 | 12:40 |
| ssam2 | i'm interested in jonathanmaw's thoughts | 12:40 |
| *** ernestask has joined #buildstream | 12:50 | |
| *** tristan has quit IRC | 12:56 | |
| jonathanmaw | ssam2: hrm, I didn't know it could do that | 13:00 |
| jonathanmaw | I suppose at the point of `bst shell` overlap checking is redundant | 13:01 |
| jonathanmaw | I'm not sure about the codepaths, but would it make sense to have the stage_dependency_artifacts grow a "check_overlaps" arg? | 13:02 |
| ssam2 | that might make sense, yeah | 13:08 |
| *** mcatanzaro has joined #buildstream | 13:16 | |
| gitlab-br-bot | buildstream: merge request (element-workspaces->master: Make workspaces element-wide instead of source-specific) #257 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/257 | 13:19 |
| *** ssam2 has quit IRC | 13:34 | |
| jmac | I've since reset my buildstream to master and done a full rebuild of core/gedit.bst. The 'gedit' binary doesn't appear anywhere within ~/.cache/buildstream until I do a `bst checkout`; should the binary exist somewhere on disk before I do the checkout? | 14:05 |
| *** ssam2 has joined #buildstream | 14:29 | |
| ssam2 | what's our review policy for the cargo-fetcher repo ? | 14:37 |
| ssam2 | i sent https://gitlab.com/BuildStream/cargo-fetcher/merge_requests/1 which i'm happy to merge if the policy is "go ahead and do it" ... | 14:37 |
| ssam2 | jmac, when buildstream does 'Caching artifact' and you are using the ostree cache backend, the artifact is stored in the ostree repo at ~/.cache/buildstream/artifacts/ostree | 14:51 |
| ssam2 | the first time something *uses* the artifact, it gets extracted to ~/.cache/buildstream/artifacts/extract so that we can then hardlink it into the staging area or whatever we need to do | 14:51 |
| jmac | Right, so that gedit is stored in artifacts/ostree in some internal ostree object and needs to be extracted with ostree? | 14:52 |
| ssam2 | yeah | 14:52 |
| ssam2 | try `ostree refs --repo ~/.cache/buildstream/artifacts/ostree --list | grep gedit` | 14:52 |
| ssam2 | each ref in the output will correspond to one build of gedit | 14:52 |
| ssam2 | then you can do `ostree checkout --repo ~/.cache/buildstream/artifacts/ostree gedit/1234abcdef ./my-gedit-checkout` | 14:53 |
| jmac | Right, yes, I was just searching for the right ostree syntax | 14:53 |
| jmac | It's like learning git over again | 14:53 |
| jmac | I'm at the 'this is stupid and I hate it' phase | 14:53 |
| ssam2 | i would criticise ostree for not being inconsistent with git's ui, but git's ui is completely interally inconsistent anyway :-) | 14:54 |
| ssam2 | -not | 14:54 |
| jmac | Why would there be three builds in there, though? It should be marked as locally cached. | 14:55 |
| ssam2 | every build is saved | 14:56 |
| ssam2 | we don't actually ever expire builds from the local cache currently | 14:57 |
| jmac | But I deleted all of ~/.cache/buildstream and did a new bst track/build from scratch. | 14:57 |
| jmac | I can't think why it would ever do more than one build of gedit. | 14:58 |
| ssam2 | ah, also artifacts are stored under both the 'strong' and 'weak' cache key | 15:00 |
| ssam2 | so you get two refs per build | 15:00 |
| ssam2 | https://buildstream.gitlab.io/buildstream/cachekeys.html#cachekeys explains the 'strong' vs 'weak' business a bit | 15:00 |
| jmac | That accounts for two of them... | 15:01 |
| jmac | bst checkout complains about not being able to fchown files | 15:03 |
| jmac | Unless I'm root | 15:03 |
| ssam2 | ostree checkout ? ah yes, try --user-mode | 15:04 |
| jmac | That's got it | 15:05 |
| gitlab-br-bot | buildstream: issue #220 ("[RFE] Add option to bst --track to update to the latest tag in the branch specify by track: instead to latest HEAD") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/220 | 15:10 |
| aday | ssam2: given that the fix to my librsvg patch went into cargo-fetcher, how do i get it? | 15:30 |
| aday | the guide on the gnome wiki just talks about updating gnome-build-meta | 15:30 |
| ssam2 | aday, there's a cron job running on gnome7.codethink.co.uk which should have done everything we need | 15:35 |
| ssam2 | let me check the logs | 15:35 |
| aday | ssam2: i tried running the build again and hit the same issue, but maybe i didn't give it long enough | 15:35 |
| aday | i didn't realise that the fix wouldn't be instantaneous | 15:36 |
| ssam2 | bah, something is broken | 15:36 |
| ssam2 | it should update every 5 minutes | 15:36 |
| ssam2 | but instead it esplodes every 5 minutes ... https://gnome7.codethink.co.uk/cargo-fetch-logs/cargo-fetch-2018-01-30-153501.txt | 15:36 |
| aday | as a newcomer to buildstream, it would be good to have a primer on how it works | 15:36 |
| ssam2 | it's mentioned at https://wiki.gnome.org/Projects/BuildStream/Infrastructure | 15:36 |
| ssam2 | that page could no doubt be improved; but the long term goal is for most of the stuff described there to not have to exist | 15:36 |
| aday | ah, i didn't know about that page | 15:37 |
| * ssam2 notices that the jhbuild autoconversion is already now obsolete :-) | 15:38 | |
| ssam2 | this "too many open files" issue seems to happen every time i run `cargo fetch` | 15:40 |
| ssam2 | `sudo lsof|wc -l` reports 7385 other open files | 15:40 |
| ssam2 | seems like a Cargo bug ... https://github.com/rust-lang/cargo/issues/4403 is related | 15:42 |
| ssam2 | or a libgit2 bug | 15:42 |
| ssam2 | the workaround from that issue (running `git gc` inside Cargo's checkout of its index repo) seems to have fixed things | 15:46 |
| ssam2 | https://gnome7.codethink.co.uk/cargo-fetch-logs/cargo-fetch-2018-01-30-154501.txt | 15:46 |
| ssam2 | aday, building librsvg *should* now be working if you get the latest versions of crates.bst and librsvg.bst | 15:48 |
| ssam2 | which should happen by default | 15:48 |
| aday | thank, ssam2: | 15:50 |
| aday | let's see | 15:50 |
| *** tristan has joined #buildstream | 15:55 | |
| aday | ssam2: still failing | 15:57 |
| ssam2 | argh | 15:57 |
| ssam2 | with the same error ? | 15:57 |
| aday | oh, maybe not actually | 16:00 |
| aday | error: no matching version `^0.23` found for package `cssparser` (required by `rsvg_internals`) | 16:00 |
| aday | i just saw cssparser | 16:00 |
| ssam2 | i think that is the same | 16:00 |
| * aday makes a sacrifice to the build gods | 16:02 | |
| aday | is it working yet? | 16:02 |
| ssam2 | let me try and reproduce here | 16:03 |
| tlater | I'm currently working on my branch to move the test suite to debian-8 (so we can test with python3.4) | 16:05 |
| tlater | And well, I'm reimplementing the hack to remove ostree/bwrap for unix | 16:06 |
| tlater | It feels a bit pointless doing this, should I create a separate image for that? Perhaps even a debian-8 one, so that we can just swap it out once we have an *actual* unix runner | 16:07 |
| tlater | Nevermind, that would also just be an intermediate solution | 16:07 |
| tlater | One that takes up an entire image :| | 16:08 |
| ssam2 | yeah, it seems a bit of a pain having to maintain two images with such a minor difference between them | 16:08 |
| tlater | It's just a bit hard to remove ostree from that particular image | 16:08 |
| tlater | Since we have to build it manually | 16:08 |
| tlater | I suppose I can continue running the fedora image for it though. | 16:09 |
| ssam2 | surely it's easier if you built it manually | 16:09 |
| ssam2 | just use `rm` :-) | 16:10 |
| tlater | Well, I'm not sure what debian usually has in /usr/local | 16:10 |
| ssam2 | shouldn't be anything there | 16:10 |
| ssam2 | by default | 16:10 |
| tlater | I guess I can look at the image | 16:10 |
| ssam2 | if you remove the whole thing, you perhaps break subsequent attempts to install stuff into /usr/local but that's totally unimportant for a throwaway container like this | 16:10 |
| ssam2 | aday, i just got a successful librsvg build | 16:11 |
| ssam2 | hmm, perhaps this is no-strict mode biting us ... | 16:12 |
| ssam2 | could you share a full build log, and also the file elements/base/crates.bst ? | 16:13 |
| tlater | Ah, right | 16:15 |
| * tlater had to put ostree in /usr because it didn't want to run from /usr/local | 16:15 | |
| ssam2 | is the source tree still around ? if so, you could `make uninstall` | 16:17 |
| aday | ssam2: build log - https://paste.fedoraproject.org/paste/rSnMAUY58TNIho~DRXDDWg | 16:17 |
| tlater | No :| | 16:17 |
| tlater | Hrm | 16:17 |
| aday | ssam2: crates.bst - https://paste.fedoraproject.org/paste/W-fao3~DMpqG5u6sKuTPhA | 16:18 |
| ssam2 | hmm, crates.bst doesn't have a ref saved | 16:18 |
| ssam2 | what command are you using to run the build ? | 16:18 |
| aday | ssam2: i think it was `bst build --track-all --track-save core/gnome-shell.bst` | 16:21 |
| aday | taken from the gnome tutorial | 16:21 |
| ssam2 | odd, that should write an exact ref to crates.bst | 16:21 |
| ssam2 | that's what --track-save means | 16:21 |
| ssam2 | without the ref it's hard to know if you have the updated version | 16:21 |
| ssam2 | either it's not being updated, or the it's not being rebuilt once updated | 16:22 |
| ssam2 | -the | 16:22 |
| aday | i just reran the command and the ref appeared in the file | 16:23 |
| ssam2 | ah, great | 16:23 |
| ssam2 | i have ref 92f0fe7debf166908e0e32bfe97327457de5039a2c17ae278e9e467d626f3b2c | 16:23 |
| aday | me too! | 16:24 |
| * aday high fives ssam2 | 16:24 | |
| tristan | fwiw, this is what drives the accumulative vendored crates: https://gitlab.com/BuildStream/cargo-fetcher/blob/master/Cargo.toml | 16:28 |
| tristan | And it seems to have the required cssparser version | 16:28 |
| tristan | that will run periodically on gnome7 populating a repo we use to provide rust deps to builds which need them | 16:28 |
| tristan | What I dont like about that build log, is line 1059: "location searched: registry https://github.com/rust-lang/crates.io-index" | 16:30 |
| tristan | that would have caused a network error, perhaps librsvg build scripts changed in such a way as to override the /.cargo/config we install | 16:30 |
| aday | ssam2: librsvg successfully built \o/ | 16:37 |
| aday | thanks for your help | 16:37 |
| * ssam2 high fives aday ! | 16:37 | |
| * tristan remains confused as to why it failed before :-/ | 16:38 | |
| ssam2 | initially, lack of https://gitlab.com/BuildStream/cargo-fetcher/merge_requests/1 in the cargo-vendor repo | 16:38 |
| tristan | Ah | 16:38 |
| tristan | now it all makes sense :D | 16:38 |
| tristan | annoying this crates thing, better solution without moving parts is desirable | 16:39 |
| *** valentind has joined #buildstream | 16:52 | |
| gitlab-br-bot | buildstream: merge request (sam/conf-docs->master: Improve documentation for Autotools, CMake and Meson elements) #258 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/258 | 16:54 |
| tlater | ssam2: I think I'll just use the fedora image for unix tests for now | 16:55 |
| tlater | Now just to figure out how to `useradd` consistently across multiple platforms... | 17:00 |
| tlater | Oh, useradd is available on all distros? \o// | 17:02 |
| *** Prince781 has joined #buildstream | 17:15 | |
| *** Prince781 has quit IRC | 17:16 | |
| jmac | Should changing a project's project.yaml cause a complete rebuild? | 17:20 |
| ssam2 | depends what you change | 17:21 |
| jmac | I added elements/autotools/config/strip-commands and it's started an almost full rebuild but some bits were still marked as cached | 17:25 |
| ssam2 | that should trigger a rebuild of every autotools element | 17:26 |
| ssam2 | and, in strict mode, anything which depends on any autotools element | 17:26 |
| ssam2 | assuming your strip-commands were different from the default ones | 17:26 |
| jmac | Ah, it's clever enough to only build autotools elements? Very nice. | 17:26 |
| aday | so, ah, is there a way to avoid building webkit? | 17:32 |
| ssam2 | two ways ... | 17:34 |
| *** Prince781 has joined #buildstream | 17:34 | |
| ssam2 | first is get someone who has push access to the cache push a build there for you | 17:34 |
| ssam2 | CI will do that for us in future, but for now it's a manual thing | 17:34 |
| ssam2 | hmm, since we're using a tarball for that, the cache should really have it there | 17:35 |
| ssam2 | as long as you are in no-strict mode ... but that's what we recommend by default in the instructions | 17:35 |
| *** Prince781 has quit IRC | 17:37 | |
| aday | i'll just leave the thought with you. it'd be a nice thing to skip | 17:39 |
| aday | with jhbuild it was often possible to cheat and use your distro version | 17:40 |
| ssam2 | the intention is very much that someone already built it for you | 17:40 |
| aday | that's music to my ears | 17:41 |
| aday | is there a way to pause a build other than hitting ctrl+c? | 17:54 |
| aday | i've looked in the docs but can't see anything | 17:55 |
| ssam2 | ctrl+z should work | 17:55 |
| ssam2 | it's usually then `fg %1` to resume again | 17:56 |
| aday | thanks | 17:56 |
| *** mcatanzaro has quit IRC | 17:58 | |
| *** jonathanmaw has quit IRC | 18:02 | |
| *** ssam2 has quit IRC | 18:02 | |
| juergbi | do i see this right that we don't use the platform (OS/arch) for the (context) cache key? | 18:06 |
| juergbi | i.e., we might have cache key conflicts for builds on different platforms? | 18:07 |
| juergbi | tristan: ^^ | 18:07 |
| juergbi | also, why do we use the type name of the artifact cache (OSTreeCache vs. Tar) for the cache key? | 18:08 |
| *** mcatanzaro has joined #buildstream | 18:16 | |
| *** xjuan has joined #buildstream | 18:31 | |
| *** aday has quit IRC | 19:59 | |
| *** aday has joined #buildstream | 20:00 | |
| *** aday has quit IRC | 20:07 | |
| *** ernestask has quit IRC | 21:15 | |
| *** aday has joined #buildstream | 21:21 | |
| *** valentind has quit IRC | 21:40 | |
| *** aday has quit IRC | 22:21 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!