IRC logs for #baserock for Monday, 2014-11-24

persiamwilliams_ct: In reference to the ZFS discussion recently: in another channel it was mentioned that it is non-trivial to *boot* a linux system using only ZFS, as until it can read modules, the kernel can't read ZFS, and it needs to get the modules from *somewhere*.  Putting the modules in an initramfs initially seems to make sense, but then the *bootloader* would need ZFS support, which means no uboot and no grub (a patched lilo could work).  Using 00:44
persiaan alternate FS for /boot seems the common solution.00:44
*** duderdice [~chatzilla@c-73-184-236-199.hsd1.ga.comcast.net] has quit []02:59
*** duderdice [~chatzilla@c-73-184-236-199.hsd1.ga.comcast.net] has joined #baserock03:46
*** duderdice [~chatzilla@c-73-184-236-199.hsd1.ga.comcast.net] has quit [Quit: ChatZilla 0.9.91 [Firefox 34.0/20141117202603]]04:01
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock07:51
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:05
paulsher1oodstraycat: thanks. i scrapped the volume in the end08:27
*** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:40
mike is now known as Guest6207408:40
*** locallycompact [~lc@110.154.199.146.dyn.plus.net] has joined #baserock08:49
*** rdale [~quassel@140.Red-79-144-56.dynamicIP.rima-tde.net] has joined #baserock08:53
*** locallycompact [~lc@110.154.199.146.dyn.plus.net] has quit [Ping timeout: 272 seconds]08:56
*** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:06
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:07
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:08
mwilliams_ctpersia: thanks for the info! I guess that's why DKMS had been suggested previously09:08
persiaDKMS doesn't solve the problem.  DKMS will recompile local modules when a kernel package is updated.  The Baserock model means this is never necessary.09:11
persia(because the kernel would never be updated as a package, or independent of a system build, which system build would have already included recompilation of modules)09:12
mwilliams_ctindeed, it's not the right solution for Baserock09:12
radiofreealternate fs for /boot is what i'm doing for the jetson, the patches to upgrade systems like that are already in system-version-manager09:13
persiaCool!09:13
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:14
radiofreeis using zfs going to be part of a big "how we update baserock systems" update?09:14
persiaThe impression I had from traffic so far was that ZFS was considered as a potential alternative to btrfs.  I'm not sure it is intended as replacement, precisely.09:16
bashrc_probably mainly because of licensing09:16
persiaI thought it was because of stability09:17
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock09:23
*** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds]09:24
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:27
*** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:50
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:02
Mode #baserock +v ssam2 by ChanServ10:02
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:03
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer]10:20
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock10:21
radiofreessam2: i don't think cryptopp is standard then :\ http://svn.code.sf.net/p/cryptopp/code/trunk/10:23
franredradiofree, http://svn.code.sf.net/p/cryptopp/code/  <-- it has truck, branches and tags... looks like standard10:24
franredtrunk*10:25
richard_mawnot exactly, since all the stuff you actually want is in the c5 subdirectory10:25
franredummmm, true, but don't we lorry the repo as standard and then we add the morph file to deal with the oddity of non-standard repos?10:26
richard_mawyou can probably use `"layout": {"trunk": "trunk/c5", "branches": "branches/c5/*", "tags": "tags/setuptools/*"}`10:26
richard_mawwait, those tags are bogus10:27
richard_mawit's "tags/*/c5" and "branches/*/c5"10:27
radiofreeok, i'll  change it to that!10:28
radiofreeis "url": "svn://svn.code.sf.net/p/cryptopp/code/trunk"  correct?10:29
franredradiofree, I think you have to remove trunk to lorry branches and tags10:30
franredI would use, "url": "svn://svn.code.sf.net/p/cryptopp/code"10:31
richard_mawfranred is correct, you don't want /trunk at the end10:31
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds]10:32
paulsher1oodhmmm... qt4 doesn't build from master, i think? http://paste.baserock.org/uyusoxemug.vhdl10:52
rdalei haven't been looking at that, only qt510:54
paulsher1oodrdale: would you mind taking a look?10:54
*** cosm [~Unknown@host-78-150-56-250.as13285.net] has quit [Ping timeout: 250 seconds]10:55
radiofreeit's gstreamer10:55
radiofreeupdate the sha for gstreamer-0.10 to the latest HEAD10:55
rdaleyes, sure. but the thing that is stopping me doing anything with baserock at the moment is that xserver doesn't build for me - i dont know why10:55
radiofreepaulsher1ood: ^10:55
paulsher1oodradiofree: i'm wondering how/when it broke?10:56
radiofreeerm... around June10:56
rdaleyes, nothing seems to have changed with the xserver for a while10:56
radiofreepaulsher1ood: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-June/006631.html10:57
paulsher1oodi get same error building qt5-devel-system10:57
radiofreeagain, gstreamer10:57
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:57
Mode #baserock +v ssam2 by ChanServ10:57
rdalei've split off the qtmultimedia module into it's own stratum with my current patch10:57
pedroalvarezah, I see. this is not the same gstreamer that is being built on genive10:57
paulsher1oodradiofree: so is it that you provided patches and we didn't merge them?10:57
rdale^it's^its10:58
radiofreepaulsher1ood: they are merged now, but the ref in master never got updated i think10:59
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: petefoth]11:00
radiofreeonly merged a couple of weeks ago though11:00
radiofreethere is no system with qt done as part of a release, so i suppose it's easy to miss11:00
paulsher1oodyup11:00
rdalei wasn't thinking people were still using qt4 either11:00
paulsher1oodso the fix is to update ref for gstreamer to the one in your patch?11:01
radiofreepaulsher1ood: yep11:01
radiofreeupdate http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/multimedia-gstreamer-0.10.morph11:01
radiofreeupdate "gstreamer" in that to use sha 1bb95000....11:01
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock11:04
paulsher1oodradiofree: your patch had sha 60185a6 ?11:15
radiofreehttp://git.baserock.org/cgi-bin/cgit.cgi/delta/gstreamer.git/commit/?h=baserock/morph/0.10&id=1bb950008f4656f6a6153fa88a8ebb5a39fbe84f11:16
paulsher1oodoh, after merge11:16
jjardon  paulsher1ood simply build wherever is in the current upstream 0.10 branch will fix the problem11:16
radiofreejjardon: well, we need http://git.baserock.org/cgi-bin/cgit.cgi/delta/gstreamer.git/commit/?h=baserock/morph/0.10&id=c7e4a97d26396882960fd399b1a5e298e40d2a3511:17
paulsher1oodjjardon: yup! :-)11:17
radiofreeso ignore jjardon11:17
radiofreesimply build whatever is in the current baserock/morph/0.10 branch ;)11:17
paulsher1oodradiofree: he's talking about a different world :-)11:17
radiofreebuilding from 0.10 master will also work, you'll just end up cloning the submodule from freedesktop rather than gbo11:18
jjardonrdale: whats the error? I think you have to add  --disable-glx to the xserver configure parameters11:18
radiofreeit's a pity morph can't automatically adjust the submodules11:18
jjardonpaulsher1ood: yeah, you need the submodule thing11:20
radiofreepaulsher1ood: btw my wip on the install script is https://github.com/jamespthomas/baserock-jetson-install/blob/master/baserock-install.sh11:23
* paulsher1ood needs to find time to test it :-)11:25
radiofreewell the "# do the tegra-uboot-install stuff here..." needs to be done manually11:25
radiofreeatm...11:25
radiofreealso it'll partition the jetson, and create /boot, however you need to manually dd the baserock image (see dd-script.sh)11:26
radiofreeWARNING: that script is hardcoded to /dev/sdb211:26
radiofreei'll finish it off tomorrow though11:26
radiofreepedroalvarez: what's the cache server url for the arm mason?11:29
pedroalvarezradiofree: http://cache.baserock.org:8080/ :)11:29
pedroalvarezthe same for all of them11:30
paulsher1oodpedroalvarez: that works already? wow!11:30
paulsher1oodhow does it work?11:30
radiofree[22:25:51] <jjardon> "Fetching to local cache" <- magic words :) :D11:30
pedroalvarezpaulsher1ood: are you asking for implementation details, or perfomance?11:31
paulsher1oodimplementation details, out of interest11:31
pedroalvarezright11:31
*** cosm [~Unknown@cspc154.cs.man.ac.uk] has joined #baserock11:33
pedroalvarezcache.baserock.org is an artifact server (also a trove, but that doesn't matter here). Mason  is just an script that calls `morph distbuild` on every change, these Masons can be configured to use a local distbuild network (running in the same system as mason), or a different one (like we do now for arm). These distbuild networks are using cache.baserock.org as their cache server, so whenever they build something, they populate its cache.11:35
rdalejjardon: the xserver error i'm getting: http://paste.baserock.org/ozovuxenuy.vhdl11:35
jjardonrdale: never seen that error before, Im building with a old chroot here though11:36
rdalejjardon: i'm building in the same vm i've been using for a while and it used to work, but i can't see what has changed to break it11:39
jjardonrdale: seems you are hitting https://www.libreoffice.org/bugzilla/show_bug.cgi?id=8299011:39
rdaleyes, it's a known bug that was fixed a while ago11:39
jjardon(related with the recent upgrade to glibc 2.2011:39
jjardonrdale: Im working in a branch to upgrade to latest xserver that will probably fix the problem11:40
rdalehave we upgraded to glibc 2.20 in baserock then?11:41
pedroalvarezrdale: yup!11:41
rdaleah ha11:42
jjardonpedroalvarez: is it Alvarez or Álvarez?11:47
pedroalvarezjjardon: hahah I'm not using the Á since I moved to UK11:48
rjekWhy not? :)11:48
jjardonpedroalvarez: oki!11:49
pedroalvarezI've had many problems just because I have 2 surnames instead of one. so I can imagine how many problems I'll hit just because of the tilde11:49
paulsher1oodred at http://mason-armv7lhf.baserock.org11:57
radiofreethe latest merge hasn't propagated yet?12:00
pedroalvarezpaulsher1ood: this is normal. The arm distbuild network is configured to use the baserock-clone trove, so g.b.o doesn't end up with build branches12:00
pedroalvarezas I said on friday, we can think about it. I think there is not harm on using g.b.o. for this distbuild network, but I'd like to discuss it12:01
mwilliams_cthi folks! I've been going through the build deploy cycle on w.b.o and have rebooted to an upgraded system. strangely, it doesnt seem to have any network access. I'm not even sure what keywords to use to search for help on this, any pointers?12:02
radiofreemwilliams_ct: what version of systemd?12:02
radiofreesystemctl --version12:03
mwilliams_ctradiofree: systemd 21712:03
paulsher1oodmwilliams_ct: ipaddr ?12:03
radiofreemwilliams_ct: interesting! what does ifconfig -a give you?12:03
radiofreelooking for something called either en* or eth*12:03
mwilliams_ctslight issue that I can't copy and paste because it's on an openstack instance12:04
radiofreeyou can run udhcpc for now, but this should be automatic12:04
radiofreemwilliams_ct: is there a device called eth*?12:04
paulsher1oodmwilliams_ct: uggh.. and you can't ssh in, obviously :-)12:04
paulsher1oodmwilliams_ct: screenshot?12:04
mwilliams_ctradiofree: yes, with no ip address12:05
radiofreemwilliams_ct: ok, you need to edit /etc/systemd/network/10-dhcp.network12:05
radiofreechange en* to eth*, which will use dhcp, but considering you're using openstack i don't think that's what you want12:05
paulsher1oodpedroalvarez: oh, so the red is just delay, til mirroring catches up?12:05
pedroalvarezpaulsher1ood: yes12:05
pedroalvarezand I'd like that this didn't happen12:06
mwilliams_ctradiofree: that's  cracked it, thanks!12:06
paulsher1ood(not least because i keep crying 'red')12:06
paulsher1oodradiofree: is this a bug in our default configs?12:06
radiofreepaulsher1ood: yep12:07
pedroalvarezI'd like to have that working :(12:07
radiofreeresult of the systemd upgrade, there was some discussion here about it a few days ago12:07
radiofreepedroalvarez: isn't it just a matter of changing the network deployment.. configuration (??) scripts to use the new systemd format?12:07
pedroalvareznot sure, I don't know why are we configuring dhcp for en* and not for eth*, and I'm not sure if we should move to this new ethernet devices naming, or change the networkd conf12:09
ssam2I think we should change the networkd.conf12:10
ssam2even if we do move to name our devices en*12:10
ssam2I can't think of a situation where I'd have a device named eth0 and *not* want it to be auto-configured 12:10
radiofreename=e* would probably work, or en*,eth* if you can do that would be better12:12
pedroalvarezanother question is: do we want to stick that configuration in the chunk morphology? or should we move it to a configuration extension?12:13
radiofreewasn't there some other issue where you might not actually want to use dhcp though?12:13
ssam2pedroalvarez: i'm not sure, it seems like it should go in a config extension, but on the other hand it's nice for the unconfigured system to still have working network12:14
ssam2neater to put it in a config extension I guess12:14
ssam2radiofree: there's the case where you NFS-booted and so the kernel already DHCP'ed12:15
ssam2we should test whether the new systemd networkd handles that case...12:15
radiofreeso no baserock systems using static ip address?12:16
ssam2there are, but they are manually configured12:17
ssam2hmm, which is probably another argument for putting the whole thing in a config extension12:17
radiofreei think having a general dhcp config that matches on en* and eth* would be better12:17
pedroalvarezhm.. I thought that the simple-network configuration extension was used to configure static ip  addresses12:17
radiofreethen if you need to do anything specific, overwrite that with a configuration extension12:18
ssam2that'd be fine by me12:18
pedroalvarezshall we go for "en*,eth*" then?12:18
ssam2let's12:19
jmacsShould there be a set of CA root certificates on my baserock system somewhere?12:23
pedroalvarezmwilliams_ct: can you test that if you change eth* (or en*) in /etc/systemd/network/10-dhcp.network, to use "en*,eth*" instead also works?12:23
*** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 240 seconds]12:23
mwilliams_ctpedroalvarez: sure will have a look12:23
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock12:23
mwilliams_ctpedroalvarez: nope12:24
mwilliams_ct(as in nope, doesnt work)12:24
pedroalvarezjmacs: here? /usr/share/ca-certificates 12:25
jmacsI don't have that12:25
jmacsMy development system does12:25
pedroalvarezinstalled by the ca-certificates chunk12:26
pedroalvarezwhich is in core12:26
jmacsOdd.12:26
pedroalvarezyou also should have /etc/ssl/certs.12:30
pedroalvarezdoes your system have core?12:30
jmacsYes12:30
pedroalvarezyou should have the files /baserock/core-devel.meta and  /baserock/core-runtime.meta12:31
pedroalvarezand also /baserock/ca-certificates-* files12:31
jmacsI'lll check that after I've redeployed12:31
jjardonpaulsher1ood: FYI, that last commit can not affect http://mason-armv7lhf.baserock.org, as its a change in the graphics stack, and we are only building a build-* system there12:32
paulsher1oodright12:32
jjardon(hope this can be changed soon ;))12:32
paulsher1ood:-)12:32
persiaWhat is the release restriction?  Could we define a "test" cluster, and have masons test that?12:33
pedroalvarezpersia: this is currently called clusters/ci.morph12:33
* persia is confused, and goes to reinvestigate the current mason architecture12:37
persiaI had thought ci.morph only specified the systems to be used to build the systems mason builds.12:37
pedroalvarezwow, I can't understand that :) you might be right or wrong12:38
pedroalvarezci.morph says:   This cluster morph is for use by the Mason Continuous Delivery pipeline  during development.12:39
pedroalvarezso, these are the systems that are going to be tested by mason. If we want to add genivi systems, we should add them here12:39
persiaNote that the systems *built* by mason seem to be defined in mason-generator.sh12:40
SotKpersia: mason-generator.sh builds and deploys a Mason (I think its distbuild+trove using that script)12:41
* persia grumbles about systemd timers and the lost arts of cron and at12:41
paulsher1ood:)12:42
SotKMason builds and tests the systems in ci.morph which match its distbuild architecture12:42
persiaAs a side note, the OpenStack project specifically prefers nobody use "OS" to refer to it (and please ignore all the cases where OpenStack refers to itself as OS: these are now considered bugs).12:43
DavePageOpSt12:44
persiaAnd now I'm more confused.  Mason *seems* to call scripts/release-build, scripts/release-test, and scripts/release-upload, none of which specify ci.morph anywhere.12:48
persiaNote that this is the 2nd gen Mason: not the new shiny ectoplasm-enabled revision in discussion on the mailing list.12:49
pedroalvarezpersia: you can configure what cluster to build when creating mason12:49
radiofreeout of interest why is it still called eth* in openstack instances?12:51
radiofreeis net.ifnames=0 being passed?12:52
franredradiofree, I think so12:52
franredto the first question, not sure to the second12:52
persiapedroalvarez: With MASON_CLUSTER_MORPHOLOGY ?12:52
SotKpersia: yes12:54
* persia gets confused between MASON_CLUSTER_MORPHOLOGY and BUILD_CLUSTER_MORPHOLOGY and gives up.12:56
persiaIs there any reason we can't add much bigger systems to ci.morph, with more cool stuff in?12:56
SotKpersia: they are one and the same, for some reason the cluster morphology expects MASON_CLUSTER_MORPHOLOGY but that gets added to /etc/mason.conf as BUILD_CLUSTER_MORPHOLOGY by ansible12:58
SotKpersia: no technical reason that I am aware of, except the only test we do at the moment it checking that the system we are testing can build itself12:58
pedroalvarezpersia: bigger systems to test means slow feedback I guess12:59
persiapedroalvarez: Yes, but *some* feedback.  As mentioned above, some changes are getting no test at all.13:01
persiaAha!  mason/share/mason.conf renames all the variables.13:03
pedroalvarezyeah, I was just saying that maybe we decided to not included them because of the slow feedback13:03
pedroalvarezI'm of the opinion that we should test them all13:03
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds]13:03
* persia has progressed from confused aboutgen2 mason to depressed about gen2 mason, and looks forward to gen3 mason with great expectations.13:04
persiaI don't know about *all*: I'd be happy with a couple of the larger ones.13:04
persiaAlso, since GENIVI relies on Baserock, and GENIVI doesn't seem to have a working validation suite, it may be sensible to test those as well.13:04
pedroalvarezI'd say those with weston (genivi-baseline)13:04
persiaMaybe genivi-baseline + xfce + devel-system?13:05
persiaExtra points if we can find a way to test cross-bootstrap, but I think that is beyond the capabilities of gen2 Mason13:06
ssam2does 'gen2 mason' refer to http://mason-x86-64.baserock.org/ or the thing Adam is working on now?13:07
persiaThe current one13:07
persiagen1 is the old Jenkins-based Mason.13:07
ssam2ah, right13:07
persiaUnless there are more generations of which I'm unaware?13:08
pedroalvarezwell, gen0 is human testing :)13:10
ssam2no, I think you're correct13:10
ssam2I wondered if gen2 was the work-in-progress one13:10
* ssam2 packs up to attend http://operatingsystems.io/13:10
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]13:10
persiaFrom the notes so far, I *think* we might be able to use that to do cross-bootstrap, but it needs more investigation and thought (and I don't want to delay the rest of the gen3 stuff for that).13:11
SotKwe could just add a step (or replace the scripts/release-build step) to test that the cross-bootstrap command works13:17
SotKtesting the result of that command will need some thought though I imagine13:18
jmacsI'm still not entirely clear on what pedroalvarez's installer patch is for13:18
jmacsDoes anyone else understand it? (since he's just left for a conference)13:18
richard_mawit's roughly analogous to the USB installers you got for other distros13:20
richard_mawbut we've said: "oh, that's just another system, that contains a system you actually want to put on the target"13:21
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]13:22
petefothI’ve tweaked the permissions on the Stakeholder role in Taiga, to allow anyone to do pretty much everything. Thanks to radiofree for noticing that the role didn’t originally have those powers13:22
persiaSotK: My thought is that because we need to have it be different architectures, we need some way of having chained jobs in an architecture-independent manner, so the current setup of one-mason-per-arch isn't ideal.13:26
persiajmacs: I considered it to be a sneakernet deploy mechanism.13:26
richard_mawin isolation it can be used as that, combined with the pxeboot deployment stuff I was working on, you can deploy over network13:27
jmacsI can see the advantage of that, but installer.py appears to make an installation device and then actually runs it and reboots13:28
jmacsI'm not sure I see the difference between this and a normal self-deploy13:28
richard_mawradiofree might be interested in it too, since he was talking about changing how we deploy to Jetsons to work from an SD card13:28
* persia looks at installer.py again13:29
richard_mawjmacs: I haven't gotten to the code yet, but the idea is that the rootfs for the system you want to install is somewhere like /rootfs, and you set init=/installer.py, and the installer sets things up then runs rawdisk.write to put /rootfs on the local storage13:30
jmacsAh, I see, so installer.py is made part of the deployed system and not run at deploy time13:31
persiaRight.  The key is the cluster morphology.13:31
persiaThe to-install system gets set aside, to be installed by installer.py, which installs and reboots.13:31
* persia is still in the process of educating a pythonic palate, so is avoiding code review of installer.py directly13:32
jmacsWell, I'm fine with Python but missing an understanding of the wider implications, so we should have everything covered13:33
* persia goes back to formally review the non-python bits13:36
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock13:50
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock13:59
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]13:59
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock13:59
radiofreepedroalvarez: is the installer meant to install on hardware where baserock is the only os?14:11
persiaradiofree: That is how it reads to me14:14
radiofreeI think that's reasonable for now14:17
radiofreethere's a lot more you'd have to add to dual boot (existing bootloaders etc...)14:17
persiaIndeed :)14:17
radiofreeand of course, to actually update the stuff will require changing system-version-manager to support this14:17
persiaHrm?  Why?14:18
radiofreepersia: it's hardcoded to use extlinux.conf for a lot of things14:18
persiaOh, ugh.14:18
persiaLet's not do it that way.14:18
richard_mawyou could make the pre-installed bootloader chain-boot the baserock managed one14:18
radiofreewhich obviously isn't going to work for grub2 (for example)14:18
persiarichard_maw: yes, but syslinux isn't a very good choice for "the baserock managed one"14:19
* persia would vastly prefer EFI, or uboot, or grub2, any of which supports multiple architectures well14:19
radiofreefor embedded devices i think baserock being the only os is fine14:20
radiofreeobviously if i wanted to install this on my laptop i'd like it to support grub214:20
persiaFor nearly any case where Baserock is better than a distro, I think being the only OS is fine.14:20
radiofreebut i like what richard_maw suggested, it's a decent suggestion for getting something working quickly14:21
* persia would be delighted to no longer need grub2 on a laptop, but unfortunately booting linux directly from EFI is not well supported.14:21
radiofreeof course you'd have to change the installer..14:21
persiaActually, bootloader comprehension is something that needs to be done for system-version-manager anyway, so perhaps that is somewhat separable.14:22
persia(as currently it isn't possible to upgrade an install that can't pretend to be extlinux)14:22
radiofreethankfully u-boot can speak it now14:23
richard_mawI've heard good things about running grub2 as a u-boot application, as I believe its btrfs support is better, it can handle volume management, and it may be able to handle ZFS14:23
persiaradiofree: All u-boot, or only some u-boot?14:25
persiarichard_maw: How can grub2 handle ZFS?  I thought grub2 was GPL2, and ZFS was CDDL.  Is there a clean-room ZFS for grub?14:26
radiofreepersia: mainline at least14:26
richard_mawhttps://launchpad.net/~zfs-native/+archive/ubuntu/grub suggests someone's been trying it, but I haven't looked at how things are licensed14:27
persiaCool!  I thought it was still a vendor module.14:27
radiofreepersia: nope, and it's so much nicer than generating a boot.scr14:27
radiofreetext!14:28
radiofreeyou can build mainline for wandboard as well, would be interesting to test the system-version-manager patches for that as well14:28
radiofreeif the wandboard also supports the usb gadget stuff, you'd be able to use the install script i'm using for a jetson on it as well14:29
*** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock14:33
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds]14:34
petefoth_ is now known as petefoth14:34
persiaHrm.  I don't like the lack of attribution in the patches in grub2-zfs: there is at least one case of code being explicitly copied from Solaris into a file declared GPL3+ by a patch declared GPL3+14:34
persiaI'd *really* like to use that, but I fear it needs more investigation.14:34
richard_mawyeah, I get the feeling that if it were legal, distributions would be officially doing it14:36
persiaIt's not impossible.  As I mentioned before, there *are* bootloaders that can use ZFS14:38
persialilo being the most popular.14:38
persiaFor EFI-based systems, one could also store a bootloader ZFS module in the EFI partition, load that, and use that to load /boot.14:39
persia(assuming there exist ZFS modules for grub2 and/or u-boot)14:39
radiofreeare we all aboard the zfs train now then?14:54
rjekchoo choo14:54
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds]14:55
richard_mawI still like btrfs, but we need to be able to do zfs14:57
jmacsIf I have two workspaces on a baserock system, should builds on one affect the other?14:58
jmacsI just started a build in my second workspace and now my first is saying the system I want to deploy isn't built14:59
SotKhave you updated morph in the meantime?15:00
jmacsOh, might have done15:00
jmacsYeah, that'll be it15:02
SotKSo, with this Mason work to let us have multiple test plugins for turbo-hipster, there is a bunch of code that will be useful to *all* the test plugins.15:07
SotKDoes it make sense for this to live somewhere in the turbo-hipster git repo, or should it go elsewhere?15:07
* persia looks at upstream turbo-hipster15:11
persiaThere seems to be some test framework there: code useful for all tests might belong there.15:13
persiaBut some common code is probably baserock-specific, which might do better in the baserock/baserock/system-tests repo (or similar)15:14
persiaMaybe ask jhesketh in #openstack-dev how much can go upstream, and how much needs to be in a specialised repo?15:15
*** genii [~quassel@ubuntu/member/genii] has joined #baserock15:16
SotKMost of the code I had in mind is baserock-specific, regarding deployments and morphology handling stuff15:18
SotKI think that system-tests is probably the best place for it15:19
*** cosm [~Unknown@cspc154.cs.man.ac.uk] has quit [Ping timeout: 255 seconds]15:19
persiaMakes sense.  Anything that can be more general would be nice to push to turbo-hipster, but I'm wary of pushing code that can't go upstream into an upstream-derived repo.  To me, this is a recipe for continuous merge pain.15:20
SotKI thought about the merge pain regarding plugins too. turbo-hipster expects plugins in "$REPO/turbo_hipster/task_plugins/", but do all of our CI tests belong in the repo derived from turbo-hipster upstream, or should they go elsewhere and get put in the right place later?15:25
persiaThat doesn't sound like an ideal architecture.  I'd ask jhesketh how users of turbo-hipster are imagined to use it.15:29
persiaThat said, it is the middle of the night there, so such a query probably wouldn't get answered until morning.15:29
paulsher1oodpersia: do they really imagine any users outside the openstack use-case?15:30
persiaI have no idea.  I've not spoken with the author about it.  That said, for any other infra component where I've asked that class of question, folk were excited at the prospect of more users.15:31
* persia needs to find a way to be positive first, and then negative15:31
paulsher1oodpersia: i assume you saw my conv in #storyboard - clearly there's interest in ux help, but if everything comes down to 'no, we need it the way we do it already' it's not obvious how/why folks would contribute, except on helping them with the openstack backlog?15:34
persiaI don't know.  Might just be a matter of how we engage.15:35
jjardonrdale: hi, maybe you want to try baserock/jjardon/xserver and check if the xserver problem is gone?15:47
rdalerebase my qt5 changes on that branch?15:49
jjardonrdale: or cherry-pick, they are only 3 patches15:50
rdaleok, maybe that is easier15:50
*** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 250 seconds]15:52
*** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds]15:54
*** vmeson [~quassel@128.224.252.2] has joined #baserock15:54
*** cosm [~Unknown@host-78-150-56-250.as13285.net] has joined #baserock16:02
jmacsStill, this system seems very keen on rebuilding everything - all I changed was to add DISK_SIZE: 4G to the cluster definition and it's decided to rebuild about 90 elements16:14
radiofreedid you git pull the definitions?16:14
jmacsNo16:14
jmacsWith two workspaces is it possible the build cache is colliding?16:15
radiofreei wouldn't have thought so, if you updated morph between builds it's possible the cache key has changed16:17
radiofreerichard_maw would be the best person to ask about this though16:17
radiofreeare you using cache.baserock.org?16:17
jmacsI don't know16:17
richard_mawworkspaces share the caches between them16:18
radiofreeadd (to your /src/morph.conf)16:18
radiofreeartifact-cache-server = http://cache.baserock.org:8080/16:18
SotKjmacs: do you have artifact-cache-server set in your /etc/morph.conf16:18
SotKheh16:18
jmacsNope16:18
jmacsDo now16:18
*** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock16:28
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock16:33
jmacsDoesn't really seem to have sped things up much16:35
rdalejjardon: the xserver builds again with your patches16:56
jjardonrdale: nice, I guess thats a +1 from you? ;)16:59
rdaleyes indeed - if i have a vote16:59
richard_mawrdale: you do17:00
rdaleok, i'll give jjardon a +1 then17:00
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit]17:07
paulsher1oodwe seem to have two versions of orc - one in multimedia, one in multimedia-gstreamer-0.10 - is there a need for the difference?17:12
jjardonpedroalvarez: no really17:17
jjardonpaulsher1ood: ^17:17
paulsher1oodok, so maybe i'll do a patch to update to the later one?17:18
jjardonpaulsher1ood: correct solution would be to create a orc-stratum and make multimedia and multimedia-gstreamer-0.10 depend on it17:19
richard_mawyou would also have to add orc-stratum to the systems that include multimedia-*, unless we merge the run-depends patch, at which point we annotate multimedia-* to run-depend on orc-stratum17:21
paulsher1ooda stratum just containing orc? what's the benefit?17:24
paulsher1oodi can do that, though17:25
richard_mawit's currently the only way to have both multimedia strata depend on the same definition17:25
paulsher1oodwhat is orc?17:26
paulsher1oodhttp://code.entropywave.com/orc/17:32
jjardonpaulsher1ood: a library to take advantage of SIMD instructions in some architectures17:33
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]17:33
paulsher1oodso it doesn't logically go in any other stratum, i guess17:34
jjardonlike SSE or  3DNow!17:35
jjardonpaulsher1ood: AFAIK only gstreamer depends on it17:35
jjardonoh, and pulseaudio17:36
paulsher1oodah17:37
jjardonpaulsher1ood: you can put it in audio-bluetooth stratum, alsa stuff is there as well17:38
paulsher1oodok, makes sense - multimedia depends on that anyway17:38
jjardonyes17:39
paulsher1oodhmmm... does pulseaudio actually require orc?17:42
paulsher1oodi'm a bit worried about having orc in a big stratum (audio-bluetooth) and thus would not be explicitly clear it's only there for gstreamer17:44
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]17:44
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds]17:48
*** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal]17:56
jjardonpaulsher1ood: It doesn, but its optional: http://git.baserock.org/cgi-bin/cgit.cgi/delta/pulseaudio.git/tree/configure.ac#n118717:58
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]17:58
paulsher1oodah, ok17:58
*** Guest62074 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]18:01
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat]18:09
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]18:10
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock19:29
*** tiagogomes [~tiagogome@host-92-16-23-104.as13285.net] has joined #baserock19:47
*** tiagogomes [~tiagogome@host-92-16-23-104.as13285.net] has quit [Client Quit]19:47
paulsher1ooddid we update dbus recently?20:40
radiofreeI don't remember seeing any patches for that. Why?20:41
radiofreeIf it's an issue with the session bus, then there's never been one in br20:42
radiofreeYou can however do20:42
paulsher1oodgenivi baseline audiomanager not building for me20:42
radiofreedbus-launch --sh-syntax > /tmp/dbus-session20:42
radiofreeThe source /tmp/dbus-session whenever you need to use it20:43
radiofreeAh.. Well I built a genivi baseline today and it was fine20:43
paulsher1oodmust be me, then :)20:44
paulsher1oodyes, it was me21:03
paulsher1oodbut mesa in master doesn't build, am i right?21:07
radiofreeShould be fixed now21:33
radiofreejjardon 21:33
radiofreeI built a genivi system from master after his fix. Works21:34
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]22:39
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]23:13
*** juergbi [~juerg@vserver.paldo.org] has quit [Ping timeout: 245 seconds]23:58

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!