| *** tristan has quit IRC | 00:00 | |
| *** persia has joined #buildstream | 00:54 | |
| *** Prince781 has quit IRC | 04:43 | |
| *** mercy_ has joined #buildstream | 04:44 | |
| mercy_ | ________ ______ _____ __ ______ __________ _ ___________________ ____ ____ ______ | 04:45 |
|---|---|---|
| mercy_ | / _/ __ \/ ____// ___// / / / __ \/ ____/ __ \/ | / / ____/_ __/ ___/ / __ \/ __ \/ ____/ | 04:45 |
| mercy_ | / // /_/ / / \__ \/ / / / /_/ / __/ / /_/ / |/ / __/ / / \__ \ / / / / /_/ / / __ | 04:45 |
| mercy_ | _/ // _, _/ /____ ___/ / /_/ / ____/ /___/ _, _/ /| / /___ / / ___/ // /_/ / _, _/ /_/ / | 04:45 |
| mercy_ | /___/_/ |_|\____(_)____/\____/_/ /_____/_/ |_/_/ |_/_____/ /_/ /____(_)____/_/ |_|\____/ | 04:45 |
| mercy_ | persia juergbi slaf zalupik cs_shadow jennis theawless[m] lantw44 csoriano adds68 skullman nexus rafaelff[m] cgmcintyre[m] pro[m] connorshea[m] mrmcq2u[m] m_22[m] jjardon[m] bochecha kailueke[m] abderrahim[m] ptomato[m] asingh_[m] inigomartinez mattiasb waltervargas[m] ernestask[m] gitlab-br-bot | 04:45 |
| *** mercy_ has left #buildstream | 04:45 | |
| *** Prince781 has joined #buildstream | 04:50 | |
| *** Prince781 has quit IRC | 05:04 | |
| *** Prince781 has joined #buildstream | 05:32 | |
| *** Prince781 has quit IRC | 06:10 | |
| *** noisecell has joined #buildstream | 07:53 | |
| *** valentind has joined #buildstream | 08:49 | |
| *** tristan has joined #buildstream | 08:57 | |
| *** toscalix has joined #buildstream | 09:17 | |
| *** aday has joined #buildstream | 09:19 | |
| gitlab-br-bot | buildstream: merge request (proper-build-shells->master: element.py: Create real build shell for `bst shell --build`) #277 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/277 | 09:27 |
| tristan | juergbi, right now we only have 2 news items since 1.0 in master, they're pretty serious ones but; any thoughts on what we might have missed there ? | 09:30 |
| tristan | or anyone :) | 09:30 |
| tristan | I think the tests refactoring was a pretty big change | 09:30 |
| *** jonathanmaw has joined #buildstream | 09:32 | |
| skullman | the hacky sleep waiting for fuse to be mounted bothers me more than it should | 09:40 |
| skullman | is it that we might be running in a container where setuid doesn't work, hence `fusermount -u` won't work? | 09:40 |
| tristan | that depends on the site it seems | 09:42 |
| tristan | from what I recall, fusermount is needed and setuid but not always; and the C library calls out to fusermount -u itself, only as a fallback mechanism | 09:43 |
| tristan | skullman, but I think you are talking about the sleep at mount time no ? not at umount time | 09:44 |
| tristan | at mount time; it could *probably* be improved by reading off a pipe from the child process to synchonize startup | 09:45 |
| skullman | tristan: aye I'm talking about the sleep at mount time, but AIUI if we were to let it background we wouldn't need the sleep but we'd need to use `fusermount -u` to unmount it | 09:45 |
| skullman | tristan: yeah, would have to replace fuse_main with fuse_mount, fuse_new and fuse_loop | 09:45 |
| skullman | and notify before calling fuse_loop | 09:46 |
| tristan | ohhhhh "let it background" is a whole other can of worms; I investigated that and it is in that case *impossible* to synchronize as I recall | 09:46 |
| skullman | ah, my mistake for assuming it would do something sensible if backgrounding | 09:47 |
| tristan | skullman, what I vaguely recall; is that if you relinquish control to the fuse C library in it's own background mode, there is no way for it to tell you when it's done it's work | 09:48 |
| tristan | which yeah, seems we're working around with that ismount thing currently anyway | 09:49 |
| * skullman investigated casync recently so could compare its fuse handling, so would be in a position to make changes to fuse.py if there was will and funding to make it nicer | 09:49 | |
| tristan | but syncrhonization of libfuse mounts is limited, would have to refresh memory | 09:49 |
| *** dominic has joined #buildstream | 09:49 | |
| tristan | there is also syncrhonization of umount which is necessary (and still buggy) | 09:50 |
| tristan | I think we may have some very rare cases where we still fail to tear down a sandbox because of it | 09:50 |
| skullman | ouch | 09:51 |
| tristan | (errors happen when trying to remove the dev nodes that `bwrap` leaves behind, because things are still mounted, it's not clear) | 09:51 |
| skullman | sounds like the bwrap code is the next most interesting thing for me to look at while I try to get a handle on how things fit together | 09:52 |
| tristan | https://gitlab.com/BuildStream/buildstream/issues/161 | 09:52 |
| *** tiago has joined #buildstream | 09:53 | |
| *** ssam2 has joined #buildstream | 09:56 | |
| juergbi | tristan: another news item would be incremental workspace builds, although this has still issues | 09:57 |
| skullman | tristan: wow, that is a weird one. Sounds like the fusefs process was terminated but the mount point not yet removed. | 09:57 |
| juergbi | it looks like we're not using --die-with-parent for bwrap. that might be a good idea to add | 09:58 |
| tristan | Ah right ! | 09:59 |
| tristan | skullman, it seems that way yes; fuse is very hard to syncrhonize | 09:59 |
| tristan | Hmmm, ok so in around 30min I can validate my fix | 10:00 |
| *** ssam2 has quit IRC | 10:01 | |
| tristan | Wish the artifact server was up | 10:01 |
| tristan | it is but, hrm | 10:01 |
| *** ssam2 has joined #buildstream | 10:01 | |
| tristan | isn't this config supposed to work: https://bpaste.net/show/8a1268778de2 ? | 10:01 |
| tristan | ssam2, have you noticed that even though gnome7 was brought back to life; it's still not functioning as an artifact server ? | 10:02 |
| ssam2 | i haven't, but i haven't been doing anything that would pull from it | 10:02 |
| ssam2 | that should either work, or give you a warning early on in the pipeline that it doesn't | 10:02 |
| tristan | Failed to fetch remote refs from ssh://artifacts@gnome7.codethink.co.uk:10007/artifacts: ssh: connect to host gnome7.codethink.co.uk port 10007: Connection timed out | 10:03 |
| * ssam2 tries and fails to find sshd logs on gnome7 | 10:05 | |
| ssam2 | oh, it's ssh.service not sshd.service | 10:06 |
| ssam2 | no login attempts for user 'artifacts' are even getting logged by sshd | 10:06 |
| ssam2 | on gnome7 | 10:06 |
| ssam2 | i'm not sure what does that port 10007 forwarding | 10:07 |
| tristan | ssam2, oh jeez... mkay... | 10:07 |
| ssam2 | i think gary has set up something else we can use as a cache though | 10:09 |
| ssam2 | he was certainly in the process of doing that | 10:09 |
| *** valentind has quit IRC | 10:09 | |
| tristan | ssam2, yeah, in between cache servers - old one should still be working while we setup the new | 10:10 |
| ssam2 | yeah | 10:10 |
| tristan | I'm kind of upset about this whole thing being unstable, and would be wiser to just not bother with it and wait for the stable cache to come up | 10:11 |
| ssam2 | yeah, we're lucky really I think that nobody is really consuming that cache in anger yet | 10:12 |
| tristan | except me | 10:12 |
| ssam2 | yeah | 10:12 |
| tristan | who has to build webkit, again | 10:12 |
| gitlab-br-bot | buildstream: merge request (juerg/die-with-parent->master: sandbox/_sandboxbwrap.py: Use --die-with-parent) #278 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/278 | 10:18 |
| gitlab-br-bot | buildstream: merge request (sam/233-push-after-pull->master: Avoid pushing things we just pulled) #276 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/276 | 10:30 |
| ltu | tristan, what's your view wrt all those outstanding documentation MRs? i'm assuming you still want to review them yourself rather than juergbi | 10:31 |
| gitlab-br-bot | buildstream: issue #232 ("fd leak when generating epiphany tarball") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/232 | 10:35 |
| gitlab-br-bot | buildstream: merge request (proper-build-shells->master: element.py: Create real build shell for `bst shell --build`) #277 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/277 | 10:35 |
| gitlab-br-bot | buildstream: issue #257 ("workspace local state file keeps getting created") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/257 | 10:40 |
| tristan | ltu, frankly I have not had the time, review of those docs was costing me more time than it would cost to just write docs | 10:41 |
| *** noisecell has quit IRC | 11:07 | |
| gitlab-br-bot | buildstream: merge request (212-git-source-needs-a-way-to-disable-checking-out-submodules->master: Resolve "Git source needs a way to disable checking out submodules") #259 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/259 | 11:11 |
| gitlab-br-bot | buildstream: issue #258 ("Configurable log line formatting") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/258 | 11:35 |
| *** noisecell has joined #buildstream | 11:46 | |
| gitlab-br-bot | buildstream: issue #245 ("Logging issues") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/245 | 11:46 |
| *** noisecell has quit IRC | 12:09 | |
| *** noisecell has joined #buildstream | 12:09 | |
| *** noisecell has quit IRC | 12:25 | |
| *** noisecell has joined #buildstream | 12:39 | |
| gitlab-br-bot | buildstream: issue #166 ("bst sometimes modifies source `track` parameters") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/166 | 12:39 |
| tristan | Note, I've reopened #166 (thanks for fixing this !!!) because we should technically have this in the stable branch too | 12:41 |
| nexus | np | 12:42 |
| persia | tristan: Do you feel that fix is important enough to backport? | 12:48 |
| * paulsherwood thinks kbas beats buildstream's cache approach, except for identity/security | 12:51 | |
| persia | paulsherwood: By what measure? | 12:52 |
| ssam2 | the concept, or the specific implementation ? | 12:53 |
| persia | feature list? pull speed? storage requirements? | 12:54 |
| ssam2 | random thought: we currently allow /dev/random and /dev/urandom access in the sandbox | 12:56 |
| ssam2 | which *seems* like a bad idea for reproducibility :-) | 12:56 |
| ssam2 | i might file a bug to try removing them and seeing what breaks | 12:56 |
| jmac | What if an element needs to create a pair of cryptographic keys? | 12:57 |
| persia | ssam2: I suspect there are runtime things that break if they can't initialise with them. We could fake them with known replay sequences (e.g. a simple counter) | 12:57 |
| persia | But I think better is to just cause sources to be reproducible except when they should not be (such as jmac's example) | 12:58 |
| *** noisecell has quit IRC | 12:58 | |
| ssam2 | jmac, that would be bad unless they are purely for testing or creating a dummy input for something | 12:59 |
| ssam2 | jmac, here, have this opensshd artifact I built for you which ships with a ready-to-use private key ... | 12:59 |
| ssam2 | i promise i won't give it to anyone else or take a copy myself | 13:00 |
| tristan | persia, when you run `bst track`; it munges your project, and incorrectly so; I'd say that's pretty damn severe yeah | 13:00 |
| juergbi | urandom would be needed for testing binaries/libraries that use it | 13:00 |
| jmac | Would it? If I built and deployed it myself I don't see the problem | 13:00 |
| ssam2 | it seems conceptually wrong to do that at build time, rather than on first-use. i can't articulate exactly why though | 13:01 |
| tristan | ssam2, there are various things which dont build at all without those devices | 13:01 |
| ssam2 | perhaps it's just that buildstream is designed in favour of artifact reuse | 13:01 |
| persia | For private artifacts within a trust zone, I think it is better not to do on first-run, as it means that one can have a purely read-only instance of a service. | 13:02 |
| juergbi | i don't think it buys us much to avoid them. we can't completely enforce reproducibility anyway. if a tool that normally uses /dev/urandom doesn't find it, it likely either fails or falls back to PRNG which doesn't help either | 13:02 |
| tristan | ssam2, I did try some baserock full system builds without it; but also I recall reading on reproducible-builds.org that trying to build without those is a bit overkill | 13:02 |
| ssam2 | fair enough | 13:02 |
| jmac | I'm imagining a system (which may not exist in the real world) in which I can't get any access to a box unless ssh is running, and I need to extract the public key before first run | 13:02 |
| ssam2 | in trying to sum up issue #38, i've ended up trying to document our sandbox setup | 13:02 |
| persia | jmac: That's actually common in the world. cloud-init(1) was designed in part to be able to seed data before first login for precisely that class of use case. | 13:03 |
| ssam2 | that led me to wonder if the 5 devices we specify in _sandboxbwrap.py are "canonical" enough to list them in the docs | 13:03 |
| tristan | jmac, I recall juergbi and I rehashed this age old "I wanna produce an artifact with my custom thing in it" thing a lot, a while ago | 13:03 |
| persia | (pre-cloud sshd created server certificates at install time: that was modified to be at first-run to allow creation of images that would be reused without leaking key data, which then required out-of-band injection and inspection tooling to discover the key) | 13:04 |
| tristan | jmac, originally we thought there might be a different kind of "deployment" element for that; but then we nuked host tools to hell and decided that that sort of stuff belongs in post-processing after extracting reproducible artifacts from buildstream | 13:04 |
| jmac | That sounds reasonable. | 13:05 |
| persia | post-processing buildstream to generate keys, followed by out-of-buildstream deployment seems correct to me. | 13:05 |
| jmac | We need to make sure someone doesn't do it anyway, though; if someone does what I'm describing and uses a predictable /dev/random, boom | 13:05 |
| jmac | Perhaps show some big warnings if anyone reads from it | 13:06 |
| tristan | myeah that's problematic | 13:06 |
| tristan | maybe we could spoof it somehow | 13:06 |
| tristan | I mean, we can live with a "dont do that crazy shit" for a long time | 13:06 |
| jmac | Yes. | 13:06 |
| tristan | but seems interesting to have a real /rev/random that only ever produces the random number 1 | 13:07 |
| ssam2 | https://github.com/bmwiedemann/reproducible-faketools creates /dev/random and /dev/urandom files that are actually the same as /dev/zero | 13:08 |
| juergbi | https://xkcd.com/221/ | 13:08 |
| tristan | :) | 13:09 |
| ssam2 | but maybe better not to do that, so that when we do reproducibility testing we actually catch things that are reading from /dev/random | 13:09 |
| ssam2 | rather than hiding the actual problem | 13:10 |
| persia | That's probably better. Producing the same result from a source that doesn't typically produce the same result strikes me as less than ideal. | 13:12 |
| *** noisecell has joined #buildstream | 13:12 | |
| *** noisecell has quit IRC | 13:17 | |
| *** noisecell has joined #buildstream | 13:17 | |
| gitlab-br-bot | buildstream: merge request (jmac/microsecond-timing->master: WIP: Optional microsecond timing for log messages) #275 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/275 | 13:18 |
| jmac | ^ removed the documentation from that request | 13:19 |
| gitlab-br-bot | buildstream: merge request (jmac/microsecond-timing->master: Optional microsecond timing for log messages) #275 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/275 | 13:21 |
| paulsherwood | aiui kbas is more reliable, uses less resources, is easier to setup, has less dependencies. i may be wrong | 13:21 |
| paulsherwood | moving swiftly on... could bst be used to create custom Windows/MacOS images | 13:25 |
| paulsherwood | ? | 13:25 |
| persia | paulsherwood: Yes, but currently those would have to be buildable on linux. | 13:26 |
| persia | There is some work underway that *should* be able to allow creating custom MacOS images on MacOS, but it very much depends on the sources chosen at the current time. | 13:26 |
| paulsherwood | so no in parcice, then? | 13:26 |
| paulsherwood | practice | 13:26 |
| persia | It depends on the source. | 13:27 |
| persia | For example, freeciv's windows binaries *can* be built from linux, and so it is theoretically possible to create a Windows installer of freeciv with BuildStream | 13:27 |
| persia | But that's not universally true. | 13:27 |
| persia | For MacOS, the main issue today is that the UNIX backend depends on being run as root. | 13:28 |
| persia | Well, and that some sources can't be built on the default filesystems, but that's a smaller issue. | 13:29 |
| paulsherwood | generic usecase - i'm developing sw to run on both MacOS+Windows. ideally i want to validate my sw on controlled (but special) MacOS/Windows images deployed in CI for build and or test. can i use bst to create the custom images | 13:29 |
| persia | If you are starting software from scratch, absolutely. | 13:31 |
| paulsherwood | (maybe via bst in a docker container or vm operating on host directories? | 13:31 |
| persia | If you are starting from existing software, maybe: depends on the software. | 13:31 |
| paulsherwood | not from scratch | 13:32 |
| persia | If you want to run the build under windows, you'd have to use some sort of unix compatibility layer (there are a few to choose from) and the generic unix backend, and build as root. | 13:32 |
| paulsherwood | root would be an acceptable compromise i think, provided sandboxing is still happening | 13:32 |
| persia | Then the software has to be known to a) build safely on case insensitive filesystems and b) build correctly using tooling you can inject into buildstream and run in a unix-like context | 13:33 |
| persia | The generic unix interface doesn't have real sandboxing (uses chroot, no namespace protection, etc.). You'd need a sandboxing backend for your build platform. | 13:34 |
| persia | If you can build the software in a linux environment, you can have real sandboxing, but you will need to inject tooling that can run in that enviornment and build for your target environment. | 13:36 |
| *** noisecell has quit IRC | 13:36 | |
| gitlab-br-bot | buildstream: issue #259 ("Start time for jobs in the log output") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/259 | 13:37 |
| paulsherwood | the usecase i'm considering is to replace hand-crafted mac/windows build machines with (say gitlab runner) appliances that have bst at the top level, but running whatever tooling is on the machine | 13:37 |
| persia | BuildStream doesn't work that way. | 13:37 |
| paulsherwood | in what sense? | 13:38 |
| persia | Every effort has been taken to remove access to the host tooling. This is weak in the case of the generic unix backend (as it is possible to break out of the chroot and access host tooling), but not weak enough for normal payloads to run "whatever tooling is on the machine" | 13:38 |
| persia | Unless one embeds a chroot escape exploit into the build instructions, everything that runs has to run against an environment either constructed by buildstream or injected into buildstream. | 13:39 |
| paulsherwood | right, and that is sensible. | 13:39 |
| persia | It is possible to inject an install of a proprietary operating system as a baseline, assuming the semantics are roughly POSIX. | 13:40 |
| persia | And one could use that + buildstream to build images that depend on tooling only available in that environment. | 13:41 |
| persia | But that's not quite the same as what you describe asking gitlab runner to do. | 13:41 |
| persia | And anything that depends on deep features of an OS probably requires a target-specific sandbox implementation. | 13:42 |
| paulsherwood | right. that sounds ok. i shouldn't have said 'whatever tooling is on the machine' - i would want to control that, but via the 'inejct into bst' route | 13:43 |
| persia | (note that this is possible: BuildStream already has two sandbox backends enabled, but it's work if you want it for platforms not currently supported) | 13:43 |
| paulsherwood | yup | 13:43 |
| persia | Then, broadly, yes, but it's a long road of work to make something reliable and secure :) | 13:43 |
| persia | My recommendation would be to start by trying to build some hello-world thing with the generic unix backend. | 13:44 |
| persia | There might be some platform bugs, as I don't think running bst under either MacOS or Windows is tested much,. | 13:45 |
| persia | Once that works, then you'd want a platform sandbox backend, to make it a bit more secure. | 13:45 |
| persia | During the build/test cycle for that, most of the wrinkles about injecting an OS baseline are likely to be resolved. | 13:45 |
| persia | From that point you could start defining elements to put atop the baseline towards building your application. | 13:46 |
| persia | And you'll probably want a custom output plugin that generates the sorts of artifacts you want to deliver at the end. | 13:47 |
| persia | For MacOS, I suspect this is relatively easy. For Windows, I'd strongly suggest focusing on a WSL-based implemnentation, as you'll encounter fewer false assumptions along the way. | 13:48 |
| *** noisecell has joined #buildstream | 13:50 | |
| juergbi | interesting, WSL allows running Win32 binaries. afaik, it also has at least partial support for namespaces and thus bwrap might work | 13:52 |
| persia | That would be very cool. ,but needs testing. | 13:58 |
| persia | If we can use bwrap under WSL, building Windows software on Windows should work smoothly. | 13:58 |
| gitlab-br-bot | buildstream: issue #259 ("Start time for jobs in the log output") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/259 | 14:10 |
| *** noisecell has quit IRC | 14:22 | |
| *** noisecell has joined #buildstream | 14:23 | |
| juergbi | persia: injecting windows SDK into buildstream may require some manual work and may not be distributable but other than that, yes | 14:28 |
| juergbi | i'm wondering in what way Win32 processes running in a WSL namespace are sandboxed, though. really odd combination | 14:29 |
| juergbi | i suspect not at all (or maybe Windows will refuse running Win32 binaries in a WSL namespace/sandbox) | 14:30 |
| persia | Yes. Getting a license to distribute a windows SDK (or windows chroot) is well outside the scope of this discussion, but shouldn't be needed if push is restricted to internal non-public cache. | 14:32 |
| *** noisecell has quit IRC | 15:45 | |
| *** Prince781 has joined #buildstream | 15:47 | |
| *** Prince781 has quit IRC | 15:57 | |
| *** noisecell has joined #buildstream | 16:00 | |
| *** mcatanzaro has joined #buildstream | 16:01 | |
| *** Prince781 has joined #buildstream | 16:14 | |
| *** toscalix has quit IRC | 16:28 | |
| jjardon[m] | Hi, I want to put some files in a specific folder in a generated system (for example, the /usr/lib/os-release file); is there recommended way to do this in buildstream? | 16:32 |
| persia | My recommendation would be to put the files in a git repo, create a Makefile that put them in the desired locations when called with `make install`, and write an element for it. | 16:34 |
| ssam2 | there's an easier way | 16:35 |
| ssam2 | import them with the 'local' element from the same git repo as your project | 16:35 |
| ssam2 | see sdk/files/initramfs-scripts in the freedesktop SDK repo for example | 16:35 |
| ssam2 | if they are going to change frequently or there are lots of them then maybe a separate Git repo would be worthwhile, though | 16:35 |
| persia | My main motivation for recommending a repo is to parallel the base-files package in Debian. If one just needs a couple files for a local thing, using the "local" element is probably easier. If one wants to maintain a set of core files (which I thought was implied by including /usr/lib/os-release), then I think it is good to use proper SCM to collaborate on them. | 16:39 |
| ssam2 | i expect javier's buildstream project is also in a "proper SCM" | 16:39 |
| ssam2 | if not, then he has a bigger problem :-) | 16:39 |
| persia | And you've convinced me. | 16:41 |
| persia | I've just realised this is the same as "native" and "non-native" packaging, essentially, and I agree there is a place for both, and in cases where code is not shared between different sets of build instructions, "native" (using local elements) is the saner way to go. | 16:42 |
| gitlab-br-bot | buildstream: merge request (sam/doc-sandbox->master: doc: Add 'sandboxing' section) #279 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/279 | 16:45 |
| ssam2 | jmac, that ^ might be interesting to you related to issue #38 | 16:45 |
| jmac | I will try to remember that for when I look at that issue next week | 16:46 |
| ssam2 | i will mark it as related, in fact | 16:46 |
| gitlab-br-bot | buildstream: merge request (sam/doc-sandbox->master: doc: Add 'sandboxing' section) #279 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/279 | 16:47 |
| gitlab-br-bot | buildstream: merge request (sam/doc-sandbox->master: doc: Add 'sandboxing' section) #279 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/279 | 16:49 |
| *** dominic has quit IRC | 16:53 | |
| *** ssam2 has quit IRC | 16:58 | |
| jjardon[m] | ssam2: persia thanks for your inputs | 16:59 |
| *** adds68 has quit IRC | 17:02 | |
| *** adds68 has joined #buildstream | 17:02 | |
| *** jonathanmaw has quit IRC | 17:05 | |
| *** noisecell has quit IRC | 17:14 | |
| *** valentind has joined #buildstream | 17:25 | |
| *** tiago has quit IRC | 17:42 | |
| *** adds68 has quit IRC | 18:11 | |
| *** Prince781 has quit IRC | 18:57 | |
| *** Prince781 has joined #buildstream | 19:00 | |
| *** aday has quit IRC | 19:12 | |
| *** Prince781 has quit IRC | 19:34 | |
| *** Prince781 has joined #buildstream | 19:47 | |
| *** Prince781 has quit IRC | 19:51 | |
| *** valentind has quit IRC | 20:57 | |
| *** valentind has joined #buildstream | 20:57 | |
| *** mcatanzaro has quit IRC | 21:07 | |
| *** cs_shadow has quit IRC | 22:17 | |
| *** valentind has quit IRC | 22:59 | |
| *** mcatanzaro has joined #buildstream | 23:53 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!