IRC logs for #baserock for Wednesday, 2015-03-18

*** oleksandr has joined #baserock00:01
*** oleksandr has quit IRC00:07
*** jjardon has quit IRC00:30
*** edcragg has quit IRC00:31
*** jjardon has joined #baserock00:31
*** edcragg has joined #baserock00:44
*** zoli__ has joined #baserock01:24
*** edcragg has quit IRC01:24
*** zoli__ has quit IRC01:28
*** zoli__ has joined #baserock06:17
*** zoli__ has quit IRC07:02
*** zoli__ has joined #baserock07:06
*** pacon2 has quit IRC07:31
petefothWhen I sign in to gerrit - it takes me to the 'Settings page (as if I haven't been in before, which I was, yesterday). If I try to set my username to petefoth, it claims that username is in us - it is, by me :(07:31
petefothTried clearing cookies and stuff, but same response07:36
petefothIt says I registered this morning (Mar 18, 2015 7:29 AM with account ID 23) which is rubbish - I registered several days ago, and set the petefoth username yesterday .07:38
*** pacon2 has joined #baserock07:40
*** a1exhughe5 has joined #baserock08:09
*** gfinney has joined #baserock08:17
*** XuLiu has joined #baserock08:17
*** XuLiu has quit IRC08:19
*** pacon2 has quit IRC08:38
*** pacon2 has joined #baserock08:38
*** rdale has joined #baserock08:47
*** pacon2 has quit IRC08:47
*** pacon2 has joined #baserock08:48
*** franred has joined #baserock08:52
*** bashrc_ has joined #baserock08:57
*** mdunford has joined #baserock09:04
*** sherm_ has joined #baserock09:05
petefothI have pushed a modified, gerrit-focussed version of the 'Contributing' page (http://wiki.baserock.org/contributing/) Please feel free to comment, and to point out / ridicule any deficiencies you may find :)09:05
*** jonathanmaw has joined #baserock09:08
*** gary_perkins has joined #baserock09:22
franredpetefoth, looks sane to me, the only bit that you may can change is that you can do the "git remote add gerrit $BASEROCK_GERRIT_REPOSITORY" before the clone I think09:23
petefothfranred: thanks. IS there any advantage do renaming before doing the clone?09:24
franredpetefoth, you don't do the rename, you just say which alias has that repository that you are cloning from09:24
franreds/say/specified/09:25
*** radiofree has quit IRC09:26
*** radiofree has joined #baserock09:26
petefothfranred: Sorry - I'm confused. Maybe easier for you just to make the change :)09:27
*** pacon2 has quit IRC09:28
franredpetefoth, ok, let me check a couple of things09:29
*** pacon2 has joined #baserock09:29
petefothfranred: OK - the clone (in the changuing morph section' is a copy of / reference to the instructions in  'Using latest version of Morph' page09:30
*** radiofree has quit IRC09:30
*** radiofree has joined #baserock09:31
*** radiofree has quit IRC09:31
*** tiagogomes_ has joined #baserock09:32
franredpetefoth, much better solution, you can use "git clone $MORPH_REPO --origin gerrit" so the alias of the repo is "gerrit" and not "origin"09:33
*** radiofree has joined #baserock09:34
petefothfranred: OK. Shall I change both pages?09:34
*** radiofree has quit IRC09:35
franredpetefoth, please do it :)09:36
* petefoth does 'git help clone' and reads the output carefully :)09:36
*** radiofree has joined #baserock09:37
*** radiofree has quit IRC09:38
*** radiofree has joined #baserock09:38
SotKCan anyone enlighten me on what may have gone wrong here? http://paste.baserock.org/uvidiwesop09:42
* SotK notices his disk is quite full, maybe it was that09:43
petefothfranred: I caan't make the --origin parameter work - tried various permutations - see http://paste.baserock.org/ejuwotexog09:44
petefothfranred: ignore me please, I'm stupid :)09:45
petefothDone!09:49
franredhttp://paste.baserock.org/galezidewu09:50
franredpetefoth, :D09:50
gfinneyHelp please. I've taken the current baserock and morph code and ran "morph build systems/base-system-x86_64-generic.morph". I'm still getting  "ERROR: Stratum devtools has no build dependencies for chunk vim in strata/devtools.morph"09:51
gfinneyWhat's going wrong09:51
*** ssam2 has joined #baserock09:52
*** ChanServ sets mode: +v ssam209:52
rdalemorph was recently changed to make build dependencies optional - before they were mandatory09:52
jjardongfinney: follow this to use latest morph: http://wiki.baserock.org/using-latest-morph/09:53
gfinneyOK lets give it a go.09:54
*** edcragg has joined #baserock09:56
*** pacon2 has quit IRC09:59
*** pacon2 has joined #baserock10:00
jjardonpetefoth: good work! I do not think changing definitions requires any special config though10:01
petefothjjardon: it's not about changing definitions particularly, it's about working within a system branch created by 'morph branch'10:02
petefothjjardon: which is different from changing morph in the /src/morph directory10:03
jjardonpetefoth No differences for me, but I do not use morph branch so maybe you are right (neither I push from my baserock system)10:08
bashrc_the term "cluster" seems strange. How was it arrived at, and does it have anything to do with cluster computing?10:09
petefothjjardon: hopefully the page can be simplified once the 'morph  branch' workflow is removed, deprecated, whatevered10:09
richard_mawbest we could think of for a group of system deployments10:09
KinnisonMost deployments in the wider world are more of than one system.  We chose the term 'cluster' to represent how they tend to be interrelated10:09
*** Krin has joined #baserock10:10
petefothjjardon: how are you getting on with your 'What I do with Baserock' story?10:10
*** lachlanmackenzie has joined #baserock10:12
ssam2I've found that in practice I never use cluster morphs with more than one entry, even when there are multiple related systems10:12
ssam2mostly because I need to configure each system post deployment in some way10:12
ssam2radiofree: I added a couple of notes about disk space to the jetson flashing guide, do they make sense? http://source.baserock.branchable.com/?p=source.git;a=blobdiff;f=guides/baserock-jetson.mdwn;h=2e8315f7422e1ae12a237e71cb9662290341d7e0;hp=99f04870b0eec9c0be1b8976dc63faf5d70ee808;hb=c7d06ac678c0373eb5bd2959c65b560a1fa41306;hpb=00c3e68d563b6147abc823211386eb25bfb42ea010:13
ssam2line wrapping :( i used the web interface10:13
radiofreessam2: +210:14
ssam2ta10:15
jjardonpetefoth: I should start writing that some of these days :)10:15
petefothjjardon: ;)10:15
*** wschaller has joined #baserock10:16
jmacspedroalvarez: If you had to give an estimate for getting ARMv6 working in baserock (including the work you've already done) what would you say?10:36
pedroalvarezjmacs: for someone without cross-bootstrap experience?10:38
jmacsEither with or without would be a useful number10:40
pedroalvarezjmacs: right, I'll give you an answer soon11:02
SotKwho can merge on gerrit.baserock.org?11:03
pedroalvarezI believe that users on the Mergers group11:04
jmacsAnother question, has anyone tried to make a Yocto recipe import tool before?11:05
pedroalvarezand I also believe that people that were allowed to do merges on git.b.o will be included on the mergers group11:05
pedroalvarezjmacs: so, I'd say that for a supported architecture, the generation of a bootstrap rootfs can take 2-3 weeks. This includes adding support for the new architecture in some chunks and in Morph)11:09
pedroalvarezwith that, you will be able to use Morph in that architecture, and use it to build a rootfs of the new architecture11:10
Kinnisonjmacs: yocto recipes are (IIRC) turing complete making an import tool hard to write11:10
Kinnisonjmacs: It may be possible to heuristically import some recipes11:10
jmacsKinnison: Is that a 'no'?11:10
jmacspedroalvarez: For someone with cross-bootstrap experience?11:10
pedroalvarezextra work will be research about how to build a bsp for the new architecture.11:10
Kinnisonjmacs: Noone has tried, mostly because it feels like a potentially black-hole endeavour11:10
Kinnisonjmacs: It's possible things have gotten better since then11:11
Kinnisonjmacs: but when I last looked, they even had logic to do with their build process encoded into file *paths*11:11
jjardonssam2: hey! when you have a minute, maybe you can review in gerrit my patches to change how we check for the definitions version (you already give them a +1 in the ml)11:12
pedroalvarezjmacs: for someone with a bit of understanding of how Morph builds, and differences when building for different architectures11:12
bashrc_just a thought: does baserock.org actually run on baserock?11:12
pedroalvarezmost of them11:12
jmacspedroalvarez: OK, thanks11:13
pedroalvarezs/and differences/and understands the differences/11:14
petefothbashrc_: there are different parts of baserock.org. The wiki is hosted at branchable. git.b.o (I believe) is a Trove and therefore is a Baserock system. Fairly sure that gerrit.baserock.org and Storyboard.b.o are also Baserock VMs11:16
bashrc_nice11:16
franredbashrc_, petefoth, gerrit and storyboard are not running in Baserock11:21
petefothfranred: sorry - I thought they were11:22
petefothI believe we have ikiwiki running in Baserock so the wiki could be hosted on a BAserock VM, but as Branchable host free wikis for open source projects, there's no advantage in moving11:22
petefothbashrc_: ^^11:22
*** oleksandr has joined #baserock11:22
*** oleksandr is now known as Guest1790311:23
ssam2jjardon: I will. I got stuck yakshaving a bit because I need to pull them inside baserock to test them, I tried to use git-review, then realised i need to add it to baserock first...11:24
ssam2petefoth, franred: gerrit is on Baserock. storyboard is on Fedora right now11:24
ssam2petefoth: also, I believe codethink sponsor our hosting at branchable.11:25
petefothssam2: ta!11:25
* petefoth learns lost of new things :)11:25
franredssam2, ooh, I didn't know gerrit was in baserock, sorry for the confusion11:27
CTtpollardI compiled a list of all the dependencies I could find for storyboard a while back, it is probably outdated now though11:31
CTtpollardand uses a different method to host it compared to how it is done on s.b.o I believe11:32
ssam2I deployed storyboard.baserock.org with https://github.com/openstack-infra/puppet-storyboard11:32
ssam2but it took some manual fixups to get it to actually work11:32
ssam2well, it was a fork of https://github.com/openstack-infra/puppet-storyboard11:32
ssam2https://github.com/openstack-infra/puppet-storyboard seems to require a forked version of some puppet modules, it's a bit of a mess11:33
CTtpollardI've only ever used it using the devel method of tox and grunt11:35
*** persia has quit IRC11:39
*** persia_ has quit IRC11:39
*** persia has joined #baserock11:40
*** persia_ has joined #baserock11:40
*** persia has quit IRC11:44
*** persia_ has quit IRC11:44
*** persia has joined #baserock11:46
*** persia_ has joined #baserock11:46
*** pacon2 has quit IRC12:06
*** Guest17903 has quit IRC12:07
petefothit has been suggested in another place that we need to restorethe instructions to add pylru for users of old baserock versions. I wouldn't want to see that in current pages, but we could maybe have a searchable archive of 'old knowledge' in to help people stuck with less current versions12:07
SotK'old knowledge' seems like a good place for this kind of thing12:08
jmacsHow do I know what I'm looking for is 'old knowledge'?12:08
* petefoth goes to create a story12:08
Zarawe should also work out how old something needs to be before it counts as 'old knowledge'12:09
mwilliams_ctThis bit me the other day when I was working on an old VM. for that specific example (pylru) it should be OK to add a note "if you are working with version older than x you will need to do y"12:09
jmacsIt bit me yesterday as well12:09
mwilliams_ctI agree with jmacs, I wouldnt have known that was old knowledge specifically12:09
petefothjmacs: by searching the whole site?12:09
jmacspetefoth: Search doesn't work on our wiki.12:09
petefothmwilliams_ct: but a year form now, who will be workign with that version12:09
Zarathat's why you need to work out how old it needs to be.12:09
ssam2my general opinion is that we have limited resources, and we should try to spend them supporting people who are using the latest released versions12:10
petefothjmacs: that's a different story.  :) I think we should have a 'search the wiki' function12:10
petefothssam2: +712:10
mwilliams_ctpetefoth: possibly me, I could decide to go and update an old VM rather than making a new one. I take your point though12:10
mwilliams_ctI don't want to suggest this as a general "we always have instructions for older things", but this one shouldnt add too much complexity and has affected at least jmacs and I (and presumably somebody in another place)12:11
ssam2a 'working with older versions of baserock' section would be fine, i think12:11
jmacsssam2: I probably wouldn't have thought to look there.12:11
petefothmwilliams_ct: maybe we should have a documente 'upgrade path' so the instruction won't be 'Install pylru' (or whatever the latest change is) but 'Run this update script' - that advice will never go otu of fashion :)12:11
ssam2jmacs: fair enough. My main issue is that if we have lots of compatibility notes in the wiki, it becomes full of compatibility notes that we never remove12:12
ssam2if they are in their own page, then at least only that page becomes full of them12:12
ssam2morph will need more deps once the ostree branch is merged, for what it's worth12:12
jmacsIf a search for "pylru" finds the relevant page, I think that will do fine.12:13
ZaraI think that if the wiki only supports the latest version of baserock, that should be made explicit on the wiki.12:13
ssam2that's a good idea12:14
ssam2ideally we'd have versioned documentation, but that's a long way off12:15
mwilliams_ctpetefoth: that seems a good compromise12:15
* SotK would expect the opposite if he was exploring a new piece of software (most recent unless otherwise stated), but agrees it should be noted one way or the other12:15
mwilliams_ct(I say compromise, actually it seems a better idea full stop)12:15
SotKthings like this make me agree with persia that we should hide the using-latest-morph page and tell people to upgrade their machine if they need a newer version in general12:16
ZaraI think we need more a more stable master of definitions before we do that.12:18
bashrc_if the wiki is based on git, then you could have versioned documentation12:18
richard_mawit is, you can clone git clone git://baserock.branchable.com/12:18
mwilliams_ctbashrc_: that's a very good idea, a version setting like Django uses. though as ssam2 has pointed out, we might not have adequate resources to support it12:18
petefothbashrc_: it is based on git. It is always possible to explore the git history, but that doesn't make documentation very 'discoverable'12:19
richard_mawalso, we don't tag which version the documentation is for12:19
jmacsBut realisitically nobody's going to mark all their contributions to the wiki as 'relevant to 15.10'12:19
bashrc_I think the version can be assumed based on the time of edits12:19
petefothbashrc_: it can be assumed, but the ssumption woudl likely be wrong, as the wiki doesn't get as much update love as the code12:21
petefothjmacs: when I asked about search, the answer was "Google indexes w.b.o, so using 'site: wiki.baserock.org morph' as part of your Google search string will do what you want"12:33
petefothThe follwoign search brigs up refernces to pylru (from the recent changs page) https://www.google.co.uk/search?q=site%3A+wiki.baserock.org+morph&oq=site%3A+wiki.baserock.org+morph&aqs=chrome..69i57j69i58.26230j0j8&sourceid=chrome&es_sm=119&ie=UTF-8#q=site:+wiki.baserock.org+pylru12:34
franredssam2, who has merge permissions in gerrit? and if someone has it which is the button to press to merge one accepted patch?12:37
petefothThe recent changes page is currently showng changes going back 11 days and 20 hours. Personally I think that, plus a prominent message saying 'If you get bizarre errors, first things to do are a: upgrade your Baserock VM as described in <link> and b: use the latest morph as described in <link>" will be a: enoiugh and b; future proof12:37
SotKfranred: I think there is a "Submit" button on the change screen if you have merge permissions12:38
jmacspetefoth: That's a good idea.12:38
ssam2franred: finally, someone asks!12:39
ssam2anyone in Mergers group has merge permissions12:39
* SotK asked earlier today!12:39
SotK:)12:39
ssam2one of the ops needs to manually people to Mergers groups. anyone already in baserock-writers on git.baserock.org can go in right away12:40
* pedroalvarez now checks if he told SotK the right answer12:40
petefothjmacs: but I'm not sure how you go about upgrading your development VM. I guess it will eb a variation on the 'simple build deploy workflow' But we need to make that more prominent12:40
SotKpedroalvarez: you did :)12:40
franredssam2, ok, I think Im not in the mergers group12:40
ssam2anyone not in baserock-writers should ask on the mailing list like before, anyone who is known on the list and has a few patches merged can be in the Mergers group12:40
ssam2franred: you should be in Administrators group, so you can add yourself12:40
paulsherwoodssam2: so i'm not a merger, which is fine unless folks think it'd be better to include me12:41
jmacspetefoth: I can't really comment on that since I know how to upgrade my development machine already. It's a process that takes several hours though, so not something I'm just going to do automatically before asking for help.12:41
paulsherwoodseveral hours?12:41
ssam2paulsherwood: you're in baserock-writers on git.baserock.org, so it's up to you12:42
paulsherwoodhistorically i've done a couple of merges, at a pinch. happy to be included, but wouldn't want to become a bottleneck12:42
*** wschaller has quit IRC12:42
SotKjmacs: it definitely shouldn't be taking several hours to do an upgrade :/12:43
pedroalvarezgood thing is now nobody needs to be in any special group to push things for review12:43
paulsherwood+112:43
Zarapetefoth: I think the message would need to say, 'and, if that results in errors, b: use the latest morph'. But, again, there are days when master of definitions is down, or master of morph is broken, so we shouldn't delete information too early.12:43
petefothZara: agreed12:44
jmacsSotK: About 2 hours and 10 minutes on my VM last night.12:44
paulsherwoodyes. i started trying to tease out the logic on updates, forward+backward compatibility a couple of weeks ago, then got distracted12:44
ssam2paulsherwood: I think we should be inclusive with the Mergers group. nobody can really do any harm, except merge things that the majority of people don't want12:44
jmacsThat's just for the build, not counting deploy12:44
paulsherwoodjmacs: doing what, exactly? what kind of a VM is it, if i may ask?12:44
petefothI've updated http://wiki.baserock.org/policies/ to mention Gerrit12:45
SotKjmacs: is artifact-cache-server set in your /etc/morph.conf?12:45
paulsherwoodjmacs: ah. were you building from scratch? not using cache.b.o?12:45
jmacs"morph build systems/devel-system-x86_64-generic.morph", virtualbox VM with 8G RAM and 1 CPU12:45
jjardonpetefoth: in policies?12:45
jmacsI have artifact-cache-server set to  http://cache.baserock.org:8080/12:46
petefothjmacs: I think we need a workflow that doesn't need to build, e.g. take the latest image, diff with my current VM and apply the diff12:46
petefothIsn't that on the roadmap somewhere? ;)12:46
paulsherwoodpetefoth: i think you'll find it's a bit more complicated than that ((c) ben goldacre)12:47
petefothjjardon:  yes http://source.baserock.branchable.com/?p=source.git;a=commit;h=941b34d69abc1c486a1d6dbc377e6436579b2ed412:47
petefothpaulsherwood: surely not :)12:47
jjardonah, makes sense12:47
SotKjmacs: thats odd, how much did it need to build from scratch?12:48
paulsherwoodjmacs: could you possibly post the morph output from that, if you still have it?12:48
jmacsI don't know. This is the first time I've built anything in 2 months.12:48
* paulsherwood will leave this conv to sotk12:49
jmacsDon't have the morph output unfortunately12:49
SotKjmacs: do you have a morph log somewhere?12:50
jjardonssam2: Is it ok to update http://wiki.baserock.org/bug-reporting/ to mention storyboard?12:51
jjardonor is it not ready yet?12:51
ssam2I guess it's OK to update it12:52
jmacsSotK: Where would one be, if there was one?12:53
ssam2although storyboard is really a task tracker, not a bug tracker12:54
SotKthe quick-start guide suggests that morph is configured to put it in /src/morph.log12:54
SotKbut if you didn't follow that and "log" isn't mentioned in your /etc/morph.conf then I don't think you have one12:54
jmacsSotK: Oh yes, I was looking in /src/morph.12:55
pedroalvarezI think I know what happened with jmacs's build12:57
petefothI've added a 'USe the latest version' section to the 'Build issues page' http://wiki.baserock.org/guides/build-failures/?updated#index1h2, http://source.baserock.branchable.com/?p=source.git;a=blobdiff;f=guides/build-failures.mdwn;h=2baead44b0f9d43eecfd45c1d7f75bfa590de257;hp=b4ff87a3d7bc8c2f58fc97a1910dd088c5cf3c67;hb=598ad260ef3f459eaab65bf25c9fca68e9b5b79c;hpb=941b34d69abc1c486a1d6dbc377e6436579b2ed412:57
pedroalvarezcache.baserock.org was full last night, so mason failed to populate it.12:58
SotKaha12:59
SotKthat would explain it12:59
ssam2i just send a patch for adding git-review to baserock using git-review in baserock :)13:00
petefothThe simplest way to ge the latest system is to create a new VM. The new VM can use the vdisk containg the /src partition from the old VM so you won't (shouldn't) lose any work.13:01
petefothssam2: nice!13:01
pedroalvarezohh! :D13:01
pedroalvarezwe will be able send reviews from baserock :)13:02
* paulsherwood cant see any way to add himself to mergers group - no sign of any such group13:02
petefothpaulsherwood: I think that needs to be done by someone in the Administrators group, whcih you also wont be able to see13:03
paulsherwoodheh13:04
petefothhopefully a member of that group will pass this way soon13:04
pedroalvarezadministrators == baserock ops13:04
ssam2i've just added you and Adam13:04
paulsherwoodtvm13:04
petefothcan I nominate paulsherwood for membership of bserock ops?13:04
* petefoth ducks13:05
SotKty ssam213:05
* pedroalvarez adds himself13:06
* paulsherwood wonders where the big red 'merge button' is13:08
SotKpedroalvarez: looks like jmac had to rebuild from stage-1 for some reason... would the cache.b.o issue explain that?13:09
paulsherwoodpossibly13:09
SotKit managed to fetch stage-1-binutils but everything else needed building13:10
pedroalvareztoday?13:10
* pedroalvarez goes to se some logs13:10
SotKyesterday between about 17:00 and 20:0013:10
ssam2paulsherwood: it only appears when you can merge, stupidly. It's blue and says 'Submit'13:11
SotK17:34 to be more precise13:11
pedroalvarezSotK: at that time mason was failing  because cache.b.o was full13:12
pedroalvarezbut it had a lot of things built13:12
paulsherwoodssam2: ok. so even though c13 appears to have 2x +1, it seems not to be ready for merge?13:12
pedroalvarezSotK: so one guess is that the artifact server was failing to  give you the files because it was full13:13
* paulsherwood may be missing something obvious, here13:13
SotKjmacs: were you using latest morph?13:13
ssam2paulsherwood: 1+1 does not = +2 in gerrit13:13
ssam2someone has to explicitly give a +213:13
paulsherwoodssam2: ah. so by default second reviewer should do that in future?13:13
jmacsSotK: I think so; I'd just cloned it, and fixed that pylru issue13:14
ssam2paulsherwood: giving a +2 in Gerrit is effectively saying "I'm certain that this should be merged"13:15
ssam2anyone in the Mergers group who thinks a patch should definitely be merged should give a +213:15
ssam2if it already has 10x +1s that will probably make the decision quite easy, but someone still needs to make the final decision13:15
ssam2I think that if it has no +1s but you are sure it works, it's fine to give a +2 straight away13:16
SotKjmacs: and you were using master?13:16
ssam2paulsherwood: for your 'Make stage2-linux-api-headers and stage2-gawk dependencies explicit' patch I didn't want to go ahead and give a +2 right away, sorry13:17
paulsherwoodssam2: i understand, i'm just trying to iron out procedure here.13:18
jmacsSotK: master of morph, baserock/pedroalvarez/rpi2 of definitions, but that's pretty close to master13:18
petefoththe 'site:wiki.baserock.org morph' search string works for DDG as well as Google. BUt I've just spotted the search box in the top right hand corner over every page. IS that new, or was jmacs fibbing when he said 'Search doesn't work on our wiki.'?13:19
paulsherwoodif one reviewer says +1, then another does the same, this requires a third step. simpler would be if a patch already has +1, second reviewer by default does +2 and merge, unless there is doubt, in which case second reviewer shuoldn't even be giving +1 ???13:19
paulsherwoodssam2: ^^13:20
pedroalvarezjmacs: you just reminded me I havn't shared with you changes needed in Morph to support armv6lhf: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=baserock/pedroalvarez/rpi13:21
ssam2paulsherwood: agreed13:21
ssam2but the second review has to be someone in the Mergers group to be able to do that13:21
* SotK is out of ideas as to why it decided to rebuild then13:21
ssam2*reviewer13:21
jmacspedroalvarez: Thought there might be some :)13:21
ssam2paulsherwood: if we allowed anyone to give a +2, anyone who signed up would be able to merge stuff to master right away13:22
rdalei've just set up a baserock openid account, and i got a mail back saying it was set up, but i can't login using the password i gave when registering13:22
* rjek frowns at the register form's name fields.13:23
ssam2rdale: what error do you get?13:23
petefothIt's good to separate merge from review. I'ts an extra step for reviewers who are also mergers, but that's no bad thing IMO13:24
rdalePlease enter a correct username and password. Note that both fields may be case-sensitive13:24
ssam2hmm13:24
rjekI just managed to register and successfully login.13:24
*** wschaller has joined #baserock13:24
rdalei can try 'forgot password' even though i haven't13:25
pedroalvarezIf rjek managed to register and login, I'm sorry rdale, but then it's your fault :P13:26
ssam2rdale: I can't find anything that might have gone wrong13:26
ssam2rdale: you have an account, with a password set13:26
rdalehmm13:26
ssam2i can tell you the hash, salt and algorithm if you want :) but of course not the password13:26
rdalei'm just using 'forgot password' to reset the password13:27
paulsherwoodssam2: i'm ok with second review has to be by a merger13:27
ssam2cool13:27
paulsherwoodseems best13:27
paulsherwoodpetefoth: do you really want to involve 3 people for review/merge of every change?13:28
petefothpaulsherwood: I think it makes sense to separate the 'review' and 'merge' steps. Doesn't have to be three people13:29
petefothjust three distinct steps13:30
rdaledoh! i was typing in my email address instead of my username13:30
paulsherwoodi don't, in this context. i see no value in separating second review from merge13:30
paulsherwoodi can be wrong, however13:30
petefothI guess we can live without agreeing on this :) I'm happy to defer to the wisdom of others13:31
paulsherwoodkey point is, if second reviewer doesn't do +2, no-one can merge. if they do +2, they can merge, and save somone else having to do so asynchronously13:31
petefothbut can a second review be done by someone who doesn't have nerge powers?13:32
pedroalvareznope13:32
paulsherwoodi'm suggesting that by default, no13:32
petefoththen I disagree more strongly13:32
petefoththe more reviewers the better.13:33
paulsherwoodi fear you don't understand, petefoth13:33
pedroalvarezthey are almost the same thing, but having them separate makes the user that is going to do the merge think better what is he doing13:33
paulsherwood'the more reviewers the better' is just *not true*13:33
* petefoth walks away13:34
paulsherwoodand there is enough science to disprove it, iiuc. http://www.amazon.com/Making-Software-Really-Works-Believe/dp/059680832113:34
* straycat hopes it's still possible to express "you have +2, but you can fix these up and merge yourself"13:34
ssam2straycat: +2 doesn't automatically merge, someone needs to press 'submit'13:35
petefothSO we're saying 'Someone has already reviewed this, and you don't have +2 powers so you may not record your review comments'?13:35
straycatssam2, cool13:35
petefothThat is so clearly nonsense...13:35
paulsherwoodpetefoth: nope, i'm not saying that.13:35
petefoth I said ' can a second review be done by someone who doesn't have nerge powers?' and pedroalvarez said 'nope'/ What am I missiong?13:36
paulsherwoodhere, we have practical issues. limited bandwidth for people who can (and are trusted to) merge13:36
paulsherwoodnothing to *stop* other reviewers, but actually, we struggle to get *enough* reviews done13:37
pedroalvarezpetefoth: sorry, I undesrtood that as ' can a +2 be done by someone...'13:37
petefothOK so long as anyoine can record review comments, I'm happy13:37
paulsherwoodand having 4 folks pile in to do second reviews (say), with none of them merging, would be a waste of limited resources13:37
petefothpaulsherwood: it's OK pedroalvarez has clarified13:39
paulsherwoodso i'm just advocating that 2nd review can and by default should be done by a merger, and that if they review positively, they merge, rather than leaving it as another step for someone else13:39
pedroalvarezI'd say that whoever presses the +2 buttom, also preses the "submit" buttom13:39
paulsherwood+2 :-)13:39
petefoth+1 :)13:39
paulsherwoodhooray :-)13:39
straycatpedroalvarez, unless there are optional fixups13:40
paulsherwoodpetefoth: you might still find that book interesting. subsequent reviews appear not to be worth very much13:40
pedroalvarezalso a +2 review can be also just check the other +1 reviews, check the reviewers, and trust them.13:40
* paulsherwood gest back to work :-)13:40
petefothpaulsherwood: thanks13:40
straycatit'd be pretty annoying to get a review back saying "you've accidentally made this sort locale dependant but i merged it anyway"13:40
* petefoth does likewise13:40
petefothpaulsherwood: do you ahve a copy of that book13:41
pedroalvarezstraycat: we need to research about the fixup-on-merge with gerrit13:41
paulsherwoodi think i bought it on kindle, will check13:41
straycatanyway, clearly that would never happen so *shrug*13:41
straycatpedroalvarez, yeah :)13:42
*** zoli__ has quit IRC13:44
mauricemoss_Does anyone know why I can't create a symlink with Morph like this? `ln -s $DESTDIR/bin/uci /bin/uci` throws 'ln: failed to create symbolic link '/bin/uci': Read-only file system'14:05
Kinnisonln from to14:05
Kinnisonso you want ln -s /bin/uci "${DESTDIR}/bin/uci"14:06
rdalewon't that copy the symlink over /bin/uci when the chunk is used subsequently?14:10
Kinnisonoh point14:11
* Kinnison didn't even think about the paths, was just confused by destdir in the wrong side14:11
Kinnisonmauricemoss_: why are you trying to alter /bin during a build?14:11
mauricemoss_Kinnison, I want it the other way round.. Morph installs the binary in /usr/bin/* when installing it in "/" instead of "/usr" Morph can't find the include files if packages depend on each other14:13
mauricemoss_Unfortunately OpenWrt use stuff like:14:14
mauricemoss_char *plug[] = { "/sbin/procd", "-h", "/etc/hotplug-preinit.json", NULL };14:14
mauricemoss_execvp(plug[0], plug);14:14
mauricemoss_so I need a symlink or the binary to be in "/sbin" or "/bin" :-/14:15
mauricemoss_(depending on the package)14:15
KinnisonAre you building with PREFIX=/usr instead of PREFIX=/ perhaps?14:15
mauricemoss_Is PREFIX=/usr not required to run Morph? All the chunks use this prefix, don't they?14:17
rdalei would do: cd "$DESTDIR$PREFIX/bin" ; ln -s ../usr/bin/uci uci14:17
*** zoli__ has joined #baserock14:18
Kinnisonmauricemoss_: PREFIX=/usr is just the default, if you need to build your stuff with a different PREFIX then set it for your chunk14:18
rdaleoops, i meant: cd "$DESTDIR$PREFIX/bin" ; ln -s ../bin/uci uci14:20
mauricemoss_Kinnison: Ok, I'll give it a try again. I've seen issues with includes going wrong.14:20
mauricemoss_rdale, ta!14:21
Kinnisonmauricemoss_: You might need PREFIX=/usr but BINDIR and SBINDIR set differently14:21
rdaleyes, i don't think a prefix of '/' will work14:21
Kinnisonmauricemoss_: the particular chunks will need you to tweak them if they have such hardcoded paths14:21
rdaleoops, attempt #3: cd "$DESTDIR$PREFIX/bin" ; ln -s ../../bin/uci uci14:22
mauricemoss_Kinnison: cool, I didn't know about BINDIR. is there a list of all the environment variables Morph uses somewhere?14:24
richard_mawBINDIR and SBINDIR aren't set by morph14:24
richard_mawthey're defined by make usually14:24
richard_mawhence are only visible in the makefiles14:24
richard_mawbut they derive part of their value from PREFIX14:24
richard_mawwhich morph does define14:25
richard_mawyou can of course override BINDIR and SBINDIR in your chunk definition file to get autotoolsy programs to install it elsewhere14:25
richard_mawbut that's better off done in the configure-commands if it supports it14:25
mauricemoss_richard_maw, ok thanks!14:26
*** jonathanmaw has quit IRC14:36
*** jonathanmaw has joined #baserock14:37
*** zoli__ has quit IRC14:41
*** jonathanmaw has quit IRC14:41
*** jonathanmaw has joined #baserock14:42
ratmice__mauricemoss_: these variables generally come from the gnu coding standards15:02
ratmice__https://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables15:02
*** zoli__ has joined #baserock15:11
mauricemoss_ratmice__, good to know :)15:16
*** sambishop has quit IRC15:25
*** ssam2 has quit IRC15:27
paulsherwoodooh, ratmice__ - been meaning to ask you - do you have any interest in deterministic builds?15:29
paulsherwood(ie bit-for-bit reproducibility)15:29
*** sambishop has joined #baserock15:40
*** ssam2 has joined #baserock15:40
*** ChanServ sets mode: +v ssam215:40
tiagogomes_mmm, doesn't morph support submodules? I am getting a build failure because the project that I am trying to compile has a submodule to gnulib15:46
tiagogomes_the gnulib directory is empty thought15:46
SotKwhat is the url for it in .gitmodules?15:46
tiagogomes_ah never mind, I was looking at the wrong directory15:47
* tiagogomes_ needs caffeine15:47
rdalei can't clone the gerrit definitions repo - have a got the right url: git://gerrit.baserock.org/baserock/baserock/definitions16:01
radiofreewhen i try to register a new e-mail in gerrit i get a 50016:03
jmacsrdale: Try git clone http://gerrit.baserock.org/baserock/baserock/definitions16:03
jmacsI don't know if that will get you push access though16:03
rdalei can clone with that at least - thanks16:04
pedroalvarezradiofree: registering a new e-mail requires gerrit to send email, and we don't have that bit atm16:06
franredwhat am I missing to get a segmentation fault running make in kmod after it compiles fine from morph? http://paste.baserock.org/afazehujut16:07
pedroalvarezfranred: /dev /proc and maybe others16:08
pedroalvarezmaybe just /proc16:08
*** sherm_ has quit IRC16:11
franredpedroalvarez, do I need to mount them and run the configuration commands? or mounting them and running make should be enough?16:12
pedroalvareziirc it was: bind mount them before running chroot, and then make should work16:13
pedroalvarezI don't see why you would need to run the configure commands again16:14
franredpedroalvarez, thanks, I will try it16:14
rdalei've pushed my change to gerrit with this command:  git push origin HEAD:refs/for/master/baserock/rdale/update-cmake is that all i need to do?16:17
ratmice__paulsherwood: yeah, but I don't think its particularly crucial for anything i would be doing in the near future16:17
jjardonradiofree: known bug: https://storyboard.baserock.org/#!/story/2816:17
ssam2rdale: I don't see it...16:18
ssam2what is 'origin' ?16:18
rdalebother, it should be gerrit. i just copied the push command from the wiki16:19
SotK hm, is the wiki wrong?16:20
rdalehere's what i've been doing: http://paste.baserock.org/ewaqucokaf16:21
jjardonrdale: can you try git push origin HEAD:refs/for/master/update-cmake ?16:21
jjardonrdale: yo should use git push gerrit HEAD:refs/for/master/update-cmake instead16:22
rdalestill not working: http://paste.baserock.org/eqotarakus16:24
franredpedroalvarez, still having the segmentation fault16:24
paulsherwoodrdale: gerrit, not origin16:24
jjardonnot sure why the --origin=gerrit was added in the wiki but Ive just fixed it16:24
paulsherwoodoops. i see you did that16:25
ssam2rdale: do you have a Change-Id in your commit message?16:25
jjardonrdale: seems you bracnh doesnt have any changes against what its already in the remote repo. can you check you are locally in the correct branch and that you have the Chane-Id in every commit?16:26
rdalei downloaded the hook - but i had commited the change before adding the hook - is that the problem?16:26
franredjjardon, I think petefoth added because gerrit-review understand "gerrit" as remote name16:26
paulsherwoodrdale: i hit that too. yes, need to make the commit again16:26
jjardonrdale: yes, run git commit --amend to add it16:26
* straycat hugs richard_maw16:29
straycatthanks!16:29
straycati hadn't even got 'round to biffing yet16:29
pedroalvarezs/gerrit-review/git-review/16:33
rdalei have a change-id in my commit, but i still can't seem to push the change: http://paste.baserock.org/munoqeweda16:35
paulsherwoodmissing tree?!16:36
pedroalvarezfranred: just found this, which is what rdale was using to avoid that problem: http://paste.baserock.org/atawenivoc16:37
franredpedroalvarez, no luck with that either :/16:42
ssam2rdale: wow, '! [remote rejected] HEAD -> refs/for/master/update-cmake (n/a (unpacker error))' is totally new16:44
rdaleoh :(16:44
Kinnisonapparently that can be related to filesystem permission errors16:45
Kinnisonhttp://stackoverflow.com/questions/4025708/git-cant-push-unpacker-error-related-to-permission-issues16:45
ssam2no permission errors I can see, but several other possible causes16:46
ssam2https://stackoverflow.com/questions/16586642/git-unpack-error-on-push-to-gerrit16:47
ssam2probably https://code.google.com/p/gerrit/issues/detail?id=1582 which seems to be fixed in 2.1016:47
Kinnisonurgh16:47
ssam2we're still on 2.916:47
KinnisonThis is one reason gitano uses git's implementation of git16:47
ssam2rdale: try adding '--no-thin' to the 'git push' cmdline as a workaround16:47
rdaleok16:48
rdalethat works - so it is the same problem as the stackoverflow page16:48
rdaleyes! my change is on the list of patches for review now16:49
*** a1exhughe5 has quit IRC16:56
paulsherwoodrichard_maw: are you -1 on my patch, based on your email just now? it already has +216:58
paulsherwood(well +1 and +1)16:58
richard_mawpaulsherwood: I have no objections to your patch specifically, just to the idea that we should do it everywhere in general16:59
richard_mawit may be useful to be explicit in build-essential16:59
richard_mawbut I wouldn't want it to be mandatory everywhere16:59
straycatmy +1 is for build-essential only fwiw16:59
paulsherwoodunderstood. if/when i get past build-essential, i should be able to establish how pervasive this is17:00
paulsherwoodat the moment, folks must admit that we don't know?17:00
jjardonssam2: see? we need 2.10 :)17:00
rdalei am using git 1.9.1 on my laptop17:01
*** jonathanmaw has quit IRC17:01
straycatcan only imagine it *might* grow unwieldy for very large strata, maybe?17:01
richard_mawpaulsherwood: I know that it's totally pervasive, because at one point we were encouraged to remove redundant dependency information to make strata smaller17:01
edcragghi, this commit (http://paste.baserock.org/cuduruqote) appears to break building bison in the native build phase of cross-bootstrap. specifically, i think the bison 'bootstrap' script does rely on being run with bash. Would submitting a reversion to this patch be an acceptable solution?17:05
paulsherwoodi know i did that, for build-depends: at stratum level. i don't think i was involved in this logic, which still seems obscure to me17:05
paulsherwoodrichard_maw: ^^17:05
Kinnisonjjardon: You committed the change that edcragg is referring to -- reverting it results in native bootstrap completing again17:05
Kinnisonjjardon: was it purely a "cleanup" or was the change to remove bash something explicitly needed?17:06
jjardonedcragg: Kinnison: only cleanup, ok by me reverting it (with the reason so we do not change it again)17:07
Kinnisonedcragg: Fancy producing a reversion with explanation and submitting it to gerrit?17:07
Kinnisonjjardon: thanks :)17:07
edcraggjjardon: thanks17:07
edcraggKinnison: sure17:07
paulsherwoodrichard_maw: anyways, if the ultimate conclusion is to imply the depends of depends, doesn't that mean some of the dependency info the strata are currently carrying is also redundant? it's inconsistency i'm unhappy with17:07
* richard_maw remembers quizzing jjardon about it at the time, and being told that he'd checked17:08
Kinnisonrichard_maw: it's possible the issue only manifests during native_bootstrap17:08
Kinnisonrichard_maw: given the "interesting" environment there17:08
richard_mawpaulsherwood: in general I also prefer consistency, but I believe exceptions are sometimes better, like your proposed patch to build-depends. Dependencies are much trickier during the bootstrap.17:11
* paulsherwood actually believes other strata behave differently.. but will need time to prove it17:11
paulsherwoodin other news, i'm tearing my hair out trying to understand what could cause stage2-gcc to build differently in ybd vs morph, when all earlier components appear to be the same. is there something special about stage2-gcc?17:13
Kinnisonthe compiler stages are *really* delicate17:13
paulsherwood(i even went to the extent of making ybd use morph's artifacts...)17:13
KinnisonAre you confident that the environment matches exactly?17:13
paulsherwoodi'm 98% confident, yes17:14
KinnisonWe've been having bootstrap issues purely related to whether /usr/bin comes before /bin in PATH17:14
Kinnisonso check things like that17:15
radiofreepaulsherwood: what's different about them?17:16
jmacsDo we have any support for building an upstream ref + a patch file (maybe included in definitions?)17:16
radiofreejmacs: as far as i'm aware, no17:16
radiofreebut i think that would be nice17:16
Kinnisonjmacs: You get to apply the patch to a git branch IIRC17:16
radiofreei think that's what yocto does?17:17
jmacsradiofree: It is.17:17
jmacsI mean, they carry patches around in their equivalent of definitions.17:17
pedroalvarezwe prefer go upstream and fix things there :P17:17
radiofreepedroalvarez: well that's not always going to work out17:17
radiofreee.g http://git.baserock.org/cgi-bin/cgit.cgi/delta/gstreamer.git/commit/?h=baserock/morph/0.10&id=c7e4a97d26396882960fd399b1a5e298e40d2a3517:17
radiofreei'd prefer that submodule updating to be done my morph, rather than having to add it to a git repo17:18
pedroalvarezradiofree: indeed, we are planing other solutions for that17:19
paulsherwoodradiofree: looks like i blew away my results, will need to reproduce overnight17:22
* radiofree momentarily confused pedroalvarez for paulsherwood17:30
paulsherwoodinteresting :)17:30
pedroalvarezknown issue17:30
richard_mawBug closed: WONTFIX17:41
radiofreeNOTABUG?17:42
jjardonmy understanding is that dependencies within a stratum are always explicit: it can be implicit between strata17:44
jjardonrichard_maw: not sure if this is related with what you were talking about?17:45
*** Krin has quit IRC17:46
richard_mawjjardon: it's useful data, but your understanding was incorrect, recursive dependencies have always been considered withing a stratum, and at one point they weren't between strata.17:47
jjardonId like to do everything explicit17:50
jjardonthere are not so many strata anyway17:51
richard_maw91 total strata, 340 chunks with definition files17:52
jjardonmmm, thinking twice Im not sure; it would be a bit weird have a openstack stratum depending on build-depends and all the stratum on top17:52
*** bashrc_ has quit IRC17:53
richard_mawit would certainly be rather verbose17:53
jjardonrichard_maw: high number of strata doesnt mean that you depend on all of them: there is not a vertical hierachy, but rather a horizontal one when you reach a point17:54
jjardonone of my concerns is when you move chunks around: you dont really know if you can or not remove build-depends from  the stratum, as there is not info why a specific stratum depends on other strata17:56
richard_mawthat's an excellent new point17:57
richard_mawthe only solution I can think of for that is to list stratum build dependencies per-chunk, at which point we've nearly thrown out strata entirely17:58
jjardonone solution would be to make the chunk depend on strata?17:58
jjardon:)17:58
richard_mawyeah, have each chunk declare all the strata it depends on, rather than every chunk implicitly depending on every stratum listed at the top of the stratum file17:58
jjardonyeah, we think the same17:59
ssam2i think that's a good idea (chunks depending directly on strata)17:59
rdalethat sounds worse than what we have to me18:00
richard_mawif we do that, and allow chunks to depend on chunks from other strata then strata become just a way to group chunk definitions18:00
ssam2which I believe is on the wishlist anyway18:00
rdalemainly we have poor command line only tooling, which makes it very hard to do queries such as 'show me the implicit dependencies for this chunk'18:00
jjardonrichard_maw: I was thinking allow chunks to depend on other strata, not other chunks from other strata18:01
richard_mawI know, I was just thinking about other changes we could also do which would make sense in some contexts18:02
*** mdunford has quit IRC18:05
ssam2rdale: if we decide to add an extra layer of tooling, this discussion becomes more or less irrelevant.18:06
ssam2but I don't think we'll be able to do that any time soon18:06
*** CTtpollard has quit IRC18:07
rdaleyes, so to me it seems premature to start messing with the build-essential stratum18:07
*** ssam2 has quit IRC18:09
*** zoli__ has quit IRC18:11
*** zoli__ has joined #baserock18:15
*** tiagogomes_ has quit IRC18:17
*** rdale has quit IRC18:25
*** zoli__ has quit IRC18:33
paulsherwoodhmmm...18:58
paulsherwoodso, before i spend many more hours on this...18:59
paulsherwoodif we look at http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/erlang.morph19:01
paulsherwood(for example)19:01
paulsherwoodyou folks are saying that because rebar requires erlang, erlang-sd_notify should only need to require rebar, and it would be expected behaviour that morph infers that because it needs rebar, it also needs erlang?19:03
*** wschaller has quit IRC19:09
*** lachlanmackenzie has quit IRC19:20
*** zoli__ has joined #baserock19:21
*** gfinney has quit IRC19:30
*** gfinney has joined #baserock19:32
*** CTtpollard has joined #baserock19:40
*** gary_perkins has quit IRC19:51
*** zoli__ has quit IRC20:10
*** zoli__ has joined #baserock20:10
*** edcragg has quit IRC20:18
* paulsherwood wonders why even bother with the build-depends given this behaviour. morph could just build in order, so all chunks 1-n in a stratum are assumed present at build time for chunk n+120:44
paulsherwood(and they will be present at runtime anyway....)20:45
*** pacon2 has joined #baserock21:08
SotKwith the same happening based on stratum order in a system?21:16
*** persia has quit IRC21:50
*** persia has joined #baserock21:51
*** persia has joined #baserock21:51
*** gfinney has quit IRC22:26
*** gfinney_ has joined #baserock22:26
*** pacon2 has quit IRC23:39

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!