| gitlab-br-bot | juergbi opened MR !1873 (juerg/temporary-failure->master: _exceptions.py: Propagate `temporary` to the base class) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1873 | 05:13 |
|---|---|---|
| *** phildawson has joined #buildstream | 07:04 | |
| *** benschubert has joined #buildstream | 07:34 | |
| *** phildawson_ has joined #buildstream | 07:36 | |
| *** phildawson has quit IRC | 07:37 | |
| *** tristan has joined #buildstream | 07:49 | |
| *** tristan_ has joined #buildstream | 07:50 | |
| *** ChanServ sets mode: +o tristan_ | 07:50 | |
| *** tristan_ is now known as tristan | 07:52 | |
| *** tpollard has joined #buildstream | 08:36 | |
| *** santi has joined #buildstream | 08:36 | |
| *** phildawson-ct has joined #buildstream | 08:37 | |
| *** phildawson_ has quit IRC | 08:38 | |
| *** rdale has joined #buildstream | 08:38 | |
| gitlab-br-bot | marge-bot123 merged MR !1871 (tristan/fix-doc-builds->master: Documentation build fixes) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1871 | 08:53 |
| *** lachlan has joined #buildstream | 09:07 | |
| gitlab-br-bot | marge-bot123 merged MR !1869 (tristan/remove-old-version-annotations->master: Remove old version annotations) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1869 | 09:39 |
| gitlab-br-bot | juergbi closed MR !1872 (seanborg/documentation-typos->master: Fix typo namspaceing -> namespacing) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1872 | 09:41 |
| gitlab-br-bot | juergbi reopened MR !1872 (seanborg/documentation-typos->master: Fix typo namspaceing -> namespacing) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1872 | 09:41 |
| gitlab-br-bot | juergbi closed MR !1872 (seanborg/documentation-typos->master: Fix typo namspaceing -> namespacing) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1872 | 09:46 |
| tristan | min-version is a bit challenging... as something similar needs to be done for plugins | 09:49 |
| tristan | I suppose it makes sense to have semantic versioning for plugins too, replacing the old BST_FORMAT_VERSION number, and recommend that plugins be versioned in sync with their release tags ? | 09:50 |
| gitlab-br-bot | BenjaminSchubert approved MR !1873 (juerg/temporary-failure->master: _exceptions.py: Propagate `temporary` to the base class) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1873 | 09:51 |
| tristan | Or does it instead make sense to abolish it entirely, given that projects can reference precise versions of plugins they use ? | 09:52 |
| tristan | I suppose when it comes to separately installed system packages, there needs to be some story there which is anyway going to be out-of-bounds | 09:52 |
| tristan | like "Install this plugin with version == 1.2.3 using pip install foo..." | 09:53 |
| douglaswinship | Slightly over my head, I'm afraid. | 09:54 |
| tristan | Currently projects can require a specific minimal version number of the projects they use: https://docs.buildstream.build/master/format_project.html#pip-plugins | 09:57 |
| tristan | So when a project requires that the user install a "plugin package" alongside BuildStream, it can assert a minimal version of the plugin to ensure compatibility | 09:57 |
| tristan | In this scenario, we had assumed that plugins would always be stable (which they of course werent) | 09:58 |
| douglaswinship | Yup, i've always wondered about that. If they require a minimum version, rather than a specific version, doesn't that open the door for variable outputs? | 09:58 |
| tristan | Semantic versioning could allow plugins to specify 1.0, where 1.2 and 1.99 would be compatible, and the plugin could version bump to 2.0 to signify API breakage (without creating an entirely new namespace) | 09:58 |
| tristan | douglaswinship, it does not if people follow the rules, but people don't follow rules | 09:59 |
| tristan | We kind of opened up pip plugin installations as a means for people to provide *stable* outputs | 09:59 |
| douglaswinship | No, they never do :( | 09:59 |
| tristan | stable plugins I mean | 09:59 |
| tristan | But yeah, so now we will introduce a way to use junctions to load plugins, which will allow plugins to be packaged as BuildStream projects, and open the door for BuildStream to just fetch the plugins at load time | 10:00 |
| tristan | So anyway, I'm wondering if it's worthwhile to extend this functionality for BuildStream 2.x, or to abandon it altogether and give up hope that people might use it at all | 10:01 |
| * tristan has a meeting... | 10:01 | |
| *** lachlan has quit IRC | 10:03 | |
| douglaswinship | Oh, I opened an issue yesterday, a bug report. #1288 | 10:06 |
| gitlab-br-bot | Issue #1288: Prevent buildstream sandbox folders from appearing in checked out artifacts https://gitlab.com/BuildStream/buildstream/-/issues/1288 | 10:06 |
| douglaswinship | Is there anything I should/could be doing to promote it and encourage people to look at it? | 10:07 |
| douglaswinship | I'm not confident that I'll be able to get any further on my own. | 10:07 |
| *** cs-shadow has joined #buildstream | 10:10 | |
| *** lachlan has joined #buildstream | 10:19 | |
| *** lachlan has quit IRC | 10:27 | |
| tristan | Hmmm, that's strange | 10:32 |
| tristan | douglaswinship, my first intuition is that the severity is low if the directories are not actually in the artifacts themselves | 10:32 |
| tristan | but then, it's still something important, depending on how you use buildstream | 10:33 |
| tristan | might be easy to fix | 10:34 |
| *** lachlan has joined #buildstream | 10:40 | |
| tristan | cs-shadow, do you have an opinion about plugin versioning ? | 10:41 |
| tristan | cs-shadow, I'm looking at doing the s/format-version/min-version change now, and ran into the problem of "what to do with plugin version requirements" | 10:42 |
| cs-shadow | tristan: hi, sorry i may be missing some context, but looking at the scrollback, is it about the minimum plugin format version in the project configuration? | 10:44 |
| tristan | Yes :) | 10:44 |
| tristan | You walked in directly after I went through spilling my guts | 10:45 |
| tristan | it was a very emotional scene :'( | 10:45 |
| tristan | cs-shadow, I'm currently tossing a coin where on one hand... we replace the silly integer with proper semantic versioning, and on the other hand; we just throw it all away | 10:46 |
| tristan | I pinged you because I think, you are the most intimately involved with the ins and outs of pip plugin source | 10:47 |
| cs-shadow | there's one issue i see with recommending that plugin versions being the same as their package versions, which is when you have multiple plugins in the same package and the user only needs some of them. The integer version could've allowed some users to selectively upgrade (or not) | 10:47 |
| cs-shadow | that being said, I don't think this will be a major incovenience | 10:48 |
| tristan | So in your view, using pip sourced plugins kind of goes hand in hand with the user using a venv, and being "in control" of which plugins are being used, for a (possibly multi-project and junctioned) build pipeline, basically ? | 10:49 |
| tristan | Like, a user has the ability to decide | 10:50 |
| cs-shadow | my view is that since BuildStream has no opinion on how the pip plugins are installed, it should find whatever is in the environment (whether it be virtual or not) | 10:51 |
| tristan | I guess that semantic versioning buys you nothing in the case that you might need 1.x of one plugin in one project and 2.x of another plugin in another project in the same pipeline | 10:51 |
| cs-shadow | are you expecting plugins to have breaking changes within bst 2.x lifecycle? | 10:52 |
| tristan | Most definitely 100% | 10:52 |
| tristan | On a very regular basis | 10:52 |
| persia | Beyond just pip, I'd suggest we shouldn't try to guess how a user has installed plugins (maybe pip (maybe in a venv), maybe system packages, maybe local install). It might be nice to leverage per-project plugins, but general environment plugins should just come from the environment. | 10:52 |
| tristan | cs-shadow, I don't expect that to happen for core plugins maintained under BuildStream governance, though | 10:53 |
| tristan | So before we walk down a completely different road than I was expecting or insinuating... let me clarify: I'm wondering if we really do need that versioning at all | 10:53 |
| tristan | My observation has been so far that, I have not really seen a plugin ever set it's BST_FORMAT_VERSION to anything other than 0 | 10:54 |
| tristan | The reason I ask about user control of installed plugins, is mostly because; if the user does have control, they will install exactly the versions which work for their pipeline; and maybe we don't need it there ? | 10:55 |
| tristan | Also on the flipside, once we have the ability to load plugins over junctions: Versioning of those plugins becomes not useful either (A project is completely explicit about exactly which plugin it loads) | 10:56 |
| cs-shadow | I think we can defer to user to have them install the correct version, the only thing I expect BuildStream to do is to raise sensible errors. | 10:56 |
| cs-shadow | most breaking changes that I can think of, can also be done by adding a similar flag in the plugin configuration. So, I think we can get rid of it. | 10:56 |
| *** mohan43u has quit IRC | 10:57 | |
| tristan | cs-shadow, so in BuildStream core we are already getting rid of format-version in favor of matching that with installed BuildStream semantic version | 10:57 |
| tristan | cs-shadow, because of this, I think it would be more uniform (and easier on users) if we did the same for plugins | 10:57 |
| *** mohan43u has joined #buildstream | 10:57 | |
| tristan | Regardless of whether the semantic versioning of major points is actually ever used (plugins might remain 1.x for their entire lifetime without breaking), it's easier to have an error saying "I need plugin foo >= 1.4" | 10:58 |
| cs-shadow | I think the difference is that min-version works for Core because we aren't expecting breaking changes there. Plugins will need to be able to declare max versions as well if they are allowed to break compatilbility | 10:58 |
| tristan | Than to have the user see "I need a plugin with format version 26, please go figure out what plugin version has that" | 10:59 |
| tristan | min-version also works in a forward thinking way where BuildStream 3 might one day materialize too, at which point min-version could be set to "3.0" and a "Please install BuildStream 3" message could be issued | 11:00 |
| tristan | (but that's not really relevant) | 11:00 |
| cs-shadow | yes, but I'm thinking the case where there's a plugin 2.0 and 3.0, and my project only works with 2.0 | 11:00 |
| tristan | The main driver for semantic versioning was that it makes more sense to users to say "This project requires BuildStream >= 2.2" | 11:00 |
| tristan | Right | 11:01 |
| tristan | cs-shadow, I could imagine that a plugin might do that if they break their YAML API | 11:01 |
| cs-shadow | yep, that's what I meant when I was asking whether we are expecting plugins to break their API | 11:01 |
| tristan | Honestly, I don't expect it for plugins where the version guards are important | 11:02 |
| tristan | But it could | 11:02 |
| tristan | I mean, if you are installing your plugins separately and hoping things work; you are probably very diligent about the plugins you use | 11:03 |
| tristan | But you might still find a reason that you might want to break your plugin package I guess | 11:03 |
| tristan | So first off, what I'm reading here is: "Yes we still want version guards for plugins" | 11:04 |
| tristan | cs-shadow, ^^^ correct ? | 11:04 |
| * tristan doesn't have a huge opinion or preference here really, just haven't seen people using it and wondered if we could afford dropping it | 11:05 | |
| cs-shadow | i think so, my main concern is good error messages. I am less concerned whether the logic lives in BuildStream core or plugins | 11:05 |
| tristan | You think this could be done on a per plugin basis ? | 11:05 |
| tristan | cs-shadow, I guess that it's still better to have the version guard expressed in project.conf: https://docs.buildstream.build/master/format_project.html#pip-plugins ? | 11:06 |
| cs-shadow | one idea I had was that we completely abolish the plugin format version from core, and let plugins read the yaml and "deal with it". For example, plugins can recognize a field and assume that it's format version such and such implicitly | 11:07 |
| cs-shadow | (just thinking out loud) | 11:07 |
| tristan | yeah I get it... I think that it would be more onerous for the user (project author) though | 11:07 |
| *** lachlan has quit IRC | 11:08 | |
| tristan | Now... considering that pip source plugins are the only use case where plugins are not explicitly defined by the project; I wonder if we could simplify things here a little | 11:08 |
| tristan | cs-shadow, What if we used semantic versioning *only* for pip plugins, and actually used pip package metadata to implement it ? | 11:09 |
| tristan | If you are loading a local plugin, or a cross-junction plugin, your project defines already _exactly_ what's getting loaded, so it seems unnecessary to have a version check there | 11:10 |
| *** CTtpollard has joined #buildstream | 11:11 | |
| cs-shadow | I'd be in favor of that. It'll also be clerarer from the error message that `BuildStream expected plugin>2.0, you have 1.4, aborting`. Then user could install plugin > 2.0 and try again, as opposed to figuring out which format version comes from which package version | 11:11 |
| *** tpollard has quit IRC | 11:11 | |
| *** CTtpollard is now known as tpollard | 11:12 | |
| tristan | exactly, that's the main motivation for core as well | 11:12 |
| tristan | that, and using a different format/word that is hard required (to be able to distinguish between bst-1 and bst-2 projects) | 11:12 |
| cs-shadow | I guess one question would be that how complicated expressions we want to support there, like: | 11:13 |
| cs-shadow | `plugin > 2.0` | 11:13 |
| cs-shadow | `plugin < 3.0` | 11:13 |
| cs-shadow | `plugin != 2.1` | 11:13 |
| cs-shadow | `plugin > 2.0, !=2.1` | 11:13 |
| cs-shadow | ... | 11:13 |
| tristan | cs-shadow, is there some setuptools-foo we could use to offload this completely ? | 11:14 |
| persia | I think that the complication of expression support is something one only learns over time. Python 2.6 introduced a number of new ways to express version incompatibility as a results of lessons learned with attempts to specify stuff for python 3, for example. | 11:14 |
| tristan | Or maybe we want explicit reimplementation in order to *avoid* offloading this comparison to a potentially "moving target" ? | 11:15 |
| cs-shadow | persia is right, pep 440 (https://www.python.org/dev/peps/pep-0440) define the "new" versioning scheme that project _should_ follow but some don't. So, I'd be in favor of saying that if we the plugin or your requirement don't follow pep 440, bad for you. | 11:17 |
| cs-shadow | If we say that, then there's a well-used library - distlib (https://pypi.org/project/distlib/) - that's used by things like `pip` to do this for us, and we can support everything that pep 440 supports | 11:17 |
| tristan | cs-shadow, I'm in the midst of writing up the min-version change and would have liked to put it behind us this week hehe... that said, shall I make a small writeup of this and post that to the list ? | 11:19 |
| * tristan suspects he could still get it all done in a week, it's not a *huge* change | 11:19 | |
| cs-shadow | tristan: that seems perfect | 11:20 |
| tristan | Alright will do | 11:20 |
| cs-shadow | cheers! | 11:21 |
| *** lachlan has joined #buildstream | 11:22 | |
| *** lachlan has quit IRC | 11:26 | |
| *** narispo has quit IRC | 11:30 | |
| *** narispo has joined #buildstream | 11:30 | |
| *** tpollard has quit IRC | 11:45 | |
| *** CTtpollard has joined #buildstream | 11:45 | |
| *** CTtpollard is now known as tpollard | 11:45 | |
| *** lachlan has joined #buildstream | 11:46 | |
| valentind | coldtom, There were failures to upload to cache: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/519318645 | 11:51 |
| valentind | Not sure if you saw that. | 11:51 |
| valentind | Maybe it was restarted. | 11:51 |
| valentind | Feel free to restart the jobs if you want to test the cache server: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/2378 | 11:52 |
| coldtom | ah, looks like redis fell over again... | 11:54 |
| cphang | valentind https://gitlab.com/celduin/infrastructure/celduin-infra/-/merge_requests/78 is going to get merged today where it'll get deployed to our staging cluster. Once we've done some testing, we'll look to promote it to public asap | 11:55 |
| valentind | Great. | 11:55 |
| tristan | cs-shadow, sent as https://mail.gnome.org/archives/buildstream-list/2020-April/msg00017.html | 11:56 |
| *** lachlan has quit IRC | 11:57 | |
| gitlab-br-bot | juergbi opened MR !1874 (juerg/validate-path->master: _casbaseddirectory.py: Validate path components) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1874 | 12:01 |
| *** tristan has quit IRC | 12:04 | |
| gitlab-br-bot | marge-bot123 merged MR !1873 (juerg/temporary-failure->master: _exceptions.py: Propagate `temporary` to the base class) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1873 | 12:12 |
| *** narispo has quit IRC | 12:54 | |
| *** narispo has joined #buildstream | 12:54 | |
| *** tristan has joined #buildstream | 12:55 | |
| cs-shadow | tristan: +1, thanks | 13:00 |
| *** hasebastian has joined #buildstream | 13:08 | |
| *** narispo has quit IRC | 13:11 | |
| *** narispo has joined #buildstream | 13:11 | |
| *** tristan has quit IRC | 13:18 | |
| *** lachlan has joined #buildstream | 13:21 | |
| *** lachlan has quit IRC | 13:31 | |
| *** phoenix has joined #buildstream | 13:37 | |
| *** phoenix has quit IRC | 13:38 | |
| *** d0a372eb0 has joined #buildstream | 13:43 | |
| *** d0a372eb0 has left #buildstream | 13:43 | |
| *** lachlan has joined #buildstream | 13:48 | |
| *** lachlan has quit IRC | 13:56 | |
| *** lachlan has joined #buildstream | 14:22 | |
| *** benschubert has quit IRC | 14:28 | |
| *** benschubert has joined #buildstream | 14:28 | |
| *** lachlan has quit IRC | 14:33 | |
| *** tristan has joined #buildstream | 14:37 | |
| *** lachlan has joined #buildstream | 14:47 | |
| *** cs-shadow has quit IRC | 14:52 | |
| *** cs-shadow has joined #buildstream | 14:52 | |
| *** lachlan has quit IRC | 15:04 | |
| *** lachlan has joined #buildstream | 15:17 | |
| *** lachlan has quit IRC | 15:41 | |
| WSalmon | I have https://gitlab.com/BuildStream/bst-plugins-experimental/-/commits/willsalmon/git_tag_gitlfs which in CI uses the git_tag plugin which i need to fix up to pass the tests, https://gitlab.com/BuildStream/bst-plugins-experimental/-/jobs/520533065, but when i run locally it dose not find the git_tag plugin https://hastebin.com/duyonicepu.md dose any one have any idea what is up? | 16:04 |
| *** lachlan has joined #buildstream | 16:05 | |
| WSalmon | phildawson-ct, benschubert maybe? | 16:05 |
| benschubert | WSalmon: did you `register_repo_kind` on a kind named "git" ? Also `gitRepo` is not public, so I think you'd need to write a repo for git_tag? | 16:28 |
| WSalmon | yep i can see that there is loads todo but in CI it brakes cos the tests should brake but locally loads of things are failing cos bst-plugins-experimental dosent seem to be installed inside tox or atleas the plugins from it are not there | 16:31 |
| benschubert | if you run tox on bst-plugins-experimental locally, the plugins should be there, how are you running it? | 16:31 |
| WSalmon | (venvbuildstream) [will@wsx280 bst-plugins-experimental]$ tox -e py35-bst-fixed | 16:33 |
| WSalmon | https://hastebin.com/ihezakuzux.sql | 16:33 |
| WSalmon | but i get the same for py37 too and for fixed or master | 16:34 |
| benschubert | I can't access hastebin, can you use github's gists/gnome paste/gitlab snippets? | 16:34 |
| WSalmon | https://paste.gnome.org/pfdnyjpj6 | 16:35 |
| WSalmon | oh wow gnome paste is much better if you just click raw | 16:36 |
| *** lachlan has quit IRC | 16:36 | |
| WSalmon | that venv has bst-master and the plugins installed in to it but i presume tox will make its own and they wont interfear? | 16:37 |
| cs-shadow | WSalmon: the package name should `bst-plugins-experimental`, not `builstream-external` | 16:37 |
| cs-shadow | in your project.conf | 16:37 |
| WSalmon | i fixed that and it dose the same | 16:37 |
| WSalmon | there are loads that are failing | 16:38 |
| cs-shadow | can you share a new snippet with logs after that fix pleae | 16:38 |
| cs-shadow | maybe also run with `-x`, one failure should be enough to debug it if they're all the same | 16:38 |
| WSalmon | so this is master | 16:39 |
| WSalmon | https://paste.gnome.org/pqsbcl4uz | 16:39 |
| *** jjardon has quit IRC | 16:40 | |
| benschubert | WSalmon: with the errors please :) | 16:40 |
| *** jjardon has joined #buildstream | 16:43 | |
| *** ChanServ sets mode: +o jjardon | 16:43 | |
| *** jjardon has quit IRC | 16:44 | |
| *** jjardon has joined #buildstream | 16:45 | |
| *** ChanServ sets mode: +o jjardon | 16:45 | |
| *** jjardon has quit IRC | 16:46 | |
| *** jjardon has joined #buildstream | 16:47 | |
| *** ChanServ sets mode: +o jjardon | 16:47 | |
| WSalmon | https://paste.gnome.org/pwtdvbuez | 16:48 |
| WSalmon | benschubert, | 16:48 |
| WSalmon | there was way too much for all of them, i can do a diffrent one if its more helpful | 16:48 |
| coldtom | it's installing a too-old version of bst-plugins-experimental by the looks of it | 16:49 |
| coldtom | 0.12.0 is old | 16:49 |
| *** lachlan has joined #buildstream | 16:50 | |
| WSalmon | umm i will uninstall it from the venv with tox in it incase it is leaking in to the tox created one | 16:50 |
| benschubert | bst-plugins-experimental==0.12.0 yeah that's super old | 16:50 |
| WSalmon | umm exactly the same | 16:51 |
| coldtom | yeah, tox is installing it | 16:51 |
| coldtom | does buildstream depend on that for its test suite? | 16:52 |
| WSalmon | ill do a recreate thing | 16:52 |
| WSalmon | but tox made the py35 one just now | 16:52 |
| *** lachlan has quit IRC | 16:55 | |
| WSalmon | nope | 17:06 |
| *** tpollard has quit IRC | 17:13 | |
| *** narispo has quit IRC | 17:28 | |
| *** narispo has joined #buildstream | 17:28 | |
| *** lachlan has joined #buildstream | 17:31 | |
| *** hasebastian has quit IRC | 17:37 | |
| *** rdale has quit IRC | 17:43 | |
| *** santi has quit IRC | 17:56 | |
| *** santi has joined #buildstream | 17:58 | |
| *** lachlan has quit IRC | 18:15 | |
| *** santi has quit IRC | 18:20 | |
| *** phildawson-ct has quit IRC | 18:26 | |
| *** narispo has quit IRC | 18:41 | |
| *** narispo has joined #buildstream | 18:41 | |
| *** narispo has quit IRC | 18:53 | |
| *** narispo has joined #buildstream | 18:53 | |
| *** toscalix has joined #buildstream | 18:54 | |
| *** ceibal has joined #buildstream | 19:20 | |
| *** ceibal has quit IRC | 19:24 | |
| juergbi | valentind: are there tests for the oci element plugin anywhere? | 19:25 |
| valentind | juergbi, I do not think I have made tests. | 19:26 |
| juergbi | valentind: it needs to be ported to the (virtual) Directory API. however, doing this blind doesn't sound ideal | 19:27 |
| valentind | I understand. | 19:27 |
| valentind | juergbi, It could be done using valentindavid/bst2 branch for freedesktop-sdk. | 19:28 |
| valentind | I know it would be better to have tests though. | 19:28 |
| juergbi | right, should at least be able to test that it can build the fd-sdk oci images without throwing an exception | 19:28 |
| valentind | That would be a good first step. | 19:29 |
| valentind | If you have it, then you can ping me and I can do a real test running the images. | 19:29 |
| juergbi | ok, sounds like a plan | 19:29 |
| valentind | Good. | 19:29 |
| *** benschubert has quit IRC | 19:32 | |
| *** ceibal has joined #buildstream | 19:34 | |
| *** ceibal has quit IRC | 19:37 | |
| gitlab-br-bot | cs-shadow opened MR !1875 (chandan/no-nosoftware->master: CONTRIBUTING: Remove link for obsolete issue policies) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1875 | 20:44 |
| *** toscalix has quit IRC | 21:31 | |
| *** toscalix has joined #buildstream | 21:34 | |
| *** cs-shadow has quit IRC | 22:11 | |
| *** toscalix has quit IRC | 23:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!