| *** petefoth [~petefoth@host-92-11-21-246.as43234.net] has quit [Ping timeout: 276 seconds] | 00:25 | |
| *** 17WAAZDA2 [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 00:37 | |
| *** rdale [~quassel@82.Red-83-47-22.dynamicIP.rima-tde.net] has joined #baserock | 03:30 | |
| *** rdale__ [~quassel@187.Red-2-138-205.dynamicIP.rima-tde.net] has quit [Ping timeout: 276 seconds] | 03:34 | |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:25 | |
| mike is now known as Guest68569 | 07:25 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:31 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:04 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:13 | |
| *** pedroalvarez [~quassel@ec2-54-191-112-126.us-west-2.compute.amazonaws.com] has joined #baserock | 08:51 | |
| Mode #baserock +v pedroalvarez by ChanServ | 08:51 | |
| Mode #baserock +nt by verne.freenode.net | 08:51 | |
| Mode #baserock +o pedroalvarez by ChanServ | 08:55 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:00 | |
| *** 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:12 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:21 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 09:23 | |
| bashrc | greetings earthlings | 09:27 |
|---|---|---|
| bashrc | does anyone know how to get out of "emergency mode" on boot? | 09:27 |
| bashrc | I'm getting the error "failed to start network service" | 09:27 |
| paulsherwood | for what device? | 09:28 |
| bashrc | it's a VM | 09:29 |
| paulsherwood | do you have a console? | 09:29 |
| bashrc | yes, but not a usable one | 09:29 |
| bashrc | I'm just instructed to predd Control-D to continue, perpetually | 09:29 |
| bashrc | s/predd/press | 09:29 |
| paulsherwood | how did you get to this, if i may ask? | 09:30 |
| bashrc | http://wiki.baserock.org/guides/vm-script/ | 09:30 |
| paulsherwood | am i right in thinking you wrote that page? | 09:31 |
| bashrc | yes | 09:31 |
| bashrc | if there isn't any way of getting out of emergency mode then I'll try again. It does take a while to install though | 09:32 |
| persia | It depends on the problem. | 09:33 |
| persia | Check your logs. | 09:33 |
| bashrc | looks like a network problem | 09:33 |
| persia | Generally that happens when the initrd can't load the filesystem properly. | 09:33 |
| bashrc | ah, I got in | 09:34 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:35 | |
| Mode #baserock +v ssam2 by ChanServ | 09:35 | |
| bashrc | it does some hanging and then you can enter a root password | 09:35 |
| bashrc | should there be an /etc/resolv.conf ? | 09:35 |
| Kinnison | A lack of resolv.conf should not prevent boot | 09:35 |
| pedroalvarez | i think that I've seen once the network service failing just because it failed to mount a device listed in fstab before, could this be the case? | 09:38 |
| pedroalvarez | s/it/the system/ | 09:39 |
| persia | failing to process fstab should cause the system to enter recovery mode, whereas failing to start network should not: perhaps the network failure, although the last error message, is a side-effect of an earlier error? | 09:43 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:48 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:48 | |
| pedroalvarez | bashrc: ^^ | 09:49 |
| bashrc | I'm looking at the logs. Because there's no ssh access, it's awkward | 09:52 |
| ssam2 | pedroalvarez: what's the deal with git.baserock.org now? DavePage was saying something yesterday about it needing migrating again | 09:52 |
| pedroalvarez | I'm happy to do it again. | 09:53 |
| DavePage | Well, I still have Plans for the host it's currently using, once we migrate g.b.o back to DC | 09:53 |
| pedroalvarez | then, let's move it again to DC, so we can move forward | 09:54 |
| franred | ummm, and if DC goes down again which machine are we going to use to have a back up of g.b.o? | 09:54 |
| franred | pedroalvarez, DavePage ^^ ? | 09:54 |
| DavePage | franred: Possibly, to the same Hetzner box which has been reinstalled ;) | 09:55 |
| franred | sounds good to me | 09:56 |
| bashrc | looks like the first error is probably "systemd-networkd.service has no holdoff/stopping network service" | 09:57 |
| bashrc | "holdoff time" | 09:57 |
| ssam2 | seems testgerrit.baserock.org is down because Java ran out of memory again | 09:58 |
| ssam2 | i'll restart it | 09:58 |
| Kinnison | bashrc: Is this a fresh VM made from a download from wiki.baserock.org ? | 09:58 |
| bashrc | it was made yesterday from download.baserock.org/baserock-current-build-system-x86_64.img | 09:59 |
| franred | ssam2, pedroalvarez, we should think at some point how to use hetzner as a back up which we can swap in few seconds/minutes if g.b.o goes down at some point in the future and try to automatize the migration that we are going to do for second time | 10:00 |
| bashrc | I could scrap it and try again. Might be useful to know why it broke though | 10:00 |
| persia | +1 for automated failover | 10:01 |
| DavePage | franred: Trouble is distributed / HA / failover git is Hard without proprietary software | 10:01 |
| straycat | Did we reach a decision on creating a new devtools stratum for things without dependants, like vim, that we can change without needing to rebuild a third of the system? | 10:02 |
| persia | straycat: A few people +1'd the idea, but I don't know that there was a patch that was discussed for actual application. | 10:02 |
| persia | I don't remember anyone expressing opposition | 10:03 |
| franred | DavePage, I still think that we can use the troves synchronized and swap troves main functions from mirror the repos from one trove to mirror the repos from the proper repositories | 10:03 |
| straycat | persia, Okay I'll send one then | 10:03 |
| franred | but maybe pedroalvarez and ssam2 know if that is possible without an horrific amount of development | 10:05 |
| ssam2 | franred: baserock isn't at the stage where we need to keep downtime within seconds | 10:05 |
| ssam2 | franred: but within minutes or hours would be good | 10:05 |
| ssam2 | franred: if we back up git.baserock.org's /home to hetzner, it seems logical we could set it up in such a way that we can also spin in a mirror git.baserock.org in afew minutes | 10:06 |
| DavePage | franred: Basically there's some political / business discussions that need to happen between Baserock and Codethink as Baserock's primary infrastructure donors; lots of things are technically possible but may not be desireable for Baserock's long-term objectives. | 10:06 |
| franred | DavePage, good point... I missed it, was just focused in technical stuff sorry | 10:09 |
| *** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:14 | |
| ssam2 | from the baserock-mason-x86-64 (new Zuul-based Mason) logs: | 10:16 |
| ssam2 | Jan 20 04:59:15 baserock-mason-x86-64 sshd[10095]: Accepted publickey for root from 82.70.136.246 port 54824 ssh2 | 10:16 |
| ssam2 | preceeded by several segfaults in libc.so | 10:17 |
| ssam2 | i've turned off the machine | 10:17 |
| persia | Good choice. | 10:17 |
| persia | Is there anything manual on there, or can it just be redeployed? | 10:18 |
| ssam2 | it can be redeployed, but presumably would be compromised again | 10:18 |
| ssam2 | actually, it was only given an internet-facing IP for debugging purposes | 10:19 |
| ssam2 | so could be redeployed without one | 10:19 |
| DavePage | I would suggest that if it was *preceded* by segfaults, then that probably wasn't the cause of the rooting. | 10:19 |
| DavePage | Somebody rooting by guessing a private key is hugely unlikely. | 10:19 |
| persia | ssam2: redeploying without one sounds best. | 10:20 |
| persia | If the attack vector can be identified, and the relevant bit patched, even better. | 10:20 |
| ssam2 | I can give someone access to the image if they'd like to investigate. | 10:21 |
| persia | DavePage: My interpretation was overflows that granted filesystem write access that granted ssh, but you could be right. | 10:21 |
| DavePage | Hang on | 10:21 |
| persia | That said, I don't really want to explore attack vectors in this channel :) | 10:21 |
| DavePage | http://www.whatismyip.com/ | 10:21 |
| DavePage | I suggest people in the CT office click ^^^ | 10:21 |
| Kinnison | why? | 10:22 |
| ssam2 | hmm, that does indeed suggest that the login was from the ct office :) | 10:22 |
| DavePage | Kinnison: You might see an IP address which is eerily familiar | 10:22 |
| Kinnison | DavePage: It's a zen IP | 10:22 |
| Kinnison | and a misspelled attribution | 10:22 |
| Kinnison | inetnum: 82.70.136.240 - 82.70.136.247 | 10:22 |
| Kinnison | netname: ZEN000090663 | 10:22 |
| Kinnison | descr: Code Think Ltd | 10:22 |
| Kinnison | tsk | 10:22 |
| DavePage | Kinnison: But specifically, it's the IP address in ssam2's log message which he thought implied a VM being rooted. | 10:23 |
| Kinnison | oh | 10:23 |
| persia | I'm not made that much more comfortable by a login from Codethink if the source isn't identified further. | 10:23 |
| Kinnison | """Accepted publickey""" | 10:23 |
| DavePage | persia: I'm made quite a bit more comfortable, but it was 5am. | 10:23 |
| Kinnison | implies it was someone who has a pubkey in root's .ssh/authorized_keys | 10:23 |
| Kinnison | so I'd start from that list | 10:23 |
| DavePage | Kinnison: Yes, I mentioned that previously :) | 10:23 |
| * Kinnison is slow | 10:24 | |
| * Kinnison is also angered that whatismyip.com doesn't have ipv6 support | 10:24 | |
| Kinnison | if I google for 'what is my ip' I get told 2a02:40:41:7fff:211:acff:feff:ffed which is more fun :-) | 10:24 |
| pedroalvarez | ssam2: don't worry about the segfaults | 10:31 |
| pedroalvarez | is caused by someone trying to ssh in to a non-existing user | 10:31 |
| ssam2 | ok | 10:33 |
| ssam2 | I've brought the machine back up but removed its floating IP | 10:33 |
| *** grahamfinney [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:33 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 10:38 | |
| grahamfinney | OK, new on Baserock. Where is the best place to start with the documentation? | 10:41 |
| Zara_ | http://wiki.baserock.org/ is what I use most | 10:41 |
| ssam2 | SotK: can I have your help debugging a zuul-mason issue? | 10:42 |
| ssam2 | i'm trying to trigger a job but I see in the debug logs this: | 10:42 |
| ssam2 | 2015-01-20 10:40:21,243 DEBUG zuul.IndependentPipelineManager: Considering adding change <Change 0x7f9084112390 134,1> | 10:42 |
| ssam2 | 2015-01-20 10:40:21,243 ERROR zuul.IndependentPipelineManager: Unable to find change queue for project None | 10:42 |
| persia | It's massively undercomplete, so ask here when you get stuck, and please help fix any pages that caused confusion once you have the answer. | 10:42 |
| paulsherwood | grahamfinney: please shout up here if you are confused or misled by anything on wiki.baserock.org | 10:43 |
| SotK | ssam2: what is the command you are using to trigger the job? | 10:44 |
| ssam2 | zuul -c /etc/zuul.conf enqueue --trigger gerrit --pipeline check --project definitions --change 134,1 | 10:44 |
| ssam2 | trying to use new mason to test paulsherwood's morph-arch-config branch :) http://testgerrit.baserock.org:8080/#/c/134/ | 10:44 |
| SotK | ssam2: can you paste /etc/zuul-layout.yaml somewhere? | 10:45 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:45 | |
| * paulsherwood is excited to see his patch getting such attention | 10:46 | |
| ssam2 | SotK: http://paste.baserock.org/puvuxeyuko | 10:46 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:47 | |
| ssam2 | it's the zuul-mason we deployed before Christmas | 10:47 |
| ssam2 | I've not redeployed it since | 10:47 |
| SotK | OK, the project on testgerrit looks to be "baserock/baserock/definitions" but that config file and your zuul enqueue command are expecting it to be called "definitions" | 10:48 |
| ssam2 | ah, ok | 10:48 |
| SotK | just s,definitions,baserock/baserock/definitions,g should work I think | 10:49 |
| grahamfinney | Thanks paulsherwood. Been looking at the wiki. I'll continue wading. | 10:49 |
| ssam2 | SotK: morph is running now. thanks for your help! | 10:51 |
| SotK | ssam2: no problem | 10:51 |
| bashrc | so, is the latest baserock 3.15.2 ? | 10:58 |
| ssam2 | versioning scheme is YY.WW (last 2 digits of year . week number) | 10:59 |
| ssam2 | the latest version is 15.02 | 10:59 |
| paulsherwood | 3.15.2? | 10:59 |
| bashrc | it's what someone was just saying | 11:00 |
| bashrc | I don't know where the 3 comes from | 11:00 |
| kejiahu | uname -a in baserock gives 3 digits version number | 11:02 |
| bashrc | 3.18.0 | 11:03 |
| * bashrc is now officially confused | 11:04 | |
| * SotK believes that is the kernel version | 11:04 | |
| persia | kejiahu: Why so it does. Is this a problem for some tooling? | 11:04 |
| * SotK could be wrong | 11:04 | |
| franred | bashrc, kejiahu , that is the linux kernel version | 11:04 |
| bashrc | ah, of course | 11:04 |
| kejiahu | oh, thanks for clarify | 11:05 |
| franred | latest tag of morph and definitions I think is 15.02 | 11:05 |
| franred | morph --version will give you the version of morph you are running | 11:06 |
| franred | if your system has morph on it ;) | 11:06 |
| persia | There's no good way to identify the version of Baserock as a number. One can check the definitions hash used to create the system one is running, and investigate nearby tags, but that's about it. | 11:07 |
| persia | (this is an intentional side effect of Baserock being a set of tools to generate systems, rather than being a software distribution) | 11:07 |
| tiagogomes_ | can't we put the version of Baserock in /etc/os-release? | 11:07 |
| kejiahu | morph --version only give commit tag isn't it? it's not obvious which one is newer | 11:08 |
| DavePage | A more human-readable form of persia's description in /etc/baserock-provenance or something? Listing the hashes of components therewithin? | 11:08 |
| tiagogomes_ | Also, you can look at /baserock/deployment.meta | 11:09 |
| DavePage | Ah OK | 11:10 |
| persia | kejiahu: To check ordering of tags, you need to use git, or a git visualisation tool. | 11:10 |
| persia | s/tags/commits/ | 11:10 |
| richard_maw | tiagogomes_, DavePage: Those don't belong in /etc; /etc is for configuration | 11:11 |
| richard_maw | os-release has been moved to /usr/lib IIRC | 11:12 |
| kejiahu | persia, thanks | 11:12 |
| nowster | richard_maw: is that so that /usr can be ro and /etcb be rw ? | 11:14 |
| nowster | s/etcb/etc/ | 11:14 |
| richard_maw | nowster: that's one aspect of it, but the general idea is that /etc is the domain of the system administrator, /usr is the domain of the distribution vendor, hence for a traditional distro, only the package manager should be able to fiddle with /usr (except /usr/local) | 11:15 |
| ssam2 | tiagogomes: I'd like us to put the version of Baserock in /usr/lib/os-release in the reference systems we release | 11:19 |
| ssam2 | for systems users build themselves, we should provide that facility, but it's impossible for Morph to automatically guess what versioning scheme a user considers it to be | 11:20 |
| ssam2 | or to have | 11:20 |
| ssam2 | if there was some way to express 'this system is based off Baserock 15.02 but could be wildly different' it would be nice to do that | 11:20 |
| persia | I don't think morph should even try to do that. | 11:24 |
| persia | If we want to provide a version file for reference systems, we should do so using file injection, and store the file to be injected in definitions. | 11:24 |
| ssam2 | sure, better for it to be an extension to morph than morph itself | 11:25 |
| ssam2 | using the install-files extension and maintaining the /usr/lib/os-release in definitions would be great actually | 11:27 |
| ssam2 | except that install-files.configure sucks. but we need to fix that | 11:27 |
| persia | I wouldn't complain about it implemented that way :) | 11:31 |
| persia | There will be a little confusion, as users won't always update the os-release file when changing definitions, but that happens no matter how we do it. | 11:31 |
| persia | And lots of derivatives of lots of image production systems in the past had the same issue: groups sharing more widely were usually happy to change. | 11:32 |
| tiagogomes_ | I dislike that morph moves failed builds from the staging dir to failed, making me having to clean everything and re-run configure | 11:42 |
| richard_maw | you should be able to run `morph gc` to get morph to clean up the artifacts it doesn't need and failed builds | 11:43 |
| persia | tiagogomes_: While I dislike the move as well, I'm not sure I understand your specific reasoning: are you unhappy that morph leaves the dirty build directory? | 11:44 |
| tiagogomes_ | richard_maw you misunderstood, I don't want to remove the failed build, I want to debug why it failed | 11:44 |
| ssam2 | tiagogomes_: oh, you're debugging builds that failed in bootstrap mode, right ? | 11:46 |
| ssam2 | so the paths change when it moves stuff to /src/tmp/failed and you have to rerun configure | 11:46 |
| ssam2 | you can always move it back again :) | 11:46 |
| tiagogomes_ | persia, I just would want to cd to the directory and run `make` to see what is the build failure, as sometimes morph seems to swallow some of the error output | 11:46 |
| persia | I actually prefer the dirty directory, as I like to see what artifacts were produced. | 11:47 |
| tiagogomes_ | yep ssam2, build essential | 11:47 |
| persia | Just cd'ing won't replicate the buid environment, so one can have very different results doing that (because with cd, one ends up using hte host tools, rather than the staging area tools) | 11:48 |
| tiagogomes_ | Because the other run in a chroot I don't need to re-run configure after chroot | 11:48 |
| ssam2 | persia: in bootstrap mode things are a bit different, because you *are* using the hosts tools | 11:48 |
| tiagogomes_ | persia, and for the other ones I chroot | 11:49 |
| ssam2 | and often your build takes 20 minutes or more before failing so you get very angry about having to reconfigure it again :) | 11:49 |
| persia | ssam2: True | 11:49 |
| persia | Does ./configure have to be run again because the paths are different? | 11:49 |
| tiagogomes_ | It would be nice that at the end of a build failure, morph printed out a command that would cd to right directory and would set up same environment as when it failed | 11:50 |
| persia | If that is too complicated, I'd settle for morph providing a command to deal with it: e.g. `morph debug foo` | 11:51 |
| tiagogomes_ | persia, yes, different paths | 11:55 |
| persia | Lets just not move it then. | 11:55 |
| persia | In the event that we run a new morph-managed build, it will be overwritten anyway, and it makes debugging (and discovery) easier. | 11:55 |
| tiagogomes_ | +1 | 11:56 |
| tiagogomes_ | persia it will not be overwritten, it will be in a different random temporary directory | 11:56 |
| jmalk | persia: I'm looking at cross-bootstrapping aarch64 (http://wiki.baserock.org/guides/how-to-cross-bootstrap/) and see that you've addid it here - http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/util.py#n470 - but not to the list of valid architectures in http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/__init__.py#n40 . Is there a reason you didn't, should I do so, will | 11:56 |
| persia | tiagogomes_: That works just as well. I think the main issue is it makes the `morph gc` logic harder. | 11:57 |
| Kinnison | jmalk: whatever you were saying was cut off after ', will' | 11:57 |
| persia | jmalk: I never completed that, so if you're finding issues, you should just fix them. | 11:57 |
| jmalk | s/, will/, will it cause headaches?/ | 11:58 |
| persia | jmalk: Essentially, the change I proposed was enough to be able to build armv7lhf binaries on an armv8 host from an armv7lhf chroot, but may not be enough to do it right. | 11:58 |
| jmalk | persia: ok thanks for the info | 11:58 |
| * Kinnison doesn't like line 470 there -- I'd prefer morph called it 'aarch64l' | 11:59 | |
| tiagogomes_ | persia I don't think so, chunks build successfully are kept in a chunks folder, so everything in the staging folder will be failed builds | 11:59 |
| persia | jmalk: Also, there's a patch for util-linux that needs to be applied. I've been sitting on it, but will clean it up and rebase to upstream and give you a link, so you don't have to repeat my investigations. | 11:59 |
| jmalk | persia: more thanks! | 11:59 |
| persia | tiagogomes_: Assuming morph isn't actually running in parallel, yes :) | 11:59 |
| *** rdale_ [~quassel@34.Red-83-45-185.dynamicIP.rima-tde.net] has joined #baserock | 12:00 | |
| tiagogomes_ | persia not supported :) | 12:01 |
| persia | tiagogomes_: I know, but that was part of the previous discussion :) A patch to drop "failed" is probably the best solution to this class of issues. | 12:02 |
| *** rdale [~quassel@82.Red-83-47-22.dynamicIP.rima-tde.net] has quit [Ping timeout: 246 seconds] | 12:03 | |
| *** rdale [~quassel@243.red-80-26-163.adsl.dynamic.ccgg.telefonica.net] has joined #baserock | 12:03 | |
| ssam2 | Kinnison: aarch64l because we may also have aarch64b ? makes sense to me. hopefully jmalk can fix that | 12:05 |
| Kinnison | aye | 12:05 |
| *** rdale_ [~quassel@34.Red-83-45-185.dynamicIP.rima-tde.net] has quit [Ping timeout: 252 seconds] | 12:06 | |
| persia | Please also support arm8l and arm8b, if adding architectures, so `linux32` has sensible targets. | 12:07 |
| *** rdale_ [~quassel@185.Red-2-136-65.dynamicIP.rima-tde.net] has joined #baserock | 12:08 | |
| ssam2 | would arm8l be the same as aarch64l ? | 12:08 |
| ssam2 | we should pick one for Morph and stick to it, I think | 12:09 |
| persia | No. aarch64l is 64-bit, arm8l is 32-bit | 12:09 |
| ssam2 | right | 12:09 |
| *** rdale [~quassel@243.red-80-26-163.adsl.dynamic.ccgg.telefonica.net] has quit [Ping timeout: 252 seconds] | 12:09 | |
| persia | I've only worked with that hardware in LE environments, but I was able to switch between "aarch64" and "armv8" using `linux32` | 12:10 |
| ssam2 | tiagogomes: a good solution for allowing `morph gc` to run at the same time as `morph build` would be to add a lock file to staging areas that are currently being used | 12:10 |
| ssam2 | so `morph gc` could remove anything in /src/tmp/staging that didn't have a lock file | 12:10 |
| paulsherwood | why does morph gc need to run at the same time? i've never seen a need forthat? | 12:11 |
| ssam2 | program defensively | 12:11 |
| ssam2 | if there's a way to make morph break it's own builds, we're stupid | 12:11 |
| ssam2 | its own builds | 12:12 |
| *** rdale [~quassel@248.Red-83-61-44.dynamicIP.rima-tde.net] has joined #baserock | 12:13 | |
| *** rdale_ [~quassel@185.Red-2-136-65.dynamicIP.rima-tde.net] has quit [Ping timeout: 264 seconds] | 12:16 | |
| *** rdale [~quassel@248.Red-83-61-44.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 12:16 | |
| *** rdale__ [~quassel@77.Red-83-52-107.dynamicIP.rima-tde.net] has joined #baserock | 12:16 | |
| kejiahu | question: how to change size of tmpfs in basercok | 12:18 |
| paulsherwood | ssam2: that was an answer to me? | 12:18 |
| paulsherwood | if so, i repeat my previous suggestion. run morph gc at the start of every build. less complexity. more useful | 12:19 |
| persia | kejiahu: Why do you need to expand it? | 12:19 |
| * straycat discovers a couple more duplicate lorries :o | 12:19 | |
| persia | The most common reason is best resolved by configuring morph to use a different temp directory, but if it is something else, editing fstab ought help. | 12:20 |
| ssam2 | paulsherwood: that was an answer to your question. removing the 'gc' command and running it at the start of every build would be a simpler solution, good point | 12:20 |
| paulsherwood | ssam2: unless there is a real use-case for running multiple morph builds on one machine simultaneously? | 12:20 |
| ssam2 | paulsherwood: although then people would complain that morph deleted their failed staging areas | 12:20 |
| kejiahu | persia, I am trying to morph build an image, and it complaints /tmp too small | 12:20 |
| franred | straycat, there are some python duplicated lorries for openstack AFAIK | 12:20 |
| paulsherwood | ssam2: no, they wouldn't | 12:20 |
| ssam2 | paulsherwood: I often run multiple morphs | 12:20 |
| persia | kejiahu: Right. Reconfigure morph to use a non /tmp empfs. | 12:20 |
| persia | Err, non /tmp temporary directory | 12:20 |
| ssam2 | I develop morph quite a bit, so my use cases aren't "normal" | 12:20 |
| straycat | franred, Really, where? | 12:21 |
| persia | I often find myself waiting for morph, although I've only run in parallel a couple times. I can well imagine workflows that involve significant parallel usage other than developing morph. | 12:21 |
| paulsherwood | mutiple morph builds? given it spends most of its time hard at work, running multiples in parallel seems like a bad idea | 12:21 |
| kejiahu | persia, ok, will try it thanks. | 12:21 |
| persia | paulsherwood: Depends on the environment: if you have good CPU but bad IO, multiples are more tempting. | 12:22 |
| ssam2 | in general, writing programs that can't be run in parallel (unless they are system daemons) seems like very bad workmanship to me | 12:23 |
| persia | I'd agree. | 12:23 |
| franred | straycat, they are in my list of checking, I can't point you to them right now | 12:23 |
| persia | Another use case for parallel morph is when one starts something that is bandwidth constrained, and wants to run something local (or mostly using local cache) in parallel. | 12:23 |
| straycat | franred, I ask because I'm writing a check script for the lorries repo so we can detect this sort of thing, and it didn't find those lorries | 12:24 |
| franred | ummm, interesting, I think I've seen some duplicated | 12:24 |
| paulsherwood | ssam2: fine, except that most folks then get into adding complexity, and don't actually fully test the parallelism. | 12:26 |
| persia | Let's not conflate things. | 12:27 |
| persia | morph *should* be capable of parallelism. morph should clean up after itself. | 12:28 |
| persia | There is presumably a solution that meets both these criteria, regardless of who might try to do what else to the code. | 12:28 |
| paulsherwood | :) | 12:28 |
| *** rdale [~quassel@164.Red-83-50-81.dynamicIP.rima-tde.net] has joined #baserock | 12:29 | |
| paulsherwood | ssam2: i notice elsewhere you are considering using ostree with baserock? | 12:30 |
| *** rdale__ [~quassel@77.Red-83-52-107.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 12:31 | |
| ssam2 | paulsherwood: yeah, hopefully SotK will be looking at that | 12:31 |
| ssam2 | I have a meeting now, sorry | 12:31 |
| tiagogomes_ | our libtool package really needs to be updated, it is from 2009 | 12:39 |
| tiagogomes_ | and it strips out --sysroot from the flags | 12:39 |
| persia | jmalk: prepress version: http://paste.baserock.org/olojehireb | 12:41 |
| jmacs | Having an odd problem since switching back from mime-types to ruby-gems/mime-types lorry: http://pastebin.com/rZvXiqPr | 12:41 |
| jmacs | Seems to be trying to fetch the url without ruby_gems | 12:42 |
| tiagogomes_ | also, build commands fail if the *last* command executed had a non zero exit status. It would be better that failed if any command had a non zero exit status no? | 12:42 |
| persia | tiagogomes_: That would make more sense to me: users can add "|| true" if they don't want to exit on failure. | 12:43 |
| jmalk | persia: thanks | 12:43 |
| tiagogomes_ | persia, yep | 12:43 |
| pedroalvarez | ANNOUNCEMENT: git.baserock.org will be down for 15 min aprox, starting at 14:00 (UK time). We will move it back to Datacentred in this time frame | 12:44 |
| persia | Although it isn't different at this time of year, I'd prefer times announced in UTC :) | 12:45 |
| pedroalvarez | heh, I'll do that in futre announces | 12:45 |
| pedroalvarez | announcements* | 12:46 |
| Zara_ | jmacs: this looks like the issue in chapter 5 here; the repo field looks like it won't work to me: http://wiki.baserock.org/guides/import-tool/rubygems/ | 12:50 |
| jmacs | I don't understand the use of the file:// protocol there | 12:54 |
| jmacs | Surely the source needs to come from a trove somehow. I won't have run the ruby import tool locally. | 12:56 |
| nowster | file:/// with three slashes? | 12:57 |
| straycat | file with as many slashes as you like | 13:05 |
| Zara_ | jmacs: if you haven't used the import tool, then I don't know how to fix it. If you have, then the repo field should point to the checkout of the package concerned, on your baserock system. | 13:05 |
| straycat | jmacs, the source doesn't need to come from a trove | 13:06 |
| Zara_ | eg, for me, the repo for the npm 'accepts' pkg is: repo: file:///src/workspace/here/checkouts/npm_accepts | 13:07 |
| jmacs | utterly confused now | 13:07 |
| jmacs | are you suggesting that every time someone wants to build a system with a ruby gem they have to run the import tool | 13:08 |
| jmacs | ? | 13:08 |
| straycat | no? | 13:08 |
| straycat | i'm suggesting that for testing purposes you don't need to lorry stuff into a trove | 13:08 |
| jmacs | this isn't for testing purposes | 13:08 |
| straycat | you can just build from your local sources, ensure everything works, then lorry stuff into the trove | 13:08 |
| jmacs | mime-types is already lorried and I want to use it | 13:08 |
| straycat | Okay, in that case don't pass --use-local-sources | 13:09 |
| jmacs | straycat: I'm not passing that | 13:09 |
| Zara_ | (I'm not suggesting that either, I'm saying that my knowledge of this only extends as far as the tool, and I can't be helpful otherwise) | 13:09 |
| ssam2 | tiagogomes_: is there a new libtool that doesn't strip out --sysroot ? | 13:10 |
| ssam2 | that'd be awesome if so | 13:10 |
| ssam2 | jmacs: that looks really weird | 13:11 |
| ssam2 | you have 'repo: upstream:ruby-gems/mime-types' and yet morph is looking at 'upstream:mime-types' | 13:12 |
| jmacs | Indeed | 13:12 |
| ssam2 | if you 'git grep upstream:mime-types' in the commit you have checked out, are there any results ? | 13:12 |
| tiagogomes_ | ssam2, http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=a8f549c1348c0bdedf3c01e6bed6c1e1aa5e8855 | 13:14 |
| ssam2 | AWESOME! | 13:14 |
| ssam2 | hmm, that's from 2010 ?? | 13:14 |
| tiagogomes_ | yes, the one that we are using reports 2009 | 13:15 |
| ssam2 | WHAT | 13:15 |
| ssam2 | there's a fair amount of faff in the build-essential chunk morphs to work around the fact that libtool eats --sysroot | 13:15 |
| robtaylor | gnng | 13:16 |
| ssam2 | stuff like setting LD='gcc --sysroot=$STAGE2_SYSROOT' if I recall correctly | 13:16 |
| ssam2 | robtaylor: gnng ? | 13:16 |
| tiagogomes_ | ah wait, it is more recent | 13:16 |
| tiagogomes_ | but the libtool script in binutils reports 2009 | 13:17 |
| ssam2 | ah..... because we build from tarballs during bootstrap | 13:17 |
| Kinnison | Do we need to just force-upgrade the libtool in that branch then? | 13:17 |
| ssam2 | ok. so maybe you can rebuild the bintutils tarball with a newer libtool | 13:17 |
| ssam2 | that may be harder than maintaining the current faff, but it's worth a try I think | 13:18 |
| ssam2 | it's hard because there are many combinations of autotools that don't work with each other | 13:18 |
| tiagogomes_ | I am using the latest binutils tarball, but they seem to still use an older libtool | 13:18 |
| tiagogomes_ | tell me about | 13:18 |
| robtaylor | ssam2: working around stuff when there was already a fix // | 13:19 |
| robtaylor | ah i see | 13:20 |
| jmacs | ssam2 straycat _Zara: Problem solved; I'd changed to a different definitions branch, and morph build doesn't understand that | 13:21 |
| paulsherwood | yes, morph assumes the branch named at 'morph checkout' or 'morph branch' time is the one it should build | 13:22 |
| tiagogomes_ | we just need the bintutils libtool for stage3, if stage 1 and stage 2 bintutils used the host libtool we would be fine, as in stage 3 we don't use sysroot support | 13:22 |
| Zara_ | jmacs: Glad you solved it. :) | 13:22 |
| paulsherwood | i've personally settled on just having one morph branch and putting it into the state i want using git reset --HARD foo | 13:23 |
| jmacs | paulsherwood: Does that work OK if you force push your original branch? | 13:24 |
| paulsherwood | jmacs: force push where? | 13:24 |
| jmacs | So if I've done a morph checkout of jmac-merged-branch-5 and then force pushed that from elsewhere | 13:24 |
| paulsherwood | git branch -v should show that you have checked out jmac-merged-branch-5. you can force reset that branch to any content/state you like, and morph will work as you hope | 13:26 |
| jmacs | Sounds good | 13:26 |
| paulsherwood | but if you check out any other branch there, morph will still believe it should work with jmac-merged-branch-5 | 13:26 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 13:30 | |
| *** rdale_ [~quassel@100.red-80-26-165.adsl.dynamic.ccgg.telefonica.net] has joined #baserock | 13:31 | |
| *** rdale [~quassel@164.Red-83-50-81.dynamicIP.rima-tde.net] has quit [Ping timeout: 276 seconds] | 13:35 | |
| persia | I've had success with using `git checkout` to different branches of definitions and morph still doing the right local thing. I've no idea how this interacts with morph push or distbuild. | 13:48 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:49 | |
| * paulsherwood found too many dark corners | 13:49 | |
| persia | Even without using `morph edit` or `morph push`? | 13:52 |
| paulsherwood | i never ever use morph push. the problem jmacs described above is a problem irrespective of morph edit | 13:53 |
| persia | Odd. Worked for me before. | 13:55 |
| bashrc | is there any way to check the current installed version of baserock? | 13:57 |
| paulsherwood | bashrc: metafiles in /baserock tell you all versions of everything | 13:57 |
| bashrc | so I think I now have a working devel image. Better save it before I break anything | 14:00 |
| * paulsherwood wonders why it was so hard | 14:00 | |
| persia | Are the components of devel not stored at cache.baserock.org? | 14:00 |
| * persia would think `morph build devel` would just download it, and `morph deploy` would just work | 14:00 | |
| nowster | manpage morph.1 could do with some fixing. The .RI macro doesn't work how the author thought it did. | 14:07 |
| pedroalvarez | DavePage: could we point git.baserock.org and trove.baserock.org to 185.43.218.183 | 14:10 |
| DavePage | pedroalvarez: Now? | 14:10 |
| nowster | eg. .RI "" CLUSTER [ DEPLOYMENT ...] [ SYSTEM . KEY = VALUE ] "" | 14:10 |
| nowster | should be .ΙR CLUSTER " " "" [ DEPLOYMENT ...] " " [ SYSTEM . KEY = VALUE ] (or split) | 14:10 |
| pedroalvarez | DavePage: if possible, yes | 14:10 |
| persia | nowster: I've often seen patches that small +1'd on IRC, but needs a commiter. +1 from me anyway (I'm not a committer): if it doesn't get a committer, you might need to mail the list. | 14:12 |
| nowster | persia: there are multiple instances of this | 14:12 |
| Kinnison | nowster: the manpage is created ,at least in part, | 14:13 |
| Kinnison | nowster: programmatically | 14:13 |
| persia | In that case, a proper patch to the mailing list is probably the best way to sort it. | 14:13 |
| persia | Kinnison: Maybe a bug in the generator? | 14:13 |
| Kinnison | maybe | 14:13 |
| DavePage | pedroalvarez: DNS is updated, give it ~60s to propogate | 14:14 |
| pedroalvarez | DavePage: great! thanks! I hope this time is definitive the change :) | 14:14 |
| jmalk | DavePage, pedroalvarez: I'm having problems pulling from git.baserock.org - is this because of the change or should it be unaffected? | 14:16 |
| DavePage | jmalk: Might be worth trying again? | 14:16 |
| pedroalvarez | jmalk: is because of the change. It should be up soon | 14:16 |
| jmalk | thanks | 14:16 |
| wdutch | following the cross-bootstrap x86 64 to x86 32 example here: http://wiki.baserock.org/x86_64_to_x86_32/ I've been getting the following | 14:18 |
| wdutch | ERROR: Nothing to cross-compile. Only chunks built in 'bootstrap' mode can be cross-compiled. | 14:18 |
| nowster | the manpage thing could be a bug in cliapp | 14:18 |
| pedroalvarez | ANNOUNCEMENT: git.baserock.org is UP again, thank you for your patience :) | 14:19 |
| bashrc | wdutch: I was getting that earlier | 14:20 |
| wdutch | bashrc, I noticed but build-essentials is in the morph | 14:22 |
| bashrc | yes, I think that's what's recommended on the wiki | 14:22 |
| * bashrc should build smaller images next time. Copying them is very sluggish | 14:23 | |
| jmalk | I'm looking into making changes to morph, following http://wiki.baserock.org/contributing/#index1h2, but morph is a sibling of workspace, so not included in baserock/my-branch - what is the procedure for developing morph? | 14:36 |
| richard_maw | jmalk: I usually follow the steps for using latest morph, then work in the git repository of that | 14:37 |
| jmalk | richard_maw: thanks, I'll take a look at that | 14:37 |
| persia | Another option is to git clone morph, hack it, update definitions to the SHA of your hack commit, and use cycle.sh or similar to update to new morph. | 14:38 |
| persia | Depending on your deploy/update speed, this method might be annoying though. On the other hand, if you use latest morph, it's a good idea to test with cycle.sh once before submitting the patch, just to make sure it works when installed normally. | 14:39 |
| wdutch | bashrc, did you find any way around it? | 14:43 |
| jmalk | persia: I understand most of that but am unsure how to update definitions to SHA of the morph hack commit | 14:43 |
| SotK | jmalk: edit the "ref:" field in the "morph" chunk in "strata/morph-utils.morph" to your SHA | 14:44 |
| bashrc | wdutch: no I didn't, but am trying with 6G of RAM | 14:44 |
| jmalk | SotK: ok thanks | 14:44 |
| SotK | jmalk: if you aren't pushing your morph repo, or you are pushing it somewhere other than git.baserock.org, you'll want to change the "repo" field to point to your repository too | 14:45 |
| SotK | jmalk: for example, "repo: file:///src/morph" | 14:45 |
| jmalk | SotK: ok. plan is to push to github following http://wiki.baserock.org/contributing/#index2h2 | 14:46 |
| jmalk | SotK: file:// being a placeholder or literally what I would have to type in? | 14:46 |
| persia | jmalk: URLs can have lots of shapes. "http://servername/pathname" is a common pattern. "file:///pathname" is another, and references something on the local filesystem. | 14:47 |
| richard_maw | literally what you have to type in, see https://en.wikipedia.org/wiki/File_URI_scheme | 14:48 |
| bashrc | wdutch: indeed, I'm still getting that same error | 14:48 |
| bashrc | even after having installed the development system | 14:48 |
| persia | Just remember to have three slashes. | 14:48 |
| richard_maw | python accepts just 1 slash, but I believe that's an extension to the standard | 14:48 |
| SotK | jmalk: if its on github, just point to the github repo URL instead | 14:49 |
| jmalk | richard_maw: thanks. going back to your earlier suggestion of the git repo in morph, do you still follow the baserock/username/feature-description convention? | 14:49 |
| jmalk | SotK: thanks very much | 14:49 |
| persia | richard_maw: It is indeed an extension. | 14:49 |
| richard_maw | jmalk: I always do | 14:49 |
| jmalk | richard_maw: great, thanks | 14:50 |
| richard_maw | persia: yeah, it wasn't until today that I learned that the file URI scheme had a hostname portion between the first two slashes and the third | 14:50 |
| SotK | in fact, I think we have a github repo-alias by default so you could just do 'github:your-repo' | 14:51 |
| persia | richard_maw: It isn't so important anymore, but it used to be meaningful for clusters, back when /usr/ was typically a shared NFS mount, and /usr/share another one that served multiple clusters with different architectures. | 14:51 |
| richard_maw | persia: does that mean that the file:// URI was initially for NFS? | 14:52 |
| persia | No, that was nfs:// | 14:52 |
| persia | But in the days when everyone used NFS as I describe, and didn't like NFS, there was constant talk about more transparent filesystem access mechanisms to be implemented at the OS layer. | 14:54 |
| persia | I believe the file:/// URI scheme was, in part, expecting that to come to fruition | 14:54 |
| richard_maw | It's fun to learn historical perspective! | 14:54 |
| bashrc | so, assuming my problem has something to do with build-essential, essentially how would I build build-essential? | 14:56 |
| Kinnison | You don't | 14:56 |
| Kinnison | you only build systems | 14:57 |
| bashrc | ah | 14:57 |
| wdutch | i tried to build a system with only build essentials but had the same error | 14:59 |
| wdutch | s/build/cross-boostrap/ | 14:59 |
| Kinnison | There are cross-bootstrap systems | 14:59 |
| Kinnison | you should use those | 14:59 |
| wdutch | well I had slightly more success with cross-bootstrap-system-x86_64-generic.morph than cross-bootstrap-system-x86_32-generic.morph | 15:06 |
| wdutch | now I'm getting ERROR: Failed to copy upstream:bash into /tmp/morph_tmp/staging/tmprVwLJI/stage2-fake-bash.build | 15:06 |
| Kinnison | you should be aiming for a system which has the right architecture for your goal | 15:07 |
| Kinnison | if you'r eon x86_64 and trying to cross to x86_32 you should be cross-bootstrapping an x86_32 system | 15:07 |
| wdutch | I'm just trying to see how it works, I don't have access to any architecture other than this x86_64 machine | 15:09 |
| ssam2 | wdutch: you should have a /src/morph.log file that might let you see whatever error occurred in more detail | 15:12 |
| ssam2 | if you don't have /src/morph.log, set up a /etc/morph.conf file as described in http://wiki.baserock.org/quick-start/#index4h2 | 15:12 |
| *** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 15:13 | |
| *** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:13 | |
| ssam2 | wdutch: in fact, I'd guess the problem is you are using the default morph tempdir of /tmp, which is too small to be useful | 15:14 |
| ssam2 | (making /tmp not a sensible default tempdir) | 15:14 |
| wdutch | okay | 15:14 |
| wdutch | ssam2, tempdir = /src/tmp and src is 30GB | 15:19 |
| wdutch | I don't think that's the problem | 15:19 |
| ssam2 | ok, then why did your error message refer to /tmp/morph_tmp/staging/tmprVwLJI/stage2-fake-bash.build ? | 15:19 |
| ssam2 | it should be /src/tmp/staging/... | 15:19 |
| ssam2 | (not a trick question, might be a bug, or anything) | 15:20 |
| * wdutch wonders if he forgot to symlink his morph.conf | 15:20 | |
| wdutch | yes he did | 15:21 |
| wdutch | doh | 15:21 |
| wdutch | thanks ssam2 :) | 15:22 |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 15:24 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:26 | |
| persia | richard_maw: "There is clearly a danger of confusion that a link made to a local | 15:33 |
| persia | file should be followed by someone on a different system, with | 15:33 |
| persia | unexpected and possibly harmful results. Therefore, the convention | 15:33 |
| persia | is that even a "file" URL is provided with a host part. This allows | 15:33 |
| persia | a client on another system to know that it cannot access the file | 15:33 |
| persia | system, or perhaps to use some other local mecahnism to access the | 15:33 |
| persia | file." | 15:33 |
| persia | So for multiuser scenarios, this was a mechanism to identify the namespace of the host that actually had the file. | 15:33 |
| * persia had the details incorrect, and is happy to have learned the real reason | 15:34 | |
| richard_maw | ah, so if the hostname portion doesn't match any of the hosts your machine is known as, you shouldn't attempt to read the file | 15:34 |
| persia | Right. | 15:35 |
| persia | And "localhost" or "" are wildcards. | 15:35 |
| persia | I wonder if * is supported, such that one could use "file:///*.baserock.org/foo" to identify path foo that was only available on baserock infrastructure machines. | 15:36 |
| * persia suspects nobody ever got around to adding support for that sort of thing in the various libraries we use today | 15:36 | |
| richard_maw | given different machines may resolve hosts entirely differently, it's probably only safe to follow the URI when the host is a wildcard address anyway | 15:36 |
| bashrc | getting a new cross-bootstrap error in a different VM: ERROR: Couldn't find morphology: strata/build-essential/stage2-linux-api-headers.morph | 15:37 |
| persia | Ah, good point. More modern RFCs about file: URIs may have removed the hostname specification part, only leaving the format for historical compatibility. | 15:37 |
| persia | bashrc: Does that file exist in your branch of definitions? | 15:38 |
| bashrc | indeed it does | 15:40 |
| bashrc | within strata/build-essential | 15:41 |
| paulsherwood | ssam2: are those firehose merge fails on linux master? is that actually possible? | 15:45 |
| paulsherwood | (i'm wondering if it's a sign of a bug) | 15:46 |
| perryl | that's embarrassing, it seems to be bringing in a lot more than just definitions updates to me | 15:47 |
| perryl | looking at the contents | 15:47 |
| ssam2 | yeah, that firehose instance seems to create its candidate branch on an outdated commit of definitions, so it has a large diff against master | 15:52 |
| ssam2 | when the diff against master should just be one line | 15:52 |
| ssam2 | so it is a bug in firehose | 15:53 |
| perryl | \o/ now, how to fix this bug? | 15:53 |
| ssam2 | i don't know, but I'd suspect it has a local clone of definitions which it never updates | 15:53 |
| ssam2 | or it updates the remote-tracking refs, but bases its candidate branches off 'master' instead of 'origin/master' | 15:54 |
| bwh | persia: ISTR some browsers on Windows treat file://host/path as a UNC path | 15:54 |
| perryl | indeed; the first three in december passed mason with minimal changes, the fourth on jan 2nd passed but with a massive diff | 15:54 |
| persia | bwh: That is a microsoft extension, so they should do so to maintain OS compliance (if not RFC compliance). | 15:55 |
| bwh | persia: and there were some Unix systems where //foo/bar was different from /foo/bar (don't think that's allowed by POSIX though) | 15:55 |
| persia | bwh: For those, one would use file://hostname//foo/bar | 15:56 |
| persia | I believe it not to be permitted by SUS, but I'm not sure about POSIX | 15:56 |
| perryl | Kinnison: in the firehose prototype, is there a section that restricts it to only looking at SHA differences in 'ref's? | 16:10 |
| Kinnison | do you mean follow-tip ? | 16:10 |
| perryl | i wonder if that's the issue? i'm interested as to why firehose is bringing in definitions changes that aren't just ref values | 16:12 |
| ssam2 | perryl: remember that gerrit shows the diff between what firehose pushed, and what Gerrit thinks 'master' is | 16:12 |
| ssam2 | so if firehose and gerrit have different opinions of what ref 'master' points to, it might cause this sort of confusion | 16:13 |
| perryl | ah! then yes it could be not updating definitions...which needs to be put in | 16:13 |
| persia | It is probably best to pull "master" from gerrit, rather than from anywhere else, as the potential for confusion can be very large indeed. | 16:14 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:21 | |
| nowster | stage2-fake-bash failing with: /src/tmp/staging/tmpXfoFif/tools/bin/sh: line 4: syntax error: unexpected ")" | 16:22 |
| nowster | has anyone seen that ^^ before? | 16:22 |
| ssam2 | no, that's creative | 16:22 |
| ssam2 | could you pastebin some context somewhere? | 16:23 |
| nowster | I assume it's something coming from the install script. | 16:23 |
| paulsherwood | i think i've seen it when my ybd attempts have not been progressing from stage1 to stage2 properly, ie it's not getting the expected paths/tools | 16:23 |
| persia | Is bootstrap something Mason is testing? | 16:24 |
| nowster | ssam2: https://admin.codethink.co.uk/pnopaste/?2196 | 16:25 |
| paulsherwood | persia: no, i don't think so. | 16:26 |
| SotK | persia: nope, just build and deploy | 16:26 |
| paulsherwood | can anyone explain/remember why boostrap starts differently from normal systems? | 16:26 |
| Kinnison | nowster: My recent patch fixed that | 16:26 |
| persia | SotK: Would it be possible to add something that verified build-essential still builds as well, or does caching mean that can never work? | 16:26 |
| Kinnison | nowster: and sam merged it | 16:26 |
| Kinnison | nowster: So you might just need to pull changes from master (of definitions) | 16:26 |
| paulsherwood | Kinnison saves the day :-) | 16:27 |
| persia | Or rebase your definitions over master | 16:27 |
| nowster | Kinnison: when did that change to definitions go in? | 16:27 |
| Kinnison | umm, yesterday morning I think | 16:27 |
| Kinnison | Check if stage2-fake-bash has a build-dep on stage2-busybox | 16:27 |
| Kinnison | if it does, you need to update | 16:27 |
| Kinnison | because that b-d is wrong | 16:27 |
| nowster | right | 16:28 |
| ssam2 | nowster: http://paste.baserock.org is a better pastebin for here by the way because it's not private | 16:28 |
| * nowster rebases | 16:29 | |
| nowster | ok | 16:29 |
| nowster | Kinnison: Cheers! That fixed it. | 16:30 |
| persia | \o/ | 16:30 |
| Kinnison | nowster: yw | 16:31 |
| ssam2 | persia, paulsherwood, SotK: Mason tests bootstrap each time we change something in the bootstrap | 16:31 |
| ssam2 | it doesn't test cross-bootstrap at all | 16:31 |
| persia | ssam2: Ah, so the key thing is really just that we need to get around to dropping cross-bootstrap already? | 16:31 |
| Kinnison | I hope not | 16:31 |
| Kinnison | not being able to cross-bootstrap systems would make me sad | 16:32 |
| ssam2 | if one codepath could satisfy both use cases that'd be great | 16:32 |
| Kinnison | ssam2: Sadly the issue was masked by the fact that in a native build, stage2's busybox can be run on the BUILD machine | 16:32 |
| ssam2 | although just because the same codepath is used for both doesn't mean it can't work for native bootstrap while breaking for cross-bootstrap | 16:32 |
| ssam2 | yeah | 16:32 |
| persia | Kinnison: From what pedroalvarez and richard_maw said yesterday, I had the impression that `morph build` should be able to achieve the same goal, using the regular build-essential morphology. | 16:32 |
| * Kinnison would find that quite surprising, but given the intelligence of those two, not impossible | 16:33 | |
| * Kinnison thought cross-bootstrap did a fundamentally different thing | 16:33 | |
| * richard_maw needs to collect context for a moment | 16:34 | |
| * pedroalvarez too | 16:34 | |
| pedroalvarez | :) | 16:34 |
| richard_maw | yeah, you need to run cross-bootstrap, as I recall, I was saying that we don't need a separate cross-bootstrap morphology, not that we don't need a separate cross-bootstrap command | 16:35 |
| pedroalvarez | and I agreed to that | 16:35 |
| persia | Ah. I thought richard_maw said that we didn't need a separate morphology and that pedroalvarez said he wanted to just use `morph build`. | 16:35 |
| richard_maw | If we had heterogenous distbuild networks we could do a cross-bootstrap in morph build, but we're not there | 16:36 |
| pedroalvarez | I tried to comunicate that `morph cross-bootstrap` should behave as `morph build`. But talking about the arguments that the command needs to run. | 16:36 |
| persia | I was thinking using the same two-step model. | 16:36 |
| Kinnison | richard_maw: would that work if we're trying to cross-bootstrap to an arch we aren't on yet? | 16:37 |
| persia | pedroalvarez: Ah, I misunderstood. Thanks for the clarification. | 16:37 |
| richard_maw | Kinnison: not without some form of distbuild worker agent on the target. That may not have to be a Baserock system, but if there's not an existing userland from a distribution then we'd always need cross-bootstrap | 16:38 |
| Kinnison | so let's assume we always need cross-bootstrap | 16:39 |
| Kinnison | and that cross-bootstrap is always somewhat different from "heterogenous build" | 16:39 |
| persia | I think there are three potential models: | 16:40 |
| persia | 1) I am building for my host | 16:40 |
| persia | 2) My host and target differ, and I have distbuild nodes for the target | 16:41 |
| persia | 3) My host and target differ, and I don't have distbuild nodes for the target | 16:41 |
| persia | (3) might have (a) and (b), being whether there are any distbuild nodes at all, but that's somewhat separate, | 16:42 |
| persia | All of these ought work, except that in case (3), if any of my build commands or install commands need to execute anything native, it all falls down. | 16:42 |
| Kinnison | cross-bootstrap is not just aobut building chunks though | 16:42 |
| persia | but that's just the content of definitions, rather than being a morph thing. | 16:42 |
| Kinnison | it also prepares a native-bootstrap script and a tarball full of appropriately prepared source trees | 16:43 |
| persia | Is that something that can't be declared as definitions? | 16:43 |
| Kinnison | I'd really rather not try to | 16:43 |
| Kinnison | it'd be a huge duplication of effort | 16:43 |
| persia | In my imagination, I can specify that some sources get included to some paths in a target, so it's just a matter of cross-building the base toolchain, adding the build script, and adding the sources. | 16:45 |
| persia | Making my cross-bootstrap definition mostly a matter of including the sources I want and the build-essential bit. | 16:45 |
| persia | That said, maybe this is flawed in some way, in which case I'd appreciate correction. | 16:45 |
| Kinnison | The point is that morph understands the bootstrap chunks (and builds them, preparing the toolchain for $TARGET via crossing) and then assembles those, and the sources to all the non-bootstrap chunks, and a script to build them all as close to how morph would as possible given the limitations, and creates you a tarball to shunt over | 16:46 |
| Kinnison | If we somehow expected to move that intelligence into chunk definitions, I'd be scared at the complexity involved | 16:47 |
| persia | Whereas I get scared as soon as you write "morph understands the bootstrap chunks" because of the implications for alternate toolchains, alternate kernels, etc. | 16:48 |
| Kinnison | "understands the bootstrap chunks" was poor wording | 16:49 |
| Kinnison | morph understands that for cross-bootstrapping, it should build the bootstrap chunks, and pack up the sources for the rest | 16:50 |
| persia | Ah, so this works for an arbitrary set of bootstrap chunks? | 16:50 |
| Kinnison | In theory, it should yes | 16:51 |
| Kinnison | the critical thing being that bootstrap chunks are prepared in the context of the HOST platform | 16:51 |
| *** grahamfinney_ [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:51 | |
| Kinnison | whereas the moment you're doing a non-bootstrap chunk you need to be able to execute TARGET code | 16:52 |
| persia | Right. | 16:52 |
| *** grahamfinney [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 16:54 | |
| paulsherwood | Kinnison: by non-bootstrap you mean a chunk whose build-mode is not 'bootstrap'? | 16:55 |
| persia | With some thought, this is fundamentally different from a generic cross-compile case. | 16:55 |
| persia | As a result, we probably do need a separate command, and the logic in morph, despite my misgivings. | 16:55 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 16:56 | |
| *** grahamfinney_ [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 17:00 | |
| Kinnison | paulsherwood: indeed | 17:00 |
| straycat | perryl, How come it also needs to catch AttributeError? My docs say ValueError is raised if the doc is invalid json | 17:04 |
| perryl | straycat: if you enter a correctly formatted but nonsense JSON string, e.g. {"sha":"abcdef1"} it throws an AttributeError and exits | 17:05 |
| straycat | perryl, from queue_event you mean? | 17:07 |
| perryl | straycat, looking at the traceback that occurs without, it seems to be in msg = yaml.load(json.loads(line)) | 17:08 |
| Kinnison | wtf | 17:08 |
| Kinnison | yaml and json? | 17:08 |
| straycat | so it's binary safe | 17:08 |
| Kinnison | Oh is this distbuild? | 17:09 |
| perryl | yes | 17:09 |
| Kinnison | aah | 17:09 |
| * Kinnison knows nothing and so shuts up | 17:09 | |
| straycat | perryl, Ahh I see now that's coming from the yaml.load | 17:10 |
| perryl | straycat, does yaml.load have issue with unexpected JSON formats? i'm not 100% on distbuild so i'm willing to defer to you on this | 17:12 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:15 | |
| straycat | perryl, well we're encoding our yaml in json, so when we decode we're expecting the result of json.loads() to be a yaml document | 17:18 |
| straycat | So yeah I think you're right to catch the AttributeError there | 17:18 |
| bashrc | ugh. Network failures again | 17:19 |
| straycat | perryl, I'm not sure what other exceptions could be thrown from a given input though, the safest thing to do may be to just have that one line in the try block, catch any exception that we get from it and pass | 17:21 |
| perryl | straycat: and put queue_event outside the try: block? | 17:22 |
| straycat | In fact, we shouldn't be using load at all | 17:22 |
| straycat | "Warning: It is not safe to call yaml.load with any data received from an untrusted source! yaml.load is as powerful as pickle.load and so may call any Python function. Check the yaml.safe_load function though." | 17:23 |
| straycat | (http://pyyaml.org/wiki/PyYAMLDocumentation) | 17:24 |
| straycat | perryl, sorry, yeah | 17:26 |
| straycat | And I'd replace load with safe_load | 17:26 |
| perryl | no problem, i'll update my commit. do you want me to change yaml.load to safe_load in a separate commit as well? | 17:26 |
| straycat | either's fine by me :) | 17:27 |
| perryl | i think they should be fine in the same commit as they're relatively in the same scope! i'll push a second patch to the ML once i've tested it | 17:28 |
| straycat | cool :) | 17:28 |
| jmacs | So, can we do pre-commit hooks on g.b.o.? That's potentially interesting | 17:29 |
| Kinnison | pre-commit is local to the committer | 17:29 |
| Kinnison | do you mean update hook? | 17:30 |
| jmacs | I do | 17:30 |
| Kinnison | Yes, we can do update hooks, but they are constrained in the ways gitano hooks are constrained | 17:31 |
| jmacs | Although maybe paulsherwood and straycat did mean something local to the committer, on the mailing list | 17:31 |
| Kinnison | So it depends on what you want the hook to do | 17:31 |
| jmacs | Originally we were talking about a script that checked for duplicate lorries | 17:33 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:33 | |
| persia | I think the best time to run that is post-push and pre-merge, but that depends on infrastructure we don't have today :( | 17:33 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:34 | |
| Kinnison | I think the check is best done as a "try-load" in lorry-controller and then a hook which queries that | 17:34 |
| jmacs | persia: Either that or done as an automatic review on the mailing list. | 17:34 |
| persia | jmacs: Right. That works just as well. | 17:35 |
| ssam2 | jmacs: about your chef patch: shall I merge it with the fixup franred suggested (of adding 'cloud-init' to the list of enabled configure extensions in systems/ceph-service-x86_64-generic.morph) ? | 17:36 |
| straycat | ssam2 suggested the script we currently have could be run as a pre-commit hook, but i'm also happy to try out some of the other options | 17:36 |
| ssam2 | alternately, if you felt like requesting push access to git.baserock.org i'd +1 your request, if someone else did so too you could then merge it yourself :) | 17:37 |
| ssam2 | s/patch/branch/ | 17:37 |
| jmacs | ssam2: I'll just have a look at fran's suggestion... | 17:38 |
| jmacs | franred: Is your suggestion to remove cloud-init from ceph-service-x86_64-generic.morph? If so, I'm fine with that | 17:40 |
| jmacs | Or add the configuration extension? | 17:40 |
| franred | jmacs, my suggestion is add the configuration extension if the system can be deployed in openstack if not cloud-init won't work when you enabled in the cluster morphology | 17:41 |
| franred | or if cloud-init is not needed for anything, just remove it from the system | 17:42 |
| jmacs | This patch series doesn't address openstack | 17:42 |
| jmacs | So it's probably there by accident | 17:42 |
| ssam2 | there's no harm to having cloud-init available, even if you don't care about OpenStack yet | 17:44 |
| jmacs | Ah, I was assuming I'd have to add something to the cluster morph, but if I don't need to, then we can just add the configure extension | 17:45 |
| ssam2 | you'd also need to add 'CLOUD_JNIT: yes' to the cluster morph *if* you were deploying to OpenStack | 17:47 |
| ssam2 | CLOUD_INIT even | 17:47 |
| ssam2 | but as a precedent, the build- and devel- systems contain the cloud-init stratum and have the cloud-init configure extension available | 17:48 |
| jmacs | But we're not | 17:48 |
| jmacs | Right, I see | 17:48 |
| ssam2 | which means that when we *do* deploy to OpenStack, it *only* requires a different cluster morph to enable cloud-init | 17:48 |
| ssam2 | listing the configuration-extensions in the system morph is a mis-feature | 17:49 |
| jmacs | I'm fine with adding cloud-init to the configuration-extensions section | 17:50 |
| ssam2 | they should effectively all be enabled, I think, but before doing that we'd need to vet them all to make sure all of them are no-ops unless enabled with a deploy-time variable | 17:50 |
| ssam2 | jmacs: ok, cool. do you want me to do that and merge? | 17:50 |
| jmacs | ssam2: Please do | 17:50 |
| ssam2 | ok | 17:50 |
| jmacs | Thanks ssam2! | 17:52 |
| jmacs | Were the openstack python tools (glance, nova etc) added into devel-system recently? | 17:58 |
| ssam2 | they'd been there a while I think | 17:59 |
| jmacs | But they are in devel? | 18:00 |
| ssam2 | in openstack-clients stratum | 18:00 |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:00 | |
| franred | ssam2, jmacs, but they are only the clients | 18:00 |
| franred | and some of them | 18:00 |
| ssam2 | since 2014-08-18 at least | 18:00 |
| jmacs | That's all I need, I think | 18:00 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:00 | |
| jmacs | Odd, I should have them then | 18:01 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:01 | |
| pedroalvarez | hm... | 18:02 |
| pedroalvarez | `which nova` ? | 18:02 |
| franred | jmacs, http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/openstack-clients.morph | 18:03 |
| lachlanmackenzie | Hi, I've been trying to follow the instructions contained in http://wiki.baserock.org/guides/vm-script/ - but I don't seem to be able to login to the vm once it's created. Can you confirm that the default password is still 'root'. | 18:06 |
| franred | lachlanmackenzie, the VM does not have password, it has user root, no password | 18:07 |
| persia | Is there a default password? I thought default was no password. | 18:07 |
| franred | persia, default is no password | 18:08 |
| jmacs | You can only log in on the console and you won't be asked for a password. | 18:08 |
| lachlanmackenzie | jmacs: problem is that I can't launch the graphical console - it comes up with an SDL error. | 18:09 |
| lachlanmackenzie | I've tried running with -curses and it simply displays a grey screen. | 18:11 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:13 | |
| persia | Ugh. Another solution is to deploy it with ssh injection (I forget the right argument for that), and ssh in. | 18:13 |
| lachlanmackenzie | persia: Thanks, I will have a look at that. | 18:14 |
| franred | lachlanmackenzie, or using virt-manager | 18:16 |
| jmacs | lachlanmackenzie: Yep, that's the only way to do it if you can't get the console (unless you have some serial console emulation in your virtualisation software) | 18:16 |
| jmacs | I don't know for sure if baserock has a serial console tbh | 18:16 |
| lachlanmackenzie | I might try setting the vnc port | 18:16 |
| persia | I don't know of any configuration extension that creates a serial port, but my knowledge isn't encyclopedic. | 18:17 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 18:27 | |
| *** brlogger [~supybot@host-78-148-28-74.as13285.net] has joined #baserock | 18:31 | |
| *** brlogger [~supybot@host-78-148-28-74.as13285.net] has quit [Quit: Ctrl-C at console.] | 18:41 | |
| pedroalvarez | yup.. supybot will be joining #baserock to get irclogs and then publish them. | 18:59 |
| pedroalvarez | Now I have to investigate how to transform the existing logs to the new format | 19:00 |
| pedroalvarez | or how can I get them from my client (quassel) | 19:00 |
| pedroalvarez | so we don't lost any irclog from the past | 19:00 |
| pedroalvarez | My attempt of converting paste.baserock.org to a baserock definition, is going slower than expected. I thought that with nodejs in a system I could run any node application. But no. I will have to use the import tool | 19:03 |
| *** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 19:05 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:09 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 19:09 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 19:09 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:09 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 245 seconds] | 19:14 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 19:16 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 19:16 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:16 | |
| *** Guest68569 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 19:21 | |
| *** rdale [~quassel@50.Red-2-137-7.dynamicIP.rima-tde.net] has joined #baserock | 19:40 | |
| *** rdale_ [~quassel@100.red-80-26-165.adsl.dynamic.ccgg.telefonica.net] has quit [Ping timeout: 264 seconds] | 19:43 | |
| *** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has quit [Quit: Changing server] | 19:44 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 19:46 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:20 | |
| persia | What magic does the import tool do that can't be done manually? I thought the import tool was just a mechanism to make it easier to write definitions. | 20:21 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 20:26 | |
| *** rdale_ [~quassel@253.Red-2-136-156.dynamicIP.rima-tde.net] has joined #baserock | 20:51 | |
| *** rdale [~quassel@50.Red-2-137-7.dynamicIP.rima-tde.net] has quit [Ping timeout: 255 seconds] | 20:54 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 21:05 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 21:06 | |
| pedroalvarez | The haste-server depends on 8 or 9 node libraries. Just because of that. | 21:28 |
| pedroalvarez | So yes, the only magic that it's supposed to do is to save my time. :) | 21:39 |
| persia | Ah, excellent. Tools that save time are lovely. | 21:43 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 21:56 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 22:07 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!