IRC logs for #baserock for Tuesday, 2015-05-26

*** zoli__ has joined #baserock00:34
*** zoli__ has quit IRC00:39
*** zoli__ has joined #baserock01:35
*** zoli__ has quit IRC01:40
*** zoli__ has joined #baserock02:36
*** petefoth has quit IRC05:15
*** petefoth has joined #baserock06:26
*** mike has joined #baserock06:46
*** mike is now known as Guest8873206:46
*** zoli__ has quit IRC06:49
*** zoli__ has joined #baserock07:09
*** perryl_ is now known as perryl07:18
*** CTtpollard has joined #baserock07:23
*** edcragg has joined #baserock07:39
*** franred has joined #baserock07:42
*** edcragg has quit IRC07:53
*** mariaderidder has joined #baserock08:05
*** bashrc_ has joined #baserock08:06
*** rdale has joined #baserock08:09
*** petefoth has quit IRC08:17
*** petefoth has joined #baserock08:18
*** jonathanmaw has joined #baserock08:23
*** gary_perkins has joined #baserock08:29
*** edcragg has joined #baserock08:33
*** tiagogomes_ has joined #baserock08:49
*** ssam2 has joined #baserock09:00
*** ChanServ sets mode: +v ssam209:00
*** lachlanmackenzie has joined #baserock09:13
* pedroalvarez sighs after seeing that alsa-(utils|libs) have rebased master and also the tag that we are currently using09:23
pedroalvarezIt's not the first time they do this09:23
richard_mawperhaps it's time to start using morph anchor09:24
ssam2richard_maw: could you help me with `morph diff` quickly?09:25
ssam2i'm running this: `morph diff baserock:baserock/definitions master -- baserock:baserock/definitions 508d657dd94478d41eb1ec93a1c1556c607d55e6`09:25
ssam2but I get: "ERROR: From expected definition specs 'from' and 'to'; missing 'to'"09:25
richard_mawssam2: single -09:26
Kinnisonpedroalvarez: Oh dear, did they put a release out explaining why?09:26
richard_mawssam2: I wanted to use --, but the argument parser swallows it, and to stop it doing that would require rewriting everything to not use cliapp's argument parser09:26
pedroalvarezKinnison: It looks like they rebased just after one release, maybe trying to fix something in the release? I can't see anything in their release notes, I will do a diff to investigate what changed, maybe is something that they have to do, although it seems to me that doing that in tags is not fair play09:31
KinnisonIt's (IMO) not fair play to rebase master without a jolly good explanation09:32
*** flatmush1 is now known as flatmush09:33
KinnisonIt's one thing if you're a small project09:33
Kinnisonbut not when you're big09:33
*** Guest88732 has quit IRC09:34
richard_mawas a data point, systemd messed up their `make dist` in their latest release, but haven't attempted to move the tag09:35
pedroalvarezshouldn't we avoid things like "+refs/tags/*:refs/tags/*" in the refspecs?09:40
pedroalvarez(until we decide to use `morph anchor`)09:41
KinnisonIIRC too many projects turned out to be badly behaved to not have that as default09:41
Kinnisonbecause we don't monitor the lorry issues regularly09:41
pedroalvarezbut that means: force push all the tags, right?09:42
pedroalvarezforce-push tags + upstream rebasing tags + we using directly tags for definitions (and not anchoring them in a branch) --> scary09:44
KinnisonWhich is why I always advocated anchor branches even when we wanted to use tagged releases09:45
Kinnisonbut I kept being overruled by people who thought it was too onerous to manage09:45
KinnisonAt least, with morph anchor, the effort is reduced09:45
ssam2pedroalvarez: if there was a consistent naming scheme for personal branches, that'd be ok09:46
pedroalvarezKinnison: indeed, +1 to morph anchor, for whenever we are ready for the discussion about using it09:46
ssam2pedroalvarez: if Lorry didn't fail when any branches fail to update, it'd be a lot more practical to avoid  "+refs/tags/*:refs/tags/*" as well09:46
ssam2pedroalvarez: presumably `morph anchor` would be used at release time, so whether it's up to whoever is doing releases, in practice09:47
ssam2i.e. mostly you ;)09:47
ssam2*whether it's used is up to09:48
*** Guest88732 has joined #baserock09:49
pedroalvarezssam2: regarding lorry failing when only some branches failed - not sure we can do anything about it09:50
pedroalvarezevery project is different, and we sometimes want branches, instead of master (e.g. Openstack projects)09:51
ssam2yeah. Although, if the failures just showed up as warnings, and it was easy to tweak the .lorry files, it would be more practical to develop a set of .lorry files that described the different projects09:52
ssam2still a big, ongoing job though, I'm glad we aren't trying to do that :)09:52
pedroalvarezaye, that sounds big09:53
jjardonHi, I asked this yesterday, but in case someone around miss it: is dlopen mean to work when you are building systems?09:57
KinnisonIt *ought* to work09:57
Kinnisonthat it doesn't is surprising09:57
Kinnison(Not least, it works for building things like gall whose test suite uses it)09:58
Kinnisonand for any python module with C components09:58
ssam2is there any reason why `morph anchor` defaults to pushing branches, instead of tags ?10:00
ssam2and, is 'refs/tags/{trove_id}/anchors/{name}/{commit_sha1}' a sensible setting for 'anchor-ref-format' if one wants tags instead of branches?10:02
ssam2(that's just the default value but in refs/tags instead of refs/heads)10:03
KinnisonI'm not sure if Trove rulesets all support that10:03
ssam2they definitely don't support pushing anchors to refs/heads/* in every repo, it seems10:04
ssam2I have an error log from a user who tried the default behaviour, and found it didn't work. But the log is confusing me a bit (it might contain some private stuff so I can't post it here)10:06
*** Guest88732 has quit IRC10:09
*** Guest88732 has joined #baserock10:22
*** sambishop has joined #baserock10:38
straycatbecause the ruleset doesn't support pushing tags to delta/10:39
ratmice__jjardon: I can't imagine why dlopen wouldn't work, for most of the's i've looked at dlopen is pretty much the same code path as -lfoo linking uses10:43
jjardonKinnison, ratmice__ : thanks, I completely lost why this chunk fail to compile with:
Kinnisonjjardon: sounds more like it wasn't built with expat visible on the system10:47
jjardonI rebuilt gettext again with libexpat as dependency: same problem10:48
jjardongettext try to dlopen or if that fails. but seems we only have in our systems10:52
ratmice__and whatever you are building is getting a build dep on expat?10:52
Kinnisonjjardon: Sounds like expat's install target isn't naking things properly10:52
ratmice__what's the (SONAME) on from readelf -d?10:53
jjardonoh, we are using the experimental cmake build system for libexpat, maybe that's the problem10:53
ratmice__er i'm confused that shouldn't matter in dlopen :)10:53
jjardonratmice__:  0x000000000000000e (SONAME)             Library soname: []10:53
ratmice__so, I assume gettext is trying to work with multiple ABI's of expat for some reason10:55
jjardonratmice__: thats rigth10:56
jmacsstraycat: I see you submitted a v2 to my jmac/partial-java-build-support branch - thanks - but I can't tell from gerrit where you pushed it10:57
straycatjmacs, i might not have pushed that branch anywhere, other than to gerrit11:00
jmacsOh right, yes, gerrit is a git server11:00
ratmice__jjardon: seems like it does the actual version dependent stuff at the symbol level (e.g. there is no different handling for one version vs the other), so if expat is building without the symlink might add a 3rd if (handle == NULL) handle = dlopen("", RTLD_LAZY);11:02
ratmice__but yeah, not sure where the right place to fix it is (expat, gettext or both)11:05
ratmice__jjardon: for future reference LD_DEBUG=files (i'd assume when running configure or whatever, actually never tried with configure scripts) can help with finding these issues11:09
* ratmice__ isn't sure how to get that environment variable set with auto determining build systems11:10
jmacsstraycat: I can pull HEAD:refs/for/master/jmac/partial-java-build-support from gerrit, but the ref shown in gerrit doesn't appear in my git repo...11:11
jjardonratmice__: cheers, noted :)11:11
straycatjmacs, i usually use git review -d <change number> which is fetching refs/changes/96/696/211:16
straycat"The first 68 is the id of the change mod 100. The only reason for this initial number is to reduce the number of files in any given directory within the git repository."11:17
straycat( refs/changes/68/68/2 )11:17
straycat( )11:18
jmacsLooks like today's job is going to be learning gerrit, then :)11:18
*** pacon has joined #baserock11:40
*** pacon has quit IRC12:44
jmacsstraycat: Where did the "96" come from in refs/changes/96/696/2 ?13:20
ssam2it's 696 % 10013:23
ssam2I believe that Gerrit would hit some limit in Git ref names if it had thousands of refs under refs/changes directly13:24
straycat12:19  straycat$ "The first 68 is the id of the change mod 100. The only reason for this initial number is to reduce the13:30
straycat                 number of files in any given directory within the git repository."13:30
jmacsSo now I appear to have straycat's updated commit on its own, without my other two commits - is it appropriate to cherry-pick straycat's commit onto my own branch, or will that mess up gerrit?13:31
straycatwe can merge 696 and rebase the others on top of it13:32
jmacs696/2, you mean?13:33
jmacsI suppose that would work13:34
straycat697 needs work though13:35
Kinnisonstraycat: Are you intending to do anything for Change 219?  You've not tended to it since April 7th -- If you're abandoning it, can you please explicitly abandon it in the UI ?13:36
jmacsWell, yes, but I didn't know how to develop on it without having your change in my tree13:37
straycati'm not abandoning it at all13:37
jmacsI should be able to work on it now13:37
straycati just don't have time to fix morph so that i can fix the bug *and* avoid duplicating the graph structures13:37
* straycat shrugs13:37
jjardonHi, I manage to strip debug symbols in my image using a strip-everything.morph chunk in the end of my last stratum. As this is a bit hacky, I'd like to ask what would be the best way to implement this so it can be submitted to the project?13:39
KinnisonZara: Change 331 (and related) you have -1'd13:39
KinnisonZara: And left for over 5 weeks13:40
KinnisonZara: Are you abandoning that work?13:40
ZaraKinnison: fb still haven't updated their licensing, though originally they said they were going to13:40
Zaraso we're still waiting for them. I think I have abandoned the two related changes13:40
KinnisonI see13:41
richard_mawjjardon: it's a neat hack that I had considered doing myself, but IMO the appropriate way to do this would be to strip at build time.13:41
richard_mawjjardon: btw, I'm currently working on binary stripping13:42
Kinnisonbashrc_: You have a non-trivial sequence of changes culminating in #281 which haven't seen activity for ca. 5 weeks -- are you abandoning these?13:42
ZaraKinnison: I could abandon the last patch and resurrect it later if/when they update their repo, if that's preferable to leaving the patch there.13:43
KinnisonZara: So long as you're managing that patch, I'll not bug you again this week :)13:43
*** petefoth has quit IRC13:44
*** petefoth has joined #baserock13:44
Zaraokay, great. :)13:44
bashrc_Kinnison: if they're not going to be pulled then I guess they can be abandoned13:46
Kinnisonbashrc_: If you know who took over that work then I can ask them13:46
jjardonrichard_maw: oh, nice. Any idea when are you going to have time to have something we can try? Happy to test if needed13:46
ZaraNow for me to bug everyone with errors! In my cross-bootstrapped system, I did 'morph init workspace', which worked, followed by a morph checkout in the workspace, which didn't work. Here's the error log: . What's going on? Have I forgotten a step?13:46
straycatZara, can you ping ?13:47
richard_mawjjardon: I'm currently writing up my proposal in!/story/47 along with my reasoning13:47
bashrc_Kinnison: I don't know if anyone took over the firehose development. perryl was doing it prior to me. I don't know if she went back to it13:47
KinnisonZara: Check your /etc/resolv.conf13:47
KinnisonZara: It's likely missing a 'nameserver' entry13:47
Kinnisonfatal: Unable to look up (port 9418) (System error)13:48
Kinnisonbeing the hint13:48
perrylbashrc_: i've not had a chance to go back to the firehose development work; currently unsure when i will next be able to do so13:49
bashrc_so I guess for now it's on ice13:50
Zaraheh, it appears that I have no 'resolv.conf' in /etc. also don't seem to have a morph.conf so possibly the cross-bootstrap page should link to the quick-start page instead of the 'using baserock' page...13:50
Kinnisonthe mid-cross-bootstrap stuff is "odd" anyway13:51
jjardonrichard_maw: nice, thanks13:54
wdutchI'll have a look at firehose, maybe I can do something useful?14:01
wdutchhe says without knowing what he's signing up for ...14:02
richard_mawssam2: btw, I had cause to think about sysroots, and I was reminded about how clever your work to make the stage 2 bootstrap work with the gcc specs locating the sysroot by environment variable was.14:03
richard_mawgood job14:03
bashrc_wdutch what relained was testing of the various operation modes14:03
richard_mawI think it got less praise than it deserved.14:03
wdutchbashrc_: thanks14:05
bashrc_I think I managed to implement all the modes14:06
bashrc_just needs testing/debugging14:06
Kinnisonjjardon: I love your spanglish14:06
Kinnisonjjardon: In future, when you think "posterior" is the word you want, try using "later" or "future" :)14:06
ssam2heh, thanks14:07
Kinnisonjjardon: because while it's "correct", its colloquial use is quite different :)14:07
jjardonKinnison: ah :), will do14:09
* pedroalvarez makes a note for posterior commits14:15
* Kinnison dreads14:16
KinnisonSotK_: Change 253 and related -- XFCE stuff -- are you intending to do something with it?14:24
SotK_Kinnison: I am intending to send a v2 when I get time :)14:25
Kinnison6 weeks is a long time to let a change go fallow14:25
jjardonKinnison: I will try to help with that when I get some time as well14:26
Kinnisonstraycat: Change 67 (anon access in trove rulesets) seems to be waiting for action on your part14:29
Kinnisonrichard_maw: If straycat doesn't have time, are you able to adopt and follow it through?14:29
richard_mawKinnison: theoretically able, but it's not a priority task for me so I'm not sure whether I'd be any more likely to get around to it14:32
straycati can probably sort that out at some point14:34
straycati only need to change the comment14:34
Kinnisonjjardon: Change 17 -- richard_maw left it at -2 asking you to either abandon or produce a more complete patch14:39
Kinnisonjjardon: Are you intending to do the latter?14:39
Kinnisonjjardon: if so, feel like commenting to that effect?  If not, please abandon14:39
jjardonKinnison: done!14:44
Kinnisonexcellent, thank you jjardon14:44
jjardonKinnison: sorry, I keep trying to come back to that but other things arise all the time14:45
KinnisonSotK_: your huge ostree-staging work -- what's the situation with that?14:45
Kinnisonjjardon: I know the feeling14:45
Kinnisonjjardon: I'm just trying to garden the open changes14:45
richard_mawKinnison: tbh it's all pending fixing up split /usr and being able to move everything into /usr, so it's safe to have an empty /etc14:46
richard_mawKinnison: since rather late in its development we worked out that we can't actually safely have the deployment speed-ups on a hard-linked rootfs14:47
Kinnisonrichard_maw: That whole series?14:48
richard_mawKinnison: theoretically we could break all the links to files outside /usr, but I don't know of the best place to put that logic that would be overly special-casing how systems are built14:48
richard_mawKinnison: it's not safe to use, completely independently of it breaking cross-bootstrap14:49
KinnisonI see14:49
richard_mawand the naive way to make it safe again, completely defeats the purpose14:49
richard_mawwhich is sad, because we could do a lot of cool things with ostree both as the build tool and as part of the upgrade story of target systems14:51
* richard_maw would like to replace our current upgrade mechanism with ostree14:51
richard_mawsince it's more featureful and it's less code for us to have to maintain independently14:51
KinnisonFor now I shall skip that entire series14:52
* Kinnison goes back to gardening14:52
Kinnisondoffm: Change #444 has been idle for coming up to a month -- any idea when you might get back to it?14:54
doffmKinnison: I'd kinda forgotten. I can probably get back to it this week.14:56
Kinnisonpedroalvarez: Change #325 was reviewed by you, jjardon uploaded new versions, and you've not re-reviewed -- do you have time/context to reconsider it?14:58
jmacsfranred: I'm trying to understand your comment on my java patch - the instance config file for baserock_gerrit - does that just expect the user to down load the JDK manually?14:58
pedroalvarezKinnison: will re-review it now14:58
Kinnisonpedroalvarez: yay14:58
ssam2jmacs: yes, it does14:58
ssam2jmacs: Oracle seem to discourage auto-downloading it14:59
Kinnisonjjardon: Can I also re-raise #405 to your attention?15:00
Kinnisonjjardon: #265 you appear to have submitted and then -1'd yourself -- 2 weeks have then passed -- plans?15:01
jjardonKinnison: #405: that one is a little bit more tricky, as seems changes need to be done in systems I do not use and I'm not familiar with.15:02
jjardonKinnison: 265: it will be there until someone with access to that hardware test the patches15:02
radiofreeabandon 26515:03
jjardonKinnison: or we can remove support for these boards from definitions if we are actually not maintaining them15:04
Kinnisonjjardon: I dunno about you, but a change -1'd by the author of it doesn't inspire me to run tests :)15:04
radiofreejjardon: why? we *used* to have a bsp that you could drop into a system and boot a wandboard with15:05
radiofreebarring some kind of terrible userspace disaster that should still be the case15:05
pedroalvarezKinnison: unless the author says that he is -1ing it to avoid having it merged without testing15:05
radiofreeterrible userspace disaster e.g version 1 of
KinnisonSotK_: You submitted and -1'd the distbuild-stress-tester topic (#623 and friends) -- any idea on whether you'll come back to it or not?15:17
SotK_Kinnison: I intend to come back to it, yes15:20
pedroalvarezoh, systemd 22015:21
pedroalvarezrichard_maw: re - "systemd messing up their `make dist`" in the release. Would that be a problem for us to use it?15:22
Kinnisonjjardon: the change series culminating in #168 (terminal_title) -- are you coming back to that any time soon?15:22
richard_mawpedroalvarez: nope, we build from git15:22
richard_mawpedroalvarez: though they require newer kernel headers in 220 than 219, which might cause issues15:22
richard_mawpedroalvarez: I've got a patch locally that we could submit to fix that15:23
* pedroalvarez realises how stupid was his question15:23
richard_mawnah, packaging is difficult (as we can see from the 220 release's accident), it's not stupid to not know the implications of make dist vs building from git15:24
jjardonradiofree: we still have;. If current master is broken simply use a older definitions15:24
jjardonproblem is that its probably broken as no one is actively testing it on a wandboard15:24
*** zoli__ has quit IRC15:24
radiofreejjardon: or you could just not touch kernels for hardware you're not testing15:25
pedroalvarezrichard_maw: we are using kernel headers from 4.0 I believe15:26
richard_mawthat ought to be new enough then15:26
Kinnisonssam2: Are you working on a new patchset for #581 any time soon?  (I appreciate it has only been a week, so now I'm just being a naggy git :)15:27
ssam2i doubt it will be soon15:27
ssam2but would prefer to keep the change open, so I can keep track of the fact that it needs doing15:27
KinnisonI may bug you in future :)15:28
radiofreeis it safe to run a "morph upgrade" on a system that's currently doing a "morph build"?15:34
radiofreeno wait, morph deploy15:34
pedroalvarezI think it's even safe to self-upgrade the system15:36
robtaylorany chance could get a * cert?15:38
KinnisonI asked about it, and ssam2 said he wanted to redeploy it first15:38
*** radiofree has quit IRC15:48
*** radiofree has joined #baserock15:49
jjardonKinnison: maybe you can take a look to when you have time15:50
Kinnisonjjardon: I can look, but I'm not in a position to test-build right now15:52
ZaraHi, I tried to build a system and got a strange error: . Someone suggested it might be to do with my machine having an old kernel (3.10.24)15:54
ZaraI'm trying to do the build after running linux-user-chroot inside a chroot (into a cross-bootstrapped system). if anyone has a lightbulb moment, please let me know! :)15:57
KinnisonYou're running *inside* a l-u-c ?15:57
Zaraah, do I need to come out of that? the wiki is a bit ambiguous so I'll change it if so15:58
Kinnisonl-u-c drops a lot of permissions15:58
Kinnisonlikely including the ability to unshare etc15:59
Kinnisonensure the base of the cross-bootstrapped system is a mount point (use mount --bind /foo/bar /foo/bar if it's not) and use normal 'chroot' to go inside15:59
Kinnisonthat might work better15:59
jjardonZara: ah, linux-user-chroot / /bin/sh is only to check everything is working correctly: you should exit from there before start the build16:00
Zaraah, okay, will do :)16:00
richard_mawjjardon: can I see the morphology you used to strip your system?16:22
radiofreeit's come up before, what's the fix for "Couldn't find morphology: systems/system-that-is-clearly-there-and-commited-to-git.morph"16:24
ssam2i don't know :(16:25
Zaradid you make a new branch? maybe it's looking at the wrong commit?16:25
jjardonrichard_maw: sure, but we couldn't deploy it yet, so not sure is working correctly at the moment: this is the commit:
radiofreei just did morph checkout baserock:baserock/definitions master16:26
radiofreethen git checkout *branch*16:26
radiofreecopying the system morph to something else worked...16:26
radiofreecp systems/my-system.morph systems/my-system-2.morph16:26
radiofreeedit the name of my-system-2.morph, don't commit, works16:27
ssam2are there any changes to the repo other than that?16:27
ssam2Morph takes a different code path depending on whether you have any uncommitted changes or not16:27
richard_mawthanks jjardon16:27
radiofreessam2: no other changes16:28
ssam2right. that'll be why. It certainly sucks16:31
*** mariaderidder has quit IRC17:01
*** jonathanmaw has quit IRC17:02
SotK_radiofree: morph doesn't build the checked out branch, it builds using the branch defined in $workspace/$branch_given_to_morph_checkout/.morph-system-branch/config17:11
radiofreeis that a new thing?17:12
SotK_so despite your git checkout *branch*, it is still looking at master unless you have uncommitted changes17:12
SotK_nope, it's been like that forever afaik17:12
SotK_it just isn't noticeable most of the time17:13
radiofreethis is only an issue with morph build though17:13
radiofreegit checkout -b foo and adding strata/chunks is fine17:13
SotK_even when there are no uncommitted changes?17:15
*** ssam2 has quit IRC17:18
radiofreeSotK_: i... i think so17:18
jjardonugh, cross- system tarball is still ~4GB17:24
jjardonlist of current stuff:
jjardonmmm, ok. Seems that is a normal size17:27
*** lachlanmackenzie has quit IRC17:28
*** Guest88732 has quit IRC17:35
*** tiagogomes_ has quit IRC17:48
*** gary_perkins has quit IRC18:28
*** edcragg has quit IRC18:46
SotK_radiofree: thats weird18:51
SotK_hmm, maybe its not that weird18:52
rjekCan't it be both?18:52
SotK_I think its weird after all18:55
*** SotK_ is now known as SotK19:33
*** rdale has quit IRC20:04
pedroalvarezurgh, libexpat change broke everything21:02
* pedroalvarez sends to fix it21:26
*** zoli__ has joined #baserock23:03
*** zoli__ has quit IRC23:43

Generated by 2.15.3 by Marius Gedminas - find it at!