| *** zoli__ has joined #baserock | 00:48 | |
| *** zoli__ has quit IRC | 00:52 | |
| *** zoli__ has joined #baserock | 02:36 | |
| *** zoli__ has quit IRC | 02:42 | |
| *** zoli__ has joined #baserock | 04:38 | |
| *** zoli__ has quit IRC | 04:42 | |
| *** zoli__ has joined #baserock | 05:26 | |
| *** sambishop has quit IRC | 05:34 | |
| *** inara has quit IRC | 05:48 | |
| *** inara has joined #baserock | 06:03 | |
| *** zoli__ has quit IRC | 06:15 | |
| *** zoli__ has joined #baserock | 06:36 | |
| *** sambishop has joined #baserock | 06:57 | |
| * straycat meows | 07:03 | |
| *** a1exhughe5 has joined #baserock | 07:11 | |
| straycat | https://lwn.net/SubscriberLink/641779/474137b50693725a/ was a good article | 07:29 |
|---|---|---|
| *** Albert__ has joined #baserock | 07:30 | |
| *** Albert__ has quit IRC | 07:33 | |
| *** Albert has joined #baserock | 07:34 | |
| *** persia_ has quit IRC | 07:39 | |
| *** persia_ has joined #baserock | 07:40 | |
| *** persia_ has joined #baserock | 07:40 | |
| *** sherm_ has joined #baserock | 07:52 | |
| *** mariaderidder has joined #baserock | 07:53 | |
| *** bashrc has joined #baserock | 08:07 | |
| *** edcragg has joined #baserock | 08:19 | |
| Kinnison | Thank you straycat, that is an interesting article indeed. | 08:19 |
| *** gary_perkins has joined #baserock | 08:27 | |
| *** jonathanmaw has joined #baserock | 08:27 | |
| *** ssam2 has joined #baserock | 08:31 | |
| *** ChanServ sets mode: +v ssam2 | 08:31 | |
| *** bfletcher has joined #baserock | 08:33 | |
| ssam2 | good morning | 08:37 |
| Kinnison | Hi ssam2 | 08:38 |
| tiagogomes_ | morning | 08:39 |
| ssam2 | I have a bunch of Morph patches that it'd be nice for people to review | 08:39 |
| ssam2 | there is a reward at the end | 08:39 |
| Kinnison | is it chocolate? | 08:40 |
| ssam2 | this distbuild branch seems to fix a longstanding problem at a customer site: https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:master+topic:sam/distbuild-controller-job-tracking (And has +1 from franred already) | 08:40 |
| ssam2 | it's not chocolate | 08:40 |
| Kinnison | aww | 08:40 |
| Kinnison | there's merge conflict statements in the summary | 08:40 |
| ssam2 | a couple of other tiny distbuild ones (+1 already from straycat): https://gerrit.baserock.org/#/c/569/ and https://gerrit.baserock.org/#/c/575/ | 08:40 |
| ssam2 | Kinnison: yes, they depend on each other so patches 2, 3, and 4 will show as 'merge conflict' until patch 1 is merged | 08:41 |
| ssam2 | one patch for sysroot.write that fixes a regression (+1 from richard maw already): https://gerrit.baserock.org/#/c/502/ | 08:41 |
| ssam2 | and the reward: first version of patches to make `morph build` and `morph deploy` work from any checkout of definitions.git (not requiring a workspace and system branch): https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:master+topic:sam/workspaces-optional-3 | 08:42 |
| persia | WooHoo! | 08:42 |
| Kinnison | ssam2: regarding 502 -- are you going to be submitting a new patch based on your discussion with Richard Maw? | 08:46 |
| Kinnison | ssam2: (cp -al) | 08:46 |
| ssam2 | I didn't have time to test that, so no | 08:46 |
| pedroalvarez | ssam2: I like that reward!" | 08:55 |
| *** rdale has quit IRC | 08:58 | |
| *** Stanto has quit IRC | 08:58 | |
| *** SotK has quit IRC | 08:58 | |
| *** rdale has joined #baserock | 09:00 | |
| *** Stanto has joined #baserock | 09:00 | |
| *** SotK has joined #baserock | 09:00 | |
| * straycat had forgotten about https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:master+topic:sam/distbuild-controller-job-tracking and will look at it now | 09:07 | |
| *** straycat is now known as reviewcat | 09:08 | |
| *** lachlanmackenzie has joined #baserock | 09:16 | |
| *** Krin has joined #baserock | 09:24 | |
| rdale | i've reverted the gcc 5.1 commit and built my system with that, and it is still hanging on startup in syslinux | 09:24 |
| persia | rdale: To confirm: using a non-gcc5.1 devel system, you reverted the change, and built a new devel system, and using that, you built your system, and it doesn't work? | 09:25 |
| rdale | yes, it doesn't work with gcc 4.9.2 | 09:26 |
| persia | But a devel system built with gcc 4.9.2 works? | 09:27 |
| tiagogomes_ | rdale reverting gcc 5.1 worked for me | 09:28 |
| rdale | i built a system in an existing image with 5.1 and that works. what doesn't work is building an img file in /src/tmp, copying it out and running it with kvm | 09:28 |
| pedroalvarez | The variables of this problem are a bit complex. Please, specify the version of gcc of the Host (devel system doing the deployment) and the version of gcc of the system being deployed | 09:28 |
| rdale | host is gcc 5.1, deployed system is 4.9.2 | 09:29 |
| rdale | so maybe i need to downgrade my host? | 09:29 |
| pedroalvarez | I think that is the problem | 09:29 |
| pedroalvarez | the version of gcc of the host doing the deployments | 09:29 |
| tiagogomes_ | yes, my host gcc is 4.9.2 | 09:30 |
| pedroalvarez | "the problem" - the variable that makes it crash | 09:30 |
| rdale | right - i need a gcc 4.9.2 host then | 09:30 |
| pedroalvarez | the problem might be syslinux or btrfs-progs being built with gcc 5.1 | 09:32 |
| pedroalvarez | But this is just a guess | 09:33 |
| ssam2 | This is where richard maw's idea of doing deployment in a container that is a Baserock system, rather than in the host directly, seems nice | 09:33 |
| rdale | yes, i think i assumed that was what was going on | 09:34 |
| persia | Can we reuse the same sandbox environment we use to build the chunks, or would it require yet another container structure? | 09:34 |
| ssam2 | I'm not sure. Certainly I'd like Morph to have only one way of doing containers | 09:38 |
| Kinnison | The protocol for deployment allows for deployment extensions to access the wider world | 09:38 |
| Kinnison | the one containment mechanism would need extending to parameterise that kind of thing | 09:38 |
| persia | Kinnison: So no network at build-time, but network at deploy-time? | 09:39 |
| Kinnison | persia: indeed | 09:40 |
| Kinnison | persia: also deployment protocol allows for the configure/write extensions to have access to host resources | 09:40 |
| Kinnison | persia: e.g. filesystems for storing metadata etc | 09:40 |
| ssam2 | deployment protocol also allows them to delete the entire host, so i'd be up for limiting it a bit | 09:40 |
| Kinnison | :) | 09:41 |
| * Kinnison notes that deploying to self (cycle.sh) needs to remain a viable operation in whatever changed world you come up with | 09:41 | |
| persia | Does it need be rw, or does ro work? I wonder if we could do something like bind-mount the current commit of definitions to /definitions in the staging area, to be read-only. | 09:42 |
| ssam2 | indeed. Maybe that could be done by allowing the container to contact the host's system-version-manager process (or equivalent) somehow | 09:42 |
| persia | I thought deploy-to-self was an ssh operation, where the self involved was coincidental, rather than being special in terms of host interaction. | 09:42 |
| persia | Just allowing network ought handle that. | 09:42 |
| pedroalvarez | persia: i think you are right | 09:43 |
| ssam2 | persia: true, but you can do 'ssh root@localhost rm -Rf /*' right now :) | 09:43 |
| persia | ssam2: Yes, but preventing that requires a level of invasiveness that is more than I would prefer. | 09:44 |
| persia | Whereas a poorly coded write extension could remove one's entire host system even if one was targeting something else, which is a bit more painful. | 09:45 |
| jonathanmaw | pedroalvarez: Kinnison has asked me to help with testing your pam changes (since my genivi-demo-platform work relies on pam) | 09:57 |
| jonathanmaw | anything I can help with? | 09:58 |
| pedroalvarez | jonathanmaw: see the current status of the patch: https://gerrit.baserock.org/#/c/573/ | 10:00 |
| pedroalvarez | I've cheked that loginctl shows a session open, but I don't know if this patch will break your current work | 10:01 |
| *** rdale has quit IRC | 10:11 | |
| *** rdale has joined #baserock | 10:12 | |
| richard_maw | I'm working on a `morph diff` command to make it easier to see what changed between branches of definitions | 10:16 |
| Kinnison | ssam2: Who can abandon a patch in gerrit? Only the author? | 10:17 |
| ssam2 | not sure | 10:18 |
| ssam2 | I think anyone in Mergers or the author | 10:18 |
| ssam2 | or maybe it's Administrators and the author | 10:18 |
| SotK | I think its the latter | 10:18 |
| Kinnison | Hmm | 10:18 |
| ssam2 | SotK: if you don't see an 'Abandon' button for a patch where you're not the author, then I guess so | 10:19 |
| * Kinnison wonders what the ettiquette should be on patches which are materially abandoned by their author, but not specifically marked as such | 10:19 | |
| SotK | ssam2: indeed I do not | 10:19 |
| richard_maw | I wanted to have it work by computing a full build graph, so you could diff two systems and see "in this system chunk foo also depends on bar", but our data model doesn't allow you to parse and graph multiple systems together. The biggest issue is the architecture, but we want to add parameterisation, which would make it even more inappropriate in its current state | 10:20 |
| Kinnison | e.g. https://gerrit.baserock.org/#/c/133/ -- written and submitted over a month ago, a concern posted 2 weeks ago, still nothing from the author since 2 minutes after the initial submission | 10:20 |
| ssam2 | richard_maw: I would love to be able to have systems of multiple architectures in one source pool.. but I imagine it's too much work for now | 10:21 |
| richard_maw | ssam2: it's definitely too much work for now, given committments that want a `morph diff` by friday, I'd estimate it'd take a week to pull the source pool code apart and put it back together to allow graphing multiple systems at once | 10:22 |
| richard_maw | ssam2: I think I'll have to fall back to parsing on top of the morphology set | 10:23 |
| persia | jjardon: Any thoughts on 133? Are you planning to get back to it? | 10:23 |
| persia | Kinnison: As reflected by my immediately prior post: I think we ought just poke the submitter to see what they plan. If someone is absent from the community, we can look at something more complicated, but for folk who are relatively active, it ought be as simple as a reminder. | 10:26 |
| Kinnison | persia: I was wondering if perhaps some kind of bot could poke the entries on gerrit directly | 10:28 |
| *** flatmush has quit IRC | 10:28 | |
| Kinnison | persia: that way we'd have a central location for the pokings, and perhaps a way to have a robotic policy | 10:28 |
| persia | I think this should be the central location for the pokings. | 10:28 |
| persia | (where "this" is #baserock@freenode) | 10:29 |
| Kinnison | IRC is ephemeral | 10:29 |
| Kinnison | Ephemeral pokings are harder to track | 10:29 |
| persia | irclogs.baserock.org make it less so | 10:29 |
| persia | And I'm not sure I understand the value of tracking pokings. | 10:29 |
| Kinnison | Because I'd like to see "poked N times after M days of silence -> auto-abandon patch" | 10:30 |
| jmacs | Do we not have an email address for each patch submitter? | 10:30 |
| Kinnison | gerrit's patch list is already becoming unwieldy | 10:30 |
| persia | jmacs: We do. | 10:30 |
| persia | If the list is unwieldy, we need to do better at cleaning it. | 10:30 |
| jmacs | Then have a bot send an email after a week/month of inactivity | 10:30 |
| ssam2 | Gerrit's patch list is already becoming unwieldy, but I think that's partly because there are several big patch series on there | 10:30 |
| persia | While some of that is reviewing, most of it is being better about actually landing stuff before we submit new stuff. | 10:31 |
| ssam2 | there are many patches for both OSTree and Firehose | 10:31 |
| *** flatmush has joined #baserock | 10:33 | |
| jjardon | persia: maybe, there are other issues with more priority though | 10:36 |
| *** flatmush has quit IRC | 10:39 | |
| jonathanmaw | pedroalvarez: can you give use-cases where you can log into a system with the wrong password. I'm having trouble reproducing that problem before using your patch. | 10:41 |
| pedroalvarez | jonathanmaw: oh, no, the actual problem is that you can't use the `su` command | 10:42 |
| *** flatmush has joined #baserock | 10:42 | |
| jonathanmaw | pedroalvarez: I'm not sure what the addition of pam_deny.so in system-auth is for, then. | 10:42 |
| pedroalvarez | jonathanmaw: so, currently you can't do: `su git -c 'echo foo'` | 10:44 |
| Kinnison | jonathanmaw: if you do the fix to shadow *without* the addition of pam_deny.so *then* you get the login-with-wrong-password issue | 10:44 |
| pedroalvarez | exactly | 10:44 |
| Kinnison | jonathanmaw: which you can verify by commenting out the pam_deny lines in your generated system | 10:44 |
| Kinnison | jonathanmaw: pam.d files use # as a comment marker | 10:45 |
| pedroalvarez | Kinnison: now you are here, what is '-' for in a pam.d file? | 10:45 |
| Kinnison | pedroalvarez: depends where | 10:46 |
| pedroalvarez | at the start | 10:46 |
| Kinnison | example? | 10:46 |
| jonathanmaw | noted. a worrisome thought occurs though - to properly test that your patch doesn't break the genivi-demo-platform, I'll have to rebuild everything from login upwards, which is an overnight job | 10:46 |
| pedroalvarez | hm... I guess that only adding the pam.d files won't give you the same result | 10:47 |
| jonathanmaw | pedroalvarez: yep. I could do a massive hack and re-install shadow, pam, systemd, etc... on top of my system afterwards, but I don't trust the integrity of that. | 10:48 |
| pedroalvarez | well, no rush, I'd prefer if this is well tested | 10:48 |
| tiagogomes_ | what is the purpose of strata/bsp-x86_both-tools.morph | 10:55 |
| Kinnison | for chroot systems to be able to deploy disk images, they need the bsp tooling but not a kernel | 10:55 |
| persia | jjardon: Understood. If you think it's still relevant, let it be. If you are done with it, abandon it. If you're just distracted, no worries (but maybe leave a note to that effect on the review). | 10:57 |
| persia | On rebuilding being an overnight job: do we have any way of parallelising builds to reduce this cost? | 10:58 |
| pedroalvarez | Kinnison: sorry, I got distracted "-session required pam_selinux.so close" | 11:00 |
| * Kinnison will have a look in a bit | 11:03 | |
| tiagogomes_ | btrfs-utils 4.0 didn't solved the boot problem | 11:12 |
| pedroalvarez | it might be the case that upstream hasn't spotted the error, nor fixed it | 11:14 |
| jjardon | ssam2: about https://gerrit.baserock.org/#/c/531/ , you need a fix in the install-files extension make it work (already merged) (https://gerrit.baserock.org/#/c/530/) . Should we consider this a change in the definitions format? | 11:15 |
| tiagogomes_ | or syslinux could be the culprit | 11:15 |
| pedroalvarez | nothing regarding gcc in btrfs-progs/syslinux | 11:15 |
| pedroalvarez | well, there are things, but nothing obvious | 11:15 |
| tiagogomes_ | what's that flag to show the build output | 11:16 |
| pedroalvarez | --verbose I believe | 11:17 |
| pedroalvarez | but you should have it in you artifacts/ folder | 11:17 |
| pedroalvarez | something like /src/cache/artifacts/<cache-key>.build-log | 11:18 |
| ssam2 | jjardon: yes | 11:25 |
| ssam2 | jjardon: we should perhaps look at moving some configure extensions into definitions.git to avoid this problem... | 11:26 |
| pedroalvarez | oh, Raspberry PI2 for GDP | 11:28 |
| pedroalvarez | I still want to put baserock in a PI | 11:28 |
| jjardon | ssam2: ok, should I upgrade the definitions versions and then work on the move? | 11:28 |
| ratmice__ | Kinnison: while I do understand the need for a smooth review queue, archival purposes are important, e.g. I recently revisited a ~5 year old patch upon discovering the thing blocking it is part of some ~13 year old deprecated behavior | 11:39 |
| pedroalvarez | morph.git and definitions.git are too connected... | 11:39 |
| persia | pedroalvarez: +1 | 11:41 |
| persia | I believe we've run into the problem of deciding we have two buckets, and trying to put everything in one or the other, so that both are confusing. | 11:42 |
| persia | Rather, I think we would do better to cause morph to only be a tool for building/deploying/analysing definitions, and defintions to only be declarative definitions of systems. | 11:43 |
| persia | All the other bits would do better somewhere else, which would make the others less tightly bound. | 11:43 |
| pedroalvarez | are the extensions part of the tools or part of the definitions? | 11:43 |
| persia | That's the sort of issue we need to determine. | 11:44 |
| pedroalvarez | :) | 11:44 |
| persia | Currently the extensions contain both logic and configuration. | 11:44 |
| persia | As such, I suspect they ought be scrapped, and replaced with something sane. | 11:45 |
| pedroalvarez | I'm currently thinking that configure extenisons are part of definitions, but my thoughts might be caused by an specific case | 11:45 |
| persia | I think that the description of how to configure a system belongs in the definitions. | 11:46 |
| pedroalvarez | we have to think about this, yes | 11:46 |
| ssam2 | I think config extensions should go in definitions | 11:46 |
| persia | But I'm not convinced that the logic that processes that description does. | 11:46 |
| persia | As such, I think that trying to determine where "configureation extensions" go is the part that makes it hard. | 11:47 |
| * richard_maw grumbles about MorphologyLoader being unnecessarily object oriented, given it has no __init__ and it only uses self to call other functions | 11:47 | |
| ssam2 | also, all the configure extensions should be replaced with Ansible scripts :) | 11:47 |
| persia | ssam2: Does that require ansible on the target, or can ansible be used to manipulate the target remotely from the host at deploy time? | 11:48 |
| * persia still has a dream of being able to deploy really tiny systems, including systems that are not running a linux kernel or POSIX userspace | 11:48 | |
| ssam2 | it'd require SSH on the target | 11:50 |
| ssam2 | wait,no it wouldn't | 11:51 |
| ssam2 | ansible could do its thing at deploy time and manipulate the system directly in a chroot | 11:51 |
| ssam2 | but it probably doesn't actually make sense to force Ansible on everyone | 11:51 |
| ssam2 | I need to do a 15.19 release this week | 11:52 |
| ssam2 | I've done some draft release notes: http://wiki.baserock.org/releases/baserock-15.19/ | 11:52 |
| ssam2 | There are a couple of blockers: syslinux being broken is the main one | 11:52 |
| ssam2 | I think since it's Wednesday already, reverting GCC to 4.9 for the release is the sensible option | 11:52 |
| pedroalvarez | +1 | 11:53 |
| persia | If ansible can operate at deploy time, then I'm +1 on forcing ansible on everyone. | 11:53 |
| ssam2 | cool :) | 11:53 |
| persia | That's an entire other group of people who are working on having YAML to configure systems, which is what we have. | 11:53 |
| persia | So if we aren't using their stuff, then we're just playing catch-up (and probably badly) | 11:53 |
| persia | But, please, be sure that we have at least one working configured system (e.g. minimal) that doesn't have any ansible runtime support in the deployed system, so relies on ansible to do things at deployment time. | 11:54 |
| pedroalvarez | ssam2: the release notes look ok to me | 12:00 |
| *** mariaderidder has quit IRC | 12:02 | |
| *** zoli__ has quit IRC | 12:02 | |
| richard_maw | my only issue with ansible is wondering how it would interact with read-only /usr deployments | 12:02 |
| *** zoli__ has joined #baserock | 12:02 | |
| persia | ssam2: For the release notes: could morph have a tag as the minimum thing to upgrade to in order to use defintions 15.19? | 12:03 |
| persia | Also, release notes indicate upgrade to gcc 5.1, but I thought you suggested downgrading again to 4.9 | 12:04 |
| persia | For systemd, it may be useful to indicate between which releases the commit is, so people don't have to hunt. | 12:05 |
| persia | Same for libxslt | 12:05 |
| jjardon | ssam2: https://gerrit.baserock.org/580 I will upgrade the wiki if it gets merged | 12:06 |
| *** zoli__ has quit IRC | 12:07 | |
| persia | The headline of the release notes indicates definitions version 2, but the new architectures section indicates definitions version 3. Are these inconsistent for a reason? If so, this should be made clear. If not, they should be consistent. | 12:07 |
| jjardon | persia: definitions are using format 2, morph support 3 as well | 12:08 |
| Kinnison | ratmice__: Abandoned patches are not, iirc, deleted | 12:08 |
| persia | I'm not entirely happy about making a release that cannot generate x86 development images. | 12:09 |
| ratmice__ | persia: don't think ansible at deploy time would necessarily work in that case you specified (non-linux kernel/userspace) | 12:09 |
| persia | ratmice__: Depends on the target. For a image target, the image can be unpacked, and managed with the host semantics. For a remote target, the ansible contents ought be able to handle the right format, so long as ssh works. | 12:10 |
| persia | That said, I may not understand ansible. | 12:10 |
| ratmice__ | a lot of times, you can generate an image from linux with some juju, without being able to mount it | 12:10 |
| jjardon | ssam2: Maybe worth mention the upgrade to mesa 10.5.4? | 12:10 |
| persia | ratmice__: Yes, but the current model involves mounting a filesystem to run the system-integration commands, so we can be fairly confident that we are able to do this. | 12:11 |
| tiagogomes_ | I was having a go at updating syslinux but it is not trivial and it would require some changes. Besides it would need to be tested for Ironic, and pxeboot write | 12:11 |
| jjardon | tiagogomes_: there is a patch to update syslinux already | 12:11 |
| jjardon | but I was told it will break pxeboot | 12:11 |
| tiagogomes_ | jjardon, there are a lot of things wrong with that patch | 12:11 |
| ratmice__ | persia: so if one can avoid system integration commands that should be fine | 12:12 |
| jjardon | tiagogomes_: I didnt see any review from you in gerrit | 12:12 |
| persia | ratmice__: Sure: similarly, if one needs to construct an image that cannot be mounted, one could avoid configuration extensions. | 12:13 |
| tiagogomes_ | jjardon I left a note that it would break Ironic. I'll augment it | 12:13 |
| ratmice__ | anyhow, I'd never really decided on whether actually generating our target images as a deployment was needed, having a known system from which everybody generates them is already an improvement :) | 12:15 |
| jjardon | tiagogomes_: go ahead with your approach, I do not think I will have time to work on it this week | 12:16 |
| persia | ratmice__: Hrm? How can everybody generate target images if one cannot actually generate a target image? | 12:17 |
| ratmice__ | persia: ah, our main deployment from baserock is the target image generation system including all of the cross compilers, still using the custom makefiles/host binaries/shell scripts invoking host binaries to generate the target image | 12:21 |
| persia | ratmice__: Ah, so you use Baserock to deploy a known system for others to use to deploy various systems? | 12:21 |
| ratmice__ | yup | 12:21 |
| persia | Now your comment makes sense: yes, whether to do it that way or single-stage depends on what makes sense for your workflow. | 12:22 |
| persia | The BSP/SDK code is for a similar sort of workflow, where one uses Baserock to generate tooling that folk can use to develop software for a target system. | 12:22 |
| *** zoli__ has joined #baserock | 12:24 | |
| ratmice__ | yeah, It's kind of weird in our case because of the host binaries, being provided by one deployment then used in the other (complicated by the inability to mount) | 12:26 |
| persia | Heh, indeed. | 12:28 |
| ratmice__ | so, in general that would mean that we have one branch of the definitions which were only usable under the deployment of another branch | 12:29 |
| persia | Right. Rather than self-hosting, you'd end up with a set of defintions used to generate the development systems, and an entirely separate set of definitions used to generate target systems. | 12:30 |
| ssam2 | thanks for feedback on release notes, will get to it in a bit | 12:36 |
| ratmice__ | and FWIW the reason we can't mount it is essentially we build a swap partition, the kernel boots it and starts mapping memory from disk, so doing so means reimplementing the entire kernel in linux | 12:37 |
| ratmice__ | s/in linux/in the linux kernel/ | 12:38 |
| persia | Oh, nifty | 12:39 |
| *** nowster has joined #baserock | 12:43 | |
| ratmice__ | so considering those programs written to the swap can be 3rd party (and including the initial baserock images bootstrapping our deployment) we're at our 4th branch I believe.. :) | 12:48 |
| ratmice__ | so yeah, for now at least i've just figured that it adds a whole lot of complexity i'm not going to worry about at the moment | 12:53 |
| nowster | Hi all. I have a ./configure script that tries out the set*uid() calls, which fail under linux-user-chroot | 12:57 |
| nowster | I notice that linux-user-chroot is not setuid | 12:57 |
| radiofree | pedroalvarez: for genivi specific systemd units should we push them to http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/bsp-support.git/ to avoid cluttering up definitions? | 12:58 |
| persia | nowster: Are you running morph as root? If so, I would think the lack of setuid would not impact that. | 12:58 |
| nowster | yes I am running as root | 12:59 |
| * persia doesn't understand why root should have issues calling the set*uid() calls | 13:00 | |
| nowster | because linux-user-chroot drops those privs | 13:00 |
| nowster | */ | 13:00 |
| nowster | if (prctl (PR_SET_NO_NEW_PRIVS, 1) < 0 && errno != EINVAL) | 13:00 |
| nowster | fatal_errno ("prctl (PR_SET_NO_NEW_PRIVS)"); | 13:00 |
| nowster | else if (prctl (PR_SET_SECUREBITS, | 13:00 |
| nowster | SECBIT_NOROOT | SECBIT_NOROOT_LOCKED) < 0) | 13:00 |
| nowster | fatal_errno ("prctl (SECBIT_NOROOT)"); | 13:00 |
| persia | hmmm..... | 13:00 |
| Kinnison | It's part of the protection l-u-c does | 13:02 |
| nowster | the configure script detects it's running non-root and falls back to not actually checking the functions work, but if run as root it will check them | 13:03 |
| *** edcragg has quit IRC | 13:07 | |
| *** edcragg has joined #baserock | 13:09 | |
| *** mariaderidder has joined #baserock | 13:09 | |
| pedroalvarez | tiagogomes_: I'm currently thinking that we can copy the probably-culprit-chunk-artifacts to a working system, unpack them and see what happens | 13:11 |
| pedroalvarez | just an idea, I'm not currently debugging that | 13:11 |
| ratmice__ | nowster: maybe upstream would accept a patch to disable the check from a configure option? (not that any of the configure option mechanisms are readily applicable in a clean fashion) | 13:12 |
| tiagogomes_ | pedroalvarez we can, but I am not going to do it to mine for obvious reasons :) | 13:12 |
| pedroalvarez | :) | 13:12 |
| nowster | ratmice__: it's not even autotools! | 13:12 |
| pedroalvarez | tiagogomes_: I can, I guess | 13:12 |
| tiagogomes_ | nowster not using autopain is a good sign | 13:13 |
| nowster | it's samba | 13:13 |
| nowster | and they're using a new python-y build system called "waf" | 13:13 |
| tiagogomes_ | pedroalvarez that would help, as I am not completely sure is a syslinux problem | 13:14 |
| pedroalvarez | I'm assuming that these artifacts are currently in cache.baserock.org, so that I don't have to build anything | 13:14 |
| * pedroalvarez will do that | 13:15 | |
| *** reviewcat is now known as straycat | 13:16 | |
| Albert | I'm trying to build a completely fresh Genivi AudioManager within a Baserock VM> I'm getting the error: "Can't find common-api generated headers!". Anyone seen this before? | 13:25 |
| radiofree | that sounds incredibly genivi specific, did build-depend on whatever common-api is? | 13:26 |
| Albert | Indeed it is genivi-specific. Sorry should've said. | 13:27 |
| Albert | Sorry radiofree, not sure I understood the question | 13:28 |
| radiofree | i don't know what common-api is, but it sounds like you need headers it generates, did you build depend on common-api? | 13:29 |
| Albert | I'm doing a fresh AudioManager 6.2, which is necessitating an update to CommonAPI, so I'm building that too. It is on that that I am getting that specific error. | 13:30 |
| radiofree | so it's commonapi that's complaining about common-api headers? | 13:31 |
| Albert | I'll paste an output | 13:32 |
| pedroalvarez | Ok, new version to fix shadow + PAM: https://gerrit.baserock.org/#/c/573/2 | 13:34 |
| Albert | No, I tell a lie: This is AudioManager's build that is failing. I have already built CommonAPI. The output is at http://paste.baserock.org/eruyaxusem. BUT I'm going to revisit CommonAPI build to make sure it is built and installed properly. | 13:35 |
| Albert | It's always when you discuss it with someone that you notice your own possible errors. | 13:36 |
| rdale | i would fix the syntax error in the cmake file whatever that is | 13:37 |
| radiofree | does you audiomanager chunk build-depend on commonapi? | 13:37 |
| radiofree | if it does, i suggest checking through cmake/CommonAPIGenerator.cmake to see what it's trying to do/find | 13:37 |
| Albert | BTW those log files haven't been particularly enlightening. | 13:37 |
| straycat | ruroh | 13:38 |
| straycat | richard_maw, 290483010cfc7945cd4483fadd1d98c3b83efb3 seems to have broken morph checkout :/ | 13:38 |
| richard_maw | straycat: taking a look now | 13:40 |
| persia | Is that not a positive thing? | 13:40 |
| Albert | It chunk builds yes. But I'm bringing it up to date to meet dependency requirements up to date. Sadly the released version of AudioManager had some build-killing errors that I've already fixed (!) | 13:40 |
| richard_maw | straycat: how is it broken? doesn't work as it should, or crashes when attempted? | 13:41 |
| straycat | richard_maw, the push url is the same as the fetch url | 13:41 |
| richard_maw | hm, test suite will have missed that distinction because it has no difference in its configuration | 13:43 |
| Albert | rdale, Missed that. There have been several of those but it is to do with versioning of cmake. It should have allowed that with just a warning. | 13:43 |
| radiofree | how do you see the log for a failed systemd service? | 13:44 |
| radiofree | journalctrl _PID=foo gives me nothing | 13:44 |
| bashrc | systemctl status <servicename> | 13:44 |
| radiofree | that doesn't give me any useful logging other than it failed | 13:44 |
| richard_maw | journalctl -u $unit_name | 13:46 |
| ssam2 | journalctl --unit=xx sometimes works | 13:46 |
| ssam2 | snap | 13:46 |
| ssam2 | persia: we have users who are used to the `morph checkout` workflow, we shouldn't break it for them | 13:46 |
| persia | At least not without warning. I very much hope we will eventually break it for them, but I can accept not doing so unintentionally. | 13:47 |
| paulsherwood | heh | 13:48 |
| ssam2 | about having a tag of Morph as 'the minimum thing to upgrade to in order to use definitions 15.19': what if we tagged morph.git with each version of definitions.git that it understood ? | 13:48 |
| ssam2 | so morph 'baserock-definitions-v2' would be needed to build 15.19 | 13:49 |
| straycat | would be good to have all of this workflow along with the structure of definitions defined somewhere so we can refer to that | 13:49 |
| ratmice__ | nowster: they do seem to have amassed quite a bit of logic in their build/configure stuff it would appear :/ | 13:49 |
| richard_maw | straycat: I'm still spinning up on this failure, it sounds like the issue is that checking whether the in-memory version is None is a completely inappropriate way to test whether it is set on-disk | 13:49 |
| straycat | ahh | 13:50 |
| richard_maw | straycat: and it's set on-disk at clone time | 13:50 |
| richard_maw | straycat: can you try putting `self.name is None and` before the check for the in-memory fetch_url and push_url are compared to None | 13:52 |
| Albert | Yeah, I got rid of that error report but it doesn't fix it. | 13:53 |
| persia | ssam2: I'm fine with tagging morph with things like "comprehends-definitions-v2", "comprehends-definitions-v3", etc. (or some more concise representation), so long as the nature of the representation also allows "no-longer-comprehends-defintions-v2", etc. | 13:54 |
| ssam2 | that seems a bit too hard to represent in a `git tag`, then | 13:55 |
| straycat | richard_maw, sure, though i'd assumed you'd reproduced this yourself? | 13:56 |
| richard_maw | straycat: sorry, I haven't yet, task switching is currently expensive, so I was deferring until I could easily switch and test | 13:58 |
| persia | ssam2: It's a matter of semantics: perhaps "definitions-v2-supported" and "definitions-v2-unsupported"? Even "defv2" and "nodefv2"? | 14:02 |
| straycat | richard_maw, yes that seems to fix it | 14:03 |
| persia | The other sensible option is to semantically version morph, and constrain these sorts of changes to specific release windows (but that probably makes everyone using use-latest-morph cry) | 14:03 |
| richard_maw | straycat: cool, thanks for trying it, I've only just got as far as reproducing the fault | 14:03 |
| paulsherwood | ssam2: i can't help feeling we're making this harder than it needs to be. | 14:04 |
| ssam2 | persia: why is it useful to be able to check out a version of Morph that can't build a certain version of definitions? | 14:04 |
| paulsherwood | (the versioning thing) | 14:04 |
| ssam2 | me too, I would love for someone to come up with a good way to do it that doesn't break things for people who are trying to upgrade their systems later on | 14:04 |
| persia | ssam2: Rather, it is useful to be able to look at annotated history, and check out the last version that *could* read a certain version. | 14:04 |
| paulsherwood | (and the deploy extensions thing etc) | 14:04 |
| persia | So tag-1 | 14:04 |
| paulsherwood | ssam2: would you still love it if the way didn't involve morph, at all? :) | 14:05 |
| ssam2 | yes | 14:05 |
| ssam2 | even more so | 14:05 |
| * persia would probably do that with `git checkout tag-that-cannot-build-something && git checkout HEAD-1` | 14:05 | |
| richard_maw | straycat: I can confirm the fix, do you want to submit it or should I? | 14:05 |
| * richard_maw runs test suite | 14:06 | |
| straycat | richard_maw, feel free :) | 14:06 |
| *** edcragg has quit IRC | 14:15 | |
| *** edcragg has joined #baserock | 14:17 | |
| richard_maw | straycat: https://gerrit.baserock.org/585 | 14:22 |
| *** straycat is now known as reviewcat | 14:42 | |
| radiofree | switching vt's in baserock seems a bit broken | 14:45 |
| radiofree | seems to hang on "Starting Getty on ttyx" | 14:45 |
| reviewcat | i don't fully understand the fix either, just that we can't use that comparison for named repos? | 14:46 |
| pedroalvarez | Kinnison: sorry but I don't understand your comment here: https://gerrit.baserock.org/#/c/573/3 | 14:49 |
| pedroalvarez | "systemd adds a number of files" | 14:49 |
| Kinnison | systemd's pam.d stuff, is it *only* system-auth or is there more? | 14:49 |
| pedroalvarez | ahh | 14:50 |
| pedroalvarez | Kinnison: there are 2 more, but they have "session include system-auth" at the bottom | 14:50 |
| Kinnison | do they have any auth lines? | 14:51 |
| Kinnison | 'session include ...' will only do includes for session, not for auth :) | 14:51 |
| richard_maw | reviewcat: if it's a named remote, there's sufficient config on-disk and the url fetch off disk logic is smart enough to give you the other url as a default | 14:51 |
| richard_maw | reviewcat: the issue is that we need to do this logic ourselves for unnamed remotes | 14:51 |
| richard_maw | reviewcat: and there was a bug in whether we needed to do it for named remotes, and they interacted badlty | 14:52 |
| reviewcat | Okay | 14:53 |
| pedroalvarez | Kinnison: grr... then the 'systemd-user; file doesn't have that: http://paste.baserock.org/eyufiruyol | 14:53 |
| *** reviewcat is now known as straycat | 14:53 | |
| Kinnison | systemd-user doesn't have any auth | 14:54 |
| Kinnison | so that's fine | 14:54 |
| Kinnison | it probably doesn't do auth since user sessions are, in theory, pre-authenticated | 14:54 |
| pedroalvarez | Kinnison: oh, do you see that '-' prefixes? | 14:54 |
| Kinnison | yes | 14:55 |
| Kinnison | I think that causes "if not present, silently ignore" | 14:55 |
| Kinnison | rather than raising warnings that the file isn't there | 14:55 |
| pedroalvarez | even if it's optional | 14:55 |
| Kinnison | optional will still raise a logged warning if the entry can't be found | 14:55 |
| pedroalvarez | richard_maw suggested me to add that prefix to the pam_selinux requirement | 14:55 |
| pedroalvarez | good to know | 14:56 |
| Kinnison | pedroalvarez: I am not the oracle of all PAM knowledge though | 14:56 |
| Kinnison | pedroalvarez: so don't trust me, do research | 14:57 |
| Kinnison | :) | 14:57 |
| pedroalvarez | investigating now | 14:57 |
| pedroalvarez | I couldn't find useful information about this | 14:57 |
| * Kinnison fears PAM's source may be the best information | 14:57 | |
| * Kinnison also fears PAM's source | 14:57 | |
| pedroalvarez | :) | 14:58 |
| pedroalvarez | Kinnison: thankf for your help | 14:58 |
| pedroalvarez | thanks even | 14:58 |
| Kinnison | :) | 14:58 |
| *** tiagogomes_ has quit IRC | 15:00 | |
| * richard_maw found an oblique reference to the - prefix of lines in pam config in an old website after having seen it used once | 15:03 | |
| richard_maw | I failed to find any official documentation or the example | 15:03 |
| pedroalvarez | it doesn't make any difference | 15:04 |
| Kinnison | if (tok[0] == '-') { /* do not log module load errors */ | 15:08 |
| Kinnison | handler_type = PAM_HT_SILENT_MODULE; | 15:08 |
| Kinnison | ++tok; | 15:08 |
| Kinnison | } | 15:08 |
| Kinnison | from pam_handlers.c | 15:08 |
| ratmice__ | seems to be documented in pam.conf(5) | 15:08 |
| Kinnison | so it is | 15:10 |
| * Kinnison failed to find that on his last read-through | 15:10 | |
| * richard_maw failed to find it on 5 read-throughs | 15:10 | |
| richard_maw | does that stop it counting module load failure as an error though? | 15:11 |
| richard_maw | s/an error/reason to refuse or gain entry independently of the result of running the module/ | 15:11 |
| Kinnison | if (handler_type != PAM_HT_SILENT_MODULE) | 15:12 |
| Kinnison | pam_syslog(pamh, LOG_ERR, "adding faulty module: %s", mod_path); | 15:12 |
| Kinnison | success = PAM_SUCCESS; /* We have successfully added a module */ | 15:12 |
| Kinnison | Based on that, I think missing modules are somehow ignored? | 15:12 |
| Kinnison | pam's code confuses me | 15:13 |
| richard_maw | it looks to me like it just doesn't log the result, it still appears to interpret failure to load as identical to the module failing to authenticate | 15:13 |
| richard_maw | though it's still plausible that it couts a missing module as a success independently of whether a - is listed | 15:14 |
| richard_maw | s;couts;counts; | 15:15 |
| straycat | if there's no comments on https://gerrit.baserock.org/#/c/585 i will merge it | 15:15 |
| * richard_maw is annoyed that he has spent all day puzzling through how best to load all the definitions in a repository for inspection without duplicating the loading logic, but has gained an understanding where the flaw is in the model that prevents us graphing multiple systems at once | 15:17 | |
| richard_maw | Sources are the point of conflation between the logical structure of the input, and the working data structure of what will be produced | 15:18 |
| richard_maw | it's only once Sources are passed to the artifact graphing code that they become invalid for analysing the logical structure of the input | 15:18 |
| ssam2 | could a couple of people review https://gerrit.baserock.org/#/c/584/ (revert GCC to 4.9.2) please? | 15:30 |
| ssam2 | I'd like to get it merged today so the Masons can do the rebuild overnight | 15:31 |
| straycat | i seem to be running into all the broken things today | 15:34 |
| richard_maw | ssam2: not being one of the people who reviewed the update to 5.1 I'm not sure how much use I'd be, but I'll take a look | 15:39 |
| radiofree | ssam2: is that actually the case? i believe richard_maw reverted that and it still didn't work? | 15:42 |
| radiofree | or maybe i missed the rest of the conversation | 15:42 |
| richard_maw | radiofree: I believe you meant someone else | 15:42 |
| radiofree | rdale: :) | 15:43 |
| rdale | i reverted by my host environment, and the deployed system to 4.9.2 and all is well again | 15:46 |
| rdale | ^by^both | 15:46 |
| *** sherm_ has quit IRC | 15:46 | |
| radiofree | godspeed gcc 5.1 then | 15:47 |
| rjek | :-/ | 15:47 |
| *** 16WAAW5JF has joined #baserock | 15:48 | |
| rdale | i've given 584 a +1 | 15:49 |
| rjek | Interesting nick, tiago. | 15:49 |
| 16WAAW5JF | huh | 15:55 |
| * richard_maw grumbles that zookeeper-clients had a broken morphology path to strata/test-tools.morph (was missing the .morph) | 15:56 | |
| *** 16WAAW5JF is now known as tiagogomes | 15:56 | |
| richard_maw | Krin: ^ | 15:56 |
| straycat | better not mention that zookeeper still contains 'github' in the repo field then >.> | 15:59 |
| Krin | they did? i did a lot of testing on them before committing anything... do you need me to solve anything? or are you grumbling that i hadnt solved it? | 15:59 |
| Krin | richard_maw, ^ | 16:01 |
| richard_maw | Krin: look at systems/zookeeper-client-x86_64.morph | 16:02 |
| richard_maw | particularly the test-tools entry in the strata list | 16:02 |
| richard_maw | it's missing the .morph off the end of the "morph" path | 16:02 |
| pedroalvarez | richard_maw: does it fail to build? or just silently ignores it? | 16:03 |
| richard_maw | fails to create the source pool | 16:04 |
| *** a1exhughe5 has quit IRC | 16:05 | |
| Krin | huh. it silently ignored it previously, i'd built that from fresh 5 times before committing it. as it was the first thing i'd done with baserock. i'll take a look and see what is going on while this other thing download (it's taking a while anyway) | 16:06 |
| straycat | can you also fix it so that we're not downloading the chunk from github while you're there | 16:07 |
| *** jonathanmaw has quit IRC | 16:07 | |
| Krin | i'll look at that straycat. but i seem to be seeing an entirely different version of the file to everyone else... the version i see does not have a test-tools entry. | 16:17 |
| Krin | *pulls again and now it IS there* huh... | 16:18 |
| pedroalvarez | oh, the test-tools change has been a recent addition | 16:18 |
| persia | Krin: Which branch and which commit? | 16:18 |
| persia | Krin: compare http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/systems/zookeeper-client-x86_64.morph | 16:19 |
| pedroalvarez | the bug is here: https://gerrit.baserock.org/#/c/543/ | 16:19 |
| persia | Krin: And http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/zookeeper.morph | 16:19 |
| pedroalvarez | s/is/is being introduced/ | 16:19 |
| * Krin 's poor little brain explodes | 16:22 | |
| *** zoli__ has quit IRC | 16:24 | |
| Krin | well the test tools thing should not have been added. that was a mock program that was optional. and instructions for adding it are in the documentation, but it should not be there by default. and i'll try and work out how to make it go away from the default download | 16:26 |
| Krin | (the overall system) | 16:27 |
| *** ssam2 has quit IRC | 16:39 | |
| *** mariaderidder has quit IRC | 16:51 | |
| pdar | When deploying multiple images with a cluster morphology, is there a way to define common fields for each of the images you want to deploy. In the attatched cluster morphology I have a whole bunch of repeated lines and I wondered if it was possible to avoid this. http://paste.baserock.org/ahifeqogox | 16:52 |
| persia | I believe inheritance was discussed previously, but I don't believe it was implemented. I may be wrong (and would be delighted in this case) | 16:52 |
| * pdar crosses fingers for inheritance | 16:54 | |
| richard_maw | pdar: there's two ways | 16:58 |
| richard_maw | 1. there's a deploy-defaults field that can be used to set them for the whole file | 16:58 |
| richard_maw | 2. you can use the yaml anchors, refs and merge keys syntax | 16:58 |
| richard_maw | pdar: the twonode and threenode definitions show the second way | 16:58 |
| persia | Oh right, (2) was the big argument against implementing inheritance: YAML already has it. | 16:59 |
| pdar | richard_maw: cool, thanks! I'll check them out and see what I can c ome up with | 17:00 |
| *** bashrc has quit IRC | 17:01 | |
| richard_maw | pdar: see http://paste.baserock.org/ositijohid | 17:02 |
| richard_maw | persia: there was some form of inheritance we wanted, but it had to cross file boundaries so yaml inheritance wouldn't've been appropriate | 17:04 |
| persia | For clusters? I thought that was for contents. | 17:04 |
| richard_maw | persia: there's previously been arguments against using yaml inheritance because its syntax is arcane, and we should have a mechanism for inheritance at the structural level, rather than syntactic | 17:04 |
| richard_maw | I don't recall any discussions about inheritance for clusters | 17:05 |
| richard_maw | apart from when I first suggested using yaml inheritance in clusters | 17:05 |
| persia | My memory was that we had some discussion about deployment variable inheritance around when we were knocking the sharp edges off `morph upgrade`, maybe 10-15 months ago. | 17:06 |
| persia | But as I said, I may be mistaken (especially given the span of time) | 17:07 |
| Krin | ls | 17:10 |
| pedroalvarez | . | 17:10 |
| pedroalvarez | .. | 17:10 |
| pedroalvarez | baserock | 17:10 |
| Zara | smartest thing I've done today: told a stratum to build-depend on itself. Morph was willing to spend an indefinite amount of time 'deciding on task order'... | 17:11 |
| pedroalvarez | ^C | 17:11 |
| pedroalvarez | Zara: didn't it fail at some point? | 17:11 |
| pedroalvarez | "level recursion exceeded" or something like that? | 17:11 |
| Zara | pedroalvarez: maybe it would have done; I did leave it while I got a cup of tea, so probably >5 minutes, but not hours | 17:11 |
| Zara | I thought there was probably something odd going on so ^C'd out of there | 17:12 |
| *** CTtpollard has quit IRC | 17:13 | |
| pdar | richard_maw: Awesome! Thanks for the paste! | 17:16 |
| *** tiagogomes has quit IRC | 17:18 | |
| *** zoli__ has joined #baserock | 17:25 | |
| *** gary_perkins has quit IRC | 17:30 | |
| *** zoli__ has quit IRC | 17:30 | |
| * SotK is surprised it went for 5 minutes before hitting the maximum recursion depth | 17:48 | |
| pedroalvarez | Yeah, me too | 17:55 |
| *** rdale has quit IRC | 18:08 | |
| *** lachlanmackenzie has quit IRC | 18:23 | |
| *** zoli__ has joined #baserock | 18:42 | |
| *** cyndis has quit IRC | 18:43 | |
| *** Krin has quit IRC | 18:47 | |
| *** Stanto has quit IRC | 18:47 | |
| *** SotK has quit IRC | 18:48 | |
| *** inara has quit IRC | 18:48 | |
| *** inara has joined #baserock | 18:49 | |
| *** Krin has joined #baserock | 18:49 | |
| *** Stanto has joined #baserock | 18:49 | |
| *** SotK has joined #baserock | 18:49 | |
| *** inara` has joined #baserock | 18:49 | |
| *** cyndis has joined #baserock | 19:10 | |
| paulsherwood | is it just me, or does install-essential-files not work for deploy --upgrade ? | 19:13 |
| paulsherwood | i haven't used cycle-sh for a while, but i am sure it used to work. | 19:14 |
| *** cyndis has quit IRC | 19:18 | |
| *** cyndis has joined #baserock | 19:19 | |
| paulsherwood | http://paste.baserock.org/canejehine | 19:22 |
| SotK | pedroalvarez: aha, its just stuck in an infinite loop when creating the source pool | 19:48 |
| *** sambishop has quit IRC | 20:31 | |
| SotK | Zara, pedroalvarez: https://gerrit.baserock.org/#/c/589/ should fix that indefinite hang | 20:48 |
| persia | Oh, heh | 21:26 |
| *** bjdooks has quit IRC | 22:07 | |
| *** bjdooks has joined #baserock | 22:07 | |
| *** petefoth has quit IRC | 22:29 | |
| *** Albert has quit IRC | 22:43 | |
| pedroalvarez | Great SotK! I'll review that tomorrow | 22:50 |
| pedroalvarez | paulsherwood: I believe you need a newer morph | 22:50 |
| Kinnison | I'm sure straycat submitted a patch which fixed the infinite-recursion issue months ago | 22:54 |
| pedroalvarez | I guess that we forgot about old patches in the ML when we moved to Gerrit | 22:59 |
| Kinnison | https://gerrit.baserock.org/#/c/219/ | 23:05 |
| Kinnison | only a month ago | 23:05 |
| *** zoli__ has quit IRC | 23:28 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!