IRC logs for #baserock for Wednesday, 2014-12-17

*** sambishop [] has quit [Ping timeout: 258 seconds]04:54
*** sambishop [] has joined #baserock04:54
*** mike [] has joined #baserock07:43
mike is now known as Guest5924507:44
*** mariaderidder [] has joined #baserock08:57
*** bashrc [] has joined #baserock09:00
* pedroalvarez reads about libisofs, python-libisofs, etc09:36
*** petefoth [] has quit []09:38
*** petefoth [] has joined #baserock09:38
* persia wonders whether most baserock targets have optical drives09:38
* Kinnison imagines he's considering faking up an ISO for IPMI09:39
pedroalvarezno, I was just researching after reading the "Deploying to ISO" email09:40
petefothIt's easy to add one to a VirtualBox VM (as described in my response to Gavin's email). I imagine something similar would be feasible in other virtualisation systems, but I have no idea how :)09:43
persiaThe issue with ISOs is that either one has to deal with read-only root, or one has to perform an "install".  We know how to do the latter, but should avoid it for optimisation purposes most of the time (because it requires an additional data duplication operation)09:44
* persia goes to read mail, expecting to find lots of things for which a reply may be useful09:45
*** zoli_ [] has joined #baserock09:49
*** zoli_ [] has quit [Changing host]09:49
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock09:49
mauricemoss_I started creating a new system for our acer chromebook (it should run gnome in the end). I was wondering, is it sensible to create a cross bootstrap system or better to build everything natively on the chromebook?09:50
persiaDepends on the architecture of the chromebook.09:50
mauricemoss_tegra k1, same as in the jetson09:50
persiaIf it is a supported architecture, then I'd recommend either a native build or distbuild.09:50
persiaIf it is unsupported, you need cross-bootstrap to get a system in a shape where you can complete a native build or distbuild.09:51
persiaIf it is the same as a jetson, it should be good for building.09:51
mauricemoss_ok :)09:51
*** ssam2 [] has joined #baserock09:53
Mode #baserock +v ssam2 by ChanServ09:53
persiaI seem to remember jjardon doing something towards a GNOME/Weston system, which might be a sensible point of collaboration (if only because it increases the chances that things are cached on, reducing your build time)09:53
pedroalvarezYeah, I also suggest using a jetson to as devboard and the chromebook as target, but I don't know the croomebook so maybe is easy to use as development environment and as a target at the same time09:53
persiaTwo makes life easier, but with self-upgrade, one can swap in and out of a development system as well.09:54
mauricemoss_persia, I was speaking to jjardon yesterday about gnome. some fixes are still to be commited.09:57
persiaExcellent, then you probably know more than I about the current state of affairs.09:58
mauricemoss_I'll try self update first and see how I get on10:00
SotKregarding faster feedback from Zuul, we currently have a single "pipeline" which runs the build and test when a new change is pushed to Gerrit. Perhaps it is worth going with the Verified label being +1 builds, +2 tested, and having two pipelines defined in our config, one which runs the build then reports, one which tests things if there is a successful build report?10:04
*** CTtpollard [] has quit [Ping timeout: 272 seconds]10:11
persiaIt is a balance-of-resources question.  If we expect scarce resources, we should encourage developers to discover if things work locally (and give them tools to do so).  If we expect plentiful resources, we should encourage developers to publish often, and give them fast feedback when things are not working.10:11
persiaA potential middle ground would be to find a way to notify the submitter that the test had started, and pass them some means to look at the log-in-progress.10:12
*** zoli__ [] has joined #baserock10:12
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer]10:13
persiaThat said, we ought fail early and visibly if we know we are failing, so that the -1 can be posted soonest.10:13
persiaBut until there is a -1 or a +1, there is no particularly useful information available, because we have not yet found a test that failed, but we cannot yet assert that all tests pass.10:14
SotKthe current setup exposes the logs-in-progress at http://ZUUL_IP/logs, but our Mason is not exposed to the internet10:14
persia(and I think we'd want to discourage developers from watching the log, when they could be doing something useful)10:14
*** Krin [] has joined #baserock10:15
*** CTtpollard [] has joined #baserock10:15
*** CTtpollard [] has quit [Client Quit]10:15
*** CTtpollard [] has joined #baserock10:16
jjardonpersia: a reference weston system already exist and its being builded for x86 and arm, so all the components are available in the cache11:52
persiamauricemoss_: ^^11:52
jjardonfor GNOME xwayland is needed (will send patches today or tomorrow) and tzdata, that seems to be inside eglibc but now its a separate package11:53
jjardonProbably more things more thats what its in my list rigth now11:53
Krinhas anyone got time to take a look at what I'm hoping is the final patch for the zookeeper work?13:16
*** ssam2 [] has quit [Ping timeout: 245 seconds]13:17
*** ssam2 [] has joined #baserock13:31
Mode #baserock +v ssam2 by ChanServ13:31
*** tpollard_ [] has joined #baserock14:09
*** CTtpollard [] has quit [Ping timeout: 250 seconds]14:11
*** tpollard_ [] has quit [Client Quit]14:12
*** CTtpollard [] has joined #baserock14:12
mauricemoss_system-version-manager throws an error: how can I fix this?14:14
persiaCould you paste that somewhere public, like
pedroalvarezmauricemoss_: ^^14:29
radiofreemauricemoss_: since you're using stock u-boot i'm assuming this isn't a btrfs partition14:29
radiofreemauricemoss_: i changed system-version-manager to support non btrfs boot paritions14:30
radiofreehowever you'll need a recent version of baserock14:30
radiofreeand your patition structure will have to be p1 = ext2/3/4, p2=btrfs14:30
radiofreeput the baserock image in p2, and copy over extlinux.conf into p1 (e.g mmcblk0p1) /extlinux/extlinux.conf14:31
mauricemoss_radiofree, ok, deploying works only with btrfs?14:31
persiaUpgrades work only with btrfs today14:31
persiaAnd system-version-manager only matters when one has upgraded a system (otherwise it is just factory)14:31
radiofreemauricemoss_: if you can make sense of
persiaThere was some talk of supporting ZFS, but I haven't seen patches for that yet.14:32
mauricemoss_my idea was to upgrade the rootfs to different partitions to have a fall back14:32
radiofreepersia: i don't think u-boot supports zfs either14:32
mauricemoss_I'm not using uboot atm14:32
mauricemoss_booting into a chromiumos kernel partition14:32
radiofreeno idea sorry, but baserock needs btrfs to upgrade14:32
persiaradiofree: From I thought the problem was only with system-version-manager: how is u-boot related?14:33
radiofreeif you're using master, you can now have a separate boot partition though14:33
radiofreepersia: because he's almost certainly not using a btrfs partition?14:33
radiofreei might be wrong about that mauricemoss_?14:33
persiaAh.  I see.14:33
* persia leaves this to folk who understand more14:33
mauricemoss_I used the rootfs you created for the chroot/crouton demo14:34
radiofreethat's just a tarball, what is the partition you extracted it to formated as?14:34
mauricemoss_it's ext4, I'll change it to btrfs14:34
mauricemoss_and then swapping between two btrfs partitions after deploying14:35
radiofreewell you can't just extract the tarball onto a btrfs partition14:35
radiofreeyou need a rawdisk image and you need to dd it14:35
radiofreealso you need to check your bootloader can read from a btrfs partition14:36
*** franred [] has quit [Ping timeout: 258 seconds]14:36
mauricemoss_radiofree, ok will check14:36
pedroalvarezso that's why is not working then14:37
pedroalvarezmaybe we should improve the code to catch an exception there14:37
radiofreethat's the expected layout of a boot partition14:38
radiofreeyou can copy all of those files from a rawdisk image14:38
radiofreeso for the jetson (using u-boot) i have mmcblk0p1 as an ext4 partition with that layout14:38
radiofreeand mmcblk0p2 as a btrfs partition with the baserock image14:38
mauricemoss_can I just deplot a rootfs to a btrfs partiton and change the kernel parameters from chromiumos? it's needs to be signed with a google tool anyway14:39
radiofreei'm going to go with no14:39
radiofreebut someone else is probably more qualified to answer that14:39
radiofreethe btrfs partition needs to be a specific format (subvolumes created etc...)14:40
*** Guest59245 [] has quit [Ping timeout: 244 seconds]14:40
*** ssam2 [] has quit [Ping timeout: 244 seconds]14:41
*** pdar [] has quit [Ping timeout: 244 seconds]14:41
*** pdar [] has joined #baserock14:41
*** ssam2 [] has joined #baserock14:41
Mode #baserock +v ssam2 by ChanServ14:41
*** Guest59245 [] has joined #baserock14:41
radiofreehow can i btrfsck my baserock partition?14:50
radiofreeafter running "resize max" on it the partition will eventually end up being remounted read only14:51
radiofreemaybe after a day, maybe after a few hours...14:51
radiofreei only notice it because systemd-journald spams the kernel log about how it can't write14:51
*** franred [] has joined #baserock14:51
*** mdunford [] has quit [Ping timeout: 250 seconds]14:57
robtaylorradiofree: sounds like its screwed, im afriad15:03
robtaylorsomeone really needs to make a systmd timer unit that does a defrag15:06
robtaylor(or at least, the deploy scripts should do a defrag and a balance if they don't already)15:07
ssam2that'd be great (except no doubt it'd run whenever I was trying to do something else and use up all the IO)15:07
robtaylorssam2: thats kinda the reason tht btrfs doesnt do it automatically15:09
robtaylor(thogh it does run as a low prio background thread)15:09
robtaylorssam2: a timer unit for 5am should do the job for most folk ;)15:09
robtaylorthough a balance and defrag after deploy is really a must-have, i'd say15:10
radiofreeapparently i can't run it at boot?15:11
*** mdunford [] has joined #baserock15:11
radiofreei can mount the emmc using u-boot and run it from my laptop i suppose15:11
robtayloryou can set it to auto defrag as a mount option, i think15:11
radiofreei never see this issue until i use btrfs filesystem resize max / 15:11
ssam2robtaylor: oh! that'd be good enough for me, probably15:11
robtaylorradiofree: it sounds like your file system is screwed i'm afraid - i've had that before15:12
robtaylorssam2: yeah!15:12
radiofreerebooting fixes it :\15:12
robtaylorradiofree: oh, thats lucky15:12
radiofreeit'll happen again15:12
robtaylorradiofree: back it up now if you need it15:12
radiofreethere's nothing critical on it, this is a jetson15:12
robtaylorradiofree: and then either blow it away or defrag and rebalance15:12
robtaylorbut ime rebalancing at this point just goes horribly wrong...15:12
radiofreeis filesystem resize a bit iffy then?15:12
robtaylorit  *shouldn't* be, tbh15:13
robtaylorbut the remount read-only is what btrfs does when things are wrong. you'll probably see some scary messages in dmesg15:13
ssam2(about autodefreg: promises that 'Once the developers make sure it doesn't defrag files over and over again, they'll move this toward the default.')15:13
robtaylorits' said that for quite a long while :(15:14
*** franred [] has quit [Ping timeout: 265 seconds]15:14
radiofreebefore it happens i get15:15
radiofree[385101.169536] mmcblk0: timed out sending r/w cmd command, card status 0x90015:15
radiofreethen a couple of [385101.176741] blk_update_request: I/O error, dev mmcblk0, sector 763840015:15
radiofreethen finally a [385101.231274] BTRFS: bdev /dev/mmcblk0p2 errs: wr 4, rd 0, flush 0, corrupt 0, gen 015:15
robtaylorradiofree: oh.15:16
radiofreewe're running btrfs on the jetsons for the mason right15:16
robtaylorradiofree: thats your mmc getting screwed then15:16
radiofreebut we *didn't* use resize max there15:16
radiofreerobtaylor: i see this on two boards, both of which i ran resize max on15:17
robtaylorradiofree: sounds like a bad interaction between resize max and the (e)mmc firmware15:17
radiofreeactually, i only did resize 8G on this other one and that has been fine15:18
robtaylorsounds like the emmc fireware things its out of space, or is having problems finding good free underlying blocks15:18
radiofreemaybe the emmc is buggered on this other board then15:18
radiofreeok, i'll just reflash it and run it for a bit without resizing15:18
robtayloryeah, that might do the job15:19
radiofreeas i said, it could be an hour, a day, a week.. before i see that message15:19
persiaUnless the FTL supports btrfs, it is probably best not to use more than 80% of the capacity.15:19
robtaylorpersia: that sounds like good advice15:19
radiofree80% it is then15:19
*** franred [] has joined #baserock15:19
persiaNote that btrfs has explicit support for some FTLs, in which case it doesn't matter, but that ought be considered the rare case.15:19
persiaAnd inexpensive SD cards or eMMC tends to have FAT-optimised FTLs.15:20
*** petefoth [] has quit [Quit: petefoth]15:28
* paulsher1ood wonders if it's too late to propose 'brie' as a name for firehose16:09
perrylit'd save time on typing the name!16:10
persiaNot at all: anything other than "firehose" would be lovely.  Why "brie"?16:10
Kinnisonpaulsher1ood: it's a tad cheesy16:10
paulsher1oodit's already called that...
paulsher1oodbaserock robotic integration engineer :)16:11
* paulsher1ood would be happy to send a global replace patch series16:11
paulsher1oods/ series//16:11
persiaSeems namespace-safe16:12
*** fay_ [] has quit [Read error: Connection reset by peer]16:12
perryli like it; it's short, memorable, doesn't clash with nomenclature16:12
paulsher1ooddo i take that as 2 x +1 ? :)16:12
pedroalvarezI'd like to hear that word first16:13
* Kinnison dislikes it but not enough to -1 it, so -0 from me16:13
paulsher1ood'bree' as in the cheese, pedroalvarez 16:13
ssam2i don't like it but won't oppose it16:13
persiapaulsher1ood: If there was a posted patch series, with an explanation of the name change, I'd +1 it.16:13
paulsher1oodok. how do we get perryl's latest patchset merged first?16:13
persiaKinnison: ssam2: Do either of you have anything else?  Or do you expect we'll get a new name in the near future otherwise?16:14
* paulsher1ood doesn't want to cause others to rebase16:14
ssam2I don't have any better ideas :)16:14
Kinnisonpersia: I like 'firehose' as a name16:14
Kinnisonotherwise I'd not have picked it16:14
ssam2i think Firehose is a good name too16:14
* paulsher1ood is ok with firehose16:14
persiaI've commented on why I think that is a poor name, and nobody wrote anything in opposition on the mailing list.16:14
pedroalvarezI think that brie is not better than firehose16:14
paulsher1oodenough bikeshedding. persia - are you -1 on firehose?16:15
paulsher1oodor -0?16:15
persiapaulsher1ood: -1.16:15
pedroalvarezbut firehose is already there! :)16:15
mwilliams_ctI don't think it's a bad name, but I'd be concerned that it doesn't give any more information than the name Firehose does about what the purpose is. unless you know the abreviation already16:15
persiapedroalvarez: Yes, but over several statements from me disagreeing.  I still don't like it, and won't be made to like it, but I defer to consensus objection.16:16
Kinnisonpersia: I, as a rule, do not get involved in any positive or negative way in bikeshedding discussions because I find I get riled up too easily16:16
ssam2about merging lauren's branch: I'm kind of deep in Node.js at the moment, I don't really want to drop it to review firehose today unless it's deemed more urgent16:16
Kinnisonpersia: as such, I declined to comment either way on your mail16:16
pedroalvarezI agree with mwilliams_ct. I like baserock robot integrator engineer, though16:16
paulsher1oodssam2: no, not urgent16:16
persiaKinnison: I generally follow that process, but I believe it actually important in this case, rather than being a bikeshed-color class of issue.16:16
ssam2Node.js does not make me happy, if anyone was wondering. It's like someone ported all the bad bits of GLib async  programming to Javascript16:17
Kinnisonpersia: Also, IIRC the crux of your mail was that 'firehose' was a term already understood to mean something vastly different in the community16:17
Kinnisonpersia: and since I know that my "understanding" of terms is usually pretty unique, I declined to be involved at that level too16:17
persiaAnd that is my source of dislike for the word.16:17
Kinnisonsince I personally chose 'firehose' because of what I understood it to mean in the community16:18
KinnisonBut then gain, I *like* the morphology/chunk/stratum terminology too, so I'm known-dodgy wrt. nomenclature16:18
persiaI usually see it applied to bug streams and request streams, not patch streams.16:18
jmacsTo me, 'firehose' suggests an unfiltered source, and a huge volume of information16:18
Kinnisonjmacs: and the 'firehose' tool works with that16:19
persiaI'm also a fan of the stone-related terminology, which is why I suggested alternate stone-related names for this tool.16:19
Kinnisonjmacs: so to me it fits :-)16:19
persiaExcept it filters.16:19
persiaOr it ought filter.16:19
KinnisonBut now I'm being drawn into a discussion I dislike, so I'mma stop now and go to do something else16:19
pedroalvarezwasnt the stone-related terminology going to disappear?16:20
paulsher1oodfirehose is a catchy name (which is in part why it has stuck), but does not really describe what this does imo16:20
Kinnisonpaulsher1ood: if the open source world used names which described what things did, turbo-hipster would never exist16:20
persianor, because it is a word with meaning, is it available to be a noun describing a project16:21
pedroalvarezKinnison: or maybe it would be doing something really different16:21
* persia also prefers non-descriptive names16:21
Kinnisonpedroalvarez: accelerating hipsters to high velocities?  we can but hope16:21
* perryl ponders dropping stone-related naming schemes in favour of cheese-related16:23
* pedroalvarez cures cheddar-cheese-x86_64 to openstack16:24
Kinnisonpedroalvarez: no, you "lay down" cheese16:25
* Kinnison likes the idea of systems being called 'truckles' though16:25
pedroalvarezKinnison: right, thanks!16:25
radiofreehow about "Mitzy"16:25
Kinnisonthat's a good cat name, so I approve16:25
jmacsThat sounds like drugs.16:25
pedroalvarezI was pondering "integra" for firehose to have a descriptive name, but there are already some projects called like that16:26
radiofreeis there any particular reason rsync isn't on a genivi image?16:27
*** cosm [] has quit [Ping timeout: 255 seconds]16:27
pedroalvarezradiofree: the reason is that is not mandatory16:28
paulsher1oodradiofree: i think genivi images are supposed to be more like a target than a devel environment. shouldn't leave tools lying around on a target?16:28
pedroalvarezrsync is in tools.morph16:28
radiofreei see, but you can't upgrade a genivi image then?16:28
radiofreei have to keep switching back to factory16:28
pedroalvarezthat is indeed an issue if we want it to be upgradable16:29
* persia likes "truckles", as it nicely avoids "systems", "packages", and other overloaded terms16:29
perryltruckles is close to truffles. chocolate related naming schemes!16:30
persiatruffles are not chocolate: they are tasty mold16:30
radiofreepedroalvarez: would moving rsync to foundation make sense?16:30
persiaAnd mould-related nomenclature isn't as pleasing16:30
radiofreeit's not so much a "tool" when the upgrade process depends on it being there16:31
Kinnisonpersia: that old chestnut [mushroom]16:31
pedroalvarezradiofree: I agree, I was actually thinking about that16:31
paulsher1oodgiven i made the same argument about adding foundation to zookeeper systems, i have to agree :)16:33
paulsher1oodbut can i show my ignorance, and ask... is rsync needed on both sides? if i'm upgrading a target, do i need rsync on the target, or just the host?16:34
pedroalvarezerm.. re foundation in zookeeper systems. Now I think that is needed, and not only for upgrades16:35
paulsher1ood(i appreciate that if i'm doing a self-upgrade, they're both the same)16:35
pedroalvarezrsync is needed on both I believe16:35
persiapaulsher1ood: Depends how we rsync, but it is better if it is present on both sides.16:35
* paulsher1ood thinks Krin claimed/established foundation wasn't needed16:35
ssam2rsync > 3.0.0 is GPLv3 so can't be in GENIVI baselines16:35
pedroalvarezssam2: good catch16:36
pedroalvarezwe can maybe improve the upgrade process to try rsync and if not, scp?16:37
pedroalvarezor another alternative?16:37
KrinI made no such claim. I don't know the function of foundation, so I'm going of the judgement of my better informed peers there, and added it back in with the latest of the patch series :)16:37
pedroalvarezKrin: without foundation, no systemd. So I believe that is needed16:38
Krinahh, then yes it is indeed needed, as part of zookeeper uses systemd :)16:39
Krinwell, part of the server implementation of zookeeper anyway16:39
persiarsync can work with no rsync on the remote: it is just slower.16:39
radiofreecan we use tbdiff?16:39
radiofreei have no idea what tbdiff really is btw, but i seem to remember it upgrading something16:39
radiofreeor i'm thinking of trebuchet?16:40
*** cosm [] has joined #baserock16:40
ssam2tbdiff creates and applies binary diffs16:41
ssam2trebuchet is a fuzzy name only right now I think16:41
perrylpaulsher1ood: firehose notes are on w.b.o16:42
paulsher1oodooh, cool... 16:42
paulsher1oodbetter come up with a better name *quick* or persia will be forever disgruntled16:43
franredI need to add psycopg2 which is a python adapter for postgresql - should I add to databases or add it to openstack which is the one which is going to use it?16:46
persiaI might just submit the patch to name it "Lugger" or "Hod" myself.16:47
franred"databases.morph" and "openstack-services.morph"16:47
paulsher1oodopenstack, franred i think? unless openstack systems already use dataases.morph?16:47
franredpaulsher1ood, openstack system needs to use databases.morph16:47
paulsher1oodthen databases please16:48
pedroalvarezfranred: IMO, you shouldn't end up using databases.morph. Maybe we should create a postgres.morph stratum with postgres, dependencies, and utilities like that python library16:48
paulsher1ood+1 for that16:48
CTtpollardI'd +1 a separate postgres morph 16:49
persiaTHat sounds like a better plan then16:49
paulsher1oodwhat did we decide to call foo-and-the-things-usually-needed-with-foo?16:50
* pedroalvarez is not sure16:50
persiaA stratum?16:50
paulsher1oodpersia: i meant naming standard. pedroalvarez may be right. or foo-tools ?16:51
persiaI don't remember16:52
paulsher1oodlooks like we have more *-utils than *-tools. so let's go for that?16:53
*** Guest59245 [] has quit [Quit: Leaving]16:53
pedroalvarezyeah, postgres-utils sounds ok to me16:54
*** ssam2 [] has quit [Remote host closed the connection]17:14
*** Krin [] has quit [Remote host closed the connection]17:36
*** mariaderidder [] has quit [Quit: Ex-Chat]17:55
*** bashrc [] has quit [Quit: Lost terminal]18:01
*** franred [] has quit [Quit: Leaving]18:13
*** zoli__ [] has quit [Remote host closed the connection]18:22
*** zoli_ [] has joined #baserock18:23
*** zoli_ [] has quit [Changing host]18:23
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock18:23
*** genii [~quassel@ubuntu/member/genii] has joined #baserock18:54
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]18:54
*** zoli_ [] has joined #baserock18:55
*** zoli_ [] has quit [Changing host]18:55
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock18:55
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]18:56
*** zoli_ [] has joined #baserock19:03
*** zoli_ [] has quit [Changing host]19:03
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock19:03
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]19:29
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock19:33
*** rdale_ [] has joined #baserock20:01
*** rdale [] has quit [Read error: Connection reset by peer]20:02
*** rdale [] has joined #baserock20:33
*** rdale_ [] has quit [Ping timeout: 240 seconds]20:36
*** rdale_ [] has joined #baserock20:44
*** rdale [] has quit [Ping timeout: 258 seconds]20:47
*** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection]21:58
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]22:22
*** zoli_ [] has joined #baserock23:04
*** zoli_ [] has quit [Changing host]23:04
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock23:04
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]23:04

Generated by 2.15.3 by Marius Gedminas - find it at!