IRC logs for #baserock for Wednesday, 2015-06-10

*** zoli__ has joined #baserock02:26
paulsherwoodSotK: any ideas on this? https://github.com/devcurmudgeon/ybd/issues/6405:24
*** petefoth has joined #baserock06:23
*** edcragg has joined #baserock06:41
*** zoli__ has quit IRC06:48
*** a1exhughe5 has joined #baserock07:06
*** zoli__ has joined #baserock07:11
straycatpaulsherwood, the fstab.configure extension and hosts.configure extensions depend on morphlib07:24
*** rdale has joined #baserock07:32
*** edcragg has quit IRC07:48
straycatpaulsherwood, http://sprunge.us/Kbfi07:50
*** gary_perkins has joined #baserock07:53
*** mariaderidder has joined #baserock07:55
petefoth https://mason-x86-64.baserock.org is currently red :(07:57
pedroalvarezpetefoth: as expected08:04
pedroalvarezfinally :)08:04
petefothpedroalvarez: that's allright then :)08:05
SotKpaulsherwood: the baserock/adamcoldrick/remove-dependencies branch of definitions on git.b.o may be interesting to you :)08:06
*** bashrc has joined #baserock08:07
pedroalvarezI wonder if we have fixed in master this distbuild issue where chunks are built multiple times08:09
paulsherwoodSotK: how do we get that into master?08:13
*** sambishop has joined #baserock08:13
SotKpaulsherwood: persuade someone to review and merge the branch I linked in my mail to the list first, then send the extra commit in the branch I just mentioned to Gerrit08:14
SotKbut I need to do a Baserock release between those steps08:15
SotK(which must contain morph with my "setting PYTHONPATH" patch)08:15
straycatwtf , why would you randomly remove cliapp from the extensions08:19
*** edcragg has joined #baserock08:20
*** zoli__ has quit IRC08:20
SotKstraycat: see https://github.com/devcurmudgeon/ybd/issues/29 which is where the "move extensions into definitions and remove dependencies" came from08:26
straycatoh right, so shall we get rid of jinja2, and anything else that's remotely useful because it's not including in python?08:28
rjekhah08:28
straycat*included08:28
* SotK thinks that the only two other external dependencies are jinja2 and keystoneclient, which are more widely used than cliapp I guess?08:31
straycatyeah, you still haven't given me a good reason to remove cliapp08:31
SotK(and can be obtained by `pip install` if you are so inclined)08:31
straycatwhy the fuck do i care about installing with pip in baserock?08:32
SotKwe may want to use definitions outside of baserock08:33
SotKif the extensions all depend on cliapp, then running them outside of a baserock VM means you need to find and install cliapp manually (or `apt-get install` it on debian)08:33
straycatoh my08:33
paulsherwoodstraycat: please calm down, there may be children present :)08:33
straycatthat does sound difficult08:33
* straycat is still waiting for a good reason to remove cliapp08:33
* rjek throws toys out of his pram08:33
SotKstraycat: it might not be difficult, but it is inconvenient08:34
paulsherwoodstraycat: to make deplyoment more widely useful than just baserock08:35
paulsherwoodwith minimum frictino08:35
straycati could have cliapp on pip within the hour if i wanted, your point is moot08:35
paulsherwoodit's not. cliapp has been NOT in pip for nearly four years. causing friction08:35
paulsherwoodi'm trying to expand the usability of baserock outside baserock, i think that's wortwhile08:36
straycatokay, there's *still* no good technical reason to remove cliapp08:37
paulsherwoodno, that's not true either. it's an *unnecessary* dependency is a valid reason imo08:38
straycatoh yeah good point, we could rewrite the bits of cliapp we need instead of helping upstream improve them08:38
straycatunless open source is about helping upstreams ofcourse08:38
paulsherwoodwe can agree to disagree on this, perhaps.08:38
KinnisonIt's clearly necessary or the branch wouldn't pull bits of cliapp in08:38
*** zoli__ has joined #baserock08:39
KinnisonHowever, I don't have the brain bandwidth to get involved in this particular "discussion" so will say no more08:39
paulsherwoodi could extend that to 'morph is necessary because....' but i don't think that makes it true08:39
straycati also should get on with other stuff, pretty sure it's clear how i feel about this change now08:40
paulsherwoodyup, me too :)08:40
rjekThe C library's beginning to look redundant, too08:46
paulsherwoodheh08:48
tlsaThe reasons for choosing dependencies don't have to be technical.  They can be political, or practical.  Using unusual deps which aren't packaged in "the normal way" can and does put some people off, even if its not tecnically difficult.  (I've seen this a lot on my own projects.)08:49
paulsherwoodSotK: has anyone -1 your patches? i cant see gerrit at the moment08:49
SotKpaulsherwood: which patches?08:52
paulsherwoodSotK: 09:14 < SotK> paulsherwood: persuade someone to review and merge the branch I linked in my mail to the list first,08:53
SotKpaulsherwood: that branch isn't on Gerrit, since it contains merge commits of history which isn't in the repo on Gerrit (and I don't think that sending such merge commits will end well)08:54
* pedroalvarez understood that as a massive patch that cannot be sent to gerrit/mail list, but has been linked in an email08:54
*** Guest86040 is now known as fay_08:54
paulsherwoodright. i'm willing to review it, but i'm clearly biassed.08:55
paulsherwoodmaybe i shouldn't do so08:55
paulsherwoodany volunteers?08:55
KinnisonIf it's somewhere I *can* review it, I shall08:56
paulsherwoodSotK: link to email, please?08:56
SotKKinnison: baserock/adamcoldrick/writeexts-in-definitions in definitions on git.baserock.org08:57
SotKhttp://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-June/013085.html08:57
Kinnisonexcellent08:57
* Kinnison shall get to that momentarily08:57
paulsherwoodanyone else? i could maybe ask radiofree08:57
paulsherwoodor jjardon08:58
paulsherwood(i'm working with them today)08:58
* SotK should have mentioned that its important that the reviewers make sure the imported history is sane08:58
*** ssam2 has joined #baserock09:04
*** ChanServ sets mode: +v ssam209:04
*** lachlanmackenzie has joined #baserock09:10
edcraggssam2: i missed your ping yesterday, all the commits on gerrit are providing support for Altera Cyclone V development kit09:57
*** pacon has joined #baserock10:00
ssam2edcragg: will they need any ongoing maintenance, and is there a plan for that?10:01
ssam2I take it to do maintenance one would need access to one of those dev kits?10:01
franredwdutch, are you working on firehose? I saw you are looking at https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/firehose+branch:master+topic:bmottram/firehose changes10:13
wdutchfranred: yup; I'm trying to go through them10:15
franredwdutch, ok, give me a shout if you need some of them to be merge when they get reviewed10:16
wdutchfranred: okay thanks :)10:16
edcraggssam2: it would need maintenance as much as any system. The board was supposed to be returned to Altera, but they aren't vastly difficult to obtain. No plan as such, as far as i know, though10:17
edcraggyou would need a dev kit for maintenance, as the hardware is rather specific10:18
ssam2OK. That makes me wonder if it belongs in the reference system definitions, or somewhere else10:18
edcraggsales wanted upstream support10:19
ssam2I feel like when we merge something to definitions, we are making a commitment to at least try and support it. But without access to the hardware, I certainly can't make that commitment10:19
ssam2if you can commit to try and support it, fine10:19
*** mdunford has joined #baserock10:20
ssam2this isn't the only time we've hit this problem... there are other things in definitions that are basically unmaintained10:20
ssam2but at some point, we need to be clear about whether definitions.git is a set of definitions that are tested and working, or dumping ground for things we don't even have the capability to test10:21
wdutchfranred: gerrit.baserock.org/#/c/160/ is good to be merged imo10:21
edcraggssam2: besides that, there are also changes to morph that aren't platform specific10:21
ssam2edcragg: yeah, I think those can be considered separately10:22
ssam2although there's work in progress to move the .write extension code into definitions.git, which kind of blocks reviewing those patches10:22
pedroalvarezI wonder if we can have a separate set of systems that are not the maintained reference systems10:22
paulsherwoodssam2: i've previously sgugested we could have branches in definitions... there could be a branch for rocketboard for exampkle?10:23
pedroalvarezso, in definitions, but making clear that they were working at the time they were merged, but we are not actively maintaining  them10:23
franredwdutch, done10:23
wdutchta10:23
franredwdutch, I trust you are testing this patches10:24
edcragga branch sounds sensible to me10:25
* richard_maw doesn't like branches, but also doesn't have the time to justify it at this point10:31
kejiahu_which chunk provides system-version-manager?10:32
pedroalvarezkejiahu_: tbdiff10:34
wdutchfranred: firehose doesn't work for me but I'm under the impression firehose doesn't work yet - I'm checking it by making small cliapp apps and ensuring the code works in isolation, maybe this is the wrong thing to do?10:34
kejiahu_pedroalvarez: thanks#10:35
franredwdutch, Im fine with that - making it work would be nice for us10:37
wdutchheh, don't get your hopes up, I'm a little out of my depth10:38
franredkejiahu_, you could check next time in a baserock system `grep $what_ever_I_want_to_know_get_installed_in_baserock /baserock/*`10:38
franredwdutch, things get made doing little steps ;-)10:39
kejiahu_franred: thanks for the tips :)10:40
ssam2paulsherwood: that seems like abuse of git branches to me10:41
ssam2paulsherwood:  i'd get very confused if there were lots of different branches in different states that all did different things10:42
ssam2one separate branch for 'contrib' definitions, perhaps10:42
ssam2or a separate repo10:42
ssam2or even just a separate dir in definitions10:43
ssam2systems/examples/ perhaps10:43
pedroalvarezsomething like systems/examples is what I have suggested before10:43
mdunfordssam2: I'm trying to find out what it means for a system definition to be listed here http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/systems is it explained somewhere?10:46
jjardonmaybe a new folder systems/other or systems/contrib for the systems that are not actively maintained?10:50
jmacsWhen a morph build fails, should I be able to chroot into the /src/tmp/failed/tmpsomething directory and repeat the commands?10:51
jmacsI did that, and the version of make in /tools/bin appears to be broken10:52
jjardonmdunford: My understanding is that there are example systems that build and run at some point. The only ones we can be sure that still build in current master of definitions are the ones listed in http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/clusters/ci.morph10:53
ssam2jmacs: is it a stage1- or stage2- chunk?10:55
ssam2mdunford: it's not really explained formally, I would like to explain it somewhere10:55
ssam2http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/README is probably the place10:55
mdunfordssam2: jjardon: It would be good if it was explained, so that when trying to contribute to definitions.git we can know beforehand how to comply :)10:56
rdalejmacs: did you bind mount /dev /proc and /tmp - if you don't make seg faults?10:57
mdunfordjjardon: thanks10:57
jmacsrdale: That's probably what I need to do10:57
jjardonmdunford: maybe we can add a README to the systems/ directory, fancy send a patch? :)10:58
jmacsrdale: Just found the instructions on the wiki, thanks10:59
rdaleok10:59
mdunfordjjardon: You might be waiting a while for that one :p11:00
persiaReading backscroll, I'm a bit concerned about creating a distinction between "maintained" and "unmaintained" reference systems.  To my definition of "maintained", no reference systems are today.11:00
pedroalvarezsome of them have some level of maintenance11:02
jjardonpersia: I try to be sure the weston system in x86 work and is keep up-to-date11:02
persiapedroalvarez: Yes, but none of them are known to work at any given time.11:02
*** wschaller has joined #baserock11:03
persiajjardon: Yes, but that depends on your time, and you've not had time for Baserock for periods in the past.  I'm not sure you want to be asserting that the *project* maintains that, do you?11:03
jjardonI would say the project take some degree on the systems listed in http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/clusters/ci.morph11:06
ssam2persia: fair point that we should quality what "maintained" means given our current level of resources11:06
jjardonsome degree of care*11:06
petefothI guess the project neeeds to decide whether it will commit to maintaining specific systems, and ensurign they continue to work. If they do that, then the distinction between 'maintained' and 'non-maintained' becomes useful. Until then...11:06
persiapetefoth: +111:06
ssam2persia: I still think there's a useful distinction between "systems that are continously built and are known to be used." vs. "we don't even have hardware that could run this system"11:06
ssam2or maybe it makes more sense to note this info in the description field of each system .morph ...11:07
petefothssam2: that *is* a useful distinction, though the second part should be 'vs. anything else'11:07
persiassam2: Were it not for the recent erlang issue, I would likely agree with that.  Given that even for systems that are continuously built, we find massive holes in functionality, I think we need more tests.11:07
ssam2persia: i don't think anyone would deny that we need more tests.11:08
persiajjardon: Yes: the CI systems are in slightly better shape than the others, because they get built.  Whether they are fit for purpose is something else.11:08
persiassam2: Heh, I agree.  My point is that I believe that we need both a) more confidence that the "maintained" systems work, and b) more consensus that the "maintained" systems are important enough to be drop-everything-to-fix within the project before we start claiming the project "maintains" specific systems.11:09
persiaI believe that more tests for systems we want to call "maintained" is part of that.11:09
ssam2so would you prefer I avoid using the term "maintains", when I create a patch for definitions.git today that explains the current state of affairs?11:10
ssam2or would you prefer I avoided making the patch at all?11:11
jmacsrdale: Hmm, no, the thing I found on the wiki is something different. I've done "mount -o bind /dev dev/" in the staging directory, same for tmp and proc, then "chroot .", but still make segfaults11:12
ssam2(I wish I could commit to either improving test infrastructure, or getting some sort of concensus out of the various people who contribute opinions to the Baserock project, but i cannot)11:12
rdalejmacs: i also do /sys: mount -o bind /sys $CHROOT_DIR/sys - maybe it's that?11:13
persiassam2: I'm mostly concerned about the meaning of "maintains".  I'm a fan of single-source information, so I'd rather any documentation referenced ci.morph or similar, rather than annotating systems directly.11:13
jmacsrdale: No luck :(11:14
persiaFor test infrastructure, I think we're mostly blocked on the pre-merge CI stuff.11:14
persiaFor building consensus on how we "support" and/or "maintain" things, I think that will only happen as we gain a wider set of non-developer users who depend on the development team for that maintenance and/or support.11:15
ssam2persia: referencing  ci.morph in README is a good idea11:15
persiaMy fear is that someone will read some definition of things we "support" or "maintain" and falsely believe that this includes our effort to fix bugs in more than specific tools, provide security fixes, etc.11:16
jjardonssam2: I was writing a patch to add systems/README, should I stop? :)11:16
ssam2jjardon: oh, carry on!11:16
ssam2jjardon: but change the top-level README instead, I think11:16
jmacsAny other ideas on how to reproduce a failing command from a morph build?11:21
jmacsssam2: To answer your earlier question, I think it's stage3 of gcc, and I can see stage2 make being unpacked before the build11:21
ssam2jmacs: ok. I asked because the stage1 and stage2 chunks aren't built in a chroot11:22
ssam2but the stage2 chunks should work fine inside the stage3 chroot11:22
jjardonssam2: https://gerrit.baserock.org/83411:23
ssam2ta11:25
*** wschaller_ has joined #baserock11:26
jjardonfranred: do you have a patch to fix the breakage of the erlang stratum or should I work on it?11:27
pedroalvarezjjardon:: he has it, but he hasn't sent it yet11:30
*** wschaller has quit IRC11:30
jjardonpedroalvarez: ack11:31
straycatssam2, i'm run out of arguing tokens today11:35
straycatbut i don't see how a pastebin script gets to be considered "essential"11:35
straycatfrankly i solve this with "alias sprunge="curl -F 'sprunge=<-' http://sprunge.us""11:36
rdalei've got a small lorry patch up for review if anyone could +1 it that would be very welcome: https://gerrit.baserock.org/83311:36
straycat*i've11:36
ssam2straycat: I don't think https://gerrit.baserock.org/#/c/827/ is the ideal solution either, but I can't think of a better one that isn't lots of extra effort for the submitter11:37
ssam2straycat: no need to argue. I have no strong opinion either way11:37
ssam2jmacs: I just discovered the same issue of 'make' segfaulting in a staging chroot11:38
ssam2jmacs: i've not seen it before.11:38
* SotK wishes ybd had something like cache.baserock.org :)11:38
jmacsssam2: OK, I'll have a deeper dig into what's going on.11:39
ssam2jmacs: actually, in this case it's not even a chroot -- it's a linux-user-chroot over '/'11:39
ssam2maybe a bug in make11:39
jmacsIf you run that make outside the chroot, it says "not found", as though it can't find the loader11:41
jmacsBut it doesn't segfault if you manually give it a loader11:41
*** wschaller_ has quit IRC11:42
ssam2ah. in stage3 there is a special ld.so11:42
ssam2which is deliberate, as a way of isolating the stage2 tools both from the host and from the system being built11:43
ssam2not many patches upstream since 4.1, http://git.savannah.gnu.org/cgit/make.git/commit/?id=292da6f6867b75a5af7ddbb639a1feae022f438f is the only one that looks interesting11:43
jmacsssam2: Where is the special ld.so? lib64/ld-2.21.so in the staging directory is identical to the host's one.11:47
ssam2tools/lib/11:47
jmacsok11:48
ssam2the lib64/ld-2.21.so is probably from the stage3 (final) glibc chunk11:48
ssam2http://git.savannah.gnu.org/cgit/make.git/commit/?id=292da6f6867b75a5af7ddbb639a1feae022f438f does indeed fix the segfault I'm experiencing. I'll send a patch for definitions.git11:50
*** pacon has quit IRC11:52
jmacsssam2: Why did we both see that problem? You weren't trying to build gcc with java support, were you?11:54
Zaramaybe we should use some lamps like these with mason... http://www.frisnit.com/internet-of-things-ci-status-lamp/11:55
straycat+2**3211:55
jmacsI think we've actually got some of them in the hackspace11:55
ssam2jmacs: no :)11:56
ssam2jmacs: I was trying to debug a test failure, which involved running `make` manually under linux-user-chroot11:56
ssam2sadly that segfault is not what is causing the test to fail11:56
jmacsOh, I see.11:57
* SotK finds he needs to rebuild from scratch and is sad12:22
SotKwhat happened to Mason?12:23
rdale'passwd' is no longer working in my system, although it was yesterday. i am getting errors about /etc/pam.d/system-auth being missing - what would cause that to not be installed?12:30
kejiahu_has anybody got 'unsupported machine ID' error with Jetson before? http://paste.baserock.org/dapomexoha, bsp built by http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/bsp-jetson.morph with nouveau removed.12:33
*** wschaller has joined #baserock12:34
Kinnisonrdale: sounds like you have shadow but not systemd in your system12:34
Kinnisonrdale: our shadow is set up to take the system-auth PAM configuration from systemd12:35
Kinnisonrdale: You'll need to deposit a suitable system-auth pam.d file into your system in some other manner if you want our shadow build and not systemd12:35
rdalei see, i don't have systemd12:35
rdaledoes shadow have a config option to not use systemd?12:36
KinnisonIt's not "using systemd"12:38
Kinnisonit's expecting a system-auth file to be present which we chose to supply via systemd12:38
rdaleah i see12:38
Kinnisonyou can simply inject a suitable system-auth file yourself, either through whichever chunk is providing your init functionality if it's independent of the rest of the system; or via install-files or similar during deploy12:38
Kinnisoneither will be quite sufficient12:38
rdaleok12:38
Kinnisonif you want a reference point, simply copy system-auth from a running system which has systemd, and remove the systemd specific bits12:39
franredIm trying to push some patches to gerrit and I getting the following error: http://paste.baserock.org/nevuyivuku12:42
franredanyone has any idea why my changes should be in refs/for/master/update-openstack-to-kilo already?12:44
franreds/should be/are/12:44
franredummm looks like I have some commits without Change-Id, I going to try to recreate them and send them again12:55
*** petefoth_ has joined #baserock12:58
*** petefoth has quit IRC12:59
*** petefoth_ is now known as petefoth12:59
franredhttps://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/definitions+branch:master+topic:baserock/update-openstack-to-kilo <-- Patches to update OpenStack to Kilo and fix for the erlang-sd_notify problem (doesn't build because lack of systemd headers)13:00
straycatso pylint gives -ve scores13:12
straycatis it wise to admit i've discovered this?13:12
straycatwell i fixed things and now i'm on 8.14, so i guess it's okay13:13
franredjjardon, you may want to have a look at https://gerrit.baserock.org/#/c/836/ - it fixes mason13:29
franreds/mason/the build error in mason/13:29
* SotK wonders what happened to https://mason-x86-32.baserock.org/13:39
petefothSotK: At least it's not showing red :)13:41
richard_mawprobably ran out of disk space13:42
SotKred would be better than nothing at all13:42
petefothUnlike https://mason-x86-64.baserock.org/13:42
petefoth"2015-06-10 09:01:31 Build of erlang-sd_notify failed."13:43
franredpetefoth, the fix is in gerrit already https://gerrit.baserock.org/#/c/836/13:43
petefothfranred: OK< I'll be quite :)13:43
petefothor evene  quite13:43
petefothnot noisy13:43
*** a1exhughe5 has quit IRC13:45
*** a1exhughe5 has joined #baserock13:58
*** fay_ has quit IRC14:01
* pedroalvarez notes that x86_32 mason doesn't build openstack systems14:04
pedroalvarezthus, no erlang14:05
pedroalvarezbut yes... 50314:05
ssam2sorry, i did spot earlier that but didn't look at it yet14:08
pedroalvarezshould be fixed now14:08
ssam2cool!14:08
pedroalvarezbuilding from stage1-binutils though14:08
*** fay has joined #baserock14:17
*** fay is now known as Guest1418014:17
*** petefoth has quit IRC14:19
jjardonthat's look correct, that chunk was updated today14:19
pedroalvarez:)14:22
*** wschaller_ has joined #baserock14:37
*** wschaller has quit IRC14:41
jmacsssam2: You said that revision 292da6f6 of make fixed your issue - how did you use that patch? Did you just change the ref to 292da6f6 and change the repo to git.sv.gnu.org, or do you have some way of cherry-picking fixes into definitions?14:55
ssam2I cherry-picked it into a branch of the the make-tarball repo on git.baserock.org14:55
ssam2which is easy to do if you have push access there14:55
ssam2i'm happy to give you push access there if you need to do that sort of thing in future14:56
ssam2well, to test the fix I just did 'git clone' of make-tarball.git locally, then did 'make install' in my chroot14:57
ssam2once that worked, I made a branch of make-tarball.git and did a patch for definitions14:57
jmacsI don't have git inside my chroot; I'll have to wget it15:02
jmacsActually, what is make-tarball.git? I thought it'd be something with a binary version of make in it15:05
ssam2it's a release tarball of make15:05
ssam2because make is super early in the build process, it's impractical to build it from the git repo15:05
ssam2it's created by Lorry; the make-4.1 tag is the make-4.1.tar.gz tarball15:05
ssam2i'm not sure what 'master' is :)15:05
Kinnisonfor tarball imports it's usually the most recent tarball imported15:06
ssam2ah, so the same thing in this case15:06
*** Guest14180 is now known as fay_15:06
jmacsHow do you build it without make?15:07
Kinnisonmake has a shell script in it IIRC15:07
ssam2stage2-make builds make15:07
KinnisonOh, we do it that way15:07
Kinnison:)15:07
ssam2the host system's make builds stage2-make, as stage2-make is a 'bootstrap' mode chunk15:07
*** pedroalvarez_ has joined #baserock15:11
*** ChanServ sets mode: +v pedroalvarez_15:11
*** pedroalvarez has quit IRC15:14
jmacsMaybe it's the heat, but I'm completely lost by what you just said. How can stage2-make make another make unless definitions knows about an alternative version of make?15:14
KinnisonThe host system has a make binary. (call it host-make)15:15
perryli'm trying to run YBD while including a function to set a fake build time via libfaketime, but i'm getting an error and the following log: http://paste.baserock.org/qezupapuro; can anyone tell what's going wrong?15:15
KinnisonIn bootstrap mode, the stage2-make chunk is built using host-make15:15
*** pedroalvarez_ is now known as pedroalvarez15:15
KinnisonThen, the real make chunk is built, using stage2-make15:15
KinnisonIs that any clearer?15:16
jmacsYes but it doesn't get me any closer to a working make15:16
jmacsUnless I'm meant to make make-tarball outside the chroot15:16
KinnisonAre you not using Baserock's build-essential definition?15:16
jmacsYes, and that one produces a broken make15:17
KinnisonOkay, I'm lost too now :(15:17
ssam2jmacs: what is your goal?15:25
jmacsDebug why gcc doesn't build when you specify --enable-languages=java15:25
ssam2so you're debugging *inside* the failed staging chroot of 'gcc'?15:26
jmacsYes15:26
ssam2you should be able to build a fixed make outside the chroot then, and copy it in15:27
jmacsThe host's make works fine outside the chroot, but not inside it15:27
jmacsBut does it also need that fix?15:27
ssam2I doubt it.15:28
ssam2I don't think we've established whether the fact that it fixed a segfault for me means it'll solve your problem15:28
jmacsI can't cherry pick that fix for make-tarball anyway15:29
jmacsDoesn't appear to be in git.baserock.org's version15:29
ssam2git.baserock.org's make.git is actually an import of a now-obsolete Bzr repo on Launchpad that the GNU Make project used to use15:29
paulsherwoodperryl: maybe ssam2 can help with that - it looks like sometihng might be trying fiddle with the sandboxed area?15:30
ssam2I wish there was a clear way to mark it as such15:30
ssam2it's in make-tarball.git in branch baserock/make-4.1-ttyname-segfault-fix15:30
ssam2(or some such name)15:30
ssam2there's also a patch for definitions that uses that branch which you could test out: https://gerrit.baserock.org/#/c/835/ and rebuild15:30
ssam2perryl: sorry, I missed your question15:30
jmacsRight, that looks good15:31
perrylssam2: i'm trying to run YBD while including a function to set a fake build time via libfaketime, but i'm getting an error and the following log: http://paste.baserock.org/qezupapuro; can anyone tell what's going wrong?15:31
ssam2hmm.. not sure15:32
ssam2the same command works without the added faketime bit?15:32
perryli have no idea if it's linked to the faketime part actually; i just know that before adding it in the build worked, and after i got the read only filesystem issue15:32
ssam2ok15:32
ssam2sandboxlib logs the full command it is running with the python logging module15:33
ssam2you could add two lines to the ybd code to make it put that info on stdout:15:33
ssam2import logging, sys15:33
ssam2logging.basicConfig(stream=sys.stdout, level=logging.DEBUG)15:33
ssam2i'll try help you out in person in a bit, i'm looking at a (weirdly similar) problem right now15:34
perrylssam2: no worries, i'll try removing the parts i added and adding logging and see what changes!15:35
*** a1exhughe5 has quit IRC15:38
*** wschaller has joined #baserock15:53
*** wschaller_ has quit IRC15:53
*** jonathanmaw has quit IRC16:04
*** zoli___ has joined #baserock16:17
*** zoli__ has quit IRC16:18
*** wschaller_ has joined #baserock16:34
*** wschaller has quit IRC16:37
perrylhmm...after a fair bit of faff and figuring out what wrong changes i'd made, i'm now getting ValueError: I/O operation on closed file when running YBD16:39
* perryl checks with master again to be sure16:39
richard_mawperryl: double close because it was opened from a context manager then returned?16:40
perrylrichard_maw: could be :/ it's an error i've introduced to be sure..though master also fails due to no "executor_for_platform" in sandboxlib16:41
paulsherwoodmaster ybd fails?16:41
perrylyes16:43
perryli'll have a look to see if anything is logged16:43
ssam2perryl: what version of sandboxlib are you using?16:45
ssam2you may need to update16:45
perrylssam2: which is the latest version16:46
perryl?16:46
ssam20.3.016:46
ssam2it's on https://pypi.python.org/pypi/sandboxlib16:46
perrylwhoa, yeah i was on 0.1.116:46
paulsherwoodssam2: btw... any chance we could have one line of  Setting up sandbox using <module 'sandboxlib.linux_user_chroot' from '/usr/lib/python2.7/site-packages/sandboxlib/linux_user_chroot.pyc'> rather than a couple of hundred? :)16:48
*** mariaderidder has quit IRC16:49
ssam2paulsherwood: as in, you want the message to be printed once per process, rather than once per call to run_sandbox() ?16:54
ssam2if so, yes16:55
paulsherwoodssam2: yup. once per run of ybd, ideally i think?16:56
paulsherwoodunless we believe that the content could change during a run?16:57
ssam2easy enough. although if someone installs linux-user-chroot half-way through a build, it will not be accurate ;)16:57
ssam2so, it could change, but it is very unlikely16:57
paulsherwoodinteresting. do we need to close that hole?16:57
ssam2actually, yes :)16:58
paulsherwoodeasy to do?16:58
ssam2it should just pick the backend once on startup anyway16:58
ssam2i'll send a patch16:58
paulsherwoodok great16:58
kejiahu_has anybody tried deploy baserock as update on jetson board recently? it fails for me on master. http://paste.baserock.org/dapomexoha. Another question, does moving extensions to a sub-directory under definitions means they should be independent to morphlib? it seems some extensions are still importing morphlib, and some are loading files for position doesn't exists16:58
*** bashrc has quit IRC17:02
ssam2kejiahu_: I think you have lost the device tree (DTB_FILE) in your updated version17:03
ssam2the extensions move is a work in progress by SotK, I'm not sure the state of it myself17:04
kejiahu_ssam2: thanks, but it was built from the reference definition in master, I don't expected it to miss that...http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/systems/devel-system-armv7lhf-jetson.morph17:08
ssam2how was it deployed?17:11
ssam2the cluster .morph file you used to upgrade needs to have DTB_FILE set17:12
ssam2clusters/jetson-update.morph gives an example17:12
*** mdunford has quit IRC17:13
kejiahu_ssam2: yes, I used that as reference, this is my cluster http://paste.baserock.org/abowayosup17:14
kejiahu_ssam2: I only changed the name, and also added VERSION_LABLE on, as it's required by update17:14
SotKkejiahu_: some are still dependent on morphlib sadly17:22
SotKI'm working on solving that this week, see the "Moving morphlib/writeexts.py into definitions" email thread on baserock-dev17:23
radiofreecan baserock deploy using/to openstack ironic?17:24
kejiahu_SotK: thanks for clarify that :)17:24
*** ssam2 has quit IRC17:25
kejiahu_radiofree: ironic is deploying in a very similar way as moonshot m2 deployment. with some modification, I'd expected baserock deploy to be used to ironic17:27
radiofreekejiahu_: you did some work on it right? is it all upstream?17:30
radiofreei.e does morph support deployment to ironic? or is it in some branch somewhere17:30
radiofrees/to/using/17:31
kejiahu_radiofree: morph doesn't support deployment using ironic currently, they cluster to deploy for moonshot m2 deployment was upstreamed, it was done by edcragg17:33
radiofreethanks kejiahu_17:33
kejiahu_radiofree: tiago got some success on using ironic to deploy on x86, but we haven't got it on arm yet17:34
kejiahu_radiofree:  :)17:34
*** edcragg has quit IRC17:41
*** wschaller_ has quit IRC17:42
SotKkejiahu_: no problem17:44
*** gary_perkins has quit IRC18:26
*** lachlanmackenzie has quit IRC18:37
*** edcragg has joined #baserock19:08
*** zoli___ has quit IRC20:47
*** zoli__ has joined #baserock21:44
*** zoli___ has joined #baserock21:48
*** zoli__ has quit IRC21:48
*** zoli___ has quit IRC22:21
*** edcragg has quit IRC23:26
*** edcragg has joined #baserock23:36

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