*** oleksandr has joined #baserock | 00:01 | |
*** oleksandr has quit IRC | 00:07 | |
*** jjardon has quit IRC | 00:30 | |
*** edcragg has quit IRC | 00:31 | |
*** jjardon has joined #baserock | 00:31 | |
*** edcragg has joined #baserock | 00:44 | |
*** zoli__ has joined #baserock | 01:24 | |
*** edcragg has quit IRC | 01:24 | |
*** zoli__ has quit IRC | 01:28 | |
*** zoli__ has joined #baserock | 06:17 | |
*** zoli__ has quit IRC | 07:02 | |
*** zoli__ has joined #baserock | 07:06 | |
*** pacon2 has quit IRC | 07:31 | |
petefoth | When 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 |
---|---|---|
petefoth | Tried clearing cookies and stuff, but same response | 07:36 |
petefoth | It 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 #baserock | 07:40 | |
*** a1exhughe5 has joined #baserock | 08:09 | |
*** gfinney has joined #baserock | 08:17 | |
*** XuLiu has joined #baserock | 08:17 | |
*** XuLiu has quit IRC | 08:19 | |
*** pacon2 has quit IRC | 08:38 | |
*** pacon2 has joined #baserock | 08:38 | |
*** rdale has joined #baserock | 08:47 | |
*** pacon2 has quit IRC | 08:47 | |
*** pacon2 has joined #baserock | 08:48 | |
*** franred has joined #baserock | 08:52 | |
*** bashrc_ has joined #baserock | 08:57 | |
*** mdunford has joined #baserock | 09:04 | |
*** sherm_ has joined #baserock | 09:05 | |
petefoth | I 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 #baserock | 09:08 | |
*** gary_perkins has joined #baserock | 09:22 | |
franred | petefoth, 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 think | 09:23 |
petefoth | franred: thanks. IS there any advantage do renaming before doing the clone? | 09:24 |
franred | petefoth, you don't do the rename, you just say which alias has that repository that you are cloning from | 09:24 |
franred | s/say/specified/ | 09:25 |
*** radiofree has quit IRC | 09:26 | |
*** radiofree has joined #baserock | 09:26 | |
petefoth | franred: Sorry - I'm confused. Maybe easier for you just to make the change :) | 09:27 |
*** pacon2 has quit IRC | 09:28 | |
franred | petefoth, ok, let me check a couple of things | 09:29 |
*** pacon2 has joined #baserock | 09:29 | |
petefoth | franred: OK - the clone (in the changuing morph section' is a copy of / reference to the instructions in 'Using latest version of Morph' page | 09:30 |
*** radiofree has quit IRC | 09:30 | |
*** radiofree has joined #baserock | 09:31 | |
*** radiofree has quit IRC | 09:31 | |
*** tiagogomes_ has joined #baserock | 09:32 | |
franred | petefoth, 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 #baserock | 09:34 | |
petefoth | franred: OK. Shall I change both pages? | 09:34 |
*** radiofree has quit IRC | 09:35 | |
franred | petefoth, please do it :) | 09:36 |
* petefoth does 'git help clone' and reads the output carefully :) | 09:36 | |
*** radiofree has joined #baserock | 09:37 | |
*** radiofree has quit IRC | 09:38 | |
*** radiofree has joined #baserock | 09:38 | |
SotK | Can anyone enlighten me on what may have gone wrong here? http://paste.baserock.org/uvidiwesop | 09:42 |
* SotK notices his disk is quite full, maybe it was that | 09:43 | |
petefoth | franred: I caan't make the --origin parameter work - tried various permutations - see http://paste.baserock.org/ejuwotexog | 09:44 |
petefoth | franred: ignore me please, I'm stupid :) | 09:45 |
petefoth | Done! | 09:49 |
franred | http://paste.baserock.org/galezidewu | 09:50 |
franred | petefoth, :D | 09:50 |
gfinney | Help 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 |
gfinney | What's going wrong | 09:51 |
*** ssam2 has joined #baserock | 09:52 | |
*** ChanServ sets mode: +v ssam2 | 09:52 | |
rdale | morph was recently changed to make build dependencies optional - before they were mandatory | 09:52 |
jjardon | gfinney: follow this to use latest morph: http://wiki.baserock.org/using-latest-morph/ | 09:53 |
gfinney | OK lets give it a go. | 09:54 |
*** edcragg has joined #baserock | 09:56 | |
*** pacon2 has quit IRC | 09:59 | |
*** pacon2 has joined #baserock | 10:00 | |
jjardon | petefoth: good work! I do not think changing definitions requires any special config though | 10:01 |
petefoth | jjardon: it's not about changing definitions particularly, it's about working within a system branch created by 'morph branch' | 10:02 |
petefoth | jjardon: which is different from changing morph in the /src/morph directory | 10:03 |
jjardon | petefoth 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 |
petefoth | jjardon: hopefully the page can be simplified once the 'morph branch' workflow is removed, deprecated, whatevered | 10:09 |
richard_maw | best we could think of for a group of system deployments | 10:09 |
Kinnison | Most deployments in the wider world are more of than one system. We chose the term 'cluster' to represent how they tend to be interrelated | 10:09 |
*** Krin has joined #baserock | 10:10 | |
petefoth | jjardon: how are you getting on with your 'What I do with Baserock' story? | 10:10 |
*** lachlanmackenzie has joined #baserock | 10:12 | |
ssam2 | I've found that in practice I never use cluster morphs with more than one entry, even when there are multiple related systems | 10:12 |
ssam2 | mostly because I need to configure each system post deployment in some way | 10:12 |
ssam2 | radiofree: 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=00c3e68d563b6147abc823211386eb25bfb42ea0 | 10:13 |
ssam2 | line wrapping :( i used the web interface | 10:13 |
radiofree | ssam2: +2 | 10:14 |
ssam2 | ta | 10:15 |
jjardon | petefoth: I should start writing that some of these days :) | 10:15 |
petefoth | jjardon: ;) | 10:15 |
*** wschaller has joined #baserock | 10:16 | |
jmacs | pedroalvarez: 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 |
pedroalvarez | jmacs: for someone without cross-bootstrap experience? | 10:38 |
jmacs | Either with or without would be a useful number | 10:40 |
pedroalvarez | jmacs: right, I'll give you an answer soon | 11:02 |
SotK | who can merge on gerrit.baserock.org? | 11:03 |
pedroalvarez | I believe that users on the Mergers group | 11:04 |
jmacs | Another question, has anyone tried to make a Yocto recipe import tool before? | 11:05 |
pedroalvarez | and I also believe that people that were allowed to do merges on git.b.o will be included on the mergers group | 11:05 |
pedroalvarez | jmacs: 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 |
pedroalvarez | with that, you will be able to use Morph in that architecture, and use it to build a rootfs of the new architecture | 11:10 |
Kinnison | jmacs: yocto recipes are (IIRC) turing complete making an import tool hard to write | 11:10 |
Kinnison | jmacs: It may be possible to heuristically import some recipes | 11:10 |
jmacs | Kinnison: Is that a 'no'? | 11:10 |
jmacs | pedroalvarez: For someone with cross-bootstrap experience? | 11:10 |
pedroalvarez | extra work will be research about how to build a bsp for the new architecture. | 11:10 |
Kinnison | jmacs: Noone has tried, mostly because it feels like a potentially black-hole endeavour | 11:10 |
Kinnison | jmacs: It's possible things have gotten better since then | 11:11 |
Kinnison | jmacs: but when I last looked, they even had logic to do with their build process encoded into file *paths* | 11:11 |
jjardon | ssam2: 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 |
pedroalvarez | jmacs: for someone with a bit of understanding of how Morph builds, and differences when building for different architectures | 11:12 |
bashrc_ | just a thought: does baserock.org actually run on baserock? | 11:12 |
pedroalvarez | most of them | 11:12 |
jmacs | pedroalvarez: OK, thanks | 11:13 |
pedroalvarez | s/and differences/and understands the differences/ | 11:14 |
petefoth | bashrc_: 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 VMs | 11:16 |
bashrc_ | nice | 11:16 |
franred | bashrc_, petefoth, gerrit and storyboard are not running in Baserock | 11:21 |
petefoth | franred: sorry - I thought they were | 11:22 |
petefoth | I 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 moving | 11:22 |
petefoth | bashrc_: ^^ | 11:22 |
*** oleksandr has joined #baserock | 11:22 | |
*** oleksandr is now known as Guest17903 | 11:23 | |
ssam2 | jjardon: 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 |
ssam2 | petefoth, franred: gerrit is on Baserock. storyboard is on Fedora right now | 11:24 |
ssam2 | petefoth: also, I believe codethink sponsor our hosting at branchable. | 11:25 |
petefoth | ssam2: ta! | 11:25 |
* petefoth learns lost of new things :) | 11:25 | |
franred | ssam2, ooh, I didn't know gerrit was in baserock, sorry for the confusion | 11:27 |
CTtpollard | I compiled a list of all the dependencies I could find for storyboard a while back, it is probably outdated now though | 11:31 |
CTtpollard | and uses a different method to host it compared to how it is done on s.b.o I believe | 11:32 |
ssam2 | I deployed storyboard.baserock.org with https://github.com/openstack-infra/puppet-storyboard | 11:32 |
ssam2 | but it took some manual fixups to get it to actually work | 11:32 |
ssam2 | well, it was a fork of https://github.com/openstack-infra/puppet-storyboard | 11:32 |
ssam2 | https://github.com/openstack-infra/puppet-storyboard seems to require a forked version of some puppet modules, it's a bit of a mess | 11:33 |
CTtpollard | I've only ever used it using the devel method of tox and grunt | 11:35 |
*** persia has quit IRC | 11:39 | |
*** persia_ has quit IRC | 11:39 | |
*** persia has joined #baserock | 11:40 | |
*** persia_ has joined #baserock | 11:40 | |
*** persia has quit IRC | 11:44 | |
*** persia_ has quit IRC | 11:44 | |
*** persia has joined #baserock | 11:46 | |
*** persia_ has joined #baserock | 11:46 | |
*** pacon2 has quit IRC | 12:06 | |
*** Guest17903 has quit IRC | 12:07 | |
petefoth | it 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 versions | 12:07 |
SotK | 'old knowledge' seems like a good place for this kind of thing | 12:08 |
jmacs | How do I know what I'm looking for is 'old knowledge'? | 12:08 |
* petefoth goes to create a story | 12:08 | |
Zara | we should also work out how old something needs to be before it counts as 'old knowledge' | 12:09 |
mwilliams_ct | This 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 |
jmacs | It bit me yesterday as well | 12:09 |
mwilliams_ct | I agree with jmacs, I wouldnt have known that was old knowledge specifically | 12:09 |
petefoth | jmacs: by searching the whole site? | 12:09 |
jmacs | petefoth: Search doesn't work on our wiki. | 12:09 |
petefoth | mwilliams_ct: but a year form now, who will be workign with that version | 12:09 |
Zara | that's why you need to work out how old it needs to be. | 12:09 |
ssam2 | my general opinion is that we have limited resources, and we should try to spend them supporting people who are using the latest released versions | 12:10 |
petefoth | jmacs: that's a different story. :) I think we should have a 'search the wiki' function | 12:10 |
petefoth | ssam2: +7 | 12:10 |
mwilliams_ct | petefoth: possibly me, I could decide to go and update an old VM rather than making a new one. I take your point though | 12:10 |
mwilliams_ct | I 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 |
ssam2 | a 'working with older versions of baserock' section would be fine, i think | 12:11 |
jmacs | ssam2: I probably wouldn't have thought to look there. | 12:11 |
petefoth | mwilliams_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 |
ssam2 | jmacs: 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 remove | 12:12 |
ssam2 | if they are in their own page, then at least only that page becomes full of them | 12:12 |
ssam2 | morph will need more deps once the ostree branch is merged, for what it's worth | 12:12 |
jmacs | If a search for "pylru" finds the relevant page, I think that will do fine. | 12:13 |
Zara | I think that if the wiki only supports the latest version of baserock, that should be made explicit on the wiki. | 12:13 |
ssam2 | that's a good idea | 12:14 |
ssam2 | ideally we'd have versioned documentation, but that's a long way off | 12:15 |
mwilliams_ct | petefoth: that seems a good compromise | 12: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 other | 12:15 | |
mwilliams_ct | (I say compromise, actually it seems a better idea full stop) | 12:15 |
SotK | things 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 general | 12:16 |
Zara | I 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 documentation | 12:18 |
richard_maw | it is, you can clone git clone git://baserock.branchable.com/ | 12:18 |
mwilliams_ct | bashrc_: 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 it | 12:18 |
petefoth | bashrc_: 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_maw | also, we don't tag which version the documentation is for | 12:19 |
jmacs | But 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 edits | 12:19 |
petefoth | bashrc_: it can be assumed, but the ssumption woudl likely be wrong, as the wiki doesn't get as much update love as the code | 12:21 |
petefoth | jmacs: 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 |
petefoth | The 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+pylru | 12:34 |
franred | ssam2, who has merge permissions in gerrit? and if someone has it which is the button to press to merge one accepted patch? | 12:37 |
petefoth | The 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 proof | 12:37 |
SotK | franred: I think there is a "Submit" button on the change screen if you have merge permissions | 12:38 |
jmacs | petefoth: That's a good idea. | 12:38 |
ssam2 | franred: finally, someone asks! | 12:39 |
ssam2 | anyone in Mergers group has merge permissions | 12:39 |
* SotK asked earlier today! | 12:39 | |
SotK | :) | 12:39 |
ssam2 | one of the ops needs to manually people to Mergers groups. anyone already in baserock-writers on git.baserock.org can go in right away | 12:40 |
* pedroalvarez now checks if he told SotK the right answer | 12:40 | |
petefoth | jmacs: 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 prominent | 12:40 |
SotK | pedroalvarez: you did :) | 12:40 |
franred | ssam2, ok, I think Im not in the mergers group | 12:40 |
ssam2 | anyone 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 group | 12:40 |
ssam2 | franred: you should be in Administrators group, so you can add yourself | 12:40 |
paulsherwood | ssam2: so i'm not a merger, which is fine unless folks think it'd be better to include me | 12:41 |
jmacs | petefoth: 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 |
paulsherwood | several hours? | 12:41 |
ssam2 | paulsherwood: you're in baserock-writers on git.baserock.org, so it's up to you | 12:42 |
paulsherwood | historically i've done a couple of merges, at a pinch. happy to be included, but wouldn't want to become a bottleneck | 12:42 |
*** wschaller has quit IRC | 12:42 | |
SotK | jmacs: it definitely shouldn't be taking several hours to do an upgrade :/ | 12:43 |
pedroalvarez | good thing is now nobody needs to be in any special group to push things for review | 12:43 |
paulsherwood | +1 | 12:43 |
Zara | petefoth: 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 |
petefoth | Zara: agreed | 12:44 |
jmacs | SotK: About 2 hours and 10 minutes on my VM last night. | 12:44 |
paulsherwood | yes. i started trying to tease out the logic on updates, forward+backward compatibility a couple of weeks ago, then got distracted | 12:44 |
ssam2 | paulsherwood: 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 want | 12:44 |
jmacs | That's just for the build, not counting deploy | 12:44 |
paulsherwood | jmacs: doing what, exactly? what kind of a VM is it, if i may ask? | 12:44 |
petefoth | I've updated http://wiki.baserock.org/policies/ to mention Gerrit | 12:45 |
SotK | jmacs: is artifact-cache-server set in your /etc/morph.conf? | 12:45 |
paulsherwood | jmacs: 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 CPU | 12:45 |
jjardon | petefoth: in policies? | 12:45 |
jmacs | I have artifact-cache-server set to http://cache.baserock.org:8080/ | 12:46 |
petefoth | jmacs: 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 diff | 12:46 |
petefoth | Isn't that on the roadmap somewhere? ;) | 12:46 |
paulsherwood | petefoth: i think you'll find it's a bit more complicated than that ((c) ben goldacre) | 12:47 |
petefoth | jjardon: yes http://source.baserock.branchable.com/?p=source.git;a=commit;h=941b34d69abc1c486a1d6dbc377e6436579b2ed4 | 12:47 |
petefoth | paulsherwood: surely not :) | 12:47 |
jjardon | ah, makes sense | 12:47 |
SotK | jmacs: thats odd, how much did it need to build from scratch? | 12:48 |
paulsherwood | jmacs: could you possibly post the morph output from that, if you still have it? | 12:48 |
jmacs | I don't know. This is the first time I've built anything in 2 months. | 12:48 |
* paulsherwood will leave this conv to sotk | 12:49 | |
jmacs | Don't have the morph output unfortunately | 12:49 |
SotK | jmacs: do you have a morph log somewhere? | 12:50 |
jjardon | ssam2: Is it ok to update http://wiki.baserock.org/bug-reporting/ to mention storyboard? | 12:51 |
jjardon | or is it not ready yet? | 12:51 |
ssam2 | I guess it's OK to update it | 12:52 |
jmacs | SotK: Where would one be, if there was one? | 12:53 |
ssam2 | although storyboard is really a task tracker, not a bug tracker | 12:54 |
SotK | the quick-start guide suggests that morph is configured to put it in /src/morph.log | 12:54 |
SotK | but if you didn't follow that and "log" isn't mentioned in your /etc/morph.conf then I don't think you have one | 12:54 |
jmacs | SotK: Oh yes, I was looking in /src/morph. | 12:55 |
pedroalvarez | I think I know what happened with jmacs's build | 12:57 |
petefoth | I'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=941b34d69abc1c486a1d6dbc377e6436579b2ed4 | 12:57 |
pedroalvarez | cache.baserock.org was full last night, so mason failed to populate it. | 12:58 |
SotK | aha | 12:59 |
SotK | that would explain it | 12:59 |
ssam2 | i just send a patch for adding git-review to baserock using git-review in baserock :) | 13:00 |
petefoth | The 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 |
petefoth | ssam2: nice! | 13:01 |
pedroalvarez | ohh! :D | 13:01 |
pedroalvarez | we 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 group | 13:02 | |
petefoth | paulsherwood: I think that needs to be done by someone in the Administrators group, whcih you also wont be able to see | 13:03 |
paulsherwood | heh | 13:04 |
petefoth | hopefully a member of that group will pass this way soon | 13:04 |
pedroalvarez | administrators == baserock ops | 13:04 |
ssam2 | i've just added you and Adam | 13:04 |
paulsherwood | tvm | 13:04 |
petefoth | can I nominate paulsherwood for membership of bserock ops? | 13:04 |
* petefoth ducks | 13:05 | |
SotK | ty ssam2 | 13:05 |
* pedroalvarez adds himself | 13:06 | |
* paulsherwood wonders where the big red 'merge button' is | 13:08 | |
SotK | pedroalvarez: looks like jmac had to rebuild from stage-1 for some reason... would the cache.b.o issue explain that? | 13:09 |
paulsherwood | possibly | 13:09 |
SotK | it managed to fetch stage-1-binutils but everything else needed building | 13:10 |
pedroalvarez | today? | 13:10 |
* pedroalvarez goes to se some logs | 13:10 | |
SotK | yesterday between about 17:00 and 20:00 | 13:10 |
ssam2 | paulsherwood: it only appears when you can merge, stupidly. It's blue and says 'Submit' | 13:11 |
SotK | 17:34 to be more precise | 13:11 |
pedroalvarez | SotK: at that time mason was failing because cache.b.o was full | 13:12 |
pedroalvarez | but it had a lot of things built | 13:12 |
paulsherwood | ssam2: ok. so even though c13 appears to have 2x +1, it seems not to be ready for merge? | 13:12 |
pedroalvarez | SotK: so one guess is that the artifact server was failing to give you the files because it was full | 13:13 |
* paulsherwood may be missing something obvious, here | 13:13 | |
SotK | jmacs: were you using latest morph? | 13:13 |
ssam2 | paulsherwood: 1+1 does not = +2 in gerrit | 13:13 |
ssam2 | someone has to explicitly give a +2 | 13:13 |
paulsherwood | ssam2: ah. so by default second reviewer should do that in future? | 13:13 |
jmacs | SotK: I think so; I'd just cloned it, and fixed that pylru issue | 13:14 |
ssam2 | paulsherwood: giving a +2 in Gerrit is effectively saying "I'm certain that this should be merged" | 13:15 |
ssam2 | anyone in the Mergers group who thinks a patch should definitely be merged should give a +2 | 13:15 |
ssam2 | if it already has 10x +1s that will probably make the decision quite easy, but someone still needs to make the final decision | 13:15 |
ssam2 | I think that if it has no +1s but you are sure it works, it's fine to give a +2 straight away | 13:16 |
SotK | jmacs: and you were using master? | 13:16 |
ssam2 | paulsherwood: 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, sorry | 13:17 |
paulsherwood | ssam2: i understand, i'm just trying to iron out procedure here. | 13:18 |
jmacs | SotK: master of morph, baserock/pedroalvarez/rpi2 of definitions, but that's pretty close to master | 13:18 |
petefoth | the '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 |
paulsherwood | if 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 |
paulsherwood | ssam2: ^^ | 13:20 |
pedroalvarez | jmacs: 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/rpi | 13:21 |
ssam2 | paulsherwood: agreed | 13:21 |
ssam2 | but the second review has to be someone in the Mergers group to be able to do that | 13:21 |
* SotK is out of ideas as to why it decided to rebuild then | 13:21 | |
ssam2 | *reviewer | 13:21 |
jmacs | pedroalvarez: Thought there might be some :) | 13:21 |
ssam2 | paulsherwood: if we allowed anyone to give a +2, anyone who signed up would be able to merge stuff to master right away | 13:22 |
rdale | i'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 registering | 13:22 |
* rjek frowns at the register form's name fields. | 13:23 | |
ssam2 | rdale: what error do you get? | 13:23 |
petefoth | It's good to separate merge from review. I'ts an extra step for reviewers who are also mergers, but that's no bad thing IMO | 13:24 |
rdale | Please enter a correct username and password. Note that both fields may be case-sensitive | 13:24 |
ssam2 | hmm | 13:24 |
rjek | I just managed to register and successfully login. | 13:24 |
*** wschaller has joined #baserock | 13:24 | |
rdale | i can try 'forgot password' even though i haven't | 13:25 |
pedroalvarez | If rjek managed to register and login, I'm sorry rdale, but then it's your fault :P | 13:26 |
ssam2 | rdale: I can't find anything that might have gone wrong | 13:26 |
ssam2 | rdale: you have an account, with a password set | 13:26 |
rdale | hmm | 13:26 |
ssam2 | i can tell you the hash, salt and algorithm if you want :) but of course not the password | 13:26 |
rdale | i'm just using 'forgot password' to reset the password | 13:27 |
paulsherwood | ssam2: i'm ok with second review has to be by a merger | 13:27 |
ssam2 | cool | 13:27 |
paulsherwood | seems best | 13:27 |
paulsherwood | petefoth: do you really want to involve 3 people for review/merge of every change? | 13:28 |
petefoth | paulsherwood: I think it makes sense to separate the 'review' and 'merge' steps. Doesn't have to be three people | 13:29 |
petefoth | just three distinct steps | 13:30 |
rdale | doh! i was typing in my email address instead of my username | 13:30 |
paulsherwood | i don't, in this context. i see no value in separating second review from merge | 13:30 |
paulsherwood | i can be wrong, however | 13:30 |
petefoth | I guess we can live without agreeing on this :) I'm happy to defer to the wisdom of others | 13:31 |
paulsherwood | key 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 asynchronously | 13:31 |
petefoth | but can a second review be done by someone who doesn't have nerge powers? | 13:32 |
pedroalvarez | nope | 13:32 |
paulsherwood | i'm suggesting that by default, no | 13:32 |
petefoth | then I disagree more strongly | 13:32 |
petefoth | the more reviewers the better. | 13:33 |
paulsherwood | i fear you don't understand, petefoth | 13:33 |
pedroalvarez | they are almost the same thing, but having them separate makes the user that is going to do the merge think better what is he doing | 13:33 |
paulsherwood | 'the more reviewers the better' is just *not true* | 13:33 |
* petefoth walks away | 13:34 | |
paulsherwood | and there is enough science to disprove it, iiuc. http://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321 | 13:34 |
* straycat hopes it's still possible to express "you have +2, but you can fix these up and merge yourself" | 13:34 | |
ssam2 | straycat: +2 doesn't automatically merge, someone needs to press 'submit' | 13:35 |
petefoth | SO 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 |
straycat | ssam2, cool | 13:35 |
petefoth | That is so clearly nonsense... | 13:35 |
paulsherwood | petefoth: 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 |
paulsherwood | here, we have practical issues. limited bandwidth for people who can (and are trusted to) merge | 13:36 |
paulsherwood | nothing to *stop* other reviewers, but actually, we struggle to get *enough* reviews done | 13:37 |
pedroalvarez | petefoth: sorry, I undesrtood that as ' can a +2 be done by someone...' | 13:37 |
petefoth | OK so long as anyoine can record review comments, I'm happy | 13:37 |
paulsherwood | and having 4 folks pile in to do second reviews (say), with none of them merging, would be a waste of limited resources | 13:37 |
petefoth | paulsherwood: it's OK pedroalvarez has clarified | 13:39 |
paulsherwood | so 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 else | 13:39 |
pedroalvarez | I'd say that whoever presses the +2 buttom, also preses the "submit" buttom | 13:39 |
paulsherwood | +2 :-) | 13:39 |
petefoth | +1 :) | 13:39 |
paulsherwood | hooray :-) | 13:39 |
straycat | pedroalvarez, unless there are optional fixups | 13:40 |
paulsherwood | petefoth: you might still find that book interesting. subsequent reviews appear not to be worth very much | 13:40 |
pedroalvarez | also 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 | |
petefoth | paulsherwood: thanks | 13:40 |
straycat | it'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 likewise | 13:40 | |
petefoth | paulsherwood: do you ahve a copy of that book | 13:41 |
pedroalvarez | straycat: we need to research about the fixup-on-merge with gerrit | 13:41 |
paulsherwood | i think i bought it on kindle, will check | 13:41 |
straycat | anyway, clearly that would never happen so *shrug* | 13:41 |
straycat | pedroalvarez, yeah :) | 13:42 |
*** zoli__ has quit IRC | 13: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 |
Kinnison | ln from to | 14:05 |
Kinnison | so you want ln -s /bin/uci "${DESTDIR}/bin/uci" | 14:06 |
rdale | won't that copy the symlink over /bin/uci when the chunk is used subsequently? | 14:10 |
Kinnison | oh point | 14:11 |
* Kinnison didn't even think about the paths, was just confused by destdir in the wrong side | 14:11 | |
Kinnison | mauricemoss_: 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 other | 14: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 |
Kinnison | Are 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 |
rdale | i would do: cd "$DESTDIR$PREFIX/bin" ; ln -s ../usr/bin/uci uci | 14:17 |
*** zoli__ has joined #baserock | 14:18 | |
Kinnison | mauricemoss_: PREFIX=/usr is just the default, if you need to build your stuff with a different PREFIX then set it for your chunk | 14:18 |
rdale | oops, i meant: cd "$DESTDIR$PREFIX/bin" ; ln -s ../bin/uci uci | 14: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 |
Kinnison | mauricemoss_: You might need PREFIX=/usr but BINDIR and SBINDIR set differently | 14:21 |
rdale | yes, i don't think a prefix of '/' will work | 14:21 |
Kinnison | mauricemoss_: the particular chunks will need you to tweak them if they have such hardcoded paths | 14:21 |
rdale | oops, attempt #3: cd "$DESTDIR$PREFIX/bin" ; ln -s ../../bin/uci uci | 14: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_maw | BINDIR and SBINDIR aren't set by morph | 14:24 |
richard_maw | they're defined by make usually | 14:24 |
richard_maw | hence are only visible in the makefiles | 14:24 |
richard_maw | but they derive part of their value from PREFIX | 14:24 |
richard_maw | which morph does define | 14:25 |
richard_maw | you can of course override BINDIR and SBINDIR in your chunk definition file to get autotoolsy programs to install it elsewhere | 14:25 |
richard_maw | but that's better off done in the configure-commands if it supports it | 14:25 |
mauricemoss_ | richard_maw, ok thanks! | 14:26 |
*** jonathanmaw has quit IRC | 14:36 | |
*** jonathanmaw has joined #baserock | 14:37 | |
*** zoli__ has quit IRC | 14:41 | |
*** jonathanmaw has quit IRC | 14:41 | |
*** jonathanmaw has joined #baserock | 14:42 | |
ratmice__ | mauricemoss_: these variables generally come from the gnu coding standards | 15:02 |
ratmice__ | https://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables | 15:02 |
*** zoli__ has joined #baserock | 15:11 | |
mauricemoss_ | ratmice__, good to know :) | 15:16 |
*** sambishop has quit IRC | 15:25 | |
*** ssam2 has quit IRC | 15:27 | |
paulsherwood | ooh, 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 #baserock | 15:40 | |
*** ssam2 has joined #baserock | 15:40 | |
*** ChanServ sets mode: +v ssam2 | 15: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 gnulib | 15:46 |
tiagogomes_ | the gnulib directory is empty thought | 15:46 |
SotK | what is the url for it in .gitmodules? | 15:46 |
tiagogomes_ | ah never mind, I was looking at the wrong directory | 15:47 |
* tiagogomes_ needs caffeine | 15:47 | |
rdale | i can't clone the gerrit definitions repo - have a got the right url: git://gerrit.baserock.org/baserock/baserock/definitions | 16:01 |
radiofree | when i try to register a new e-mail in gerrit i get a 500 | 16:03 |
jmacs | rdale: Try git clone http://gerrit.baserock.org/baserock/baserock/definitions | 16:03 |
jmacs | I don't know if that will get you push access though | 16:03 |
rdale | i can clone with that at least - thanks | 16:04 |
pedroalvarez | radiofree: registering a new e-mail requires gerrit to send email, and we don't have that bit atm | 16:06 |
franred | what am I missing to get a segmentation fault running make in kmod after it compiles fine from morph? http://paste.baserock.org/afazehujut | 16:07 |
pedroalvarez | franred: /dev /proc and maybe others | 16:08 |
pedroalvarez | maybe just /proc | 16:08 |
*** sherm_ has quit IRC | 16:11 | |
franred | pedroalvarez, do I need to mount them and run the configuration commands? or mounting them and running make should be enough? | 16:12 |
pedroalvarez | iirc it was: bind mount them before running chroot, and then make should work | 16:13 |
pedroalvarez | I don't see why you would need to run the configure commands again | 16:14 |
franred | pedroalvarez, thanks, I will try it | 16:14 |
rdale | i'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 future | 16:17 |
jjardon | radiofree: known bug: https://storyboard.baserock.org/#!/story/28 | 16:17 |
ssam2 | rdale: I don't see it... | 16:18 |
ssam2 | what is 'origin' ? | 16:18 |
rdale | bother, it should be gerrit. i just copied the push command from the wiki | 16:19 |
SotK | hm, is the wiki wrong? | 16:20 |
rdale | here's what i've been doing: http://paste.baserock.org/ewaqucokaf | 16:21 |
jjardon | rdale: can you try git push origin HEAD:refs/for/master/update-cmake ? | 16:21 |
jjardon | rdale: yo should use git push gerrit HEAD:refs/for/master/update-cmake instead | 16:22 |
rdale | still not working: http://paste.baserock.org/eqotarakus | 16:24 |
franred | pedroalvarez, still having the segmentation fault | 16:24 |
paulsherwood | rdale: gerrit, not origin | 16:24 |
jjardon | not sure why the --origin=gerrit was added in the wiki but Ive just fixed it | 16:24 |
paulsherwood | oops. i see you did that | 16:25 |
ssam2 | rdale: do you have a Change-Id in your commit message? | 16:25 |
jjardon | rdale: 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 |
rdale | i downloaded the hook - but i had commited the change before adding the hook - is that the problem? | 16:26 |
franred | jjardon, I think petefoth added because gerrit-review understand "gerrit" as remote name | 16:26 |
paulsherwood | rdale: i hit that too. yes, need to make the commit again | 16:26 |
jjardon | rdale: yes, run git commit --amend to add it | 16:26 |
* straycat hugs richard_maw | 16:29 | |
straycat | thanks! | 16:29 |
straycat | i hadn't even got 'round to biffing yet | 16:29 |
pedroalvarez | s/gerrit-review/git-review/ | 16:33 |
rdale | i have a change-id in my commit, but i still can't seem to push the change: http://paste.baserock.org/munoqeweda | 16:35 |
paulsherwood | missing tree?! | 16:36 |
pedroalvarez | franred: just found this, which is what rdale was using to avoid that problem: http://paste.baserock.org/atawenivoc | 16:37 |
franred | pedroalvarez, no luck with that either :/ | 16:42 |
ssam2 | rdale: wow, '! [remote rejected] HEAD -> refs/for/master/update-cmake (n/a (unpacker error))' is totally new | 16:44 |
rdale | oh :( | 16:44 |
Kinnison | apparently that can be related to filesystem permission errors | 16:45 |
Kinnison | http://stackoverflow.com/questions/4025708/git-cant-push-unpacker-error-related-to-permission-issues | 16:45 |
ssam2 | no permission errors I can see, but several other possible causes | 16:46 |
ssam2 | https://stackoverflow.com/questions/16586642/git-unpack-error-on-push-to-gerrit | 16:47 |
ssam2 | probably https://code.google.com/p/gerrit/issues/detail?id=1582 which seems to be fixed in 2.10 | 16:47 |
Kinnison | urgh | 16:47 |
ssam2 | we're still on 2.9 | 16:47 |
Kinnison | This is one reason gitano uses git's implementation of git | 16:47 |
ssam2 | rdale: try adding '--no-thin' to the 'git push' cmdline as a workaround | 16:47 |
rdale | ok | 16:48 |
rdale | that works - so it is the same problem as the stackoverflow page | 16:48 |
rdale | yes! my change is on the list of patches for review now | 16:49 |
*** a1exhughe5 has quit IRC | 16:56 | |
paulsherwood | richard_maw: are you -1 on my patch, based on your email just now? it already has +2 | 16:58 |
paulsherwood | (well +1 and +1) | 16:58 |
richard_maw | paulsherwood: I have no objections to your patch specifically, just to the idea that we should do it everywhere in general | 16:59 |
richard_maw | it may be useful to be explicit in build-essential | 16:59 |
richard_maw | but I wouldn't want it to be mandatory everywhere | 16:59 |
straycat | my +1 is for build-essential only fwiw | 16:59 |
paulsherwood | understood. if/when i get past build-essential, i should be able to establish how pervasive this is | 17:00 |
paulsherwood | at the moment, folks must admit that we don't know? | 17:00 |
jjardon | ssam2: see? we need 2.10 :) | 17:00 |
rdale | i am using git 1.9.1 on my laptop | 17:01 |
*** jonathanmaw has quit IRC | 17:01 | |
straycat | can only imagine it *might* grow unwieldy for very large strata, maybe? | 17:01 |
richard_maw | paulsherwood: I know that it's totally pervasive, because at one point we were encouraged to remove redundant dependency information to make strata smaller | 17:01 |
edcragg | hi, 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 |
paulsherwood | i 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 me | 17:05 |
paulsherwood | richard_maw: ^^ | 17:05 |
Kinnison | jjardon: You committed the change that edcragg is referring to -- reverting it results in native bootstrap completing again | 17:05 |
Kinnison | jjardon: was it purely a "cleanup" or was the change to remove bash something explicitly needed? | 17:06 |
jjardon | edcragg: Kinnison: only cleanup, ok by me reverting it (with the reason so we do not change it again) | 17:07 |
Kinnison | edcragg: Fancy producing a reversion with explanation and submitting it to gerrit? | 17:07 |
Kinnison | jjardon: thanks :) | 17:07 |
edcragg | jjardon: thanks | 17:07 |
edcragg | Kinnison: sure | 17:07 |
paulsherwood | richard_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 with | 17:07 |
* richard_maw remembers quizzing jjardon about it at the time, and being told that he'd checked | 17:08 | |
Kinnison | richard_maw: it's possible the issue only manifests during native_bootstrap | 17:08 |
Kinnison | richard_maw: given the "interesting" environment there | 17:08 |
richard_maw | paulsherwood: 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 it | 17:11 | |
paulsherwood | in 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 |
Kinnison | the compiler stages are *really* delicate | 17:13 |
paulsherwood | (i even went to the extent of making ybd use morph's artifacts...) | 17:13 |
Kinnison | Are you confident that the environment matches exactly? | 17:13 |
paulsherwood | i'm 98% confident, yes | 17:14 |
Kinnison | We've been having bootstrap issues purely related to whether /usr/bin comes before /bin in PATH | 17:14 |
Kinnison | so check things like that | 17:15 |
radiofree | paulsherwood: what's different about them? | 17:16 |
jmacs | Do we have any support for building an upstream ref + a patch file (maybe included in definitions?) | 17:16 |
radiofree | jmacs: as far as i'm aware, no | 17:16 |
radiofree | but i think that would be nice | 17:16 |
Kinnison | jmacs: You get to apply the patch to a git branch IIRC | 17:16 |
radiofree | i think that's what yocto does? | 17:17 |
jmacs | radiofree: It is. | 17:17 |
jmacs | I mean, they carry patches around in their equivalent of definitions. | 17:17 |
pedroalvarez | we prefer go upstream and fix things there :P | 17:17 |
radiofree | pedroalvarez: well that's not always going to work out | 17:17 |
radiofree | e.g http://git.baserock.org/cgi-bin/cgit.cgi/delta/gstreamer.git/commit/?h=baserock/morph/0.10&id=c7e4a97d26396882960fd399b1a5e298e40d2a35 | 17:17 |
radiofree | i'd prefer that submodule updating to be done my morph, rather than having to add it to a git repo | 17:18 |
pedroalvarez | radiofree: indeed, we are planing other solutions for that | 17:19 |
paulsherwood | radiofree: looks like i blew away my results, will need to reproduce overnight | 17:22 |
* radiofree momentarily confused pedroalvarez for paulsherwood | 17:30 | |
paulsherwood | interesting :) | 17:30 |
pedroalvarez | known issue | 17:30 |
richard_maw | Bug closed: WONTFIX | 17:41 |
radiofree | NOTABUG? | 17:42 |
jjardon | my understanding is that dependencies within a stratum are always explicit: it can be implicit between strata | 17:44 |
jjardon | richard_maw: not sure if this is related with what you were talking about? | 17:45 |
*** Krin has quit IRC | 17:46 | |
richard_maw | jjardon: 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 |
jjardon | Id like to do everything explicit | 17:50 |
jjardon | there are not so many strata anyway | 17:51 |
richard_maw | 91 total strata, 340 chunks with definition files | 17:52 |
jjardon | mmm, thinking twice Im not sure; it would be a bit weird have a openstack stratum depending on build-depends and all the stratum on top | 17:52 |
*** bashrc_ has quit IRC | 17:53 | |
richard_maw | it would certainly be rather verbose | 17:53 |
jjardon | richard_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 point | 17:54 |
jjardon | one 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 strata | 17:56 |
richard_maw | that's an excellent new point | 17:57 |
richard_maw | the 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 entirely | 17:58 |
jjardon | one solution would be to make the chunk depend on strata? | 17:58 |
jjardon | :) | 17:58 |
richard_maw | yeah, 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 file | 17:58 |
jjardon | yeah, we think the same | 17:59 |
ssam2 | i think that's a good idea (chunks depending directly on strata) | 17:59 |
rdale | that sounds worse than what we have to me | 18:00 |
richard_maw | if we do that, and allow chunks to depend on chunks from other strata then strata become just a way to group chunk definitions | 18:00 |
ssam2 | which I believe is on the wishlist anyway | 18:00 |
rdale | mainly 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 |
jjardon | richard_maw: I was thinking allow chunks to depend on other strata, not other chunks from other strata | 18:01 |
richard_maw | I know, I was just thinking about other changes we could also do which would make sense in some contexts | 18:02 |
*** mdunford has quit IRC | 18:05 | |
ssam2 | rdale: if we decide to add an extra layer of tooling, this discussion becomes more or less irrelevant. | 18:06 |
ssam2 | but I don't think we'll be able to do that any time soon | 18:06 |
*** CTtpollard has quit IRC | 18:07 | |
rdale | yes, so to me it seems premature to start messing with the build-essential stratum | 18:07 |
*** ssam2 has quit IRC | 18:09 | |
*** zoli__ has quit IRC | 18:11 | |
*** zoli__ has joined #baserock | 18:15 | |
*** tiagogomes_ has quit IRC | 18:17 | |
*** rdale has quit IRC | 18:25 | |
*** zoli__ has quit IRC | 18:33 | |
paulsherwood | hmmm... | 18:58 |
paulsherwood | so, before i spend many more hours on this... | 18:59 |
paulsherwood | if we look at http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/erlang.morph | 19:01 |
paulsherwood | (for example) | 19:01 |
paulsherwood | you 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 IRC | 19:09 | |
*** lachlanmackenzie has quit IRC | 19:20 | |
*** zoli__ has joined #baserock | 19:21 | |
*** gfinney has quit IRC | 19:30 | |
*** gfinney has joined #baserock | 19:32 | |
*** CTtpollard has joined #baserock | 19:40 | |
*** gary_perkins has quit IRC | 19:51 | |
*** zoli__ has quit IRC | 20:10 | |
*** zoli__ has joined #baserock | 20:10 | |
*** edcragg has quit IRC | 20: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+1 | 20:44 | |
paulsherwood | (and they will be present at runtime anyway....) | 20:45 |
*** pacon2 has joined #baserock | 21:08 | |
SotK | with the same happening based on stratum order in a system? | 21:16 |
*** persia has quit IRC | 21:50 | |
*** persia has joined #baserock | 21:51 | |
*** persia has joined #baserock | 21:51 | |
*** gfinney has quit IRC | 22:26 | |
*** gfinney_ has joined #baserock | 22:26 | |
*** pacon2 has quit IRC | 23:39 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!