IRC logs for #baserock for Tuesday, 2014-09-30

SotKpedroalvarez: thanks for fixing the lorries :)07:01
* SotK wishes for YAML lorries07:01
*** dutch [] has joined #baserock07:15
*** tiagogomes [~tiagogome@] has joined #baserock07:33
pedroalvarezSotK: np :)07:53
paulsherwoodjjardon: building now....what should i test?07:56
*** pdar [] has joined #baserock08:12
dutchpedroalvarez: is there a stratum containing mariadb?08:41
*** violeta [] has joined #baserock08:43
*** jonathanmaw [] has joined #baserock08:47
dutchthanks paulsherwood08:54
*** ssam2 [] has joined #baserock09:03
juergbihi ssam2, a comment about your linux api headers mail from last week. updating linux headers does not normally break userspace from running with older kernels09:07
pedroalvarezquestion: 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
juergbissam2: glibc's --enable-kernel= is what decides that09:08
Kinnisonpedroalvarez: 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 message09:08
Kinnisonpedroalvarez: but ultimately making that distinction is up to you09:09
ssam2juergbi: oh, thanks for pointing that out09:09
ssam2I'll reply to that effect on the mailing list for posterity09:09
pedroalvarezKinnison: makes sense, thanks09:10
violetaaren't the configure-commands supposed to run before the build-commands?09:17
Kinnisonvioleta: yep09:18
pedroalvarezvioleta: any reason you think that is not happening?09:19
violetaI get the message: "Running build-commands", but not the equivalent for configure-commands, and the build is failing...09:19
Kinnisonsounds like it's not running your morphology09:20
Kinnisonor perhaps you have a typo09:20
pedroalvarezvioleta: could we see the stratum and the chunk morpholigies?09:21
*** jmacs [] has joined #baserock09:41
ssam2pedroalvarez: I guess you've noticed the problems in the public Mason at already09:53
ssam2have I missed a discussion of it or does it still need investigating ?09:53
ssam2seems that the issue is that it's trying to Git clone ssh:// URLs from but doesn't have access to do that09:54
ssam2and for the delta/ repos this isn't a problem because it then fetches a tarball09:54
ssam2but for the baserock/ repos there are no tarballs so it gets an error09:54
violetamy stratum and chunk:
ssam2so 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
violetathe error I get:
pedroalvarezssam2: but Mason ended up building it09:54
pedroalvarezvioleta: can you use a public paste service?09:55
ssam2pedroalvarez: 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 ..09:57
ssam2the 'baserock:' repo-alias expands to ssh:// for reads as well as writes, so that's the problem, I guess09:58
Kinnisonbaserock: should expand to git:// for reads10:01
KinnisonDoes it not?10:01
ssam2it does in my Baserock chroot10:01
ssam2but it doesn't on that Mason10:01
ssam2which has trove-host = and trove-id = baserock10:02
KinnisonIt should only change to ssh:// if the trove-id and/or trove-hostname is changed from default I think10:02
pedroalvarezvioleta: is there a u-boot.morph in your u-boot checkout?10:02
ssam2but in my chroot I have trove-id = ct-mcr-1 and trove-host = ct-mcr-1 and it works fine10:02
violetapedroalvarez, checkout?10:02
ssam2by "works fine" I mean "doesn't use an ssh URL for reads"10:02
KinnisonI imagine you have keys for your ct-mcr-1 trove, wherever that is10:02
ssam2no, the repo-alias pattern expands to a git:// URL10:03
ssam2well, one git:// and one ssh:// for push access10:03
Kinnisonbaserock: will expand to ssh://git@TROVE-HOST/10:03
Kinnisonerm /baserock/10:03
KinnisonI wonder if you're looking at pre- or at post- config processing10:03
pedroalvarezwell, looking at the morphologies looks like you have used `morph edit` to clone u-boot in your workspace10:03
ssam2Kinnison: in my chroot? no, it doesn't10:03
violetapedroalvarez, yes10:04
pedroalvarezlooks 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 morphology10:04
pedroalvarezso I assume that instead of usinng strata/bsp-jetson-devel/u-boot.morph, is using something else10:05
pedroalvarezif you look in wherever you have the u-boot sources, can you see an u-boot.morph file?10:05
pedroalvarezIf so, can you share it with me?10:06
* Kinnison notes that u-boot is also present in the tools stratum10:07
Kinnisoncould confusion be happening because of that10:07
violetapedroalvarez, no .morph in my u-boot source, should there be?10:08
Kinnisonvioleta: ^^^10:08
Kinnisonthis could be a chunk-name conflict10:08
* paulsherwood would like to suggest that morph disallow duplicate names in the whole chunks/strata/systems space10:09
paulsherwoodbut anyway10:09
pedroalvarezvioleta: no no, just checking what was happening10:10
pedroalvarezare 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 confused10:11
Kinnisonpaulsherwood: I want all artifact names to be enforced-unique too10:11
Kinnisonpaulsherwood: at least within systems10:11
violetapedroalvarez, yes, I'm sure, but Kinnison is right, the error is with strata/tools/u-boot.morph10:12
paulsherwoodif within the whole of definitions, we can remove the need to specify relative paths10:12
Kinnisonvioleta: did 'morph edit' edit that too?10:12
Kinnisonvioleta: if so, just "unedit" strata/tools.morph10:12
Kinnisonand things should settle10:12
violetaahhhh, 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" patch10:14
pedroalvarezah, yes, u-boot in tools. I somehow thought looking at the log that the error was happening when building the u-boot in the bsp10:14
violetapedroalvarez, that's what I thought too10:15
ssam2can I commit this fix for Mason configuration?
paulsherwoodssam2: +110:22
ssam2this doesn't fix the issue on our public Mason, it fixes a problem with deploying non-generic Masons10:22
Kinnisonssam2: +110:23
ssam2my existing baserock/sam/mason-deploy-fix branch from Friday needs another +1 too10:27
paulsherwood(assuming you've tested it)10:28
paulsherwoodssam2: ^^10:29
pedroalvarezsorry about the errors :(10:29
paulsherwoodwe all make errors ;)10:30
paulsherwoodpedroalvarez: branch for your morph --version fix?10:34
paulsherwoodfound it10:34
pedroalvarezthis time the test pass :)10:34
paulsherwoodpedroalvarez: +110:35
paulsherwoodssam2: please grant a +1 to pedroalvarez ? :)10:37
SotKpedroalvarez: +110:39
SotK(I tried to reply on the list but my mail client is misbehaving)10:40
pedroalvarezthanks guys!10:40
paulsherwoodvioleta: are you still stuck?10:41
violetapaulsherwood, 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 now10:42
violetacross your fingers10:42
paulsherwoodthat builds10:43
paulsherwoodand deploys10:43
paulsherwoodvioleta: please check if you've fixed all the configs10:44
violetapaulsherwood, I haven't changed the dtb name :-S10:46
paulsherwoodsay 'gracias, paul' :-)10:47
violetathanks paulsherwood10:48
paulsherwoodyw. by return, you have to fix the btrfs problem i hit :)10:48
violetamercy beaucoup10:48
violetapaulsherwood, what problem?10:49
paulsherwoodvioleta: somehow it fails to pick up my /src mount... i had a similar problem on OpenStack, maybne i should try pedroalvarez' fix for that11:13
pedroalvarezwasn't a fix11:13
pedroalvarezpaulsherwood: Is this happening after an upgrade?11:14
pedroalvarezin a jetson?11:14
pedroalvarezpaulsherwood: can I see /etc/fstab after the upgrade?11:14
paulsherwoodit worked for me on cloud. on what basis can you say that it wasn't a fix?11:14
radiofreepaulsherwood: maybe sata isn't enabled/11:15
paulsherwoodah, true11:15
paulsherwoodso will setting ROOT_DEVICE: /dev/vda cause any harm?11:15
radiofreeare you talking about a jetson?11:15
pedroalvarezpaulsherwood: in jetson won't work at all 11:16
radiofreethere won't be a /dev/vda11:16
radiofreemount /dev/sda1 /src, see if that works11:16
pedroalvarezradiofree: but that "fix" will screw up the entire fstab file11:16
radiofreepedroalvarez: eh?11:16
radiofreei added ROOT_DEVICE: specifically to allow the fstab to be set to /dev/sda111:17
radiofreeno wait11:17
radiofreei didn't11:17
radiofreeROOT_DEVICE is for the  bootloader11:17
radiofreepaulsherwood: you want /dev/mmcblk0p1 as your ROOT_DEVICE for jetson11:17
* paulsherwood avoids touching ROOT_DEVICE, and redoes the deploy11:17
radiofreewhat does your fstab look like on the system without /src?11:17
pedroalvarezThis is the reason I say that it wasn't a fix. The upgrade should handle this by default, without ROOT_DEVICE11:18
radiofreeif you don't have a /dev/sda1 then the kernel doesn't have sata11:18
radiofreepedroalvarez: tbdiff doesn't use ROOT_DEVICE?11:19
pedroalvarezthat looks sane, but this is before the upgrade I believe11:19
paulsherwoodtrue, upgrading now11:19
radiofreeso you're upgrading from 3.10 to ?11:19
paulsherwood3.17-rc6 or 711:20
pedroalvarezradiofree: as you can see in this paste we use UUID in fstab to make it more generic. The upgrade should keep this format instead of hardcoding /dev/sda, vda, mmc* IMO11:22
paulsherwood is where things hang around....11:25
paulsherwoodafter upgrade fstab is
pedroalvarezfstab is ok11:26
radiofreeyeah, do you have a /dev/sda1?11:27
pedroalvarez`ls -l /dev/sda1`11:27
radiofreeno sata11:27
pedroalvarezradiofree: do you know how to enable it>11:27
radiofreeI assumed it would have been enabled by default11:28
radiofreeask in #tegra11:28
radiofreemaybe it didn't land for 3.1711:28
paulsherwoodthis is 3.1611:28
paulsherwoodsorry 3.17-rc611:28
paulsherwoodi'll try rc711:28
radiofreethat might not help11:29
paulsherwoodi think it won't, tbh11: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
paulsherwoodok, where would i find those?11:31
radiofreeyou might be able to add it to the device tree11:32
radiofree there's
KinnisonYou won't get SATA working fully until you also merge the pci/next stuff11:55
KinnisonAt least I didn't11:55
Kinnison *and* upgrade your u-boot11:55
paulsherwoodah, is u-boot upgrade required too? that's beyond my reach at this point11:56
paulsherwoodKinnison: Manfred assures me that none of his colleagues in the office moved common-api tags, but some are on holiday12:08
paulsherwoodis there any possibility of an issue our end?12:08
KinnisonNot that could cause this kind of behaviour12:08
KinnisonRemember the tag moves could be as old as June12:08
KinnisonIf someone in the team then force-pushed something else, they could force-push a tag move if they weren't careful12:09
paulsherwoodyup, i assume they are12:09
paulsherwood'Unfortunately I don’t know any way to look up tag changes in git itself...12:09
paulsherwoodfrom manfred12:09
* Kinnison pokes a stick at the web HMI for smartdevicelink in the meantime12:09
paulsherwoodi 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/traceability12:11
Kinnisontrap/prevent aye12:13
paulsherwoodwe can't prevent it. upstream can do what they like?12:15
KinnisonWe can prevent the damage hitting our trove12:16
KinnisonWe discussed automatically creating shadow tags when new tags showed up, so that when upstream blorfs a tag, our shadow-tag would still anchor the commit12:16
KinnisonOkay, so the stick I poked this HMI with went in, but has yet to come back12:17
paulsherwoodyes to the shadow tags idea12:17
KinnisonMmm, now the idea is easy, the details are way harder to work out12:18
paulsherwoodreally? seems pretty simple12:18
paulsherwoodbut.... unpetrify12:19
Kinnisonunpetrify needs to go away12:19
Kinnisonso don't think about it12:19
KinnisonWe'll need a nominated anchor ref12:19
Kinnisonbut don't think "unpetrify"12:19
Kinnison'ref' should go away and be 'sha1'12:19
Kinnisonand should always be a sha112:19
* Kinnison <- opinionated12:20
paulsherwoodi'm fine with that12:21
KinnisonOkay, so stracing this server shows the http request coming in12:21
Kinnisonand nothing going back out12:21
paulsherwoodany config required on the server?12:22
* paulsherwood cant remember how this worked originally12:22
KinnisonI'm currently looking at what has been installed to see if I'm missing content12:22
KinnisonI used that back when I started this branch, yes12:23
paulsherwoodiirc the server had to be run in the right directory12:23
KinnisonOh cripes12:23
paulsherwoodi may be wrong, though12:24
paulsherwoodi think we were using just busybox http last time?12:25
KinnisonThere's no useful content installed12:26
* Kinnison needs to see what's missing from their build system12:26
jjardonI think baserock would be quite less uselful if you force ref to be a sha instead a branch/tag13:01
violetawhat's the problem with ref being a branch?13:02
KinnisonLack of lock-down means a given build is harder to reproduce13:02
paulsherwoodjjardon, violeta - we need some way of tracking back to see what was actually built. tags and branches can move13:02
KinnisonAnd I'm sorry to say that recent events have made me even more militant about this13:03
paulsherwoodi think we need to support both worlds13:03
jjardonpaulsherwood: is that the only problem, you can store that info in the resulting build somewhere13:03
KinnisonI think tracking a ref is either something 'morph build' should be doing, or firehose13:03
paulsherwoodspeed by allowing developers to use tags. reproducibility by locking SHA1s13:03
paulsherwoodjjardon: not if the tag/branch is later moved...13:04
paulsherwoodmay leave dangling commits, which get lost13:04
jjardonpaulsherwood: morph could store the actual sha that gets builded, not the tag/branch13:04
KinnisonWe do13:05
Kinnisonbut it's not in the commit13:05
KinnisonWhich means the commit can't be usefully reused later13:05
KinnisonAlso, the SHA doesn' thelp if upstream changes the tag/branch in a force-push way, and thus the relevant objects are lost through gc13:05
SotKKinnison: 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 problem13:06
KinnisonSotK: It's an approach13:07
KinnisonBut there's other aspects which need checking13:07
jjardonKinnison: then what is the advantage to ref pointing to SHAs? Same can happen if upstream force-push13:08
Kinnisonjjardon: that's what the point of the anchor ref is13:08
Kinnisonjjardon: something we currently unfortunately call unpetrify-re13:08
KinnisonWe *should not* rely on refs out of our control for anchoring things13:08
Kinnisonwe currently do, an awful lot, and that's bad13:09
jjardonKinnison: is that documented somewhere?13:10
* jjardon always found the unpetrify-ref concept/field a bit confusing to understand13:11
tlsame too13:11
Kinnisonjjardon: this is all a bit under-documented and under-understood because we keep having thoughts about how we'd prefer it to be13:12
* jjardon would expect a explanation of the current "correct" thing to do when he submitted patches changing that field13:13
KinnisonThere's little consensus on the 'correct' thing right now13:13
KinnisonParticularly since we're not making releases13:14
petefothTo 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
jjardoncant 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 anymore13:18
KinnisonResults in a lot of human time resolving safe forces vs. unsafe forces13:19
Kinnisonjjardon: sha as ref is about reproducing from a commit13:19
Kinnisonjjardon: anchoring is about preventing issues when upstream forces13:19
Kinnisonjjardon: 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 builds13:20
Kinnisonpetefoth: We probably need to write down all the things we're thinking about on this topic and then try and rationalise them13:20
Kinnisonpetefoth: 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 resolve13:20
violetapedroalvarez, the instructions you gave me for building an out of tree kernel module make my build fail, I think something is missing,
petefothKinnison: 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 that13:22
petefothIn the absence of StroyBoard, I may create a wikipage as a duimping ground for iseas and questions13:22
jjardonpetefoth: if you want to tart a conversation to get feedback probably email works better, then you can put the conclusions in the wiki13:24
pedroalvarezvioleta: heheh I enjoyed your report :)13:25
petefothjjardon: 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
pedroalvarezvioleta: what I suggested you to add:
tlsawhy 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
violetapedroalvarez, that's the [...] in my report :-P, so I currently do that13:26
Kinnisontlsa: that's one possible argument, although the only valid mark is "maybe reproducible" vs. "not reproducible"13:26
pedroalvarezvioleta: so remove 'make INSTALL_MOD_PATH="$DESTDIR" modules_install' if it wasn't there before13:27
violetapedroalvarez, the problem is that I think I have to do something *before*, like making the modules or something13:27
Kinnison'make modules'13:27
Kinnisonin the build commands13:27
pedroalvarezKinnison: but is that needed?13:27
KinnisonIf you want to do modules_install, yes13:27
violetapedroalvarez, it wasn't there before, you told me to add those two lines too13:27
pedroalvarezKinnison: is that going to be needed to install later an out-of-tree kernel module?13:28
tlsacould have `morph lock`, `morph unlock` to convert from ref as branch to ref as current sha1 and viseversa13:28
Kinnisonpedroalvarez: that, I couldn't tell you off the top of my head13:28
jjardonwhat 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 branches13:29
Kinnisontlsa: welcome to petrify/unpetrify and all the pains that produces13:29
Kinnisonjjardon: IMO master should *always* be reproducible13:29
Kinnisonjjardon: meaning we need both SHA1s in all the commits *and* something tracking and anchoring them13:29
KinnisonBut I am an extremist13:29
pedroalvarezvioleta: sorry, but I didn't wanted to say that. So please, remove it13:30
violetapedroalvarez, :-) ta13:30
pedroalvarezunless someone else says that it's needed13:30
jjardonKinnison: 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-ref13:31
Kinnisonjjardon: currently we're not making releases -- that means master must be reproducible or people will be unable to identify when issues arise / are fixed13:32
KinnisonIf we were making regular releases, I'd only demand releases be reproducible13:32
Kinnison*but* I do not want to be the person making the final technical decisions on this13:32
KinnisonI'm just opinionated and loud :-)13:32
jjardonthat would work for me13:33
KinnisonAnd right now, my opinion is that cmake and all its ilk should be purged from history13:33
rjekeugh, cmake13:33
jjardonmaster 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% reproducible13:34
jjardon(and you can still probably reproduce a master build if you have the resulting metadata available)13:34
petefothReproducibiliy may not be a requirment for all BAserock users13:35
Kinnisonjjardon: I'd prefer that the majority of master be locked down already13:35
KinnisonOtherwise it increases time-to-build on average13:36
jjardonId say thats a bug: you can not stop updating the system components because the time to build is too long13:37
KinnisonI wouldn't want the majority of core system components to be updated willy-nilly because of upstream pushes13:39
KinnisonI want firehose to be carefully pulling in changes, and *testing* them before giving them to master13:39
Kinnisonotherwise we can't run a master which could be released with relative ease13:39
* Kinnison strongly dislikes projects whose master branch may or may not be buildable13:39
tlsayeah, 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 that13:39
* Kinnison continues to poke at cmake with a desultory stick13:40
jjardonI 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
tlsanormally they would tag to say "this is ready to be used/supported"13:44
KinnisonAfter 14 years as a Debian developer I can say I have developed a deep distrust of upstreams :-)13:44
ssam2that 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 Baserock13:47
ssam2that's not to say that you're wrong, of course13:47
KinnisonOne can be close to something one distrusts13:47
ssam2fair point13:47
KinnisonOtherwise driving on the road system would be impossible13:47
tlsaI guess it depends on the project.  Ones like libpng make very frequent releases with fixes and stuff, so it's frequently taged13:49
tlsaones like NetSurf are about half a year between tags :)13:49
tlsawe don't really bother with bugfix releases, and try to ensure master isn't broken, or if it is, then not for too long13:50
jjardonwell, 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 used13:50
paulsherwoodjjardon: that's true for the most part. but if they change something, we need to trap it.13:51
rjekUpstreams can be unhinged lunatics.13:51
tlsaalso, 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 master13:52
rjekBut CI can detect some of that.13:52
jjardonpaulsherwood: 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
jjardonrjek: the same can be said about downstream, but we are not talking about that here13:56
* pedroalvarez has integrated ca-certificates in a baserocky way but patching upstream14:16
pedroalvarezthis is the patch:
pedroalvarezgit clone https://.. works14:18
ssam2cool ! why is the patch needed?14:30
pedroalvarezbecause I want to run update-ca-certificates as a post-install-command14:32
pedroalvarezbecause curl needs them installed at build time14:33
ssam2oh, so you want it to support DESTDIR ?14:33
pedroalvarezssam2: this is the morphology to install it
pedroalvarezwith destdir wouldn't be enough I think14:36
richard_mawpedroalvarez: quote the "$ETCCERTSDIR" in the mkdir -p14:36
pedroalvarezrichard_maw: will do :)14:37
richard_mawlooks good14:37
pedroalvarezupdate-ca-certificates reads from /etc/ and from /usr/share and writes in /etc14:37
richard_mawI 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 sources14:38
pedroalvarezsent for review14:45
Kinnisonrichard_maw: even with staging integration, we need destdir support in the script14:46
violeta 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 exist14:50
radiofreevioleta: why's it looking for /lib/modules/3.10.24-g123cc6?14:51
violetaradiofree, I'm not sure because I haven't been able to find where is doing those commands..14:51
radiofreedid you make an install the kernel modules?14:51
radiofreeit looks like it's trying to use your systems kernel module dir14:52
violetaradiofree, this ? or you mean "make modules_install" or... ? I have no idea14:52
radiofreei have no idea what that file is violeta oO14:53
violetathat's what pedroalvarez has told me to do for out of tree kernel modules14:53
pedroalvarezhehe that is to install the kernel source needed to build out-of-tree kernel modules14:53
radiofreeyour kernel, you need to make modules_install MOD_DEST_DIR (or whatever it is)=....14:53
violetamake INSTALL_MOD_PATH="$DESTDIR" modules_install14:54
radiofreesomething like that yes14:54
violetapedroalvarez, so seems like I need that14:54
violetabut then I have to do "make modules" before14:54
radiofreebut the kernel you're building should be a 3.1714:54
violetayes, I thought it was14:55
radiofreeso it looks like it's trying to install it for the kernel currently running14:55
radiofreeyou'll have to ask someone familar with out-of-tree kernel modules14:58
violetaso 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
radiofreedepmod command is failing14:58
radiofreewell, did you do make modules_install?14:58
radiofreecheck in the chroot dir14:58
radiofreeoh well, you need to do that14:58
violetaok, there was a bit of a confusion before14:58
violetajust to be sure, pedroalvarez , do I need to do "make INSTALL_PATH="$DESTDIR"/boot install" too?15:01
pedroalvarezvioleta: I think you don't. That looks like to install the kernel15:01
violetaok, ta15:02
*** genii [~quassel@ubuntu/member/genii] has joined #baserock15:08
radiofreei still think this is going to fail though15:15
radiofreemake sure you compile nouveau as a module violeta15:16
violetaradiofree, I've done what you told me:  cd drm && make (special out-of-tree kernel module info here)15:18
radiofreeyes but i mean in the kernel config15:20
radiofreebuild nouveau as a module there15:20
violetaoh :-/15:20
radiofree(as well)15:20
* radiofree did say that15:21
radiofreescripts/config -m DRM_NOUVEAU..... scripts/config -e DRM_TEGRA_STAGING15:22
paulsherwoodvioleta: can you push your definitions branch somewhere?15:29
paulsherwoodsay github, for example?15:29
violetapaulsherwood, ok15:29
* paulsherwood has a jetson, would like to follow along :)15:30
violetapaulsherwood, do you need my kernel & u-boot branches too?15:33
pedroalvarezradiofree: can I ask you how did you deployed this system?
pedroalvarezusing the tar.write extension?15:34
radiofreeno, rawdisk.write15:35
radiofreei think15:35
pedroalvarezyeah, that makes more sense to me15:35
radiofreeis that the one on the jetson guide page, that tells you to use baserock-jetson-flash?15:35
radiofreethat's rawdisk.write then, i manually gziped it up15:36
paulsherwoodvioleta: hmm... that could be a long upload for you15:36
paulsherwoodpedroalvarez: 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
radiofreefork on github and push it as a branch?15:38
paulsherwoodis there a kernel mirror on github?15:38
paulsherwooddumb question15:39
richard_mawthere was when was down15:39
paulsherwoodfork that and you should be good to push15:40
paulsherwoodvioleta: may be a reasonable place to start for a u-boot fork15:42
violetapaulsherwood, I thought I had access to gbo15:42
paulsherwoodoh, if you do, go right ahead :)15:42
paulsherwood(push access? )15:42
paulsherwoodvioleta: `morph trovectl whoami`15:43
violetapaulsherwood, 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 :-S15:44
* violeta facepalms15:47
violetaI forgot -A for my ssh connection15:47
*** dutch [] has quit [Quit: Quit]16:07
violetapaulsherwood, violeta-jetson in baserock/definitions, currently working on u-boot and linux repos (branch naming problems...)16:10
paulsherwoodvioleta: i think you need to name baserock/violeta/foo16:14
violetapaulsherwood, yeah, done right now16:14
radiofreebizarre place to add "cma=256M"16:18
radiofreevioleta: add it to the front of the kernel args16:18
violetadoes it affect anything? (not that I don't want to change it, but to know if I had mess with something)16:19
radiofreewell this version of u-boot cuts of the kernel args, so it might do yes16:19
radiofreedrm-module should be renamed nouveau-drm16:19
radiofreedon't forget to build nouveau as a module in the kernel config16:20
radiofree+ TEGRA_STAGING (enable that)16:20
*** tiagogomes [~tiagogome@] has quit [Quit: Leaving]16:33
paulsherwoodyes? is that a result?16:50
violetaerhm, no, that was a "yes! I won't forget again"16:51
violetasorry to disappoint you ;-)16:51
paulsherwoodday's not over :)16:52
paulsherwoodpedroalvarez: your ca-certs branch appears not to work for me... eg curl fails. anything i can check?16:58
pedroalvarez`git clone`16:59
paulsherwoodurl: (60) SSL certificate problem: unable to get local issuer certificate16:59
paulsherwoodto be fair, i did some other things too..17:00
paulsherwoodlet me *just* build your branch17:00
paulsherwoodah i may have misssed the 217:01
paulsherwoodbah... quite a rebuild, that...17:03
radiofreethe problems with putting things in core :\17:04
*** jonathanmaw [] has quit [Quit: Leaving]17:07
pedroalvarezafter some hours analyzing the problem with fstab when upgrading systems, I think I know how to solve it17:15
pedroalvarezand reusing existing code17:16
pedroalvarezI don't have time to send a patch now, though17:16
ssam2bah, seems I merged three separate branches while trying to merge one17:23
ssam2oh hang on, I'm looking at an internal trove that mirrors the upstream one17:23
ssam2same on, though17:23
ssam2it's all stuff that should be in master anyway, though, so I'm not going to revert anything17:25
ssam2in fact, I think it's just being displayed strangely by cgit.17:26
ssam2good night all!17:27
*** ssam2 [] has quit [Quit: Leaving]17:27
violetait failed D-:17:48
* violeta is frustrated enough for today17:49
jjardonpaulsherwood: 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
jjardonAlso, maybe its my biased perception but weston seems to run smoother after all the upgrades18:50
paulsherwoodpedroalvarez: have you seen anything like this?
paulsherwoodactually, that's just me being dumb... sorry for the noise20:33
paulsherwoodcan someone remind me what i need as extr deplol line for genivi baseline weston?21:10
paulsherwoodjjardon: ^^?21:10
paulsherwoodsomething VGA21:10
* paulsherwood finds it in release.morph KERNEL_ARGS: vga=78821:15
paulsherwoodjjardon: i think i've built your branch, but nothing shows up on screen when i run weston21:24
paulsherwoodwill test more tmrw21:24
jjardonpaulsherwood: did you run weston with the fb backend? (weston
pedroalvarezpaulsherwood: did the ca-certificates built then?21:38
*** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection]22:01

Generated by 2.15.3 by Marius Gedminas - find it at!