| *** juergbi [~juerg@vserver.paldo.org] has quit [Ping timeout: 255 seconds] | 03:44 | |
| *** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 255 seconds] | 03:44 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 03:44 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 03:44 | |
| *** juergbi [~juerg@vserver.paldo.org] has joined #baserock | 03:46 | |
| *** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has joined #baserock | 03:50 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 05:57 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 05:57 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 05:57 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Client Quit] | 05:58 | |
| *** aananth [~caananth@74.112.167.117] has joined #baserock | 08:08 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:11 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 08:54 | |
| pedroalvarez | Hi all | 09:03 |
|---|---|---|
| pedroalvarez | I'm pondering doing a full release, increasing the size of the disks | 09:04 |
| paulsher1ood | increasing the size of the disks? which disks? | 09:05 |
| pedroalvarez | of the build systems released, so there is more space to do self upgrades | 09:05 |
| paulsher1ood | oh, yes. ok | 09:05 |
| paulsher1ood | same for devel | 09:05 |
| paulsher1ood | (and release email should explain this, and need to tweak the wiki) | 09:06 |
| paulsher1ood | i did separate out the 'increase space' instructions in prep for this | 09:06 |
| pedroalvarez | regarding the devel system, we decided to release only the build system | 09:07 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:07 | |
| paulsher1ood | oh? ok | 09:10 |
| paulsher1ood | no genivi? | 09:10 |
| pedroalvarez | yeah! | 09:11 |
| pedroalvarez | :) | 09:11 |
| pedroalvarez | to be clear, when I say full release I mean release all the systems in clusters/release.morph | 09:12 |
| paulsher1ood | right | 09:12 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 09:15 | |
| pedroalvarez | on the other hand, I also wonder if makes sense to make the images of jetson smaller, so it takes less time to flash them | 09:17 |
| pedroalvarez | I think is possible to specify the size of the disk on the jetson-flash script | 09:18 |
| paulsher1ood | it is | 09:18 |
| pedroalvarez | great | 09:19 |
| pedroalvarez | then I think is a good idea. | 09:20 |
| paulsher1ood | yes | 09:21 |
| * pedroalvarez thinks that 6G for build systems is ok | 09:24 | |
| pedroalvarez | So this is basically my proposal: http://paste.baserock.org/ujaxopukuz.sm | 09:28 |
| persia | Is the "2G" for the devel-system-armv7lhf-jetson a typo? | 09:29 |
| pedroalvarez | nope | 09:30 |
| pedroalvarez | when the image is 4G you have to wait for 0's to be flashed | 09:30 |
| persia | This is for flash speed? Won't that break upgrades entirely? | 09:30 |
| franred | how big is the minimal image for the jetson? | 09:30 |
| pedroalvarez | the main point here is that you can set up the disk size when flashing | 09:30 |
| persia | Ah, OK. | 09:31 |
| pedroalvarez | so it won't break the upgrades | 09:31 |
| franred | if it is more than 1, I would suggest not to make it less than 3GB | 09:31 |
| pedroalvarez | I'm not 100% sure about that change because I've never tried it myself | 09:34 |
| franred | pedroalvarez, forget what I said... | 09:34 |
| pedroalvarez | franred: no worries :) | 09:34 |
| pedroalvarez | I see that in the script that James has sent for review he has changed the ROOTFS size :) | 09:37 |
| *** aananth [~caananth@74.112.167.117] has quit [Ping timeout: 256 seconds] | 09:45 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:46 | |
| radiofree | persia: you can run the btrfs filesystem resize max command once it's flashed | 09:50 |
| radiofree | so then it expands from 2G to 14G | 09:50 |
| persia | In that case, why do we specify the size in the cluster definition? wouldn't it be better to always be minimum size? | 09:50 |
| radiofree | i thought you had to specify it? | 09:51 |
| persia | Yes, but why? conputers are good at math | 09:51 |
| radiofree | oh right, yes, i agree, you shouldn't need to do that | 09:52 |
| persia | Well, perhaps it is important for non-growable filesystems, but in that case "auto" ought be an acceptable value (and probably the default) | 09:53 |
| pedroalvarez | i've been thinking about this, and deploying images with the minimum disk size possible can cause the system to not boot at all | 09:55 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:55 | |
| pedroalvarez | am I right? | 09:55 |
| persia | how so? | 09:56 |
| pedroalvarez | my idea was to reduce the disk size for the cloud systems, so cloud-init will resize them after boot | 09:57 |
| pedroalvarez | but then I thought, will a btfs system boot with no space free? | 09:57 |
| persia | For the Ubuntu MID project, we put in an extra 100M of space in the images, to support folk hacking images before deployment, but this extra space may have also served other purposes (all my other image exerience is with iive and installer images, which are different) | 09:57 |
| Kinnison | pedroalvarez: with zero space free, probably not | 09:58 |
| *** ssam2 [~ssam2@cpc7-asht7-2-0-cust170.10-1.cable.virginm.net] has joined #baserock | 10:01 | |
| Mode #baserock +v ssam2 by ChanServ | 10:01 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 10:02 | |
| *** aananth [~caananth@74.112.167.117] has joined #baserock | 10:02 | |
| ssam2 | happy friday everyone! | 10:02 |
| Kinnison | Hmm | 10:02 |
| Kinnison | :-) | 10:02 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 10:03 | |
| pedroalvarez | Hi ssam2! | 10:04 |
| ssam2 | i seem to have accumulated a monumental pile of email in 3 days, but a lot of it seems to be 'you have received a new secure message' spam | 10:05 |
| *** locallycompact [~lc@65.56.200.146.dyn.plus.net] has quit [Ping timeout: 272 seconds] | 10:06 | |
| Kinnison | heh | 10:06 |
| persia | If you received the email, the message is already compromised :) | 10:06 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Client Quit] | 10:06 | |
| pedroalvarez | wow, took me only 20 minutes to deploy all the systems of release.morph | 10:11 |
| *** abdul [~abdul@202.0.77.198] has quit [Quit: Leaving] | 10:11 | |
| pedroalvarez | Is the easiest release ever | 10:12 |
| radiofree | was that using the public facing mason? | 10:12 |
| radiofree | which is the best thing ever | 10:12 |
| pedroalvarez | yes | 10:13 |
| pedroalvarez | also, I have to say that I deployed the systems in the same network of mason, so fetching the system artifacts was fast | 10:13 |
| pedroalvarez | same as* :) | 10:14 |
| persia | Getting closer to releases being only a new tag :) | 10:17 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:18 | |
| pedroalvarez | hm.. we broke list-artifacts plugin: http://paste.baserock.org/poraqaxiru.rb | 10:31 |
| Kinnison | Is there no yarn for that? | 10:31 |
| pedroalvarez | I assume there isn't | 10:31 |
| ssam2 | no. feel free to write one! | 10:31 |
| Kinnison | :-( | 10:31 |
| paulsher1ood | heh | 10:31 |
| ssam2 | actually, seems like I tried not to break it but somehow still managed to break it | 10:32 |
| paulsher1ood | so if we are ready to make the dc artifact server the default, it's all done? | 10:32 |
| paulsher1ood | (that could be as simple as telling folks to add the line to their morph.conf) | 10:32 |
| ssam2 | that line should be morphlib.sourceresolver.create_source_pool rather than morphlib.SourceResolver.create_source_pool | 10:32 |
| pedroalvarez | thanks ssam2! | 10:34 |
| radiofree | Javier needs to change his name, it appears as "Javier Jard<C3><B3>n" in a git log message on baserock | 11:12 |
| richard_maw | it could be worse, my name appears as "Richard Maw"! | 11:13 |
| * richard_maw stops making silly comments | 11:14 | |
| straycat | please don't :) | 11:14 |
| persia | radiofree: In which locale do you see that? | 11:14 |
| pedroalvarez | my name sometimes is My Name :) | 11:15 |
| radiofree | persia: i'm using a genivi system as a developement environment | 11:15 |
| radiofree | i'm not sure this is an issue on the devel systems | 11:15 |
| persia | In that case, you are using the C locale, which cannot handle UTF-8, hence the issue. | 11:18 |
| pedroalvarez | given that the baserock-flash script is going to end up in scripts/ I decided to release the jetson systems as compressed .img files and also the u-boot file. | 11:20 |
| radiofree | pedroalvarez: did you remember to change the device tree name in the devel system release cluster? | 11:24 |
| pedroalvarez | yup | 11:24 |
| radiofree | great! | 11:24 |
| pedroalvarez | all the changes I made are visible in the release branch | 11:24 |
| pedroalvarez | I also tested the build-system and the genivi-system, | 11:24 |
| pedroalvarez | and they worked | 11:24 |
| paulsher1ood | pedroalvarez: i wasn't able to get the genivi-ivi shell thing running. do the instructions need to be changed? | 11:25 |
| pedroalvarez | oh! I think that is because we are saying there that weston has to use the fbdev backend | 11:27 |
| pedroalvarez | and in arm that's not true | 11:27 |
| pedroalvarez | but it is in x86 | 11:27 |
| radiofree | yes for jetson you just run "weston" | 11:27 |
| radiofree | btw that graphical environment, while fancy and nice to play with, is *not* the genivi-ivi shell | 11:28 |
| radiofree | unfortunately if ivi-controller (the genivi part) displays... nothing.. until you setup a load of layers | 11:28 |
| paulsher1ood | radiofree: when i followed the instrcutions, all i got was normal weston i think | 11:30 |
| * pedroalvarez is stuck with the relase notes | 11:32 | |
| radiofree | are you sure you copied it to .config/weston.ini | 11:32 |
| paulsher1ood | yup | 11:32 |
| radiofree | cd /root/.config | 11:32 |
| paulsher1ood | ... i'll check | 11:32 |
| radiofree | and run weston from there | 11:32 |
| paulsher1ood | ah, no. i need to rename it :) | 11:33 |
| ssam2 | pedroalvarez: re. the broken `morph list-artifacts`, do you want me to send a patch to fix it ? | 11:33 |
| * radiofree will refrain from posting the line from CMU Sphinx about debugging | 11:34 | |
| pedroalvarez | ssam2: I don't have the time to fix it today, and I solved the issue I had with that command using a version of morph that works | 11:34 |
| paulsher1ood | radiofree: thanks :-) | 11:34 |
| paulsher1ood | radiofree: go ahead and post it, though :) | 11:35 |
| radiofree | "Troubleshooting is not rocket science. For all issues you may blame yourself. You are most likely the reason of failure." | 11:35 |
| paulsher1ood | :-) | 11:36 |
| radiofree | i need to put that on a post-it note and stick it to my monitor | 11:36 |
| ssam2 | pedroalvarez: ok, I'll send a patch | 11:42 |
| radiofree | i wonder if it would be possible to flash u-boot from within baserock | 11:45 |
| aananth | Hi, today I am trying to build an image from my Jetson board, configured vtsc-trove as its trove-host. But it throws "is an invalid reference for repo git://136.18.233.152/delta/linux". Details in http://fpaste.org/150734/59654151/. | 11:45 |
| aananth | Any idea? Is it because of the new trove server is not completely synced? | 11:45 |
| radiofree | i'm thinking - create a boot.scr file with the correct commands, reboot, have u-boot load that and flash the new u-boot and then delete the boot.scr file so it then boots normally | 11:46 |
| pedroalvarez | aananth: yeah, that can be the cause | 11:47 |
| jmacs | Hmm, I'm sure I used to have mkfs.ext4 on my baserock system | 11:47 |
| paulsher1ood | pedroalvarez: i'm not sure it is the cause, i think there are other corner cases maybe | 11:47 |
| radiofree | that ref is for the completely wrong kernel though | 11:48 |
| pedroalvarez | radiofree: what do you mean by that | 11:48 |
| radiofree | that's the ref for baserock/v3.8 | 11:49 |
| radiofree | which almost certainly won't boot the jetson | 11:49 |
| aananth | pedroalvarez: Thanks. I just checked the journalctl, I could see ntpd-boot.service in Jetson is unable to sync clock... Can that be another cause? | 11:49 |
| persia | radiofree: Yes, although for local flash, we'd need a flash program, and for remote flash, we'd need to think about it a bit more, and probably add a new deployment mechansim to morph | 11:50 |
| pedroalvarez | aananth: I don't thnk that's the issue | 11:50 |
| radiofree | aananth: i see you're using upgrade-devel.morph | 11:50 |
| radiofree | did you change the system name in that? | 11:50 |
| radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/clusters/upgrade-devel.morph | 11:51 |
| radiofree | uses devel-system-x86_64-generic.morph, which uses that kernel ref | 11:51 |
| paulsher1ood | aananth: if you're upgrading a jetson, you need jetson-upgrade.morph as your cluster | 11:51 |
| jmacs | Does anyone know why I don't have mkfs.ext4 on my baserock linux system, or where it should come from? | 11:51 |
| radiofree | persia: there's the tegra-uboot-flash scripts from nvidia that work really well if you have a laptop | 11:51 |
| radiofree | the only part i'm a bit unsure about is "then delete the boot.scr file" | 11:52 |
| persia | Right. Those should work fine from a baserock laptop. My memory of working with them involves some x86 binary code, which may be an obstacle in some situations. | 11:52 |
| pedroalvarez | jmacs: I hope this helps: http://paste.baserock.org/yulejigawe.avrasm | 11:52 |
| radiofree | persia: the nvflash in the L4T release is x86, however these scripts should work on arm | 11:53 |
| radiofree | since you have the source and can compile it | 11:53 |
| persia | radiofree: Give it a try. If it works, add a deployment mechanism for it :) | 11:53 |
| radiofree | however that requires the jetson to be in recovery mode and it does it via usb, so not that useful running on the board you want to flash | 11:53 |
| persia | We ought be able to just specify to use that in a cluster definition, so that one can do everything sensibly. | 11:53 |
| persia | No, but it is useful if you have a build board and a test board, and your test board USB gadget is connected to your build board USB host. | 11:54 |
| radiofree | i was thinking of doing it in a similar way by touching a file which our (modified) u-boot looks for, if there, follow the commands to upgrade u-boot | 11:54 |
| * persia wants to simplify the model for folk fiddling with local dev boards, as the current mess is a bit annoying | 11:54 | |
| jmacs | pedroalvarez: Yes, that'll be it, thanks | 11:55 |
| persia | radiofree: Handling local upgrades for deployed systems is also a nice area to fix, but it doesn't help folk migrating to baserock, or comparing baserock systems to legacy systems, or similar workflows. | 11:55 |
| pedroalvarez | jmacs: not sure if it's present in latest devel system, the system I'm using is a couple of months old. | 11:56 |
| aananth | paulsherlood: thanks :-). Should I make any changes to the jetson-upgrade.morph? (like TROVE_HOST, TROVE_ID etc)? | 11:56 |
| pedroalvarez | do we still have TROVE_HOST and TROVE_ID in jetson-upgrade? | 11:56 |
| pedroalvarez | hah | 11:56 |
| paulsher1ood | i think they are ignored, aananth | 11:56 |
| pedroalvarez | these are for now the release notes: http://paste.baserock.org/izunaragoc.md | 12:03 |
| straycat | Does morph insist that morphologies must be yaml now? (they can't be json anymore?) | 12:04 |
| straycat | Okay I guess it does. | 12:07 |
| radiofree | i was thinking last night that the number of systems could be massively reduced if you separated the idea of a system from it's bsp | 12:08 |
| radiofree | so you'd do something like morph build devel-system jetson-bsp | 12:08 |
| radiofree | morph build devel-system x86_64 etc... | 12:08 |
| straycat | multi-arch systems would be cool | 12:09 |
| pedroalvarez | but then our devel-system for ppc is different than the others | 12:09 |
| aananth | radiofree: do I need to change the system name if I use clusters/jetson-upgrade.morph as my cluster? | 12:13 |
| radiofree | i don't think so | 12:13 |
| ssam2 | pedroalvarez: release notes look good | 12:17 |
| radiofree | pedroalvarez: The Wayland 'drm' backend is working on the NVIDIA Jetson in this release | 12:17 |
| radiofree | it was working on the previous release? | 12:17 |
| pedroalvarez | ssam2: I have to confess that I reused yours :) | 12:17 |
| pedroalvarez | radiofree: it wasn't working IIRC | 12:18 |
| pedroalvarez | radiofree: at least we said that in the release notes | 12:18 |
| ssam2 | peroalvarez: ''This change can cause that the self-upgrade of a system doesn't work if the system has less than 2G free on its rootfs.' -> 'This change might cause self-upgrade of a system to fail if the system has less then 2GB free in its root file system' | 12:18 |
| ssam2 | pedroalvarez: reusing release notes is the only sensible way ! | 12:18 |
| radiofree | well only one client didn't work, i think it's a bit unfair to say the whole thing didn't work because of that | 12:18 |
| pedroalvarez | radiofree: do you think I have to remove that point in the release notes? | 12:19 |
| pedroalvarez | ssam2: thanks for helping :) | 12:19 |
| radiofree | pedroalvarez: yeah :) | 12:20 |
| pedroalvarez | ssam2: actually I think there is not harm in putting 3G there instead of 2G | 12:22 |
| straycat | ssam2, this startum morph generation has hardcoded ruby stuff in it, is that intended? | 12:22 |
| straycat | *stratum | 12:22 |
| pedroalvarez | I don't know what else can I say in the genivi release notes: http://paste.baserock.org/zibigexaxi.md | 12:26 |
| pedroalvarez | paulsher1ood: can you plase review them? ^^ | 12:26 |
| * straycat reads them while he waits | 12:28 | |
| pedroalvarez | straycat: the full release notes are these: http://paste.baserock.org/yeratezake.vhdl | 12:28 |
| straycat | pedroalvarez, "There have been more changes since the Baserock 14.40" | 12:29 |
| straycat | I think you mean to say 14.40 release | 12:29 |
| straycat | I'd also drop the comma after "Any questions" | 12:29 |
| persia | pedroalvarez: Those look fine to me. if you want to be expansive, you can detail what else changed in Baserock versions, but perhaps it is better to cause folk to read the regular release notes (because it invites them to think about Baserock more widely) | 12:29 |
| pedroalvarez | straycat: thanks! :) | 12:29 |
| ssam2 | straycat: what stratum morph generation ? | 12:30 |
| pedroalvarez | persia: is what we do always, just point the genivi releated changes and then link the full release notes | 12:30 |
| persia | Then that is probably the strategy to continue to follow | 12:30 |
| straycat | ssam2, _generate_stratum_morph_if_none_exists in mainloop.py | 12:30 |
| ssam2 | straycat: ah! well, it's intentional but only as a temporary solution | 12:31 |
| * straycat nods | 12:31 | |
| straycat | Okay so you'd be fine with modifying it to make it more general? | 12:32 |
| straycat | *with me | 12:32 |
| straycat | as typos go, that was a bad one | 12:32 |
| ssam2 | that'd be great | 12:32 |
| straycat | Okay cool thanks | 12:32 |
| ssam2 | it's only the stratum build depends that are ruby-specific I think | 12:32 |
| ssam2 | so I guess the cmd_rubygem() function and the other ones could just pass in what strata should be build-depends of the generated stratum, if that works | 12:33 |
| ssam2 | it might get a bit more complex, but hopefully not yet :) | 12:33 |
| ssam2 | I guess the 'm['x-build-dependencies-rubygems'].iteritems()' needs to change too ... I guess it should iterate through each kind in self.importers (the list of importers that were enabled) | 12:35 |
| aananth | paulsherlood: I did "morph edit bzip2", I could see the git is cloned to Jetson board (successful first step! yay!!), I added a #error statement to find out the time Jetson takes to find that error, but I get similar warning as earlier. See http://fpaste.org/150746/14159682/ | 12:35 |
| aananth | How do I confirm if the trove is completely synched or what % is complete? | 12:36 |
| straycat | ssam2, yes that's what's in the way of my import currently, I think iterating through the enabled kinds would be good | 12:37 |
| radiofree | aananth: i'm not sure why it's complaining about that, df2e1b9168a7ab5dd8149e38b5ac70cdef86d1fa is the wrong kernel for a jetson | 12:39 |
| paulsher1ood | pedroalvarez: is that on the wiki somewhere? i'd like to edit | 12:45 |
| pedroalvarez | paulsher1ood: feel free: http://wiki.baserock.org/releases/baserock-14.46/ | 12:46 |
| aananth | radiofree: I get "Repository seems to be empty", if I try to view http://136.18.233.152/cgi-bin/cgit.cgi/delta/linux.git/ from the browser. Could the synch incomplete is the reason? | 12:46 |
| *** cyndis [cyndis@lakka.kapsi.fi] has quit [Ping timeout: 265 seconds] | 12:46 | |
| radiofree | aananth: yes it would appear so | 12:46 |
| pedroalvarez | aananth: indeed, seems to be the reason | 12:46 |
| radiofree | the linux kernel is big, if you're on a slow connection it might take some time | 12:46 |
| radiofree | do you have the /lc-status.html page on your trove? | 12:47 |
| radiofree | if you browse to the bottom of cgit, there's a link "View Lorry Controller Status", that might tell you what's happening | 12:47 |
| pedroalvarez | paulsher1ood: although if you wanted to edit the genivi release notes, they are not in the wiki | 12:48 |
| aananth | radiofree: I could see delta/linux-rt, delta/qt4-tools, delta/coreutils, delta/rsync in "Currently running jobs". | 12:48 |
| aananth | What is expected there? None? | 12:49 |
| radiofree | aananth: i think it's fine to see those things, is delta/linux in the run-queue? | 12:49 |
| paulsher1ood | pedroalvarez: why not roll the genivi release notes into the main release notes? | 12:50 |
| aananth | radiofree: Yes, all the 4 are in run queue as well and the run queue is a big list. | 12:51 |
| aananth | 893 more items, include the above 4. | 12:51 |
| radiofree | i think you'll need someone with more trove experience! it seems like it's still mirroring gbo, which can take some time | 12:52 |
| radiofree | pedroalvarez: ^? | 12:53 |
| aananth | does this means, I can take a week off, due to our slow network speed :-) | 12:54 |
| straycat | aananth, If you have root on the trove you can get more detailed information if you setup a tunnel to the trove on port 12765 and access localhost:12765/1.0/status-html | 12:54 |
| paulsher1ood | straycat: this makes me remember the ghost-jobs sitution we had before... ? | 12:54 |
| straycat | unless i'm mistaken liw's fix for that was merged, so that shouldn't be a problem? | 12:55 |
| pedroalvarez | ghost jobs are fixed | 12:56 |
| straycat | that little bit about the admin interface needs to be documented somewhere if it isn't already | 12:56 |
| paulsher1ood | aananth: how many jobs are *running* ? | 12:56 |
| pedroalvarez | paulsher1ood: I think he said 4 | 12:57 |
| paulsher1ood | ok, so not ghost jobs then | 12:57 |
| paulsher1ood | pedroalvarez: http://wiki.baserock.org/download/ does not mention build images, just devel and base?? | 12:58 |
| pedroalvarez | I'm modifying that right now | 12:58 |
| aananth | paulsherlood: 4 jobs are running and 890+ are in queue. | 12:59 |
| aananth | Also note that the host machine is a core2duo, very slow PC. We will upgrade it to a powerful machine soon. | 13:05 |
| *** cyndis [cyndis@lakka.kapsi.fi] has joined #baserock | 13:05 | |
| persia | Doesn't lorry require massive heaps of RAM, or is that requirement reduced for only mirroring git? | 13:07 |
| Kinnison | much less ram for git mirrors | 13:08 |
| pedroalvarez | paulsher1ood: downloads page updated | 13:08 |
| straycat | http://sprunge.us/LCZF | 13:09 |
| pedroalvarez | straycat: looks good to me | 13:10 |
| paulsher1ood | straycat: +1 | 13:11 |
| paulsher1ood | pedroalvarez: tvm | 13:11 |
| straycat | yay merged | 13:11 |
| paulsher1ood | pedroalvarez: something wrong with the link on jetsone genivi uboot | 13:12 |
| pedroalvarez | paulsher1ood: yup, just fixed it, reload the page | 13:13 |
| pedroalvarez | also the jetson images were wrong and now fixed | 13:13 |
| pedroalvarez | I think that for now we can put the baserock-flash script in download.baserock.org to update the instructions of the wiki | 13:14 |
| paulsher1ood | ok | 13:14 |
| paulsher1ood | pedroalvarez: bad news, i fear... | 13:18 |
| * pedroalvarez freezes | 13:19 | |
| paulsher1ood | i have been scripting something to work out what the latest tag is in a given chunk build.... | 13:19 |
| paulsher1ood | http://paste.baserock.org/himofevaqe.md | 13:19 |
| paulsher1ood | i can not be sure it is accurate | 13:19 |
| paulsher1ood | but it immediately makes me ask if our ofono version is in need of update | 13:20 |
| * paulsher1ood will check properly now | 13:20 | |
| paulsher1ood | i think my script is correct | 13:22 |
| pedroalvarez | seems we missed that change in the H-0.1 release | 13:24 |
| paulsher1ood | so long ago? | 13:24 |
| paulsher1ood | wow | 13:24 |
| pedroalvarez | btw... your script rules | 13:25 |
| pedroalvarez | and I'd like to use it in the future for this usecase | 13:27 |
| pedroalvarez | I've modified the wiki to support the renaming of the devel systems | 13:29 |
| petefoth | pedroalvarez: did you have any plans to update all the wiki pages that refer to ‘devel’ systems so that they refer to ‘build’ systems instead? If not, I’ll p[ut it on my list of things to do | 13:30 |
| pedroalvarez | petefoth: I've modified most of them | 13:30 |
| petefoth | pedroalvarez: just seen your latest post - ignorte me | 13:30 |
| pedroalvarez | petefoth: there are some instructions where morph builds a devel system | 13:30 |
| pedroalvarez | petefoth: tthat instructions are fine | 13:31 |
| pedroalvarez | petefoth: but not the instructions that ask you to download files from download.baserock.org | 13:31 |
| petefoth | pedroalvarez: OK. I don’t know which pages will need to be changed. I’ll leave it to you :) | 13:32 |
| pedroalvarez | radiofree: can you share with me your latest version of the baserock-flash script? | 13:32 |
| radiofree | pedroalvarez: it's on the list | 13:32 |
| radiofree | and a branch on definitions | 13:33 |
| petefoth | So are ‘build’ and ‘devel’ systems the same thing? If not , what are the differences? | 13:36 |
| petefoth | And whoich should normal users be using? | 13:36 |
| richard_maw | build is the minimal amount to build another system | 13:40 |
| richard_maw | devel contains ruby and the like, to be a more productive development environment | 13:40 |
| richard_maw | it should eventually contain lorry and the new baserock-import stuff | 13:40 |
| petefoth | So we should be encouraging users who ae gpoing to do devlopment to download the ‘devel’ systems, not ‘build’ systems? | 13:41 |
| petefoth | ‘Cos that’s not the effect of the latest wiki changes | 13:41 |
| paulsher1ood | normal users should start using build system until further notice i think | 13:42 |
| petefoth | OK, so we shpuld change stuff that says’ set up a development system’ to ‘Setup a build system’? | 13:43 |
| richard_maw | though one thing we thought about, was just releasing the build system, and providing instructions on how to upgrade it to a devel lsystem, rather than releasing devel system images | 13:43 |
| paulsher1ood | pedroalvarez: yes | 13:44 |
| petefoth | richard_maw: I’m not sure that counts as ‘simplifying the Baserock workflows’ | 13:44 |
| paulsher1ood | sorry petefoth yes | 13:44 |
| paulsher1ood | pedroalvarez: i meant petefoth :) | 13:44 |
| petefoth | paulsher1ood: OK - I’ll go away and edit | 13:45 |
| paulsher1ood | petefoth: yes, it does simplify the workflow, really | 13:45 |
| pedroalvarez | radiofree: does u-boot need to be +x to be flasheable? | 13:45 |
| paulsher1ood | petefoth: there is no *need* for a normal user to upgrade from build to devel. but doing so should help him/her to understand the capabilities of baserock | 13:46 |
| paulsher1ood | it does mean i need to do the videos again again, though :) | 13:46 |
| petefoth | The more documentation - and the better the documentation - we have, the greater the cost of maintaining it as we change stuff :( Which is not an argument for *less* (or *worse*) documentation! | 13:48 |
| dabukalam | Surely the higher the quality of documentation will lead to more people being able to use it, therefore a larger community, therefore a larger number of people willing to work on documentation? | 13:49 |
| * pedroalvarez updates the jeston flash instructions | 13:50 | |
| petefoth | dabukalam: *nobody* wants to work on documentation! I only do it ‘cos I get paid :) | 13:50 |
| DavePage | I like working on documentation. | 13:51 |
| jmacs | Rubbish, I like working on documentation too. | 13:51 |
| petefoth | pedroalvarez: I’ll do the devel-with and glossay changes | 13:51 |
| * dabukalam makes a mental note to read more about open source community building | 13:52 | |
| DavePage | But then I am heavily didactic | 13:52 |
| * paulsher1ood favours less documentation, of better quality. and software which 'does the sensible thing' | 13:52 | |
| petefoth | DavePage: jmacs: I stand corrected. I have just obesrved the tendency inopen source SW development - including Baserock - for the amount and quality of documentation to lag significantly behind tha ampount and quality of code. | 13:53 |
| * Kinnison notes that no matter how sensible software is, users inevitably require documentation and it's nearly impossible to determine which aspect of documentation any given user will need, until they need it | 13:53 | |
| jmacs | I'm not sure I am didactic, but documentation allows for more creativity than code (whether this is a good thing, I don't know) | 13:53 |
| DavePage | petefoth: That's because most contributors are people who value code over documentation. | 13:53 |
| Kinnison | jmacs: perhaps so, and if so perhaps that explains why I am poor at documentation -- 'creativity' is hard for me | 13:54 |
| petefoth | Kinnison: so you can write it all, and accept that some will never be used, or write only what people sak for (or compplain about not having) | 13:54 |
| jmacs | petefoth: I think documentation is often seen as second class to code, and since all projects overrun, the code gets done first and the documentation gets done "later" | 13:54 |
| Kinnison | petefoth: indeed, but my point is that if you're going to write any up-front, it should be all | 13:55 |
| petefoth | jmacs: +lots | 13:55 |
| dabukalam | I imagine one must have a very good understanding of codebase in order to write quality documentation. Although I hope someone will correct me. | 13:55 |
| petefoth | jmacs: and that is not only a problem in FOSS - applies in commenrcial / closed source stuff too IME | 13:55 |
| jmacs | dabukalam: Not necessarily; I think you can write good documentation if you know how a system behaves, even if you don't know how it works. | 13:56 |
| petefoth | dabukalam: depends *what* documentation. You shouldn’t need to knwo the codebase to write good *user* documeentation | 13:56 |
| pedroalvarez | I'm going to announce the release :) | 13:57 |
| petefoth | jmacs: or if you know how the system is *required* to behave. Comparing software against user documentation can be good at exposing places where software does not fulfil its requirments | 13:57 |
| petefoth | assuming to have any documentation of what the requirments are :) | 13:58 |
| petefoth | s/to/you | 13:58 |
| DavePage | Also, programmers don't make good documenters as a whole; they tend to cluster at particlar points around the Kolb Learning Circle / Honey-Mumford styles / VARK that may not reflect the users' learning preferences. | 13:59 |
| DavePage | (this is why the first version of any documentation I write is completely crap for end users, since I'm a reflective conceptualiser and most users are going to be concrete experimenters) | 14:01 |
| paulsher1ood | pedroalvarez: i made one last fix to the release notes | 14:02 |
| paulsher1ood | (now) | 14:02 |
| DavePage | petefoth: Surely the point of user stories etc. is that they essentially become documentation-driven design :) | 14:02 |
| pedroalvarez | paulsher1ood: thanks, I'll send the release mail with that fix | 14:03 |
| petefoth | DavePage: I find Use Cases (UML-style) more useful / easier to work with than User stories, because they encourage more formalisation, and less ambiguous nrrrative. But specifying requirments from a user’s perspective is a good way of doing things, and allows the development of both good spoftware *and* good user dcoumentation | 14:05 |
| jmacs | Is there a guide for writing run-once scripts for Baserock linux deployments, or is that a general systemd/linux thing? | 14:07 |
| richard_maw | as in first-boot? | 14:07 |
| jmacs | Yes. | 14:08 |
| richard_maw | we usually drop a systemd unit into /etc with `ConditionFileExists=!/path/to/some/generated/file` | 14:08 |
| pedroalvarez | Baserock 14.46 has been released! | 14:09 |
| richard_maw | \o/ | 14:09 |
| franred | :D | 14:09 |
| jmacs | richard_maw: Right, looks like I'll need to learn a little systemd | 14:09 |
| richard_maw | jmacs: you also need to add a symlink into multi-user.target.wants to get the unit to start | 14:09 |
| pedroalvarez | If you find any error, please report them to me, or feel free to fix them if it's possible. I have to leave now, but I've tested almos everything I could | 14:11 |
| franred | jmacs, I have some examples: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/openstack/etc/systemd/system?h=baserock/franred/openstack | 14:11 |
| franred | not sure are the better examples ever, also they are not reviewed yet, but they work and may give you an idea | 14:12 |
| jmacs | franred, richard_maw: Thanks | 14:12 |
| richard_maw | Alternatively, you could look at http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/distbuild/usr/lib/systemd/system/distbuild-setup.service for how distbuild sets itself up, but it's slightly different, as it unconditionally runs, but only if it's been given /etc/distbuild/distbuild.conf | 14:13 |
| paulsher1ood | http://paste.baserock.org/lokulitise.md includes shas where no tag can be found | 14:28 |
| jjardon | Hi, there is a new stable version of mesa (10.3.2->10.3.3) (majority of the patches are to fix stuff in the freedreno driver): http://paste.baserock.org/fusajenawa.sql ok to commit? | 14:29 |
| richard_maw | jjardon: I don't have enough experience in the graphics stack to know what's going on, but if radiofree gives you a +1, you can have one from me too | 14:32 |
| franred | jjardon, I imagine that graphics driver would be nice to test in both architectures before merging | 14:32 |
| radiofree | jjardon: i've already tested this on the jetson and it works fine +1 | 14:33 |
| jjardon | richard_maw: radiofree thanks, pushed! | 14:34 |
| pedroalvarez | radiofree: you have my +1 in all the patches included in the release branch | 14:35 |
| * jjardon testing a patch for gstreamer 1.4.x, in case someone was planning on working on this | 14:38 | |
| *** aananth [~caananth@74.112.167.117] has quit [Quit: Leaving] | 14:39 | |
| paulsher1ood | jjardon: i would +1 if i could bjuild and see it working | 14:40 |
| radiofree | jjardon: could you send patches for your busybox branch as well? | 14:46 |
| jjardon | radiofree: I can if you want but its a single patch to remove stuff: http://git.baserock.org/cgi-bin/cgit.cgi/delta/busybox.git/commit/?h=baserock/jjardon/build-essential&id=dc498632d6346bbd4685853c1f1470c36d430409 | 14:49 |
| radiofree | cool, so systemd now does ntpd? | 14:50 |
| richard_maw | I'm a little confused on that matter, since I saw a message recently that suggested you needed isc-ntp or chrony too, but I'm not sure. | 14:52 |
| straycat | pedroalvarez, woohooyay! | 14:54 |
| jjardon | paulsher1ood: I will publish a branch when it builds ;) | 14:56 |
| jjardon | radiofree: yeah | 14:56 |
| jjardon | and /etc/resolv.conf as well ! | 14:56 |
| jjardon | richard_maw: my system booted with the correct time without me doing anything so I guess is working ;) | 14:57 |
| radiofree | jjardon: so i see you're matching on + Name=en* for the dhcp config | 14:57 |
| radiofree | is the consistent device naming on by default now? | 14:57 |
| jjardon | radiofree: yeah | 14:58 |
| jjardon | at least in my patches, yes | 14:58 |
| richard_maw | the reason we were backing out of the deterministing interface name change was that our ifup scripts weren't able to handle them | 14:59 |
| richard_maw | this is no longer needed, so we can use deterministic names now | 14:59 |
| radiofree | ok we'll when it's built i'll test it, however i don't think that match would work on my laptop | 14:59 |
| radiofree | my ethernet device is em1 | 15:00 |
| jjardon | radiofree: uh? thats non standard, it should start by en if its a ethernet device: http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20 | 15:03 |
| dabukalam | I just modified a broken link on the wiki but forgot to add a commit message, any way I can go back and add it? | 15:05 |
| richard_maw | nope | 15:05 |
| dabukalam | Is it the end of the world? | 15:05 |
| richard_maw | nope | 15:05 |
| dabukalam | ok nvm then :) | 15:05 |
| richard_maw | it's possible to annotate commits after the fact with git notes, but you'd need push access to the backing repository to be able to do that | 15:06 |
| petefoth | Can a base system do it’s building using distbuild? (Context: I’m updating glossary.mdwn in the light of the ‘build system’ => ‘devel system change’) | 15:06 |
| radiofree | jjardon: http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming | 15:06 |
| radiofree | " /sbin/ifconfig -a must show LAN-on-Motherboard ports named em[1234] " | 15:06 |
| radiofree | so maybe fedora specific? | 15:06 |
| jjardon | maybe older versions of systemd name things differently | 15:07 |
| radiofree | systemd 208! i feel old now! | 15:07 |
| jjardon | seems there are some changes about this in v217 http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ | 15:07 |
| jjardon | radiofree: you know what Im going to say now .... | 15:08 |
| Kinnison | paulsher1ood: the baserock vagrant thing you just published, was that using the Baserock Vagrant system from definitions? | 15:09 |
| jjardon | jjardon: 217 here :P | 15:09 |
| jjardon | radiofree: 217 here :P | 15:09 |
| paulsher1ood | Kinnison: i didn't publish anything. i believe that someone just noticed a previous video published by ssam2 | 15:10 |
| Kinnison | aah right | 15:10 |
| Kinnison | cool | 15:10 |
| Kinnison | it was a lot of work to get that to go properly, so I'm glad it's documented for others to follow | 15:10 |
| * paulsher1ood hopes it still works :-) | 15:11 | |
| radiofree | hmm i think it's only 216 in fedora 21 :\ | 15:11 |
| straycat | ssam2, I'm a little confused by this m['x-build-dependencies-rubygems'].iteritems(), aren't the dependencies obtained outside of the morphology now? | 15:11 |
| petefoth | Don’t we /shouldn’t we test that it still works? | 15:12 |
| radiofree | heh https://www.happyassassin.net/2014/10/31/psa-dont-fedup-to-fedora-21-right-now/ | 15:12 |
| rjek | No journaled package installation? | 15:16 |
| jjardon | radiofree: another reason to switch: you dont need to do a massive upgrade every 6 months, you are always up-to-date | 15:17 |
| richard_maw | jjardon: let's not get into a distro holy war | 15:18 |
| rjek | Obviously, everybody should use PuppyLinux. | 15:19 |
| * rjek runs away. | 15:19 | |
| jjardon | richard_maw: I was not figthing (yet), only recommending ;) | 15:20 |
| ssam2 | straycat: hmm, yes | 15:24 |
| straycat | Okay that' | 15:24 |
| straycat | s alright then | 15:24 |
| ssam2 | petefoth: a base system doesn't have morph, so can't use distbuild | 15:24 |
| ssam2 | straycat: yeah, I guess that code does nothing | 15:25 |
| ssam2 | but I stopped using build-depends for any RubyGems so I didn't notice | 15:26 |
| straycat | I wasn't sure because the README still mentions that hand written morphs need the x-build-deps-... field, so I guess if I rewrite that bit so it says, provide a .foreign-dependencies file | 15:26 |
| petefoth | ssam2: thanks | 15:26 |
| * straycat nods | 15:26 | |
| ssam2 | straycat: yeah, dependencies are definitely specified in .foreign-dependencies now | 15:26 |
| straycat | ok cool | 15:27 |
| petefoth | my question should have been ‘Can a *build* system do it’s building using distbuild?’ | 15:27 |
| ssam2 | petefoth: oh, in that case the answer is yes | 15:27 |
| petefoth | ssam2: thanks again | 15:27 |
| ssam2 | straycat: the Package.dependencies field has the info that was in the x-build-dependencies and x-runtime-dependencies fields | 15:28 |
| ssam2 | I think Package.dependencies is simply the contents of the .foreign-dependencies file | 15:28 |
| * straycat nods | 15:28 | |
| ssam2 | i'm guessing you won't need that for Python much since, like RubyGems, PyPI doesn't store information on the build dependencies (C libaries etc.) that a package has | 15:29 |
| ssam2 | and the python dependencies aren't usually needed at build time | 15:29 |
| straycat | ssam2, setuptools has a notion of build dependencies, you can pass a list of setup_requires that will be downloaded into the source tree before the build/install steps are started. I've written stuff to make it so that anything specified in setup_requires will get translated into a build-dependency. I have noticed though that most packages don't seem to use setup_requires, and I've seen a few things that, in the README, tell you to go and a | 15:32 |
| richard_maw | straycat: you were cut off | 15:33 |
| straycat | where? | 15:33 |
| richard_maw | tell you to go and a | 15:33 |
| straycat | tell you to go and apt-get some things, I don't think there's anything we can do | 15:33 |
| straycat | about that really. | 15:33 |
| ssam2 | straycat: ok, so build-depends may be a little more significant for Python packages | 15:35 |
| * straycat nods | 15:36 | |
| petefoth | guides/docker.mdwn references baserock-current-devel-x86_64-chroot.tar.gz. Should that be changed to baserock-current-base-x86_64-chroot.tar.gz? | 15:39 |
| pedroalvarez | petefoth: thank you for taking time to update the wiki :) I really appreciate it | 15:39 |
| pedroalvarez | petefoth: yes | 15:40 |
| petefoth | s/base/build/ | 15:40 |
| paulsher1ood | urggg... http://85.199.252.101/log/64b3b934e786a979b37aebdac43ab58852129ba8--2014-11-14%2015:18:00.log | 15:42 |
| paulsher1ood | richard_maw: ^^ ? | 15:43 |
| radiofree | ERROR: Ref 9b0b5206a25c1d874d6e17952c4385838e57563e is an invalid reference for repo git://git.baserock.org/baserock/baserock/morph | 15:43 |
| richard_maw | radiofree: that commit is currently propagating to other troves from git.baserock.org | 15:44 |
| richard_maw | paulsher1ood: looking | 15:44 |
| radiofree | that's the error in the log | 15:45 |
| richard_maw | ah, I got confused by the output being out of order | 15:46 |
| petefoth | docker.mdwn currently says ‘If you just want a Baserock container in docker, try `docker pull baserock/14.29` Can I update that to 14.46, or don’t we make / publish a docker image as part of the release? | 15:53 |
| richard_maw | we haven't made any other docker container releases | 15:54 |
| richard_maw | it's a non-trivial amount of work | 15:54 |
| petefoth | richard_maw: OK I’ll leave it as 14.29? | 15:55 |
| pedroalvarez | franred ssam2. I'd like to discuss with you some points about our infrastructure. Could it be here on IRC on Monday? | 15:57 |
| franred | pedroalvarez, sure | 15:58 |
| ssam2 | pedroalvarez: sure | 15:59 |
| paulsher1ood | richard_maw: it's a trivial amount of work, tbh :) | 15:59 |
| paulsher1ood | petefoth: leave it as 14.29 | 15:59 |
| richard_maw | paulsher1ood: is it automatable? | 16:00 |
| paulsher1ood | richard_maw: possibly | 16:02 |
| paulsher1ood | sorry, on a call now | 16:02 |
| ssam2 | richard_maw: definitely | 16:07 |
| petefoth | I think that, if it’s not too much work, we *should* have a ‘baserock in a docker container’ reference system | 16:17 |
| petefoth | but I won’t change the wki to say that we have one (yet) :) | 16:17 |
| * paulsher1ood proposed this some time aga | 16:18 | |
| richard_maw | petefoth: Docker ≠ Vagrant | 16:18 |
| richard_maw | Vagrant could be a good thing to make bootstrapping into Baserock easier | 16:19 |
| petefoth | richard_maw: I don’t disagree, but docker seems to be flavour of the month ATM, and oit would be good to make BAserock easily accessible for people whpo are experimenting with it | 16:20 |
| Kinnison | Doing a docker container based on the chroot system ought to be fairly easy | 16:21 |
| petefoth | Vagrant is a bit less mainstream from what I can tell | 16:21 |
| petefoth | Kinnison: we have the instructions - it would just be a matter of automating it, and testing the result | 16:21 |
| Kinnison | cool | 16:21 |
| richard_maw | Kinnison: I'd forgotten about chroot systems. I'd like to do away with them by just calling them devel-system.{morph/def}, and having our -x86_64-generic etc. systemd runtime depend on the chroot systems | 16:22 |
| Kinnison | The chroot systems lack kernel etc. would your proposal cover that? | 16:23 |
| richard_maw | yep, your systems that you actually intend to deploy to hardware (emulated or not) also include/run-depend on the bsp stratum | 16:24 |
| * petefoth will add ‘Baserock in a docker container’ and ‘Basreock in Vagrant’ reference systems to the s tories-for-storyboard page | 16:24 | |
| petefoth | s/will add/has added/ | 16:28 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 17:06 | |
| jjardon | changed my mind: no problem to enable gallium-egl in all architectures : http://imgur.com/dIkAQPd | 17:09 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:51 | |
| straycat | hrm, we have delta/python-packages/* and delta/python-* is that intended? | 17:55 |
| radiofree | what a beautiful triangle | 17:58 |
| radiofree | jjardon: i've mostly rebuilt your systemd stuff as well | 17:59 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 18:00 | |
| jjardon | radiofree: nice! | 18:00 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 18:03 | |
| persia | vagrant is still the way cool toy for developers, but docker is getting more press because the developers are happy, and vagrant didn't work so well for devops. | 18:07 |
| radiofree | jjardon: won't be able to test it tonight though! still most of the graphics stuff left to build (i'm testing with a genivi imge) | 18:09 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 18:10 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:28 | |
| *** rdale [~quassel@9.Red-83-45-185.dynamicIP.rima-tde.net] has quit [Ping timeout: 255 seconds] | 18:37 | |
| *** rdale [~quassel@9.Red-83-45-185.dynamicIP.rima-tde.net] has joined #baserock | 18:50 | |
| *** vmeson [~quassel@128.224.252.2] has quit [Read error: Connection reset by peer] | 19:02 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving.] | 19:10 | |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 19:13 | |
| *** ssam2 [~ssam2@cpc7-asht7-2-0-cust170.10-1.cable.virginm.net] has quit [Quit: Leaving] | 19:25 | |
| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has joined #baserock | 19:28 | |
| *** ssam2 [~ssam2@cpc7-asht7-2-0-cust170.10-1.cable.virginm.net] has joined #baserock | 19:32 | |
| Mode #baserock +v ssam2 by ChanServ | 19:32 | |
| *** ssam2 [~ssam2@cpc7-asht7-2-0-cust170.10-1.cable.virginm.net] has quit [Quit: Leaving] | 19:38 | |
| *** rdale [~quassel@9.Red-83-45-185.dynamicIP.rima-tde.net] has quit [Ping timeout: 244 seconds] | 23:11 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!