IRC logs for #baserock for Wednesday, 2015-04-22

*** zoli__ has joined #baserock05:39
*** zoli__ has quit IRC06:19
*** paulw has joined #baserock06:31
*** zoli__ has joined #baserock06:40
*** Albert_ has joined #baserock07:04
*** a1exhughe5 has joined #baserock07:06
SotKgood morning folks!07:13
paulsherwoodKinnison: to get to the bottom of this, please can you confirm git status and tell me HEAD of the definitions you are seeing this issue in?07:30
paulsherwoodand please confirm you're using 74e9e8ce8e1d480c946b17a8f00c1dd98fd267e7 of ybd07:33
*** mike has joined #baserock07:52
*** mike is now known as Guest4705707:53
*** mariaderidder has joined #baserock07:53
straycatrichard_maw, if you're around would you be able to share your opinion on  i don't feel confident merging it as it stands08:01
Kinnisonpaulsherwood: wrt ybd the only changes I have locally are related to deployment, I have 74e9e8ce8e1d480c946b17a8f00c1dd98fd267e7 in my history08:01
Kinnisonpaulsherwood: I'm using 8b0fe30b1bbfe9803a5541119daefbf567ea3483 of definitions currently08:01
*** bashrc_ has joined #baserock08:03
SotKfwiw it does the right thing for me using 74e9e8ce8e1d480c946b17a8f00c1dd98fd267e7 of ybd and 8b0fe30b1bbfe9803a5541119daefbf567ea3483 of definitions08:06
KinnisonI think it's entirely a case of filesystem ordering08:08
KinnisonSotK: could you run it against build-system and capture the log08:08
* Kinnison will work out what line he wants to see in a sec08:08
SotKKinnison: is there any log more verbose than the stuff which ends up on stdout?08:09
SotKif not, then here:
KinnisonI'll review that in a bit08:11
* pedroalvarez sees django and erlang there08:12
SotKnot in the cache key part though08:13
pedroalvarezI didn't notice that. True.08:14
*** rdale has joined #baserock08:16
SotKAnyone mind if I merge
SotKAlso ?08:18
* pedroalvarez does a quick review08:21
pedroalvarezboth merged08:22
straycatSotK, did you have some OSTree changes that needed reviewing?08:23
SotKthanks pedroalvarez08:23
pedroalvarezstraycat: topic:ostree, y think08:24
*** jonathanmaw has joined #baserock08:24
SotKstraycat: yeah,
KinnisonSotK: yep08:28
KinnisonSotK: Your log: 2015-04-22 08:05:05 [python-markdown] ['strata/core.morph', 'strata/python-cliapp.morph', 'strata/python-wsgi.morph'] | ['strata/erlang.morph', 'strata/django.morph', 'strata/xstatic.morph', 'strata/openstack-clients.morph']08:28
KinnisonSotK: My log: 2015-04-22 08:09:11 [python-markdown] ['strata/erlang.morph', 'strata/django.morph', 'strata/xstatic.morph', 'strata/openstack-clients.morph'] | ['strata/core.morph', 'strata/python-cliapp.morph', 'strata/python-wsgi.morph']08:28
Kinnisonnotice the subtle difference?08:28
SotKyours read openstack-services.morph before whatever other stratum its in for some reason08:29
KinnisonI say again -- likely filesystem ordering08:29
straycatSotK, this is a lot of changes08:29
straycatis this a series08:29
straycatI don't know where to start08:29
SotKyeah, its a giant pile of stuff08:31
SotKit starts here
straycatmaybe we should only use gerrit for small changes08:32
SotKthe first four parts of the series are pretty separate from the rest08:33
*** gary_perkins has joined #baserock08:34
SotKand most of the others are changing the various places we use the artifact caches to use the slightly different API the ostree artifact cache has08:34
SotKthen finally some patches which improve a couple of things08:35
*** ssam2 has joined #baserock08:46
*** ChanServ sets mode: +v ssam208:46
pedroalvarezwell, yesterday we found that a bug in our current version of systemd was fixed new master of it. I'm tempted to send a patach for that. What does the people think?08:47
franredpedroalvarez, +1  to the patch08:48
SotKstraycat, anyone else thinking of looking at the OSTree stuff: Hopefully this clears stuff up a little:
pedroalvarezfranred: :) thanks08:53
pedroalvarezI will do a full test before sending the patch08:53
*** Krin has joined #baserock08:55
ssam2weird failure building a trove system from the ostree definitions branch in my chroot:
ssam2git-describe in the failed staging area works fine08:58
ssam2could be something broken in my chroot of course, but it's super weird!08:58
*** edcragg has joined #baserock08:58
* pedroalvarez cant think about what may be causing this error09:02
*** lachlanmackenzie has joined #baserock09:18
pedroalvarezANNOUNCEMENT: I'm going to disable the artifact-cache-write service in, so that we stop creating artifacts there in the cache and I can easily increase the sice of its disk09:22
straycathmm, what file system is?09:23
pedroalvarezThis shouldn't affect to users that are using this artifact cache server09:23
pedroalvarezstraycat: ext409:23
straycatoh well it probably doesn't matter anyway09:23
pedroalvarezRight, they are disabled now09:24
pedroalvarezs/they are/it is/09:25
* pedroalvarez does a final rsync09:25
*** zoli___ has joined #baserock09:27
*** zoli__ has quit IRC09:27
*** CTtpollard has quit IRC09:28
*** CTtpollard has joined #baserock09:32
SotKI'm looking at installing alongside morph09:48
SotKdoes anyone have an opinion on where it should be installed?09:49
franredSotK, will that not make slower the builds? or you plan to run it once?09:49
paulsherwoodSotK: maybe check if there's a more up-to-date version if/when you do that? it's from debian...09:49
SotKI plan to have a separate command to check all the licenses and some other stuff :)09:49
ssam2in morphlib/ would be ok I think09:49
ssam2maybe morphlib/contrib or something so it's not mixed up with the python code09:50
pedroalvarezpaulsherwood: we have updated it few weeks ago, but yeah, there might be newer versions09:50
pedroalvarezSotK: so, nothing like running it at build time, and  populating the metadata with the results then?09:51
SotKpedroalvarez: no09:51
SotKnothing like that :)09:51
richard_mawjjardon: I had to -2 your syslinux update patch, sorry. I don't know if it would cause problems for disk image creation (it may), but it will cause problems for pxeboot, which would break pxeboot.write and the Ironic Conductor09:52
richard_mawtiagogomes_: ^09:55
jjardonrichard_maw: dont worry, whats the Ironic Conductor?09:55
richard_mawan OpenStack component, it manages a tftp server and writes an image to the disk of the target machine, which serves it over iscsi09:57
persiaWould it also affect the non-Ironic hardware deployment mechanism?09:58
richard_mawpersia: "which would break pxeboot.write"09:59
richard_mawsorry, that's a rude way of putting it10:00
richard_mawThe non-Ironic netboot deployment mechanism is called pxeboot.write, which I previously mentioned would be broken10:01
jjardonrichard_maw: could you be more specific why it would cause problems with pxeboot ?10:01
jjardon(If you have time, its not urgent)10:01
richard_mawjjardon: I linked to the syslinux wiki page on the gerrit.10:02
persiaAh.  I thought there was more to that than just pxeboot.write: my apologies.10:02
richard_mawbehaviour changed in version 5, it's no longer a single binary, the initial payload will download the rest of its support code from the tftp server before processing config10:02
richard_mawso we need to copy more files to the tftp root than just pxelinux.010:03
jjardonrichard_maw: thanks for the info10:03
*** ssam2 has quit IRC10:04
richard_mawso we'd need pxeboot.write and the Ironic work to conditionally copy extra support files into the tftproot.10:06
richard_mawIt *should* just be a matter of altering pxeboot.write and openstack-ironic.configure to also install extra files though10:06
richard_mawI'll happily change my -2 to a +1 if that's done, and we've tested that it is sufficient10:08
* richard_maw was hoping to have time to sort out the bootloader situation this week, but that hasn't happened10:09
jjardonrichard_maw: sure, thanks for the review10:11
pedroalvarezhm.. a running baserock system lost its IP,  here the networkd logs:
*** ssam2 has joined #baserock10:19
*** ChanServ sets mode: +v ssam210:19
Kinnisonpedroalvarez: I'd imagine whatever the syntax error is in caused networkd to not bother renewing the lease10:20
pedroalvarezKinnison: restarting networkd fixed this, so I don't think so10:21
pedroalvarezKinnison: oh, worth noting that this file doesn't have any br-ex configuration10:21
KinnisonCheck if there's been anything about not renewing leases?10:21
pedroalvarez(even that the name has br-ex on it)10:21
KinnisonIf you have an isolated network yould try setting the lease time down to say 5 minutes to test more10:22
richard_mawpedroalvarez: If the first useful line in that file is IPForward=yes, then I've had that bug before when I forgot that I should be extending the original config file instead of replacing it10:22
Kinnisonpaulsherwood: Why did you add         call(['mv', cachefile + '.tar', cachefile + '.tar.gz'])10:22
Kinnisonpaulsherwood: in the full_root path ?10:23
pedroalvarezrichard_maw: yeah, I noticed, but I don't think it is related to this error10:23
paulsherwoodKinnison: so the cache algorithm spots that system has been built already10:24
paulsherwooda hack, i acknowledge :)10:24
pedroalvarezKinnison: ah, so that is the reason that  causes networkd to restart? that it has to renew the lease?10:25
Kinnisonpedroalvarez: I'd imagine so10:25
Kinnisonpedroalvarez: DHCP leases last a fixed amount of time10:25
Kinnisonpedroalvarez: maybe 4h in your example10:26
KinnisonOr perhaps 1h renew 4h lifetime10:26
*** ssam2_ has joined #baserock10:26
Kinnisonor 1h renew 3h lifetime10:26
Kinnisondhcp is sometimes "hard" :)10:26
paulsherwoodKinnison: i was/am intending to tidy up later10:26
*** ssam2 has quit IRC10:28
Kinnisonpedroalvarez: You'd need to find the renew, rebind, expire timings for your network to be more certain of what's going on10:28
richard_mawit turns out to have been that an invalid configuration file was being matched against the interface, so there no longer was any config for DHCP10:29
richard_mawso networkd decided that it should no longer have that address10:29
richard_mawso de-configured it10:29
richard_mawand because it was an invalid config file, it didn't provide any new config10:30
* pedroalvarez discovers how useful can be networkctl10:30
richard_mawthe only feature I really miss from the old debian interfaces file that isn't available in networkd is per-interface hostnames10:32
richard_mawand I might have a go at that this weekend if I find time10:32
*** petefoth_ has joined #baserock10:32
*** petefoth has quit IRC10:33
*** petefoth_ is now known as petefoth10:33
jjardonSotK: about ; does that mean that morph will have a hard requirement on linux >= 3.18?10:36
SotKno, it can use unionfs-fuse if overlayfs isn't available10:37
richard_mawyou could also fall-back to copying and using mtimes to determine which files have changed10:38
richard_mawbut FUSE should be sufficient10:38
* Kinnison sighs, inserts:10:39
Kinnison        # 2. do something with it10:39
Kinnison        app.log(this, "No idea what to do now")10:39
* Kinnison sits back to ponder more10:39
ssam2_i like self-doubt in software. too often programs make out like they always know what's best10:40
jjardonSotK: cool, thanks10:41
richard_mawI'm going through the gerrit patch backlog.10:46
richard_mawKinnison: still needs another +1, and I'd prefer it were by someone who knew what was involved10:47
straycatrichard_maw, could look at ?10:47
straycatit speeds up distbuild, but i'm not confident giving it a +110:47
richard_mawstraycat: I was planning to start from the oldest and work towards the newest, as we've a lot of patches that have just sat there10:47
richard_mawI hope I'll get that far, but given I just reviewed series 14, I'm not so sure10:48
* straycat contemplates bribing richard_maw10:48
*** ssam2_ has quit IRC10:49
pdarIm trying to deploy to a baseock openstack system and am getting the following error:
*** zoli___ has quit IRC10:50
pdarMight this be because the deploying system cant resolve "onenode"?10:51
straycatpdar, you're trying to deploy openstack to openstack using the credentials of the system you're deploying rather than the system you're deploying to?10:51
pedroalvarezpdar: try adding " onenode" to the deployer /etc/hosts file10:52
pdarstraycat: Am i?10:52
jjardonrichard_maw: it would be great if you start with the ostree patches, I'd say they are the most important ones at the moment (much more than mine at least :))10:52
pdarpedroalvarez: I tried this and didnt change10:52
straycatpdar, i don't know that's what it looked like10:52
straycatunless the thing you'10:52
straycatre deploying to has the hostname 'onenode'10:53
*** ssam2 has joined #baserock10:53
*** ChanServ sets mode: +v ssam210:53
pdarstraycat: It does, but I didnt tell it anything about onenode in my cluster morph. So I assume it makes contact with and then tries to acces glance using the onenode when trying to validate the credentials10:55
pedroalvarezhm.. so11:06
pedroalvarezdeploying a sytem without setting a HOSTNAME in the morphology11:06
pedroalvarezcauses the deployed system to have the same hostname as the deployer11:06
ssam2yeah, i got bitten by that11:06
pedroalvarezwe could just change the name of the HOSTNAME env variable used in baserock11:07
*** zoli__ has joined #baserock11:08
ssam2hopefully final batch of distbuild fixes from my current project:
ssam2only lightly tested so far, so not ready for merging yet11:11
jjardonSotK: about, I can build ostree-core stratum without the tools stratum at all (you just have to replace - morph: strata/tools.morph for - morph: strata/foundation.morph)11:21
pedroalvarezurgh... Looks like this upgrade isn't honouring "BOOT_DEVICE"11:27
radiofreei think that's an awful bug :\11:28
radiofreeif the thing you're upgrading wasn't deployed with BOOT_DEVICE, it doesn't work11:28
radiofreei think...11:28
radiofreeyou could manually edit the /baserock/deployment thingy and add it11:29
pedroalvarezthen we should put BOOT_DEVICE in the release.morph for jetson systems11:29
pedroalvarezthen figure out other ways to fix it11:29
SotKjjardon: heh, excellent, I'll add it to the cross-bootstrap systems too thne11:30
* pedroalvarez adds BOOT_DEVICE to the deployment metadata and tires again11:30
pedroalvarezand yes, that worked11:35
paulsherwoodKinnison: can i help?11:36
pedroalvarezsystemd master also worked on this jetson11:38
* pedroalvarez just sent a patch to upgrade it11:39
franredpedroalvarez, do you have any logs about the error is got fixed in the new systemd update?  (it would be nice to have a description of it in the commit message)11:49
radiofreered mason is red11:50
SotKradiofree: it'll be because pedroalvarez turned off cache.b.o's writeable cache server11:50
SotKjjardon: are you planning to update the version of OSTree we're using/going to be using?12:01
jjardonSotK: at some point, when everything is merged and settle down12:02
SotKjjardon: excellent, thanks!12:02
*** sambishop has quit IRC12:09
paulsherwoodmason is red... is that a known problem?12:14
petefoth[12:50pm] radiofree: red mason is red12:16
petefoth[12:50pm] SotK: radiofree: it'll be because pedroalvarez turned off cache.b.o's writeable cache server12:16
petefothDon't know if anything is being done to make ti green again12:16
* paulsherwood needs glasses12:16
*** Krin has quit IRC12:16
SotKpedroalvarez: is cache.b.o's writeable cache coming back soon?12:29
Kinnisonpaulsherwood: Right now, unlikely12:34
*** zoli__ has quit IRC12:36
*** zoli__ has joined #baserock12:36
paulsherwoodKinnison: ok12:37
paulsherwoodjonathanmaw: please could you send your email to the GDP maintainer on its list?  strangely it appears to be a yocto-specific list name..
jonathanmawpaulsherwood: ok. Any specific message you want to come across to them other than "here's what I managed in the time available"?12:42
pedroalvarezSotK: yes, soon12:45
SotKpaulsherwood: ^ re: mason12:45
pedroalvarezsomehow, rsync -a --delete decided to delete everything before starting again12:45
pedroalvarezthat's why is taking longer than expected12:47
ssam2pedroalvarez: maybe you need --partial ?12:47
*** locallycompact has joined #baserock12:49
*** Albert_ has quit IRC12:50
*** Albert_ has joined #baserock12:50
paulsherwoodjonathanmaw: i was thinking just send your existing email and ask for any help and guidance13:05
paulsherwoodin other news...13:05
* paulsherwood is to act as GENVI Tools team lead13:05
pedroalvarezpaulsherwood: congrats!13:07
rdalesounds good - is yocto a tool?13:07
paulsherwoodi believe it contains several13:07
* richard_maw is unhappy about the speed-up-artifact-serialisation patches being non-atomically-applicable13:07
KinnisonI think we (as a project) need to think hard about how we want to do longer patch series13:08
Kinnisongerrit doesn't exactly encourage them13:08
* richard_maw is also unhappy with the "new" gerrit interface not displaying dependency information13:08
paulsherwoodwe seem to try everything, eventually :)13:08
Kinnisonpaulsherwood: that's not exactly a useful interjection13:08
richard_mawpaulsherwood: let's not13:08
* paulsherwood will be quiet, now13:09
persiaI think long patch series are hard to review.13:10
persia(no matter how presented)13:10
richard_mawpersia: I definitely agree there13:10
persiaAnd I think it would be better to send small series (or single patches) for review and acceptance before going too far down some path.13:11
* bashrc_ tries to use the gerrit UI sparingly13:11
persiaReduces rework for everyone, but depends on responsive reviewers (which mostly depends on the submitters ability to ask and receive reviews, which may be releated to their own review activity)13:11
KinnisonMy main issue with single-patch review cycles is that it often conflates changes which would be semantically better split out -- but short series can do that13:11
richard_mawbashrc_: a massive patch series is unreviewable because it is massive, completely independently from the UI13:12
* Kinnison therefore votes +1 on any approach which promotes short (but atomic) series13:12
persiaThis isn't to say I'm against patchwork as a tool, just that I think the development process that causes the creation of large patch series is unoptimal, and we should deprecate that regardless of our tooling choices.13:12
* Kinnison is -1 on another wholesale tooling change13:12
richard_mawKinnison: agreed13:13
persiaKinnison: I like the idea of short series: 2-4 patches that make more sense as separate commits.13:13
* Kinnison nods13:13
bashrc_what comprises a large patch series?13:13
KinnisonMore than about 5 patches13:13
richard_mawIMO lines of code is more important to judge a patch series than the number of patches involved13:13
Kinnisonhuge individual patches are also worrisome13:14
bashrc_less than the magical number 7 perhaps13:14
persiaWe'd need a really good reason to change tooling, I agree: my lack of -1 on patchwork was mostly because I don't like to prejudge things, so if we did decide we needed a tooling change, I want another opportunity to have an opinion about any given alternative.13:14
Kinnisonunless they're demonstrably mechanical13:14
ssam2richard_maw: those 3 patches predate Gerrit, they were originally a series on the mailing list that was expected to be applied in sequence13:14
jmacsLike copyright notice updates, for example13:14
persiaFor mechanical patches, I prefer to have the mechanism included in the commit message, so that others can validate the mechanical change was correct.13:14
richard_mawssam2: I know, and it was difficult to review on the mailing list too.13:14
ssam2I agree that working towards having changes be individually appliable is generally a good idea. Although sometimes you just need context.13:15
persiajmacs: Why would that ever be mechanical?13:15
* Kinnison remembers when he used to do code review by printing the delta out and sitting in a meeting room with the developer doing an interactive review13:15
jmacspersia: Change of company name, for example.13:15
Kinnisonin that circumstance "it fits on the table in MR2" was the definition of the maximum size of a change13:15
persiajmacs: That should only change Copyright attribution if the files were changed after the name change (same applies to personal name changes)13:16
SotKI could squash all three into one patch, but I felt like that would be worse13:16
persiaSpecifically, just because some entity (statutory or corporeal) wants to be called something else doesn't give them the right to remove copyright from the prior named entity in the past.13:17
richard_mawit would, but extra scaffolding code would have been required for this to be readable13:17
richard_mawSotK: ^13:17
pedroalvarezANNOUNCEMENT: should be up again13:17
bashrc_in an ideal series each patch should have some distinct reason associated with it. Difficult to review patches are where lots of changes have been made for lots of different reasons13:19
richard_mawbashrc_: that's not sufficient for it to be ideal IMO, it also needs to work in isolation to reduce the context overhead on understanding it13:19
persiaTo confirm, the "long patch series" that sparked this was ?13:19
SotKrichard_maw: How do you mean? Leaving the old serialise code there in the first patch, then squashing 2 and 3 together for example?13:20
richard_mawpersia: it's one of them, is that I'm currently looking at13:20
Kinnisonlocallycompact: I'm sorry for keeping on nit-picking :)13:20
richard_mawSotK: if you couldn't keep the old bits working during the modification period, yes; and then a further patch at the end to remove the bits that were no longer needed13:21
* richard_maw tried to explain this in a response to the ostree series13:21
locallycompactMerge the one that works or don't, I don't care for pedantry13:21
persiaAh, I see.  Even for relatively short series (in the 2-4 range), there's extra work that developers need to do in order to make each commit atomically safe.13:22
Kinnisonlocallycompact: I don't want to merge something which has overloaded names, and I can't merge the most recent series since it has mismatched names13:22
* Kinnison is having enough trouble with overloaded names without introducing more13:23
locallycompactI don't know what that last part means because this builds for me13:27
*** paulwaters_ has joined #baserock13:28
Kinnisonso the last variant you uploaded to gerrit builds with current morph?13:28
* Kinnison mumbles rude rude words13:29
Kinnison(not at locallycompact )13:29
* locallycompact wasn't confused :)13:29
CTtpollardtalking about gerrit, I caught end of this talk at FOSDEM, not sure if it's of any use:
CTtpollard'magic hooks'13:33
richard_mawSotK: Biff re
Albert_How do I add debug to chunks that don't have a configure-commands section? In particular I want to add debug symbolic info to CommonAPI.13:41
richard_mawAlbert_: add your own configure-commands section that has a modified form of the appropriate configure command, depending on what the build-system is13:42
Albert_I tried to do that (naively I'm sure) but it didn't work.13:43
richard_mawwell, it's what you'd have to do, did it ignore the command you specified, or did you put one in that wasn't compatible with the automatically entered configure commands?13:44
Albert_It broke13:44
richard_mawprobably the latter then13:45
richard_mawyou'll have to find someone familiar with how CommonAPI is normally built13:45
richard_mawjonathanmaw or pedroalvarez maybe ^13:45
Albert_thanks richard_maw13:46
pedroalvarezAlbert_: can you show us the modified chunk that is not building?13:47
Albert_I'll have to check because I deleted it13:47
richard_mawSotK: Biff re
SotKrichard_maw: ty13:48
richard_mawSotK: you won't say that when you see my response13:49
ssam2SotK: if you haven't already fixed the thing I complained about on Gerrit,
ssam2i had to fix it locally anyway13:50
SotKssam2: thanks13:52
SotKrichard_maw: at least its being reviewed at last13:52
Albert_pedroalvarez, I think I tried something like this:
richard_mawSotK: yeah, sorry I haven't been able to do my usual wednesday reviews for the past 3 weeks13:54
* richard_maw needs a whole day for big reviews, which is another reason to keep patches small13:54
SotKrichard_maw: no problem :)13:55
pedroalvarezAlbert_: this should be more equivalent to the current instructions:
Albert_Thanks pedroalvarez13:58
* ssam2 wonders if there's a way to detect whether a system /doesn't/ have overlayfs, to avoid having to modify distbuild-setup13:59
ssam2I guess modifying distbuild-setup to have an extra parameter isn't hard, but i wish it wasn't needed13:59
*** locallycompact has quit IRC13:59
ssam2currenlty the ostree-branch of morph requires you to set '--union-filesystem=unionfs-fuse' to make it use unionfs-fuse13:59
pedroalvarezAlbert_: I guess you still want to --disable-acl, though14:00
pedroalvarezAlbert_: you still have errors building that, let us know14:01
SotKssam2: can you check the kernel version somehow?14:01
*** Krin has joined #baserock14:01
richard_mawSotK: we should be checking the kernel features, not kernel version14:02
persiaThere's no realiable way to determine what modules have been built into a kernel.14:02
SotKah yes, ignore me14:02
radiofreepersia: you could grep /proc/config.gz14:02
persiaeasy enough to play with modprobe and lsmod for external modules.14:02
Albert_pedroalvarez, What does --disable-acl do?14:02
persiaradiofree: Doesn't always exist (because enabling it is a kernel config option)14:03
radiofreeit exists in baserock, that's what we're talking about here?14:03
pedroalvarezAlbert_: ew, I mentioned that because it was in the build instructions you sent me:
richard_mawAlbert: it's because our acl chunk is buggered, we've not built it as a shared library, so anything which provides a library can't use it, just final binaries like btrfs-progs14:03
Albert_Sorry, not paying proper attention14:04
persiaradiofree: It isn't guaranteed to exist in Baserock, because people can fiddle the config.  Also, if I had my way, Baserock would not assume the substrate was linux.14:05
Albert_Yeah, pedroalvarez, that was already on and I didn't really notice. I would presumably have it the same except with debug.14:06
Albert_richard_maw, so I need to remove it?14:06
richard_mawno, you need --disable-acl or the build system will try to use something that won't work, and bugger up later14:07
richard_mawwe'd need to fix acl before we can remove --disable-acl14:07
Albert_Oh I get it14:07
richard_mawSotK: Biff re
*** locallycompact has joined #baserock14:14
*** ssam2 has quit IRC14:16
*** ssam2_ has joined #baserock14:16
richard_mawthere were a few alternative tools for interacting with gerrit menioned earlier, what were they apart from git-review?14:50
* richard_maw is hoping to find one that includes dependency information14:50
ssam2_if you do `git-review -d 327` (where 327 is the top change of the branch you want) it fetches you a branch with that change and everything it depends on14:51
richard_mawthanks Kinnison14:51
* petefoth thinks 'git gerrymander' should be a valid command14:52
richard_mawpetefoth: too comprehensible14:52
petefothrichard_maw: probably14:52
persiarichard_maw: gertty14:59
* pedroalvarez failed to set up gertty15:00
* richard_maw is annoyed by google auto-correcting gertty to getty15:00
persiaI think gertty needed some special gerrit config.  I don't remember if that got enabled.15:04
persiaBut `pip install gertty` should be a lightweight way to try it.15:04
Kinnison2015-04-22 14:17:49 [] WARNING: Need to find extensions now15:06
* Kinnison proceeds15:06
* Kinnison progresses even15:06
KinnisonSo. little. brain. left.15:06
*** petefoth has quit IRC15:07
*** robtaylo1 is now known as robtaylor15:30
*** Guest47057 has quit IRC15:33
richard_mawwell, gertty is failing to authorize15:33
* richard_maw checks whether he put is credentials in correctly15:33
*** jonathanmaw has quit IRC15:33
persiarichard_maw: We might need something on the gerrit side: I seem to remember ssam2_talking about that before.15:35
richard_mawI've found no information about what needs to be enabled15:35
radiofreei thought it was just https?15:37
persiaThat seems to match my memory, but we did that.15:38
persiaProbably needs someone to have a go from both sides to find out.15:38
franredrichard_maw, Im going to merge this and I will fix the few comments from pdar in my patch series about ceilometer in multinode - is that right for both of us?15:43
richard_mawsounds fine to me15:43
*** a1exhughe5 has quit IRC15:44
richard_mawwell, using digest auth stops it failing to authenticate, but I'm not yet seeing any changes15:45
franredrichard_maw, pdar, merged15:50
richard_mawgertty claims that the reason it can't work is that the download-commands plugin is missing from the server15:56
ssam2_that is true15:56
KinnisonDo we have a spare weekend to restart gerrit in?15:56
ssam2_is that the royal 'we' ?15:57
KinnisonNo, it's more the "ssam2_ we"15:57
ssam2_ah. it takes 10 minutes or so, but i'm afraid I don't have 10 minutes free until about May time15:57
KinnisonSo not that long to wait15:57
ssam2_pedro, fran or Gary can also do this15:57
* richard_maw abandons the idea of having a nice interface to review with and works out how to make gerrit's web UI back to the old form, so he can see dependencies16:05
pedroalvarezI'll make a note to enable that, if the only thing needed is enabling it and a restart16:08
ssam2_thanks! note that to /get/ plugins, the easiest way is to extract them from the gerrit .war file, if present16:11
ssam2_like this:
ssam2_i wasted ages looking for how to download them from the gerrit project's web page16:12
pedroalvarezssam2_: useful info, thanks!16:17
*** zoli__ has quit IRC16:40
*** zoli__ has joined #baserock16:41
*** zoli__ has quit IRC16:41
*** mariaderidder has quit IRC16:55
jjardonHi, Ive successfully natively built the bootstrap Baserock tarball as explained in the point 3 in ; where is the result system created? my 'native-bootstrap' seems that only build the different components, not build a final rootfs16:56
jjardonthis is how the native-bootstrap script looks like:
pedroalvarezjjardon: they are on the same system you are running16:57
pedroalvarezjjardon: try running `morph --version`16:57
pedroalvarezwith "they are on the same system" I mean that the things that script have built, are installed on /16:59
jjardonpedroalvarez: yeah, but is native-bootstrap not meant to build a rootfs (tarball)?17:01
pedroalvareznative-bootstrap exsist to do the native building part of the cross-bootstrap process17:02
pedroalvarezthe result is not a new rootfs, is your current rootfs modified17:02
bashrc_fixed an error with one of the firehose patches17:02
*** bashrc_ has quit IRC17:04
pedroalvarezjjardon: now from where you are you can just use Morph17:04
jjardonpedroalvarez: mmm, what is the tarball the docs are talking about in the point 4 in then? a manually generated one?17:04
pedroalvarezis the same one you are currently chrooted in17:05
pedroalvarezpoint 4 is confusing and wrong17:05
pedroalvarezit should say something like: "After running native-bootstrap script, you will be in a system with Morph and everything needed to start building using baserock"17:06
pedroalvarezI think that when I wrote it I thought that step 3 generated another rootfs17:07
* ssam2_ successfully deploys a 'build' system to .tar on a Calxeda node, using unionfs-fuse and OSTree17:08
ssam2_exactly 1 minute 30 to do that17:08
ssam2_of which about 55 seconds is writing the 2GB .tar file17:08
jjardonSotK: thanks for this!17:11
*** simonh_ has quit IRC17:19
franredssam2_, that is pretty impressive!! :D17:20
* SotK takes 1min39s to construct a trove system artifact17:27
*** gary_perkins has quit IRC17:31
*** ssam2_ has quit IRC17:31
*** gary_perkins has joined #baserock17:31
*** Krin has quit IRC17:36
jjardonpedroalvarez: thanks. I think a note to add/configure /etc/resolv.conf should be added as well. Will try to add something later17:36
*** locallycompact has quit IRC17:39
*** franred has quit IRC17:41
*** gary_perkins_ has joined #baserock17:44
*** gary_perkins has quit IRC17:45
*** zoli__ has joined #baserock17:56
*** rdale has quit IRC17:56
*** edcragg has quit IRC18:00
*** zoli__ has quit IRC18:18
*** lachlanmackenzie has quit IRC18:37
*** Albert_ has quit IRC18:46
*** gary_perkins_ has quit IRC19:27
*** zoli__ has joined #baserock20:05
*** edcragg has joined #baserock20:32
*** edcragg has quit IRC22:03
*** zoli__ has quit IRC23:33

Generated by 2.15.3 by Marius Gedminas - find it at!