IRC logs for #baserock for Monday, 2015-06-08

*** zoli__ has joined #baserock02:45
*** zoli__ has quit IRC02:50
*** zoli__ has joined #baserock02:59
*** zoli__ has quit IRC03:00
*** pdar has quit IRC03:27
*** petefotheringham has quit IRC03:27
*** paulw has quit IRC03:27
*** De|ta has quit IRC03:27
*** paulsher1ood has quit IRC03:27
*** jmacs has quit IRC03:27
*** mwilliams_ct has quit IRC03:27
*** pdar has joined #baserock03:27
*** De|ta has joined #baserock03:28
*** petefotheringham has joined #baserock03:28
*** paulsherwood has joined #baserock03:28
*** mwilliams_ct has joined #baserock03:28
*** jmacs has joined #baserock03:28
*** paulw has joined #baserock03:28
*** pacon has quit IRC04:13
*** zoli__ has joined #baserock05:10
*** zoli__ has quit IRC05:49
*** zoli__ has joined #baserock06:19
*** petefoth has joined #baserock06:26
*** pacon has joined #baserock06:44
*** edcragg has joined #baserock07:00
*** edcragg has quit IRC07:05
*** rdale has joined #baserock07:53
*** gary_perkins has joined #baserock08:01
*** bashrc_ has joined #baserock08:05
*** jonathanmaw has joined #baserock08:07
*** sambishop has joined #baserock08:12
*** fay_ has joined #baserock08:14
*** mariaderidder has joined #baserock08:30
*** CTtpollard has joined #baserock08:37
*** ssam2 has joined #baserock09:12
*** ChanServ sets mode: +v ssam209:12
*** flatmush has quit IRC09:26
paulsherwoodhas 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
radiofreepaulsherwood: i tried it on fedora 19 but it didn't work09:31
paulsherwoodespecially wondering what hurles new users hit, either in the 'documentation' ie the readme, or in getting dependencies to work09:31
paulsherwoodradiofree: could you raise an issue please?09:32
radiofreesome error about app not being initialised09:32
radiofreepaulsherwood: fedora 19 is old, i put it down to that and decided to update to 21 for testing09:32
radiofreei have a fedora 20 machine here i can test on now though09:32
paulsherwoodhmmm. 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 from09:33
rjekI was just thinking that09:33
rjekIs that version 2?09:33
paulsherwoodSotK: year-week09:33
Kinnisonpaulsherwood: So you're saying you're one of those horrendous upstreams who moves tags?09:33
SotKpaulsherwood: it was week 23 last week?09:33
SotK:)09:33
* Kinnison imagines we're somewhat closer to week 23 yes09:33
radiofreepaulsherwood: you'll have to wait until tonight for the fedora 19 test, but i wouldn't worry about that09:33
paulsherwoodah. my bad, then :)09:33
Kinnisonpaulsherwood: 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 master09:34
paulsherwoodKinnison: 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 moment09:34
Kinnisonpaulsherwood: habits formed in preproduction will be harder for you to break later09:34
radiofreeah, aarch64 build failed on gcc :\09:34
rjekEverything's pre-production until somebody's daring or careless enough to put it into production.09:34
*** flatmush has joined #baserock09:34
paulsherwoodKinnison: i disagree. i change my habits regularly, to suit the project i'm on09: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
jmacsI don't think I would never publish anything if I followed that idea09:36
paulsherwoodKinnison: great in theory. in practice i make too many last-minute mistakes for that :)09:36
jmacs^ but with correct words09:36
*** lachlanmackenzie has joined #baserock09:36
paulsherwoodKinnison: i've been taking the view that ybd was an r&d project in accordance with http://www.devcurmudgeon.com/three-times-done.html09:36
rjekThis is why we have point releases.09:36
* paulsherwood hasn't needed 'releases' at all so far :)09:37
Kinnisonpaulsherwood: I don't see why R&D wouldn't be run as "proper" otherwise you form bad habits09:37
paulsherwoodKinnison: noted09:37
Kinnisonpaulsherwood: also, by definition, habits don't change regularly09:37
paulsherwoodKinnison: let's agree to disagree :-)09:37
KinnisonIt may be your habit to regularly change your behaviour09:38
Kinnisonbut that's different09:38
paulsherwood:-)09:38
* Kinnison agreed to generally disagree with paulsherwood quite some years ago now :)09:39
paulsherwoodheh09:39
Kinnisondoesn't stop me arguing my points :)09:39
SotKpaulsherwood: 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
paulsherwoodSotK: i've not tried deployment for a while... was leaving that to you :-)09:48
SotK:)09:48
SotKI'll have a more detailed look soon09:48
paulsherwoodSotK: note, x86_64 is now optional :)09:48
* richard_maw whispers teeessstt suuiiiittteeesss09:49
paulsherwoodrichard_maw: i heard that, it echoes all across the interweb!09:49
paulsherwoodat the moment the closest thing that ybd has to a test suite is.... ybd09:50
paulsherwoodthat's not to say i'm against having some specific tests... running ybd on all the things takes quite a long time09:50
*** petefoth_ has joined #baserock09:53
*** petefoth has quit IRC09:55
*** petefoth_ is now known as petefoth09:55
KinnisonSotK: I never wrote subsystem deployment09:55
KinnisonSotK: so unless someone else did...09:55
SotKan attempt was made, I don't know if it was ever working though09:56
paulsherwoodi thought i'd got some of it working09:59
pedroalvarezI wonder if definitions should have definied some tests?10:17
SotKpedroalvarez: you mean per-system?10:18
pedroalvarezI mean, a place where it's definied that for a given definition, you should have a given result10:19
SotKaha, I see10:21
pedroalvarezbut it might be difficult to have, given that for different build systems, there will be different implementations, giving different results10:22
franredwhat 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 dependencies10:27
pedroalvarezWill 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_mawpedroalvarez: depends on whether the delay means it eventually starts properly10:46
richard_mawpedroalvarez: it would be better to impose proper dependencies10:47
richard_mawpedroalvarez: so you are not at the whim of the speed of your current system10:47
pedroalvarezyes, that makes sense, and I think I know how to fix this using dependencies instead of doing that ugly hack10:47
*** edcragg has joined #baserock10:58
SotKI 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
paulsherwoodSotK: what's the patch?12:15
SotKsetting PYTHONPATH when running deployment extensions12:16
ssam2SotK: or base your patch of richard_maw's patch that adds version 512:16
ssam2*off12:16
SotKssam2: that's probably a better idea12:17
ssam2i still think we should be discussing changes to the definitions format on baserock-dev first12:17
paulsherwood+112:17
ssam2not that discussion should block sending a patch of course, but it should block merging the patch12:17
SotKhmm... ISTR someone suggesting feature flags as well as a definitions version number12:19
richard_mawhmm, version: 5 meaning parse the rest of the file for feature flags maybe12: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 IRC12:24
SotKIt 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 #baserock12:25
paulsherwoodisn't there a way to code it so it works with or without?12:25
paulsherwood(without changing version)?12:25
SotKno, I'd need to change the functionality of old versions of morph to do that12:27
SotKwell, 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 that12:27
paulsherwoodah, ok12:27
SotKand 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 do12:28
rdalei 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
ssam2rdale: yes. All of the current versions don't actually need migration scripts, I think12:32
ssam2we could remove some of them, though. The last released version of the Baserock reference systems contained Morph that supported up to v3, I think12:33
rdalei suppose my definition of needing a version number bump, would be that the change requires a conversion script12:33
ssam2so we could remove 0, 1, and 2 if we wanted12:33
SotKrdale: 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 too12:34
rdalewell i don't think we should be attempting to do that, it won't scale12:34
SotKthen I don't really see what the use of versioning gives us?12:35
rdalemy understanding is that if the version of definitions is older than the current morph, we would run suitable migration scripts12:36
ssam2rdale: yes12:38
ssam2rdale: but Morph still needs to *know* that it is too old, somehow12:38
ssam2rdale: introducing changes that would cause old versions of Morph to crash thus requires a version number increment12:38
rdalei 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
radiofreepaulsherwood: where does the ybd log go?12:39
richard_mawradiofree: stdout or stderr12:39
paulsherwoodradiofree: which one? stdout, and a file for each component. there's no file of the build log itself, i'm embarassed to admit12:39
radiofreeah, ok12:40
paulsherwoodi 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 somewhere12:43
robtaylorrdale: 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 that12:43
SotKI don't think I'd want a new log file created in my current directory each time I ran ybd12:43
SotKwe'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 script12:45
ssam2robtaylor: that's how I think it will work. The only thing is none of the versions so far have required any migration12:45
rdalerobtaylor: 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 features12:45
robtaylorssam2: i guess a minimum migration script would bump the version field then ;)12:46
SotKrdale: 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 example12:46
SotKthe latter sounds like a problem with the definitions, when actually morph just needs updating12:47
rdaleis that all the lists of version numbers do in the morph code?12:47
robtaylorrdale: yeah, i guess forcing forward moviment at least will make people try and fix issues rather than just downgrading ;)12:47
SotKrdale: yes, as far as I am aware12:47
rdaleok12:47
SotKactually, richard_maw's patches for strip commands introduce some code conditional on the version number12:48
SotKthey are not yet merged, however12:48
*** pacon has quit IRC12:58
*** richard_maw has quit IRC13:03
*** richard_maw has joined #baserock13:05
*** ChanServ sets mode: +v richard_maw13:05
*** sambishop has quit IRC13:12
*** sambishop has joined #baserock13:23
*** sam_ has joined #baserock13:38
*** sambishop has quit IRC13:38
*** lachlanmackenzie has quit IRC13:44
*** lachlanmackenzie has joined #baserock13:55
*** zoli__ has quit IRC14:43
*** zoli__ has joined #baserock14:44
*** zoli__ has quit IRC14:48
* SotK discovers that subsystems don't seem to get built when doing `ybd $some-cluster-with-subsystems`14:53
straycatcoincidentally,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
pedroalvarezstraycat: http://mashable.com/wp-content/uploads/2014/02/second.png14:57
straycat:)14:58
*** petefoth has quit IRC15:01
*** zoli__ has joined #baserock15:05
paulsherwoodSotK: can you raise an issue, please15:07
paulsherwood?15:07
SotKpaulsherwood: yeah sure, I'm working on a fix for it too15:07
paulsherwoodperfect :)15:07
paulsherwoodrdale: 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 breakage15:29
paulsherwoodfor example, we've already shown that upgrading distbuild can be non-trivial... which causes users to be reluctant to do it15:30
rdaleif we have very few users, and the ones we have won't upgrade, then allowing them to stay put seems like declaring the software obsolete15:31
rdalebut 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 code15:32
paulsherwoodrdale: 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 elsewhere15:34
*** nowster_ is now known as nowster15:34
rdalewe 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 that15:35
SotKand then say "morph can only support a single version, everything else gives an appropriate "please upgrade/downgrade definitions version" error?15:37
paulsherwoodcould this be done so that mostly the *interpretation* of the yaml was decoupled from the tooling?15:37
rdalebut 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 list15:37
rdale'build-depends: []' ==> '' is one i remember15:38
SotKindeed15:39
* Kinnison mumbles about how he said all of this months and months ago and was blithely ignored for 'expedience'15:39
paulsherwoodKinnison: we can't have all the things all at once, that's all15:39
paulsherwoodKinnison: you could take this just as confirmation that you're right, again :)15:40
SotKthat didn't *need* a forward migration script because morph doesn't mind if 'build-depends: []' is there, it just stopped enforcing its presence15:40
Kinnisonpaulsherwood: I'm tired of being shown to have been right months and months of effort later :-/15:40
paulsherwoodKinnison: me too.15:40
paulsherwood:)15:41
Kinnisonhrm :)15:41
ssam2rdale, SoTK: I agree on that plan15:41
ssam2rdale: all the previous changes are described here: http://wiki.baserock.org/definitions/historical/15:42
rdaleexcellent!15:42
* robtaylor imagines versions/<number>/{up,down}.py somewhere, perhaps with versions/<number>/definitions.md recording the documentation for that version15:44
rdalei 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 arch15:44
robtaylorthe 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 reality15:45
robtaylorhaving said that, its definitly better than nothing15:45
paulsherwoodrobtaylor: i'm hoping for something more automated/intelligent if possible15:48
paulsherwoodit may not be, of course :)15:49
* Kinnison has no problem with down migrations saying "No, can't do it"15:50
SotKHas the ybd strip-commands stuff been tested when building a cluster?15:52
SotKpaulsherwood, richard_maw ^^15:52
robtaylorpaulsherwood: well i guess you could have a test suite that does random up/down grades and tests it works with the relevent morph/ybd15:52
richard_mawSotK: I didn't, I looked at the cached artifact.15:52
robtaylorpaulsherwood: 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
SotKrichard_maw: it seems that its running the strip-command when "building" the cluster definition, and crashing15:54
SotKpaulsherwood, richard_maw: http://sprunge.us/BdQH15:55
paulsherwoodSotK: ouch !15:56
*** petefoth has joined #baserock15: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
paulsherwoodyup15:58
*** jonathanmaw has quit IRC16:01
paulsherwoodSotK: 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 separate16:01
SotKI don't see how we can fix this without special casing clusters though :/16:05
paulsherwoodhmmm16:06
* richard_maw doesn't see that as a problem16:06
richard_mawthey *are* fundamentally different things16:06
paulsherwoodyup, true16:06
richard_mawit just happened to accidentally work in the previous code16:07
paulsherwoodbut we want the possibility of deploying components16:07
* SotK doesn't see it as a problem either fwiw16:08
SotKpaulsherwood: what do you mean?16:08
richard_mawpaulsherwood: ehhh,16:08
richard_mawpaulsherwood: a lot of variables are only known at the system level16:08
richard_mawi.e. the architecture is passed down from the system16:08
richard_mawin morph16:08
* richard_maw isn't entirely comfortable with ybd passing it in on the command line16:08
richard_mawand we also want to be able to parameterise builds, possibly by setting fields in the system to be inherited16:09
paulsherwoodrichard_maw: yes, ok. but if that's the only variable you're worried about , i think it's easy to address16:09
richard_mawit's all the other variables we may want to add which is the trouble16:09
paulsherwoodok understood16:09
ssam2can 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
ssam2oh, I guess it's the 'a' operation16:12
richard_mawis there nothing in git log?16:12
ssam2I always thought you needed a newline over the 'a'16:12
ssam2http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/strata/build-essential/stage1-gcc.morph?id=fe5e9e45bb56bccb6c6ad755b21074ce4df26a02 -- not really16:12
ssam2s/over/after/16:12
* SotK gets back to the INITRAMFS_PATH error he started with16:23
paulsherwoodrichard_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 that16:24
richard_mawit may just be too late in the day16:24
paulsherwoodok, np. i'll leave it16:24
richard_mawmost components need their architecture, as it needs to go into the cache key16:25
paulsherwoodyup. but we don't want to have a definition of component per architecture16:25
paulsherwoodso if i build a component, i need to state the target architecture somehow, don't i?16:26
richard_maw…yes?16:26
paulsherwood17:08  * richard_maw isn't entirely comfortable with ybd passing it in on the command line16:26
paulsherwoodhow would you prefer it to be communicated?16:26
richard_mawas part of the system definition16:27
paulsherwoodi'm building a component. no system is to be inferred16:27
richard_mawand have it be passed down to the chunk definitions16:27
radiofreeI'm getting "clone: Invalid argument" with ybd16:28
paulsherwoodeek16:28
richard_mawpaulsherwood: but you need your variables to be defined somewhere, and IMO they only make sense together at the system definition level16:28
richard_mawradiofree: kernel not support namespaces?16:28
radiofreei have CONFIG_NAMESPACES=y and CONFIG_USER_NS=y16:29
paulsherwoodrichard_maw: i'm building individual components, or strata. arch still makes sense, imo16:29
paulsherwoodradiofree: can you paste the log?16:29
richard_mawradiofree: you may be missing the pid namespace16:29
radiofreeCONFIG_PID_NS=y16:29
radiofreeonly one missing is CONFIG_NET_NS but i'm assuming that doesn't need to be set?16:30
KinnisonI thought we isolated net too16:30
richard_mawradiofree: you assume incorrectly thre16:30
radiofreeah, so i do need that?16:30
richard_mawpaulsherwood: 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 IRC16:32
richard_mawpaulsherwood: 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_mawto 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
paulsherwoodrichard_maw: it's not 'hackily'. there are actual usecases requiring 'build this thing, which is not a system'16:33
radiofreerichard_maw: morph builds it fine16:33
paulsherwoodrichard_maw: separately i'm of the view that definitions in a given branch of a git repo should be uniquely defined :)16:34
radiofreehmm well this is stage1 binutils16:34
* radiofree just rebuilds with NET_NS16:34
richard_mawpaulsherwood: 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 definition16:35
paulsherwoodrichard_maw: yes, i get that. we have some way to go on making this tidy, though :)16:36
richard_mawwe could file the numbers off system definitions and call them something else, and you'd have such a definition16:36
richard_mawprovided we add a way of specifying an individual chunk/component, assuming that's the granularity you want to build/depoly16: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 is16:38
radiofreerichard_maw: thanks, it was CONFIG_NS16:39
paulsherwoodSotK: probably, unless it adds an excessive number of loc16:39
radiofreeNETWORK_NS even16:39
richard_mawpaulsherwood: I suppose `call(['find'], stdout=f, stderr=f)` is also an attempt to do it with the fewest loc16:39
richard_mawbtw, you should use stderr=subprocess.STDOUT, or it can get weird and mix the streams in a way that the subprocess didn't produce16:40
paulsherwoodrichard_maw: yup, but also it was the easiest solution i knew. if you have something better, i'm happy to consider it16:49
richard_mawnothing 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+exec16:51
paulsherwoodrichard_maw: that would be better, then. i wasn't happy using find16:52
richard_mawthough 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 code16:52
* paulsherwood is undecided, then16:53
*** sam_ has quit IRC17:01
persiaTrying to read backscroll ,I think we have competiting definitions of "system".17:03
persiaOn the one hand, a "system" is a set of software that is built and packaged for some end.17:03
ssam2i'd call that a "package"17:03
persiaOn the other hand, a "system" is a set of software that comprises some self-hosting execution environment.17:04
persiassam2: So the content of a DVD would be a "package"?17:04
ssam2that'd be a "movie" ?17:04
persiaWhich I believe is currently a synonym for "system" in morph semantics :)17:04
ssam2i don't have a strong opinion on this, but I think treating "deploy as a system" as separate to "deploy as a package" is sensible17:05
ssam2and am in favour of supporting both17:05
persiaIn such a model, is the movie a "package" or a "system"?17:06
persiaSimilarly, how about the DVD menu?17:06
* paulsherwood has no braincells left for this today17:06
persiaTo 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
ssam2agreed. It may be that we move to only using the terms "system" and "package" at deploy-time17:08
persiaI 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
ssam2presumably at deploy time we'd call a DVD a "dvd"17:08
persiaDVD is a logical representation of bits, like a tarball.17:09
persiaThe specific content that lets one execute a menu, watch a movie, etc. is software, which ought fit into either "package" or "system".17:09
ssam2I guess so17:09
ssam2surprisingly, I've managed to build stage1-binutils and stage1-gcc on Mac OS X using YBD17:10
paulsherwoodnot package, please!17:10
paulsherwoodssam2: w00t!!!!17:11
ssam2stage2-linux-api-headers doesn't build, though, unsurprisingly17:11
persiaOne 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 IRC17:19
*** ssam2 has quit IRC17:26
radiofreepaulsherwood: master seems to have fixed the issue on fedora 1917:30
* radiofree is trying it on his personal craptop, so this may take a while17:30
radiofreeit'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/Linux17:31
*** edcragg has quit IRC17:37
*** sambishop has joined #baserock17:38
jjardonHi, is it https://mason-x86-64.baserock.org/ building something?18:07
*** lachlanmackenzie has quit IRC18:21
*** edcragg has joined #baserock18:51
paulsherwoodradiofree: cool!18:53
radiofreestage2-fhsdirs ... mount (MS_BIND): No such file or directory19:19
radiofreemaybe deleting tmp fixes this19:20
radiofreehttp://fpaste.org/230115/79130714/19:21
*** edcragg has quit IRC19:22
radiofreeand the build log http://fpaste.org/230116/14337913/19:22
radiofreewasn't this an issue in the past?19:23
paulsherwoodradiofree: it's a race. run it again, should work19:31
paulsherwoodmy forking is too smart there https://github.com/devcurmudgeon/ybd/issues/5119:32
paulsherwoodbasically i fork to delete the old staging, while starting work on the next chunk... because deleting can take some time on my machine19:33
paulsherwoodtrouble is that the sandboxing tries to lock off all directories, including the tree which is being deleted19:33
paulsherwoodi can drop the fork, but that'll slow it down a bit. am hoping for a brainwave19:34
radiofreeit seems to have worked, thought the output is a little odd now19:35
paulsherwoodi wonder if the sandbox can safely ignore the tmp files?19:35
paulsherwoodradiofree: odd?19:36
paulsherwoodi know some changes got made today19:36
radiofreeit scrolled off my screen session19:37
radiofreehmm19:38
radiofreei'm building 2015-06-08 19:36:19 [stage2-gcc] Start build19:38
radiofreeactually it's ok19:38
radiofreeif 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 staging19:40
radiofreethough that might not help with this sandboxing actually19:40
radiofree(i haven't looked at the sandboxing code for morph either, no idea how it's working)19:41
paulsherwoodwhat's the right architecture for Moonshot?20:00
paulsherwoodError: unsupported Morph architecture: aarch6420:01
radiofreeif you're using ybd, it's armv8l64 to remain consistent with baserock20:05
radiofreehowever you'll need another patch to ybd to get it working20:05
radiofreejust built gcc!20:05
*** sambishop has quit IRC20:12
*** sambishop has joined #baserock20:13
paulsherwood:-)20:18
paulsherwoodradiofree: do you have that patch anywhere/20:19
paulsherwood?20:19
radiofreejust pushed it to github, however i'm getting a 404 when i try and do a pull request20:20
radiofreehttps://github.com/jamespthomas/ybd/commit/fa3ce50053e0960a491b3c9a072aa3613a10612820:20
radiofreepaulsherwood: here's the patch http://paste.fedoraproject.org/230138/95009143/20:23
paulsherwoodradiofree: thanks, i've managed to pull it. shall i merge it, too?20:24
radiofreeit should work20:26
radiofreei suppose i better actually test it20:26
paulsherwood:)20:27
* paulsherwood keeps hitting 'too many mounts' on the Moonshot20:27
radiofreereboot?20:28
radiofreeif you delete a cached artefact for something that another component down the line depends on (e.g gcc) the build fails20:29
*** sambishop has quit IRC20:29
*** sambishop has joined #baserock20:30
paulsherwoodyup. that's issue #15. iirc trying to fix it leads to a weird import recursion problem20:30
paulsherwoodmounts seems to be hardcoded at 50 somewhere20:31
*** zoli__ has quit IRC20:53
paulsherwoodyour patch is working for me, merged!20:53
*** zoli__ has joined #baserock20:53
radiofreeyou won't actually be able to tell it's worked until you get to building gcc20:54
radiofree(proper gcc)20:54
radiofreeon aarch6420:54
radiofreeactually i'll try it on a jetson as well to make sure it's not buggered that up20:55
paulsherwoodok :) well, if it doesn't work, reversion is cheap too :-)20:57
*** zoli__ has quit IRC20:58
*** zoli__ has joined #baserock21:19
*** sambishop has quit IRC21:20
*** sambishop has joined #baserock21:21
*** sambishop has quit IRC21:25
*** zoli__ has quit IRC21:26
*** zoli__ has joined #baserock21:26
*** zoli___ has joined #baserock21:29
*** zoli__ has quit IRC21:33
*** zoli__ has joined #baserock21:35
*** zoli__ has quit IRC21:36
*** zoli__ has joined #baserock21:37
*** zoli___ has quit IRC21:37
radiofreedidn't work >.<21:38
radiofree(on aarch64 at least, though i'm now starting to think it's something additional)21:45
radiofreerun again, builds, looks like it's an issue similar to fhs-dirs21:48
* radiofree will leave it building the system and look at that tomorrow21:48
rjekradiofree: Are you still at work?!21:50
rjek(he says, working.)21:50
radiofreeno, remote access!21:50
rjekSo working, just not from the office? :)21:50
* rjek turns the lights out21:51
*** zoli__ has quit IRC23:15
*** zoli__ has joined #baserock23:15
*** zoli__ has quit IRC23:20
*** sambishop has joined #baserock23:23
*** Stanto has quit IRC23:38

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