IRC logs for #baserock for Tuesday, 2015-05-12

*** rdale_ has joined #baserock02:30
*** rdale has quit IRC02:34
*** dabukalam has quit IRC03:17
*** dabukalam has joined #baserock03:18
*** dabukalam has joined #baserock03:18
*** zoli__ has joined #baserock06:27
*** a1exhughe5 has joined #baserock07:07
pedroalvarezAlbert: are you around?08:08
AlbertI am08:08
pedroalvarezIn your email you say that 6.2 doesn't build right? So that you want to apply the patch that you have sent to a previous tag08:09
pedroalvarezOr are you suggesting to apply the patch to 6.2? I'm a bit confused08:10
AlbertSorry if I was unclear. The patch need to be applied to 6.208:11
*** mariaderidder has joined #baserock08:12
pedroalvarezah, ok. Part of my confusion is caused by an email in one of the Genivi lists complaining about 6.2 not building for other reasons.08:13
AlbertOh? Not aware of that one.08:13
*** bashrc has joined #baserock08:15
pedroalvarezAlbert: also, part of my confusion is caused by the fact that the typos that you are fixing, doesn't exist in the 6.2 tag08:15
pedroalvarezfor example:
pedroalvarezYour patches seems to change SOURCES for SOUCRES, and in the sourcecode I already see the latter08:16
*** mariaderidder has quit IRC08:17
AlbertLine 165 says SOUCRES instead of SOURCES08:17
pedroalvarezI totally agree, but your patch is the following:08:17
pedroalvarezto me, it means the other way around08:18
*** edcragg has joined #baserock08:18
Albert?? That's odd. I took that straight from the diffs08:18
pedroalvarezindeed, it's odd.08:19
AlbertAh, it could be that I did the diff the wrong way round08:20
pedroalvarezanyway, I understand the problem now08:20
rdale_you should use 'git format-patch..' and 'git send-email..' for sending patches to a mailing list08:21
pedroalvarezyes, that's another point08:21
AlbertWell, one continues to learn08:21
pedroalvarezrdale_: although I'm afraid we have removed that bit from the contributing page08:22
rdale_oh ok - i think the instructions should still be there as we can't always use gerrit08:24
*** mariaderidder has joined #baserock08:25
*** mike has joined #baserock08:26
*** mike is now known as Guest1830508:26
*** gary_perkins has joined #baserock08:28
*** tiagogomes_ has joined #baserock08:28
pedroalvarezrdale_: I agree08:36
*** jonathanmaw has joined #baserock08:36
rdale_i'm just trying to edit the wiki page - if i have a google login for codethink, can that be used as an openid?08:37
pedroalvarezrdale_: also, looks like we might have a use case for it when patching delta repos08:37
pedroalvareziirc google dropped openid support08:37
pedroalvarezbaserock openid should work08:37
pedroalvarezAlbert: biff08:38
rdale_do i have a baserock openid - how do i tell?08:38
* petefoth will reinstate some information about submitting patches to the ML 08:38
petefothUNless anyone else is about to do it08:39
DavePagepetefoth: Put it on the wiki ;)08:39
rdale_yes, please do if i can't - but i would still like to be able to edit the wiki08:39
petefothrdale_: then get yourself a baserock OpenID08:39
rdale_i'm on the page about editing the wiki, but it doesn't say how to get a baserock openid08:40
petefothI'll add that too shall I? ;)08:40
rdale_thanks - i can test the instructions then08:41
pedroalvarezI can see something in the contributing page about our openid08:42
pedroalvarezbut sadly, under "Set up a gerrit account"08:42
rdale_ah so i must have one already08:42
petefothAny other use cases fpor submitting patches to the ML rather than via gerrit? (The ones I have are 1. if gerrit is unavailable; 2. Patches for delta repos08:43
pedroalvarezthat's it, I think08:44
pedroalvarezI can't thing of more use cases08:44
AlbertI'm going to have to patch the morph file for AudioManager. Which branch?08:44
pedroalvarezAlbert: I don't understand your question08:44
pedroalvarezthe morph file shold be in the definitions repository08:44
petefothI was thinking of 'refactoring' the 'Contributing' page to esnure that it is logical and coherent, rather than just a dumping ground for anything vaguely relating to 'contributing'08:45
DavePagepetefoth: That sounds like a useful contribution08:45
petefothDavePage: Oh! I won't do it then ;)08:45
rjekAnsible creator says immutable systems are the future:
DavePagerjek: I wondered when you were going to post that here :)08:46
rjekDavePage: I think what he's suggesting is that you run an ansible playbook, and then remount -oremount,ro /, right?  Yeah, right?08:46
AlbertThat's what I mean. The morph file for AudioManager needs a patch too, for it's calling parameters. There have been changes to Baserock recently, so which Baserock should I make the change to?08:46
pedroalvarezAlbert: send patches against the master branch please. We don't have development branches, only sometimes when we are going to do a release and we don't want to include all the incoming patches in the release.08:48
richard_mawrjek: that article makes me want to have another go at Live Atomic Updates in systemd. Most of the bits are already there, it's just missing the facility to do a pivot without killing off every process09:02
*** ssam2 has joined #baserock09:03
*** ChanServ sets mode: +v ssam209:03
rjekWhat's wrong with a little procicide now and again?09:04
richard_mawrjek: when it happens and you don't intend it to, such as when killall is killall509:05
*** lachlanmackenzie has joined #baserock09:18
petefothI guess another use case for submitting patches via the ML is if a contributor does not have time, energy or motivation to get an OpenID and register to use gerrit. This might be the case for small changes09:23
rdale_or sometimes you submit 'theoretical' patches as part of a design discussion, and don't intend them to be merged09:25
jmacsI agree; I think gerrit is optimised for regular contributors09:27
petefothrdale_: yes, but I think you can do that in gerrit by posting to a special branch (or something - I may be making that up)09:28
petefothI'm going to put the information about submitting  patches via the ML on a spearate page, as there is already too mucj information in 'contributing'09:29
ssam2you can sent private 'drafts' to gerrit09:32
ssam2i'm not sure if you can make them public while still keeping them as 'drafts', so it seems like more of a backup method09:32
ssam2i could be wrong as well09:32
rdale_i would rather use the mailing list for that i think09:32
benbrown_Prepend commit messages with RFC?09:33
pedroalvarezhm.. I have here a mason that is not building anymore :/10:03
pedroalvarezI wonder if this might be a bug in distbuild, but my debugging skills with it are not good10:03
straycat*a* bug10:04
pedroalvarezstraycat: it's working much better than a year ago10:07
straycatyes :)10:09
Zaraany lovely people have a moment to look at ?10:17
*** Albert has quit IRC10:17
pedroalvarezZara: oh, you did what I told you to. Did that work?10:21
*** Albert has joined #baserock10:22
*** mariaderidder has quit IRC10:25
*** mariaderidder has joined #baserock10:25
Zarapedroalvarez: yeah, it did :)10:26
richard_mawI wrote up what I've been doing to support a shutdownramfs in Baserock at since the individual patches don't contain sufficient context, and I don't think they should10:39
*** zoli__ has quit IRC10:44
tiagogomes_I'd like that RFCs sent to the mailing list had a page on the wiki as well, so that they don't get lost10:48
richard_mawthere's an archive10:49
richard_mawand I'd prefer if we didn't have a long-running RFC10:50
richard_mawI'd prefer we concluded whether we want it or didn't wan it soon enough that we don't need to preserve the RFC10:50
richard_mawit would then become a design document of some form instead10:50
tiagogomes_we couldn't not wanting it now but wanting it later; or we could want it now but not wanting allocate resources to implement it10:53
ssam2tiagogomes: some of us use for tracking that sort of thing10:53
ssam2i would understand if you don't want to use it, there are major flaws in the UI of storyboard (at least in the version we have running)10:54
ssam2such as it only lists 10 stories, so you have to play with the sort headers to change which 10 you see10:55
tiagogomes_huh? You can't see all?10:58
*** Guest18305 has quit IRC10:59
Zarafranred: I just tested your change and it does work. :) I think I was just confused about how $DESTDIR worked.11:01
*** zoli__ has joined #baserock11:03
franredZara, then I think you can also skip `ETCDIR=/etc` because it is written in that way in the Makefile11:03
Zaragah :D11:04
franredyou still need to set PREFIX="$PREFIX" because in the Makefile it default it to /usr/local and we like prefix to be /usr11:04
*** zoli__ has joined #baserock11:10
*** zoli__ has joined #baserock11:11
ssam2tiaogomes_: I don't see a way to 'see all' in the UI11:11
*** zoli__ has quit IRC11:13
pedroalvarezssam2: argh! I thought we had only 10 stories!11:13
*** zoli__ has joined #baserock11:14
pedroalvarezwell, if you pick a project, then you can see all the stories of that project11:15
*** Guest18305 has joined #baserock11:15
*** zoli__ has quit IRC11:17
jjardonssam2: Hi, would it be possible to remove the veto from , now that new release is out?11:21
pedroalvarezI think we can close this story now:!/story/2111:22
pedroalvarez(thanks to jonathanmaw)11:22
ssam2jjardon: done11:23
*** petefoth has left #baserock11:23
ssam2we'll probably still have a nightmare upgrading from 15.19 to the next release because of distbuild being broken in 15.19, of course...11:23
ssam2but at least we triedf11:23
ssam2we could tag a 15.19.1 release with the fixed version of Morph, I guess11:24
pedroalvarezI think that would be a good idea11:29
ssam2i'll wait til the various outstanding distbuild patches are merged and then do that11:30
jjardonDoes anybody remember why 2c7dc4cd1531d97aaf3823d23eeba4e0bb6742be of definitions was needed? ("Update the jetson cluster to use BOOT_DEVICE")11:45
jjardonradiofree: ^ ?11:45
ssam2because we have a separate ext4 partition for holding the kernel when deploying to Jetsons, now11:45
ssam2so BOOT_DEVICE points to the ext4 partition and ROOT_DEVICE points to the btrfs partition with /usr and everything11:45
ssam2i think that's needed because of bugs in U-Boot trying to read the kernel from Btrfs11:46
jjardonah, ok11:47
*** zoli__ has joined #baserock11:48
jjardonIm trying to run "morph deploy" but its failing with this error: Shouldnt that utility be in all the baserock systems?11:49
jjardonthis is my cluster file:
ssam2it should be present in the 'build' and 'devel' systems, which are the ones that contain Morph11:50
pedroalvarezare you by any chance using a cross-bootstrap system to deploy that?11:50
jjardonpedroalvarez: im inside the chroot resulting from native-build the bootstrap system, yes11:52
ssam2ignore the failure on, I'm changing their network config12:07
ssam2will announce on baserock-dev when it's done12:07
*** zoli__ has joined #baserock12:30
paulsherwoodwhile waiting (an hour!?) to wget latest build-system and wondering why it's so big, i came across this...
ssam2it's mostly big because we do no debug stripping at all12:41
richard_mawpaulsherwood: that approach would require hand-crafting all our executables, which is not feasible12:41
* rjek does not want to replace GCC with a small ELF binary written in assembly.12:42
ssam2that is an interesting article though12:42
rjekI have used C and C++ compilers written in assembler.  It's not nice.12:43
richard_mawpaulsherwood: after stripping binaries, the next step to tiny installer images is to contort your system such that you ship a squashfs rootfs, but we're some ways away from read-only /usr, and I've no idea how we'd do upgradable systems with a squashfs rootfs12:45
nowsterrjek: paulsherwood: 45 bytes is still longer than #/bin/sh\nexit 42\n12:55
rjeknowster: :)12:55
paulsherwoodi wasn't actually suggesting that approach... i just thought it might be of interest here12:56
paulsherwoodwhat i *would* like to suggest is that we should strip binaries12:57
Kinnisonpaulsherwood: It's a somewhat old article12:57
* Kinnison remembers reading that back in uni12:57
Kinnisonwell, in summer holidays after 1st year12:57
paulsherwoodstripping binaries on its own would make a big difference i believe12:58
Kinnisonstripping would make sense12:58
Kinnisonand could be done as a configure extension12:58
Kinnisonif we built our binutils appropriately12:58
rjekOn the other hand, debug symbols in a developer system can be handy12:58
radiofreeBOOT_DEVICE isn't just useful on a jetson, the thinkpad i installed baserock on uses it as well12:58
richard_mawif we're posting interesting artcles: is interesting12:58
radiofreerather than just having one giant "/dev/sda" with no partition table12:59
ratmice__i've been annoyed by the whole debug symbols/separate debug symbols thing lately (how to get the separate debug symbols, you compile with debug info, copy the debug symbols out, then strip them from the original) be so much less work to just generate them in a separate file initially13:10
jjardonpedroalvarez: so, how should I meant to deploy in this system? (4c) doesn't seem to say anything more is needed13:26
pedroalvarezthis is because the 2 times I've done this, I deployed to a nfs server13:28
pedroalvarezso I didn't face this problem, and i didn't document anything13:28
pedroalvarezI think the best approach for your situation is to, with that chroot, build a build/devel system, and deploy it using sysroot.write to generate another chroot with all the tools needed.13:29
*** Guest18305 has quit IRC13:41
rjekratmice__: ++13:44
rjekI think Debian has some automatic infrastructure for ripping out debug symbols from libraries and such so they can be put in different packages.13:45
rjekPerhaps something artefact splitting could also do?13:45
*** petefoth has joined #baserock13:46
jjardonpedroalvarez: :( ok, thanks. Is there any documentation/examples about how to use that extension?13:47
petefothThe 'Submitting patches via the Mailing List' page now exists at and is referenced from the 'Contributing' page. The text is a straight copy of the old version and could probably do with some pruning, but I'll leave that until we've thought some more about making the 'contributinsg' pages more engaging for new contributors13:48
pedroalvarez`morph help sysroot` says it doesn't have any documentation13:49
richard_mawrjek: my thoughts on debug symbols were to move build-systems to definitions, add strip commands to post-install-commands and tie the default split rules to build-systems, so it defines a -debug artifact13:50
rjekrichard_maw: Sounds ideal.13:50
pedroalvarezjjardon: well, maybe is better to deploy to a tarball13:50
pedroalvarezwhich is documented :) `morph help tar.write`13:51
paulsherwoodam i alone seeing a kernel panic on current build-system-x86_64.img.gz ?13:52
pedroalvarezpaulsherwood: I can give it a go13:52
paulsherwoodalso it seesm to take longer to boot than ever before13:53
*** Guest18305 has joined #baserock13:53
jjardonpedroalvarez: ok, I will take a look, thanks13:54
* paulsherwood does wonder what's happened here13:54
pedroalvarezpaulsherwood: I think something is wrong with that13:54
ssam2could be the initramfs13:54
pedroalvarezinitramfs is only 6M IIRC :/13:55
jjardonpedroalvarez: I think ssam2 is talking about the boot speed13:55
pedroalvarezbuild 32b is  621M13:55
pedroalvarezah, true13:55
pedroalvarezpaulsherwood: but then, does it boot?13:56
pedroalvarezand the kernel crashes later?13:56
paulsherwoodkernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block(0,0)13:57
jjardonrichard_maw: you mean we will have to create a tiny morph file for every chunk only to put what build system is using? or the plan is to add the build system in the stratum?13:57
richard_mawjjardon: did I say I was going to make build-system detection manual?13:58
richard_mawI just said that the logic for what a build system provides should be moved to definitions13:59
ssam2oh, so the release is broken!13:59
ssam2I probably did only test x86_32.13:59
richard_mawjjardon: the detection rules would have to go with it13:59
*** Guest18305 has quit IRC13:59
jjardonrichard_maw: ah, ok. sorry I misunderstood13:59
pedroalvarezssam2: I 've just finished downloading the 64b image, I'm going to test it now14:00
* richard_maw currently favours removing automatic build-system detection, but only if we could in-line it in the stratum, and has oscillated between wanting it and not wanting it too much to seriously suggest it14:01
ratmice__rjek: yeah, there is an example of how to do that:
ratmice__rjek: objcopy --only-keep-debug foo foo.debug14:06
pedroalvarezpaulsherwood: I confirm that the image doesn't boot14:09
ssam2but the x86_32 image (no initramfs) does, so I think it's definitely the initramfs that broke things14:10
ssam2jjardon: how did you test (adding initramfs to x86_64 system) -- did you see it working?14:12
pedroalvarez547M of initramfs :/ something is wrong :)14:12
jjardonssam2: I built a weston x86_64 image and boot it in my laptop14:14
jjardonssam2: I posted screenshots in this channel14:14
ssam2cool. I wonder if this problem is specific to the build-system-x86_64 then14:14
ssam2hard to understand how that would happen though14:14
*** Guest18305 has joined #baserock14:15
ssam2ok, this turns looks like a long chain of failure that leads to it being my fault14:18
ssam2the build-system-x86_64.img contains /itself/ as an initramfs, rather than the actual initramfs14:19
ssam2which is why it's huge and why it doesn't boot14:19
paulsherwoodssam2: safest way to avoid mistakes is not to do anything ;)14:19
ssam2the reason this happened is: I had followed to use Morph from the source tree (because it's impossible to build this release with Morph from the previous release)14:20
ssam2but I had a work-in-progress branch checked out, instead of 'master', by accident14:20
ssam2and that branch (it turns out) has a regression in `morph deploy` that caused this screwup14:21
pedroalvarezwell, I think we have learned some interesting lessons :)14:21
ssam2the universe will always build a better fool14:22
* DavePage suspects that release builds should be generated in an automatically-created clean environment?14:23
ssam2yes, that would be good14:23
ssam2I guess I'll redeploy and reupload the release images for 15.19, since it's not the baserock-15.19 tag of definitions that is broken14:24
ssam2thanks for spotting this paulsherwood!14:25
ratmice__rjek: oh, and i'd be wary of lifting stuff from debian in this regard (years ago so maybe i recall incorrectly), but their separate debuginfo stuff showed up in debian before it landed upstream and they ended up carrying an incompatible version (not sure if that is still the case)14:34
rjekratmice__: I think it works pretty well now, at least for the libraries that have it (it isn't universal)14:36
ratmice__rjek: right, i just mean they have to carry patches since they are slightly incompatible with upstream in some way that i can't recall14:37
rjekThat seems sadly likely.14:38
rjekBut, for libraries it can be done with, doing it automatically seems like a win.14:38
pedroalvarezDavePage: we have been thinking about that, and I think it will eventually end up as part of the process14:43
DavePagepedroalvarez: *nods*14:43
*** Albert has quit IRC14:54
*** Albert has joined #baserock14:55
ssam2I've uploaded a fixed version of
ssam2apologies for the cockup15:02
ssam2I'll mail baserock-dev as well15:02
pedroalvarezZara: I'm currently wondering if we can drop your 3 lorries patches, e. i. you know you don't need them (as Javier suggested)15:04
Zarapedroalvarez: I think we will want one of them (the openbmc one), but it looks like we won't need the other two15:06
pedroalvarezZara: ok, no rush, just wondering15:06
Zarayeah, I've left them there because I'm still not 100% sure we won't need them later, but so far it's looking like we won't need them :)15:07
franredZara, you could abandon them and if you need to recover them, you could do from the abandoned page15:08
Zaraokay, will do.15:08
franredjust FYI, as pedroalvarez said there are not rush on it15:08
*** paulw has quit IRC15:43
*** a1exhughe5 has quit IRC15:44
jjardonDo you think it would be a good idea to split the build systems? Not sure a embedded developer would like to build the openstack support15:48
ssam2you mean the openstack clients? I imagine they're quite small15:51
ssam2I don't want to do anything that makes the release process more complicated15:51
jjardonfair anough16:00
franreddoes the python import tool only import python packages hosted in Pypi? is it possible import dependencies from a downloaded repo? (i.e. Nova or Openstack-nova does not exists in Pypi but would be nice if I can clone nova and get a lorry/stratum with its dependencies using the cloned repo)16:04
ssam2i'm not sure. straycat ?16:04
ssam2the question is whether the cloned repo contains enough info or not16:05
ssam2but there's some way of discovering the URL, the python.to_lorry program could be extended to support that method16:05
ssam2I've hit a weird error with `morph diff`:
richard_mawssam2: that's because some stratum missed the .morph off the end of the morphology file of a dependency16:07
richard_mawyou can limit yourself to a subset of the systems by listing the paths after the ref16:08
ssam2ah, right16:08
* richard_maw doesn't recall which system definition is broken, but it happened during the OpenStack reshuffle16:08
richard_mawit's zookeeper-clients IIRC16:09
pedroalvarezoh, still broken :(16:09
* pedroalvarez can fix that16:09
franredssam2, other way to do this is passing to the import tool where the repository instead of the name of the python package16:12
franreds/instead/is or its URL instead/16:14
franredstraycat, ^^16:14
ssam2franred: at what point?16:14
ssam2you can already create a .lorry file manually for any components, which the import tool will then load as if it had created them itself16:15
franredssam2, can I point the import tool to a stratum  or a system too?16:18
pedroalvarezfranred: I assume you have found the docs
ssam2what do you mean by "point" ?16:20
ssam2the import tool *creates* a stratum, it doesn't look at strata or systems at all16:20
ssam2it'd be nice to improve it so that it updated existing definitions, rather than spitting out a new stratum, but I think that's not trivial and would require changes to the definitions format for it to be that good16:21
franredpedroalvarez, I've read the docs and check the command line16:21
franredssam2, yeah, I've misunderstood your previous sentence about the lorry file16:22
ssam2I'm going to create a baserock-15.19.1 release tag, with (test-tools.morph fix) and (update morph to latest) on top of 15.1916:24
ssam2mainly because distbuild was really broken in 15.1916:24
jjardonHi, I have this build failure that its fixed if I compile with -02 instead the morph defaults (-march is armv5te). What is the bes way to proceed here? I noticed something similar seems to be needed by glibc16:25
franred --> says explicitly "Please note that this tool expects any python packages to be on pypi, you cannot currently import packages from other places"16:25
ssam2right. I don't know the details of how that works, best to discuss with straycat whenever he is around16:27
franredok I will wait for straycat :), thanks anyway16:29
*** ssam2 has quit IRC16:35
jjardonpedroalvarez: so, should something be added to the cross- systems? maybe we should move btrfs-progs to core?16:42
paulsherwooddoes anyone have a jetson that they could try something out on for me please?16:48
jmacsaarch64be ok?16:48
richard_mawaarch64 on a Jetson?16:49
richard_mawI thought they were 32-bit16:49
paulsherwoodi assume he means moonshot16:49
jmacsNo, armv7b, sorry16:49
paulsherwoodbasically any non x86 baserock system16:49
jmacsWhat would you like me to try?16:50
paulsherwoodbuilding a system on it using ybd :)16:50
jmacsOK, if you point me at some instructions...16:51
paulsherwoodeither it should 'just work' in which case it'll sit there building overnight, or you'll hit a rock immediately and that would be useful feedback16:52
*** Guest18305 has quit IRC16:53
paulsherwoodgit clone into your /src, then cd into a checkout of definitions, then run python /src/ybd/ybd $system $arch16:53
paulsherwoodwhere $system is relative path to a morph file describing a system that can be built on arnv7b, and $arch is whatever morph arch needs to be (presumably armv7b)16:54
jmacsMy definitions may be quite old, does that matter?16:54
paulsherwoodno, should be fine16:54
paulsherwoodor you chould clone a new copy somewhere16:54
paulsherwood(doesn't need a workspace, just a git checkout)16:54
jmacsOK, I'm building devel-system-armv7b-highbank.morph as there doesn't seem to be a morph for armv7b-jetson16:56
jmacsIt appears to be doing things.16:56
* paulsherwood crosses fingers 16:56
paulsherwoodif it seems happy, could you leave it running overnight please?16:57
jmacsYes, no problem16:57
paulsherwood(can be killed and re-started if that's better for you)16:57
*** mariaderidder has quit IRC17:02
*** bashrc has quit IRC17:02
*** cyndis has quit IRC17:02
*** bashrc has joined #baserock17:02
*** cyndis has joined #baserock17:02
*** lachlanmackenzie has quit IRC17:29
*** gary_perkins has quit IRC17:32
* paulsherwood successfully upgrades a devel system using ybd17:33
jmacsybd last said "2015-05-12 17:28:54 [systems/devel-system-armv7b-highbank.morph] Finished" but hasn't exited yet17:36
jmacsI'll leave it running17:36
Kinnisonit's unlikely to have completed that fast17:36
KinnisonI'd look back in the log for errors17:36
paulsherwoodthat sounds like a bug... it's doing some forking... for a notional 'distbuild'17:39
paulsherwoodjmacs: thanks :)17:39
* paulsherwood needs to work out how to fork and drop all context_managers17:39
*** Albert has quit IRC17:43
*** zoli__ has quit IRC17:53
*** edcragg has quit IRC18:03
*** rdale_ has quit IRC18:36
*** zoli__ has joined #baserock18:53
*** zoli__ has quit IRC18:58
*** zoli__ has joined #baserock20:35
*** Albert has joined #baserock22:27
*** Albert has quit IRC22:32
*** zoli__ has quit IRC23:33

Generated by 2.14.0 by Marius Gedminas - find it at!