*** cosm [~Unknown@us2x.mullvad.net] has quit [Ping timeout: 258 seconds] | 00:15 | |
*** cosm [~Unknown@host-78-150-56-250.as13285.net] has joined #baserock | 00:31 | |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:23 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 07:35 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 07:35 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 07:35 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 08:30 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:51 | |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:57 | |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [] | 08:58 | |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:01 | |
*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 09:02 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:40 | |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:01 | |
*** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:02 | |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 11:05 | |
petefoth_ is now known as petefoth | 11:05 | |
*** rdale [~quassel@252.Red-2-136-152.dynamicIP.rima-tde.net] has quit [Ping timeout: 265 seconds] | 11:48 | |
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 11:52 | |
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:55 | |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:24 | |
*** locallycompact [~lc@110.154.199.146.dyn.plus.net] has joined #baserock | 12:37 | |
perryl | out of curiosity, how long does the build-deploy cycle take to complete? | 14:08 |
---|---|---|
perryl | or is that like asking 'how long is a piece of string'? | 14:09 |
persia | A bit like that, yes. | 14:09 |
persia | If you're working on an edge component, it can be a matter of minutes. | 14:09 |
richard_maw | it is really, it depends on how the size of the system you want to build, how much has been previously built, and how large you want to make disk images if you're deploying those | 14:09 |
persia | If you're modifying something deep, like experimenting with a new C compiler, and invalidating all your caches, it can be hours or days. | 14:10 |
persia | (e.g. moving from gcc/glibc to clang/musl) | 14:10 |
paulsher1ood | persia: not days, normally. full rebuild took ~ 10 hours for me last time i tried it | 14:11 |
richard_maw | for a dinky little ARM board it would be | 14:11 |
persia | paulsher1ood: I've taken > 3 days to build a devel system, and had runs I interrupted that ran nearly that long and remained incomplete. | 14:11 |
paulsher1ood | persia: ok i believe you :) | 14:12 |
persia | Note that some of the slowness bugs I had have been fixed. In practice, I suspect you are closer to the right maximum | 14:12 |
paulsher1ood | at the other extreme, on my macbook, my normal build-and-deploy-system-with-new-kernel-to-self takes 10-15 minutes | 14:12 |
persia | You could probably be even faster if you were to do build-and-deploy-to-self with a leaf python app. | 14:14 |
paulsher1ood | well yes, most of the time is building the kernel | 14:14 |
straycat | deploy is faster now at least | 14:18 |
paulsher1ood | yup. what happened there? | 14:19 |
jmacs | pdar: Have there been any changes to ceph in Baserock recently? I'm getting an error saying the boost library is missing | 14:19 |
pdar | Oh yes, are you using a new master? | 14:20 |
straycat | liw's fix to not transmit zeros iirc | 14:20 |
jmacs | pdar: Maybe - I'm working on an odd branch atm | 14:22 |
jmacs | This is why I need a tool to say "tell me the origin of this component" :) | 14:22 |
paulsher1ood | http://wiki.baserock.org/guides/build-deploy-cycle/?updated#index3h2 | 14:22 |
straycat | so, now we just need to rewrite everything in k, and we'll be fine, style guide here: http://kparc.com/cs/style.txt | 14:23 |
paulsher1ood | jmacs: what do you mean by 'origin'? | 14:23 |
pdar | I think radiofree said it might be something to do with the change to glib | 14:24 |
jmacs | I'm not sure; details on where the source came from, where it's been cached, and the git ref | 14:24 |
persia | How is this different from repo/ref? | 14:25 |
radiofree | pdar: did building the newer version work? | 14:25 |
pdar | radiofree: it worked great yep thanks :) | 14:26 |
pdar | jmacs: if you change to the most recent version of boost-tarball v1.56 the boost libraries should compile fine | 14:49 |
pdar | jmacs: but, this stops them form working with the old version of ceph thats set in defenitions | 14:50 |
*** locallycompact [~lc@110.154.199.146.dyn.plus.net] has quit [Read error: Connection reset by peer] | 14:51 | |
jmacs | How do I do that? Can I map from boost version numbers to a ref to put in ceph-service.morph easily? | 14:53 |
petefoth | the virtualbox-ssh write extension looks for carious network related parameters (HOST_IPADDR, NETMASK, NETWORK_CONFIG. can these be passed in in the samre way as others, i.e. in the clkuster definitio file or as key/value pairs of arguments in the call to `morph deploy’? | 14:57 |
paulsher1ood | jmacs: would a quick tutorial help? | 15:00 |
pdar | jmacs: if you take the commit id of the boost v1.56 at http://git.baserock.org/cgi-bin/cgit.cgi/delta/boost-tarball.git/commit/?id=1c3648bf5b7d17fcd4fe9bc95802b16fd9eee304 and swap that for the one in ceph-service.morph | 15:01 |
* paulsher1ood assumes jmacs has seen the kernel update tutorial https://vimeo.com/110065776 | 15:02 | |
paulsher1ood | you can put a short sha, branch, or tag in the ref: field | 15:02 |
jmacs | Yes, I was wondering how pdar found that page just given the information "v1.56" | 15:02 |
straycat | petefoth, any of the env vars can be passed on the command line to morph deploy | 15:03 |
jmacs | So "boost_1_56_0" would work as a ref | 15:04 |
jmacs | paulsher1ood: No, I haven't seen that video, I'll watch it now. | 15:04 |
petefoth | straycat: thanks. Are they passed as network config stanzas (as decribd in simple-network.configure) or is some other form? | 15:04 |
jmacs | Got it anyway. Click on the tag, then on the "tagged object" field. | 15:05 |
straycat | petefoth, not sure i understand, the vars themselves are just strings interpreted by the extension | 15:07 |
petefoth | straycat: Yes I understand that (I think :). I’m particulalry flummoxed by the NETWORK_CONFIG variable: I suspect - from reading simple-network.configure - that it is more than a simple string: possibly its is one or more network config stanzas as handled in the `parse_network_stanza` function. I need to describe - in the virtualbox-ssh.write.help file - how these stanzas get passed to the virtualbox-ssh write extension (not the | 15:22 |
petefoth | simple-network.configure extension) | 15:22 |
pedroalvarez | note, simple-network.configure extension is not being used by any of the systems | 15:26 |
pedroalvarez | it was removed from all the systems with systemds | 15:26 |
pedroalvarez | s/s$// | 15:27 |
Kinnison | Yes, which is sad | 15:27 |
petefoth | pedroalvarez: noted thanks! I wont bother documenting that one just yet then :) I guess that virtualbox-ssh *does* get used sometimes (or does everyone here use KVM or OpenStack? | 15:27 |
Kinnison | petefoth: You're going to have to ask jjardon for help with how to write up what simple-network.configure *used* to be used for | 15:27 |
pedroalvarez | petefoth: yeah, I believe thet some people use virtualbox-ssh | 15:28 |
* SotK uses virtualbox at home but has never done a virtualbox-ssh deployment | 15:29 | |
jmacs | I've been using virtualbox-ssh extensively | 15:29 |
petefoth | Kinnison: OK :) But I still need to know how to setup networking using the vbox-ssh wirte extension. | 15:29 |
* paulsher1ood uses virtualbox-ssh exclusively | 15:29 | |
Kinnison | petefoth: You'll need to have jjardon help you and then you can document it | 15:30 |
Kinnison | petefoth: when he did the systemd networking stuff he dropped simple-network.configure and made apparently no moves to document the replacement | 15:30 |
Kinnison | I could be missing something though | 15:30 |
petefoth | jmacs: please can you talk (or email or irc me through the vbox-ssh stuff) | 15:30 |
pedroalvarez | is needed to configure the network when doing a vbox-ssh deployment? | 15:31 |
pedroalvarez | is mandatory? | 15:31 |
petefoth | Kinnison: you’re missing that I was using simple-network as a (probably confusing) example. What I care about at the moment is the vbox-ssh networking stuff | 15:31 |
Kinnison | At the time *I* wrote the virtualbox networking stuff, it was using simple-network.configure | 15:32 |
petefoth | pedroalvarez: I don’t know, and I can’t work it out from looking at the code! That’s why I’m shouting ‘Heeeeeelp’ :) | 15:32 |
pedroalvarez | heh | 15:32 |
pedroalvarez | ok | 15:32 |
pedroalvarez | you don't need to document the networking stuff to document the vbox deployment | 15:32 |
paulsher1ood | petefoth: i assume you've seen http://wiki.baserock.org/guides/deploy-trove-to-virtualbox/ | 15:33 |
paulsher1ood | (which has an example) | 15:33 |
petefoth | paulsher1ood: thanks - I should hav elooked there instead of looking through the code :) | 15:34 |
jmacs | paulsher1ood: I will only have copied NETWORK_CONFIG from somewhere - I'll try and remember where | 15:34 |
* pedroalvarez realises that in every example of vbox deployment we configure the network, and wonders if it's something needed in virtualbox | 15:34 | |
* Kinnison notes that the virtualbox-ssh deployment extension expects NETWORK_CONFIG, expects it to define eth0 and eth1, and expects that one will be attached to a host-only network | 15:34 | |
petefoth | If that still works I can use that for the write.help file | 15:34 |
* paulsher1ood wonders who wrote 'ditch the verbosity and just do it wi with a script' | 15:34 | |
jmacs | petefoth: I'm just using the example from http://wiki.baserock.org/devel-with/#index5h2 | 15:35 |
jmacs | With a modified static address for eth0 | 15:35 |
petefoth | jmacs: thanks that’ll be useful too. | 15:35 |
paulsher1ood | the 'ditch verbosity' is more verbose than the no-frills page | 15:35 |
pedroalvarez | aaaaaah! NETWORK_CONFIG is also present in the vbox write extension, not only in the simple-network configure extension | 15:35 |
petefoth | pedroalvarez: exactly! | 15:36 |
pedroalvarez | sorry pete | 15:36 |
petefoth | pedroalvarez: NP! stupid questions and vaguely enlightened answers all work together to get me to the right place in the end :) | 15:37 |
* petefoth notes that the correct answer to his question was ‘Read the wiki, dummy!’ :) | 15:38 | |
pedroalvarez | after a quick look to the vbox write extension, I think it may be broken | 15:38 |
petefoth | pedroalvarez: not *my* problem - I’m just doucmenting how it is *meant* to work | 15:39 |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 15:39 | |
* paulsher1ood wonders who Robert is, and what made him decide to write http://wiki.baserock.org/guides/vm-script when http://wiki.baserock.org/guides/no-frills/ exists | 15:39 | |
pedroalvarez | paulsher1ood: not sure, but I think that it was bashrc > | 15:44 |
pedroalvarez | ? | 15:44 |
* petefoth looks in his irc logs | 15:44 | |
paulsher1ood | maybe, maybe not | 15:44 |
*** genii [~quassel@ubuntu/member/genii] has joined #baserock | 15:46 | |
paulsher1ood | bashrc: assuming you wrote the vm-script page, i don't see what it gives over the no-frills page, which pre-dates vm-script? | 15:47 |
* paulsher1ood looks harder | 15:47 | |
bashrc | I think there's more in the vm-script, but I'll have to check. I was trying to get to a state where I could compile zfs | 15:48 |
bashrc | but if they're very similar then just merge them into one | 15:49 |
paulsher1ood | vm-script assumes presence of emacs, debian/ubuntu i think | 15:49 |
paulsher1ood | but i agree with the idea of having a script to do all of this | 15:49 |
paulsher1ood | bashrc: i'll think a bit more | 15:50 |
paulsher1ood | thanks | 15:50 |
bashrc | my impression is that the barrier to entry is pretty high. You have to jump around various pages to get something running | 15:51 |
paulsher1ood | the no-frills page covers everything in vm-script, but it's vbox specific (can run on macos or linux). vm-script is kvm and linux specific iiuc | 15:52 |
paulsher1ood | so probably worth having two pages, one to cover vbox, one for kvm. and maybe standardize the style | 15:53 |
paulsher1ood | bashrc: sadly i agree with you about the barrier to entry seeming high | 15:53 |
petefoth | and keep the pages ‘editor-agnostic’ | 15:55 |
bashrc | if you seek more adoption then maybe have one or more downloadable scripts which can be used to make a working VM so that users can get going quickly | 15:55 |
richard_maw | there's an argument for vagrant | 15:55 |
paulsher1ood | scripts would be simpler, richard_maw :) | 15:57 |
robtaylor | jjardon: https://github.com/eggert/tz is the git repo for the current tzdata 'coordinator' | 16:02 |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 16:30 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:33 | |
straycat | what's the ip of the shared artifact cache? | 16:35 |
pedroalvarez | cache.baserock.org | 16:36 |
straycat | thanks | 16:36 |
pedroalvarez | np! | 16:43 |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 16:44 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:45 | |
straycat | well, i just screwed up the dev machine i was using for import, at least i can deploy a new one in 2 minutes. | 16:49 |
pedroalvarez | I've recovered devel systems in the past uncompressing a system artifact in / | 16:50 |
pedroalvarez | which was pretty hacky but it worked :) | 16:51 |
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 16:51 | |
* paulsher1ood realizes we should rename linux-jetson-tk1 to linux@jetson-tk1 etc | 16:55 | |
Kinnison | is jetson-tk1 the name of the ref? | 16:56 |
* Kinnison thought the point of the @ was chunkname@shasum but is perhaps missing something | 16:56 | |
paulsher1ood | i thought the point was to differentiate chunk@foo from chunk@bar, where bar and foo may be refs or other things | 16:57 |
Kinnison | So they're meant to be conceptually entirely different things? | 16:57 |
* Kinnison thought the post-@ stuff was parameterisation | 16:58 | |
paulsher1ood | not necessarily. but for example we could have linux at a specific ref with docker config, same without. | 16:58 |
Kinnison | Oh | 16:58 |
* Kinnison repositions the @foo stuff from "variant-by-parameterisation" to "entirely separate stuff" box in his head | 16:59 | |
paulsher1ood | i think it's still variant by parameterisation? it's certainly just a way of distinguishing variants of chunk. i'd hope anything after the @ was usefulmeaningful to humans - could be a tag, or not | 17:00 |
Kinnison | If there's no useful constraint on what can differ between foo@bar and foo@baz then they're entirely separate things in the conceptual model | 17:01 |
Kinnison | Hence my confusion, I thought it was just a way to affect which SHA was built from | 17:01 |
* Kinnison admits he didn't follow the conversation very closely as was occupied elsewhere at the time :-( | 17:02 | |
jmacs | So I've managed to build the current ceph-service-x86_64-generic.morph, and I've set the versions of both boost and ceph to the same as the building version in my branch of baserock/sam/chef, but the baserock/sam/chef world still refuses to build boost | 17:02 |
paulsher1ood | Kinnison: the first use case was we had several chunk definitions called 'u-boot' | 17:02 |
paulsher1ood | we now have u-boot@jetson, u-boot@wandboard. people can interpret some meaning from that. and parsing can know that they are not the same chunk | 17:04 |
Kinnison | Right, but in what way is that different from calling them u-boot-jetson u-boot-wandboard etc? | 17:05 |
* Kinnison is trying to determine the semantic value of the @.... | 17:05 | |
paulsher1ood | the @ gives ability to infer that they are both variants of u-boot. we already use - overmuch to achieve that | 17:06 |
Kinnison | So it's purely a convention for humans? | 17:06 |
paulsher1ood | yup | 17:06 |
Kinnison | okay | 17:06 |
paulsher1ood | except that i could, for example easily script to identify which 'chunks' occur more than once | 17:07 |
Kinnison | paulsher1ood: only on the assumption that the convention is followed uniformly | 17:07 |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 17:07 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 17:07 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:07 | |
* Kinnison would likely have advocated '+' over '@' if he'd known it was purely for humans | 17:07 | |
Kinnison | No matter, 'tis done now | 17:07 |
Kinnison | No need to repaint | 17:08 |
paulsher1ood | oh.. i'd be ok switching, not sure what the difference is though | 17:08 |
Kinnison | I read '@' as "at" | 17:08 |
paulsher1ood | radiofree read it as an email address ;) | 17:08 |
Kinnison | thus it implies what is before is a name and what is after is some kind of location or temporal identity | 17:08 |
Kinnison | email addreses fit my parse mechanic | 17:09 |
Kinnison | But so does jeff@12pm | 17:09 |
Kinnison | or u-boot@2b534154 | 17:09 |
Kinnison | anyway, I'm just needing to readjust my expectations, and that's fine | 17:10 |
* Kinnison has to do that all the time :-) | 17:10 | |
jjardon | robtaylor: nice, thanks | 17:14 |
robtaylor | jjardon: np | 17:14 |
* robtaylor is with Kinnison on this, u-boot@jetson reads as 'u-boot at jetson' to me also | 17:16 | |
radiofree | is there a .morph domain name? | 17:17 |
rjek | if you pay for it | 17:17 |
radiofree | maybe we can git send-email patches directly to the files | 17:18 |
radiofree | u-boot@jetson.morph | 17:18 |
robtaylor | heh | 17:20 |
rjek | :) | 17:21 |
jmacs | pdar: Any idea why I'm still getting the 'Boost thread library not found' issue? I'm not convinced it's built it yet, but I don't know how to check | 17:21 |
straycat | heh, so it looks as though the version of setuptools i upgraded us to doesn't play nicely with a particular dependency needed to install openstack packages >.> | 17:21 |
* paulsher1ood still prefers | over @ and +, but would be happy to adopt + if this will lay it to rest :) | 17:22 | |
pdar | jmacs: Can I come see? | 17:23 |
jjardon | Kinnison: to be fair, AFAIK none of my changes broke any system already in definitions, and no one told me about specific network configurations I was not aware of when I submitted the patches. Saying that Id be happy to take a look when I have some time if someone put a system in definitions I can test against | 17:23 |
jmacs | pdar: Sure | 17:23 |
Kinnison | jjardon: I raised the issue the moment I saw the patches and was told it was "handled" | 17:23 |
Kinnison | paulsher1ood: I'm fine with '@' being the token you chose | 17:24 |
paulsher1ood | ok, thanks | 17:24 |
Kinnison | paulsher1ood: I would argue that '|' is a very dangerous metacharacter | 17:24 |
Kinnison | paulsher1ood: esp. if someone wrote a definitions processor in shell :-) | 17:24 |
DavePage | Kinnison: Ceci n'est pas un pipe? | 17:24 |
Kinnison | DavePage: well done, here's an apple | 17:25 |
richard_maw | Kinnison: I'd argue that's a good reason to put it in, so people don't do something so silly as to use shell and not sanitise their input | 17:25 |
Kinnison | richard_maw: heh | 17:25 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:27 | |
petefoth1 | maybe on the wiki, we could have downloadable scripts (for VBox, for KVM) for those who want to do stuff quickly, along with a narrative pages for each explaining what each script is doing and why for those who want to understand before they get started? | 17:31 |
DavePage | You could have the narrative as comments within the script! | 17:31 |
petefoth1 | Wite the scripts sensibly and the wiki page can *be* the script | 17:31 |
paulsher1ood | show me the code :) | 17:31 |
petefoth1 | DavePage: indeed | 17:32 |
petefoth1 | paulsher1ood: show the code on the wiki page | 17:32 |
petefoth1 | :) | 17:32 |
jjardon | Kinnison: I explicity said (being aware that I could brake something) that the changes will only handle ethernet devices and will configure them with DHCP: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-November/009329.html but we can always revert the patches if you think they are not ready | 17:37 |
paulsher1ood | petefoth1: i meant, why not write the code | 17:37 |
Kinnison | jjardon: I just think that rather than hardcoding the DHCP config in systemd's chunk you should have altered simple-network.configure to create the relevant configuration files :-) | 17:37 |
robtaylor | paulsher1ood: | makes sense in this case for a mathmo =) ('|' reads 'given that') | 17:38 |
petefoth1 | paulsher1ood: I'm thinking about how to write something that displays the content of some file in a wiki page. I have no idea how to do that, but I am sure someone has solved that problem already | 17:40 |
petefoth1 | is that the 'code' you suggest that I write? or...? | 17:41 |
jjardon | Kinnison: sure, but Im not sure when I will have time to do that, thats why my suggestion about the revertion if things are broken for people. Will try to spend some time over the weekend though | 17:41 |
petefoth1 | or just have a link on your quick-start page to the script file in g.b.o | 17:42 |
petefoth1 | with informative comments in your script - which may be there already | 17:43 |
Kinnison | jjardon: I think we should keep moving forwards, and just note this as a failure on my part to be engaged enough to catch the issue before merge :-) | 17:43 |
paulsher1ood | petefoth1: you mentioned having downloadable scripts (for VBox, for KVM) | 17:43 |
petefoth1 | Ah yes. probabaly based on what bashrc wrote on the vm-script page | 17:44 |
* jjardon likes going forward ;) | 17:44 | |
jjardon | is it ok to lorry this? http://paste.baserock.org/ivapixuruy.sql | 17:44 |
paulsher1ood | +1 | 17:45 |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:50 | |
jmacs | Is there an easy way to tell which release of baserock a branch is based on? | 17:56 |
jmacs | baserock/sam/chef in this case | 17:56 |
paulsher1ood | jmacs: have you built it? | 17:57 |
jmacs | Yes | 17:57 |
paulsher1ood | technically it's not 'based on' a release. | 17:57 |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 17:57 | |
paulsher1ood | in a running baserock system, /baserock has metafiles describing every component | 17:58 |
jmacs | Ah, haven't tried actually running it yet | 17:58 |
paulsher1ood | jmacs: you could just untar it for example | 17:58 |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:59 | |
paulsher1ood | but the ref info is in the definition anyway? | 17:59 |
paulsher1ood | what are you actually trying to work out, if i may ask? | 17:59 |
jmacs | I don't think I kept the deployed image unfortunately | 17:59 |
paulsher1ood | jmacs: if you've built it, it'll be cached | 17:59 |
jmacs | Sam's branch won't build ceph-service, and I'm trying to figure out what's changed between sam branching off and 14.40.1 | 18:00 |
paulsher1ood | git diff? | 18:00 |
jmacs | I imagine that'll be quite big | 18:01 |
paulsher1ood | does 14.40.1 built it? | 18:01 |
jmacs | Yes. | 18:01 |
paulsher1ood | you could git bisect, then | 18:01 |
paulsher1ood | or maybe not... please hold | 18:02 |
jmacs | I thought git-bisect required a linear set of commits | 18:02 |
jjardon | robtaylor: as you found it, can I get a +1 from you as well? http://paste.baserock.org/ivapixuruy.sql | 18:03 |
paulsher1ood | jmacs: hence maybe not. | 18:03 |
paulsher1ood | you can work out where a branch diverged from master, though | 18:03 |
straycat | Given, https://bitbucket.org/pypa/setuptools/issue/73/typeerror-dist-must-be-a-distribution#comment-7267980 I don't expect the import tool to be able to import openstack | 18:04 |
straycat | I'm also not sure whether upgrading setuptools may have implications for the existing openstack stuff | 18:04 |
straycat | franred, Have you tried rebuilding openstack stuff recently? | 18:04 |
franred | jjardon, looks ok to me | 18:04 |
franred | straycat, yesterday | 18:05 |
straycat | Okay cool | 18:05 |
franred | but I haven't rebase my branch since 2 weeks ago | 18:05 |
straycat | Okay less cool | 18:05 |
paulsher1ood | jmacs: 14.26 | 18:05 |
paulsher1ood | the magic was... | 18:06 |
paulsher1ood | git merge-base origin/baserock/sam/chef origin/maste | 18:06 |
jjardon | pushed! thanks franred paulsher1ood | 18:06 |
paulsher1ood | git merge-base origin/baserock/sam/chef origin/master (sorry) | 18:06 |
jmacs | merge-base, that rings a bell now | 18:06 |
paulsher1ood | thne.. | 18:06 |
paulsher1ood | git describe --abbrev=0 6523c60a6e918d982ac378beef48e0d3dfa0603e | 18:06 |
paulsher1ood | jmacs: so merge-base is where sam forked, and the describe command finds the latest tag before that | 18:07 |
straycat | franred, What's your branch? | 18:07 |
franred | baserock/franred/openstack | 18:08 |
franred | straycat, ^^ | 18:08 |
straycat | thanks | 18:08 |
jmacs | Thanks paulsher1ood! | 18:08 |
paulsher1ood | jmacs: yw | 18:09 |
robtaylor | jjardon: hsure, +1 | 18:13 |
paulsher1ood | straycat: that setuptools comment is too deep for me, would it make sense to write up the problem and send to the list? | 18:14 |
* paulsher1ood wonders if we can get the arm mason working off the same trove as the x86 one, so they keep in step better? | 18:15 | |
jjardon | mmm, taking a look around, maybe it would be better to pass the configuration directly in the native format, so no script is needed, similar how coreos does: https://coreos.com/docs/cluster-management/setup/network-config-with-networkd/ | 18:19 |
straycat | paulsher1ood, maybe, I'll do some more investigation first | 18:20 |
paulsher1ood | straycat: ok | 18:21 |
radiofree | :\ | 18:55 |
radiofree | why does binutils never seem to get cached? | 18:55 |
radiofree | when doing a deploy with --no-git-update and no network, it complains about that | 18:56 |
radiofree | "Expansion of upstream:binutils-redhat for pullpat yielded...." | 18:56 |
radiofree | and again :\ | 18:58 |
radiofree | any help here? | 18:58 |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 19:05 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 19:05 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Client Quit] | 19:05 | |
*** tiagogomes [~tiagogome@host-89-241-254-215.as13285.net] has joined #baserock | 19:14 | |
*** tiagogomes [~tiagogome@host-89-241-254-215.as13285.net] has quit [Client Quit] | 19:14 | |
paulsher1ood | that sounds like a bug, tbh | 20:56 |
paulsher1ood | i've never understood why deploy needs network at all | 20:56 |
Kinnison | It needs network because it needs to make the build graph to know the artifact to deploy | 20:57 |
paulsher1ood | meh :) | 20:57 |
Kinnison | And it needs network because we're not caching a bunch of the data the server works out for us | 20:57 |
Kinnison | That's the issue | 20:57 |
paulsher1ood | sounds fixable, at least :) | 20:58 |
Kinnison | Sam was looking at it on the train back from London earlier this week | 20:58 |
Kinnison | dunno how far he got | 20:58 |
paulsher1ood | sounds like the demo idea won't work, radiofree | 21:01 |
paulsher1ood | but not to worry | 21:01 |
paulsher1ood | (i can't be sure of network) | 21:01 |
Kinnison | If you have all the git repos cached locally then it will work | 21:12 |
paulsher1ood | i think he's trying to deploy after build. | 21:24 |
*** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 22:46 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!