| *** Prince781 has joined #buildstream | 00:54 | |
| *** slaf has quit IRC | 01:33 | |
| *** slaf has joined #buildstream | 01:36 | |
| *** Prince781 has quit IRC | 01:45 | |
| *** xjuan has quit IRC | 02:20 | |
| *** mcatanzaro has quit IRC | 02:53 | |
| *** ernestask has joined #buildstream | 07:28 | |
| * paulsherwood wonders how closely the bst folks actually looked at the ybd cache-key work | 08:06 | |
| * paulsherwood notes that ybd cache-key has had 11 versions since the original re-implementation of morph cache-key | 08:08 | |
| paulsherwood | (not to say that bst cache isn't better, what with the strong and weak concept... but still) | 08:09 |
|---|---|---|
| *** valentind has joined #buildstream | 08:43 | |
| *** jonathanmaw has joined #buildstream | 09:37 | |
| *** aday has joined #buildstream | 09:46 | |
| *** tiago has quit IRC | 09:54 | |
| *** tiago has joined #buildstream | 09:55 | |
| *** valentind has quit IRC | 10:03 | |
| *** ssam2 has joined #buildstream | 10:11 | |
| 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 | 10:21 |
| 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 | 10:27 |
| gitlab-br-bot | buildstream: merge request (monkey-patch-setuptools->master: Modify the generated CLI script by monkey patching) #231 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/231 | 10:29 |
| *** aday has quit IRC | 10:32 | |
| *** aday has joined #buildstream | 10:38 | |
| tristan | juergbi, the first looks like a regression from moving arches from being built-in to a type of option; while the second is necessary "strictly speaking" inasmuchas, so long as we have still not solved #38 the outputs are different depending on cache | 11:14 |
| juergbi | ok, will file an issue for the first one | 11:15 |
| tristan | juergbi, however; since you raise it, I'm tempted to say things are much simpler if we dont fix the former, and trust that sources are doing their job; lack of host tools guarantees uniqueness here already | 11:15 |
| tristan | "Sources" doing their job meaning, guaranteeing a different cache key for a different input | 11:15 |
| juergbi | this often solves the issue | 11:16 |
| juergbi | however, biarch toolchains may still produce problems here | 11:16 |
| tristan | juergbi, in the hope that things go where we want to steer them, and we can leverage the build farm things to do cross compiles... | 11:16 |
| juergbi | same imported toolchain can build x86-32 and x86-64. configure uses uname to decide which to build... | 11:16 |
| tristan | we should consider that the result of `uname` is almost always the wrong thing too | 11:16 |
| juergbi | but autotools and possibly other systems do use that, afaik | 11:17 |
| juergbi | i'd certainly recommend explicit target arch | 11:17 |
| juergbi | however, i'd like to avoid accidental clashes | 11:17 |
| tristan | mhm, yes | 11:17 |
| juergbi | maybe we could actually block/neutralize uname via bwrap | 11:17 |
| tristan | juergbi, if we're going to address that; we should have this reported by the sandbox | 11:17 |
| juergbi | have to figure out whether seccomp in bwrap supports that | 11:18 |
| tristan | The default for an `arch` type option is appropriate to get from the host (default build for host arch), the arch which goes into a build is decided by the sandbox | 11:18 |
| tristan | and at one point, the arch required of the sandbox is decided by an option | 11:18 |
| juergbi | yes, if we are explicit in what sandbox arch we use, we can avoid this issue as well | 11:19 |
| juergbi | (and bst could then also use `setarch` to ensure uname makes sense) | 11:20 |
| tristan | juergbi, I think for our current sandboxes we can use host uname, until they do any kind of virtualization (a conceivable one being spoofing uname results on a target-compat arch, like building i386 on x86_64) | 11:20 |
| tristan | however I'm starting to be afraid of uname, seeing as it will tell you a different string for the same hardware depending on OS | 11:21 |
| juergbi | arch names are not really standardized, yes... | 11:21 |
| juergbi | we also have a similar situation for OS, although there we don't typically have the issue of a single toolchain supporting multiple OSes | 11:22 |
| tristan | We're probably going to end up needing to decide on a nomanclature for them and be more explicit | 11:22 |
| juergbi | may make sense | 11:22 |
| tristan | yeah not sure, I've been trying to steer away from that mess, but if we'll have support for executing the sandbox in a given binary format I'm not sure it's escapable | 11:23 |
| tristan | The latter of the two problems, it does seem tempting to just call it issue #38 and remove that part of the cache key | 11:25 |
| juergbi | given that we don't use host tools, the issue with OSes would just arise in very special cases (e.g., importing toolchains for both Linux and QNX and then building based on `uname`) | 11:25 |
| tristan | juergbi, at this point it's mostly a matter of convenience | 11:26 |
| juergbi | latter problem: or be explicit about it, or at the very least comment it clearly in the code why we currently have it | 11:26 |
| tristan | I.e. uname behaving differently | 11:26 |
| tristan | If we could have a portable way to reporting machine arch that would be nice | 11:26 |
| juergbi | things are tricky given that there are also multiple (not fully compatible) CPU families in a single arch | 11:27 |
| juergbi | be it i586 vs i686 or armv7 with and without FP hardware | 11:27 |
| tristan | we probably want to keep some measure of convenience (guessing what you want to build depending on your host and the options you've enabled) | 11:29 |
| juergbi | agree but on the bst level, we can't do the guessing inside individual build jobs | 11:30 |
| tristan | because it's very very often the case that it's guessable; while other specific features are usually encoded into the compiler | 11:30 |
| tristan | Hmmm | 11:30 |
| tristan | Now thinking of sub-projects I can see that tucking those away as options to the bootstrapping base project will just bubble up and not be hidden from consumers anyway | 11:31 |
| tristan | juergbi, btw when I say "the sandbox" I dont mean it needs to be something that runs inside the sandbox which guesses it | 11:32 |
| juergbi | sure | 11:33 |
| tristan | juergbi, I just mean that abstract class's implementation should be contributing, not the invocation context | 11:34 |
| * tristan thought that was misunderstood with "we can't do the guessing inside individual build jobs" | 11:34 | |
| juergbi | i just wanted to make this clear | 11:34 |
| tristan | yeah | 11:35 |
| tristan | So I understood properly :) ummm, I guess we have to keep with the same uname approach | 11:35 |
| tristan | (even though the bootstrap projects we know about will always be explicit about the toolchain they are bootstrapping, so in known cases uniqueness is guaranteed) | 11:36 |
| tristan | given the randomness which surrounds arch names it would have been nice to be able to overlook it | 11:37 |
| paulsherwood | tristan: are you planning to reply to my/edmunds questions about what problems bst aims to solve? | 11:38 |
| tristan | Oh that | 11:38 |
| tristan | I was planning on not getting caught up in anything other than drafting slides but fell into the irc pit accidentally | 11:39 |
| paulsherwood | ack :) | 11:39 |
| paulsherwood | does this help at all? https://gitlab.com/trustable/trustable-mustard/blob/master/markdown/software-construction.md | 11:39 |
| tristan | paulsherwood, I can reply to the email with replies to each of those points yes | 11:41 |
| * paulsherwood looks forward to it :) | 11:41 | |
| paulsherwood | if you have other points, i'm interested also :) | 11:42 |
| tristan | glancing over the first half, my answers are mostly "Yes", and "To the extent that is reasonable" | 11:42 |
| ssam2 | i had a couple of goes at replying to Edmund's points but i found it impossible | 11:43 |
| ssam2 | my main thought was "if you like your existing tool a lot, keep it" :-) | 11:43 |
| ssam2 | but that didn't seem a useful response | 11:44 |
| tristan | ssam2 will never be a politician :) | 11:44 |
| ssam2 | let's hope! | 11:44 |
| tristan | which is a lucky thing hehe yeah | 11:44 |
| tlater | Free gnome water bottles for everyone | 11:45 |
| ssam2 | free software for all! | 11:45 |
| paulsherwood | ssam2: i'm disregarding edmund's email - he titled it about problems, then immediately asked if buildstream is/features various solutions | 11:49 |
| tristan | It would be nice to CI the procedure for producing an image on a foreign architecture and using the source-bundle feature to give it the dependencies which buildstream needs in order to turn a new machine into a builder | 11:50 |
| * tristan has this on a checklist of things we do, but notices we're not testing that part | 11:51 | |
| tristan | ssam2, do you have a full size BuildStreamBeaver ? | 12:52 |
| ssam2 | yeah | 12:56 |
| tristan | I want one :) | 12:56 |
| ssam2 | one sec | 12:56 |
| * tlater wonders if tristan is sewing his beaver costume | 12:56 | |
| ssam2 | tristan, http://afuera.me.uk/junk/buildstream-beaver-placeholder.jpg | 12:57 |
| tristan | ssam2, thanks | 12:57 |
| ssam2 | i assume a virtual copy is fine, the actual beaver is out fixing someone's plumbing | 12:58 |
| tristan | eek, do we have another UI regression of late ? | 13:26 |
| tristan | It looks like the start of `bst build` is showing the `git cat-file` commands while checking source consistency state at startup | 13:27 |
| tristan | without being nicely silenced in a nested timed activity | 13:27 |
| tristan | juergbi, I'm guessing this is a side effect of fixing how state is handled | 13:30 |
| juergbi | hm, i see it here as well but not sure why state handling would have caused this | 13:32 |
| tristan | I'm making that connection because I wonder if state is not being resolved as early as it used to be | 13:33 |
| tristan | but I could be wrong | 13:34 |
| tristan | Pipeline.initialize() should be resolving consistency | 13:34 |
| tristan | or earlier even ? | 13:34 |
| tristan | we used to have 3 tickers, load, resolve and checking cached states | 13:35 |
| tristan | the last one seems missing | 13:35 |
| tristan | we changed the tickers to be timed activities and work with the logger | 13:35 |
| tristan | looks like this is now in Pipeline.assert_consistent() | 13:37 |
| juergbi | it's possible that it's resolved later for the non-strict case | 13:37 |
| juergbi | as we don't calculate a unreliable strong key anymore in non-strict mode | 13:37 |
| juergbi | however, at least with tracking enabled, we can't do this anyway early on | 13:39 |
| tristan | when tracking is enabled we go through the regular pathways and I think that status message is silenced anyway | 13:40 |
| tristan | but things might be coming apart in this regard, as we went from explicit to implicit state updates | 13:41 |
| *** ernestask has quit IRC | 13:42 | |
| *** ernestask has joined #buildstream | 13:43 | |
| *** tiago has quit IRC | 13:49 | |
| *** tiago has joined #buildstream | 13:50 | |
| *** tiago has joined #buildstream | 13:52 | |
| *** Prince781 has joined #buildstream | 14:15 | |
| *** Prince781 has quit IRC | 14:29 | |
| *** Prince781 has joined #buildstream | 14:30 | |
| *** Prince781 has quit IRC | 14:33 | |
| gitlab-br-bot | buildstream: issue #172 ("pkg_resources module causes a delay of between 0 and many seconds every time `bst` starts up") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/172 | 14:44 |
| gitlab-br-bot | buildstream: issue #172 ("pkg_resources module causes a delay of between 0 and many seconds every time `bst` starts up") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/172 | 14:44 |
| gitlab-br-bot | buildstream: merge request (monkey-patch-setuptools->master: Modify the generated CLI script by monkey patching) #231 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/231 | 14:44 |
| gitlab-br-bot | buildstream: issue #172 ("pkg_resources module causes a delay of between 0 and many seconds every time `bst` starts up") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/172 | 14:46 |
| juergbi | ssam2: i still don't see any improvement with !234 on top of !231 (the latter now in master) | 14:56 |
| ssam2 | hmm | 14:56 |
| tlater | juergbi: It's required for another MR that I wrote | 14:57 |
| tlater | The one that makes the bash-completion path as small as possible | 14:57 |
| tlater | Since we need to load the number from somewhere, and including pkg_resources in that path makes everything slow | 14:57 |
| juergbi | ok, that's fine with me. i'm just wondering why `bst --help` (as simple test case) doesn't get a speedup with these changes | 14:58 |
| ssam2 | i don't see the improvement either | 14:58 |
| tlater | I did see a pretty significant improvement on the completions, never tested anything else myself | 14:59 |
| ssam2 | maybe one of our dependencies has started importing pkg_resouresc ?? | 14:59 |
| ssam2 | I definitely saw this working a month or two ago | 14:59 |
| ssam2 | ah, i didn't actually reinstall the wrapper binary | 14:59 |
| ssam2 | now it's faster | 15:00 |
| ssam2 | for me 0.5s to 0.3s | 15:00 |
| juergbi | hm, maybe i have an odd setup. it's still 0.35s here | 15:00 |
| ssam2 | the slowdown scales with the number of python site-packages you have | 15:01 |
| ssam2 | as the bug is pkg_resources scanning all of them on load | 15:01 |
| ssam2 | if you have an ssd and not many python site-packages then maybe you don't see it so much | 15:01 |
| juergbi | maybe that's the reason | 15:02 |
| juergbi | good to know that it helps on some systems at least | 15:03 |
| juergbi | ta | 15:03 |
| *** Prince781 has joined #buildstream | 15:12 | |
| *** ssam2 has quit IRC | 15:17 | |
| *** jennis has joined #buildstream | 15:22 | |
| *** ssam2 has joined #buildstream | 15:23 | |
| *** mcatanzaro has joined #buildstream | 15:27 | |
| gitlab-br-bot | buildstream: merge request (version-read-no-pkg_res->master: Get version number w/o pkg_resources) #234 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/234 | 15:30 |
| gitlab-br-bot | buildstream: merge request (unused_complete_var->master: Document _frontend autocomplete path more, remove unused var) #254 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/254 | 15:42 |
| jmac | I'm starting to get reproducibility data out of BuildStream; this roughly matches the reproducibility data from Debian. https://paste.gnome.org/pxf8y7yio | 15:54 |
| jmac | It's done by external scripts at the moment. | 15:55 |
| tristan | nice ! | 15:56 |
| tristan | ssam2, you're the libreoffice buff, seems I was naive to think I could have such a cool feature but... maybe it's hiding somewhere... | 15:57 |
| tristan | ssam2, have you an idea how to make a video which starts on slide 2, go up into the top right corner and *keep playing* until I get to slide 10 ? | 15:58 |
| gitlab-br-bot | buildstream: merge request (unused_complete_var->master: Document _frontend autocomplete path more, remove unused var) #254 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/254 | 16:14 |
| ssam2 | tristan, heh, I have no idea about that | 16:30 |
| ssam2 | see if you can grab michael meeks on saturday and ask him | 16:30 |
| ssam2 | it might be better to just open the video in Totem if you can get the window to sit above LO's | 16:31 |
| tristan | ssam2, yeah might do... | 16:37 |
| tristan | I have this whole recording of an epiphany build hehe | 16:37 |
| tristan | was hoping I could let it run in the corner while talking | 16:37 |
| jmac | Can I tell buildstream to just tell me the immediate build dependencies of an element, rather than the full list? | 16:38 |
| tristan | hrmmm nope | 16:38 |
| jmac | I may suggest a patch to allow that as an option to --deps | 16:39 |
| tristan | jmac, we have been trying to standardize on how to specify "parts of a pipeline" either for bst show or other purposes | 16:39 |
| jmac | Ok, that sounds good | 16:39 |
| tristan | yeah that's one approach; I've toyed with the idea of a "depth" before | 16:39 |
| tristan | but not sure it's interesting | 16:40 |
| tristan | we have the --deps <thing> pattern, and we have the --except thing | 16:40 |
| tristan | which we try to repeat where relevant in the CLI for consistency | 16:40 |
| *** tristan_ has joined #buildstream | 16:43 | |
| *** valentind has joined #buildstream | 16:50 | |
| mcatanzaro | Downloading libwacom seems to be broken, the link takes me to a sourceforge download gate (wait five seconds, then the download starts) which isn't good | 17:12 |
| mcatanzaro | https://paste.gnome.org/poel6bwbg/m6jvnl/raw | 17:13 |
| mcatanzaro | Any ideas? | 17:13 |
| mcatanzaro | Also: what is tomjon? :P | 17:13 |
| ssam2 | tomjon is a veteran placeholder | 17:13 |
| ssam2 | he's lived through several build systems now :-) | 17:13 |
| ssam2 | as for libwacom ... hmm :-( | 17:14 |
| ssam2 | i don't know that this ever worked | 17:14 |
| ssam2 | actually it just worked for m,e | 17:16 |
| ssam2 | except you have a different URL | 17:16 |
| mcatanzaro | :O | 17:16 |
| ssam2 | I have: sourceforge_net:linuxwacom/files/libwacom/libwacom-0.23.tar.bz2 | 17:17 |
| ssam2 | in my core-deps/libwacom.bst | 17:17 |
| ssam2 | from commit 8d2d9ea7f709e58e9ec39b1c0df423a81333dc74 | 17:17 |
| ssam2 | wait, that's the same url | 17:18 |
| ssam2 | but, it works ... maybe they are doing some nasty stuff based on your IP or something ? | 17:18 |
| *** tristan_ has quit IRC | 17:18 | |
| mcatanzaro | Sigh | 17:19 |
| mcatanzaro | I've retried several times, it always fails | 17:20 |
| ssam2 | as a workaround, we have a mirror here: http://git.baserock.org/cgit/delta/linuxwacom/libwacom.git/ | 17:20 |
| ssam2 | that mirrors git rather than tarball | 17:20 |
| ssam2 | but might be enough | 17:20 |
| mcatanzaro | wget works: https://paste.gnome.org/pthlzy13j/fasp1t/raw | 17:21 |
| ssam2 | right | 17:21 |
| ssam2 | to be fair, we are using urllib.request internally | 17:21 |
| ssam2 | which is not particularly known for smartness | 17:21 |
| mcatanzaro | The link works from a web browser too (though the download is started via JS, after a five second delay) | 17:22 |
| ssam2 | maybe if we used 'requests' instead we would get increased smartness | 17:22 |
| mcatanzaro | That's really suspicious | 17:22 |
| ssam2 | at the cost of another python dep | 17:22 |
| ssam2 | this is the relevant code: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/plugins/sources/_downloadablefilesource.py#L83 | 17:22 |
| mcatanzaro | Well, I have no idea why wget gets a .tar.bz, but a web browser gets an HTML page | 17:22 |
| tlater | Ah | 17:23 |
| tlater | That's a redirect, isn't it? | 17:23 |
| juergbi | user agent based? | 17:23 |
| mcatanzaro | I guess sourceforge is probably doing user agent parsing, that's my only guess | 17:23 |
| mcatanzaro | Yes | 17:23 |
| tlater | wget has fancy follow-redirect code | 17:23 |
| mcatanzaro | tlater: Surely urllib can follow redirects...? That's not very fancy | 17:23 |
| tlater | mcatanzaro: Have you tried it with curl -LO? | 17:23 |
| tlater | Err, curl -O | 17:23 |
| tlater | mcatanzaro: It's possible that urllib doesn't follow redirects by default | 17:24 |
| juergbi | wget --user-agent="" still works | 17:24 |
| tlater | Yeah, curl -O outputs an html page instead of a .tar.gz | 17:25 |
| tlater | (Still named .tar.gz) | 17:25 |
| ssam2 | it is returning 302, at least | 17:26 |
| tlater | But apparently urllib follows redirects by default :| | 17:26 |
| mcatanzaro | clap, clap, clap | 17:26 |
| tlater | Maybe sourceforge redirects the python user-agent to a JS site for some reason? | 17:27 |
| ssam2 | it may be the 'Accept */*' that's causing it | 17:27 |
| ssam2 | if I use plain urlopen, I get binary data | 17:28 |
| ssam2 | which is tar bzip2 | 17:29 |
| ssam2 | so my naive fix would be to remove that header; but maybe it's there for a reason | 17:30 |
| * tlater doesn't recall the accept header standards | 17:30 | |
| ssam2 | oh wait, it was working for me anyway | 17:30 |
| ssam2 | I'm a bad testcase here | 17:30 |
| tlater | Hm, setting Accept to something like text/plain could help, but it might also break some elements | 17:32 |
| tlater | Probably better to leave that up to the server to decide | 17:32 |
| tlater | We could have special casing for sourceforge though if that actually fixes it | 17:32 |
| mcatanzaro | What about request.add_header('Accept', 'application/x-bzip-compressed-tar')? | 17:32 |
| tlater | mcatanzaro: Do we know what the user expects? | 17:33 |
| tlater | Oh, I guess this is a tar source | 17:33 |
| mcatanzaro | tlater: Yes we do :D | 17:33 |
| tlater | We could definitely set the accept header with the source type :) | 17:33 |
| mcatanzaro | https://gitlab.com/BuildStream/buildstream/commit/3fd7fe1fd3406fc9c35d0d2719085809c48247c7 <-- says the accept header is to make alioth work | 17:33 |
| mcatanzaro | (Yay for GitLab blame!) | 17:33 |
| abderrahim[m] | Hi guys | 17:33 |
| mcatanzaro | valentind we are arguing about your code ^^^ | 17:34 |
| tlater | o/ abderrahim[m] | 17:34 |
| abderrahim[m] | Regarding this source forge thing, I noticed there are two sf URL types in gnome project.conf | 17:35 |
| abderrahim[m] | This may be worth investigating | 17:35 |
| abderrahim[m] | Sorry I'm on a phone | 17:36 |
| ssam2 | mcatanzaro, what version of python do you have ? i'm on 3.6.3 here | 17:36 |
| mcatanzaro | ssam2: 3.6.4 duh duh duh | 17:39 |
| ssam2 | doubt that's the issue then | 17:40 |
| tlater | mcatanzaro: Have you tried setting the accept header to something else? | 17:40 |
| mcatanzaro | No, I probably should | 17:41 |
| mcatanzaro | But we should also investigate "there are two sf URL types in gnome project.conf" as that's very suspicious | 17:41 |
| mcatanzaro | Lemme look at that first | 17:41 |
| mcatanzaro | There is downloads.sourceforge.net: http://downloads.sourceforge.net/ | 17:42 |
| mcatanzaro | And there is sourceforge_net: https://sourceforge.net/projects/ | 17:42 |
| mcatanzaro | hmmmm | 17:42 |
| ssam2 | presumably both were used in jhbuild | 17:42 |
| mcatanzaro | We only have two projects using soursceforge, libpinyin (downloads.sourceforge.net) and libwacom (plain sourceforge.net) | 17:42 |
| ssam2 | so, does libpinyin download for you ? :-) | 17:43 |
| mcatanzaro | Yes | 17:44 |
| mcatanzaro | Wait | 17:44 |
| mcatanzaro | no | 17:44 |
| mcatanzaro | No it doesn't- | 17:44 |
| mcatanzaro | Drat | 17:44 |
| mcatanzaro | https://paste.gnome.org/p2zs0wnkm/wzgsqw/raw | 17:44 |
| * tlater wonders why the sha doesn't report an issue | 17:46 | |
| mcatanzaro | OK now I'm getting somewhere | 17:46 |
| mcatanzaro | I did a 'git pull' in the buildstream repo and reinstalled buildstream with 'pip3 install --user -e' | 17:47 |
| mcatanzaro | I think it worked now | 17:47 |
| mcatanzaro | I updated from January 18 git master to today's | 17:47 |
| tlater | Erk | 17:48 |
| mcatanzaro | Yes, I'm pretty sure it's working now | 17:48 |
| tlater | Temporary regression sounds bad | 17:48 |
| *** jennis has quit IRC | 17:53 | |
| *** Prince781 has quit IRC | 18:01 | |
| *** jonathanmaw has quit IRC | 18:01 | |
| *** Prince781 has joined #buildstream | 18:02 | |
| *** Prince781 has quit IRC | 18:05 | |
| *** Prince781 has joined #buildstream | 18:07 | |
| *** ssam2 has quit IRC | 18:16 | |
| jjardon[m] | Is there any plan to tag another bst release soon? | 18:25 |
| tristan | jjardon[m], lets do that after fosdem | 18:25 |
| tristan | jjardon[m], we have a ton of features ready to land too | 18:25 |
| jjardon[m] | there are some stuff in master that is currently interesting for our project (like more logging when connecting to remote) | 18:25 |
| tristan | so lets get them through and roll a dev release | 18:25 |
| jjardon[m] | how is the cache-key of the cache calculated? we need to use the same version we expect the developers to use so they can reuse the same cache | 18:27 |
| jjardon[m] | I know 1.0.1 generates different artifacts than current master, for example (I guess is expected) | 18:28 |
| tristan | jjardon[m], for 1.0, they will remain the same; for 1.1 (dev), they will vary but not often, until next stable 1.2.x where they will be stable again | 18:28 |
| tristan | jjardon[m], current policy is stable cache keys for a stable release lifetime | 18:28 |
| jjardon[m] | rigth | 18:29 |
| tristan | jjardon[m], to be honest; I would not care about 1.0.x really; and stay with master and accept that cache keys will change a few times over the year | 18:29 |
| tristan | with 1.2 we probably have the features you care about | 18:30 |
| tristan | but that will be in... around september with gnome 3.30 | 18:30 |
| jjardon[m] | well | 18:30 |
| jjardon[m] | that make things about more delicate, as I can not say people to use master and hope the cache generated is the same as they need | 18:31 |
| *** adds68 has quit IRC | 18:32 | |
| tristan | If you populate caches with new versions of BuildStream as they roll out, and tell users to keep using master, it should be alright; but it's true that people who dont pull new buildstream will lose out on cache hits | 18:33 |
| tristan | that said, it shouldnt happen often; and you will simply not get the bright and shiney perfect world where you just need not care; at least until 1.2 | 18:33 |
| *** adds68 has joined #buildstream | 18:34 | |
| tristan | jjardon[m], I do see your concern, almost worth considering an earlier release - we had punted the next stable to *next* gnome because our first API stable release landed in mid-cycle | 18:36 |
| tristan | which is still desirable given all the features people want to land, stable before gnome 3.28 doesnt sound super rational either | 18:37 |
| *** Prince781 has quit IRC | 18:57 | |
| mcatanzaro | Hey question, we are supposed to have CI running to ensure gnome-build-meta is always up-to-date, right? | 19:08 |
| mcatanzaro | But https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/elements/core/gnome-control-center.bst specifies autotools, two weeks after the autotools build system was deleted | 19:09 |
| mcatanzaro | So... is it not currently running...? | 19:09 |
| jjardon[m] | mcatanzaro: AFAIK there is no CI at the moment | 19:16 |
| jjardon[m] | It will be though | 19:17 |
| mcatanzaro | OK | 19:17 |
| mcatanzaro | Next question, following the guide https://wiki.gnome.org/Newcomers/BuildSystemComponent | 19:17 |
| mcatanzaro | After changing the element type to meson, I run 'bst build --track-all --track-save core/gnome-control-center.bst' then 'bst shell core/gnome-control-center.bst' | 19:18 |
| mcatanzaro | As instructed | 19:18 |
| mcatanzaro | It says: "Missing elements for staging an environment for a shell: | 19:18 |
| mcatanzaro | core/gnome-control-center.bst | 19:18 |
| mcatanzaro | Try building them first" | 19:18 |
| mcatanzaro | That is... confusing. I have to remove the --track-all and --track-save arguments to get it to build. | 19:19 |
| mcatanzaro | The tutorial doesn't mention that | 19:20 |
| mcatanzaro | (BTW, do you have time to review aday's feedback on the tutorial?) | 19:20 |
| abderrahim[m] | mcatanzaro: It seems to be a bug. I also noticed it. | 19:34 |
| *** adds68 has quit IRC | 19:54 | |
| *** adds68 has joined #buildstream | 20:27 | |
| *** adds68 has quit IRC | 20:41 | |
| gitlab-br-bot | buildstream: issue #221 ("Allow automatically configuring git remote URL when opening workspace") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/221 | 20:55 |
| gitlab-br-bot | buildstream: issue #222 ("Allow running bst commands from workspace directory") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/222 | 21:02 |
| mcatanzaro | abderrahim[m]: I think 'bst build --track-all --track-save' causes bst to not build the final module that you asked it to build, just everything else | 21:15 |
| abderrahim[m] | Maybe, but it should. It should be equivalent to bst track + bst build | 21:38 |
| * abderrahim[m] is cursing autocorrect which keeps changing bst to best | 21:39 | |
| mcatanzaro | I'm not sure what it should do, because there is no man page, and doesn't seem possible to get the supported arguments out of --help | 21:46 |
| abderrahim[m] | bst build --help ? | 21:51 |
| mcatanzaro | Ahh... I had tried 'bst --help build' and 'bst help build' and 'bst build help' but didn't think to try that one | 21:52 |
| *** valentind has quit IRC | 21:56 | |
| *** ernestask has quit IRC | 22:00 | |
| *** aday has quit IRC | 22:14 | |
| *** Prince781 has joined #buildstream | 22:27 | |
| gitlab-br-bot | buildstream: issue #223 ("Make it possible to run functional GNOME apps from bst shell") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/223 | 22:56 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
