| *** zoli__ has quit IRC | 07:02 | |
| *** zoli__ has joined #baserock | 07:02 | |
| *** zoli__ has quit IRC | 09:04 | |
| *** zoli__ has joined #baserock | 09:04 | |
| *** zoli___ has joined #baserock | 09:06 | |
| *** zoli__ has quit IRC | 09:06 | |
| *** zoli___ has quit IRC | 09:17 | |
| paulsherwood | thinking furher about forward-backward compatibility i made https://docs.google.com/spreadsheets/d/17ytSkN22wqfLFd2IWCdvcBhzSD--93dpbEm6bvUgnBI/edit#gid=0 | 10:25 |
|---|---|---|
| paulsherwood | i'll add other examples if i get time | 10:25 |
| rjek | Morning, paulsherwood. | 10:25 |
| straycat | jjardon, didn't seem to, if there's no version file the function returns None rather than 0 | 10:25 |
| * rjek looks | 10:25 | |
| paulsherwood | morning rjek :) | 10:26 |
| paulsherwood | it's still fuzzy in my mind - an old system may or may not have an old morph on it | 10:26 |
| rjek | forwards/backwards compatability is always a pain when there are so many variables involved, but it's often worthwhile pain. | 10:27 |
| paulsherwood | yup. am trying to help clarify policy/approach, given i expect rate of change to have to increase soonish | 10:28 |
| paulsherwood | and it would be a shame to p*** off users with increasing frequency if we can avoid it :-) | 10:29 |
| paulsherwood | straycat: does that make it behave differently, though? | 10:31 |
| * paulsherwood has morph and definitions in very specific pieces at the moment so can't check trivially | 10:31 | |
| straycat | right now, probably not, but it could if we have sections of code that are conditional on the version number i think | 10:32 |
| paulsherwood | ah, correct | 10:33 |
| rjek | We've had quite a few instances recently where people have come in here and said "I get this error", to which the solution is "upgrade your morph to master"; even having a more helpful error here would be an improvement. | 10:33 |
| paulsherwood | hmm... i guess you don't mean to suggest that all morph errors include the line 'please upgrade to latest morph' ? ;-) | 10:35 |
| rjek | No :) | 10:35 |
| rjek | But if we go ahead with your suggestion that morph at least /try/ in the face of warnings at the top of its output ("I don't understand this VERSION, but I'm going to try anyway"), if the build fails it should probably say at the end of its output ("Try upgrading morph") | 10:36 |
| rjek | When things go wrong, people almost never look at the start of output :) | 10:36 |
| pedroalvarez | paulsherwood: I guess you can rename pylru as something more generic that implies that Morph needs more things to run. The same thing happened whith cliapp a while ago. | 10:37 |
| * straycat thought it might be useful to have a mechanism that collects warnings and prints them at the end | 10:37 | |
| rjek | straycat: +1 | 10:37 |
| ratmice__ | I think if the warn and continue approach prevails, a strict option to parse and fail when hitting an unknown version/fields should be considered | 10:38 |
| * rjek is very proud of his command line parser that does that, having been fed up with so little software that does it :) | 10:38 | |
| rjek | ratmice__: Or perhaps the inverse; a --ignore-warnings | 10:38 |
| rjek | --just-get-on-with-it | 10:39 |
| rjek | People could always pop the option in their morph.conf; although I'd still suggest the output includes "ignoring some warnings/errors; build may not be reproducible" or similar. | 10:39 |
| paulsherwood | pedroalvarez: yup. i just wanted to start with specific examples, and then try to infer the generic factor(s) | 10:44 |
| ratmice__ | not sure if there is the possibility that an ignored option could turn into a successful compilation but end up with runtime errors, and if this happens how far removed from the build logs could someone end up before someone notices | 11:01 |
| straycat | just need to check something, is version 0 to be treated as some sort of special version where morph just applies a "default" behaviour, essentially ignoring versions, or is it a first version? | 12:18 |
| *** zoli__ has joined #baserock | 12:19 | |
| *** zoli__ has quit IRC | 12:23 | |
| * straycat guesses that if lack of version file means 0 then 0 means "current" | 12:30 | |
| paulsherwood | no, lack of version file was to be assumed version 0. version 1 and onwards should only be achievable explicitly in version file | 12:50 |
| paulsherwood | (i believe) | 12:50 |
| straycat | Okay and version 0 is just a first version, so in the absence of a version file morph will assume you're using the first version of definitions, version 0 | 13:01 |
| persia | STating it like that gives me the impression there is something special about the exact format labelled "0", which worries me, as the current morph has some support for variations in the format. | 13:37 |
| *** zoli__ has joined #baserock | 13:44 | |
| *** pacon has quit IRC | 13:49 | |
| *** pacon has joined #baserock | 13:51 | |
| paulsherwood | straycat: yes | 14:00 |
| paulsherwood | persia: i don't understand what you mean | 14:00 |
| persia | Unversioned definitions has had several formats. I seem to recall prior statements that some parts of morph existed to support some features that are not present in the current HEAD of definitions master. | 14:01 |
| persia | I don't think we'd do well to declare that the format that is formally expressed as version "0" is something in particular, and force morph to handle it explicitly. | 14:02 |
| persia | Rather, I think we ought assume unversioned is a mess, and try to deal with it for a bit, but focus on getting to version 1, which we can declare as a specific format, and mostly worry about versions from that point. | 14:02 |
| persia | And once the transition away from unversioned is complete, I think the entire debate about lack of version becomes meaningless. | 14:03 |
| persia | Because very soon it won't make sense for morph to try to handle unversioned, as that will be too old. | 14:03 |
| persia | Plus, as there are a large number of different formats that were unversioned, we can't clean up the legacy mess if we try to handle them. | 14:04 |
| paulsherwood | i agree with most of what you're saying, in theory. how do you propose to 'deal with it for a bit' ? | 14:04 |
| persia | For that, it makes sense to treat unversioned with essentially similar parsing logic to what we have today, as you suggest. | 14:06 |
| persia | But it doesn't make sense to suggest that unversioned is specifically "Version 0", as if that is a defined format. | 14:06 |
| *** pacon2 has joined #baserock | 14:06 | |
| persia | Because it becomes tempting to clean up the "version 0" support code, which breaks earlier transitional unversioned definitions. | 14:06 |
| persia | To a certain degree, it seems to me that this might be a sensible time to branch morph, so we have a morph that moves to bugfix-only that can handle unversioned+0, and another branch that can handle 0+1 and complains for unversioned. | 14:08 |
| persia | Where "0" is specifically the format from the time that we declared version 0. | 14:08 |
| persia | DIfferent branches can be different major versions, so morph 0.x.y is the one that handles transitionals, and morph 1.x.y handles 1, etc. | 14:08 |
| *** pacon has quit IRC | 14:09 | |
| paulsherwood | i think the idea was to move on from 0 with tiny changes, as quickly as possible. no attempt to stay with or tidy up 0 | 14:09 |
| persia | I specifically don't think we want to increment the major version every time we change definitions, but we probably want to have a new major version every time we drop support for several older formats, so we can tell folk to migrate by using version A, then version B, etc. to get from some old state to current morph. | 14:10 |
| paulsherwood | at the meetup the broad idea seemed to be integers, not i.j.k | 14:11 |
| persia | That makes sense. I just think it is wrong for any morph except for the transitional morph to assume unversioned == version 0. | 14:11 |
| persia | I'm talking about morph versions. Definitions is integers. | 14:11 |
| persia | I think it would be a mistake to tie these. | 14:11 |
| persia | So, I imagine morph 0.x.y being a continuing series with small bugfixes for critical bugs that can handle unversioned+0 | 14:11 |
| persia | And morph version 1.x.y being a continuing series with feature adds that can handle definitions 0,1,2,3,... | 14:12 |
| * paulsherwood struggles with the complexity | 14:12 | |
| persia | And morph version 2.x.y being a continuing series with feature adds that is introduced when morph 1.x.y moves to bugfix mode that can handle definitions versions k, k+1, k+2, k+3, ... | 14:13 |
| persia | It's *less* complex. | 14:13 |
| persia | A similar situation is deciding which versions of glibc and which versions of linux work together. | 14:13 |
| * straycat can't see a compelling reason to branch morph like that | 14:14 | |
| persia | As long as we assert that morph versioning is the same as definition versioning, we have to deal with all sorts of odd complexities about how we deal with compound trasitions. | 14:14 |
| persia | straycat: The main reason is to allow us to drop support for all sorts of old stuff while still being able to apply bugfixes to a morph that can support the old stuff. | 14:14 |
| persia | It matters more when we get to definitions version k. | 14:15 |
| * paulsherwood backs out of this... confused again | 14:15 | |
| persia | But it also allows us to escape the unversioned == version 0 mess. | 14:15 |
| straycat | I'm also not sure where morph versioning came into this | 14:18 |
| persia | Part of why I am excited about definitions versions is that it allows us to remove old compatibility code from morph. | 14:19 |
| persia | Another reason I'm excited is that it allows us to modify definitions in a way that morph can have explicit compatibility routines, rather than heuristics. | 14:20 |
| persia | But this causes a transition issue, because we need heuristics to handle unversioned definitions. | 14:20 |
| persia | Most software projects that want to support some features, and also want to drop support for those features, do this by having releases. | 14:21 |
| persia | And there is generally a separte branch for each release to allow for bugfixing to the release without forcing folk to accept all the new features (which may not work in their environment due to things that were deprecated). | 14:22 |
| persia | I suggest we deal with morph having difficulty understanding how to get from unversioned to version 0 to version 1, etc. by following this model. | 14:22 |
| straycat | I don't follow, morph is already at version 1, the series I have in flight puts us up to 2 | 14:24 |
| persia | I thought that was the definitions format. | 14:25 |
| straycat | yes sorry that's what I meant | 14:26 |
| persia | OK. | 14:27 |
| persia | So I suggest that morph acquire a version number. | 14:27 |
| persia | And then a new branch be made for stable changes to that version number | 14:27 |
| persia | And then your branch land, giving morph a new stable version | 14:28 |
| persia | And we expect the new version number to be able to handle 3, 4,5, etc. until we need to do a transition. | 14:28 |
| persia | And if folk need to deal with unversioned, they go back and use the morph that was branched as stable prior to your series landing. | 14:28 |
| persia | And then when we get to definitions version k, we do the same branch&increment to handle that transition. | 14:29 |
| straycat | The alternative is to identify the heuristics we have and instead of removing them attach conditionals to them so that they only run for unversioned/version 0 definitions | 14:29 |
| persia | Yes, but I assert that unversioned != version 0. | 14:30 |
| persia | We've had too many different unversioned things, and too many leftover heuristics. | 14:30 |
| straycat | My series makes unversioned == version 0 | 14:30 |
| straycat | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=baserock/richardipsum/existential-fix | 14:30 |
| persia | Yes, which is the part that started me complaining about it. | 14:30 |
| straycat | Okay, so the wiki lied to me | 14:31 |
| persia | Not necessarily: I might disagree with the wiki. | 14:31 |
| persia | I might even be completely wrong. | 14:31 |
| persia | And I certainly didn't attend the versioning session at the meetup. | 14:31 |
| straycat | Neither did I :/ | 14:31 |
| straycat | http://wiki.baserock.org/meetup/declarative-definitions/ | 14:32 |
| straycat | "The Definitions directory tree contains a file called VERSION. If this file is not present, tooling may assume definitions-V0 or fail gracefully" | 14:32 |
| straycat | (ftr) | 14:32 |
| straycat | So, the new branch of morph could fail gracefully for unversioned | 14:33 |
| persia | And suggest that folk who need unversioned support try the morph from the stable branch. | 14:34 |
| persia | Similarly, a bugfix patch could land on the stable branch that checked for definitions version >1, and suggested upgrading morph. | 14:34 |
| straycat | Okay, this seems like a pretty huge change, guess an RFC should go to the list before anything is done | 14:34 |
| persia | Probably. | 14:35 |
| persia | You can also do it the other way: I just think branching is easier when we want to support two different models. | 14:35 |
| persia | That being easier in code, and easier for people to think about "morph version X, supports definitions A, B, C; morph version Y supports definitions C, D, E; etc." | 14:36 |
| persia | But it is a vast change from the prior culture of asserting that "Basrock" has a version, which is implied to be related to multiple components. | 14:36 |
| straycat | I like the idea of a separate branch to support legacy definitions, allowing us to remove code we don't need anymore from current morph | 14:38 |
| straycat | without breaking things for older definitions | 14:38 |
| persia | I eventually imagine us having a new morph branch every year or two, and feeding bugfixes to 2-3 of them at any time. | 14:39 |
| persia | Whereas I hope definitions formats change more frequently, as we find better ways to express things. | 14:39 |
| straycat | Do you want to send this suggestion or shall I? I know which of us is the better writer :) | 14:44 |
| *** pacon2 is now known as pacon | 14:44 | |
| persia | I still owe the list of whole bunch of things. Waiting on me to submit an RFC may delay you unacceptably long. | 14:47 |
| straycat | Okay | 14:48 |
| straycat | Should the split be legacy: unversioned,0,1 current: >=2 ? Or legacy: unversioned current: >= 0 ? We could go back to the checkout before versioning was added and branch from that in the latter case | 14:50 |
| persia | I would do morph version 0.1 supporting unversioned, 0, 1; and morph version 1.0.1 supporting 1,2 to start. | 14:51 |
| persia | So that folk could transition against definitions version 1. | 14:51 |
| straycat | makes sense | 14:53 |
| straycat | i'll make the needed changes to this series then and submit the series as an rfc with this suggestion in the cover letter | 14:54 |
| persia | Sounds like an excellent plan. | 14:56 |
| persia | If the RFC is approved, it may make sense to have a separate series targeting the stable branch that detects defintions version > 1, and suggests using a different morph. | 14:57 |
| persia | (which series should never go to master) | 14:57 |
| * straycat nods | 15:15 | |
| *** zoli__ has quit IRC | 16:00 | |
| *** zoli__ has joined #baserock | 16:01 | |
| *** zoli___ has joined #baserock | 16:02 | |
| *** zoli__ has quit IRC | 16:05 | |
| *** zoli___ has quit IRC | 16:07 | |
| *** CTtpollard has joined #baserock | 16:56 | |
| *** CTtpollard has quit IRC | 16:58 | |
| paulsherwood | anyone know the difference between 'config.status:994: creating Makefile' and 'config.status:1002: creating Makefile' | 21:49 |
| paulsherwood | is it just a line number? | 21:49 |
| robtaylor | paulsherwood: i'd expect so, what's the context? | 21:59 |
| paulsherwood | i'm still hunting the ghost in my machine | 22:00 |
| paulsherwood | that's the only difference in config.log - which now makes me wonder if the path to my staging is too long, causing linewrappings | 22:01 |
| robtaylor | paulsherwood: hmm, that shouldn't happen | 22:01 |
| robtaylor | paulsherwood: have you got the two config.status's in qurestion | 22:02 |
| paulsherwood | yup | 22:02 |
| robtaylor | paulsherwood: can you pastebin them? | 22:02 |
| paulsherwood | morph's http://paste.baserock.org/yiqazamucu | 22:04 |
| paulsherwood | ybd's http://paste.baserock.org/ecivaworah | 22:05 |
| paulsherwood | (i've used sed to replace the staging dirs) | 22:06 |
| paulsherwood | the diffs seem to be linewrappings http://paste.baserock.org | 22:07 |
| robtaylor | paulsherwood: so seems to be something wrong with your STRIP_FOR_TARGET,RANLIB_FOR_TARGET,OBJDUMP_FOR_TARGET,NM_FOR_TARGET, LD_FOR_TARGET, AS_FOR_TARGET,AR_FOR_TARGET, LD, | 22:09 |
| robtaylor | something weird going on with TOPLEVEL_CONFIGURE_ARGUMENTS in both cases | 22:09 |
| robtaylor | paulsherwood: so | 22:10 |
| robtaylor | S["STRIP_FOR_TARGET"]="/STAGING/tools/bin/../lib/gcc/x86_64-bootstrap-linux-gnu/4.9.2/../../../../x86_64-bootstrap-linux-gnu"\ | 22:10 |
| robtaylor | "/bin/strip" | 22:10 |
| robtaylor | is yours | 22:10 |
| robtaylor | S["STRIP_FOR_TARGET"]="/STAGING/tools/bin/../lib/gcc/x86_64-bootstrap-linux-gnu/4.9.2/../../../../x86_64-bootstrap-linux-gnu/bin/strip" | 22:10 |
| robtaylor | is morphs | 22:10 |
| robtaylor | paulsherwood: so some issue with your concatenation, i guess? | 22:10 |
| paulsherwood | i'm not concatenating that | 22:10 |
| paulsherwood | that's configure, wrapping | 22:11 |
| robtaylor | paulsherwood: no | 22:11 |
| robtaylor | paulsherwood: yours has '\<newline>' in | 22:11 |
| robtaylor | between ../x86_64-bootstrap-linux-gnu and /bin/strip | 22:11 |
| paulsherwood | oh, perhaps. but i have no clue what could be doing that | 22:12 |
| robtaylor | (p.s. i just ran the two config.status's though meld to find this quickly, useful tool, but side by side diff would also help) | 22:12 |
| paulsherwood | ack | 22:13 |
| robtaylor | paulsherwood: probably how you set 'STRIP' in the environment | 22:13 |
| robtaylor | when you run configure | 22:13 |
| * paulsherwood has never heard of STRIP, and neither has YBD, and apparently neither has morph ? :) | 22:14 | |
| robtaylor | hmm, configure must be assembling it | 22:14 |
| robtaylor | paulsherwood: could you pastebin the YBD config.log? | 22:15 |
| paulsherwood | it's a struggle - it's really long. i can tell you that the only difference vs morhp's appears to be the config.status line numbers... | 22:19 |
| paulsherwood | -config.status:994: creating Makefile | 22:19 |
| paulsherwood | +config.status:1002: creating Makefile | 22:19 |
| robtaylor | ooi, does baserock have 'haste' ? | 22:19 |
| robtaylor | (the haste command, that is) | 22:19 |
| paulsherwood | nope | 22:20 |
| paulsherwood | i'm going to shorten my stage path... the differences i see in that status are mostly odd concatenations for longer lines | 22:20 |
| robtaylor | hum, someone should add haste-client to the devel environment | 22:20 |
| robtaylor | paulsherwood: where do you pass in "/STAGING/tools/bin/../lib/gcc/x86_64-bootstrap-linux-gnu/4.9.2/../../../../x86_64-bootstrap-linux-gnu" ? | 22:21 |
| paulsherwood | same way morph does, afaik | 22:22 |
| robtaylor | which is? | 22:22 |
| robtaylor | i think you have a newline on the end somehow | 22:22 |
| robtaylor | paulsherwood: paste it using this command: curl -F 'sprunge=<-' http://sprunge.us http://sprunge.us/aXZI | 22:22 |
| robtaylor | oh sorry, i mean: | 22:23 |
| robtaylor | cat config.log | curl -F 'sprunge=<-' http://sprunge.us | 22:23 |
| robtaylor | and paste the address it returns | 22:24 |
| paulsherwood | http://sprunge.us/eTUI | 22:24 |
| robtaylor | thanks | 22:24 |
| paulsherwood | passsing in is done by a combination of a 'clean environment' and containerisation settings, and the configure-commands | 22:26 |
| robtaylor | paulsherwood: i *think* you might be missing a final "'" off the end of the configure line | 22:27 |
| robtaylor | configured by ../configure, generated by GNU Autoconf 2.64, with options \" '--build=x86_64-unknown-linux-gnu' '--host=x86_64-bootstrap-linux-gnu' '--target=x86_64-bootstrap-linux-gnu' '--prefix=/tools' '--libdir=/tools/lib' '--with-local-prefix=/tools' '--with-build-sysroot=/STAGING/STAGING/STAGING | 22:28 |
| robtaylor | Copyright (C) 2009 Free Software Foundation, Inc. | 22:28 |
| robtaylor | This config.status script is free software; the Free Software Foundation | 22:28 |
| robtaylor | gives unlimited permission to copy, distribute and modify it." | 22:28 |
| robtaylor | very odd line that | 22:28 |
| * robtaylor is a bit bemused what could be happening there | 22:30 | |
| paulsherwood | that's probably my sed | 22:30 |
| robtaylor | ah | 22:30 |
| robtaylor | can i have an un-sedded version? :) | 22:30 |
| paulsherwood | http://sprunge.us/CIQI | 22:31 |
| paulsherwood | and the status http://sprunge.us/RFQc | 22:32 |
| paulsherwood | (but this is with my shorter path, now) | 22:32 |
| paulsherwood | and as a result the linenumber is now 994, same as morph's | 22:34 |
| robtaylor | ahah, ok, it was the sed introducing the newline | 22:34 |
| paulsherwood | nope | 22:34 |
| robtaylor | no, really, it was | 22:34 |
| robtaylor | run the sed again and see | 22:35 |
| paulsherwood | the 994 was reported in configure's result, before i sed anything | 22:35 |
| paulsherwood | my sed makes lines shorter, not longer. and i'm only running it *after* configure so i can compare morph result with ybd | 22:35 |
| robtaylor | line legth is not the issue here | 22:36 |
| paulsherwood | you may still be right :) | 22:36 |
| paulsherwood | but note there's no sed in the ybd run, only in my attempt to analyse it afterwards | 22:37 |
| paulsherwood | (sed -i 's|src/staging/[^/]*/[^/]*|STAGING|g' /src/staging/build-essential-20150318-190951/stage2-gcc/stage2-gcc.build/o/config.l | 22:41 |
| robtaylor | hmm, i guess configure may have some maximum line length for some old unix shell and that was causing your difference | 22:41 |
| paulsherwood | i think that's more likely | 22:41 |
| paulsherwood | if it is that, i'll be a happy camper! :) | 22:42 |
| robtaylor | HP-UX 11.00 and IRIX 6.5 Awk require that input files have a line length of at most 3070 bytes. | 22:43 |
| robtaylor | apparently | 22:43 |
| robtaylor | oh, thats just awk | 22:44 |
| * robtaylor bemused | 22:54 | |
| *** pacon has joined #baserock | 22:54 | |
| paulsherwood | im rebuilding ... j1 takes a while | 23:01 |
| paulsherwood | well the output now is different from what it was before, and different from morph... so that's progress of a sort ;) | 23:15 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!