| persia | mwilliams_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 |
|---|---|---|
| persia | an 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 #baserock | 03: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 #baserock | 07:51 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:05 | |
| paulsher1ood | straycat: thanks. i scrapped the volume in the end | 08:27 |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:40 | |
| mike is now known as Guest62074 | 08:40 | |
| *** locallycompact [~lc@110.154.199.146.dyn.plus.net] has joined #baserock | 08:49 | |
| *** rdale [~quassel@140.Red-79-144-56.dynamicIP.rima-tde.net] has joined #baserock | 08: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 #baserock | 09:06 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:07 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:08 | |
| mwilliams_ct | persia: thanks for the info! I guess that's why DKMS had been suggested previously | 09:08 |
| persia | DKMS 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_ct | indeed, it's not the right solution for Baserock | 09:12 |
| radiofree | alternate fs for /boot is what i'm doing for the jetson, the patches to upgrade systems like that are already in system-version-manager | 09:13 |
| persia | Cool! | 09:13 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:14 | |
| radiofree | is using zfs going to be part of a big "how we update baserock systems" update? | 09:14 |
| persia | The 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 licensing | 09:16 |
| persia | I thought it was because of stability | 09:17 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 09: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 #baserock | 09:27 | |
| *** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:50 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:02 | |
| Mode #baserock +v ssam2 by ChanServ | 10:02 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:03 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 10:20 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 10:21 | |
| radiofree | ssam2: i don't think cryptopp is standard then :\ http://svn.code.sf.net/p/cryptopp/code/trunk/ | 10:23 |
| franred | radiofree, http://svn.code.sf.net/p/cryptopp/code/ <-- it has truck, branches and tags... looks like standard | 10:24 |
| franred | trunk* | 10:25 |
| richard_maw | not exactly, since all the stuff you actually want is in the c5 subdirectory | 10:25 |
| franred | ummmm, 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_maw | you can probably use `"layout": {"trunk": "trunk/c5", "branches": "branches/c5/*", "tags": "tags/setuptools/*"}` | 10:26 |
| richard_maw | wait, those tags are bogus | 10:27 |
| richard_maw | it's "tags/*/c5" and "branches/*/c5" | 10:27 |
| radiofree | ok, i'll change it to that! | 10:28 |
| radiofree | is "url": "svn://svn.code.sf.net/p/cryptopp/code/trunk" correct? | 10:29 |
| franred | radiofree, I think you have to remove trunk to lorry branches and tags | 10:30 |
| franred | I would use, "url": "svn://svn.code.sf.net/p/cryptopp/code" | 10:31 |
| richard_maw | franred is correct, you don't want /trunk at the end | 10:31 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 10:32 | |
| paulsher1ood | hmmm... qt4 doesn't build from master, i think? http://paste.baserock.org/uyusoxemug.vhdl | 10:52 |
| rdale | i haven't been looking at that, only qt5 | 10:54 |
| paulsher1ood | rdale: 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 | |
| radiofree | it's gstreamer | 10:55 |
| radiofree | update the sha for gstreamer-0.10 to the latest HEAD | 10:55 |
| rdale | yes, 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 why | 10:55 |
| radiofree | paulsher1ood: ^ | 10:55 |
| paulsher1ood | radiofree: i'm wondering how/when it broke? | 10:56 |
| radiofree | erm... around June | 10:56 |
| rdale | yes, nothing seems to have changed with the xserver for a while | 10:56 |
| radiofree | paulsher1ood: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-June/006631.html | 10:57 |
| paulsher1ood | i get same error building qt5-devel-system | 10:57 |
| radiofree | again, gstreamer | 10:57 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:57 | |
| Mode #baserock +v ssam2 by ChanServ | 10:57 | |
| rdale | i've split off the qtmultimedia module into it's own stratum with my current patch | 10:57 |
| pedroalvarez | ah, I see. this is not the same gstreamer that is being built on genive | 10:57 |
| paulsher1ood | radiofree: so is it that you provided patches and we didn't merge them? | 10:57 |
| rdale | ^it's^its | 10:58 |
| radiofree | paulsher1ood: they are merged now, but the ref in master never got updated i think | 10:59 |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: petefoth] | 11:00 | |
| radiofree | only merged a couple of weeks ago though | 11:00 |
| radiofree | there is no system with qt done as part of a release, so i suppose it's easy to miss | 11:00 |
| paulsher1ood | yup | 11:00 |
| rdale | i wasn't thinking people were still using qt4 either | 11:00 |
| paulsher1ood | so the fix is to update ref for gstreamer to the one in your patch? | 11:01 |
| radiofree | paulsher1ood: yep | 11:01 |
| radiofree | update http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/multimedia-gstreamer-0.10.morph | 11:01 |
| radiofree | update "gstreamer" in that to use sha 1bb95000.... | 11:01 |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:04 | |
| paulsher1ood | radiofree: your patch had sha 60185a6 ? | 11:15 |
| radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/delta/gstreamer.git/commit/?h=baserock/morph/0.10&id=1bb950008f4656f6a6153fa88a8ebb5a39fbe84f | 11:16 |
| paulsher1ood | oh, after merge | 11:16 |
| jjardon | paulsher1ood simply build wherever is in the current upstream 0.10 branch will fix the problem | 11:16 |
| radiofree | jjardon: well, we need http://git.baserock.org/cgi-bin/cgit.cgi/delta/gstreamer.git/commit/?h=baserock/morph/0.10&id=c7e4a97d26396882960fd399b1a5e298e40d2a35 | 11:17 |
| paulsher1ood | jjardon: yup! :-) | 11:17 |
| radiofree | so ignore jjardon | 11:17 |
| radiofree | simply build whatever is in the current baserock/morph/0.10 branch ;) | 11:17 |
| paulsher1ood | radiofree: he's talking about a different world :-) | 11:17 |
| radiofree | building from 0.10 master will also work, you'll just end up cloning the submodule from freedesktop rather than gbo | 11:18 |
| jjardon | rdale: whats the error? I think you have to add --disable-glx to the xserver configure parameters | 11:18 |
| radiofree | it's a pity morph can't automatically adjust the submodules | 11:18 |
| jjardon | paulsher1ood: yeah, you need the submodule thing | 11:20 |
| radiofree | paulsher1ood: btw my wip on the install script is https://github.com/jamespthomas/baserock-jetson-install/blob/master/baserock-install.sh | 11:23 |
| * paulsher1ood needs to find time to test it :-) | 11:25 | |
| radiofree | well the "# do the tegra-uboot-install stuff here..." needs to be done manually | 11:25 |
| radiofree | atm... | 11:25 |
| radiofree | also it'll partition the jetson, and create /boot, however you need to manually dd the baserock image (see dd-script.sh) | 11:26 |
| radiofree | WARNING: that script is hardcoded to /dev/sdb2 | 11:26 |
| radiofree | i'll finish it off tomorrow though | 11:26 |
| radiofree | pedroalvarez: what's the cache server url for the arm mason? | 11:29 |
| pedroalvarez | radiofree: http://cache.baserock.org:8080/ :) | 11:29 |
| pedroalvarez | the same for all of them | 11:30 |
| paulsher1ood | pedroalvarez: that works already? wow! | 11:30 |
| paulsher1ood | how does it work? | 11:30 |
| radiofree | [22:25:51] <jjardon> "Fetching to local cache" <- magic words :) :D | 11:30 |
| pedroalvarez | paulsher1ood: are you asking for implementation details, or perfomance? | 11:31 |
| paulsher1ood | implementation details, out of interest | 11:31 |
| pedroalvarez | right | 11:31 |
| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has joined #baserock | 11:33 | |
| pedroalvarez | cache.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 |
| rdale | jjardon: the xserver error i'm getting: http://paste.baserock.org/ozovuxenuy.vhdl | 11:35 |
| jjardon | rdale: never seen that error before, Im building with a old chroot here though | 11:36 |
| rdale | jjardon: 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 it | 11:39 |
| jjardon | rdale: seems you are hitting https://www.libreoffice.org/bugzilla/show_bug.cgi?id=82990 | 11:39 |
| rdale | yes, it's a known bug that was fixed a while ago | 11:39 |
| jjardon | (related with the recent upgrade to glibc 2.20 | 11:39 |
| jjardon | rdale: Im working in a branch to upgrade to latest xserver that will probably fix the problem | 11:40 |
| rdale | have we upgraded to glibc 2.20 in baserock then? | 11:41 |
| pedroalvarez | rdale: yup! | 11:41 |
| rdale | ah ha | 11:42 |
| jjardon | pedroalvarez: is it Alvarez or Álvarez? | 11:47 |
| pedroalvarez | jjardon: hahah I'm not using the Á since I moved to UK | 11:48 |
| rjek | Why not? :) | 11:48 |
| jjardon | pedroalvarez: oki! | 11:49 |
| pedroalvarez | I'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 tilde | 11:49 |
| paulsher1ood | red at http://mason-armv7lhf.baserock.org | 11:57 |
| radiofree | the latest merge hasn't propagated yet? | 12:00 |
| pedroalvarez | paulsher1ood: 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 branches | 12:00 |
| pedroalvarez | as 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 it | 12:01 |
| mwilliams_ct | hi 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 |
| radiofree | mwilliams_ct: what version of systemd? | 12:02 |
| radiofree | systemctl --version | 12:03 |
| mwilliams_ct | radiofree: systemd 217 | 12:03 |
| paulsher1ood | mwilliams_ct: ipaddr ? | 12:03 |
| radiofree | mwilliams_ct: interesting! what does ifconfig -a give you? | 12:03 |
| radiofree | looking for something called either en* or eth* | 12:03 |
| mwilliams_ct | slight issue that I can't copy and paste because it's on an openstack instance | 12:04 |
| radiofree | you can run udhcpc for now, but this should be automatic | 12:04 |
| radiofree | mwilliams_ct: is there a device called eth*? | 12:04 |
| paulsher1ood | mwilliams_ct: uggh.. and you can't ssh in, obviously :-) | 12:04 |
| paulsher1ood | mwilliams_ct: screenshot? | 12:04 |
| mwilliams_ct | radiofree: yes, with no ip address | 12:05 |
| radiofree | mwilliams_ct: ok, you need to edit /etc/systemd/network/10-dhcp.network | 12:05 |
| radiofree | change en* to eth*, which will use dhcp, but considering you're using openstack i don't think that's what you want | 12:05 |
| paulsher1ood | pedroalvarez: oh, so the red is just delay, til mirroring catches up? | 12:05 |
| pedroalvarez | paulsher1ood: yes | 12:05 |
| pedroalvarez | and I'd like that this didn't happen | 12:06 |
| mwilliams_ct | radiofree: that's cracked it, thanks! | 12:06 |
| paulsher1ood | (not least because i keep crying 'red') | 12:06 |
| paulsher1ood | radiofree: is this a bug in our default configs? | 12:06 |
| radiofree | paulsher1ood: yep | 12:07 |
| pedroalvarez | I'd like to have that working :( | 12:07 |
| radiofree | result of the systemd upgrade, there was some discussion here about it a few days ago | 12:07 |
| radiofree | pedroalvarez: isn't it just a matter of changing the network deployment.. configuration (??) scripts to use the new systemd format? | 12:07 |
| pedroalvarez | not 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 conf | 12:09 |
| ssam2 | I think we should change the networkd.conf | 12:10 |
| ssam2 | even if we do move to name our devices en* | 12:10 |
| ssam2 | I can't think of a situation where I'd have a device named eth0 and *not* want it to be auto-configured | 12:10 |
| radiofree | name=e* would probably work, or en*,eth* if you can do that would be better | 12:12 |
| pedroalvarez | another question is: do we want to stick that configuration in the chunk morphology? or should we move it to a configuration extension? | 12:13 |
| radiofree | wasn't there some other issue where you might not actually want to use dhcp though? | 12:13 |
| ssam2 | pedroalvarez: 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 network | 12:14 |
| ssam2 | neater to put it in a config extension I guess | 12:14 |
| ssam2 | radiofree: there's the case where you NFS-booted and so the kernel already DHCP'ed | 12:15 |
| ssam2 | we should test whether the new systemd networkd handles that case... | 12:15 |
| radiofree | so no baserock systems using static ip address? | 12:16 |
| ssam2 | there are, but they are manually configured | 12:17 |
| ssam2 | hmm, which is probably another argument for putting the whole thing in a config extension | 12:17 |
| radiofree | i think having a general dhcp config that matches on en* and eth* would be better | 12:17 |
| pedroalvarez | hm.. I thought that the simple-network configuration extension was used to configure static ip addresses | 12:17 |
| radiofree | then if you need to do anything specific, overwrite that with a configuration extension | 12:18 |
| ssam2 | that'd be fine by me | 12:18 |
| pedroalvarez | shall we go for "en*,eth*" then? | 12:18 |
| ssam2 | let's | 12:19 |
| jmacs | Should there be a set of CA root certificates on my baserock system somewhere? | 12:23 |
| pedroalvarez | mwilliams_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_ct | pedroalvarez: sure will have a look | 12:23 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 12:23 | |
| mwilliams_ct | pedroalvarez: nope | 12:24 |
| mwilliams_ct | (as in nope, doesnt work) | 12:24 |
| pedroalvarez | jmacs: here? /usr/share/ca-certificates | 12:25 |
| jmacs | I don't have that | 12:25 |
| jmacs | My development system does | 12:25 |
| pedroalvarez | installed by the ca-certificates chunk | 12:26 |
| pedroalvarez | which is in core | 12:26 |
| jmacs | Odd. | 12:26 |
| pedroalvarez | you also should have /etc/ssl/certs. | 12:30 |
| pedroalvarez | does your system have core? | 12:30 |
| jmacs | Yes | 12:30 |
| pedroalvarez | you should have the files /baserock/core-devel.meta and /baserock/core-runtime.meta | 12:31 |
| pedroalvarez | and also /baserock/ca-certificates-* files | 12:31 |
| jmacs | I'lll check that after I've redeployed | 12:31 |
| jjardon | paulsher1ood: 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 there | 12:32 |
| paulsher1ood | right | 12:32 |
| jjardon | (hope this can be changed soon ;)) | 12:32 |
| paulsher1ood | :-) | 12:32 |
| persia | What is the release restriction? Could we define a "test" cluster, and have masons test that? | 12:33 |
| pedroalvarez | persia: this is currently called clusters/ci.morph | 12:33 |
| * persia is confused, and goes to reinvestigate the current mason architecture | 12:37 | |
| persia | I had thought ci.morph only specified the systems to be used to build the systems mason builds. | 12:37 |
| pedroalvarez | wow, I can't understand that :) you might be right or wrong | 12:38 |
| pedroalvarez | ci.morph says: This cluster morph is for use by the Mason Continuous Delivery pipeline during development. | 12:39 |
| pedroalvarez | so, these are the systems that are going to be tested by mason. If we want to add genivi systems, we should add them here | 12:39 |
| persia | Note that the systems *built* by mason seem to be defined in mason-generator.sh | 12:40 |
| SotK | persia: 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 at | 12:41 | |
| paulsher1ood | :) | 12:42 |
| SotK | Mason builds and tests the systems in ci.morph which match its distbuild architecture | 12:42 |
| persia | As 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 |
| DavePage | OpSt | 12:44 |
| persia | And 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 |
| persia | Note that this is the 2nd gen Mason: not the new shiny ectoplasm-enabled revision in discussion on the mailing list. | 12:49 |
| pedroalvarez | persia: you can configure what cluster to build when creating mason | 12:49 |
| radiofree | out of interest why is it still called eth* in openstack instances? | 12:51 |
| radiofree | is net.ifnames=0 being passed? | 12:52 |
| franred | radiofree, I think so | 12:52 |
| franred | to the first question, not sure to the second | 12:52 |
| persia | pedroalvarez: With MASON_CLUSTER_MORPHOLOGY ? | 12:52 |
| SotK | persia: yes | 12:54 |
| * persia gets confused between MASON_CLUSTER_MORPHOLOGY and BUILD_CLUSTER_MORPHOLOGY and gives up. | 12:56 | |
| persia | Is there any reason we can't add much bigger systems to ci.morph, with more cool stuff in? | 12:56 |
| SotK | persia: 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 ansible | 12:58 |
| SotK | persia: 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 itself | 12:58 |
| pedroalvarez | persia: bigger systems to test means slow feedback I guess | 12:59 |
| persia | pedroalvarez: Yes, but *some* feedback. As mentioned above, some changes are getting no test at all. | 13:01 |
| persia | Aha! mason/share/mason.conf renames all the variables. | 13:03 |
| pedroalvarez | yeah, I was just saying that maybe we decided to not included them because of the slow feedback | 13:03 |
| pedroalvarez | I'm of the opinion that we should test them all | 13: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 | |
| persia | I don't know about *all*: I'd be happy with a couple of the larger ones. | 13:04 |
| persia | Also, 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 |
| pedroalvarez | I'd say those with weston (genivi-baseline) | 13:04 |
| persia | Maybe genivi-baseline + xfce + devel-system? | 13:05 |
| persia | Extra points if we can find a way to test cross-bootstrap, but I think that is beyond the capabilities of gen2 Mason | 13:06 |
| ssam2 | does 'gen2 mason' refer to http://mason-x86-64.baserock.org/ or the thing Adam is working on now? | 13:07 |
| persia | The current one | 13:07 |
| persia | gen1 is the old Jenkins-based Mason. | 13:07 |
| ssam2 | ah, right | 13:07 |
| persia | Unless there are more generations of which I'm unaware? | 13:08 |
| pedroalvarez | well, gen0 is human testing :) | 13:10 |
| ssam2 | no, I think you're correct | 13:10 |
| ssam2 | I wondered if gen2 was the work-in-progress one | 13: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 | |
| persia | From 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 |
| SotK | we could just add a step (or replace the scripts/release-build step) to test that the cross-bootstrap command works | 13:17 |
| SotK | testing the result of that command will need some thought though I imagine | 13:18 |
| jmacs | I'm still not entirely clear on what pedroalvarez's installer patch is for | 13:18 |
| jmacs | Does anyone else understand it? (since he's just left for a conference) | 13:18 |
| richard_maw | it's roughly analogous to the USB installers you got for other distros | 13:20 |
| richard_maw | but 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 | |
| petefoth | I’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 powers | 13:22 |
| persia | SotK: 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 |
| persia | jmacs: I considered it to be a sneakernet deploy mechanism. | 13:26 |
| richard_maw | in isolation it can be used as that, combined with the pxeboot deployment stuff I was working on, you can deploy over network | 13:27 |
| jmacs | I can see the advantage of that, but installer.py appears to make an installation device and then actually runs it and reboots | 13:28 |
| jmacs | I'm not sure I see the difference between this and a normal self-deploy | 13:28 |
| richard_maw | radiofree might be interested in it too, since he was talking about changing how we deploy to Jetsons to work from an SD card | 13:28 |
| * persia looks at installer.py again | 13:29 | |
| richard_maw | jmacs: 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 storage | 13:30 |
| jmacs | Ah, I see, so installer.py is made part of the deployed system and not run at deploy time | 13:31 |
| persia | Right. The key is the cluster morphology. | 13:31 |
| persia | The 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 directly | 13:32 | |
| jmacs | Well, I'm fine with Python but missing an understanding of the wider implications, so we should have everything covered | 13:33 |
| * persia goes back to formally review the non-python bits | 13:36 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:50 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 13:59 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 13:59 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 13:59 | |
| radiofree | pedroalvarez: is the installer meant to install on hardware where baserock is the only os? | 14:11 |
| persia | radiofree: That is how it reads to me | 14:14 |
| radiofree | I think that's reasonable for now | 14:17 |
| radiofree | there's a lot more you'd have to add to dual boot (existing bootloaders etc...) | 14:17 |
| persia | Indeed :) | 14:17 |
| radiofree | and of course, to actually update the stuff will require changing system-version-manager to support this | 14:17 |
| persia | Hrm? Why? | 14:18 |
| radiofree | persia: it's hardcoded to use extlinux.conf for a lot of things | 14:18 |
| persia | Oh, ugh. | 14:18 |
| persia | Let's not do it that way. | 14:18 |
| richard_maw | you could make the pre-installed bootloader chain-boot the baserock managed one | 14:18 |
| radiofree | which obviously isn't going to work for grub2 (for example) | 14:18 |
| persia | richard_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 well | 14:19 | |
| radiofree | for embedded devices i think baserock being the only os is fine | 14:20 |
| radiofree | obviously if i wanted to install this on my laptop i'd like it to support grub2 | 14:20 |
| persia | For nearly any case where Baserock is better than a distro, I think being the only OS is fine. | 14:20 |
| radiofree | but i like what richard_maw suggested, it's a decent suggestion for getting something working quickly | 14: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 | |
| radiofree | of course you'd have to change the installer.. | 14:21 |
| persia | Actually, 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 |
| radiofree | thankfully u-boot can speak it now | 14:23 |
| richard_maw | I'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 ZFS | 14:23 |
| persia | radiofree: All u-boot, or only some u-boot? | 14:25 |
| persia | richard_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 |
| radiofree | persia: mainline at least | 14:26 |
| richard_maw | https://launchpad.net/~zfs-native/+archive/ubuntu/grub suggests someone's been trying it, but I haven't looked at how things are licensed | 14:27 |
| persia | Cool! I thought it was still a vendor module. | 14:27 |
| radiofree | persia: nope, and it's so much nicer than generating a boot.scr | 14:27 |
| radiofree | text! | 14:28 |
| radiofree | you can build mainline for wandboard as well, would be interesting to test the system-version-manager patches for that as well | 14:28 |
| radiofree | if 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 well | 14:29 |
| *** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14: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 petefoth | 14:34 | |
| persia | Hrm. 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 |
| persia | I'd *really* like to use that, but I fear it needs more investigation. | 14:34 |
| richard_maw | yeah, I get the feeling that if it were legal, distributions would be officially doing it | 14:36 |
| persia | It's not impossible. As I mentioned before, there *are* bootloaders that can use ZFS | 14:38 |
| persia | lilo being the most popular. | 14:38 |
| persia | For 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 |
| radiofree | are we all aboard the zfs train now then? | 14:54 |
| rjek | choo choo | 14:54 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 14:55 | |
| richard_maw | I still like btrfs, but we need to be able to do zfs | 14:57 |
| jmacs | If I have two workspaces on a baserock system, should builds on one affect the other? | 14:58 |
| jmacs | I just started a build in my second workspace and now my first is saying the system I want to deploy isn't built | 14:59 |
| SotK | have you updated morph in the meantime? | 15:00 |
| jmacs | Oh, might have done | 15:00 |
| jmacs | Yeah, that'll be it | 15:02 |
| SotK | So, 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 |
| SotK | Does 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-hipster | 15:11 | |
| persia | There seems to be some test framework there: code useful for all tests might belong there. | 15:13 |
| persia | But some common code is probably baserock-specific, which might do better in the baserock/baserock/system-tests repo (or similar) | 15:14 |
| persia | Maybe 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 #baserock | 15:16 | |
| SotK | Most of the code I had in mind is baserock-specific, regarding deployments and morphology handling stuff | 15:18 |
| SotK | I think that system-tests is probably the best place for it | 15:19 |
| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has quit [Ping timeout: 255 seconds] | 15:19 | |
| persia | Makes 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 |
| SotK | I 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 |
| persia | That doesn't sound like an ideal architecture. I'd ask jhesketh how users of turbo-hipster are imagined to use it. | 15:29 |
| persia | That said, it is the middle of the night there, so such a query probably wouldn't get answered until morning. | 15:29 |
| paulsher1ood | persia: do they really imagine any users outside the openstack use-case? | 15:30 |
| persia | I 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 negative | 15:31 | |
| paulsher1ood | persia: 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 |
| persia | I don't know. Might just be a matter of how we engage. | 15:35 |
| jjardon | rdale: hi, maybe you want to try baserock/jjardon/xserver and check if the xserver problem is gone? | 15:47 |
| rdale | rebase my qt5 changes on that branch? | 15:49 |
| jjardon | rdale: or cherry-pick, they are only 3 patches | 15:50 |
| rdale | ok, maybe that is easier | 15: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 #baserock | 15:54 | |
| *** cosm [~Unknown@host-78-150-56-250.as13285.net] has joined #baserock | 16:02 | |
| jmacs | Still, 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 elements | 16:14 |
| radiofree | did you git pull the definitions? | 16:14 |
| jmacs | No | 16:14 |
| jmacs | With two workspaces is it possible the build cache is colliding? | 16:15 |
| radiofree | i wouldn't have thought so, if you updated morph between builds it's possible the cache key has changed | 16:17 |
| radiofree | richard_maw would be the best person to ask about this though | 16:17 |
| radiofree | are you using cache.baserock.org? | 16:17 |
| jmacs | I don't know | 16:17 |
| richard_maw | workspaces share the caches between them | 16:18 |
| radiofree | add (to your /src/morph.conf) | 16:18 |
| radiofree | artifact-cache-server = http://cache.baserock.org:8080/ | 16:18 |
| SotK | jmacs: do you have artifact-cache-server set in your /etc/morph.conf | 16:18 |
| SotK | heh | 16:18 |
| jmacs | Nope | 16:18 |
| jmacs | Do now | 16:18 |
| *** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:28 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:33 | |
| jmacs | Doesn't really seem to have sped things up much | 16:35 |
| rdale | jjardon: the xserver builds again with your patches | 16:56 |
| jjardon | rdale: nice, I guess thats a +1 from you? ;) | 16:59 |
| rdale | yes indeed - if i have a vote | 16:59 |
| richard_maw | rdale: you do | 17:00 |
| rdale | ok, i'll give jjardon a +1 then | 17:00 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:07 | |
| paulsher1ood | we 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 |
| jjardon | pedroalvarez: no really | 17:17 |
| jjardon | paulsher1ood: ^ | 17:17 |
| paulsher1ood | ok, so maybe i'll do a patch to update to the later one? | 17:18 |
| jjardon | paulsher1ood: correct solution would be to create a orc-stratum and make multimedia and multimedia-gstreamer-0.10 depend on it | 17:19 |
| richard_maw | you 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-stratum | 17:21 |
| paulsher1ood | a stratum just containing orc? what's the benefit? | 17:24 |
| paulsher1ood | i can do that, though | 17:25 |
| richard_maw | it's currently the only way to have both multimedia strata depend on the same definition | 17:25 |
| paulsher1ood | what is orc? | 17:26 |
| paulsher1ood | http://code.entropywave.com/orc/ | 17:32 |
| jjardon | paulsher1ood: a library to take advantage of SIMD instructions in some architectures | 17:33 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 17:33 | |
| paulsher1ood | so it doesn't logically go in any other stratum, i guess | 17:34 |
| jjardon | like SSE or 3DNow! | 17:35 |
| jjardon | paulsher1ood: AFAIK only gstreamer depends on it | 17:35 |
| jjardon | oh, and pulseaudio | 17:36 |
| paulsher1ood | ah | 17:37 |
| jjardon | paulsher1ood: you can put it in audio-bluetooth stratum, alsa stuff is there as well | 17:38 |
| paulsher1ood | ok, makes sense - multimedia depends on that anyway | 17:38 |
| jjardon | yes | 17:39 |
| paulsher1ood | hmmm... does pulseaudio actually require orc? | 17:42 |
| paulsher1ood | i'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 gstreamer | 17: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 | |
| jjardon | paulsher1ood: It doesn, but its optional: http://git.baserock.org/cgi-bin/cgit.cgi/delta/pulseaudio.git/tree/configure.ac#n1187 | 17:58 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:58 | |
| paulsher1ood | ah, ok | 17: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 #baserock | 19:29 | |
| *** tiagogomes [~tiagogome@host-92-16-23-104.as13285.net] has joined #baserock | 19:47 | |
| *** tiagogomes [~tiagogome@host-92-16-23-104.as13285.net] has quit [Client Quit] | 19:47 | |
| paulsher1ood | did we update dbus recently? | 20:40 |
| radiofree | I don't remember seeing any patches for that. Why? | 20:41 |
| radiofree | If it's an issue with the session bus, then there's never been one in br | 20:42 |
| radiofree | You can however do | 20:42 |
| paulsher1ood | genivi baseline audiomanager not building for me | 20:42 |
| radiofree | dbus-launch --sh-syntax > /tmp/dbus-session | 20:42 |
| radiofree | The source /tmp/dbus-session whenever you need to use it | 20:43 |
| radiofree | Ah.. Well I built a genivi baseline today and it was fine | 20:43 |
| paulsher1ood | must be me, then :) | 20:44 |
| paulsher1ood | yes, it was me | 21:03 |
| paulsher1ood | but mesa in master doesn't build, am i right? | 21:07 |
| radiofree | Should be fixed now | 21:33 |
| radiofree | jjardon | 21:33 |
| radiofree | I built a genivi system from master after his fix. Works | 21: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!