| *** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 240 seconds] | 00:08 | |
| *** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has joined #baserock | 00:08 | |
| *** jmacs_ [~jimmacart@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 264 seconds] | 00:09 | |
| *** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 244 seconds] | 00:09 | |
| *** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 00:09 | |
| *** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has joined #baserock | 00:10 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 00:16 | |
| *** rdale [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has quit [Ping timeout: 244 seconds] | 00:41 | |
| *** rdale [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has joined #baserock | 00:42 | |
| *** rdale [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has quit [Ping timeout: 272 seconds] | 00:50 | |
| *** jjardon [sid723@gateway/web/irccloud.com/x-kthuhjfdsxgaglys] has quit [Ping timeout: 272 seconds] | 00:50 | |
| *** rdale_ [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has joined #baserock | 00:50 | |
| *** jjardon [sid723@gateway/web/irccloud.com/x-ihqtvarjqyectfjv] has joined #baserock | 00:52 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 07:28 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 07:59 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:20 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:51 | |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:54 | |
| mike is now known as Guest40361 | 08:54 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:57 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 09:01 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:10 | |
| paulsher1ood | radiofree_: did you write up the chromebook chroot process anywhere? | 09:11 |
|---|---|---|
| radiofree_ | paulsher1ood: in the e-mail i sent you? | 09:16 |
| radiofree_ | i'll e-mail the list when i get in | 09:16 |
| radiofree_ | one of the reasons for my rootfs patch was to enable that | 09:17 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 250 seconds] | 09:22 | |
| De|ta_ is now known as De|ta | 09:25 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 09:34 | |
| jjardon | paulsher1ood: we also build in the ci reference systems that build graphical components up to Weston | 09:36 |
| jjardon | +GStreamer and other connectivity stuff | 09:36 |
| persia | That reminds me: is there a way we can submit systems to be built by the distbuild networks to populate the cache manually, other than adding them to CI? | 09:42 |
| radiofree_ | if you knew the IP of the arm mason network? | 09:44 |
| persia | My understanding was that it didn't have a public IP | 09:45 |
| persia | But if I'm mistaken, then I suppose it's just a morph config, and distbuild, yes? | 09:45 |
| rdale_ | i'm failing to build the morph chunk: SyntaxError: Non-ASCII character '\xe2' in file /morph.build/morphlib/plugins/deploy_plugin.py on line 186, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details | 09:45 |
| rdale_ | is that a known problem? | 09:45 |
| radiofree_ | yeah if it were public you could distbuild your branch on it to populate the cache globally | 09:46 |
| persia | rdale_: One that hasn't been seen in quite a while. What is your locale? | 09:46 |
| pedroalvarez | rdale_: I've fixed that problem in definitions.git master | 09:47 |
| pedroalvarez | rdale_: as you can see, mason is full of these errors: http://mason-x86-64.baserock.org/ | 09:47 |
| rdale_ | ok - i created a branch off master yesterday, but i probably should have done a pull first - i'll try rebasing | 09:48 |
| pedroalvarez | yes, current master works | 09:48 |
| persia | pedroalvarez: Oh, was that the ... patch you just applied? | 09:48 |
| pedroalvarez | yes | 09:48 |
| persia | Ah. I thought it was the older bug. | 09:48 |
| paulsher1ood | radiofree_: i mean the process for setting up a baserock chroot on a chromebook...? | 09:49 |
| pedroalvarez | I think we have fixed all the unicode problems in morph :) | 09:49 |
| persia | radiofree_: Don't I need some credentials to be able to populate a global cache? | 09:49 |
| pedroalvarez | this reminds me that we should talk to petefoth about this and "how documentation changes can screw up morph" :) | 09:49 |
| rdale_ | is it unicode in a comment? | 09:50 |
| persia | In a documentation string | 09:50 |
| paulsher1ood | pedroalvarez: mason still red, though? | 09:51 |
| pedroalvarez | paulsher1ood: still building | 09:51 |
| pedroalvarez | http://mason-armv7lhf.baserock.org/ is showing a green already | 09:51 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 244 seconds] | 09:52 | |
| paulsher1ood | wow... how come the arm finished first? :-) | 09:53 |
| petefoth | pedroalvarez: sorry I broke the build! | 09:53 |
| persia | ARM doesn't always mean slow | 09:53 |
| radiofree_ | paulsher1ood: build tarball, copy to chromebook, extract somewhere, echo "baserock" > /path/to/your/passrock/etc/crouton/name | 09:54 |
| pedroalvarez | x86 had to build more things.. not sure why | 09:54 |
| paulsher1ood | radiofree_: ??? | 09:54 |
| paulsher1ood | radiofree_: i was hoping for something publishable on the wiki, including instructions for setting up crouton if that is required | 09:55 |
| * petefoth moves the ‘Get a working baserock vm’ task to the top of his to-do list | 09:56 | |
| paulsher1ood | petefoth: should take 10 minutes ;) | 09:56 |
| radiofree_ | download crouton, install with the flag i can't remember off the top of my head but am sure i wrote down somewhere, do what i said with the tarball | 09:56 |
| * radiofree_ will update the wiki soon | 09:57 | |
| persia | I seem to remember that having `vagrant up` working at some point was demonstrated, but not maintained due to lack of infrastructure. | 09:57 |
| radiofree_ | we need to have a tarball rootfs on the download page though | 09:57 |
| persia | With infrastructure, can that be made to work now? | 09:57 |
| pedroalvarez | .. we should be publishing the images that mason is building... | 09:58 |
| petefoth | paulsher1ood: I know - I’ve just been focussed on other stuff, amd thinking ‘Doc changes won’t break anything’. I was wrong! | 09:58 |
| persia | pedroalvarez: Only if they build succesfully, but yes, and then we're almost at the point of not needing releases anymore :) | 09:59 |
| franred | persia, as far as I know we build the images... but we don't keep them in any part, we use them to do testing and then they are removed, so, yes, the step to have continues releases is copy to a server (at least for x86_64) | 10:01 |
| rdale_ | the remote cache option seems to be a big improvement, my systems are building or failing to build really quite fast | 10:01 |
| pedroalvarez | we don't even use them to do testing | 10:01 |
| paulsher1ood | radiofree_: i've started a page... http://wiki.baserock.org/guides/baserock-cb5-311/ | 10:04 |
| radiofree_ | that page is rather unfortunately titled | 10:05 |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 10:05 | |
| radiofree_ | baserock-chromebook? | 10:05 |
| radiofree_ | baserock-arm-chromebook? | 10:05 |
| radiofree_ | since it will work on any arm chromebook | 10:05 |
| radiofree_ | pedroalvarez: persia: what did we agree about the rootfs tarball yesterday/ | 10:08 |
| radiofree_ | just build the wandboard image as a tarball? | 10:09 |
| radiofree_ | (i'll submit a patch in a moment) | 10:09 |
| radiofree_ | the wandboard *build* image | 10:09 |
| persia | franred: Why only x86_64 ? | 10:09 |
| pedroalvarez | radiofree_: I'd be ok with it being the *devel* one | 10:11 |
| franred | persia, Im sure that in x86_64 we are doing the mason full test cycle, which implies to build and deploy a raw image and test it building a new system | 10:11 |
| pedroalvarez | radiofree_: the only difference between the wandbord one and jetson one is the bsp, so it will only build the wandboard bsp | 10:11 |
| persia | radiofree_: Reading backscroll, I think we got distracted by your -1 on your patch | 10:12 |
| franred | persia, I don't know what the mason for arm is doing, pedroalvarez knows this better than me | 10:12 |
| pedroalvarez | radiofree_: can't we just build the jetson image as a tarball? | 10:12 |
| persia | I thought we were doing full test cycles for all of armv7lhf, x86_32 and x86_64 | 10:12 |
| franred | persia, no as far as I know. | 10:13 |
| pedroalvarez | no no, we are not doing full test cycles in any of the architectures, sorry | 10:13 |
| persia | Why not? | 10:13 |
| pedroalvarez | we can in x86, but I didn't have the time to configure it | 10:13 |
| SotK | r/win 11 | 10:13 |
| SotK | bah | 10:13 |
| persia | Why can't we for !x86? | 10:13 |
| radiofree_ | pedroalvarez: jetson image has more bsp | 10:14 |
| pedroalvarez | our current mason only tests in kvm or in openstack, so it deploys to any of them and performs the testing | 10:14 |
| radiofree_ | drivers, some systemd unit | 10:14 |
| radiofree_ | wandboard doesn't even have u-boot, very minimal | 10:14 |
| persia | pedroalvarez: Ah. In that case, I'm looking forward to the installer stuff even more :) | 10:15 |
| pedroalvarez | so we can deploy to bare-metal? :P | 10:15 |
| persia | Actually, we could do KVM for now. | 10:16 |
| radiofree_ | i'm glad i never build for x86 | 10:16 |
| radiofree_ | if the goal is bare-metal x86, i don't want to sit through the build of 8 million kernel modules to make that properly work | 10:17 |
| pedroalvarez | persia: for !x86 you mean? | 10:17 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:17 | |
| Mode #baserock +v ssam2 by ChanServ | 10:17 | |
| persia | pedroalvarez: Yes. | 10:17 |
| persia | radiofree_: I want bare-metal ARM, so your avoidance of x86 won't help :p | 10:17 |
| radiofree_ | we already have baremetal ARM! | 10:18 |
| persia | Without a serial cable? | 10:18 |
| persia | Or human involvement? | 10:18 |
| * persia didn't think we had access to any BMC-enabled ARM systems | 10:19 | |
| radiofree_ | i don't know how you can install anything on anything without human involvement | 10:19 |
| persia | automation. | 10:19 |
| radiofree_ | i haven't sent patches to allow baserock to be installed via osmosis yet | 10:19 |
| persia | For example, if you have BMC-enabled hardware, and code that tells the BMC to initialise the system in a certain way, after downloading additional code from a certain source, you can boot to the BMC-provided data, and then do anything you like. | 10:20 |
| radiofree_ | well you can now install baserock on a jetson with just a keypress (to put it in recovery mode) | 10:20 |
| persia | richard_maw sent some BMC patches a while back, and pedroalvarez has been working on an installer (the BMC payload) | 10:20 |
| radiofree_ | everything else (partitioning, flashing...) is automated | 10:21 |
| persia | Yeah, that doesn't work for CI, because there isn't any way to do the keypress. I suppose robots could be constructed. | 10:21 |
| radiofree_ | but you have to, the first time, press a button | 10:21 |
| persia | Do you not also need a USB connection? | 10:21 |
| radiofree_ | persia: once it has baserock on you don't need to flash it anymore | 10:21 |
| radiofree_ | just update it over-the-air | 10:21 |
| persia | That doesn't test the flash procedure. | 10:21 |
| radiofree_ | i wrote the flash procedure, it's best we don't rock that boat | 10:22 |
| pedroalvarez | hahah | 10:22 |
| pedroalvarez | persia: so, tell me about kvm + !x86 | 10:22 |
| persia | heh. But surely you'll appreciate informed reviews of how people break it? | 10:22 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 264 seconds] | 10:22 | |
| persia | pedroalvarez: If you have ppc, POWER8, armv7, armv8, or aarch64, KVM and libvirt are ported and work. | 10:23 |
| persia | If you have POWER7 or armv6, there is only partial support. | 10:23 |
| * persia doesn't know the state of KVM/libvirt for MIPS | 10:24 | |
| persia | pedroalvarez: So, if you don't want to try to spin up an entire cloud, you just run libvirtd somewhere, and then talk to it over the network. | 10:24 |
| pedroalvarez | kvm in a jetson sould work, then? | 10:25 |
| persia | Yep. | 10:25 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:25 | |
| persia | I haven't tested it (my infrastructure is still mostly in boxes), but the code is published, and I've seen it demoed on similar chips. | 10:25 |
| pedroalvarez | sounds good | 10:26 |
| paulsher1ood | pedroalvarez: 3392s x86 vs 1048s armv7 ? | 10:32 |
| pedroalvarez | arm only had to build 9 artifacts, and x86 139 | 10:33 |
| persia | cache differences? | 10:34 |
| pedroalvarez | erm.. this is odd | 10:35 |
| pedroalvarez | lorry and baserock-import strata depend on morph-utils. morph-util changed, that's why x86 rebuilt 139 artifacts, but this didn't happen on arm | 10:38 |
| * pedroalvarez forces mason-arm to re-test, and see if it still thinks it doesn't need to rebuild anything | 10:40 | |
| ssam2 | maybe someone else is using the ARM distbuild network ? | 10:41 |
| ssam2 | and already built the commit that was merged to master? | 10:41 |
| pedroalvarez | maybe... | 10:42 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 10:42 | |
| pedroalvarez | but then, why morph artifact wasn't in the cache? :P | 10:43 |
| franred | pedroalvarez, are they in the cache now? | 10:47 |
| pedroalvarez | distbuild thinks that they are, and morph has build the system artifact, so they should be in the cache | 10:48 |
| perryl | hi everyone, can someone clarify if we are still using gitano as a git server or if we have/are planning to move towards gerrit? | 10:50 |
| persia | We're still using gitano for git.baserock.org at the moment. | 10:51 |
| ssam2 | I'm not sure if anyone is actively working on moving to Gerrit | 10:52 |
| ssam2 | SotK might be | 10:52 |
| SotK | I'm not | 10:52 |
| persia | I have been advocating a move to gerrit for some time, because I like pre-merge CI, and gitano doesn't have facilities to support that at the moment, but others have pointed out that gitano is trusted, whereas one can corrupt gerrit history by spoofing the database. | 10:52 |
| persia | There's a gerrit in definitions master: I don't think anyone configured it in a way to be gerrit.baserock.org or git.baserock.org, but it does produce a gerrit. | 10:53 |
| pedroalvarez | perryl: does your work depends on what git server we use? | 10:53 |
| perryl | pedroalvarez: not as of yet; it's the firehose work and it should not depend on a particular git server | 10:54 |
| pedroalvarez | that's exactly what I was going to say, it shouldn't depend on any particular git server. We should move into that direction | 10:54 |
| perryl | however with the testing infrastructure Firehose can certainly make use of it | 10:55 |
| persia | I believe it does depend on the git server. Different git server implementations have different means by which one submits candidates. Might be a candidate push, might be a pull request, might be a patch series sent to a mailing list, etc. | 10:55 |
| persia | Be nice to have plugins for this, but it makes sense to prioritise the common case. | 10:55 |
| persia | The problem being that gitano doesn't have any recommended mechanism for the submission of candidates (so one ends up needing to manage one's own tree of branches for features). | 10:56 |
| ssam2 | i'm not sure that's a problem, I don't find it hard to name branches | 10:57 |
| ssam2 | it's a little annoying that not everyone deletes their feature branches after they have been merged to master | 10:57 |
| ssam2 | is that something Gerrit takes care of for you ? | 10:57 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:58 | |
| persia | In gerrit, when you push to a branch, it automatically generates a candidate branch, which is automatically deleted when merged to master. | 10:58 |
| persia | Or, rather, merged to the branch to which you originally pushed. | 10:58 |
| ssam2 | right. I guess that's handy (but then Gerrit forces you to remember to add a magic token to your commit message, if I understand correctly, so there's faff required either way) | 10:59 |
| persia | Rather, gerrit automatically adds a magic token, so your local commit doesn't actually match the one on the server. | 11:00 |
| perryl | ssam2: IIRC gerrit automatically adds a SHA1 to the commit message, i don't think there's anything manually added | 11:00 |
| persia | You may add one yourself, but this is only done when yu want to override an existing candidate, rather than create a new one. | 11:01 |
| SotK | persia: I thought you had to add that before pushing? | 11:01 |
| richard_maw | I thought you had to use their git hook to get the automatic token? | 11:01 |
| SotK | richard_maw: that is what I've always had to do | 11:01 |
| SotK | otherwise pushing gives an error due to lack of said magic token | 11:01 |
| * persia may misunderstand the implementation | 11:02 | |
| ssam2 | my understanding was v1 of your branch doesn't need a token but v2 and all subsequent versions do. But I could well be wrong. | 11:02 |
| ssam2 | or rather, gerrit automatically adds the token to v1 | 11:03 |
| * persia shared ssam2's understanding | 11:03 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 11:03 | |
| franred | all the versions need the token to be reviewed, at least when I looked into it | 11:03 |
| *** rdale_ [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has quit [Ping timeout: 245 seconds] | 11:10 | |
| *** rdale [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has joined #baserock | 11:11 | |
| persia | straycat: Could you help me understand the difference between an identity test and an equality test? | 11:13 |
| petefoth | How can I determine the identity of this commiter to w.b.o - committer: admin <admin@branchable.com> ? | 11:22 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 258 seconds] | 11:22 | |
| petefoth | Ihttp://wiki.baserock.org/recentchanges/ shows the name as ‘dev’ which isn’t very helpful :) | 11:23 |
| Kinnison | petefoth: It's auto-commits created during pushes | 11:23 |
| persia | petefoth: You'd need to dig into the Author: entry, and cause the identity provider to share a name | 11:23 |
| Kinnison | petefoth: E.g. if you tag something with a new tag, then admin@branchable.com will commit a new tag page if there isn't one | 11:23 |
| * Kinnison goes back to his holiday | 11:23 | |
| petefoth | but this has real diffs | 11:24 |
| persia | It also happens for web edits. | 11:24 |
| petefoth | looking at the other commits by dev, I suspect radiofree_ | 11:25 |
| pedroalvarez | I know who he is :) | 11:25 |
| persia | I believe the current editor to be paulsher1ood, based on content, but it could be an imposter, as I have no basis for my belief other than the content and opinion of the production of that individual | 11:25 |
| pedroalvarez | devcurmudgeon | 11:25 |
| petefoth | pedroalvarez: that’ll be the man - thanks! | 11:26 |
| * straycat wonders whether http://sprunge.us/JQIi | 11:27 | |
| straycat | is more useful behaviour | 11:27 |
| straycat | Currently it's quite confusing if you're an extension wanting to handle a sigint | 11:27 |
| straycat | I've been confused at least | 11:28 |
| persia | The counterargument is that it is the only guard against runaway extensions | 11:28 |
| straycat | I'm not sure I agree, I can ignore the sigterm morph sends, and morph will be forced to wait. | 11:29 |
| persia | Ah, hrm. | 11:29 |
| richard_maw | so morph should send sigkill? | 11:29 |
| straycat | Morph probably shouldn't be waiting | 11:29 |
| straycat | morph shouldn't send anything | 11:29 |
| persia | If the process isn't stopped, I'm not sure it is ideal to close the output, but don't really understand the implications. | 11:29 |
| straycat | or, well, maybe it should but only after a given amount of time | 11:30 |
| pedroalvarez | ok, nothing is wrong with mason armv7. we are building the devel system in x86, and the build system in arm | 11:32 |
| persia | So, if an exception happens, and morph doesn't kill the extension, but just begins to ignore it, what sort of problems can this cause? | 11:32 |
| richard_maw | sounds like perhaps we should be running extensions with systemd-run, since it handles a lot of painful service stuff for you | 11:32 |
| persia | pedroalvarez: Ah. Can we build the devel system everywhere? | 11:32 |
| pedroalvarez | yes, I did that change and I still don't know why i decided to put the build system instead of the devel one | 11:33 |
| pedroalvarez | silly me | 11:34 |
| persia | Verbose commit messages are a critical component to keeping a clear mind :) | 11:34 |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 11:34 | |
| straycat | Is my current solution acceptable or would we prefer to wait for some amount of time then send a sigkill? | 11:35 |
| persia | I don't understand the best option re; morph kills vs. morph ignores, but I don't like the current solution because it closes the output and doesn't stop the process, which seems wrong to me. If the process is continuing, should the output not be left open? | 11:36 |
| straycat | richard_maw, I don't enough about systemd to comment | 11:36 |
| persia | Or would morph ignore it anyway, so it doesn't matter that it is closed? | 11:36 |
| straycat | I'm not sure the output is relevant given it's all being captured by this asynccore loop which we've exited by the time we have an exception | 11:37 |
| radiofree_ is now known as radiofree | 11:38 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Quit: Bye] | 11:38 | |
| persia | Ah, OK. So safe to close then. | 11:38 |
| straycat | persia, "a is b" is id(a) == id(b), so "'foo' is 'foo'" may well be True, but probably dependant on the python implementation, so it's best just to use == for comparing equality. | 11:41 |
| persia | OK. When reading about this, I had the impression that "in" also used an identity test. Do I need to set up a list of comparisons using "=="? | 11:42 |
| richard_maw | AIUI "in" depends on the implmentation of the container, but for most primitive types it's an equality test, so `"foo" in ("fo" + "o", "bar")` is true | 11:44 |
| persia | The goal is to ensure that short strings contain the same sequence of characters. | 11:45 |
| persia | And I'd prefer to construct it in a way that allows the list of comparable strings to be extended over time because some folk aren't careful about ISA backwards compatibility. | 11:46 |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 11:46 | |
| persia | So is (var1 == "foo" and var2 in ("bar", "baz", "quux")) the right way to do this? | 11:47 |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Client Quit] | 11:47 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 11:47 | |
| * straycat nods | 11:47 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Client Quit] | 11:48 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 11:48 | |
| straycat | richard_maw, Do you have a suggestion for an immediate solution to the above problem? I could hack my extension but I feel that can be avoided easily enough. | 11:49 |
| richard_maw | I'm missing context, what do you need to handle sigint for? | 11:50 |
| straycat | I don't think I do really, but if I did need to it would be more difficult than it needs to be right now, imo. | 11:52 |
| richard_maw | well, as I recall, the point of calling .wait() was so that it would be possible to get the return code of the process, but .poll() may be more appropriate for that, and if we're terminating, then the return code isn't useful anyway | 11:55 |
| richard_maw | I'd be tempted to suggest we just replace .terminate with .kill | 11:55 |
| straycat | Why? | 11:56 |
| straycat | That doesn't allow the extension to do any cleanup? | 11:57 |
| richard_maw | hm, which is unfortunate since we can't tie all resource cleanup with process exit | 11:58 |
| pedroalvarez | persia: I lied in the commit message this time: http://paste.baserock.org/tugacupafi | 12:00 |
| * richard_maw wants to rewrite morph to use O_TMPFILE and whatever the current flavour of flink() is whenever it needs to write files | 12:01 | |
| richard_maw | but terminate, wait a bit then kill sounds like the most reasonable option for ensuring processes don't run away | 12:02 |
| radiofree | how come the baserock paste stuff doesn't show up in the preview window in quassel? | 12:02 |
| radiofree | i get the ui, but no content | 12:03 |
| persia | pedroalvarez: heh | 12:03 |
| richard_maw | radiofree: sounds like too much javascript to me | 12:03 |
| persia | Yep. Quassel prevew doesn't run any authentication or javascript | 12:04 |
| radiofree | ah | 12:05 |
| pedroalvarez | radiofree: can you preview this? http://paste.baserock.org/raw/tugacupafi | 12:05 |
| robtaylor | on is vs ==, http://stackoverflow.com/questions/2988017/string-comparison-in-python-is-vs | 12:05 |
| radiofree | that's even worse pedroalvarez :\ | 12:05 |
| radiofree | just comes up as a black square | 12:06 |
| straycat | richard_maw, sounds good to me :) | 12:06 |
| pedroalvarez | radiofree: works in my quassel client :P | 12:06 |
| robtaylor | pedroalvarez: if you want to test the initial substring, use .startswith() | 12:06 |
| robtaylor | uuk i mean | 12:06 |
| robtaylor | persia: if you want to test the initial substring, use .startswith() | 12:06 |
| * robtaylor notes that he's a terrible python programmer though, so my advice may not be the best.. | 12:07 | |
| persia | robtaylor: I don't. I just mostly develop in C and make, for which string comparisons cannot test equality, so the use of == for strings is foreign to me. | 12:07 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 240 seconds] | 12:07 | |
| robtaylor | persia: i use 'is' myself, it looks better ;) | 12:08 |
| robtaylor | and is perfectly correct for builtins | 12:08 |
| * persia is now confused, having been told to change the patch and not change the patch | 12:09 | |
| straycat | "For all built-in Python objects (like strings, lists, dicts, functions, etc.), if x is y, then x==y is also True" | 12:09 |
| straycat | Oh okay | 12:09 |
| persia | I know it works for the python implementation in the baserock devel system, but I don't want to do things that would interfere with my dream of running morph in arbitrary environments. | 12:09 |
| straycat | but then "Not always. NaN is a counterexample. But usually, identity (is) implies equality (==). The converse is not true: Two distinct objects can have the same value." | 12:10 |
| straycat | So, can we avoid all this confusion and just use == when testing for equality? :) | 12:10 |
| robtaylor | oh, hangon | 12:12 |
| robtaylor | no i'm wrong and straycat is right (and the link i posted is wrong) | 12:12 |
| straycat | yes | 12:12 |
| straycat | that was very confusing :p | 12:12 |
| robtaylor | The operators is and is not test for object identity: x is y is true if and only if x and y are the same object. x is not y yields the inverse truth value. [7] | 12:13 |
| persia | Right then. I'm no longer confused, and just have to fight with git a bit. | 12:13 |
| robtaylor | :) | 12:14 |
| robtaylor | persia: git commit --amend or a git rebase -i :) | 12:14 |
| persia | The problem is not that, but that master moved, and I accidentally merged, so have to go unmerge, which is a bit more than rebase -i (but not much more). | 12:15 |
| radiofree | don't forget to remove the rouge whitespaces as well persia | 12:16 |
| robtaylor | persia: i think rebase -i will still do the job :) | 12:16 |
| persia | radiofree: Which ones? | 12:16 |
| radiofree | if ( root_arch != host_arch | 12:16 |
| persia | Those aren't rogue: those are intentional to make things line up nicely. | 12:17 |
| persia | I was previously told that causing python to be pleasant to read was a good thing. | 12:17 |
| robtaylor | persia: that's a bit non idiomatic tbh | 12:17 |
| radiofree | line up nicely how? | 12:17 |
| persia | All the conditions start from the same point, and the "and"s fall off to the left | 12:18 |
| radiofree | i think you've gone rouge with your coding style then | 12:18 |
| radiofree | erm.. rogue... | 12:18 |
| * richard_maw tends to leave the "and"s trailing at the end | 12:19 | |
| persia | richard_maw: The reason I don't like that is because one has to modify more lines when patching a set of conditionals, causing extra diff in patches. | 12:19 |
| persia | But I'll take guidance on morph style, as I'd prefer my code not to stand out exceptionally. | 12:20 |
| persia | Are the parentheses good, or should I structure the logic to not need them? | 12:20 |
| richard_maw | go for what you think is the most readable, as a rough guideline, I think shorter is more readable | 12:21 |
| robtaylor | radiofree: is your codeing style rouge? ;) | 12:21 |
| persia | shorter involves parentheses, which also helps separate things for human comprehension (long lists of multiply negated booleans annoy humans, in my experience) | 12:23 |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 12:23 | |
| robtaylor | persia: parenthesis for logic comprehension is certainly a good thing | 12:24 |
| * richard_maw prefers parenthesis in general, since he can never remember operator precedence | 12:25 | |
| robtaylor | persia: this would be more idiomatic: http://ix.io/frp | 12:26 |
| jmacs | richard_maw: and quite likely neither can the next person reading it. | 12:26 |
| persia | It isn't just precedence: with short-circuiting, one can construct expressions that humans don't read the way compilers read. | 12:26 |
| richard_maw | robtaylor: you'd need to put paranthesis after the if when you're doing multi-line expressions | 12:26 |
| jmacs | persia: I'd consider calculating some of those terms into meaningfully named variables before the if. | 12:27 |
| persia | robtaylor: My main issue with that is the lack of indentation between the last "and" and the "raise", which makes it hard for me to read. | 12:27 |
| richard_maw | the alternative is \ continuation markers at the end of the line, which I'm generally against it's too easy to put whitespace after the \ and spoil it | 12:27 |
| robtaylor | i think better would be if _arch_compatible(root_arch,host_arch) ;) | 12:28 |
| persia | jmacs: Why? You never care about them except when root_arch != host_arch, which should be true most of the time for most users. The only exception is folk running armv8 who are building armv7 stuff in linux32 chroots. | 12:28 |
| robtaylor | and put clear logic in def _arch_compatible() | 12:28 |
| * persia learned make mostly to avoid adding \ in makefiles when implementing logic in shell | 12:29 | |
| jmacs | persia: I'm quite sure the compiler/interpreter can work out that it won't need to calculate the values if root_arch != host_arch | 12:29 |
| persia | jmacs: Hrm? If I set an assignment earlier, Python doesn't evaluate it until I use the assigned expression? | 12:29 |
| * robtaylor notes he is bikeshedding somewhat and gets back to systemd patches | 12:30 | |
| * persia wonders how one is intended to trigger side effects | 12:30 | |
| jmacs | I'm bikesheeding as well | 12:30 |
| jmacs | bikeshedding | 12:30 |
| persia | To a certain degree, the entire conversation could be described that way. The patch as submitted works. We're just trying to get the colour to match the rest of the code. | 12:31 |
| robtaylor | persia: a function to tell you archs are compatible would document what's going on nicely | 12:32 |
| persia | Yes. Of the suggestions, that is very appealing. | 12:33 |
| * robtaylor tends to view multiline ifs like too many indents - a clue you should spin out a function | 12:33 | |
| persia | But I was intrigued by the potential implications of lazy evaluation, and thought that might also be useful | 12:33 |
| * persia has spent lots of time in C removing functions in favour of multiline ifs, for optimisation | 12:34 | |
| rjek | I format C to no wider than 80 columns and 8 stop tabs because it forces to to rip stuff out | 12:34 |
| paulsher1ood | petefoth: i confirm some of my web commits have been named as 'dev' - why were you chasing this? | 12:34 |
| rjek | static inline functions are cheap | 12:34 |
| persia | rjek: I prefer 74 characters, so you can argue about it on a mailing list | 12:35 |
| rjek | persia: >:) | 12:35 |
| persia | static inline functions are cheap, but I've saved thousands of seconds in execution time by removing them :) | 12:35 |
| * persia goes back to learning how to return a value from a python function | 12:35 | |
| rjek | Your compiler is inadaquate! | 12:35 |
| persia | Yeah, well, gcc | 12:35 |
| petefoth | paulsher1ood: I look at the RSS feed of changes on w.b.o everyday - I was just wondering who had made those change. No ulterior motive :) | 12:35 |
| paulsher1ood | :) | 12:36 |
| rjek | If a static inline has only one call site, GCC basically always inlines it, so they're free at runtime | 12:36 |
| persia | If a function is declared static inline, any compiler that doesn't inline it every time is failing to comply with the standard. That said, the way in which it is inlined is not always optimial. | 12:37 |
| rjek | inline is an suggestion, IIRC. | 12:37 |
| persia | If one merges logic from several different functions, and applies boolean reduction, one can usually obtain faster execution. This is not a useful goal in Python: it's supposed to be optimised for human comprehension. | 12:37 |
| rjek | And GCC hoists the parse tree in (at least since something like 3.4) so it's as good as copy-and-past | 12:38 |
| persia | Yes, which is not as good as boolean reduction | 12:38 |
| rjek | I think if you're expecting blazing performance, Python is probably not your first point of call. Python's great for experimentation, high-level design, and glue though | 12:38 |
| persia | yes | 12:39 |
| * petefoth notes that .write and .check files include copyright headers but .write.help file don’t. Is that deliberate (because they are YAML, and YAML doesn’t allow comments, or for some other reason?) or shoudl they be added | 12:41 | |
| richard_maw | yaml allows comments, we could put them it, we just haven't | 12:42 |
| richard_maw | I don't know if we should | 12:43 |
| petefoth | richard_maw: thanks. | 12:43 |
| petefoth | richard_maw: neither do I. Nor do I know whether we should have copyright (and licence) information in the markdown files we use to populate the wiki | 12:44 |
| persia | wiki content should be licensed somehow, and we should sort that. Relicensing the wiki is a project I've seen done in a few communities, and it's best done early, so that one can reach all the authors. | 12:49 |
| petefoth | persia: would you go for one of the Open Source licences for the wiki, or one of the Creative Commons licences as the wiki isn’t really code? | 12:58 |
| persia | I've generally seen folk use CC licenses for wiki content, with a exception that any content specifically otherwise licensed is under the specific license (and a list of acceptable licenses). | 12:58 |
| persia | Because some folk like to put code snippets in the wiki, and label them MIT, ISC, GPL, etc. (depending on the source) | 12:59 |
| persia | Note that it is wise to avoid anything that prevents commercial use: at least I want to be able to use the wiki content commercially, and suspect others do as well. | 12:59 |
| petefoth | persia: indeed. | 13:00 |
| radiofree | if i build an arm rootfs can i upload it to baserock.org? | 13:01 |
| radiofree | it's for http://wiki.baserock.org/guides/baserock-cb5-311/?updated | 13:01 |
| paulsher1ood | radiofree: can't the ci generate one? | 13:02 |
| radiofree | pedroalvarez: ? | 13:02 |
| persia | The answer will be yes, but we aren't using the CI-generated images for anything: we throw them away (as discussed a few hours back). | 13:02 |
| pedroalvarez | indeed | 13:03 |
| persia | So the best way to cause one to exist is to cause it to be distbuilt, and then have one of the infra team copy it to download.baserock.org | 13:03 |
| radiofree | well it's probably easier for me to just build in on a jetson and upload it | 13:03 |
| radiofree | i can upload to download.baserock.org | 13:03 |
| paulsher1ood | persia: i thought they landed at cache.baserock.org? | 13:05 |
| persia | radiofree: Ah, if you have super powers, then don't let me stop you. | 13:05 |
| persia | paulsher1ood: The system artifacts end up there: those are not the samoye as the download artifacts at download.baserock.org: the download artifacts are post-depl | 13:06 |
| paulsher1ood | radiofree: is that true? for the chromeboook, do you need a rootfs as created by build, or does yours have rfurther processing | 13:07 |
| radiofree | paulsher1ood: it's nothing magic | 13:08 |
| radiofree | i used a jetson image deployed as a tarball | 13:08 |
| radiofree | i'll send another patch to add the tarball to release | 13:09 |
| radiofree | i want to create a file in a folder after the image has been built | 13:26 |
| radiofree | this is a configuration-extension right? | 13:27 |
| radiofree | where do they live? | 13:27 |
| radiofree | i want to submit one to create the required file for crouton | 13:28 |
| paulsher1ood | couldn't this be just done as a morph build + deploy, then? | 13:30 |
| persia | If it is system-specific, they usually live in definitions. If you want a generic one, it is in morph | 13:30 |
| radiofree | well, in my instructions it says "download the rootfs, extract, then do "echo baserock > etc/crouton/name" | 13:31 |
| persia | paulsher1ood: It depends: if you don't start with a chroot, how do you do the build+deploy? | 13:31 |
| paulsher1ood | ok, that's easier | 13:31 |
| radiofree | for crouton to work you need that file in /etc/crouton | 13:31 |
| * paulsher1ood shuts up | 13:31 | |
| radiofree | apparently configuration-extensions are in morph | 13:31 |
| radiofree | that's.... not right? | 13:31 |
| persia | There's two sets. See gerrit.configure for an example of one in definitions. | 13:32 |
| petefoth | where a write extension allows an UPGRADE parmeter, will morph deploy fail if no VM already exists at the specified location, or will it go ahead and create a new VM? | 13:32 |
| radiofree | ah | 13:32 |
| radiofree | that's fine then | 13:32 |
| radiofree | i suppose ones in morph are the generic ones | 13:32 |
| persia | Right. | 13:32 |
| *** rdale_ [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has joined #baserock | 13:35 | |
| *** rdale [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has quit [Ping timeout: 272 seconds] | 13:35 | |
| radiofree | running morph gc | 13:44 |
| radiofree | 2014-12-02 13:44:35 Removing temp subdirectory: failed | 13:44 |
| radiofree | oh wait | 13:44 |
| radiofree | never mind | 13:45 |
| vmesons is now known as vmeson | 13:45 | |
| radiofree | that's removing a temporary subdirectory called "failed", not that the "removing temp subdirectory" command has failed | 13:45 |
| *** vmeson [~quassel@128.224.252.2] has quit [Quit: vmeson] | 13:46 | |
| persia | heh. That is indeed a confusing message. | 13:47 |
| paulsher1ood | yes. i tried to get this whole thing undone. the directory should be left as staging | 13:49 |
| paulsher1ood | we shouldn't be moving stuff to 'failed' | 13:49 |
| richard_maw | we do that so that we know that it _could_ be removed to save space | 13:50 |
| richard_maw | if everything was left in the staging directories directory, you wouldn't know which ones are currently being used to build | 13:50 |
| persia | Can we track that differently? Finding "failed" has been confusing to me repeatedly (even after it was explained to me) | 13:51 |
| robtaylor | is it just a matter of changing the message? | 13:52 |
| richard_maw | couldn't we just improve the mssage to say that the directory is named failed, or call it something else? | 13:52 |
| richard_maw | s/mssage/message/ | 13:52 |
| persia | improving the message is the key thing. | 13:52 |
| paulsher1ood | staging directories *can* be removed to save space anyway, richard_maw. staging is non-permanent by convention | 13:52 |
| persia | I think we already changed the output message when things failed telling the user to go look in failed. | 13:52 |
| persia | paulsher1ood: Yes, but removing during a build breaks things. | 13:52 |
| richard_maw | paulsher1ood: yes, but we need a way to track which ones are in use, so `morph gc` doesn't just remove them during a build | 13:52 |
| richard_maw | this is currently done by moving failed builds out of the way | 13:53 |
| robtaylor | persia: ah, so what's causing you to look in staging? | 13:53 |
| paulsher1ood | what runs 'morph gc' besides a user? | 13:53 |
| persia | robtaylor: Older messages (unless I'm wrong: I haven't worked with code that didn't compile in a while) | 13:53 |
| richard_maw | cycle.sh to start with | 13:54 |
| robtaylor | paulsher1ood: there's nothing stopping your running morph gc while a build is happening | 13:54 |
| paulsher1ood | richard_maw: which is run by ujser | 13:54 |
| robtaylor | (and indeed if you see you're runnig out of space during a build, that may well be a useful thing to do..) | 13:54 |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 13:54 | |
| paulsher1ood | robtaylor: there's nothing to stop me running rm -fr / either | 13:54 |
| richard_maw | yes, but it's indirect, you might be running a build for one thing and then while you're waiting, decide that you want to update the software you're running | 13:54 |
| robtaylor | paulsher1ood: that isn't useful | 13:54 |
| paulsher1ood | robtaylor: morph build refuses to run if there isn't enough space | 13:55 |
| jjardon | petefoth: FYI, in GNOME we recently changed all the documentation to Creative Commons license CC-BY-SA 3.0 https://wiki.gnome.org/DocumentationProject/Guide/Licensing | 13:55 |
| ssam2 | paulsher1ood: I'm lacking context, but distbuild runs 'morph gc' before each build | 13:55 |
| paulsher1ood | robtaylor: the point is 'morph gc' has to be run *before* build | 13:55 |
| robtaylor | paulsher1ood: ok, so you'd need to add some sort of lockfile, but that'd work | 13:55 |
| paulsher1ood | ssam2: i'm not surprised. i asked for mrph build to run it by default | 13:56 |
| jjardon | (from GNU Free Documentation License (GFDL)) | 13:56 |
| robtaylor | jjardon: that's good | 13:56 |
| petefoth | jjardon: thanks | 13:56 |
| ssam2 | paulsher1ood: that'd have performance implications, but i don't know if they'd be at all serious | 13:56 |
| jjardon | well recently, when GNOME 3.0 was released | 13:57 |
| paulsher1ood | ssam2: it only *does* stuff if it needs to. | 13:57 |
| ssam2 | paulsher1ood: so it does, I often forget that | 13:58 |
| paulsher1ood | if it's not run, build sometimes refuses to run. that's a *much* bigger perf hit | 13:58 |
| * paulsher1ood despairs some times | 13:58 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 13:59 | |
| * paulsher1ood is obviously still smarting at the 'make cycle.sh bulletproof' discussion :) | 13:59 | |
| *** Guest40361 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 14:02 | |
| persia | I don't think it needs to be bullet-proof, I just didn't want it to surprise me or make me puzzle out how much to quote. | 14:02 |
| persia | And then, when I thought about it, I came to the conclusion that we shouldn't need an external script to do this, but that we should fix the tool so this is trivial. | 14:03 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:04 | |
| richard_maw | perhaps we should work backwards from our ideal UI of how it should work | 14:04 |
| straycat | Oh, so pip doesn't seem to kill any compilers it might run when it's interrupted. :/ | 14:06 |
| persia | straycat: Nope, which is almost as annoying as silently killing things. | 14:06 |
| persia | richard_maw: I suspect you are right, and keep meaning to submit some description of that to the wiki, but never get to it | 14:07 |
| richard_maw | it may be that we should have it read data in /baserock to work out how it was previously deployed, and allow you to make changes, such as which system morphology, on the command-line | 14:11 |
| straycat | Right, so I guess it's fair to accept that if the import tool is interrupted during a python package import then compilers may be left running on the system. | 14:11 |
| persia | It would be nice if we had a way to clean up, but yeah, that should be done (or not) in pip, not the import tool. | 14:14 |
| * straycat nods | 14:14 | |
| *** rdale_ [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has quit [Ping timeout: 240 seconds] | 14:26 | |
| *** rdale [~quassel@host86-143-211-156.range86-143.btcentralplus.com] has joined #baserock | 14:26 | |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:34 | |
| mike is now known as Guest85678 | 14:34 | |
| radiofree | arm rootfs uploaded http://download.baserock.org/baserock/build-system-armv7lhf-rootfs.tar.gz | 14:39 |
| persia | Would it benefit from testing? | 14:40 |
| radiofree | sure | 14:50 |
| * straycat tries to import persistent pineapple | 14:52 | |
| pedroalvarez | straycat: would you be able to import django? | 14:57 |
| pedroalvarez | just saying because I'd find it really useful :) | 15:03 |
| straycat | Okay I'll try that | 15:03 |
| pedroalvarez | :D :D ;D | 15:03 |
| petefoth | Is the RAM_SIZE parameter permitted / applicable for the OpenStack write extension? | 15:05 |
| persia | radiofree: Unpacking into a chroot gives me an apparently working chroot. Thanks! | 15:06 |
| pedroalvarez | petefoth: nope | 15:06 |
| petefoth | pedroalvarez: Thanks I’ll go and edit http://wiki.baserock.org/devel-with/#index5h2 then | 15:07 |
| *** Guest85678 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 15:07 | |
| petefoth | what about KERNEL_ARGS? | 15:07 |
| pedroalvarez | petefoth: yep | 15:08 |
| straycat | pedroalvarez, http://sprunge.us/ULaA was the stratum that got generated, somehow I figure we could do better than a tarball lorry of django | 15:08 |
| pedroalvarez | i was expecting to see loads of dependencies | 15:09 |
| pedroalvarez | (but I don't know how this import tool works :/ ) | 15:10 |
| pedroalvarez | thsnks! :) | 15:10 |
| petefoth | pedroalvarez: ooops - what about DISK_SIZE? | 15:10 |
| straycat | I thought it just needed python? | 15:10 |
| persia | That's what upstream claims. | 15:10 |
| persia | "[Django] requires Python version 2.7 or higher, but is has no dependencies on other Python libraries." | 15:11 |
| straycat | persia, The python stuff has't been merged into master of the import tool yet either, so it might be a little difficult for you to use :3 | 15:12 |
| straycat | s/persia/pedroalvarez/ | 15:12 |
| straycat | sorry | 15:12 |
| persia | No worries. I'm also interested :) | 15:12 |
| pedroalvarez | I was really interested because I thought that importing Django was going to be more dificult :) | 15:13 |
| * straycat gets back on with persistent pineapple | 15:14 | |
| *** Guest85678 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:20 | |
| *** flatmush1 [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:30 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 15:31 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [] | 15:31 | |
| paulsher1ood | pedroalvarez: afaik i did django as a chunk ages ago... it was trivial | 15:35 |
| pedroalvarez | paulsher1ood: why is not merged!!! | 15:36 |
| pedroalvarez | :) | 15:36 |
| paulsher1ood | pedroalvarez: because i'm petulant? :) | 15:36 |
| pedroalvarez | hah, I don't like petulant contributors!! | 15:37 |
| paulsher1ood | actually, i can't remember. i think it was a chunk on the road to something i failed to finish, therefore did not push | 15:37 |
| richard_maw | now play nice everyone | 15:37 |
| pedroalvarez | looks trivial, indeed. I think that it would be a nice thing to have | 15:38 |
| persia | Is http://wiki.baserock.org/guides/how-to-cross-bootstrap/ up-to-date? | 15:39 |
| pedroalvarez | it's missing some steps before calling chroot in various places I belive | 15:41 |
| pedroalvarez | apart from that, i think that is up-to-date | 15:41 |
| persia | OK. Next, how would I go about causing the armv7lhf distbuild cluster to create a chroot system I can deploy? | 15:42 |
| * persia is unable to compile in a hacked-up chroot, because "/ is not a mountpoint", and wants to deploy a proper baserock chroot | 15:43 | |
| pedroalvarez | didn't this fixed the problem? http://wiki.baserock.org/guides/build-failures/#index5h2 | 15:44 |
| *** Guest85678 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 15:45 | |
| *** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:45 | |
| persia | That wasn't my error message, but I'll try that. | 15:47 |
| pedroalvarez | If that didn't solve your problem I'd need more context to help you :) | 16:04 |
| * persia has yet to reproduce the problem | 16:05 | |
| persia | This is a good sign, enough so that I'm not tempted to go make my chroot behave the old way :) | 16:05 |
| persia | MInd you, I have yet to build anything, because morph is currently apparently hanging trying to fetch a cache object, but that is unikely to be related. | 16:06 |
| pedroalvarez | persia: if you can run `linux-user-chroot / /bin/sh` inside of the chroot environment, then the problme is fixed | 16:07 |
| persia | OK. I'll try that when morph exits. | 16:07 |
| pedroalvarez | if it does :) | 16:08 |
| persia | Good point :) | 16:08 |
| persia | OK. When I run `mount --bind . .` followed by `linux32 chroot . /bin/bash`, I can get the error message mentioned on the wiki. | 16:11 |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 16:11 | |
| persia | Note that this differs from the error morph gave me. | 16:11 |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:11 | |
| * persia tries morph build again, in the bind-mounted chroot | 16:11 | |
| paulsher1ood | pedroalvarez: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/ps/add-haproxy-django&id=b31d3f1763a856a6afd48649f473379e230348e9 | 16:13 |
| paulsher1ood | (assuming http://paste.baserock.org/ogigutotat) | 16:13 |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 16:16 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Changing host] | 16:16 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 16:16 | |
| pedroalvarez | paulsher1ood: nice! thanks! | 16:16 |
| persia | And now I get "mount: / is not mountpoint or bad option" | 16:26 |
| persia | (from morph) | 16:26 |
| persia | mount tells me /dev/disk/by-uuid/d31509a5-d56f-4ad5-9fd1-11208142ba1d on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) | 16:27 |
| persia | (presumably the result of having run the bind mount). I also have /proc and /sys | 16:27 |
| richard_maw | at which point of running morph is it complaining? | 16:27 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:28 | |
| persia | http://paste.baserock.org/osejaguyun.cs has the terminal log: I've cut out the uninteresting bit | 16:30 |
| richard_maw | I'd guess it's the `mount --make-rprivate /` then | 16:31 |
| richard_maw | this happens now because we make a new mount namespace then mount /dev/shm | 16:33 |
| persia | Running that command indeed replicates the error | 16:33 |
| richard_maw | it worked previously, so it may be that linux-user-chroot is able to handle that | 16:35 |
| persia | It may also be something about my environment. | 16:35 |
| persia | But I don't know how to tell the difference. | 16:36 |
| persia | Does this require special kernel support? I appear to be running an Ubuntu kernel on this machine. | 16:37 |
| richard_maw | I don't think so, are you able to run linux-user-chroot normally? I believe it uses the same syscalls | 16:38 |
| richard_maw | ah, but that would require linux-user-chroot on the system outside the chroot, wouldn't it | 16:38 |
| richard_maw | if `mount --make-rprivate /` works outside the chroot then it's unlikely to be a kernel issue | 16:39 |
| robtaylor | could be a syscall issue, but i hope it isn't | 16:39 |
| persia | How would I undo `mount --make-rprivate /` if I run it outside the chroot? | 16:39 |
| richard_maw | run `findmnt -o TARGET,PROPAGATION` to work out what the mount propagation is currently at | 16:41 |
| richard_maw | then when you want to put it back run `mount --make-$propagation $target` | 16:41 |
| richard_maw | though PROPAGATION wasn't a recognised option for findmnt in my debian system, so I don't know if the version in ubuntu is recent enough for that output format | 16:42 |
| richard_maw | I'll check if there's another way to get that information out | 16:42 |
| richard_maw | hm, no, if you've got a findmnt that old, you need to get the propagation out of /proc/self/mountinfo yourself | 16:43 |
| richard_maw | though the kernel I'm running is too old to report that! | 16:44 |
| richard_maw | if when you cat /proc/self/mountinfo you have an extra field after the mount options and before the -, then you can know what the mount options are | 16:45 |
| persia | findmnt: unknown column: PROPAGATION | 16:45 |
| richard_maw | ok, how about `awk '{print $5, $7}' /proc/self/mountinfo` | 16:45 |
| persia | List of all my mountpoints, with a siyngle hyphen after each. | 16:47 |
| richard_maw | bah, kernel's too old to report propagation, and userland wouldn't know what to do with it even if it did! | 16:47 |
| persia | 3.13.0-40-generic | 16:48 |
| richard_maw | hm, must be some kernel option not enabled then | 16:48 |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:48 | |
| richard_maw | mount propagation defaults to shared, so you can put it back to its ideal state with `mount --make-rshared /` | 16:48 |
| persia | OK | 16:49 |
| *** flatmush1 [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 16:50 | |
| persia | No errors from running `mount --make-rprivate /` followed by `mount --make-rshared /` | 16:50 |
| persia | (outside the chroot) | 16:50 |
| richard_maw | hm, then it must not be recognising / as a mount-point, and I'd assumed that your `mount --bind . .` would've done that | 16:50 |
| richard_maw | when running `findmnt` outside of the chroot, does it list the chroot? | 16:50 |
| persia | yes | 16:51 |
| richard_maw | I'm running out of ideas then, does `findmnt` show it when inside the chroot? | 16:52 |
| persia | err, I'm not actually running findmnt: I'm using awk on /proc/self/mountinfo | 16:53 |
| richard_maw | there's no magic configure options to turn on listing propagation in /proc/self/mountinfo AFAICT, I just know it's unconditionally printed in 3.17, I'm about to check when this was added | 16:53 |
| richard_maw | persia: either should be fine | 16:53 |
| persia | But, yes, inside it also shows / as a mountpoint | 16:53 |
| pedroalvarez | when I've hit this problem in the past, I solved it moving the rootfs to a different disk | 16:55 |
| richard_maw | I'm stumped, we've encountered similar issues with it failing in linus-user-chroot in the past for chroots | 16:56 |
| * persia doesn't have enough disks for that | 16:56 | |
| richard_maw | a loopback disk image ought to work | 16:56 |
| richard_maw | if it's a problem with a lack of physical hardware | 16:57 |
| jmacs | I'm hitting what appears to be an intermittent problem with gem | 16:57 |
| persia | Create a loopback disk, untar into that, loop-mount, and then chroot into the loop-mount? | 16:57 |
| jmacs | Running "gem install coderay" on baserock gives a certificate error | 16:57 |
| richard_maw | persia: that's what I'm thinking | 16:57 |
| pedroalvarez | jmacs: does your system have the ca-certificates chunk? | 16:58 |
| jmacs | pedroalvarez: It *should* do, let me check | 16:58 |
| pedroalvarez | If it is there, then maybe we need extra certificates for gem? | 16:59 |
| jmacs | Yes, I have core, which should include ca-certificates | 17:00 |
| jmacs | What's odd is that I've recorded this problem occurring before, but have no solution, as though it just goes away | 17:00 |
| franred | maybe the ca-certificates for the page of that gem are not in the normal certificates, I think you can add manually certificates to ca-certificates | 17:01 |
| persia | You can, and it should have the update-ca-certificates command | 17:01 |
| pedroalvarez | oh, intermitent problem, then that shouldn't be the problem | 17:01 |
| jmacs | persia: That's it | 17:01 |
| jmacs | update-ca-certificates fixed it | 17:02 |
| persia | Doesn't that run in the system-integration commands? | 17:02 |
| richard_maw | it should do | 17:02 |
| * persia got halfway through doing ca-certificates, and handed it off, and now feels guilty | 17:02 | |
| pedroalvarez | http://paste.baserock.org/duwewehica.coffee | 17:02 |
| pedroalvarez | worked here, the first time I run gem | 17:03 |
| pedroalvarez | persia: guilty? why? | 17:03 |
| jmacs | So it looks to me like update-ca-certificates doesn't run sometimes | 17:03 |
| richard_maw | hm, update-ca-certificates is actually run as part of the install commands of the ca-certificates chunk | 17:03 |
| persia | pedroalvarez: Because I didn't finish, and it might be buggy | 17:03 |
| richard_maw | which means it'll only contain bundled certs | 17:04 |
| persia | It should be run at system-integration time, rather than install time. | 17:04 |
| * richard_maw agrees | 17:04 | |
| * pedroalvarez fails to understand why | 17:05 | |
| richard_maw | because you could have other chunks provide certs | 17:05 |
| richard_maw | tbh, we also want it to be run at staging integration time too, but we don't have that functionality | 17:06 |
| richard_maw | so doing it in install-commands is close enough for most purposes | 17:07 |
| persia | And then re-run at integration time? | 17:07 |
| persia | (it is safe to run over and over and over again) | 17:07 |
| richard_maw | we won't need to run it in install-commands if we have staging-integration-commands | 17:07 |
| persia | Right, but we don't yet. | 17:08 |
| richard_maw | yep, because we don't have staging-integration-commands | 17:08 |
| persia | We ought fix that one day: we've been discussing the need for 10 months now :) | 17:09 |
| persia | How big do I need to make this loopback volume? is 40G enough? | 17:09 |
| jmacs | I'm not sure what staging integration time and install time are exactly | 17:09 |
| jmacs | Are these all things that run during the deploy? | 17:09 |
| richard_maw | no, they run during build | 17:09 |
| persia | jmacs: "install time" is when the chunk install-commands are run, when the chunk is built. | 17:09 |
| persia | "staging integration" commands don't exist, but they would run after the staging area is constructed, but before everything becomes read-only (which needs some means of layering FS or similar). | 17:10 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:10 | |
| persia | "System integration" commands run when the system artifact is constructed, just after all the pieces are in place, and just before it gets bundled to stick in the cache. | 17:11 |
| jmacs | Right. I haven't rebuilt anything for a while, that I can remember | 17:11 |
| jmacs | I've just been doing lots of deploys | 17:11 |
| pedroalvarez | OOI: if another chunk installs a certificate, is this going to be installed under /usr/share/ca-certificates as well? | 17:12 |
| persia | pedroalvarez: That is where it belongs | 17:12 |
| robtaylor | richard_maw: i recall us talking about some sort of thing for sysint to run things in alphanumerical ordering | 17:16 |
| robtaylor | richard_maw: so you could create a 99-rebuild-ca-cache system-inetgration | 17:16 |
| robtaylor | or similar | 17:16 |
| * robtaylor is going back a long while though, start of the year i think | 17:17 | |
| persia | February by my reckoning, but yes, some time ago | 17:23 |
| * robtaylor wonders if doing that would Just Work (tm) | 17:24 | |
| * persia rather wishes "sysfs" was just "sys" | 17:24 | |
| * persia suspects the output of `morph help branch` should not reference baserock:baserock/morphs | 17:26 | |
| radiofree | jjardon: why is systemd compiled with max-jobs: 1? | 17:28 |
| jjardon | radiofree: it fail in the generation of the GUdev.gir if not. I tried to fix it but without success | 17:29 |
| radiofree | ah, ok | 17:29 |
| jjardon | also strange as I can compile systemd in my machine without problems | 17:29 |
| radiofree | 36 minutes to build on a jetson | 17:30 |
| ssam2 | jjardon: what filesystem was your /src hosted on when you saw that error ? | 17:30 |
| ssam2 | I ask because I hit a problem that looked like a parallel make issue but was actually a FUSE bug | 17:31 |
| jjardon | ssam2: ext4 | 17:31 |
| ssam2 | which explained why I was only seeing it inside my Baserock system | 17:31 |
| ssam2 | jjardon: probably not a FUSE bug then | 17:31 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 17:31 | |
| jjardon | Im using an (old) baserock chroot though | 17:32 |
| persia | You might want to update. Experience the new bugs instead of the old ones. | 17:32 |
| * persia is using a fresh rootfs downloaded today | 17:32 | |
| jjardon | it would be good if any other can try and see if they can reproduce | 17:32 |
| radiofree | i'll try it now | 17:33 |
| jjardon | persia: yeah, I should do it at some point | 17:33 |
| persia | Mounting a loop image at /mnt, and setting up a chroot there (thanks to radiofree for the tarball) allows me to run the test commands safely. Now attempting a build. | 17:40 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:58 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 17:59 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 18:01 | |
| pedroalvarez | great | 18:02 |
| *** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:10 | |
| persia | Unfortunately my test system is now cached. | 18:18 |
| persia | Any suggestions on an armv7lhf system that is unlikely to be cached? | 18:18 |
| jjardon | Would it be possible to update the baserock images so the people that download them have network out of the box? | 18:18 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 18:22 | |
| persia | jjardon: Hrm? How do you mean? | 18:27 |
| * persia thought that worked | 18:27 | |
| persia | In fact, that *did* work for me two weeks ago. | 18:27 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:29 | |
| jjardon | persia: the images offered in baserock.org doesnt have systemd 217, so no network configuration out of the box. At least not here after running the qemu commands noted here: http://wiki.baserock.org/guides/vm-setup/#index3h2 | 18:29 |
| persia | Ah. Yes, that should be fixed. | 18:29 |
| persia | What does morph do when it is "deciding on task order"? This seems the longest single step in the build process. | 18:31 |
| straycat | iirc build graph stuff | 18:33 |
| straycat | and that probably includes creating the source pool | 18:34 |
| persia | Hurrah. Using a loopback causes morph to be capable of actual builds. | 18:36 |
| persia | straycat: Thanks. Hrm. I suspect more feedback during that would be useful: it makes it feel slow. | 18:36 |
| straycat | It can probably be faster too, I don't think anyone's really looked at runtime though. | 18:42 |
| * straycat looks for more python packages with funny names | 18:43 | |
| straycat | I wish programs would put their errors onto stderr, it would make it easier for me to report a useful error. | 18:44 |
| persia | I thought you chose them because they were useful (e.g. a JSON config parser), rather than the names | 18:44 |
| * straycat is sorry to disappoint | 18:46 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:08 | |
| * straycat tries out some of the more popular packages | 19:19 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:42 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:43 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 22:36 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 22:44 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 244 seconds] | 22:49 | |
| *** De|ta_ [~arc@195.242.156.171] has joined #baserock | 22:58 | |
| *** De|ta [~arc@195.242.156.171] has quit [Ping timeout: 252 seconds] | 22:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!