*** zoli__ has joined #baserock | 05:39 | |
*** zoli__ has quit IRC | 06:19 | |
*** paulw has joined #baserock | 06:31 | |
*** zoli__ has joined #baserock | 06:40 | |
*** Albert_ has joined #baserock | 07:04 | |
*** a1exhughe5 has joined #baserock | 07:06 | |
SotK | good morning folks! | 07:13 |
---|---|---|
paulsherwood | howdie | 07:29 |
paulsherwood | Kinnison: 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 |
paulsherwood | and please confirm you're using 74e9e8ce8e1d480c946b17a8f00c1dd98fd267e7 of ybd | 07:33 |
SotK | -h | 07:35 |
SotK | bah | 07:35 |
*** mike has joined #baserock | 07:52 | |
*** mike is now known as Guest47057 | 07:53 | |
*** mariaderidder has joined #baserock | 07:53 | |
straycat | richard_maw, if you're around would you be able to share your opinion on https://gerrit.baserock.org/#/c/341/3 i don't feel confident merging it as it stands | 08:01 |
Kinnison | paulsherwood: wrt ybd the only changes I have locally are related to deployment, I have 74e9e8ce8e1d480c946b17a8f00c1dd98fd267e7 in my history | 08:01 |
Kinnison | paulsherwood: I'm using 8b0fe30b1bbfe9803a5541119daefbf567ea3483 of definitions currently | 08:01 |
*** bashrc_ has joined #baserock | 08:03 | |
SotK | fwiw it does the right thing for me using 74e9e8ce8e1d480c946b17a8f00c1dd98fd267e7 of ybd and 8b0fe30b1bbfe9803a5541119daefbf567ea3483 of definitions | 08:06 |
Kinnison | I think it's entirely a case of filesystem ordering | 08:08 |
Kinnison | SotK: could you run it against build-system and capture the log | 08:08 |
* Kinnison will work out what line he wants to see in a sec | 08:08 | |
SotK | Kinnison: is there any log more verbose than the stuff which ends up on stdout? | 08:09 |
SotK | if not, then here: http://paste.baserock.org/lituwagihu | 08:10 |
Kinnison | I'll review that in a bit | 08:11 |
* pedroalvarez sees django and erlang there | 08:12 | |
SotK | not in the cache key part though | 08:13 |
pedroalvarez | I didn't notice that. True. | 08:14 |
*** rdale has joined #baserock | 08:16 | |
SotK | Anyone mind if I merge https://gerrit.baserock.org/#/c/415/? | 08:17 |
SotK | Also https://gerrit.baserock.org/#/c/235/ ? | 08:18 |
* pedroalvarez does a quick review | 08:21 | |
pedroalvarez | both merged | 08:22 |
straycat | SotK, did you have some OSTree changes that needed reviewing? | 08:23 |
SotK | thanks pedroalvarez | 08:23 |
pedroalvarez | straycat: topic:ostree, y think | 08:24 |
*** jonathanmaw has joined #baserock | 08:24 | |
pedroalvarez | s/y/I/ | 08:24 |
SotK | straycat: yeah, https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:ostree-staging | 08:24 |
Kinnison | SotK: yep | 08:28 |
Kinnison | SotK: 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 |
Kinnison | SotK: 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 |
Kinnison | notice the subtle difference? | 08:28 |
SotK | yep | 08:29 |
SotK | yours read openstack-services.morph before whatever other stratum its in for some reason | 08:29 |
Kinnison | I say again -- likely filesystem ordering | 08:29 |
straycat | SotK, this is a lot of changes | 08:29 |
straycat | is this a series | 08:29 |
straycat | I don't know where to start | 08:29 |
SotK | yeah, its a giant pile of stuff | 08:31 |
SotK | it starts here https://gerrit.baserock.org/#/c/287/2 | 08:31 |
straycat | maybe we should only use gerrit for small changes | 08:32 |
SotK | the first four parts of the series are pretty separate from the rest | 08:33 |
*** gary_perkins has joined #baserock | 08:34 | |
SotK | and most of the others are changing the various places we use the artifact caches to use the slightly different API the ostree artifact cache has | 08:34 |
SotK | then finally some patches which improve a couple of things | 08:35 |
*** ssam2 has joined #baserock | 08:46 | |
*** ChanServ sets mode: +v ssam2 | 08:46 | |
pedroalvarez | well, 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 |
franred | pedroalvarez, +1 to the patch | 08:48 |
SotK | straycat, anyone else thinking of looking at the OSTree stuff: Hopefully this clears stuff up a little: http://paste.baserock.org/enotowaris | 08:51 |
pedroalvarez | franred: :) thanks | 08:53 |
pedroalvarez | I will do a full test before sending the patch | 08:53 |
*** Krin has joined #baserock | 08:55 | |
ssam2 | weird failure building a trove system from the ostree definitions branch in my chroot: http://paste.baserock.org/yokiwogaca | 08:57 |
ssam2 | git-describe in the failed staging area works fine | 08:58 |
ssam2 | could be something broken in my chroot of course, but it's super weird! | 08:58 |
*** edcragg has joined #baserock | 08:58 | |
* pedroalvarez cant think about what may be causing this error | 09:02 | |
*** lachlanmackenzie has joined #baserock | 09:18 | |
pedroalvarez | ANNOUNCEMENT: I'm going to disable the artifact-cache-write service in cache.baserock.org, so that we stop creating artifacts there in the cache and I can easily increase the sice of its disk | 09:22 |
straycat | hmm, what file system is? | 09:23 |
straycat | it | 09:23 |
pedroalvarez | This shouldn't affect to users that are using this artifact cache server | 09:23 |
pedroalvarez | straycat: ext4 | 09:23 |
straycat | oh well it probably doesn't matter anyway | 09:23 |
pedroalvarez | Right, they are disabled now | 09:24 |
pedroalvarez | s/they are/it is/ | 09:25 |
* pedroalvarez does a final rsync | 09:25 | |
*** zoli___ has joined #baserock | 09:27 | |
*** zoli__ has quit IRC | 09:27 | |
*** CTtpollard has quit IRC | 09:28 | |
*** CTtpollard has joined #baserock | 09:32 | |
SotK | I'm looking at installing licensecheck.pl alongside morph | 09:48 |
SotK | does anyone have an opinion on where it should be installed? | 09:49 |
franred | SotK, will that not make slower the builds? or you plan to run it once? | 09:49 |
paulsherwood | SotK: maybe check if there's a more up-to-date version if/when you do that? it's from debian... | 09:49 |
SotK | I plan to have a separate command to check all the licenses and some other stuff :) | 09:49 |
ssam2 | in morphlib/ would be ok I think | 09:49 |
ssam2 | maybe morphlib/contrib or something so it's not mixed up with the python code | 09:50 |
pedroalvarez | paulsherwood: we have updated it few weeks ago, but yeah, there might be newer versions | 09:50 |
pedroalvarez | SotK: so, nothing like running it at build time, and populating the metadata with the results then? | 09:51 |
SotK | pedroalvarez: no | 09:51 |
SotK | nothing like that :) | 09:51 |
richard_maw | jjardon: 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 Conductor | 09:52 |
richard_maw | tiagogomes_: ^ | 09:55 |
jjardon | richard_maw: dont worry, whats the Ironic Conductor? | 09:55 |
richard_maw | an OpenStack component, it manages a tftp server and writes an image to the disk of the target machine, which serves it over iscsi | 09:57 |
persia | Would it also affect the non-Ironic hardware deployment mechanism? | 09:58 |
richard_maw | persia: "which would break pxeboot.write" | 09:59 |
richard_maw | sorry, that's a rude way of putting it | 10:00 |
richard_maw | The non-Ironic netboot deployment mechanism is called pxeboot.write, which I previously mentioned would be broken | 10:01 |
jjardon | richard_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_maw | jjardon: I linked to the syslinux wiki page on the gerrit. | 10:02 |
persia | Ah. I thought there was more to that than just pxeboot.write: my apologies. | 10:02 |
richard_maw | behaviour 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 config | 10:02 |
richard_maw | so we need to copy more files to the tftp root than just pxelinux.0 | 10:03 |
jjardon | richard_maw: thanks for the info | 10:03 |
*** ssam2 has quit IRC | 10:04 | |
richard_maw | so we'd need pxeboot.write and the Ironic work to conditionally copy extra support files into the tftproot. | 10:06 |
richard_maw | It *should* just be a matter of altering pxeboot.write and openstack-ironic.configure to also install extra files though | 10:06 |
richard_maw | I'll happily change my -2 to a +1 if that's done, and we've tested that it is sufficient | 10:08 |
* richard_maw was hoping to have time to sort out the bootloader situation this week, but that hasn't happened | 10:09 | |
jjardon | richard_maw: sure, thanks for the review | 10:11 |
pedroalvarez | hm.. a running baserock system lost its IP, here the networkd logs: http://paste.baserock.org/ibatefajey | 10:18 |
*** ssam2 has joined #baserock | 10:19 | |
*** ChanServ sets mode: +v ssam2 | 10:19 | |
Kinnison | pedroalvarez: I'd imagine whatever the syntax error is in 10-br-ex-dhcp.network caused networkd to not bother renewing the lease | 10:20 |
pedroalvarez | Kinnison: restarting networkd fixed this, so I don't think so | 10:21 |
pedroalvarez | Kinnison: oh, worth noting that this file doesn't have any br-ex configuration | 10:21 |
Kinnison | Check if there's been anything about not renewing leases? | 10:21 |
pedroalvarez | (even that the name has br-ex on it) | 10:21 |
Kinnison | If you have an isolated network yould try setting the lease time down to say 5 minutes to test more | 10:22 |
richard_maw | pedroalvarez: 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 it | 10:22 |
Kinnison | paulsherwood: Why did you add call(['mv', cachefile + '.tar', cachefile + '.tar.gz']) | 10:22 |
Kinnison | paulsherwood: in the full_root path ? | 10:23 |
pedroalvarez | richard_maw: yeah, I noticed, but I don't think it is related to this error | 10:23 |
paulsherwood | Kinnison: so the cache algorithm spots that system has been built already | 10:24 |
paulsherwood | a hack, i acknowledge :) | 10:24 |
Kinnison | Blreurgh | 10:25 |
pedroalvarez | Kinnison: ah, so that is the reason that causes networkd to restart? that it has to renew the lease? | 10:25 |
Kinnison | pedroalvarez: I'd imagine so | 10:25 |
Kinnison | pedroalvarez: DHCP leases last a fixed amount of time | 10:25 |
Kinnison | pedroalvarez: maybe 4h in your example | 10:26 |
Kinnison | Or perhaps 1h renew 4h lifetime | 10:26 |
*** ssam2_ has joined #baserock | 10:26 | |
Kinnison | or 1h renew 3h lifetime | 10:26 |
Kinnison | dhcp is sometimes "hard" :) | 10:26 |
paulsherwood | Kinnison: i was/am intending to tidy up later | 10:26 |
*** ssam2 has quit IRC | 10:28 | |
Kinnison | pedroalvarez: You'd need to find the renew, rebind, expire timings for your network to be more certain of what's going on | 10:28 |
richard_maw | it turns out to have been that an invalid configuration file was being matched against the interface, so there no longer was any config for DHCP | 10:29 |
richard_maw | so networkd decided that it should no longer have that address | 10:29 |
richard_maw | so de-configured it | 10:29 |
richard_maw | and because it was an invalid config file, it didn't provide any new config | 10:30 |
Kinnison | doh | 10:30 |
* pedroalvarez discovers how useful can be networkctl | 10:30 | |
richard_maw | the only feature I really miss from the old debian interfaces file that isn't available in networkd is per-interface hostnames | 10:32 |
richard_maw | and I might have a go at that this weekend if I find time | 10:32 |
*** petefoth_ has joined #baserock | 10:32 | |
*** petefoth has quit IRC | 10:33 | |
*** petefoth_ is now known as petefoth | 10:33 | |
jjardon | SotK: about https://gerrit.baserock.org/#/c/364/ ; does that mean that morph will have a hard requirement on linux >= 3.18? | 10:36 |
SotK | no, it can use unionfs-fuse if overlayfs isn't available | 10:37 |
richard_maw | you could also fall-back to copying and using mtimes to determine which files have changed | 10:38 |
richard_maw | but FUSE should be sufficient | 10:38 |
* Kinnison sighs, inserts: | 10:39 | |
Kinnison | # 2. do something with it | 10:39 |
Kinnison | app.log(this, "No idea what to do now") | 10:39 |
* Kinnison sits back to ponder more | 10:39 | |
ssam2_ | i like self-doubt in software. too often programs make out like they always know what's best | 10:40 |
jjardon | SotK: cool, thanks | 10:41 |
richard_maw | I'm going through the gerrit patch backlog. | 10:46 |
richard_maw | Kinnison: https://gerrit.baserock.org/#/c/133/ still needs another +1, and I'd prefer it were by someone who knew what was involved | 10:47 |
straycat | richard_maw, could look at https://gerrit.baserock.org/#/c/341/ ? | 10:47 |
straycat | it speeds up distbuild, but i'm not confident giving it a +1 | 10:47 |
richard_maw | straycat: I was planning to start from the oldest and work towards the newest, as we've a lot of patches that have just sat there | 10:47 |
richard_maw | I hope I'll get that far, but given I just reviewed series 14, I'm not so sure | 10:48 |
* straycat contemplates bribing richard_maw | 10:48 | |
*** ssam2_ has quit IRC | 10:49 | |
pdar | Im trying to deploy to a baseock openstack system and am getting the following error: http://paste.baserock.org/alotacutey | 10:50 |
*** zoli___ has quit IRC | 10:50 | |
pdar | Might this be because the deploying system cant resolve "onenode"? | 10:51 |
straycat | pdar, 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 |
pedroalvarez | pdar: try adding "10.24.1.79 onenode" to the deployer /etc/hosts file | 10:52 |
pdar | straycat: Am i? | 10:52 |
jjardon | richard_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 |
pdar | pedroalvarez: I tried this and didnt change | 10:52 |
straycat | pdar, i don't know that's what it looked like | 10:52 |
straycat | unless the thing you' | 10:52 |
straycat | re deploying to has the hostname 'onenode' | 10:53 |
*** ssam2 has joined #baserock | 10:53 | |
*** ChanServ sets mode: +v ssam2 | 10:53 | |
pdar | straycat: It does, but I didnt tell it anything about onenode in my cluster morph. So I assume it makes contact with 10.24.1.79 and then tries to acces glance using the onenode when trying to validate the credentials | 10:55 |
pedroalvarez | hm.. so | 11:06 |
pedroalvarez | deploying a sytem without setting a HOSTNAME in the morphology | 11:06 |
pedroalvarez | causes the deployed system to have the same hostname as the deployer | 11:06 |
ssam2 | yeah, i got bitten by that | 11:06 |
pedroalvarez | we could just change the name of the HOSTNAME env variable used in baserock | 11:07 |
*** zoli__ has joined #baserock | 11:08 | |
ssam2 | hopefully final batch of distbuild fixes from my current project: https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:master+topic:sam/distbuild-controller-job-tracking | 11:11 |
ssam2 | only lightly tested so far, so not ready for merging yet | 11:11 |
jjardon | SotK: about https://gerrit.baserock.org/#/c/367/, 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 |
pedroalvarez | urgh... Looks like this upgrade isn't honouring "BOOT_DEVICE" | 11:27 |
radiofree | i think that's an awful bug :\ | 11:28 |
radiofree | if the thing you're upgrading wasn't deployed with BOOT_DEVICE, it doesn't work | 11:28 |
radiofree | i think... | 11:28 |
pedroalvarez | ew | 11:28 |
radiofree | you could manually edit the /baserock/deployment thingy and add it | 11:29 |
pedroalvarez | then we should put BOOT_DEVICE in the release.morph for jetson systems | 11:29 |
pedroalvarez | then figure out other ways to fix it | 11:29 |
SotK | jjardon: heh, excellent, I'll add it to the cross-bootstrap systems too thne | 11:30 |
* pedroalvarez adds BOOT_DEVICE to the deployment metadata and tires again | 11:30 | |
pedroalvarez | and yes, that worked | 11:35 |
paulsherwood | Kinnison: can i help? | 11:36 |
pedroalvarez | systemd master also worked on this jetson | 11:38 |
* pedroalvarez just sent a patch to upgrade it | 11:39 | |
franred | pedroalvarez, 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 |
radiofree | red mason is red | 11:50 |
SotK | radiofree: it'll be because pedroalvarez turned off cache.b.o's writeable cache server | 11:50 |
radiofree | ah | 11:53 |
SotK | jjardon: are you planning to update the version of OSTree we're using/going to be using? | 12:01 |
jjardon | SotK: at some point, when everything is merged and settle down | 12:02 |
SotK | jjardon: excellent, thanks! | 12:02 |
*** sambishop has quit IRC | 12:09 | |
paulsherwood | mason is red... is that a known problem? | 12:14 |
petefoth | paulsherwood: | 12:16 |
petefoth | [12:50pm] radiofree: red mason is red | 12:16 |
petefoth | [12:50pm] SotK: radiofree: it'll be because pedroalvarez turned off cache.b.o's writeable cache server | 12:16 |
paulsherwood | aha | 12:16 |
petefoth | Don't know if anything is being done to make ti green again | 12:16 |
* paulsherwood needs glasses | 12:16 | |
*** Krin has quit IRC | 12:16 | |
SotK | pedroalvarez: is cache.b.o's writeable cache coming back soon? | 12:29 |
Kinnison | paulsherwood: Right now, unlikely | 12:34 |
*** zoli__ has quit IRC | 12:36 | |
*** zoli__ has joined #baserock | 12:36 | |
paulsherwood | Kinnison: ok | 12:37 |
paulsherwood | jonathanmaw: please could you send your email to the GDP maintainer on its list? strangely it appears to be a yocto-specific list name..https://lists.genivi.org/mailman/listinfo/genivi-meta-ivi | 12:38 |
jonathanmaw | paulsherwood: ok. Any specific message you want to come across to them other than "here's what I managed in the time available"? | 12:42 |
pedroalvarez | SotK: yes, soon | 12:45 |
SotK | paulsherwood: ^ re: mason | 12:45 |
pedroalvarez | somehow, rsync -a --delete decided to delete everything before starting again | 12:45 |
SotK | :( | 12:46 |
pedroalvarez | that's why is taking longer than expected | 12:47 |
ssam2 | pedroalvarez: maybe you need --partial ? | 12:47 |
*** locallycompact has joined #baserock | 12:49 | |
*** Albert_ has quit IRC | 12:50 | |
*** Albert_ has joined #baserock | 12:50 | |
paulsherwood | jonathanmaw: i was thinking just send your existing email and ask for any help and guidance | 13:05 |
paulsherwood | in other news... | 13:05 |
* paulsherwood is to act as GENVI Tools team lead | 13:05 | |
pedroalvarez | paulsherwood: congrats! | 13:07 |
rdale | sounds good - is yocto a tool? | 13:07 |
paulsherwood | i believe it contains several | 13:07 |
* richard_maw is unhappy about the speed-up-artifact-serialisation patches being non-atomically-applicable | 13:07 | |
Kinnison | I think we (as a project) need to think hard about how we want to do longer patch series | 13:08 |
Kinnison | gerrit doesn't exactly encourage them | 13:08 |
paulsherwood | patchwork? | 13:08 |
* richard_maw is also unhappy with the "new" gerrit interface not displaying dependency information | 13:08 | |
paulsherwood | we seem to try everything, eventually :) | 13:08 |
Kinnison | paulsherwood: that's not exactly a useful interjection | 13:08 |
richard_maw | paulsherwood: let's not | 13:08 |
* paulsherwood will be quiet, now | 13:09 | |
persia | I think long patch series are hard to review. | 13:10 |
persia | (no matter how presented) | 13:10 |
richard_maw | persia: I definitely agree there | 13:10 |
persia | And 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 sparingly | 13:11 | |
persia | Reduces 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 |
Kinnison | My 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 that | 13:11 |
richard_maw | bashrc_: a massive patch series is unreviewable because it is massive, completely independently from the UI | 13:12 |
* Kinnison therefore votes +1 on any approach which promotes short (but atomic) series | 13:12 | |
persia | This 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 change | 13:12 | |
richard_maw | Kinnison: agreed | 13:13 |
persia | Kinnison: I like the idea of short series: 2-4 patches that make more sense as separate commits. | 13:13 |
* Kinnison nods | 13:13 | |
bashrc_ | what comprises a large patch series? | 13:13 |
Kinnison | More than about 5 patches | 13:13 |
richard_maw | IMO lines of code is more important to judge a patch series than the number of patches involved | 13:13 |
Kinnison | huge individual patches are also worrisome | 13:14 |
bashrc_ | less than the magical number 7 perhaps | 13:14 |
persia | We'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 |
Kinnison | unless they're demonstrably mechanical | 13:14 |
ssam2 | richard_maw: those 3 patches predate Gerrit, they were originally a series on the mailing list that was expected to be applied in sequence | 13:14 |
jmacs | Like copyright notice updates, for example | 13:14 |
persia | For 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_maw | ssam2: I know, and it was difficult to review on the mailing list too. | 13:14 |
ssam2 | I agree that working towards having changes be individually appliable is generally a good idea. Although sometimes you just need context. | 13:15 |
persia | jmacs: 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 review | 13:15 | |
jmacs | persia: Change of company name, for example. | 13:15 |
Kinnison | in that circumstance "it fits on the table in MR2" was the definition of the maximum size of a change | 13:15 |
bashrc_ | :) | 13:16 |
persia | jmacs: That should only change Copyright attribution if the files were changed after the name change (same applies to personal name changes) | 13:16 |
SotK | I could squash all three into one patch, but I felt like that would be worse | 13:16 |
persia | Specifically, 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_maw | it would, but extra scaffolding code would have been required for this to be readable | 13:17 |
richard_maw | SotK: ^ | 13:17 |
pedroalvarez | ANNOUNCEMENT: cache.baserock.org should be up again | 13: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 reasons | 13:19 |
richard_maw | bashrc_: that's not sufficient for it to be ideal IMO, it also needs to work in isolation to reduce the context overhead on understanding it | 13:19 |
persia | To confirm, the "long patch series" that sparked this was https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:ostree-staging+topic:ostree ? | 13:19 |
SotK | richard_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_maw | persia: it's one of them, https://gerrit.baserock.org/#/q/topic:speed-up-artifact-serialisation is that I'm currently looking at | 13:20 |
Kinnison | locallycompact: I'm sorry for keeping on nit-picking :) | 13:20 |
richard_maw | SotK: 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 needed | 13:21 |
* richard_maw tried to explain this in a response to the ostree series | 13:21 | |
locallycompact | Merge the one that works or don't, I don't care for pedantry | 13:21 |
persia | Ah, 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 |
Kinnison | locallycompact: I don't want to merge something which has overloaded names, and I can't merge the most recent series since it has mismatched names | 13:22 |
* Kinnison is having enough trouble with overloaded names without introducing more | 13:23 | |
locallycompact | I don't know what that last part means because this builds for me | 13:27 |
locallycompact | # | 13:27 |
*** paulwaters_ has joined #baserock | 13:28 | |
Kinnison | so the last variant you uploaded to gerrit builds with current morph? | 13:28 |
locallycompact | yeah | 13:28 |
* Kinnison mumbles rude rude words | 13:29 | |
Kinnison | (not at locallycompact ) | 13:29 |
* locallycompact wasn't confused :) | 13:29 | |
CTtpollard | talking about gerrit, I caught end of this talk at FOSDEM, not sure if it's of any use: https://fosdem.org/2015/schedule/event/gerrit_hooks/ | 13:33 |
CTtpollard | 'magic hooks' | 13:33 |
richard_maw | SotK: Biff re https://gerrit.baserock.org/#/c/342/2 | 13:35 |
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_maw | Albert_: add your own configure-commands section that has a modified form of the appropriate configure command, depending on what the build-system is | 13:42 |
Albert_ | I tried to do that (naively I'm sure) but it didn't work. | 13:43 |
richard_maw | well, 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 broke | 13:44 |
richard_maw | probably the latter then | 13:45 |
richard_maw | you'll have to find someone familiar with how CommonAPI is normally built | 13:45 |
richard_maw | jonathanmaw or pedroalvarez maybe ^ | 13:45 |
Albert_ | thanks richard_maw | 13:46 |
pedroalvarez | Albert_: can you show us the modified chunk that is not building? | 13:47 |
Albert_ | I'll have to check because I deleted it | 13:47 |
richard_maw | SotK: Biff re https://gerrit.baserock.org/#/c/343/2 | 13:48 |
SotK | richard_maw: ty | 13:48 |
richard_maw | SotK: you won't say that when you see my response | 13:49 |
ssam2 | SotK: if you haven't already fixed the thing I complained about on Gerrit, http://sprunge.us/ROeF | 13:50 |
ssam2 | i had to fix it locally anyway | 13:50 |
SotK | ssam2: thanks | 13:52 |
SotK | richard_maw: at least its being reviewed at last | 13:52 |
Albert_ | pedroalvarez, I think I tried something like this: http://paste.baserock.org/aquyebarel | 13:53 |
richard_maw | SotK: yeah, sorry I haven't been able to do my usual wednesday reviews for the past 3 weeks | 13:54 |
* richard_maw needs a whole day for big reviews, which is another reason to keep patches small | 13:54 | |
SotK | richard_maw: no problem :) | 13:55 |
pedroalvarez | Albert_: this should be more equivalent to the current instructions: http://paste.baserock.org/ufiluqufec | 13:57 |
Albert_ | Thanks pedroalvarez | 13:58 |
* ssam2 wonders if there's a way to detect whether a system /doesn't/ have overlayfs, to avoid having to modify distbuild-setup | 13:59 | |
ssam2 | I guess modifying distbuild-setup to have an extra parameter isn't hard, but i wish it wasn't needed | 13:59 |
*** locallycompact has quit IRC | 13:59 | |
ssam2 | currenlty the ostree-branch of morph requires you to set '--union-filesystem=unionfs-fuse' to make it use unionfs-fuse | 13:59 |
pedroalvarez | Albert_: I guess you still want to --disable-acl, though | 14:00 |
pedroalvarez | Albert_: you still have errors building that, let us know | 14:01 |
SotK | ssam2: can you check the kernel version somehow? | 14:01 |
*** Krin has joined #baserock | 14:01 | |
richard_maw | SotK: we should be checking the kernel features, not kernel version | 14:02 |
persia | There's no realiable way to determine what modules have been built into a kernel. | 14:02 |
SotK | ah yes, ignore me | 14:02 |
radiofree | persia: you could grep /proc/config.gz | 14:02 |
persia | easy enough to play with modprobe and lsmod for external modules. | 14:02 |
Albert_ | pedroalvarez, What does --disable-acl do? | 14:02 |
persia | radiofree: Doesn't always exist (because enabling it is a kernel config option) | 14:03 |
radiofree | it exists in baserock, that's what we're talking about here? | 14:03 |
pedroalvarez | Albert_: ew, I mentioned that because it was in the build instructions you sent me: http://paste.baserock.org/aquyebarel | 14:03 |
richard_maw | Albert: 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-progs | 14:03 |
Albert_ | Sorry, not paying proper attention | 14:04 |
persia | radiofree: 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_maw | no, you need --disable-acl or the build system will try to use something that won't work, and bugger up later | 14:07 |
richard_maw | we'd need to fix acl before we can remove --disable-acl | 14:07 |
Albert_ | Oh I get it | 14:07 |
richard_maw | SotK: Biff re https://gerrit.baserock.org/#/c/343/2 | 14:10 |
*** locallycompact has joined #baserock | 14:14 | |
*** ssam2 has quit IRC | 14:16 | |
*** ssam2_ has joined #baserock | 14:16 | |
richard_maw | there 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 information | 14:50 | |
Kinnison | gerrymander | 14:51 |
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 on | 14:51 |
richard_maw | thanks Kinnison | 14:51 |
* petefoth thinks 'git gerrymander' should be a valid command | 14:52 | |
richard_maw | petefoth: too comprehensible | 14:52 |
petefoth | richard_maw: probably | 14:52 |
persia | richard_maw: gertty | 14:59 |
* pedroalvarez failed to set up gertty | 15:00 | |
* richard_maw is annoyed by google auto-correcting gertty to getty | 15:00 | |
persia | I think gertty needed some special gerrit config. I don't remember if that got enabled. | 15:04 |
persia | But `pip install gertty` should be a lightweight way to try it. | 15:04 |
Kinnison | 2015-04-22 14:17:49 [ybdtest.build-system-x86_64-chroot@5b4eaa90e24ad9b6f18b11ee6ad7791f24de3643d9e837249960a5a187180a19.build-system-x86_64-chroot] WARNING: Need to find extensions now | 15:06 |
* Kinnison proceeds | 15:06 | |
* Kinnison progresses even | 15:06 | |
Kinnison | So. little. brain. left. | 15:06 |
*** petefoth has quit IRC | 15:07 | |
paulsherwood | :) | 15:18 |
*** robtaylo1 is now known as robtaylor | 15:30 | |
*** Guest47057 has quit IRC | 15:33 | |
richard_maw | well, gertty is failing to authorize | 15:33 |
* richard_maw checks whether he put is credentials in correctly | 15:33 | |
*** jonathanmaw has quit IRC | 15:33 | |
persia | richard_maw: We might need something on the gerrit side: I seem to remember ssam2_talking about that before. | 15:35 |
richard_maw | I've found no information about what needs to be enabled | 15:35 |
radiofree | i thought it was just https? | 15:37 |
persia | That seems to match my memory, but we did that. | 15:38 |
persia | Probably needs someone to have a go from both sides to find out. | 15:38 |
franred | richard_maw, Im going to merge this https://gerrit.baserock.org/#/c/390/ 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 |
franred | s/us/you/ | 15:43 |
richard_maw | sounds fine to me | 15:43 |
*** a1exhughe5 has quit IRC | 15:44 | |
richard_maw | well, using digest auth stops it failing to authenticate, but I'm not yet seeing any changes | 15:45 |
franred | richard_maw, pdar, merged | 15:50 |
richard_maw | gertty claims that the reason it can't work is that the download-commands plugin is missing from the server | 15:56 |
ssam2_ | that is true | 15:56 |
Kinnison | Do we have a spare weekend to restart gerrit in? | 15:56 |
ssam2_ | is that the royal 'we' ? | 15:57 |
Kinnison | No, 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 time | 15:57 |
Kinnison | :) | 15:57 |
Kinnison | So not that long to wait | 15:57 |
ssam2_ | pedro, fran or Gary can also do this | 15: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 dependencies | 16:05 | |
pedroalvarez | I'll make a note to enable that, if the only thing needed is enabling it and a restart | 16:08 |
ssam2_ | thanks! note that to /get/ plugins, the easiest way is to extract them from the gerrit .war file, if present | 16:11 |
ssam2_ | like this: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/infrastructure.git/tree/baserock_gerrit/instance-config.yml#n64 | 16:12 |
ssam2_ | i wasted ages looking for how to download them from the gerrit project's web page | 16:12 |
pedroalvarez | ssam2_: useful info, thanks! | 16:17 |
*** zoli__ has quit IRC | 16:40 | |
*** zoli__ has joined #baserock | 16:41 | |
*** zoli__ has quit IRC | 16:41 | |
*** mariaderidder has quit IRC | 16:55 | |
jjardon | Hi, Ive successfully natively built the bootstrap Baserock tarball as explained in the point 3 in http://wiki.baserock.org/guides/how-to-cross-bootstrap ; where is the result system created? my 'native-bootstrap' seems that only build the different components, not build a final rootfs | 16:56 |
jjardon | this is how the native-bootstrap script looks like: http://paste.baserock.org/casadepucu | 16:57 |
pedroalvarez | jjardon: they are on the same system you are running | 16:57 |
pedroalvarez | jjardon: try running `morph --version` | 16:57 |
pedroalvarez | with "they are on the same system" I mean that the things that script have built, are installed on / | 16:59 |
jjardon | pedroalvarez: yeah, but is native-bootstrap not meant to build a rootfs (tarball)? | 17:01 |
pedroalvarez | no | 17:01 |
pedroalvarez | native-bootstrap exsist to do the native building part of the cross-bootstrap process | 17:02 |
pedroalvarez | the result is not a new rootfs, is your current rootfs modified | 17:02 |
bashrc_ | fixed an error with one of the firehose patches | 17:02 |
*** bashrc_ has quit IRC | 17:04 | |
pedroalvarez | jjardon: now from where you are you can just use Morph | 17:04 |
jjardon | pedroalvarez: mmm, what is the tarball the docs are talking about in the point 4 in http://wiki.baserock.org/guides/how-to-cross-bootstrap/ then? a manually generated one? | 17:04 |
pedroalvarez | is the same one you are currently chrooted in | 17:05 |
pedroalvarez | point 4 is confusing and wrong | 17:05 |
jjardon | :) | 17:06 |
pedroalvarez | it 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 |
pedroalvarez | I think that when I wrote it I thought that step 3 generated another rootfs | 17:07 |
* ssam2_ successfully deploys a 'build' system to .tar on a Calxeda node, using unionfs-fuse and OSTree | 17:08 | |
ssam2_ | exactly 1 minute 30 to do that | 17:08 |
SotK | \o/ | 17:08 |
ssam2_ | of which about 55 seconds is writing the 2GB .tar file | 17:08 |
jjardon | _amazing_ | 17:11 |
jjardon | SotK: thanks for this! | 17:11 |
*** simonh_ has quit IRC | 17:19 | |
franred | ssam2_, that is pretty impressive!! :D | 17:20 |
* SotK takes 1min39s to construct a trove system artifact | 17:27 | |
*** gary_perkins has quit IRC | 17:31 | |
*** ssam2_ has quit IRC | 17:31 | |
*** gary_perkins has joined #baserock | 17:31 | |
*** Krin has quit IRC | 17:36 | |
jjardon | pedroalvarez: thanks. I think a note to add/configure /etc/resolv.conf should be added as well. Will try to add something later | 17:36 |
*** locallycompact has quit IRC | 17:39 | |
*** franred has quit IRC | 17:41 | |
*** gary_perkins_ has joined #baserock | 17:44 | |
*** gary_perkins has quit IRC | 17:45 | |
*** zoli__ has joined #baserock | 17:56 | |
*** rdale has quit IRC | 17:56 | |
*** edcragg has quit IRC | 18:00 | |
*** zoli__ has quit IRC | 18:18 | |
*** lachlanmackenzie has quit IRC | 18:37 | |
*** Albert_ has quit IRC | 18:46 | |
*** gary_perkins_ has quit IRC | 19:27 | |
*** zoli__ has joined #baserock | 20:05 | |
*** edcragg has joined #baserock | 20:32 | |
*** edcragg has quit IRC | 22:03 | |
*** zoli__ has quit IRC | 23:33 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!