| *** zoli__ has joined #baserock | 02:45 | |
| *** zoli__ has quit IRC | 02:50 | |
| *** zoli__ has joined #baserock | 02:59 | |
| *** zoli__ has quit IRC | 03:00 | |
| *** pdar has quit IRC | 03:27 | |
| *** petefotheringham has quit IRC | 03:27 | |
| *** paulw has quit IRC | 03:27 | |
| *** De|ta has quit IRC | 03:27 | |
| *** paulsher1ood has quit IRC | 03:27 | |
| *** jmacs has quit IRC | 03:27 | |
| *** mwilliams_ct has quit IRC | 03:27 | |
| *** pdar has joined #baserock | 03:27 | |
| *** De|ta has joined #baserock | 03:28 | |
| *** petefotheringham has joined #baserock | 03:28 | |
| *** paulsherwood has joined #baserock | 03:28 | |
| *** mwilliams_ct has joined #baserock | 03:28 | |
| *** jmacs has joined #baserock | 03:28 | |
| *** paulw has joined #baserock | 03:28 | |
| *** pacon has quit IRC | 04:13 | |
| *** zoli__ has joined #baserock | 05:10 | |
| *** zoli__ has quit IRC | 05:49 | |
| *** zoli__ has joined #baserock | 06:19 | |
| *** petefoth has joined #baserock | 06:26 | |
| *** pacon has joined #baserock | 06:44 | |
| *** edcragg has joined #baserock | 07:00 | |
| *** edcragg has quit IRC | 07:05 | |
| *** rdale has joined #baserock | 07:53 | |
| *** gary_perkins has joined #baserock | 08:01 | |
| *** bashrc_ has joined #baserock | 08:05 | |
| *** jonathanmaw has joined #baserock | 08:07 | |
| *** sambishop has joined #baserock | 08:12 | |
| *** fay_ has joined #baserock | 08:14 | |
| *** mariaderidder has joined #baserock | 08:30 | |
| *** CTtpollard has joined #baserock | 08:37 | |
| *** ssam2 has joined #baserock | 09:12 | |
| *** ChanServ sets mode: +v ssam2 | 09:12 | |
| *** flatmush has quit IRC | 09:26 | |
| paulsherwood | has anyone managed to try ybd 15-13? i realized at the last minute that i'd messed up directory creation. i'm wondering if it works on fedora, debian, ubuntu etc? | 09:31 |
|---|---|---|
| radiofree | paulsherwood: i tried it on fedora 19 but it didn't work | 09:31 |
| paulsherwood | especially wondering what hurles new users hit, either in the 'documentation' ie the readme, or in getting dependencies to work | 09:31 |
| paulsherwood | radiofree: could you raise an issue please? | 09:32 |
| radiofree | some error about app not being initialised | 09:32 |
| radiofree | paulsherwood: fedora 19 is old, i put it down to that and decided to update to 21 for testing | 09:32 |
| radiofree | i have a fedora 20 machine here i can test on now though | 09:32 |
| paulsherwood | hmmm. i'm embarassed to admit that 15-13 now is not what it used to be on sat/sun. could you clone latest and try please? | 09:32 |
| * SotK wonders where that version number comes from | 09:33 | |
| rjek | I was just thinking that | 09:33 |
| rjek | Is that version 2? | 09:33 |
| paulsherwood | SotK: year-week | 09:33 |
| Kinnison | paulsherwood: So you're saying you're one of those horrendous upstreams who moves tags? | 09:33 |
| SotK | paulsherwood: it was week 23 last week? | 09:33 |
| SotK | :) | 09:33 |
| * Kinnison imagines we're somewhat closer to week 23 yes | 09:33 | |
| radiofree | paulsherwood: you'll have to wait until tonight for the fedora 19 test, but i wouldn't worry about that | 09:33 |
| paulsherwood | ah. my bad, then :) | 09:33 |
| Kinnison | paulsherwood: Even if you think you have zero users who depend on them -- get into good habits now and do not: (a) move tags or (b) rebase master | 09:34 |
| paulsherwood | Kinnison: i'm afraid i currently am, yes. if when anyone suggests actually lorrying it, i'll tighten up. at the moment it's still pre-production :) | 09:34 |
| * SotK will test it on Debian later on, and baserock in a moment | 09:34 | |
| Kinnison | paulsherwood: habits formed in preproduction will be harder for you to break later | 09:34 |
| radiofree | ah, aarch64 build failed on gcc :\ | 09:34 |
| rjek | Everything's pre-production until somebody's daring or careless enough to put it into production. | 09:34 |
| *** flatmush has joined #baserock | 09:34 | |
| paulsherwood | Kinnison: i disagree. i change my habits regularly, to suit the project i'm on | 09:34 |
| paulsherwood | (and the phase of the project i'm on) | 09:35 |
| * Kinnison has strongly held beliefs regarding "Once it is published, don't change it" | 09:35 | |
| jmacs | I don't think I would never publish anything if I followed that idea | 09:36 |
| paulsherwood | Kinnison: great in theory. in practice i make too many last-minute mistakes for that :) | 09:36 |
| jmacs | ^ but with correct words | 09:36 |
| *** lachlanmackenzie has joined #baserock | 09:36 | |
| paulsherwood | Kinnison: i've been taking the view that ybd was an r&d project in accordance with http://www.devcurmudgeon.com/three-times-done.html | 09:36 |
| rjek | This is why we have point releases. | 09:36 |
| * paulsherwood hasn't needed 'releases' at all so far :) | 09:37 | |
| Kinnison | paulsherwood: I don't see why R&D wouldn't be run as "proper" otherwise you form bad habits | 09:37 |
| paulsherwood | Kinnison: noted | 09:37 |
| Kinnison | paulsherwood: also, by definition, habits don't change regularly | 09:37 |
| paulsherwood | Kinnison: let's agree to disagree :-) | 09:37 |
| Kinnison | It may be your habit to regularly change your behaviour | 09:38 |
| Kinnison | but that's different | 09:38 |
| paulsherwood | :-) | 09:38 |
| * Kinnison agreed to generally disagree with paulsherwood quite some years ago now :) | 09:39 | |
| paulsherwood | heh | 09:39 |
| Kinnison | doesn't stop me arguing my points :) | 09:39 |
| SotK | paulsherwood: Have you tried subsystem deployment? I'm getting an error from the rawdisk write extension about INITRAMFS_PATH being specified but not existing when running `ybd clusters/release.morph x86_64` | 09:47 |
| paulsherwood | SotK: i've not tried deployment for a while... was leaving that to you :-) | 09:48 |
| SotK | :) | 09:48 |
| SotK | I'll have a more detailed look soon | 09:48 |
| paulsherwood | SotK: note, x86_64 is now optional :) | 09:48 |
| * richard_maw whispers teeessstt suuiiiittteeesss | 09:49 | |
| paulsherwood | richard_maw: i heard that, it echoes all across the interweb! | 09:49 |
| paulsherwood | at the moment the closest thing that ybd has to a test suite is.... ybd | 09:50 |
| paulsherwood | that's not to say i'm against having some specific tests... running ybd on all the things takes quite a long time | 09:50 |
| *** petefoth_ has joined #baserock | 09:53 | |
| *** petefoth has quit IRC | 09:55 | |
| *** petefoth_ is now known as petefoth | 09:55 | |
| Kinnison | SotK: I never wrote subsystem deployment | 09:55 |
| Kinnison | SotK: so unless someone else did... | 09:55 |
| SotK | an attempt was made, I don't know if it was ever working though | 09:56 |
| paulsherwood | i thought i'd got some of it working | 09:59 |
| pedroalvarez | I wonder if definitions should have definied some tests? | 10:17 |
| SotK | pedroalvarez: you mean per-system? | 10:18 |
| pedroalvarez | I mean, a place where it's definied that for a given definition, you should have a given result | 10:19 |
| SotK | aha, I see | 10:21 |
| pedroalvarez | but it might be difficult to have, given that for different build systems, there will be different implementations, giving different results | 10:22 |
| franred | what about the test suites for the different definitions? (it will not test integration but it will test if the definition can run - problem: run dependencies) | 10:25 |
| * richard_maw is pondering whether the definitions model actually needs different build step sections to have different dependencies | 10:27 | |
| pedroalvarez | Will adding some seconds in "RestartSec=" to a systemd unit, avoid systemd complaining with something like "restarted too many times" when the unit is configured with "Restart=on-failure"? | 10:46 |
| richard_maw | pedroalvarez: depends on whether the delay means it eventually starts properly | 10:46 |
| richard_maw | pedroalvarez: it would be better to impose proper dependencies | 10:47 |
| richard_maw | pedroalvarez: so you are not at the whim of the speed of your current system | 10:47 |
| pedroalvarez | yes, that makes sense, and I think I know how to fix this using dependencies instead of doing that ugly hack | 10:47 |
| *** edcragg has joined #baserock | 10:58 | |
| SotK | I have a patch for morph which needs to add to the list of supported definitions versions, but there is already a patch on Gerrit which adds version 5. I assume I should make the list [0, 1, 2, 3, 4, 6] in my patch? | 12:12 |
| paulsherwood | SotK: what's the patch? | 12:15 |
| SotK | setting PYTHONPATH when running deployment extensions | 12:16 |
| ssam2 | SotK: or base your patch of richard_maw's patch that adds version 5 | 12:16 |
| ssam2 | *off | 12:16 |
| SotK | ssam2: that's probably a better idea | 12:17 |
| ssam2 | i still think we should be discussing changes to the definitions format on baserock-dev first | 12:17 |
| paulsherwood | +1 | 12:17 |
| ssam2 | not that discussion should block sending a patch of course, but it should block merging the patch | 12:17 |
| SotK | hmm... ISTR someone suggesting feature flags as well as a definitions version number | 12:19 |
| richard_maw | hmm, version: 5 meaning parse the rest of the file for feature flags maybe | 12:20 |
| * paulsherwood wants to strangle this version thing already... not that it's not needed, just that it needs to be frictionless | 12:20 | |
| *** pacon has quit IRC | 12:24 | |
| SotK | It would be nice if a change like "setting PYTHONPATH when running deployment extensions" was unrelated to the version of the definitions format for example, but instead we could list in VERSION "set-pythonpath-for-extensions: yes" or something. | 12:24 |
| *** pacon has joined #baserock | 12:25 | |
| paulsherwood | isn't there a way to code it so it works with or without? | 12:25 |
| paulsherwood | (without changing version)? | 12:25 |
| SotK | no, I'd need to change the functionality of old versions of morph to do that | 12:27 |
| SotK | well, I could duplicate a load of code in each of the deployment extensions as and when it was needed, but I don't want to do that | 12:27 |
| paulsherwood | ah, ok | 12:27 |
| SotK | and needing to depend on a python module which is in definitions means that the definitions checkout needs to be in PYTHONPATH when running the deployment extensions, which old morph can't do | 12:28 |
| rdale | i don't think we should be having conditional code in morph based on versions numbers - that will quickly become unmaintable in my opinion. can we not write conversion scripts to bring the definitions up to date with the current morph? | 12:29 |
| ssam2 | rdale: yes. All of the current versions don't actually need migration scripts, I think | 12:32 |
| ssam2 | we could remove some of them, though. The last released version of the Baserock reference systems contained Morph that supported up to v3, I think | 12:33 |
| rdale | i suppose my definition of needing a version number bump, would be that the change requires a conversion script | 12:33 |
| ssam2 | so we could remove 0, 1, and 2 if we wanted | 12:33 |
| SotK | rdale: the problem with that is that the versioning is also trying to solve the situation where an old version of morph can't parse master of definitions too | 12:34 |
| rdale | well i don't think we should be attempting to do that, it won't scale | 12:34 |
| SotK | then I don't really see what the use of versioning gives us? | 12:35 |
| rdale | my understanding is that if the version of definitions is older than the current morph, we would run suitable migration scripts | 12:36 |
| ssam2 | rdale: yes | 12:38 |
| ssam2 | rdale: but Morph still needs to *know* that it is too old, somehow | 12:38 |
| ssam2 | rdale: introducing changes that would cause old versions of Morph to crash thus requires a version number increment | 12:38 |
| rdale | i would have to know why a user didn't want or couldn't upgrade to the latest morph. doesn't both morph and definitions have a 'current version' associated with them? | 12:39 |
| radiofree | paulsherwood: where does the ybd log go? | 12:39 |
| richard_maw | radiofree: stdout or stderr | 12:39 |
| paulsherwood | radiofree: which one? stdout, and a file for each component. there's no file of the build log itself, i'm embarassed to admit | 12:39 |
| radiofree | ah, ok | 12:40 |
| paulsherwood | i guess it would be useful to have one, with some kind of unique name. eg target-year-month-day-hh-mm-ss.build-log? | 12:42 |
| * SotK suggests a ybd.log file somewhere | 12:43 | |
| robtaylor | rdale: ssam2: could require every version bump to have a migration script, and generally have the assumption that head of nay tool is only expected to handle the current version, or something like that | 12:43 |
| SotK | I don't think I'd want a new log file created in my current directory each time I ran ybd | 12:43 |
| SotK | we'd still need to bump the version when some changes which would cause old versions of tools to crash were made, which doesn't even necessarily need a migration script | 12:45 |
| ssam2 | robtaylor: that's how I think it will work. The only thing is none of the versions so far have required any migration | 12:45 |
| rdale | robtaylor: yes that would how i assumed it would work. i we want to have an old morph handling new defintions. we would need downward migration scripts - that is better than embedding random lists of numbers in the morph code, although i can't see why a user would want to stick on an old morph, unless we were introducing bugs or undesirable features | 12:45 |
| robtaylor | ssam2: i guess a minimum migration script would bump the version field then ;) | 12:46 |
| SotK | rdale: old morph doesn't need to handle it, just give an error like "This version of morph can't support version foo of definitions" rather than "Missing field build-depends in foo.morph" for example | 12:46 |
| SotK | the latter sounds like a problem with the definitions, when actually morph just needs updating | 12:47 |
| rdale | is that all the lists of version numbers do in the morph code? | 12:47 |
| robtaylor | rdale: yeah, i guess forcing forward moviment at least will make people try and fix issues rather than just downgrading ;) | 12:47 |
| SotK | rdale: yes, as far as I am aware | 12:47 |
| rdale | ok | 12:47 |
| SotK | actually, richard_maw's patches for strip commands introduce some code conditional on the version number | 12:48 |
| SotK | they are not yet merged, however | 12:48 |
| *** pacon has quit IRC | 12:58 | |
| *** richard_maw has quit IRC | 13:03 | |
| *** richard_maw has joined #baserock | 13:05 | |
| *** ChanServ sets mode: +v richard_maw | 13:05 | |
| *** sambishop has quit IRC | 13:12 | |
| *** sambishop has joined #baserock | 13:23 | |
| *** sam_ has joined #baserock | 13:38 | |
| *** sambishop has quit IRC | 13:38 | |
| *** lachlanmackenzie has quit IRC | 13:44 | |
| *** lachlanmackenzie has joined #baserock | 13:55 | |
| *** zoli__ has quit IRC | 14:43 | |
| *** zoli__ has joined #baserock | 14:44 | |
| *** zoli__ has quit IRC | 14:48 | |
| * SotK discovers that subsystems don't seem to get built when doing `ybd $some-cluster-with-subsystems` | 14:53 | |
| straycat | coincidentally, | 14:56 |
| straycat | "Almost any abbreviation or acronym is going to be ambiguous. If the first page of Google hits for your initialization isn't about your topic, then you have the wrong name." | 14:56 |
| straycat | ( https://pause.perl.org/pause/query?ACTION=pause_namingmodules ) | 14:56 |
| pedroalvarez | straycat: http://mashable.com/wp-content/uploads/2014/02/second.png | 14:57 |
| straycat | :) | 14:58 |
| *** petefoth has quit IRC | 15:01 | |
| *** zoli__ has joined #baserock | 15:05 | |
| paulsherwood | SotK: can you raise an issue, please | 15:07 |
| paulsherwood | ? | 15:07 |
| SotK | paulsherwood: yeah sure, I'm working on a fix for it too | 15:07 |
| paulsherwood | perfect :) | 15:07 |
| paulsherwood | rdale: one reason why a user would stick to old morph, is simply that it *works*, and previous experience with morph and other software is that changing things may lead to breakage | 15:29 |
| paulsherwood | for example, we've already shown that upgrading distbuild can be non-trivial... which causes users to be reluctant to do it | 15:30 |
| rdale | if we have very few users, and the ones we have won't upgrade, then allowing them to stay put seems like declaring the software obsolete | 15:31 |
| rdale | but i personally would rather have downward migrations for the morphs, to handle the above case, rather than 'magic' lists of version numbers in the morph code | 15:32 |
| paulsherwood | rdale: i'm thinking we need migrations in both directions to be so trivial as to be zero friction. any ideas on how to achieve that? | 15:34 |
| * paulsherwood thinks it may require properly understandign the semantics as discussed elsewhere | 15:34 | |
| *** nowster_ is now known as nowster | 15:34 | |
| rdale | we need 'up' and 'down' migration scripts for each version number bump - i think the custom version of pyaml that i found should be able to handle that | 15:35 |
| SotK | and then say "morph can only support a single version, everything else gives an appropriate "please upgrade/downgrade definitions version" error? | 15:37 |
| paulsherwood | could this be done so that mostly the *interpretation* of the yaml was decoupled from the tooling? | 15:37 |
| rdale | but i'm not sure that i have much understanding of the semantics and previous changes, apart from the 'environment:' one that i disussed on the mailing list | 15:37 |
| rdale | 'build-depends: []' ==> '' is one i remember | 15:38 |
| SotK | indeed | 15:39 |
| * Kinnison mumbles about how he said all of this months and months ago and was blithely ignored for 'expedience' | 15:39 | |
| paulsherwood | Kinnison: we can't have all the things all at once, that's all | 15:39 |
| paulsherwood | Kinnison: you could take this just as confirmation that you're right, again :) | 15:40 |
| SotK | that didn't *need* a forward migration script because morph doesn't mind if 'build-depends: []' is there, it just stopped enforcing its presence | 15:40 |
| Kinnison | paulsherwood: I'm tired of being shown to have been right months and months of effort later :-/ | 15:40 |
| paulsherwood | Kinnison: me too. | 15:40 |
| paulsherwood | :) | 15:41 |
| Kinnison | hrm :) | 15:41 |
| ssam2 | rdale, SoTK: I agree on that plan | 15:41 |
| ssam2 | rdale: all the previous changes are described here: http://wiki.baserock.org/definitions/historical/ | 15:42 |
| rdale | excellent! | 15:42 |
| * robtaylor imagines versions/<number>/{up,down}.py somewhere, perhaps with versions/<number>/definitions.md recording the documentation for that version | 15:44 | |
| rdale | i think we can write up and down migrations for those. the version 3 'armv5' down migration would be a bit brutal and simply remove any system with that arch | 15:44 |
| robtaylor | the general problem with these sort of things though is that they are usuall under excercised and hence contain lots of things that trip you up in reality | 15:45 |
| robtaylor | having said that, its definitly better than nothing | 15:45 |
| paulsherwood | robtaylor: i'm hoping for something more automated/intelligent if possible | 15:48 |
| paulsherwood | it may not be, of course :) | 15:49 |
| * Kinnison has no problem with down migrations saying "No, can't do it" | 15:50 | |
| SotK | Has the ybd strip-commands stuff been tested when building a cluster? | 15:52 |
| SotK | paulsherwood, richard_maw ^^ | 15:52 |
| robtaylor | paulsherwood: well i guess you could have a test suite that does random up/down grades and tests it works with the relevent morph/ybd | 15:52 |
| richard_maw | SotK: I didn't, I looked at the cached artifact. | 15:52 |
| robtaylor | paulsherwood: for that there's have to be a clear record somwhere (git tags?) of which release/commit of a tool should be used with each version. | 15:53 |
| SotK | richard_maw: it seems that its running the strip-command when "building" the cluster definition, and crashing | 15:54 |
| SotK | paulsherwood, richard_maw: http://sprunge.us/BdQH | 15:55 |
| paulsherwood | SotK: ouch ! | 15:56 |
| *** petefoth has joined #baserock | 15:58 | |
| * SotK doesn't know how to approach solving this, I guess this kind of thing hasn't happened because normally the default commands are a noop, but I believe (I may be wrong) ybd tries to treat clusters as "just another definition" rather than a special case? | 15:58 | |
| paulsherwood | yup | 15:58 |
| *** jonathanmaw has quit IRC | 16:01 | |
| paulsherwood | SotK: it's not quite that simple at the moment. i was hoping that deployment would become part of assembly too, but ended up having to keep it separate | 16:01 |
| SotK | I don't see how we can fix this without special casing clusters though :/ | 16:05 |
| paulsherwood | hmmm | 16:06 |
| * richard_maw doesn't see that as a problem | 16:06 | |
| richard_maw | they *are* fundamentally different things | 16:06 |
| paulsherwood | yup, true | 16:06 |
| richard_maw | it just happened to accidentally work in the previous code | 16:07 |
| paulsherwood | but we want the possibility of deploying components | 16:07 |
| * SotK doesn't see it as a problem either fwiw | 16:08 | |
| SotK | paulsherwood: what do you mean? | 16:08 |
| richard_maw | paulsherwood: ehhh, | 16:08 |
| richard_maw | paulsherwood: a lot of variables are only known at the system level | 16:08 |
| richard_maw | i.e. the architecture is passed down from the system | 16:08 |
| richard_maw | in morph | 16:08 |
| * richard_maw isn't entirely comfortable with ybd passing it in on the command line | 16:08 | |
| richard_maw | and we also want to be able to parameterise builds, possibly by setting fields in the system to be inherited | 16:09 |
| paulsherwood | richard_maw: yes, ok. but if that's the only variable you're worried about , i think it's easy to address | 16:09 |
| richard_maw | it's all the other variables we may want to add which is the trouble | 16:09 |
| paulsherwood | ok understood | 16:09 |
| ssam2 | can someone explain what http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/build-essential/stage1-gcc.morph#n6 is meant to do? | 16:11 |
| ssam2 | "sed -i '/k prot/agcc_cv_libc_provides_ssp=yes' gcc/configure" | 16:11 |
| ssam2 | oh, I guess it's the 'a' operation | 16:12 |
| richard_maw | is there nothing in git log? | 16:12 |
| ssam2 | I always thought you needed a newline over the 'a' | 16:12 |
| ssam2 | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/strata/build-essential/stage1-gcc.morph?id=fe5e9e45bb56bccb6c6ad755b21074ce4df26a02 -- not really | 16:12 |
| ssam2 | s/over/after/ | 16:12 |
| * SotK gets back to the INITRAMFS_PATH error he started with | 16:23 | |
| paulsherwood | richard_maw: coming back to the $arch - most components don't care about arch, until we build them. but that doesn't mean the arch variable isn't meaningful for the components? | 16:24 |
| * richard_maw can't parse that | 16:24 | |
| richard_maw | it may just be too late in the day | 16:24 |
| paulsherwood | ok, np. i'll leave it | 16:24 |
| richard_maw | most components need their architecture, as it needs to go into the cache key | 16:25 |
| paulsherwood | yup. but we don't want to have a definition of component per architecture | 16:25 |
| paulsherwood | so if i build a component, i need to state the target architecture somehow, don't i? | 16:26 |
| richard_maw | …yes? | 16:26 |
| paulsherwood | 17:08 * richard_maw isn't entirely comfortable with ybd passing it in on the command line | 16:26 |
| paulsherwood | how would you prefer it to be communicated? | 16:26 |
| richard_maw | as part of the system definition | 16:27 |
| paulsherwood | i'm building a component. no system is to be inferred | 16:27 |
| richard_maw | and have it be passed down to the chunk definitions | 16:27 |
| radiofree | I'm getting "clone: Invalid argument" with ybd | 16:28 |
| paulsherwood | eek | 16:28 |
| richard_maw | paulsherwood: but you need your variables to be defined somewhere, and IMO they only make sense together at the system definition level | 16:28 |
| richard_maw | radiofree: kernel not support namespaces? | 16:28 |
| radiofree | i have CONFIG_NAMESPACES=y and CONFIG_USER_NS=y | 16:29 |
| paulsherwood | richard_maw: i'm building individual components, or strata. arch still makes sense, imo | 16:29 |
| paulsherwood | radiofree: can you paste the log? | 16:29 |
| richard_maw | radiofree: you may be missing the pid namespace | 16:29 |
| radiofree | CONFIG_PID_NS=y | 16:29 |
| radiofree | only one missing is CONFIG_NET_NS but i'm assuming that doesn't need to be set? | 16:30 |
| Kinnison | I thought we isolated net too | 16:30 |
| richard_maw | radiofree: you assume incorrectly thre | 16:30 |
| radiofree | ah, so i do need that? | 16:30 |
| richard_maw | paulsherwood: I think we may be violently agreeing that we need the arch for building chunks/components, I argue that we shouldn't be feeding that in on the command-line, as that's another thing you may forget to set and end up with a different result. | 16:31 |
| *** gary_perkins has quit IRC | 16:32 | |
| richard_maw | paulsherwood: I think it should go at the system level, and if you need less than the full result of the system, we need to specifiy *that*, rather than hackily saying "build this stratum" | 16:32 |
| richard_maw | to which my response would be "ok boss, but which version of this stratum do you want? We could build it with many different combinations of variables" | 16:33 |
| paulsherwood | richard_maw: it's not 'hackily'. there are actual usecases requiring 'build this thing, which is not a system' | 16:33 |
| radiofree | richard_maw: morph builds it fine | 16:33 |
| paulsherwood | richard_maw: separately i'm of the view that definitions in a given branch of a git repo should be uniquely defined :) | 16:34 |
| radiofree | hmm well this is stage1 binutils | 16:34 |
| * radiofree just rebuilds with NET_NS | 16:34 | |
| richard_maw | paulsherwood: I'm not saying that there's not a use-case for building less than a system. I'm saying that we need to describe what we want in a file, and that can't be the stratum file, as the stratum file is intended to have its architecture parameterised by a higher level definition | 16:35 |
| paulsherwood | richard_maw: yes, i get that. we have some way to go on making this tidy, though :) | 16:36 |
| richard_maw | we could file the numbers off system definitions and call them something else, and you'd have such a definition | 16:36 |
| richard_maw | provided we add a way of specifying an individual chunk/component, assuming that's the granularity you want to build/depoly | 16:37 |
| * SotK wonders if a patch to split up the deploy() function to make it less confusingly recursive would be accepted, since the alternative for subsystem deployment is going to be even more confusing than it already is | 16:38 | |
| radiofree | richard_maw: thanks, it was CONFIG_NS | 16:39 |
| paulsherwood | SotK: probably, unless it adds an excessive number of loc | 16:39 |
| radiofree | NETWORK_NS even | 16:39 |
| richard_maw | paulsherwood: I suppose `call(['find'], stdout=f, stderr=f)` is also an attempt to do it with the fewest loc | 16:39 |
| richard_maw | btw, you should use stderr=subprocess.STDOUT, or it can get weird and mix the streams in a way that the subprocess didn't produce | 16:40 |
| paulsherwood | richard_maw: yup, but also it was the easiest solution i knew. if you have something better, i'm happy to consider it | 16:49 |
| richard_maw | nothing as concise, though you could do something in 3 lines with os.walk, which wouldn't have an external dependency on `find`, and wouldn't need a costly fork+exec | 16:51 |
| paulsherwood | richard_maw: that would be better, then. i wasn't happy using find | 16:52 |
| richard_maw | though for a really large tree, shelling out to find would win, as while the fixed overhead of fork+exec is comparatively large, as find is faster than python code | 16:52 |
| * paulsherwood is undecided, then | 16:53 | |
| *** sam_ has quit IRC | 17:01 | |
| persia | Trying to read backscroll ,I think we have competiting definitions of "system". | 17:03 |
| persia | On the one hand, a "system" is a set of software that is built and packaged for some end. | 17:03 |
| ssam2 | i'd call that a "package" | 17:03 |
| persia | On the other hand, a "system" is a set of software that comprises some self-hosting execution environment. | 17:04 |
| persia | ssam2: So the content of a DVD would be a "package"? | 17:04 |
| ssam2 | that'd be a "movie" ? | 17:04 |
| persia | Which I believe is currently a synonym for "system" in morph semantics :) | 17:04 |
| ssam2 | i don't have a strong opinion on this, but I think treating "deploy as a system" as separate to "deploy as a package" is sensible | 17:05 |
| ssam2 | and am in favour of supporting both | 17:05 |
| persia | In such a model, is the movie a "package" or a "system"? | 17:06 |
| persia | Similarly, how about the DVD menu? | 17:06 |
| * paulsherwood has no braincells left for this today | 17:06 | |
| persia | To be clear: I am happy with the idea of building arbitrarily small collections of things. I just worry that the use of terms like "package" and "system" are introducing additional levels of confusion into the discussion, such that things that are obviously correct when considering one semantic assignment become obviously wrong when considering anohter. | 17:08 |
| ssam2 | agreed. It may be that we move to only using the terms "system" and "package" at deploy-time | 17:08 |
| persia | I encourage further dissent tomorrow, but with very clear specification of terms like "system" and "package" so that people know about what they are arguing. | 17:08 |
| ssam2 | presumably at deploy time we'd call a DVD a "dvd" | 17:08 |
| persia | DVD is a logical representation of bits, like a tarball. | 17:09 |
| persia | The specific content that lets one execute a menu, watch a movie, etc. is software, which ought fit into either "package" or "system". | 17:09 |
| ssam2 | I guess so | 17:09 |
| ssam2 | surprisingly, I've managed to build stage1-binutils and stage1-gcc on Mac OS X using YBD | 17:10 |
| paulsherwood | not package, please! | 17:10 |
| paulsherwood | ssam2: w00t!!!! | 17:11 |
| ssam2 | stage2-linux-api-headers doesn't build, though, unsurprisingly | 17:11 |
| persia | One could also put a read-only ISO9660 rootfs on a DVD, and treat it as a more traditional "system", but that model doesn't make us think as carefully about definitions. | 17:11 |
| *** mariaderidder has quit IRC | 17:19 | |
| *** ssam2 has quit IRC | 17:26 | |
| radiofree | paulsherwood: master seems to have fixed the issue on fedora 19 | 17:30 |
| * radiofree is trying it on his personal craptop, so this may take a while | 17:30 | |
| radiofree | it's currently moving along nicely on a mustang as well... running Linux baserock 4.1.0-rc7 #7 SMP PREEMPT Mon Jun 8 17:32:42 BST 2015 aarch64 GNU/Linux | 17:31 |
| *** edcragg has quit IRC | 17:37 | |
| *** sambishop has joined #baserock | 17:38 | |
| jjardon | Hi, is it https://mason-x86-64.baserock.org/ building something? | 18:07 |
| *** lachlanmackenzie has quit IRC | 18:21 | |
| *** edcragg has joined #baserock | 18:51 | |
| paulsherwood | radiofree: cool! | 18:53 |
| radiofree | stage2-fhsdirs ... mount (MS_BIND): No such file or directory | 19:19 |
| radiofree | maybe deleting tmp fixes this | 19:20 |
| radiofree | http://fpaste.org/230115/79130714/ | 19:21 |
| *** edcragg has quit IRC | 19:22 | |
| radiofree | and the build log http://fpaste.org/230116/14337913/ | 19:22 |
| radiofree | wasn't this an issue in the past? | 19:23 |
| paulsherwood | radiofree: it's a race. run it again, should work | 19:31 |
| paulsherwood | my forking is too smart there https://github.com/devcurmudgeon/ybd/issues/51 | 19:32 |
| paulsherwood | basically i fork to delete the old staging, while starting work on the next chunk... because deleting can take some time on my machine | 19:33 |
| paulsherwood | trouble is that the sandboxing tries to lock off all directories, including the tree which is being deleted | 19:33 |
| paulsherwood | i can drop the fork, but that'll slow it down a bit. am hoping for a brainwave | 19:34 |
| radiofree | it seems to have worked, thought the output is a little odd now | 19:35 |
| paulsherwood | i wonder if the sandbox can safely ignore the tmp files? | 19:35 |
| paulsherwood | radiofree: odd? | 19:36 |
| paulsherwood | i know some changes got made today | 19:36 |
| radiofree | it scrolled off my screen session | 19:37 |
| radiofree | hmm | 19:38 |
| radiofree | i'm building 2015-06-08 19:36:19 [stage2-gcc] Start build | 19:38 |
| radiofree | actually it's ok | 19:38 |
| radiofree | if you absolutely have to fork there (it's not a problem if you have an ssd i image?) i'd recommend moving the old staging, then delete that moved staging | 19:40 |
| radiofree | though that might not help with this sandboxing actually | 19:40 |
| radiofree | (i haven't looked at the sandboxing code for morph either, no idea how it's working) | 19:41 |
| paulsherwood | what's the right architecture for Moonshot? | 20:00 |
| paulsherwood | Error: unsupported Morph architecture: aarch64 | 20:01 |
| radiofree | if you're using ybd, it's armv8l64 to remain consistent with baserock | 20:05 |
| radiofree | however you'll need another patch to ybd to get it working | 20:05 |
| radiofree | just built gcc! | 20:05 |
| *** sambishop has quit IRC | 20:12 | |
| *** sambishop has joined #baserock | 20:13 | |
| paulsherwood | :-) | 20:18 |
| paulsherwood | radiofree: do you have that patch anywhere/ | 20:19 |
| paulsherwood | ? | 20:19 |
| radiofree | just pushed it to github, however i'm getting a 404 when i try and do a pull request | 20:20 |
| radiofree | https://github.com/jamespthomas/ybd/commit/fa3ce50053e0960a491b3c9a072aa3613a106128 | 20:20 |
| radiofree | paulsherwood: here's the patch http://paste.fedoraproject.org/230138/95009143/ | 20:23 |
| paulsherwood | radiofree: thanks, i've managed to pull it. shall i merge it, too? | 20:24 |
| radiofree | it should work | 20:26 |
| radiofree | i suppose i better actually test it | 20:26 |
| paulsherwood | :) | 20:27 |
| * paulsherwood keeps hitting 'too many mounts' on the Moonshot | 20:27 | |
| radiofree | reboot? | 20:28 |
| radiofree | if you delete a cached artefact for something that another component down the line depends on (e.g gcc) the build fails | 20:29 |
| *** sambishop has quit IRC | 20:29 | |
| *** sambishop has joined #baserock | 20:30 | |
| paulsherwood | yup. that's issue #15. iirc trying to fix it leads to a weird import recursion problem | 20:30 |
| paulsherwood | mounts seems to be hardcoded at 50 somewhere | 20:31 |
| *** zoli__ has quit IRC | 20:53 | |
| paulsherwood | your patch is working for me, merged! | 20:53 |
| *** zoli__ has joined #baserock | 20:53 | |
| radiofree | you won't actually be able to tell it's worked until you get to building gcc | 20:54 |
| radiofree | (proper gcc) | 20:54 |
| radiofree | on aarch64 | 20:54 |
| radiofree | actually i'll try it on a jetson as well to make sure it's not buggered that up | 20:55 |
| paulsherwood | ok :) well, if it doesn't work, reversion is cheap too :-) | 20:57 |
| *** zoli__ has quit IRC | 20:58 | |
| *** zoli__ has joined #baserock | 21:19 | |
| *** sambishop has quit IRC | 21:20 | |
| *** sambishop has joined #baserock | 21:21 | |
| *** sambishop has quit IRC | 21:25 | |
| *** zoli__ has quit IRC | 21:26 | |
| *** zoli__ has joined #baserock | 21:26 | |
| *** zoli___ has joined #baserock | 21:29 | |
| *** zoli__ has quit IRC | 21:33 | |
| *** zoli__ has joined #baserock | 21:35 | |
| *** zoli__ has quit IRC | 21:36 | |
| *** zoli__ has joined #baserock | 21:37 | |
| *** zoli___ has quit IRC | 21:37 | |
| radiofree | didn't work >.< | 21:38 |
| radiofree | (on aarch64 at least, though i'm now starting to think it's something additional) | 21:45 |
| radiofree | run again, builds, looks like it's an issue similar to fhs-dirs | 21:48 |
| * radiofree will leave it building the system and look at that tomorrow | 21:48 | |
| rjek | radiofree: Are you still at work?! | 21:50 |
| rjek | (he says, working.) | 21:50 |
| radiofree | no, remote access! | 21:50 |
| rjek | So working, just not from the office? :) | 21:50 |
| * rjek turns the lights out | 21:51 | |
| *** zoli__ has quit IRC | 23:15 | |
| *** zoli__ has joined #baserock | 23:15 | |
| *** zoli__ has quit IRC | 23:20 | |
| *** sambishop has joined #baserock | 23:23 | |
| *** Stanto has quit IRC | 23:38 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
