| *** saxa has joined #buildstream | 00:16 | |
| *** tristan has quit IRC | 04:10 | |
| *** tristan has joined #buildstream | 04:38 | |
| ltu | is there a difference between 'creating a new project' and 'authoring a project'? | 05:01 |
|---|---|---|
| tristan | Slight one I would say there is | 05:14 |
| tristan | creating a new project is a one time thing, while I would say authoring a project may imply maintenance, and anything to do with editing bst files and project.conf | 05:15 |
| tristan | I'm admittedly guessing into the context and thinking the motivation hiding behind the question has to do with documentation | 05:16 |
| ltu | correct | 05:16 |
| ltu | ok that makes sense then, thanks | 05:17 |
| ltu | tristan, I'm making a list of what's done and what is left to do, to see where any remaining gaps will be after the current branch from nexus is merged | 05:24 |
| ltu | we can review it later this week :) | 05:24 |
| gitlab-br-bot | buildstream: issue #183 ("Plugin loading documentation is confusing") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/183 | 07:07 |
| tristan | juergbi, I havent *really* got deep into reviewing junctions yet | 07:50 |
| tristan | juergbi, as it's been in the back of my mind since last week, I just wanted to clarify that the options thing is not really a blocker to me, it's really just the first thing that jumped out at me while looking at the changes | 07:51 |
| juergbi | ok. as i mentioned, if it wasn't for flags, i would have implemented it differently | 07:52 |
| juergbi | i hope i can update the branch today with regards to the multi-cache changes | 07:53 |
| tristan | Yeah I went through a review of that today... | 07:54 |
| tristan | I hope to land it asap too | 07:54 |
| juergbi | great | 07:55 |
| tristan | for multi-cache, this comment is the tricky part for me: https://gitlab.com/BuildStream/buildstream/merge_requests/166#note_53638563 | 07:57 |
| tristan | or two comments rather | 07:57 |
| tristan | "When an artifact is built locally, BuildStream will try to push it to the first writable cache in the list" | 07:58 |
| tristan | maybe if we only want to push to one artifact server, the configuration should identify which one(s) to push to | 08:00 |
| *** noisecell has joined #buildstream | 08:30 | |
| *** jude has joined #buildstream | 08:45 | |
| *** valentind has joined #buildstream | 09:18 | |
| *** harshitaneja has joined #buildstream | 09:43 | |
| *** jonathanmaw has joined #buildstream | 09:48 | |
| *** ernestask[m] has joined #buildstream | 09:49 | |
| *** ssam2 has joined #buildstream | 10:04 | |
| *** tiago has joined #buildstream | 10:08 | |
| *** ernestask has joined #buildstream | 10:10 | |
| *** valentind has quit IRC | 10:49 | |
| *** jude has quit IRC | 11:31 | |
| *** jude has joined #buildstream | 11:59 | |
| *** mcatanzaro has joined #buildstream | 12:40 | |
| *** harshitaneja has quit IRC | 12:49 | |
| gitlab-br-bot | buildstream: issue #183 ("Plugin loading documentation is confusing") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/183 | 13:02 |
| tristan | In the hope of expediting these patch reviews... any thoughts on https://gitlab.com/BuildStream/buildstream/merge_requests/181#note_53643337 ? | 13:14 |
| tristan | I feel like whitelisting overlaps in the sense that "I am an element but I dont care if some of what I install is later overwritten" is conceptually backwards | 13:15 |
| tristan | but lets think about it; first, it would seem that you might have to write less YAML to whitelist things that way | 13:15 |
| tristan | But then, maybe more than one element overwrites this file, that should be a separate warning anyway right ? | 13:16 |
| tristan | Yeah - maybe my talking to myself here is enough... I think that's correct | 13:16 |
| tristan | Later it might be interesting to some to have a project wide whitelist too, but that could be a separate feature that maybe noone will ever ask for | 13:17 |
| jonathanmaw | Hi tristan, I'm writing a response in the merge request right now | 13:19 |
| jonathanmaw | once I've gotten my head around some of the use-cases of overlaps, and how that affects whether we'd prefer to have configuration as "this can overlap" or "this can be overlapped", I'll send it. | 13:20 |
| tristan | Just added my comment to the bug report | 13:22 |
| tristan | jonathanmaw, it's pretty clear I think; the current approach is lossy and error prone | 13:23 |
| tristan | See the example I made in the last comment | 13:23 |
| * jonathanmaw refreshes | 13:23 | |
| tristan | Intuitively it felt wrong - because an element by itself can be stand alone, intuitively I think it should not have knowledge of it's reverse dependencies; that lead me to the line of thinking | 13:24 |
| tristan | but looking further it's clear that it's a different warning; i.e. there is a warning for every artifact which overwrites a given file that already exists, those are separate warnings | 13:25 |
| tristan | we should not be allowed to silence them all at once | 13:26 |
| tristan | otherwise undesired overlaps stemming from newly added elements later fall through the cracks | 13:26 |
| *** tristan has quit IRC | 13:38 | |
| *** tristan has joined #buildstream | 13:41 | |
| jonathanmaw | tristan: okay, seems sensible to do it the other way. I've got some questions about your other questions, though | 13:44 |
| jonathanmaw | that I asked in the merge request. | 13:44 |
| ssam2 | i fixed a pet hate of mine | 13:45 |
| ssam2 | https://buildstream.gitlab.io/ now redirects to the docs | 13:45 |
| ssam2 | also, https://buildstream.gitlab.io/ exists with a really minimal website setup that does the redirect | 13:45 |
| ssam2 | bah, the second link should be https://gitlab.com/BuildStream/buildstream.gitlab.io | 13:45 |
| *** xjuan has joined #buildstream | 13:46 | |
| tlater | Ah, ta ssam2, that also annoyed the hell out of me | 13:47 |
| *** xjuan has quit IRC | 15:02 | |
| *** xjuan has joined #buildstream | 15:02 | |
| *** xjuan has quit IRC | 15:05 | |
| *** xjuan has joined #buildstream | 15:05 | |
| gitlab-br-bot | buildstream: merge request (sam/meson->master: WIP: use Meson instead of setuptools to install and distribute BuildStream) #196 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/196 | 15:53 |
| *** noisecell has quit IRC | 15:53 | |
| mcatanzaro | Hi, anyone (jjardon[m]) around to help a fool try to learn how to use BuildStream? I'm trying to open a workspace to hack on epiphany but getting a weird error: git source at core/epiphany.bst [line 3 column 2]: expected ref 'None' was not found in git repository: 'https://git.gnome.org/browse/epiphany' | 15:57 |
| mcatanzaro | Full output: https://paste.gnome.org/p8qlxbodd/u3h32j/raw | 15:57 |
| mcatanzaro | I'll ping tristan on the off chance he's not asleep in Asia right now.... | 15:59 |
| ssam2 | mcatanzaro, could you paste the core/epiphany.bst file ? | 16:00 |
| ssam2 | or is it unchanged from a commit of gnome-modulesets.git ? | 16:00 |
| mcatanzaro | ssam2: It's unchanged... actually maybe that's the problem, I probably need to track it first | 16:00 |
| ssam2 | ah yes | 16:01 |
| ssam2 | bit of a rubbish error message though | 16:01 |
| mcatanzaro | Yes, error message needs to be better | 16:01 |
| ssam2 | do you have time to file an issue ? | 16:01 |
| mcatanzaro | Sure can | 16:01 |
| mcatanzaro | Also, next question: are you Sam Thursfield? Or different Sam? | 16:02 |
| ssam2 | i am that sam :-) | 16:02 |
| mcatanzaro | Also, next question: where's the bugtracker? | 16:02 |
| ssam2 | we're on gitlab.com | 16:02 |
| ssam2 | so https://gitlab.com/BuildStream/buildstream/issues | 16:02 |
| mcatanzaro | OK | 16:02 |
| ssam2 | once upon a time i used an irc client that would set realname, but no longer apparently | 16:03 |
| mcatanzaro | Also, next question: is modifying my local checkout of the repos, and only executing buildstream from within that checkout, really the way that development with buildstream is supposed to work? It's not very convenient relative to jhbuild. | 16:03 |
| ssam2 | I don't quite follow what you mean | 16:03 |
| ssam2 | i think that is how things are supposed to work, but i'm interested what the issues are vs. jhbuild | 16:04 |
| mcatanzaro | To use buildstream, I have to cd into its git repo, right? | 16:04 |
| ssam2 | you have to run it in the git repo of the *project* | 16:04 |
| ssam2 | you can also do `bst -C $projectdir` to run it from somewhere else | 16:04 |
| mcatanzaro | Ah yes, well that would be gnome-modulesets... so I 'cd ~/Projects/gnome-modulesets' first before doing anything else. I guess that's OK. | 16:05 |
| mcatanzaro | I can get used to that... it's a step that I don't have to do in jhbuild, though. Maybe it'd be nice to be able to configure a default project? | 16:05 |
| ssam2 | that might be nice | 16:05 |
| ssam2 | although you could equally `alias bstgnome=`bst -C /path/to/gnome-modulesets.git` | 16:06 |
| mcatanzaro | Anyway, that workflow seems to interact badly with 'bst track' which modifies the local projects | 16:06 |
| ssam2 | (except with correct shell syntax :-) | 16:06 |
| ssam2 | how so ? | 16:06 |
| mcatanzaro | I guess I'm just not super happy about how 'bst track' modifies my local projects | 16:06 |
| ssam2 | there is a way to avoid that | 16:06 |
| ssam2 | i can't remember the exact arguments, it changed at some point | 16:07 |
| mcatanzaro | Say I want to pull the new version of the modulesets... I can't 'git pull' because I have to 'git reset --hard @' first and that undoes all the work of 'bst track' | 16:07 |
| ssam2 | `bst build --track-all` | 16:07 |
| ssam2 | says "run a build, track everything, don't save the tracked refs` | 16:07 |
| ssam2 | where `bst build --track-all --track-save` does the same effectively as `bst track --all; bst build` | 16:07 |
| ssam2 | or, would it help to use `git stash` before pulling ? | 16:08 |
| ssam2 | i've not used this feature in anger yet ... personally i like having the refs written to disk, so that i don't unexpectedly get new changes | 16:08 |
| mcatanzaro | Making modifications to a git repository just seems ugly... I would have saved the modifications somewhere else, maybe under ~/.local/share/buildstream | 16:08 |
| mcatanzaro | I do have to regularly pull the new modulesets manually, right? E.g. if someone adds a new dependency to some module, buildstream is not going to magically know about that until I 'git stash' and then 'git pull' (and 'git stash pop') | 16:10 |
| ssam2 | that would be quite a drastic change conceptually; not that it couldn't happen, but the best person to discuss with is Tristan | 16:10 |
| ssam2 | and yeah, you do have to pull new modulesets | 16:10 |
| ssam2 | the self-modifying is definitely on an ugly/convenient spectrum | 16:11 |
| ssam2 | some projects like to have exact refs stored in Git | 16:11 |
| ssam2 | for that use case, having something that updates the actual files with new refs is super useful | 16:11 |
| ssam2 | but we are trying to use the same mechanism to emulate jhbuild's "always build master" functionality, which is not quite equivalent | 16:12 |
| ssam2 | (personally i quite like having refs committed to Git ... fewer surpises that way ... but it's not how jhbuild has ever worked) | 16:12 |
| mcatanzaro | I think it's too hard: we don't want to have to teach users about git stash in order to get the new GNOME projects. Honestly, ideally it would pull the projects from the *server* and not look locally at all, so that they are always up-to-date. Like JHBuild. Only experienced developers need to modify the projects usually. | 16:14 |
| ssam2 | we're going to recommend `bst build --track-all` as the default | 16:14 |
| mcatanzaro | OK, can you update https://wiki.gnome.org/action/show/Newcomers/BuildSystemComponent with that information? Right now the instructions there are different. | 16:15 |
| mcatanzaro | Maybe if --track-all is going to be recommended, that should be the default behavior...? | 16:15 |
| ssam2 | other projects won't want that | 16:16 |
| ssam2 | but perhaps it could be enabled in the project config | 16:16 |
| ssam2 | i didn't write that doc, i'd rather leave updating it to jjardon or tristan... but will make a note to follow up tomorrow | 16:16 |
| * tristan appears and reads backlog... | 16:18 | |
| mcatanzaro | Thanks! (and hi tristan!) | 16:18 |
| mcatanzaro | I will have more questions soon. I tried using it to develop libsoup tests yesterday, but couldn't figure out how to run 'make check' or get into the build directory at all. I was planning to review the buildstream documentation before asking for help with that, but, eh, I'm here now...! | 16:19 |
| tristan | Yeah it's certainly important to be able to store the very precise and exact ref of every source in a project | 16:21 |
| tristan | that's how you can tag a release and be absolutely sure that your project state reflects something that is exactly reproducible elsewhere | 16:21 |
| tristan | that said, we offer (build)+(track)-(save) as a solution for those who just want to build something on a project that has no refs stored yet, and get "whatever is latest" every time | 16:22 |
| tristan | (at the expense of course, of querying every single repo in the build plan over the network for it's latest version) | 16:23 |
| tristan | mcatanzaro, what it looks like to me, is that opening a workspace could do with some automatic tracking functionality built in | 16:24 |
| tristan | if I understand from a quick read of the backlog, this seems to be what caused the frustration | 16:24 |
| mcatanzaro | tristan: I was going to report a bug to improve the error message, like ssam2 suggested, but yeah, automatic tracking might work too | 16:25 |
| tristan | mcatanzaro, regarding the wiki fwiw; the --track-all stuff was one of the final things I wanted to land before 1.0 which we rolled out last week | 16:26 |
| tristan | that's why it's not on the wiki yet, indeed | 16:26 |
| * tristan puts that in his immediate todo list for tomorrow | 16:26 | |
| mcatanzaro | tristan: FYI: I moved the wiki page to replace the original jhbuild page. I added a redirect, should be seamless. | 16:28 |
| tristan | Nice | 16:28 |
| mcatanzaro | "I was going to report a bug to improve the error message, like ssam2 suggested, but yeah, automatic tracking might work too" --> but I discovered I need to register an account on GitLab. And the username "mcatanzaro" is already taken. So I need to think long and hard before hastily selecting a username. | 16:29 |
| tristan | Oh, and that last one... you probably want `bst shell --build <element>` | 16:29 |
| mcatanzaro | So maybe one of you can report the bug instead, sorry. :P | 16:29 |
| mcatanzaro | I'll try 'bst shell --build', thanks | 16:30 |
| jjardon[m] | Hi! seems buildstream needs the fuse module: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/47092921 It seems this is not documented? Should I open an issue? | 16:30 |
| tristan | There are 2 kind of shells, the default expects the element to be built, and stages it's runtime dependencies | 16:30 |
| tristan | the build shell stages the elements build dependencies and the sources and drops you into a shell where you can run the build yourself | 16:31 |
| tristan | thats meant for debugging the build stage | 16:31 |
| tristan | jjardon[m], dont open an issue no | 16:31 |
| tristan | jjardon[m], I believe the issue you are looking for, sounds like: https://gitlab.com/BuildStream/buildstream/issues/116 | 16:32 |
| jjardon[m] | ah ok, thanks tristan ! | 16:32 |
| tristan | jjardon[m], the fuse module, well we used to use fuse.py and then later merged a copy of it, because bugs... in both cases we fail to depend directly on fusermount | 16:33 |
| tristan | because distros can package it separately from libfuse | 16:33 |
| ssam2 | looking at the log jjardon posted | 16:33 |
| ssam2 | the actual issue seems to be that the kernel on the machine running the build had fuse support as a module, which wasn't loaded | 16:33 |
| tristan | but it looks like now since we dont depend on fuse.py, we additionally need to depend directly on libfuse | 16:33 |
| ssam2 | and because the build was running inside a container, the module couldn't be loaded with `modprobe fuse` | 16:33 |
| ssam2 | or maybe that's a side effect of needing fusermount | 16:33 |
| tristan | Ah, interesting, looks a bit more elaborate ;-) | 16:34 |
| ssam2 | all we can really do is document that your kernel needs FUSE support | 16:34 |
| tristan | ssam2, perhaps at that point, once we've done all the requiring we can do; we can say hey; your host is a bit messed up, are you in a vm or smth ? | 16:34 |
| tristan | yeah, documenting it will do :) | 16:34 |
| *** adds68_ has quit IRC | 16:35 | |
| jjardon[m] | tristan: ok, so I was already installing fuse in that machine, which includes fusermount, so I guess this a separate "issue"? | 16:37 |
| * tristan added some notes to https://gitlab.com/BuildStream/buildstream/issues/116 | 16:38 | |
| ssam2 | jjardon[m], the issue is that containers can't cause modules in the host to be loaded | 16:38 |
| ssam2 | jjardon[m], running `modprobe fuse` on the host should fix it | 16:38 |
| tristan | jjardon[m], meh, so very closely related I'd just treat it as the same issue, it's all about documenting the fuse needs | 16:38 |
| jjardon[m] | tristan: rigth | 16:39 |
| jjardon[m] | ssam2: tristan thanks for the comments! | 16:39 |
| mcatanzaro | tristan: What's the recommended workflow for running tests ('jhbuild buildone -n --check')? Is it to use 'bst shell --build' and run them manually? That's fine I guess. | 16:43 |
| tristan | mcatanzaro, for now yes, and very soon the UX for that should be greatly improved/optimized for workspaced builds | 16:48 |
| tristan | mcatanzaro, https://gitlab.com/BuildStream/buildstream/merge_requests/126 <-- there was already a lot of work done there, we're waiting for juergbi to land a little internal state handling refactor before massaging that branch in | 16:49 |
| tristan | So what should happen for a workspace build, is once you've built it once, you can build it again | 16:49 |
| tristan | and keep the .o files and everything littered around in the workspace | 16:49 |
| tristan | But, there is also another alternative, which we didnt do "just just yet", but is probably worth filing a bug for | 16:50 |
| tristan | Which is to include `test-commands` in the build elements to be run post build; we would probably want a variable to turn it on and off | 16:50 |
| tristan | There is some conflicting ideas on how to do that though; i.e. from a build optimization point of view, I'd really like to have separate elements running `make check`, and unblock later builds before running tests | 16:51 |
| tristan | That approach, would require https://gitlab.com/BuildStream/buildstream/issues/21 | 16:53 |
| gitlab-br-bot | buildstream: merge request (jjardon/fuse->master: doc/source/install.rst: BuildStream depends on 'fuse' (for fusermount) and libfuse) #214 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/214 | 16:53 |
| tristan | (I.e. theres no reason why I have to wait for glib tests to complete in order to build it's reverse deps; I can run them in parallel and fail the build as a whole after successfully building some reverse deps) | 16:54 |
| mcatanzaro | OK | 16:55 |
| mcatanzaro | tristan: Last question: what's your current timezone? Either you are up late, or you must not be in Korea? | 16:55 |
| tristan | mcatanzaro, it's about 2am | 16:56 |
| tristan | I should be ignoring IRC, but ya know... it gets my attention and cant escape it ;-) | 16:56 |
| mcatanzaro | Goodness. ZzzzzZZZZzzz. Well now I know you're a night owl, I won't feel bad about asking questions this late. :P | 16:56 |
| *** xjuan has quit IRC | 17:02 | |
| *** ssam2 has quit IRC | 17:04 | |
| *** xjuan has joined #buildstream | 17:15 | |
| *** tristan has quit IRC | 17:16 | |
| kailueke[m] | Who can push to the artifact cache? Still the case that only one machine is doing it or do individual people also have the possibility to upload their stuff? | 17:17 |
| *** tristan has joined #buildstream | 17:17 | |
| *** xjuan has quit IRC | 17:18 | |
| persia | kailueke[m]: I'm not authoritative, but I believe that A) there is restricted access to "the" artifact cache, being the default one, and that anyone can publish "an" artifact cache, and use that to upload their stuff. | 17:44 |
| persia | Err, s/and that/and (B) that/ | 17:44 |
| kailueke[m] | persia: yes, just thought it would be nice to have one of e.g. those who have commit access anyway | 17:48 |
| persia | I don't disagree: I just don't think it exists today :) | 17:51 |
| kailueke[m] | the cache already saved me some time, but even with just one project using Rust it is already a bit long to wait | 17:54 |
| kailueke[m] | but congrats to the 1.0 release, all worked fine so far | 17:56 |
| *** ernestask has quit IRC | 17:58 | |
| *** jonathanmaw has quit IRC | 17:59 | |
| mcatanzaro | "ERROR Inconsistent pipeline | 18:01 |
| mcatanzaro | Exact versions are missing for the following elements Try tracking these elements first with `bst track`" | 18:01 |
| mcatanzaro | 'bst track' doesn't help | 18:01 |
| mcatanzaro | https://paste.gnome.org/pcw0qaqnf/ju8dbf/raw <-- what to do? | 18:01 |
| mcatanzaro | I tried 'bst track core/epiphany.bst' and it ran fine, but didn't change anything when I tried to build | 18:02 |
| mcatanzaro | I do have a workspace checked out for epiphany, maybe that's causing problems? | 18:02 |
| *** xjuan has joined #buildstream | 18:05 | |
| nexus | So. I'm trying to update the meta data that is stored in artifacts, and i've been able to add the new information to the code, however, when i rebuild/install BuildStream and then build an element, the meta data isn't there, and the sha for the artifact isn't changing, even if i delete it and recreate it | 18:22 |
| nexus | any thoughts? | 18:22 |
| *** ahayzen has left #buildstream | 18:33 | |
| gitlab-br-bot | buildstream: merge request (juerg/element-state->master: WIP: element state updates) #215 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/215 | 18:42 |
| juergbi | nexus: if you want to force rebuild of artifacts, you have to increment BST_ARTIFACT_VERSION | 18:43 |
| *** valentind has joined #buildstream | 18:43 | |
| *** valentind has quit IRC | 18:46 | |
| *** paulsherwood has quit IRC | 19:33 | |
| *** nexus has quit IRC | 19:33 | |
| *** benbrown has quit IRC | 19:34 | |
| *** tlater has quit IRC | 19:34 | |
| *** ltu has quit IRC | 19:34 | |
| tristan | mcatanzaro, sorry missed that, and dozing off soon... `bst track` was at one time recursive by default, but proved unflexible; instead it will only track one element unless the --deps arg is given | 19:51 |
| tristan | one can combine `--deps all` with `--except <element>` as well, short hand to track a lot of elements while avoiding say, updating the base system and rebuilding the whole world | 19:52 |
| tristan | bst track --help should be helpful, too | 19:52 |
| *** tlater has joined #buildstream | 19:59 | |
| *** laurenceurhegyi has joined #buildstream | 20:00 | |
| m_22[m] | is there anything similar to jhbuild uninstall in buildstream? i built a module i don't need and ended up running out of disk space so i need to uninstall it | 20:13 |
| m_22[m] | also, are there any known issues with puseaudio working in the bst shell? | 20:14 |
| persia | pulse (or any component that needs to talk to the kernel) isn't going to work very well in a sandbox,. | 20:15 |
| m_22[m] | hmm, then i guess i should go back to using jhbuild for now | 20:15 |
| persia | There are documented tricks to get things like pulse working in a chroot, but I believe bubblewrap protects against most of those working. | 20:16 |
| persia | Or maybe someone with more experience will be able to answer your question better. | 20:18 |
| *** juergbi has quit IRC | 20:36 | |
| *** juergbi has joined #buildstream | 20:38 | |
| jjardon[m] | Hi! any idea why the integration commands are running before the build commands here? https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/47128247 Maybe Im missing something? | 21:00 |
| jjardon[m] | (for the llvm5 element, I meant) | 21:00 |
| juergbi | jjardon[m]: the integration commands for the build dependencies have to be executed before the build, otherwise the build dependencies might not work | 21:01 |
| jjardon[m] | juergbi: ah rigth. Sorry IIRC in another tool (ybd/baserock) they are always in the end thats why the confusion | 21:03 |
| *** noisecell has joined #buildstream | 21:43 | |
| *** noisecell has quit IRC | 21:47 | |
| *** luc14n0 has quit IRC | 22:28 | |
| *** luc14n0 has joined #buildstream | 22:28 | |
| luc14n0 | Hey gents! I'm making an openSUSE Tumbleweed BuildStream package, and I need to figure out what are the runtime deps. I can already say that python 3, ruamel.yaml, ostree gi bindings are needed to run, but I suspect that bubblewrap and pygobject gi bindings are possible runtime candidates as well. If someone could shed a light here for me. | 23:50 |
| *** xjuan has quit IRC | 23:50 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!