*** zoli__ has joined #baserock | 02:26 | |
paulsherwood | SotK: any ideas on this? https://github.com/devcurmudgeon/ybd/issues/64 | 05:24 |
---|---|---|
*** petefoth has joined #baserock | 06:23 | |
*** edcragg has joined #baserock | 06:41 | |
*** zoli__ has quit IRC | 06:48 | |
*** a1exhughe5 has joined #baserock | 07:06 | |
*** zoli__ has joined #baserock | 07:11 | |
straycat | paulsherwood, the fstab.configure extension and hosts.configure extensions depend on morphlib | 07:24 |
*** rdale has joined #baserock | 07:32 | |
*** edcragg has quit IRC | 07:48 | |
straycat | paulsherwood, http://sprunge.us/Kbfi | 07:50 |
*** gary_perkins has joined #baserock | 07:53 | |
*** mariaderidder has joined #baserock | 07:55 | |
petefoth | https://mason-x86-64.baserock.org is currently red :( | 07:57 |
pedroalvarez | petefoth: as expected | 08:04 |
pedroalvarez | finally :) | 08:04 |
petefoth | pedroalvarez: that's allright then :) | 08:05 |
SotK | paulsherwood: the baserock/adamcoldrick/remove-dependencies branch of definitions on git.b.o may be interesting to you :) | 08:06 |
*** bashrc has joined #baserock | 08:07 | |
pedroalvarez | I wonder if we have fixed in master this distbuild issue where chunks are built multiple times | 08:09 |
paulsherwood | SotK: how do we get that into master? | 08:13 |
*** sambishop has joined #baserock | 08:13 | |
SotK | paulsherwood: 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 Gerrit | 08:14 |
SotK | but I need to do a Baserock release between those steps | 08:15 |
SotK | (which must contain morph with my "setting PYTHONPATH" patch) | 08:15 |
straycat | wtf , why would you randomly remove cliapp from the extensions | 08:19 |
*** edcragg has joined #baserock | 08:20 | |
*** zoli__ has quit IRC | 08:20 | |
SotK | straycat: see https://github.com/devcurmudgeon/ybd/issues/29 which is where the "move extensions into definitions and remove dependencies" came from | 08:26 |
straycat | oh right, so shall we get rid of jinja2, and anything else that's remotely useful because it's not including in python? | 08:28 |
rjek | hah | 08:28 |
straycat | *included | 08: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 | |
straycat | yeah, you still haven't given me a good reason to remove cliapp | 08:31 |
SotK | (and can be obtained by `pip install` if you are so inclined) | 08:31 |
straycat | why the fuck do i care about installing with pip in baserock? | 08:32 |
SotK | we may want to use definitions outside of baserock | 08:33 |
SotK | if 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 |
straycat | oh my | 08:33 |
paulsherwood | straycat: please calm down, there may be children present :) | 08:33 |
straycat | that does sound difficult | 08:33 |
* straycat is still waiting for a good reason to remove cliapp | 08:33 | |
* rjek throws toys out of his pram | 08:33 | |
SotK | straycat: it might not be difficult, but it is inconvenient | 08:34 |
paulsherwood | straycat: to make deplyoment more widely useful than just baserock | 08:35 |
paulsherwood | with minimum frictino | 08:35 |
straycat | i could have cliapp on pip within the hour if i wanted, your point is moot | 08:35 |
paulsherwood | it's not. cliapp has been NOT in pip for nearly four years. causing friction | 08:35 |
paulsherwood | i'm trying to expand the usability of baserock outside baserock, i think that's wortwhile | 08:36 |
straycat | okay, there's *still* no good technical reason to remove cliapp | 08:37 |
paulsherwood | no, that's not true either. it's an *unnecessary* dependency is a valid reason imo | 08:38 |
straycat | oh yeah good point, we could rewrite the bits of cliapp we need instead of helping upstream improve them | 08:38 |
straycat | unless open source is about helping upstreams ofcourse | 08:38 |
paulsherwood | we can agree to disagree on this, perhaps. | 08:38 |
Kinnison | It's clearly necessary or the branch wouldn't pull bits of cliapp in | 08:38 |
*** zoli__ has joined #baserock | 08:39 | |
Kinnison | However, I don't have the brain bandwidth to get involved in this particular "discussion" so will say no more | 08:39 |
paulsherwood | i could extend that to 'morph is necessary because....' but i don't think that makes it true | 08:39 |
straycat | i also should get on with other stuff, pretty sure it's clear how i feel about this change now | 08:40 |
paulsherwood | yup, me too :) | 08:40 |
rjek | The C library's beginning to look redundant, too | 08:46 |
paulsherwood | heh | 08:48 |
tlsa | The 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 |
paulsherwood | SotK: has anyone -1 your patches? i cant see gerrit at the moment | 08:49 |
SotK | paulsherwood: which patches? | 08:52 |
paulsherwood | SotK: 09:14 < SotK> paulsherwood: persuade someone to review and merge the branch I linked in my mail to the list first, | 08:53 |
SotK | paulsherwood: 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 email | 08:54 | |
*** Guest86040 is now known as fay_ | 08:54 | |
paulsherwood | right. i'm willing to review it, but i'm clearly biassed. | 08:55 |
paulsherwood | maybe i shouldn't do so | 08:55 |
paulsherwood | any volunteers? | 08:55 |
Kinnison | If it's somewhere I *can* review it, I shall | 08:56 |
paulsherwood | SotK: link to email, please? | 08:56 |
SotK | Kinnison: baserock/adamcoldrick/writeexts-in-definitions in definitions on git.baserock.org | 08:57 |
SotK | http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-June/013085.html | 08:57 |
Kinnison | excellent | 08:57 |
* Kinnison shall get to that momentarily | 08:57 | |
paulsherwood | anyone else? i could maybe ask radiofree | 08:57 |
paulsherwood | or jjardon | 08: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 sane | 08:58 | |
*** ssam2 has joined #baserock | 09:04 | |
*** ChanServ sets mode: +v ssam2 | 09:04 | |
*** lachlanmackenzie has joined #baserock | 09:10 | |
edcragg | ssam2: i missed your ping yesterday, all the commits on gerrit are providing support for Altera Cyclone V development kit | 09:57 |
*** pacon has joined #baserock | 10:00 | |
ssam2 | edcragg: will they need any ongoing maintenance, and is there a plan for that? | 10:01 |
ssam2 | I take it to do maintenance one would need access to one of those dev kits? | 10:01 |
franred | wdutch, 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 changes | 10:13 |
wdutch | franred: yup; I'm trying to go through them | 10:15 |
franred | wdutch, ok, give me a shout if you need some of them to be merge when they get reviewed | 10:16 |
wdutch | franred: okay thanks :) | 10:16 |
edcragg | ssam2: 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, though | 10:17 |
edcragg | you would need a dev kit for maintenance, as the hardware is rather specific | 10:18 |
ssam2 | OK. That makes me wonder if it belongs in the reference system definitions, or somewhere else | 10:18 |
edcragg | sales wanted upstream support | 10:19 |
ssam2 | I 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 commitment | 10:19 |
ssam2 | if you can commit to try and support it, fine | 10:19 |
*** mdunford has joined #baserock | 10:20 | |
ssam2 | this isn't the only time we've hit this problem... there are other things in definitions that are basically unmaintained | 10:20 |
ssam2 | but 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 test | 10:21 |
wdutch | franred: gerrit.baserock.org/#/c/160/ is good to be merged imo | 10:21 |
edcragg | ssam2: besides that, there are also changes to morph that aren't platform specific | 10:21 |
ssam2 | edcragg: yeah, I think those can be considered separately | 10:22 |
ssam2 | although there's work in progress to move the .write extension code into definitions.git, which kind of blocks reviewing those patches | 10:22 |
pedroalvarez | I wonder if we can have a separate set of systems that are not the maintained reference systems | 10:22 |
paulsherwood | ssam2: i've previously sgugested we could have branches in definitions... there could be a branch for rocketboard for exampkle? | 10:23 |
pedroalvarez | so, in definitions, but making clear that they were working at the time they were merged, but we are not actively maintaining them | 10:23 |
franred | wdutch, done | 10:23 |
wdutch | ta | 10:23 |
franred | wdutch, I trust you are testing this patches | 10:24 |
edcragg | a branch sounds sensible to me | 10:25 |
* richard_maw doesn't like branches, but also doesn't have the time to justify it at this point | 10:31 | |
kejiahu_ | which chunk provides system-version-manager? | 10:32 |
pedroalvarez | kejiahu_: tbdiff | 10:34 |
wdutch | franred: 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 |
franred | wdutch, Im fine with that - making it work would be nice for us | 10:37 |
wdutch | heh, don't get your hopes up, I'm a little out of my depth | 10:38 |
franred | kejiahu_, you could check next time in a baserock system `grep $what_ever_I_want_to_know_get_installed_in_baserock /baserock/*` | 10:38 |
franred | wdutch, things get made doing little steps ;-) | 10:39 |
kejiahu_ | franred: thanks for the tips :) | 10:40 |
ssam2 | paulsherwood: that seems like abuse of git branches to me | 10:41 |
ssam2 | paulsherwood: i'd get very confused if there were lots of different branches in different states that all did different things | 10:42 |
ssam2 | one separate branch for 'contrib' definitions, perhaps | 10:42 |
ssam2 | or a separate repo | 10:42 |
ssam2 | or even just a separate dir in definitions | 10:43 |
ssam2 | systems/examples/ perhaps | 10:43 |
pedroalvarez | something like systems/examples is what I have suggested before | 10:43 |
mdunford | ssam2: 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 |
jjardon | maybe a new folder systems/other or systems/contrib for the systems that are not actively maintained? | 10:50 |
jmacs | When a morph build fails, should I be able to chroot into the /src/tmp/failed/tmpsomething directory and repeat the commands? | 10:51 |
jmacs | I did that, and the version of make in /tools/bin appears to be broken | 10:52 |
jjardon | mdunford: 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.morph | 10:53 |
ssam2 | jmacs: is it a stage1- or stage2- chunk? | 10:55 |
ssam2 | mdunford: it's not really explained formally, I would like to explain it somewhere | 10:55 |
ssam2 | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/README is probably the place | 10:55 |
mdunford | ssam2: 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 |
rdale | jmacs: did you bind mount /dev /proc and /tmp - if you don't make seg faults? | 10:57 |
mdunford | jjardon: thanks | 10:57 |
jmacs | rdale: That's probably what I need to do | 10:57 |
jjardon | mdunford: maybe we can add a README to the systems/ directory, fancy send a patch? :) | 10:58 |
jmacs | rdale: Just found the instructions on the wiki, thanks | 10:59 |
rdale | ok | 10:59 |
mdunford | jjardon: You might be waiting a while for that one :p | 11:00 |
persia | Reading 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 |
pedroalvarez | some of them have some level of maintenance | 11:02 |
jjardon | persia: I try to be sure the weston system in x86 work and is keep up-to-date | 11:02 |
persia | pedroalvarez: Yes, but none of them are known to work at any given time. | 11:02 |
*** wschaller has joined #baserock | 11:03 | |
persia | jjardon: 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 |
jjardon | I 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.morph | 11:06 |
ssam2 | persia: fair point that we should quality what "maintained" means given our current level of resources | 11:06 |
jjardon | some degree of care* | 11:06 |
petefoth | I 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 |
persia | petefoth: +1 | 11:06 |
ssam2 | persia: 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 |
ssam2 | or maybe it makes more sense to note this info in the description field of each system .morph ... | 11:07 |
petefoth | ssam2: that *is* a useful distinction, though the second part should be 'vs. anything else' | 11:07 |
persia | ssam2: 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 |
ssam2 | persia: i don't think anyone would deny that we need more tests. | 11:08 |
persia | jjardon: 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 |
persia | ssam2: 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 |
persia | I believe that more tests for systems we want to call "maintained" is part of that. | 11:09 |
ssam2 | so 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 |
ssam2 | or would you prefer I avoided making the patch at all? | 11:11 |
jmacs | rdale: 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 segfaults | 11: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 |
rdale | jmacs: i also do /sys: mount -o bind /sys $CHROOT_DIR/sys - maybe it's that? | 11:13 |
persia | ssam2: 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 |
jmacs | rdale: No luck :( | 11:14 |
persia | For test infrastructure, I think we're mostly blocked on the pre-merge CI stuff. | 11:14 |
persia | For 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 |
ssam2 | persia: referencing ci.morph in README is a good idea | 11:15 |
persia | My 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 |
jjardon | ssam2: I was writing a patch to add systems/README, should I stop? :) | 11:16 |
ssam2 | jjardon: oh, carry on! | 11:16 |
ssam2 | jjardon: but change the top-level README instead, I think | 11:16 |
jmacs | Any other ideas on how to reproduce a failing command from a morph build? | 11:21 |
jmacs | ssam2: To answer your earlier question, I think it's stage3 of gcc, and I can see stage2 make being unpacked before the build | 11:21 |
ssam2 | jmacs: ok. I asked because the stage1 and stage2 chunks aren't built in a chroot | 11:22 |
ssam2 | but the stage2 chunks should work fine inside the stage3 chroot | 11:22 |
jjardon | ssam2: https://gerrit.baserock.org/834 | 11:23 |
ssam2 | ta | 11:25 |
*** wschaller_ has joined #baserock | 11:26 | |
jjardon | franred: do you have a patch to fix the breakage of the erlang stratum or should I work on it? | 11:27 |
pedroalvarez | jjardon:: he has it, but he hasn't sent it yet | 11:30 |
*** wschaller has quit IRC | 11:30 | |
jjardon | pedroalvarez: ack | 11:31 |
straycat | ssam2, i'm run out of arguing tokens today | 11:35 |
straycat | but i don't see how a pastebin script gets to be considered "essential" | 11:35 |
straycat | frankly i solve this with "alias sprunge="curl -F 'sprunge=<-' http://sprunge.us"" | 11:36 |
rdale | i've got a small lorry patch up for review if anyone could +1 it that would be very welcome: https://gerrit.baserock.org/833 | 11:36 |
straycat | *i've | 11:36 |
ssam2 | straycat: 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 submitter | 11:37 |
ssam2 | straycat: no need to argue. I have no strong opinion either way | 11:37 |
ssam2 | jmacs: I just discovered the same issue of 'make' segfaulting in a staging chroot | 11:38 |
ssam2 | jmacs: i've not seen it before. | 11:38 |
* SotK wishes ybd had something like cache.baserock.org :) | 11:38 | |
jmacs | ssam2: OK, I'll have a deeper dig into what's going on. | 11:39 |
ssam2 | jmacs: actually, in this case it's not even a chroot -- it's a linux-user-chroot over '/' | 11:39 |
ssam2 | maybe a bug in make | 11:39 |
jmacs | If you run that make outside the chroot, it says "not found", as though it can't find the loader | 11:41 |
jmacs | But it doesn't segfault if you manually give it a loader | 11:41 |
*** wschaller_ has quit IRC | 11:42 | |
ssam2 | ah. in stage3 there is a special ld.so | 11:42 |
ssam2 | which is deliberate, as a way of isolating the stage2 tools both from the host and from the system being built | 11:43 |
ssam2 | not many patches upstream since 4.1, http://git.savannah.gnu.org/cgit/make.git/commit/?id=292da6f6867b75a5af7ddbb639a1feae022f438f is the only one that looks interesting | 11:43 |
jmacs | ssam2: Where is the special ld.so? lib64/ld-2.21.so in the staging directory is identical to the host's one. | 11:47 |
ssam2 | tools/lib/ | 11:47 |
jmacs | ok | 11:48 |
ssam2 | the lib64/ld-2.21.so is probably from the stage3 (final) glibc chunk | 11:48 |
ssam2 | http://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.git | 11:50 |
*** pacon has quit IRC | 11:52 | |
jmacs | ssam2: Why did we both see that problem? You weren't trying to build gcc with java support, were you? | 11:54 |
Zara | maybe we should use some lamps like these with mason... http://www.frisnit.com/internet-of-things-ci-status-lamp/ | 11:55 |
straycat | +2**32 | 11:55 |
jmacs | I think we've actually got some of them in the hackspace | 11:55 |
ssam2 | jmacs: no :) | 11:56 |
ssam2 | jmacs: I was trying to debug a test failure, which involved running `make` manually under linux-user-chroot | 11:56 |
ssam2 | sadly that segfault is not what is causing the test to fail | 11:56 |
jmacs | Oh, I see. | 11:57 |
* SotK finds he needs to rebuild from scratch and is sad | 12:22 | |
SotK | what 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 #baserock | 12:34 | |
Kinnison | rdale: sounds like you have shadow but not systemd in your system | 12:34 |
Kinnison | rdale: our shadow is set up to take the system-auth PAM configuration from systemd | 12:35 |
Kinnison | rdale: 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 systemd | 12:35 |
rdale | i see, i don't have systemd | 12:35 |
rdale | does shadow have a config option to not use systemd? | 12:36 |
Kinnison | It's not "using systemd" | 12:38 |
Kinnison | it's expecting a system-auth file to be present which we chose to supply via systemd | 12:38 |
rdale | ah i see | 12:38 |
Kinnison | you 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 deploy | 12:38 |
Kinnison | either will be quite sufficient | 12:38 |
rdale | ok | 12:38 |
Kinnison | if you want a reference point, simply copy system-auth from a running system which has systemd, and remove the systemd specific bits | 12:39 |
franred | Im trying to push some patches to gerrit and I getting the following error: http://paste.baserock.org/nevuyivuku | 12:42 |
franred | anyone has any idea why my changes should be in refs/for/master/update-openstack-to-kilo already? | 12:44 |
franred | s/should be/are/ | 12:44 |
franred | ummm looks like I have some commits without Change-Id, I going to try to recreate them and send them again | 12:55 |
*** petefoth_ has joined #baserock | 12:58 | |
*** petefoth has quit IRC | 12:59 | |
*** petefoth_ is now known as petefoth | 12:59 | |
franred | https://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 |
straycat | so pylint gives -ve scores | 13:12 |
straycat | is it wise to admit i've discovered this? | 13:12 |
straycat | well i fixed things and now i'm on 8.14, so i guess it's okay | 13:13 |
franred | jjardon, you may want to have a look at https://gerrit.baserock.org/#/c/836/ - it fixes mason | 13:29 |
franred | s/mason/the build error in mason/ | 13:29 |
* SotK wonders what happened to https://mason-x86-32.baserock.org/ | 13:39 | |
petefoth | SotK: At least it's not showing red :) | 13:41 |
richard_maw | probably ran out of disk space | 13:42 |
SotK | red would be better than nothing at all | 13:42 |
petefoth | Unlike https://mason-x86-64.baserock.org/ | 13:42 |
petefoth | "2015-06-10 09:01:31 Build of erlang-sd_notify failed." | 13:43 |
franred | petefoth, the fix is in gerrit already https://gerrit.baserock.org/#/c/836/ | 13:43 |
petefoth | franred: OK< I'll be quite :) | 13:43 |
petefoth | or evene quite | 13:43 |
petefoth | not noisy | 13:43 |
*** a1exhughe5 has quit IRC | 13:45 | |
*** a1exhughe5 has joined #baserock | 13:58 | |
*** fay_ has quit IRC | 14:01 | |
* pedroalvarez notes that x86_32 mason doesn't build openstack systems | 14:04 | |
pedroalvarez | thus, no erlang | 14:05 |
pedroalvarez | but yes... 503 | 14:05 |
ssam2 | sorry, i did spot earlier that but didn't look at it yet | 14:08 |
pedroalvarez | should be fixed now | 14:08 |
ssam2 | cool! | 14:08 |
pedroalvarez | building from stage1-binutils though | 14:08 |
*** fay has joined #baserock | 14:17 | |
*** fay is now known as Guest14180 | 14:17 | |
*** petefoth has quit IRC | 14:19 | |
jjardon | that's look correct, that chunk was updated today | 14:19 |
pedroalvarez | :) | 14:22 |
*** wschaller_ has joined #baserock | 14:37 | |
*** wschaller has quit IRC | 14:41 | |
jmacs | ssam2: 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 |
ssam2 | I cherry-picked it into a branch of the the make-tarball repo on git.baserock.org | 14:55 |
ssam2 | which is easy to do if you have push access there | 14:55 |
ssam2 | i'm happy to give you push access there if you need to do that sort of thing in future | 14:56 |
ssam2 | well, to test the fix I just did 'git clone' of make-tarball.git locally, then did 'make install' in my chroot | 14:57 |
ssam2 | once that worked, I made a branch of make-tarball.git and did a patch for definitions | 14:57 |
jmacs | I don't have git inside my chroot; I'll have to wget it | 15:02 |
jmacs | Actually, what is make-tarball.git? I thought it'd be something with a binary version of make in it | 15:05 |
ssam2 | it's a release tarball of make | 15:05 |
ssam2 | because make is super early in the build process, it's impractical to build it from the git repo | 15:05 |
ssam2 | it's created by Lorry; the make-4.1 tag is the make-4.1.tar.gz tarball | 15:05 |
ssam2 | i'm not sure what 'master' is :) | 15:05 |
Kinnison | for tarball imports it's usually the most recent tarball imported | 15:06 |
ssam2 | ah, so the same thing in this case | 15:06 |
*** Guest14180 is now known as fay_ | 15:06 | |
jmacs | How do you build it without make? | 15:07 |
Kinnison | make has a shell script in it IIRC | 15:07 |
ssam2 | stage2-make builds make | 15:07 |
Kinnison | Oh, we do it that way | 15:07 |
Kinnison | :) | 15:07 |
ssam2 | the host system's make builds stage2-make, as stage2-make is a 'bootstrap' mode chunk | 15:07 |
*** pedroalvarez_ has joined #baserock | 15:11 | |
*** ChanServ sets mode: +v pedroalvarez_ | 15:11 | |
*** pedroalvarez has quit IRC | 15:14 | |
jmacs | Maybe 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 |
Kinnison | The host system has a make binary. (call it host-make) | 15:15 |
perryl | 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:15 |
Kinnison | In bootstrap mode, the stage2-make chunk is built using host-make | 15:15 |
*** pedroalvarez_ is now known as pedroalvarez | 15:15 | |
Kinnison | Then, the real make chunk is built, using stage2-make | 15:15 |
Kinnison | Is that any clearer? | 15:16 |
jmacs | Yes but it doesn't get me any closer to a working make | 15:16 |
jmacs | Unless I'm meant to make make-tarball outside the chroot | 15:16 |
Kinnison | Are you not using Baserock's build-essential definition? | 15:16 |
jmacs | Yes, and that one produces a broken make | 15:17 |
Kinnison | Okay, I'm lost too now :( | 15:17 |
ssam2 | jmacs: what is your goal? | 15:25 |
jmacs | Debug why gcc doesn't build when you specify --enable-languages=java | 15:25 |
ssam2 | so you're debugging *inside* the failed staging chroot of 'gcc'? | 15:26 |
jmacs | Yes | 15:26 |
ssam2 | you should be able to build a fixed make outside the chroot then, and copy it in | 15:27 |
jmacs | The host's make works fine outside the chroot, but not inside it | 15:27 |
jmacs | But does it also need that fix? | 15:27 |
ssam2 | I doubt it. | 15:28 |
ssam2 | I don't think we've established whether the fact that it fixed a segfault for me means it'll solve your problem | 15:28 |
jmacs | I can't cherry pick that fix for make-tarball anyway | 15:29 |
jmacs | Doesn't appear to be in git.baserock.org's version | 15:29 |
ssam2 | git.baserock.org's make.git is actually an import of a now-obsolete Bzr repo on Launchpad that the GNU Make project used to use | 15:29 |
paulsherwood | perryl: maybe ssam2 can help with that - it looks like sometihng might be trying fiddle with the sandboxed area? | 15:30 |
ssam2 | I wish there was a clear way to mark it as such | 15:30 |
ssam2 | it's in make-tarball.git in branch baserock/make-4.1-ttyname-segfault-fix | 15:30 |
ssam2 | (or some such name) | 15:30 |
ssam2 | there's also a patch for definitions that uses that branch which you could test out: https://gerrit.baserock.org/#/c/835/ and rebuild | 15:30 |
ssam2 | perryl: sorry, I missed your question | 15:30 |
jmacs | Right, that looks good | 15:31 |
perryl | ssam2: 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 |
ssam2 | hmm.. not sure | 15:32 |
ssam2 | the same command works without the added faketime bit? | 15:32 |
perryl | i 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 issue | 15:32 |
ssam2 | ok | 15:32 |
ssam2 | sandboxlib logs the full command it is running with the python logging module | 15:33 |
ssam2 | you could add two lines to the ybd code to make it put that info on stdout: | 15:33 |
ssam2 | import logging, sys | 15:33 |
ssam2 | logging.basicConfig(stream=sys.stdout, level=logging.DEBUG) | 15:33 |
ssam2 | i'll try help you out in person in a bit, i'm looking at a (weirdly similar) problem right now | 15:34 |
perryl | ssam2: no worries, i'll try removing the parts i added and adding logging and see what changes! | 15:35 |
*** a1exhughe5 has quit IRC | 15:38 | |
*** wschaller has joined #baserock | 15:53 | |
*** wschaller_ has quit IRC | 15:53 | |
*** jonathanmaw has quit IRC | 16:04 | |
*** zoli___ has joined #baserock | 16:17 | |
*** zoli__ has quit IRC | 16:18 | |
*** wschaller_ has joined #baserock | 16:34 | |
*** wschaller has quit IRC | 16:37 | |
perryl | hmm...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 YBD | 16:39 |
* perryl checks with master again to be sure | 16:39 | |
richard_maw | perryl: double close because it was opened from a context manager then returned? | 16:40 |
perryl | richard_maw: could be :/ it's an error i've introduced to be sure..though master also fails due to no "executor_for_platform" in sandboxlib | 16:41 |
paulsherwood | master ybd fails? | 16:41 |
perryl | yes | 16:43 |
perryl | i'll have a look to see if anything is logged | 16:43 |
ssam2 | perryl: what version of sandboxlib are you using? | 16:45 |
ssam2 | you may need to update | 16:45 |
perryl | ssam2: which is the latest version | 16:46 |
perryl | ? | 16:46 |
ssam2 | 0.3.0 | 16:46 |
ssam2 | it's on https://pypi.python.org/pypi/sandboxlib | 16:46 |
perryl | whoa, yeah i was on 0.1.1 | 16:46 |
paulsherwood | ssam2: 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 IRC | 16:49 | |
ssam2 | paulsherwood: as in, you want the message to be printed once per process, rather than once per call to run_sandbox() ? | 16:54 |
ssam2 | if so, yes | 16:55 |
paulsherwood | ssam2: yup. once per run of ybd, ideally i think? | 16:56 |
paulsherwood | unless we believe that the content could change during a run? | 16:57 |
ssam2 | easy enough. although if someone installs linux-user-chroot half-way through a build, it will not be accurate ;) | 16:57 |
ssam2 | so, it could change, but it is very unlikely | 16:57 |
paulsherwood | interesting. do we need to close that hole? | 16:57 |
ssam2 | actually, yes :) | 16:58 |
paulsherwood | easy to do? | 16:58 |
ssam2 | it should just pick the backend once on startup anyway | 16:58 |
ssam2 | i'll send a patch | 16:58 |
paulsherwood | ok great | 16: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 exists | 16:58 |
*** bashrc has quit IRC | 17:02 | |
ssam2 | kejiahu_: I think you have lost the device tree (DTB_FILE) in your updated version | 17:03 |
ssam2 | the extensions move is a work in progress by SotK, I'm not sure the state of it myself | 17: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.morph | 17:08 |
ssam2 | how was it deployed? | 17:11 |
ssam2 | the cluster .morph file you used to upgrade needs to have DTB_FILE set | 17:12 |
ssam2 | clusters/jetson-update.morph gives an example | 17:12 |
*** mdunford has quit IRC | 17:13 | |
kejiahu_ | ssam2: yes, I used that as reference, this is my cluster http://paste.baserock.org/abowayosup | 17:14 |
kejiahu_ | ssam2: I only changed the name, and also added VERSION_LABLE on, as it's required by update | 17:14 |
SotK | kejiahu_: some are still dependent on morphlib sadly | 17:22 |
SotK | I'm working on solving that this week, see the "Moving morphlib/writeexts.py into definitions" email thread on baserock-dev | 17:23 |
radiofree | can baserock deploy using/to openstack ironic? | 17:24 |
kejiahu_ | SotK: thanks for clarify that :) | 17:24 |
*** ssam2 has quit IRC | 17: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 ironic | 17:27 |
radiofree | kejiahu_: you did some work on it right? is it all upstream? | 17:30 |
radiofree | i.e does morph support deployment to ironic? or is it in some branch somewhere | 17:30 |
radiofree | s/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 edcragg | 17:33 |
radiofree | thanks kejiahu_ | 17:33 |
kejiahu_ | radiofree: tiago got some success on using ironic to deploy on x86, but we haven't got it on arm yet | 17:34 |
kejiahu_ | radiofree: :) | 17:34 |
*** edcragg has quit IRC | 17:41 | |
*** wschaller_ has quit IRC | 17:42 | |
SotK | kejiahu_: no problem | 17:44 |
*** gary_perkins has quit IRC | 18:26 | |
*** lachlanmackenzie has quit IRC | 18:37 | |
*** edcragg has joined #baserock | 19:08 | |
*** zoli___ has quit IRC | 20:47 | |
*** zoli__ has joined #baserock | 21:44 | |
*** zoli___ has joined #baserock | 21:48 | |
*** zoli__ has quit IRC | 21:48 | |
*** zoli___ has quit IRC | 22:21 | |
*** edcragg has quit IRC | 23:26 | |
*** edcragg has joined #baserock | 23:36 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!