IRC logs for #baserock for Wednesday, 2016-02-24

*** cosm has quit IRC00:02
*** edcragg has quit IRC00:04
*** gtristan has joined #baserock02:26
*** toscalix has joined #baserock07:55
*** fay_ has joined #baserock08:13
*** fay_ is now known as faybrocklebank08:13
*** ctbruce has joined #baserock08:32
*** paulw has quit IRC08:35
paulsherwoodjjardon: so good news, and bad news i think...08:37
paulsherwoodadding a 'no transitive depends' option in ybd seems to be one line of code08:37
paulsherwoodbut the cache key calculation doesn't take this into account08:38
* paulsherwood thinks a bit more08:41
*** bashrc_ has joined #baserock08:54
*** gtristan has quit IRC09:15
*** tiagogomes_ has joined #baserock09:24
*** jonathanmaw has joined #baserock09:46
*** gtristan has joined #baserock09:49
*** franred has joined #baserock09:59
*** ssam2 has joined #baserock10:08
*** ChanServ sets mode: +v ssam210:08
*** edcragg has joined #baserock10:12
paulsherwoodcan we add 'test-commands' to the default build-steps at some point, to be optionally run if folks want to test a build?11:02
mwilliams_ctHow would you envision that being used? eg after a system is built, first deploy then do some sort of test on the deployed system?11:06
paulsherwoodbjdooks: can you dialin to a meeting?11:07
ssam2yes I think "test" is too abstract a term11:08
ssam2s/abstract/generic/11:08
paulsherwoodoops, ww11:08
ssam2I quite like https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests as a concrete proposal11:09
ssam2I don't think it's got very far11:09
paulsherwoodssam2: 'test' is a start, better than nothing?11:09
ssam2my point is everyone has their own conception of what it means. If you say "support for testing" but only support one specific way of doing it, most people will be disappointed that it doesn't match whatever their preconception was11:10
ssam2i'd rather say "support for running tests of chunks that follow the InstalledTests approach at build time" (which I know is less marketable :-)11:11
* richard_maw would like to point out that if you want to make the test-commands stage optional, you need to have a way of ensuring that if you run them, it doesn't change how install-commands works11:11
rdalein the ybd test i'm writing i monkeypatch assembly.run_build() - maybe having different sorts for run_build() for doing different things in ybd would be useful, instead of using flags like 'no_build' in the function11:11
richard_mawyou could either run with the staging area read-only, to ensure test-commands don't build anything that is later installed, or copy the build and install directories to run tests in11:13
persiaOr run in two phases: perform a build, cache it, run the tests, store the test results.11:13
persiaPersonally, I like the idea of moving testing-dependencies out of either build-dependencies or runtime-dependencies, because it allows one to have more interesting tests without affecting the final system.11:14
persiaThat said, I'm not that much of a fan of component testing: I'd rather perform full functional testing against an extant system.  The only problem is that having such a test suite is a massive rewriting effort, and ignores all the good work done by the component developers to test their stuff.11:15
richard_mawpersia: is that running test-commands after install-commands then?11:15
richard_mawor am I missing a larger point11:16
*** locallycompact has joined #baserock11:16
ssam2it's e.g. testing gedit inside a running gnome-shell environment running on an x server11:16
ssam2rather than running gedit's `make check` which will test some internal helper code but not much else11:17
persiaMy thought was to run install-commands, throw away the chroot, toss up a new one, and then run tests in that, so that we were testing that which was installed, rather than whatever happened to be in the build area.11:17
ssam2both of these things are useful, for different reasons11:17
persiaRight.  The problem with doing it as I suggest is that we probably can't use `make check` or whatever.  If we can use that, we need to have the dependencies for the tests (both runtime and build-time) installed in the build chroot, which may change build behaviour.11:18
ssam2unless the component follows the https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests approach11:19
richard_mawpersia: we could use a copy of the build directories *and* provide additional components in the staging area11:20
persiarichard_maw: I think I'm missing something.  My immediate response is "that still doesn't test the stuff we intend to put in the system", but I suspect I'd respond differently if I understood.11:21
persiassam2: Do you imagine having a separate artifact with the tests, so we'd install the component, the runtime dependencies, the tests, and the test runtime dependencies, and test that way?11:23
richard_mawthere is a concern that install-commands could produce something different than what was produced at build-commands time11:23
ssam2yes11:23
persiaI like that a lot!11:23
ssam2:) I think the downside to that approach is it requires changes to most components to add a `make installed-tests` target, and not sure how many would accept such patches11:24
persiarichard_maw: Yes: there is no restriction on what can be put in the install: target in a build system.  I have seen build systems that perform string modifications, strip binaries, create additional empty files, etc. during "install".  I do not expect I've seen all the oddities that exist upstream.11:24
richard_mawstill sounds difficult to reuse `make check` style tests, which expect to be running things from the build directory, unless ssam2 is suggesting the build directory is an artifact11:24
richard_mawpersia: sounds like we need both styles then11:25
persiaI think the suggestion is to lead an initiative for social change to encourage adoption of testing software post-install.11:25
*** franred has quit IRC11:25
persiaSadly.11:26
ssam2richard_maw: the idea is to make the `make check` style tests function when installed in /usr/share/installed-tests, basically. the wiki page I linked to goes into a bit of depth about this11:26
ssam2this is already works in a few gnome components, glib at least11:27
ssam2-is11:27
persiaautopkgtest does the same sort of thing, and there are tests for a moderate number of components using that framework11:29
persiahttp://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst11:29
edcragghas anyone ever seen a 'coercing to unicode' error when building with morph, seems to be something to do with cliapp running `git update ref`?11:33
* rjek wonders if that's the error you get due to Python assuming pathnames are UTF8?11:33
pedroalvarezthat one is new11:33
edcraggit gets None for some reason11:34
bwhrjek: I don't think it does assume that any more11:34
richard_mawedcragg: got a stack trace?11:34
pedroalvarezalso morph --version please11:35
richard_mawbwh: it used to be marginally better in python 2.x for file paths, since it wouldn't default to returning you a unicode for file paths in the standard library11:35
richard_mawbwh: now you need to jump through many more hoops to get it to give you file paths as byte strings11:35
bwhrjek: There's some hack to convert non-UTF-8 byte sequences to unpaired surrogates11:36
bwhand then back11:36
richard_mawbwh: and you can crash the new proposed pathlib module for python 3.x with an assertion failure if your home directory isn't in a valid utf-8 path11:36
bwhyay11:36
rjek!yay11:36
richard_mawbwh: also, os.fs{en,de}code aren't round-trippable in all circumstances11:37
edcraggrichard_maw: http://paste.baserock.org/eruboyisux11:37
edcraggpedroalvarez: bda9fe51c8e22d4c8c5ad8325094abd6ed25706d11:37
richard_mawgrr, there's a wart in the implementation of subprocess making it difficult to work out exactly what failed there11:41
richard_mawyou need to look at the .child_traceback value of that exception to see what actually broke11:41
richard_mawbut it sounds like maybe the problem is that None was passed where it shouldn't11:41
richard_mawmust be one of the arguments to runcommand, as everything under it is fairly well isolated11:42
paulsherwoodrichard_maw, persia - noted. that's what i would expect to do11:44
paulsherwood(test in a separate chroot)11:44
* paulsherwood expects that even in the worst case, tests could be achieved by having a foo-tests chunk as build-depend, and invoking their commands in test-commands of foo?11:46
*** franred has joined #baserock11:49
persiapaulsherwood: What is your worst case intended to achieve?  In my mind, I'd rather have the tests be just part of foo.11:54
paulsherwoodpersia: my worst case example is historic - I used a framework whose tests required Qt and a load of extra stuff. no way i would be able to avoid adding extra chunks in that situation, i think11:55
paulsherwoodbut i agree, for most situations it would be preferable to have tests as part of foo11:56
persiaIf you are willing to test the build area (rather than the installed software), you could have just added all that stuff to build-depends.  This is the common solution (which I find unclean)11:56
ssam2adding a separate 'test-depends' field would be fairly trivial, I think11:57
paulsherwoodthat can easily work for the installed software too, i think... this code is not yet written :)11:57
ssam2(and a good idea)11:58
paulsherwoodi'm ok with 'test-depends' too11:58
ssam2it's unfortunate that we'd often lose info (we'd have to specify stratum-level test-depends instead of chunk-level test-depends in many cases) right now, but not the end of the world11:59
paulsherwoodif we can get the spec repo separated, i'd be happy to see a flood of changes to the spec, and develop/use ybd to validate them11:59
paulsherwoodssam2: i'm in the process of implementing transitive-depends: False, not sure if that will actually be worth having, though :)12:00
pedroalvarezpaulsherwood: just wondering, also for dependencies within a stratum?12:01
paulsherwoodincidentally, would folks approve changes to the spec/format, in the absence of migrations to prove them? (ie could migrations be offered separately/later)?12:01
paulsherwoodpedroalvarez: i don't understand your question, sorry?12:02
locallycompactwhere do default splitting rules live12:02
paulsherwoodDEFAULTS iiuc12:02
pedroalvarezpaulsherwood: so there are build-depends to depend on another stratum, and to depend on another chunks. IIRC both of them are transitive12:02
paulsherwoodpedroalvarez: i'll be aiming to disable both in one go, i think12:03
paulsherwood(and then expecging jjardon to say 'but that's not quite what i wanted' :-))12:03
*** richard_maw has left #baserock12:04
pedroalvarezhahaha12:04
paulsherwoodso, thinking about this, in a non-transitive world... if i have bip-chunk in foo-stratum, and foo-stratum build-depends on bar-stratum12:07
paulsherwoodi assume  we're still expecting that bip depends on all of the contents of bar?12:08
paulsherwoodin discussion with rjek here, maybe we can have a notation/convention for transitive, say bar! vs bar ?12:10
* rjek assumes ! is not valid in the names of things12:11
persiaNo12:11
pedroalvarezthat would be confusing I think12:12
persiaOr, rather, I'd prefer if I was able to answer "no" to that question.12:12
* rjek is lazy, and thus tends to prefer his dependencies to be recursive12:12
paulsherwoodpedroalvarez: the alternative, if we can't mix, is likely to be *extremely* long dependency lists12:12
* paulsherwood has not yet proved this, though :)12:13
persiaExpanding, I would like to be able to assume that bip only depends on declared dependencies, rather than either all of bar, or even part of bar.12:13
paulsherwoodpersia: in which case, no strata as build-depends12:14
persiaI'm happy with assuming bip *build-depends* on all of bar12:14
* persia tries again with fewer overloaded words12:14
paulsherwoodheh12:14
paulsherwoodi'm only thinking about build-depends at this point12:15
rjekEnglish has a rich vocabulary, and still too many things are over-loaded.  How do the French cope?12:15
persiaGiven chunk foo in stratum bar, where stratum bar build-depends on stratum baz, I would like to be able to assert that foo has no runtime dependencies on anything in baz.12:15
rjekI agree.  But isn't that the whole reason we list build and run time dependencies separately?12:16
persiaAs a result, in system quux including bar, I would have no chunks (or split artifacts) from baz in quux.12:16
paulsherwoodi'm only talking about build-depends. currently definitions has no concept of run-depends12:17
rjekOtherwise it'd be impossible to build a system that didn't include GCC :)12:17
persiapaulsherwood: We implicitly have runtime dependencies: if bar build-depends on baz, quux ends up with baz, even if it isn't listed in the quux defintion, doesn't it?12:18
paulsherwoodyes12:18
paulsherwoodunless stripped in the end system12:18
paulsherwoods/stripped/split/12:18
persiaSo, my understanding of old morph behaviour was that if we didn't include baz in quux, but only bar, baz would not be installed, resulting in a system that could, for example, not contain gcc.12:19
persiaAs we brought in the concept of "component" and had components include components, etc., I think we may have lost this.12:19
ssam2definitions needs the concept of run-depends12:20
paulsherwoodi'd be surprised if morph ever behaved like that12:20
rjekI thought they /did/ seperate run and build depends; I'm pretty surprised that they don't and this probably demonstrates that I should use Baserock more.12:20
rjek(In order to know these things)12:20
ssam2currently, definitions authors manually declare each stratum that is included in a system12:21
ssam2each stratum artifact, if you want12:21
paulsherwoodwhich is workable, but not great, iiuc12:21
ssam2which leads to huge pain whenever something is moved into a new stratum, yeah12:21
paulsherwoodwhen run-depends was originally proposed, i pushed back because the actual implementation seemed destined to further complicate things12:22
rdalethere are default stratum split rules for -runtime and -devel12:23
* paulsherwood => food12:23
persiaIf we're adding more dependency types, one that was discussed in Debian several times was devel-depends.  I don't know if it was ever implemented outside a couple example packages, but the idea was to express the set of tools that one would need to have installed to usefully work with a given source.12:30
persiaThe rationale behind devel-depends was that several teams had found incredibly useful tools that helped them work with source, which were not needed at build-time, but were needed at source-preparation time.  The results of running these tools would be checked into the VCS, so that the build server didn't need them.  Other developers trying to review or patch these packages would find it frustrating that they could not usefully edit the code without12:30
persia installing extra tools.12:30
paulsherwoodi'm aiming for incremental improvements in small steps, pls let's not overkill this13:58
rdalehave we agreed that we don't want transitive build depends for strata and chunks though?13:59
paulsherwoodno, we haven't. i'm proposing to make ybd optionally (off by default) not install transitive dependencies14:01
paulsherwoodbecause jjardon has a use-case, and i think it will be interesting to try out14:01
rdaleok14:02
persiaMy only worry with an option is that I think it needs to be part of the cache key computation, so that when specifying build-dependencies I can indicate whether I need the option on or need the option off.14:03
rdaleif you spell out the build depends and they are the same as you would get with a transitive build depends, then the cache key should be the same, otherwise not imho14:04
persiardale: Yes: the cache key should be based on what is actually there when the build happens, not necessarily the form of the text that caused that result.14:05
rdaleright14:06
locallycompactThey're not 'transitive' dependencies if they're optional.14:07
paulsherwoodpersia: agreed. there will need to be a cache-key change for the option14:08
* paulsherwood idly wonders how many hash_factors he can safely shove into https://github.com/devcurmudgeon/ybd/blob/master/ybd/cache.py#L80 before clashes become a realistic possibility14:09
persiapaulsherwood: The key for the cache key change is as rdale wrote: it shouldn't just be an extra bit.14:11
persiaTo avoid hash clashes, I think it's best to have 4-5 bits of hash for every real bit of freedom.14:11
persia(assuming a hash of lossy hashes)14:12
gtristanpaulsherwood, https://people.gnome.org/~tvb/aboriginal.ogv <-- it happened :)14:12
gtristantime to go to the gym ... a bit late today14:13
*** richard_maw has joined #baserock14:13
paulsherwoodgtristan: there's a baserock vimeo account we could move it to?14:14
paulsherwoodw00t! anyway ;)14:14
*** gtristan has quit IRC14:19
pedroalvarezpaulsherwood: I'll upload it there, if you are not doing it already15:02
*** jonathanmaw has quit IRC16:00
*** jonathanmaw_ has joined #baserock16:00
*** jonathanmaw has joined #baserock16:00
*** jonathanmaw has quit IRC16:54
*** jonathanmaw has joined #baserock16:54
*** faybrocklebank has quit IRC16:56
pedroalvarezfranred: thanks for reviewing some patches :)17:12
franredpedroalvarez, no probs :)17:13
*** franred has quit IRC17:18
*** ctbruce has quit IRC17:21
paulsherwoodpedroalvarez: tvm17:46
pedroalvarezthat took ages to upload17:47
pedroalvarezhttps://vimeo.com/15657044717:47
*** jonathanmaw has quit IRC17:47
*** faybrocklebank has joined #baserock17:49
*** gtristan has joined #baserock17:52
pedroalvarezgtristan: I think you can remove the videwo now https://vimeo.com/15657044717:54
*** faybrocklebank has quit IRC18:02
*** ssam2 has quit IRC18:02
gtristanpedroalvarez, cool :)18:05
*** edcragg has quit IRC18:13
*** locallycompact has quit IRC18:20
*** toscalix has quit IRC18:41
*** cosm has joined #baserock20:54
*** gtristan has quit IRC20:59
*** cosm has quit IRC21:07

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