| SotK | pedroalvarez: thanks for fixing the lorries :) | 07:01 |
|---|---|---|
| * SotK wishes for YAML lorries | 07:01 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:15 | |
| paulsherwood | +1 | 07:28 |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:33 | |
| pedroalvarez | SotK: np :) | 07:53 |
| paulsherwood | jjardon: building now....what should i test? | 07:56 |
| *** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:12 | |
| dutch | pedroalvarez: is there a stratum containing mariadb? | 08:41 |
| *** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:43 | |
| paulsherwood | dutch: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/pedroalvarez/mariadb | 08:46 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:47 | |
| dutch | thanks paulsherwood | 08:54 |
| paulsherwood | np | 08:55 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:03 | |
| juergbi | hi ssam2, a comment about your linux api headers mail from last week. updating linux headers does not normally break userspace from running with older kernels | 09:07 |
| pedroalvarez | question: I'm about to send a patch of a fix suggested from someone else. Who has to be the Author of the commit? | 09:08 |
| juergbi | ssam2: glibc's --enable-kernel= is what decides that | 09:08 |
| Kinnison | pedroalvarez: typically if the fix was *authored* by the other person, then they are the author and you are the committer. If OTOH they just suggested it and you had to make the fix yourself, you're both and you credit the other person in the commit message | 09:08 |
| Kinnison | pedroalvarez: but ultimately making that distinction is up to you | 09:09 |
| ssam2 | juergbi: oh, thanks for pointing that out | 09:09 |
| ssam2 | I'll reply to that effect on the mailing list for posterity | 09:09 |
| pedroalvarez | Kinnison: makes sense, thanks | 09:10 |
| violeta | aren't the configure-commands supposed to run before the build-commands? | 09:17 |
| Kinnison | violeta: yep | 09:18 |
| pedroalvarez | violeta: any reason you think that is not happening? | 09:19 |
| pedroalvarez | s/you/to/ | 09:19 |
| violeta | I get the message: "Running build-commands", but not the equivalent for configure-commands, and the build is failing... | 09:19 |
| Kinnison | sounds like it's not running your morphology | 09:20 |
| Kinnison | or perhaps you have a typo | 09:20 |
| pedroalvarez | violeta: could we see the stratum and the chunk morpholigies? | 09:21 |
| *** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 09:41 | |
| ssam2 | pedroalvarez: I guess you've noticed the problems in the public Mason at http://85.199.252.101/ already | 09:53 |
| ssam2 | have I missed a discussion of it or does it still need investigating ? | 09:53 |
| ssam2 | seems that the issue is that it's trying to Git clone ssh:// URLs from git.baserock.org but doesn't have access to do that | 09:54 |
| ssam2 | and for the delta/ repos this isn't a problem because it then fetches a tarball | 09:54 |
| ssam2 | but for the baserock/ repos there are no tarballs so it gets an error | 09:54 |
| violeta | my stratum and chunk: https://admin.codethink.co.uk/pnopaste/?1895 | 09:54 |
| ssam2 | so the question is, how come it succeeded? But having discussed this to myself I now realise that's probably because it got fixed already. | 09:54 |
| violeta | the error I get: https://admin.codethink.co.uk/pnopaste/?1894 | 09:54 |
| pedroalvarez | ssam2: but Mason ended up building it | 09:54 |
| pedroalvarez | violeta: can you use a public paste service? | 09:55 |
| violeta | oops | 09:55 |
| violeta | pedroalvarez, http://pastebin.com/68kvydBs | 09:56 |
| ssam2 | pedroalvarez: that's the part I don't understand. How come Mason eventually managed to build the thing ? It still doesn't have a user on git.baserock.org .. | 09:57 |
| ssam2 | the 'baserock:' repo-alias expands to ssh://git@git.baserock.org for reads as well as writes, so that's the problem, I guess | 09:58 |
| Kinnison | baserock: should expand to git://git.baserock.org/ for reads | 10:01 |
| Kinnison | Does it not? | 10:01 |
| ssam2 | it does in my Baserock chroot | 10:01 |
| ssam2 | but it doesn't on that Mason | 10:01 |
| Kinnison | odd | 10:01 |
| ssam2 | which has trove-host = git.baserock.org and trove-id = baserock | 10:02 |
| Kinnison | It should only change to ssh:// if the trove-id and/or trove-hostname is changed from default I think | 10:02 |
| pedroalvarez | violeta: is there a u-boot.morph in your u-boot checkout? | 10:02 |
| Kinnison | aah | 10:02 |
| ssam2 | but in my chroot I have trove-id = ct-mcr-1 and trove-host = ct-mcr-1 and it works fine | 10:02 |
| violeta | pedroalvarez, checkout? | 10:02 |
| ssam2 | by "works fine" I mean "doesn't use an ssh URL for reads" | 10:02 |
| Kinnison | I imagine you have keys for your ct-mcr-1 trove, wherever that is | 10:02 |
| ssam2 | no, the repo-alias pattern expands to a git:// URL | 10:03 |
| ssam2 | well, one git:// and one ssh:// for push access | 10:03 |
| Kinnison | baserock: will expand to ssh://git@TROVE-HOST/ | 10:03 |
| Kinnison | erm /baserock/ | 10:03 |
| Kinnison | I wonder if you're looking at pre- or at post- config processing | 10:03 |
| pedroalvarez | well, looking at the morphologies looks like you have used `morph edit` to clone u-boot in your workspace | 10:03 |
| ssam2 | Kinnison: in my chroot? no, it doesn't | 10:03 |
| violeta | pedroalvarez, yes | 10:04 |
| pedroalvarez | looks like morph is not using "strata/bsp-jetson-devel/u-boot.morph" at all, because the first build command that it tries to do is "make tools" and I can't see that in your u-boot morphology | 10:04 |
| pedroalvarez | so I assume that instead of usinng strata/bsp-jetson-devel/u-boot.morph, is using something else | 10:05 |
| pedroalvarez | if you look in wherever you have the u-boot sources, can you see an u-boot.morph file? | 10:05 |
| pedroalvarez | If so, can you share it with me? | 10:06 |
| * Kinnison notes that u-boot is also present in the tools stratum | 10:07 | |
| Kinnison | could confusion be happening because of that | 10:07 |
| violeta | pedroalvarez, no .morph in my u-boot source, should there be? | 10:08 |
| Kinnison | violeta: ^^^ | 10:08 |
| Kinnison | this could be a chunk-name conflict | 10:08 |
| violeta | hmmm | 10:08 |
| * paulsherwood would like to suggest that morph disallow duplicate names in the whole chunks/strata/systems space | 10:09 | |
| paulsherwood | but anyway | 10:09 |
| pedroalvarez | violeta: no no, just checking what was happening | 10:10 |
| pedroalvarez | hm.. | 10:10 |
| pedroalvarez | are you sure that the u-boot morphology that you sent us is the one located in strata/bsp-jetson-devel/u-boot.morph? | 10:10 |
| * pedroalvarez is really confused | 10:11 | |
| Kinnison | paulsherwood: I want all artifact names to be enforced-unique too | 10:11 |
| Kinnison | paulsherwood: at least within systems | 10:11 |
| violeta | pedroalvarez, yes, I'm sure, but Kinnison is right, the error is with strata/tools/u-boot.morph | 10:12 |
| paulsherwood | if within the whole of definitions, we can remove the need to specify relative paths | 10:12 |
| Kinnison | violeta: did 'morph edit' edit that too? | 10:12 |
| Kinnison | violeta: if so, just "unedit" strata/tools.morph | 10:12 |
| Kinnison | and things should settle | 10:12 |
| violeta | ahhhh, makes sense! and I do remember a warning that I didn't know what it meant at the moment ;-) | 10:13 |
| * Kinnison mumbles about warning about needing to sort this out back when Paul did the "morph edit foo" patch | 10:14 | |
| pedroalvarez | ah, yes, u-boot in tools. I somehow thought looking at the log that the error was happening when building the u-boot in the bsp | 10:14 |
| violeta | pedroalvarez, that's what I thought too | 10:15 |
| ssam2 | can I commit this fix for Mason configuration? http://pastebin.com/g6XVdqjN | 10:22 |
| paulsherwood | ssam2: +1 | 10:22 |
| paulsherwood | clearly | 10:22 |
| ssam2 | this doesn't fix the issue on our public Mason, it fixes a problem with deploying non-generic Masons | 10:22 |
| Kinnison | ssam2: +1 | 10:23 |
| ssam2 | thanks | 10:23 |
| ssam2 | my existing baserock/sam/mason-deploy-fix branch from Friday needs another +1 too | 10:27 |
| ssam2 | http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-September/008358.html | 10:27 |
| paulsherwood | +1 | 10:28 |
| paulsherwood | (assuming you've tested it) | 10:28 |
| paulsherwood | ssam2: ^^ | 10:29 |
| pedroalvarez | sorry about the errors :( | 10:29 |
| paulsherwood | we all make errors ;) | 10:30 |
| paulsherwood | pedroalvarez: branch for your morph --version fix? | 10:34 |
| pedroalvarez | baserock/pedroalvarez/morph-version-fix | 10:34 |
| paulsherwood | found it | 10:34 |
| pedroalvarez | this time the test pass :) | 10:34 |
| paulsherwood | pedroalvarez: +1 | 10:35 |
| paulsherwood | (tested) | 10:35 |
| pedroalvarez | :) | 10:35 |
| paulsherwood | ssam2: please grant a +1 to pedroalvarez ? :) | 10:37 |
| SotK | pedroalvarez: +1 | 10:39 |
| pedroalvarez | great! | 10:40 |
| SotK | (I tried to reply on the list but my mail client is misbehaving) | 10:40 |
| pedroalvarez | thanks guys! | 10:40 |
| paulsherwood | violeta: are you still stuck? | 10:41 |
| violeta | paulsherwood, not for now, I had other failed build because the new kernel had a different name for the config, so I'm building it again now | 10:42 |
| violeta | cross your fingers | 10:42 |
| paulsherwood | violeta: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/ps/jetson-latest-linux | 10:43 |
| paulsherwood | that builds | 10:43 |
| paulsherwood | and deploys | 10:43 |
| paulsherwood | violeta: please check if you've fixed all the configs | 10:44 |
| paulsherwood | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/ps/jetson-latest-linux&id=26dd46d555972feab52384ccff05b9ef1ab11018 | 10:44 |
| violeta | paulsherwood, I haven't changed the dtb name :-S | 10:46 |
| paulsherwood | right | 10:47 |
| paulsherwood | say 'gracias, paul' :-) | 10:47 |
| pedroalvarez | hahahah | 10:48 |
| violeta | :-P | 10:48 |
| violeta | thanks paulsherwood | 10:48 |
| paulsherwood | yw. by return, you have to fix the btrfs problem i hit :) | 10:48 |
| violeta | mercy beaucoup | 10:48 |
| violeta | oh | 10:48 |
| violeta | paulsherwood, what problem? | 10:49 |
| paulsherwood | violeta: somehow it fails to pick up my /src mount... i had a similar problem on OpenStack, maybne i should try pedroalvarez' fix for that | 11:13 |
| pedroalvarez | wasn't a fix | 11:13 |
| pedroalvarez | paulsherwood: Is this happening after an upgrade? | 11:14 |
| paulsherwood | yup | 11:14 |
| pedroalvarez | in a jetson? | 11:14 |
| paulsherwood | yup | 11:14 |
| pedroalvarez | paulsherwood: can I see /etc/fstab after the upgrade? | 11:14 |
| paulsherwood | it worked for me on cloud. on what basis can you say that it wasn't a fix? | 11:14 |
| radiofree | paulsherwood: maybe sata isn't enabled/ | 11:15 |
| paulsherwood | ah, true | 11:15 |
| paulsherwood | so will setting ROOT_DEVICE: /dev/vda cause any harm? | 11:15 |
| radiofree | are you talking about a jetson? | 11:15 |
| paulsherwood | yup | 11:16 |
| pedroalvarez | paulsherwood: in jetson won't work at all | 11:16 |
| radiofree | there won't be a /dev/vda | 11:16 |
| paulsherwood | ok | 11:16 |
| radiofree | /dev/sda1 | 11:16 |
| radiofree | mount /dev/sda1 /src, see if that works | 11:16 |
| pedroalvarez | radiofree: but that "fix" will screw up the entire fstab file | 11:16 |
| radiofree | pedroalvarez: eh? | 11:16 |
| radiofree | i added ROOT_DEVICE: specifically to allow the fstab to be set to /dev/sda1 | 11:17 |
| radiofree | no wait | 11:17 |
| radiofree | i didn't | 11:17 |
| radiofree | ROOT_DEVICE is for the bootloader | 11:17 |
| radiofree | paulsherwood: you want /dev/mmcblk0p1 as your ROOT_DEVICE for jetson | 11:17 |
| * paulsherwood avoids touching ROOT_DEVICE, and redoes the deploy | 11:17 | |
| radiofree | what does your fstab look like on the system without /src? | 11:17 |
| pedroalvarez | This is the reason I say that it wasn't a fix. The upgrade should handle this by default, without ROOT_DEVICE | 11:18 |
| radiofree | if you don't have a /dev/sda1 then the kernel doesn't have sata | 11:18 |
| paulsherwood | http://fpaste.org/137721/ | 11:18 |
| radiofree | pedroalvarez: tbdiff doesn't use ROOT_DEVICE? | 11:19 |
| pedroalvarez | that looks sane, but this is before the upgrade I believe | 11:19 |
| paulsherwood | true, upgrading now | 11:19 |
| radiofree | so you're upgrading from 3.10 to ? | 11:19 |
| paulsherwood | 3.17-rc6 or 7 | 11:20 |
| pedroalvarez | radiofree: as you can see in this paste http://fpaste.org/137721/ we use UUID in fstab to make it more generic. The upgrade should keep this format instead of hardcoding /dev/sda, vda, mmc* IMO | 11:22 |
| paulsherwood | http://fpaste.org/137723/ is where things hang around.... | 11:25 |
| paulsherwood | after upgrade fstab is http://fpaste.org/137724/ | 11:26 |
| pedroalvarez | fstab is ok | 11:26 |
| radiofree | yeah, do you have a /dev/sda1? | 11:27 |
| pedroalvarez | `ls -l /dev/sda1` | 11:27 |
| paulsherwood | nope | 11:27 |
| radiofree | no sata | 11:27 |
| paulsherwood | ok | 11:27 |
| pedroalvarez | radiofree: do you know how to enable it> | 11:27 |
| pedroalvarez | ? | 11:27 |
| radiofree | I assumed it would have been enabled by default | 11:28 |
| radiofree | ask in #tegra | 11:28 |
| radiofree | maybe it didn't land for 3.17 | 11:28 |
| paulsherwood | this is 3.16 | 11:28 |
| paulsherwood | sorry 3.17-rc6 | 11:28 |
| paulsherwood | i'll try rc7 | 11:28 |
| radiofree | that might not help | 11:29 |
| paulsherwood | i think it won't, tbh | 11:29 |
| radiofree | "ARM: tegra: device tree changes for 3.18" | 11:30 |
| radiofree | * SATA and PCIe support added to Tegra124, and enabled on Jetson TK1. | 11:30 |
| paulsherwood | ok, where would i find those? | 11:31 |
| radiofree | you might be able to add it to the device tree | 11:32 |
| radiofree | https://git.kernel.org/cgit/linux/kernel/git/tegra/linux.git/commit/?h=for-next&id=fdd690969b8b05b0636ac46a66a885c5b1ccd651 | 11:32 |
| radiofree | there's https://git.kernel.org/cgit/linux/kernel/git/tegra/linux.git/log/?h=for-next | 11:32 |
| Kinnison | You won't get SATA working fully until you also merge the pci/next stuff | 11:55 |
| Kinnison | At least I didn't | 11:55 |
| Kinnison | *and* upgrade your u-boot | 11:55 |
| paulsherwood | ah, is u-boot upgrade required too? that's beyond my reach at this point | 11:56 |
| paulsherwood | Kinnison: Manfred assures me that none of his colleagues in the office moved common-api tags, but some are on holiday | 12:08 |
| Kinnison | heh | 12:08 |
| paulsherwood | is there any possibility of an issue our end? | 12:08 |
| Kinnison | Not that could cause this kind of behaviour | 12:08 |
| Kinnison | Remember the tag moves could be as old as June | 12:08 |
| Kinnison | If someone in the team then force-pushed something else, they could force-push a tag move if they weren't careful | 12:09 |
| paulsherwood | yup, i assume they are | 12:09 |
| paulsherwood | 'Unfortunately I don’t know any way to look up tag changes in git itself... | 12:09 |
| paulsherwood | ' | 12:09 |
| paulsherwood | from manfred | 12:09 |
| Kinnison | :-( | 12:09 |
| * Kinnison pokes a stick at the web HMI for smartdevicelink in the meantime | 12:09 | |
| paulsherwood | :) | 12:09 |
| paulsherwood | i guess i just drop this specific incident, but it does seem we need to trap this kind of thing properly if we're to have a hope of true reproducibility/traceability | 12:11 |
| Kinnison | trap/prevent aye | 12:13 |
| paulsherwood | we can't prevent it. upstream can do what they like? | 12:15 |
| Kinnison | We can prevent the damage hitting our trove | 12:16 |
| Kinnison | We discussed automatically creating shadow tags when new tags showed up, so that when upstream blorfs a tag, our shadow-tag would still anchor the commit | 12:16 |
| Kinnison | Okay, so the stick I poked this HMI with went in, but has yet to come back | 12:17 |
| Kinnison | :-( | 12:17 |
| paulsherwood | yes to the shadow tags idea | 12:17 |
| Kinnison | Mmm, now the idea is easy, the details are way harder to work out | 12:18 |
| paulsherwood | really? seems pretty simple | 12:18 |
| paulsherwood | but.... unpetrify | 12:19 |
| Kinnison | unpetrify needs to go away | 12:19 |
| paulsherwood | yup | 12:19 |
| Kinnison | so don't think about it | 12:19 |
| paulsherwood | :) | 12:19 |
| Kinnison | We'll need a nominated anchor ref | 12:19 |
| Kinnison | but don't think "unpetrify" | 12:19 |
| Kinnison | 'ref' should go away and be 'sha1' | 12:19 |
| Kinnison | and should always be a sha1 | 12:19 |
| * Kinnison <- opinionated | 12:20 | |
| paulsherwood | i'm fine with that | 12:21 |
| Kinnison | Okay, so stracing this server shows the http request coming in | 12:21 |
| Kinnison | and nothing going back out | 12:21 |
| Kinnison | :-( | 12:21 |
| SotK | :( | 12:21 |
| paulsherwood | any config required on the server? | 12:22 |
| * paulsherwood cant remember how this worked originally | 12:22 | |
| Kinnison | I'm currently looking at what has been installed to see if I'm missing content | 12:22 |
| paulsherwood | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/ps/smartdevicelink&id=e0a0d03d27525537dac550b216caa728b5fd798c | 12:23 |
| Kinnison | I used that back when I started this branch, yes | 12:23 |
| paulsherwood | iirc the server had to be run in the right directory | 12:23 |
| Kinnison | Oh cripes | 12:23 |
| paulsherwood | i may be wrong, though | 12:24 |
| paulsherwood | i think we were using just busybox http last time? | 12:25 |
| Kinnison | There's no useful content installed | 12:26 |
| * Kinnison needs to see what's missing from their build system | 12:26 | |
| jjardon | I think baserock would be quite less uselful if you force ref to be a sha instead a branch/tag | 13:01 |
| violeta | what's the problem with ref being a branch? | 13:02 |
| Kinnison | Lack of lock-down means a given build is harder to reproduce | 13:02 |
| paulsherwood | jjardon, violeta - we need some way of tracking back to see what was actually built. tags and branches can move | 13:02 |
| Kinnison | And I'm sorry to say that recent events have made me even more militant about this | 13:03 |
| paulsherwood | i think we need to support both worlds | 13:03 |
| paulsherwood | somehow | 13:03 |
| jjardon | paulsherwood: is that the only problem, you can store that info in the resulting build somewhere | 13:03 |
| Kinnison | I think tracking a ref is either something 'morph build' should be doing, or firehose | 13:03 |
| paulsherwood | speed by allowing developers to use tags. reproducibility by locking SHA1s | 13:03 |
| paulsherwood | jjardon: not if the tag/branch is later moved... | 13:04 |
| paulsherwood | may leave dangling commits, which get lost | 13:04 |
| jjardon | paulsherwood: morph could store the actual sha that gets builded, not the tag/branch | 13:04 |
| Kinnison | We do | 13:05 |
| paulsherwood | s/builded/built/ | 13:05 |
| Kinnison | but it's not in the commit | 13:05 |
| Kinnison | Which means the commit can't be usefully reused later | 13:05 |
| Kinnison | Also, the SHA doesn' thelp if upstream changes the tag/branch in a force-push way, and thus the relevant objects are lost through gc | 13:05 |
| paulsherwood | . | 13:06 |
| SotK | Kinnison: does the idea of a manifest mapping refs to SHAs in definitions that you talked about some time ago solve this? | 13:06 |
| * paulsherwood needs to think about this, now he has a reasonable understanding of both sides of the problem | 13:06 | |
| Kinnison | SotK: It's an approach | 13:07 |
| Kinnison | But there's other aspects which need checking | 13:07 |
| jjardon | Kinnison: then what is the advantage to ref pointing to SHAs? Same can happen if upstream force-push | 13:08 |
| Kinnison | jjardon: that's what the point of the anchor ref is | 13:08 |
| Kinnison | jjardon: something we currently unfortunately call unpetrify-re | 13:08 |
| Kinnison | -ref | 13:08 |
| Kinnison | We *should not* rely on refs out of our control for anchoring things | 13:08 |
| Kinnison | we currently do, an awful lot, and that's bad | 13:09 |
| jjardon | Kinnison: is that documented somewhere? | 13:10 |
| * jjardon always found the unpetrify-ref concept/field a bit confusing to understand | 13:11 | |
| tlsa | me too | 13:11 |
| Kinnison | jjardon: this is all a bit under-documented and under-understood because we keep having thoughts about how we'd prefer it to be | 13:12 |
| * jjardon would expect a explanation of the current "correct" thing to do when he submitted patches changing that field | 13:13 | |
| Kinnison | There's little consensus on the 'correct' thing right now | 13:13 |
| Kinnison | Particularly since we're not making releases | 13:14 |
| petefoth | To work out what the 'correct' thing is, we need to know what is the use case: what problem - from the Baserock user's perspective - are we trying to solve? | 13:15 |
| jjardon | cant we simply not allow force-push by default in the troves? | 13:17 |
| * jjardon still doesnt understand how using a sha as a ref can help if upstream force-push and that commit doesnt exist anymore | 13:18 | |
| Kinnison | Results in a lot of human time resolving safe forces vs. unsafe forces | 13:19 |
| Kinnison | jjardon: sha as ref is about reproducing from a commit | 13:19 |
| Kinnison | jjardon: anchoring is about preventing issues when upstream forces | 13:19 |
| Kinnison | jjardon: We do record specific SHAs in builds and thus yes you can reproduce from a built image, but that doesn't help when what you want to do is reproduce from a specific commit because you no longer have the binary builds | 13:20 |
| Kinnison | petefoth: We probably need to write down all the things we're thinking about on this topic and then try and rationalise them | 13:20 |
| Kinnison | petefoth: If we think of it as a reproduction attack then mitigation factors are the approach. If we thing of it from a usability PoV then we have a lot of conflicting arguments to resolve | 13:20 |
| violeta | pedroalvarez, the instructions you gave me for building an out of tree kernel module make my build fail, I think something is missing, http://pastebin.com/04tBqRp5 | 13:21 |
| petefoth | Kinnison: I'm trying ! Ideally we woudl have a 'Reproducability' top-level story / feature in StoryBoard, which we use to work out what users want / need in this area, and how we can satisfy that | 13:22 |
| petefoth | In the absence of StroyBoard, I may create a wikipage as a duimping ground for iseas and questions | 13:22 |
| jjardon | petefoth: if you want to tart a conversation to get feedback probably email works better, then you can put the conclusions in the wiki | 13:24 |
| pedroalvarez | violeta: heheh I enjoyed your report :) | 13:25 |
| violeta | :-D | 13:26 |
| petefoth | jjardon: agreed. But there's ben lots of discussion of this already, and I want to capture what I can in a wiki page so we don't lost too much. We can tidy it up later :) | 13:26 |
| pedroalvarez | violeta: what I suggested you to add: http://pastebin.com/0ZzVPkyL | 13:26 |
| tlsa | why not mark builds with branches as the ref as "unreproducable", and if all the refs are sha1s, mark it as "reproducable". And only release/ship ones that are marked "reproducable" | 13:26 |
| violeta | pedroalvarez, that's the [...] in my report :-P, so I currently do that | 13:26 |
| Kinnison | tlsa: that's one possible argument, although the only valid mark is "maybe reproducible" vs. "not reproducible" | 13:26 |
| tlsa | sure | 13:27 |
| pedroalvarez | violeta: so remove 'make INSTALL_MOD_PATH="$DESTDIR" modules_install' if it wasn't there before | 13:27 |
| violeta | pedroalvarez, the problem is that I think I have to do something *before*, like making the modules or something | 13:27 |
| Kinnison | 'make modules' | 13:27 |
| Kinnison | in the build commands | 13:27 |
| pedroalvarez | Kinnison: but is that needed? | 13:27 |
| Kinnison | If you want to do modules_install, yes | 13:27 |
| violeta | pedroalvarez, it wasn't there before, you told me to add those two lines too | 13:27 |
| pedroalvarez | Kinnison: is that going to be needed to install later an out-of-tree kernel module? | 13:28 |
| tlsa | could have `morph lock`, `morph unlock` to convert from ref as branch to ref as current sha1 and viseversa | 13:28 |
| Kinnison | pedroalvarez: that, I couldn't tell you off the top of my head | 13:28 |
| jjardon | what about branch definitions when we need a reproducible build and convert all the ref: to sha. master in general is not reproducible but tracking upstream branches | 13:29 |
| Kinnison | tlsa: welcome to petrify/unpetrify and all the pains that produces | 13:29 |
| Kinnison | jjardon: IMO master should *always* be reproducible | 13:29 |
| Kinnison | jjardon: meaning we need both SHA1s in all the commits *and* something tracking and anchoring them | 13:29 |
| Kinnison | But I am an extremist | 13:29 |
| pedroalvarez | violeta: sorry, but I didn't wanted to say that. So please, remove it | 13:30 |
| violeta | pedroalvarez, :-) ta | 13:30 |
| pedroalvarez | unless someone else says that it's needed | 13:30 |
| jjardon | Kinnison: I think be opinionated is good, someone have to take the technical decissions, but can you explain why is so importatn that master is always reproducible? And also seems its not at the moment as not all the modules have an unpetrify-ref | 13:31 |
| Kinnison | jjardon: currently we're not making releases -- that means master must be reproducible or people will be unable to identify when issues arise / are fixed | 13:32 |
| Kinnison | If we were making regular releases, I'd only demand releases be reproducible | 13:32 |
| Kinnison | *but* I do not want to be the person making the final technical decisions on this | 13:32 |
| Kinnison | I'm just opinionated and loud :-) | 13:32 |
| jjardon | that would work for me | 13:33 |
| Kinnison | And right now, my opinion is that cmake and all its ilk should be purged from history | 13:33 |
| rjek | eugh, cmake | 13:33 |
| jjardon | master is in general not reproducible and always tracking the latest as far as possible (possibly branches). Releases only refer to sha and should be 100% reproducible | 13:34 |
| jjardon | (and you can still probably reproduce a master build if you have the resulting metadata available) | 13:34 |
| petefoth | Reproducibiliy may not be a requirment for all BAserock users | 13:35 |
| Kinnison | jjardon: I'd prefer that the majority of master be locked down already | 13:35 |
| Kinnison | Otherwise it increases time-to-build on average | 13:36 |
| jjardon | Id say thats a bug: you can not stop updating the system components because the time to build is too long | 13:37 |
| Kinnison | I wouldn't want the majority of core system components to be updated willy-nilly because of upstream pushes | 13:39 |
| Kinnison | I want firehose to be carefully pulling in changes, and *testing* them before giving them to master | 13:39 |
| Kinnison | otherwise we can't run a master which could be released with relative ease | 13:39 |
| * Kinnison strongly dislikes projects whose master branch may or may not be buildable | 13:39 | |
| tlsa | yeah, you want to be using third party's latest tag, not there latest master, and I think it was firehose's job to deal with that | 13:39 |
| Kinnison | indeed | 13:40 |
| * Kinnison continues to poke at cmake with a desultory stick | 13:40 | |
| jjardon | I didnt mean to track master of everything (even it would makes sense for some modules), but stable branches if thay are available. In my opinion upstream developers are the one that knows more about their own code; they have more arguments to decide what should be used that someone that its integrating components (baserock) | 13:43 |
| tlsa | normally they would tag to say "this is ready to be used/supported" | 13:44 |
| Kinnison | After 14 years as a Debian developer I can say I have developed a deep distrust of upstreams :-) | 13:44 |
| ssam2 | that attitude seems a bit at odds with the philosophy of being 'as close to upstream as possible', which I have understood to be one of the goals of Baserock | 13:47 |
| ssam2 | that's not to say that you're wrong, of course | 13:47 |
| Kinnison | One can be close to something one distrusts | 13:47 |
| ssam2 | fair point | 13:47 |
| Kinnison | Otherwise driving on the road system would be impossible | 13:47 |
| tlsa | I guess it depends on the project. Ones like libpng make very frequent releases with fixes and stuff, so it's frequently taged | 13:49 |
| tlsa | ones like NetSurf are about half a year between tags :) | 13:49 |
| tlsa | we don't really bother with bugfix releases, and try to ensure master isn't broken, or if it is, then not for too long | 13:50 |
| jjardon | well, the baserock team can then decide what upstreams trust or not, but I think the general rule should be to use what upstreams consider should be used | 13:50 |
| paulsherwood | jjardon: that's true for the most part. but if they change something, we need to trap it. | 13:51 |
| rjek | Upstreams can be unhinged lunatics. | 13:51 |
| tlsa | also, for stuff like autotools, if you track master, the builds of loads of stuff will keep breaking, cos you can be sure not all projects that use it ensure they build with latest master | 13:52 |
| rjek | But CI can detect some of that. | 13:52 |
| jjardon | paulsherwood: you mean if they change a tag/branch/commit? sure, as discussed before releases will be always reproducible (and master could be reproducible too, if master didntforce-push anything since the latest master build) | 13:55 |
| jjardon | rjek: the same can be said about downstream, but we are not talking about that here | 13:56 |
| * pedroalvarez has integrated ca-certificates in a baserocky way but patching upstream | 14:16 | |
| pedroalvarez | this is the patch: http://git.baserock.org/cgi-bin/cgit.cgi/delta/ca-certificates.git/commit/?h=baserock/debian/20140325&id=e9b06b26d9e57444e74a5cb6beca3f12726fc3c6 | 14:17 |
| pedroalvarez | git clone https://.. works | 14:18 |
| ssam2 | cool ! why is the patch needed? | 14:30 |
| pedroalvarez | because I want to run update-ca-certificates as a post-install-command | 14:32 |
| pedroalvarez | because curl needs them installed at build time | 14:33 |
| ssam2 | oh, so you want it to support DESTDIR ? | 14:33 |
| pedroalvarez | ssam2: this is the morphology to install it http://pastebin.com/KGJiqdef | 14:35 |
| pedroalvarez | with destdir wouldn't be enough I think | 14:36 |
| richard_maw | pedroalvarez: quote the "$ETCCERTSDIR" in the mkdir -p | 14:36 |
| pedroalvarez | richard_maw: will do :) | 14:37 |
| richard_maw | looks good | 14:37 |
| pedroalvarez | update-ca-certificates reads from /etc/ and from /usr/share and writes in /etc | 14:37 |
| richard_maw | I was thinking we'd have to do a staging-integration and system-integration to do it, but if we only have certs coming from the ca-certificates chunk, this'll be sufficient until we need multiple cert sources | 14:38 |
| pedroalvarez | sent for review | 14:45 |
| Kinnison | richard_maw: even with staging integration, we need destdir support in the script | 14:46 |
| violeta | http://pastebin.com/CRs6HeHv I'm getting this error and I'm not sure where to look, I've tried the most intuitive places, but can't find what is failing. Do you think it has to do with the modules pedroalvarez ? because it says /lib/modules/ doesn't exist | 14:50 |
| radiofree | violeta: why's it looking for /lib/modules/3.10.24-g123cc6? | 14:51 |
| violeta | radiofree, I'm not sure because I haven't been able to find where is doing those commands.. | 14:51 |
| radiofree | did you make an install the kernel modules? | 14:51 |
| radiofree | it looks like it's trying to use your systems kernel module dir | 14:52 |
| violeta | radiofree, this http://pastebin.com/0ZzVPkyL ? or you mean "make modules_install" or... ? I have no idea | 14:52 |
| violeta | oh | 14:52 |
| radiofree | erm... | 14:53 |
| radiofree | i have no idea what that file is violeta oO | 14:53 |
| violeta | that's what pedroalvarez has told me to do for out of tree kernel modules | 14:53 |
| pedroalvarez | hehe that is to install the kernel source needed to build out-of-tree kernel modules | 14:53 |
| radiofree | your kernel, you need to make modules_install MOD_DEST_DIR (or whatever it is)=.... | 14:53 |
| violeta | make INSTALL_MOD_PATH="$DESTDIR" modules_install | 14:54 |
| violeta | ? | 14:54 |
| radiofree | something like that yes | 14:54 |
| violeta | pedroalvarez, so seems like I need that | 14:54 |
| violeta | but then I have to do "make modules" before | 14:54 |
| radiofree | but the kernel you're building should be a 3.17 | 14:54 |
| violeta | yes, I thought it was | 14:55 |
| radiofree | so it looks like it's trying to install it for the kernel currently running | 14:55 |
| radiofree | you'll have to ask someone familar with out-of-tree kernel modules | 14:58 |
| violeta | so it is trying to install it for my kernel because I haven't done the make modules_install or is there something else I should check? | 14:58 |
| radiofree | depmod command is failing | 14:58 |
| violeta | ok | 14:58 |
| radiofree | well, did you do make modules_install? | 14:58 |
| violeta | no | 14:58 |
| radiofree | check in the chroot dir | 14:58 |
| radiofree | oh well, you need to do that | 14:58 |
| violeta | ok, there was a bit of a confusion before | 14:58 |
| violeta | just to be sure, pedroalvarez , do I need to do "make INSTALL_PATH="$DESTDIR"/boot install" too? | 15:01 |
| pedroalvarez | violeta: I think you don't. That looks like to install the kernel | 15:01 |
| violeta | ok, ta | 15:02 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 15:08 | |
| radiofree | i still think this is going to fail though | 15:15 |
| radiofree | make sure you compile nouveau as a module violeta | 15:16 |
| violeta | radiofree, I've done what you told me: cd drm && make (special out-of-tree kernel module info here) | 15:18 |
| violeta | in https://github.com/Gnurou/nouveau/tree/gk20a | 15:19 |
| radiofree | yes but i mean in the kernel config | 15:20 |
| radiofree | build nouveau as a module there | 15:20 |
| violeta | oh :-/ | 15:20 |
| radiofree | (as well) | 15:20 |
| * radiofree did say that | 15:21 | |
| radiofree | scripts/config -m DRM_NOUVEAU..... scripts/config -e DRM_TEGRA_STAGING | 15:22 |
| paulsherwood | violeta: can you push your definitions branch somewhere? | 15:29 |
| paulsherwood | say github, for example? | 15:29 |
| violeta | paulsherwood, ok | 15:29 |
| * paulsherwood has a jetson, would like to follow along :) | 15:30 | |
| violeta | paulsherwood, do you need my kernel & u-boot branches too? | 15:33 |
| pedroalvarez | radiofree: can I ask you how did you deployed this system? http://download.baserock.org/baserock/baserock-e424935744d-devel-system-jetson.tar.gz | 15:34 |
| pedroalvarez | s/deployed/deploy/ | 15:34 |
| pedroalvarez | using the tar.write extension? | 15:34 |
| radiofree | no, rawdisk.write | 15:35 |
| radiofree | i think | 15:35 |
| pedroalvarez | yeah, that makes more sense to me | 15:35 |
| radiofree | is that the one on the jetson guide page, that tells you to use baserock-jetson-flash? | 15:35 |
| pedroalvarez | yes | 15:35 |
| radiofree | that's rawdisk.write then, i manually gziped it up | 15:36 |
| paulsherwood | violeta: hmm... that could be a long upload for you | 15:36 |
| paulsherwood | pedroalvarez: could we give violeta access to the baserock-clone trove so she can push with minimum grief? | 15:37 |
| paulsherwood | (or gbo, if we're confident in her git skills) | 15:38 |
| radiofree | fork on github and push it as a branch? | 15:38 |
| paulsherwood | is there a kernel mirror on github? | 15:38 |
| paulsherwood | dumb question | 15:39 |
| richard_maw | there was when kernel.org was down | 15:39 |
| paulsherwood | violeta: https://github.com/torvalds/linux | 15:40 |
| paulsherwood | fork that and you should be good to push | 15:40 |
| paulsherwood | violeta: https://github.com/swarren/u-boot may be a reasonable place to start for a u-boot fork | 15:42 |
| violeta | paulsherwood, I thought I had access to gbo | 15:42 |
| paulsherwood | oh, if you do, go right ahead :) | 15:42 |
| paulsherwood | (push access? ) | 15:42 |
| paulsherwood | violeta: `morph trovectl whoami` | 15:43 |
| violeta | paulsherwood, I am a member of baserock-writers, although I can't do `morph trovectl whoami` right now from the Jetson, I don't know why :-S | 15:44 |
| paulsherwood | weird | 15:46 |
| * violeta facepalms | 15:47 | |
| violeta | I forgot -A for my ssh connection | 15:47 |
| violeta | \o/ | 15:47 |
| paulsherwood | :-) | 15:49 |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 16:07 | |
| violeta | paulsherwood, violeta-jetson in baserock/definitions, currently working on u-boot and linux repos (branch naming problems...) | 16:10 |
| paulsherwood | violeta: i think you need to name baserock/violeta/foo | 16:14 |
| violeta | paulsherwood, yeah, done right now | 16:14 |
| radiofree | bizarre place to add "cma=256M" | 16:18 |
| radiofree | violeta: add it to the front of the kernel args | 16:18 |
| violeta | does it affect anything? (not that I don't want to change it, but to know if I had mess with something) | 16:19 |
| radiofree | well this version of u-boot cuts of the kernel args, so it might do yes | 16:19 |
| radiofree | drm-module should be renamed nouveau-drm | 16:19 |
| radiofree | don't forget to build nouveau as a module in the kernel config | 16:20 |
| radiofree | + TEGRA_STAGING (enable that) | 16:20 |
| violeta | yes! | 16:21 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 16:33 | |
| paulsherwood | yes? is that a result? | 16:50 |
| violeta | erhm, no, that was a "yes! I won't forget again" | 16:51 |
| paulsherwood | :) | 16:51 |
| violeta | sorry to disappoint you ;-) | 16:51 |
| paulsherwood | day's not over :) | 16:52 |
| violeta | indeed | 16:52 |
| paulsherwood | pedroalvarez: your ca-certs branch appears not to work for me... eg curl https://github.com fails. anything i can check? | 16:58 |
| pedroalvarez | `curl https://www.httpsnow.org/` | 16:59 |
| pedroalvarez | `git clone https://github.com/ansible/ansible-examples.git` | 16:59 |
| paulsherwood | url: (60) SSL certificate problem: unable to get local issuer certificate | 16:59 |
| paulsherwood | to be fair, i did some other things too.. | 17:00 |
| paulsherwood | let me *just* build your branch | 17:00 |
| pedroalvarez | :) | 17:00 |
| pedroalvarez | baserock/pedroalvarez/ca-certificates2 | 17:00 |
| paulsherwood | ah i may have misssed the 2 | 17:01 |
| paulsherwood | bah... quite a rebuild, that... | 17:03 |
| radiofree | the problems with putting things in core :\ | 17:04 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:07 | |
| pedroalvarez | after some hours analyzing the problem with fstab when upgrading systems, I think I know how to solve it | 17:15 |
| pedroalvarez | and reusing existing code | 17:16 |
| pedroalvarez | I don't have time to send a patch now, though | 17:16 |
| ssam2 | bah, seems I merged three separate branches while trying to merge one | 17:23 |
| ssam2 | http://ct-mcr-1.ducie.codethink.co.uk/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=master&id=b12b320e86a54d69aa9661f5bff95dfcac2c8b78 | 17:23 |
| ssam2 | oh hang on, I'm looking at an internal trove that mirrors the upstream one | 17:23 |
| ssam2 | same on git.baserock.org, though | 17:23 |
| ssam2 | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=master&id=b12b320e86a54d69aa9661f5bff95dfcac2c8b78 | 17:23 |
| ssam2 | it's all stuff that should be in master anyway, though, so I'm not going to revert anything | 17:25 |
| ssam2 | in fact, I think it's just being displayed strangely by cgit. | 17:26 |
| ssam2 | good night all! | 17:27 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:27 | |
| violeta | it failed D-: | 17:48 |
| * violeta is frustrated enough for today | 17:49 | |
| jjardon | paulsherwood: sorry, i forgot to replay to your message from this morning; i normally build a genivi baseline image and run a weston session to check everything works (in case you want to recheck) | 18:49 |
| jjardon | Also, maybe its my biased perception but weston seems to run smoother after all the upgrades | 18:50 |
| paulsherwood | pedroalvarez: have you seen anything like this? http://fpaste.org/137937/ | 20:31 |
| paulsherwood | actually, that's just me being dumb... sorry for the noise | 20:33 |
| paulsherwood | can someone remind me what i need as extr deplol line for genivi baseline weston? | 21:10 |
| paulsherwood | jjardon: ^^? | 21:10 |
| paulsherwood | something VGA | 21:10 |
| * paulsherwood finds it in release.morph KERNEL_ARGS: vga=788 | 21:15 | |
| paulsherwood | jjardon: i think i've built your branch, but nothing shows up on screen when i run weston | 21:24 |
| paulsherwood | will test more tmrw | 21:24 |
| paulsherwood | (libdrm) | 21:24 |
| jjardon | paulsherwood: did you run weston with the fb backend? (weston --backend=fbdev-backend.so) | 21:29 |
| pedroalvarez | paulsherwood: did the ca-certificates built then? | 21:38 |
| pedroalvarez | s/built/build/ | 21:39 |
| *** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 22:01 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!