*** jude has joined #buildstream | 07:00 | |
*** dabukalam has quit IRC | 07:40 | |
*** dabukalam has joined #buildstream | 07:42 | |
*** jonathanmaw has joined #buildstream | 08:17 | |
*** tristanmaat has joined #buildstream | 08:18 | |
*** ssam2 has joined #buildstream | 09:06 | |
*** tristan has joined #buildstream | 09:50 | |
tristan | jonathanmaw, ok so the no dpkg --configure is intentional, I forgot to mention | 09:52 |
---|---|---|
tristan | jonathanmaw, but for your purposes doing it locally on host-arch compatible machine, doing the configures is probably fine anyway | 09:53 |
jonathanmaw | tristan: ok. my problem is that building requires awk, and mawk doesn't install the symlink unless it runs configure | 09:53 |
tristan | Note that the way I'm doing it for gnome builds is: https://gitlab.com/BuildStream/gnome-modulesets-base/blob/master/elements/base-configure.bst | 09:53 |
jonathanmaw | aha | 09:54 |
tristan | so you could just use gnome-modulesets-base as a base for your testing, and just rewire base-system.bst to your local debootstrap-ostree creation | 09:54 |
tristan | and just make your element depend on base.bst | 09:54 |
tristan | there are a couple of tricks I do in that repo actually | 09:54 |
tristan | one of them is the linker-priority.bst | 09:54 |
tristan | I also do this in the jhbuild2bst generated project.conf: | 09:55 |
tristan | environment: | 09:55 |
tristan | LDFLAGS: -L%{libdir} | 09:55 |
tristan | LD_LIBRARY_PATH: '%{libdir}' | 09:55 |
tristan | PATH: /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin | 09:55 |
tristan | PKG_CONFIG_PATH: '%{libdir}/pkgconfig' | 09:55 |
tristan | for distutils (python) build elements I install into /usr/local, because of setuptools being a bastard | 09:56 |
tristan | that's why the PATH thing is there | 09:56 |
tristan | (you wouldnt need that anyway) | 09:56 |
tristan | jonathanmaw, then again... for your purposes, hacking your local copy of debootstrap-ostree could just make it configured | 09:57 |
tristan | jonathanmaw, the multistrap.conf.in does: | 09:58 |
tristan | ignorenativearch=true | 09:58 |
tristan | Which is the thing that causes it to avoid doing dpkg --configure even if it happens to be a native arch | 09:58 |
tristanmaat | tristan, any ideas for which current issues might be a good place to start? I'm looking at issue #15 atm | 10:12 |
jonathanmaw | tristan: I get a whole bunch of errors while configuring when running with ignorenativearch=false. I'll use base-configure. | 10:14 |
tristan | jonathanmaw, sure, we ignore the errors but yeah :) | 10:21 |
tristan | jonathanmaw, things are sure to go wrong, but after fixing the ultimate #38... I suspect that we might get no errors from that anymore | 10:22 |
tristan | tristanmaat, ummm, that's quite involved, I wouldnt recommend that as a starting point | 10:23 |
tristan | is there a reason you need that soon ? | 10:23 |
tristan | tristanmaat, I am half hoping we can NOTABUG that one, but maybe it will be necessary, but it involves reinventing how artifacts are stored | 10:24 |
tristanmaat | Not as far as I know. I'm mostly just looking for something to do that I can sensibly tackle right now | 10:24 |
tristan | tristanmaat, this would be quite useful and is very easy: https://gitlab.com/BuildStream/buildstream/issues/24 | 10:24 |
tristan | tristanmaat, basically the gist of that means that, if someone does a typo and writes something like 'rev' instead of 'ref' in a bst element, the engine currently wont tell the user about it | 10:28 |
tristan | it would need a new API on plugin.py, and the elements and sources would have to use it to validate their configurations; also the loader could use the same code | 10:30 |
tristan | probably in _yaml.py we want something that takes a dictionary as input and lists the keys which are valid for a dictionary, something like _yaml.validate_node() would be good | 10:30 |
tristanmaat | Yup, I got that :) I'll see how quickly I can read into this, I haven't done much with YAML parsing before, but it doesn't seem too hard. | 10:30 |
tristan | tristanmaat, ok well, go directly to _yaml.py and also look at plugin.py for the apis we expose to plugin authors (Source and Element plugins derive from Plugin) | 10:31 |
tristan | tristanmaat, because there is already a bunch of helper code there | 10:31 |
tristan | tristanmaat, note that loaded nodes (we refer to the dicts as nodes in our internal lingo)... all have Provenance objects attached | 10:32 |
tristan | tristanmaat, also those contain Provenance info for each member, we use that extensively for raising exceptions | 10:32 |
tristan | that's how we deliver the original file column/line info to the user | 10:33 |
tristan | so there is already a bunch of code that is helpful, most notably you want to look at Plugin.node_get_member() | 10:33 |
tristan | which will fire an exception | 10:33 |
tristanmaat | Ok, thanks, that helps a bunch | 10:34 |
gitlab-br-bot | push on buildstream@safe-hardlinks (by Tristan Van Berkom): 1 commit (last: _sandboxbwrap.py: Handle EBUSY when trying to remove bubblewrap's device bind mounts) https://gitlab.com/BuildStream/buildstream/commit/91817a5f0130609f5c31330a1e2a7079041b63d2 | 10:38 |
tristan | jonathanmaw, can you give safe-hardlinks branch another try ? | 10:39 |
jonathanmaw | tristan: having a go now | 11:44 |
tristan | nice | 11:45 |
tristan | I'm on the trail of reaping child processes on termination | 11:46 |
jonathanmaw | tristan: I haven't failed while staging any dependencies yet, so I'm hopeful | 11:46 |
tristan | It looks like, when forcefully terminating with ^C in non-interactive mode, everything is always reaped | 11:47 |
tristan | jonathanmaw, you did not before | 11:47 |
tristan | jonathanmaw, that was not while staging | 11:47 |
jonathanmaw | it's running some configure-commands right now, looks like it's building the kernel :¬| | 11:48 |
tristan | do you have some concurrent builds going on ? | 11:48 |
jonathanmaw | tristan: there were some other tasks, iirc. | 11:49 |
tristan | jonathanmaw, ummm, can you let it complete a couple of builds ? | 11:51 |
tristan | just want to feel a bit safer | 11:52 |
jonathanmaw | tristan: yep | 11:52 |
jonathanmaw | looks like I'm building systemd, gdb and lsof as well as the kernel, currently | 11:52 |
tristan | I'm confident in the code... but the change in the nature of the build significantly changes with this | 11:52 |
tristan | as seen with the leaked device files with bwrap, many systems react differently | 11:53 |
tristan | jonathanmaw, ok just let me know when one of them completes and it rolls over to the next build | 11:53 |
jonathanmaw | lsof finished, and it's building syslinux, if that helps | 11:54 |
tristan | then lets land the crazy hardlinking thing | 11:54 |
tristan | alright... lets do it | 11:54 |
tristan | I have been few days with this now and it's working fine here, found an issue on your system | 11:54 |
tristan | I think we're a go | 11:54 |
gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 13 commits (last: Added fusepy dependency to setup.py) https://gitlab.com/BuildStream/buildstream/commit/711f9716d88cd8ff31d4c5845faa8393aea23fba | 11:58 |
tristan | alright, here goes nothing :) | 11:58 |
gitlab-br-bot | buildstream: Tristan Van Berkom deleted branch safe-hardlinks | 11:58 |
gitlab-br-bot | buildstream: issue #19 ("Artifacts can get corrupted while running integration commands") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/19 | 12:04 |
tristan | nice | 12:04 |
tristan | Ok NB ALL: developer checkouts will require a `pip uninstall buildstream && pip install --user -e .` after pulling recent master | 12:05 |
tristanmaat | Is there anything that contains valid member names yet? Or should I take that from the documentation? | 12:15 |
tristan | tristanmaat, the documentation is a good starting point... | 12:17 |
tristan | tristanmaat, I think you should start with a low level _yaml.validate_node(node, valid_members) | 12:17 |
tristan | where node is a dict loaded with yaml, and valid_members is a list of strings | 12:18 |
tristan | and it raises a LoadError | 12:18 |
tristanmaat | Okay, that makes sense. | 12:18 |
tristan | tristanmaat, for a simple starting point, you can try using it in context.py, which parses the user configuration | 12:19 |
tristan | which is: https://buildstream.gitlab.io/buildstream/config.html#config | 12:19 |
tristan | tristanmaat, so we'll want it first implemented for context.py, project.py and _loader.py (which is a bit more involved) | 12:20 |
tristan | after that we can look at adding a Plugin.validate_node() API, or perhaps a simpler API for plugins to use | 12:21 |
tristanmaat | Are the tests for context.py and loader.py independent? | 12:22 |
tristan | well, mostly | 12:22 |
tristan | context.py is mostly independent, I think it's also true for _loader.py | 12:22 |
tristanmaat | Oh, I need to worry about python3 on this system. Gotcha | 12:23 |
tristan | tristanmaat, the test cases were developed very early on so most of it is very stand-alone actually, but for the sake of convenience of writing tests, it might be good to change that in the future | 12:23 |
tristan | We need >= 3.4 | 12:23 |
tristanmaat | Okay, I think I can actually do something now. Thanks again! | 12:24 |
tristan | tristanmaat, you might look at the HACKING file for a bit more guidance... also dont forget to install with the -e option | 12:24 |
tristan | `pip install --user -e` | 12:25 |
tristan | that will ensure that when you run buildstream, it is run directly from your git checkout | 12:25 |
tristan | otherwise you might find yourself testing things and wondering why your changes are not having any effect :) | 12:25 |
tristanmaat | Yup, already done :) | 12:26 |
jonathanmaw | tristan: I'm getting crashes related to https://gitlab.com/BuildStream/buildstream/commit/d17d99446436334190e3328c4ffdc05ab12892b0#a84d27007c711cee67dd0e3493451db8d78c946a_201_200 | 12:26 |
jonathanmaw | item['element'] is a string, I assume you expected it to be an Element. | 12:26 |
tristan | tristanmaat, I also fully expect that the test cases will have to be modified as a result of your change, i.e. they *probably* contain some invalid yaml | 12:26 |
tristan | jonathanmaw, oh shit | 12:26 |
tristan | sorry | 12:26 |
tristanmaat | Should this throw INVALID_YAML or INVALID_DATA, btw? | 12:27 |
tristan | jonathanmaw, my change was because I was seeing https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/plugin.py#L73 in messages: "staging {} at {}" | 12:28 |
tristan | jonathanmaw, that looks much better as an element.name, not a "{}".format(element) | 12:28 |
tristan | the latter is more appropriate in exceptions | 12:28 |
tristan | tristanmaat, INVALID_DATA is more appropriate, the INVALID_YAML I added for translating errors from the underlying parser | 12:29 |
tristan | jonathanmaw, Can you fix it ? And just make sure that element *names* are printed there, not formatted element objects ? | 12:30 |
jonathanmaw | tristan: ok. Also, it looks like https://gitlab.com/BuildStream/buildstream/commit/d39122416192c94fa1deef5053b5e288f8bbf826#b988c7a01766a2dbd7ba8aa301ac7dcf5f75e42f_0_62 snuck in, too | 12:30 |
jonathanmaw | plus I had a problem with missing dirs on bzr elements. | 12:31 |
jonathanmaw | I'll prepare a merge request of misc fixes. | 12:31 |
tristan | :-/ | 12:31 |
tristan | So it's calling a non-existing validate_layout(), when it doesnt need a preflight method at all | 12:31 |
tristan | somehow I missed that | 12:31 |
jonathanmaw | yep | 12:32 |
tristan | I wonder if I merged the wrong MR ? | 12:32 |
jonathanmaw | I'm sure I removed it, too | 12:32 |
tristan | crap | 12:32 |
tristan | And that was the time that gitlab decided to have a default enabled "feature" that squashes all commits on an MR :-S | 12:32 |
tristan | which it seems, they have removed that destructive feature altogether now | 12:32 |
tristan | wow, so I submitted an MR to https://github.com/skorokithakis/python-fuse-sample after finding that his example (which I found helpful) had link/symlink parameters backwards | 12:37 |
jonathanmaw | hrm, I'm failing to repeat the problem with bzr, now. maybe it was incidentally fixed in master . | 12:37 |
tristan | And... my MR was merged *in seconds* | 12:37 |
tristan | literally, and again; I commented on one thing there, and he replied *in seconds*, I am a bit worried about this guy | 12:38 |
tristan | I hope he takes time to eat sometimes :) | 12:38 |
* tristan found it quite astonishing to be watching the github page where he submitted the request, and it being merge before his very eyes | 12:39 | |
ssam2 | some people set up notification streams that mean they see PRs in real time | 13:09 |
tristan | yyyyeeaaaaaah | 13:11 |
tristan | I can see that *someone* thinks I never review code in a timely manner ! | 13:12 |
tristan | hehe | 13:12 |
ssam2 | i think its crazy personally, every PR should be left to ripen for a bit :-) | 13:13 |
*** Chris has joined #buildstream | 13:16 | |
jonathanmaw | tristan: I think I'm seeing the change to the filesystem at work, now. either that or I've been bitten by it not attempting to assemble the artifact due to it already existing - when assembling base-system-image, it's failing to create /buildstream/sda1 because it's a read-only file system. Time for me to figure out the correct way to make /buildstream so that it's not protected. | 13:17 |
tristan | jonathanmaw, It's my fault | 13:24 |
tristan | jonathanmaw, sounds like you found something that I overlooked | 13:24 |
jonathanmaw | tristan: ok. Since you know the most about how the sandboxing works, shall I leave it to you to implement? | 13:25 |
jonathanmaw | or shall I figure out how the sandboxing works and implement it? | 13:25 |
tristan | jonathanmaw, ok so how to fix this is the question... is it pretty safe to say that with ScriptElement's 'layout' API, anything that is not at the root is going to be read-write ? | 13:25 |
tristan | jonathanmaw, it will be very easy to fix, my greater concern is API | 13:26 |
tristan | Oh but now... I see | 13:26 |
tristan | Okay | 13:26 |
tristan | I think I will have to fix this... I was wondering if I would need this or not | 13:26 |
tristan | ok to answer my own question, yes; any non-root mount will always be read-write | 13:30 |
tristan | we dont need to budge on that really | 13:30 |
tristan | jonathanmaw, Ok so... this might take me an hour... I suppose you are blocking on this ? | 13:33 |
tristan | jonathanmaw, for *right now*... you should go into the ScriptElement configure_sandbox() method... | 13:34 |
tristan | jonathanmaw, and you should call sandbox.mark_directory() for each part of the layout needs to be read-write | 13:34 |
*** jonathanmaw has quit IRC | 13:35 | |
tristan | jonathanmaw, what I'm going to do in the meantime, is add a keyword argument to Sandbox.mark_directory() ... | 13:35 |
tristan | oops | 13:35 |
tristan | Well, I'll finish this what I'm doing first, and then I'll get to that | 13:36 |
tristan | But now I think anyway he's not blocking on this for the deb stuff | 13:36 |
ssam2 | good news about the safe-hardlinks branch! that should really improve IO performance right? now that we aren't compressing and decompressing everything all the time | 13:37 |
gitlab-br-bot | buildstream: merge request (jonathan/fixes->master: Fix some bugs that slipped through) #23 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/23 | 13:38 |
*** jonathanmaw has joined #buildstream | 13:39 | |
tristan | ssam2, right, last week I added a temporary thing to work around it so that the artifact cache was using compression | 13:47 |
tristan | ssam2, the thing was... not only does ostree checkout as hardlinks (which means I was already corrupting the cache but nobody had to know about it... sneaky)... | 13:47 |
tristan | ssam2, but if a file is the same, and only differs in name, e.g. all of those 0644 empty files... then they are also linked together ! | 13:48 |
tristan | so when I ran the dpkg --configure on a checkout like that, I would get all empty files modified (mostly __init__.py files) with some content | 13:49 |
tristan | hah | 13:49 |
ssam2 | i hit exactly the same issue a few years ago | 13:49 |
ssam2 | that was the final blocker to the project to switch Morph to using OSTree | 13:49 |
tristan | anyway yeah that's fixed and builds will both be faster and consume less disk space | 13:49 |
ssam2 | but we were out of time so Morph never got switched to using OSTree :-( | 13:49 |
tristan | jonathanmaw, ok so that was assembling an image, so my assumption is that you are not blocking on this for the debian related elements correct ? | 13:50 |
tristan | jonathanmaw, I'm on it... I need an added feature to the sandbox API, and I need to factor in how this should ideally fit into the ScriptElement API and it's image subclass | 13:50 |
tristan | ssam2, I'm very happy with the copy-on-write hardlinks, though :) | 13:51 |
tristan | ssam2, and it's a great starting point to implement our own fakeroot as a fuse layer, too | 13:51 |
jonathanmaw | tristan: I'm not blocking from it at the moment. base-configure.bst should be run without the rootfs being read-only, so I'm safe. | 13:52 |
ssam2 | tristan, yeah that is a good fix | 13:53 |
ssam2 | actually we had that too, with overlayfs | 13:53 |
ssam2 | the issue was that the system images we produced *also* had all the 0-byte files hardlinked to the same thing | 13:53 |
ssam2 | so the machine would boot, systemd would write a hex string to /etc/machine-id, and every __init__.py file on the system would contain that hex string as well | 13:54 |
ssam2 | which of course caused weird failures in Python programs | 13:54 |
tristan | ssam2, aha, so I did put some thought into this, and had considered filing an ostree bug for it | 13:54 |
tristan | I think *that* bug is something we still have | 13:54 |
tristan | I'll file a bug straight away... | 13:55 |
tristan | Not sure how much people will care about it, but I'll try to make a good case :) | 13:55 |
ssam2 | yeah, I guess the issue is that OSTree is "one way" right now | 13:56 |
ssam2 | your files go in, get deduplicated, but you can't undo that process. | 13:56 |
tristan | ssam2, my opinion is that, even if it's a good optimization, somehow saving the state of *which files* were linked together at commit time, and having at least an option for preserving that at hardlink checkout time is useful | 13:56 |
tristan | ssam2, however that, what you say, is untrue since recently at least | 13:56 |
tristan | so actually, it's not *necessarily* a problem | 13:57 |
tristan | but, my feeling is that in some edge cases, a system itself has an expectation that some files are hardlinks | 13:57 |
ssam2 | ah, if it's possible to preserve info on what files were linked together already, then we're good | 13:57 |
tristan | ssam2, not what I want no, but checking out while forcing files to not be hardlinks is an option | 13:57 |
ssam2 | ah OK | 13:58 |
tristan | that is since some time this year | 13:58 |
ssam2 | less of a disaster for us than before then, anyway :-) | 13:58 |
tristan | --force-copy or such | 13:58 |
tristan | yeah | 13:58 |
tristan | But you know, running dpkg --configure on that sysroot creates a bunch of hardlinks | 13:58 |
ssam2 | but for real systems I think you're right, we'll need OSTree to become a "two-way" store | 13:58 |
ssam2 | and keep track of what used to be a hardlink | 13:59 |
tristan | So I *wonder*, I think it's quite plausible for a system to want the same file to be available in more than one place, and then intentionally write to that file | 13:59 |
tristan | Looks like gitlab's destructive squash commits "feature" re-appeared, but disabled checkmark by default this time | 14:00 |
tristan | Someone is watching while I complain in #gitlab :) | 14:00 |
gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 2 commits (last: x86image: Fix erroneous call to validate_layout) https://gitlab.com/BuildStream/buildstream/commit/1ef4b6878a7694b774b37096ca098338cf81dc30 | 14:01 |
gitlab-br-bot | buildstream: merge request (jonathan/fixes->master: Fix some bugs that slipped through) #23 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/23 | 14:01 |
jonathanmaw | ta tristan | 14:02 |
tristanmaat | So, my "low level" implementation passes its tests. I still have the problem that I can't find valid members for a given key though - the simplest way would be to define a huge dict of key-member pairs, but that doesn't seem very neat. | 14:04 |
tristan | tristanmaat, I would think at least for the low level, a single list-of-keynames is sufficient | 14:12 |
tristan | tristanmaat, for instance, the Context object parses a few sub dictionaries, it can easily have one call to _yaml.node_validate() for each of them right ? | 14:12 |
tristanmaat | That's how I have been testing it, it just looks quite messy. I guess there is not much of an option though. | 14:14 |
tristan | tristanmaat, well | 14:22 |
tristan | tristanmaat, what about an API which does both somehow ? | 14:22 |
tristan | I.e. I can imagine that it will look redundant in code, you have to list out the strings twice, and their expected types once | 14:23 |
tristan | tristanmaat, maybe something which constructs and returns a tuple of values, doing _yaml.node_get() and _yaml.node_validate() in one shot... so that calling code could do something like: | 14:24 |
tristan | self.foo, self.bar = _yaml.node_get(node, [(foo, str), (bar, int)]) ? | 14:25 |
tristan | or rather | 14:25 |
tristan | self.foo, self.bar = _yaml.node_get(node, [("foo", str), ("bar", int)]) ? | 14:25 |
tristan | tristanmaat, not sure if that would be better, it would be less redundant, though | 14:26 |
tristan | oh yeah, there is also the default value to node_get() to consider, that when left unspecified/None means, that the parsed yaml *must* provide a value | 14:27 |
tristan | self.foo, self.bar = _yaml.node_get(node, [("foo", str, None), ("bar", int, 10)]) ? | 14:28 |
tristanmaat | Hm. Well, it would look a bit less redundant | 14:28 |
tristan | for a required "foo" and a default 10 optionally specified "bar" | 14:28 |
tristan | Right, but then, it would also be harder to read | 14:28 |
tristan | tristanmaat, I tend to favor readability over saving lines of code to be honest | 14:29 |
tristan | but if it can look comprehensive, maybe it's better ? | 14:29 |
tristan | I have a feeling that _yaml.node_get_multi() could be interesting | 14:29 |
tristan | jonathanmaw, ssam2, care to weigh in ? | 14:30 |
tristanmaat | I think it's the better call to just leave it a bit messy. I like this notation, but it would be hard to understand on first glance. | 14:30 |
tristan | right | 14:30 |
tristan | I'm a bit ambivalent anyway | 14:30 |
tristan | I care more about the plugin author facing API, and I have a feeling that those configurations are less complex than what we have to parse in the core | 14:31 |
tristanmaat | Cool, I'll finish implementing this then and look at the API | 14:32 |
tristan | nice :) | 14:32 |
tristan | ssam2, filed https://github.com/ostreedev/ostree/issues/925 in case you're interested | 14:40 |
gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 5 commits (last: utils.py: Added _kill_proc_tree()) https://gitlab.com/BuildStream/buildstream/commit/d13ef0ac12224647c665171fb65ce60e760b840a | 14:52 |
tristan | damn process termination, made more robust *again* | 14:53 |
tristan | There is still a trailing case | 14:53 |
tristan | In *some* cases we hit a 20 second timeout when trying to terminate one of the jobs, quite rare, in that case there is a warning about it and we just exit with an unreaped child; but we do do a kill -9 on everything after that timeout | 14:54 |
tristan | Unfortunately that can leave a stale SafeHardlinks mount around | 14:55 |
*** tristan has quit IRC | 15:02 | |
*** tristan has joined #buildstream | 15:15 | |
*** ChanServ sets mode: +o tristan | 15:15 | |
jonathanmaw | aha! looks like I've pulled in the necessary dependencies now! It finishes building, and then... | 16:46 |
jonathanmaw | "error: unable to create '../libpython3-all-dbg_3.5.3-1_amd64.deb': Read-only file system" | 16:46 |
jonathanmaw | now I can drop into the shell to see what I'm left with | 16:46 |
*** jonathanmaw has quit IRC | 17:04 | |
*** tristanmaat has quit IRC | 17:17 | |
*** jude has quit IRC | 17:22 | |
*** ssam2 has quit IRC | 17:51 | |
*** jude has joined #buildstream | 18:09 | |
*** jude has quit IRC | 18:17 | |
*** jude has joined #buildstream | 18:33 | |
*** pum has joined #buildstream | 20:00 | |
pum | #CHARYBDIS ON FREENODE (amdj) | 20:02 |
pum | | | | | ____| | | __ \ | 20:02 |
pum | | |__| | |__ | | | |__) | | 20:02 |
pum | | __ | __| | | | ___/ | 20:02 |
pum | | | | | |____| |____| | | 20:02 |
pum | |_| |_|______|______|_| | 20:02 |
pum | SOMEONE TOOK OUR WEBSITE AND WE NEED | 20:02 |
pum | HELP AND SUPPORT TO GET IT BACK UP!! | 20:02 |
pum | jude tristan Chris dabukalam tiagogomes violeta juergbi mattiasb jjardon[m] albfan[m] waltervargas[m] ironfoot persia gitlab-br-bot brlogger hergertme Laurence | 20:02 |
*** pum has left #buildstream | 20:02 | |
*** hergertme has quit IRC | 20:13 | |
*** hergertme has joined #buildstream | 20:14 | |
*** jude has quit IRC | 20:16 | |
* persia speculates that the website hijack was a result of unsolicited IRC traffic | 21:01 | |
*** tristan has quit IRC | 21:08 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!