| *** cosm has quit IRC | 00:02 | |
| *** edcragg has quit IRC | 00:04 | |
| *** gtristan has joined #baserock | 02:26 | |
| *** toscalix has joined #baserock | 07:55 | |
| *** fay_ has joined #baserock | 08:13 | |
| *** fay_ is now known as faybrocklebank | 08:13 | |
| *** ctbruce has joined #baserock | 08:32 | |
| *** paulw has quit IRC | 08:35 | |
| paulsherwood | jjardon: so good news, and bad news i think... | 08:37 |
|---|---|---|
| paulsherwood | adding a 'no transitive depends' option in ybd seems to be one line of code | 08:37 |
| paulsherwood | but the cache key calculation doesn't take this into account | 08:38 |
| * paulsherwood thinks a bit more | 08:41 | |
| *** bashrc_ has joined #baserock | 08:54 | |
| *** gtristan has quit IRC | 09:15 | |
| *** tiagogomes_ has joined #baserock | 09:24 | |
| *** jonathanmaw has joined #baserock | 09:46 | |
| *** gtristan has joined #baserock | 09:49 | |
| *** franred has joined #baserock | 09:59 | |
| *** ssam2 has joined #baserock | 10:08 | |
| *** ChanServ sets mode: +v ssam2 | 10:08 | |
| *** edcragg has joined #baserock | 10:12 | |
| paulsherwood | can 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_ct | How 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 |
| paulsherwood | bjdooks: can you dialin to a meeting? | 11:07 |
| ssam2 | yes I think "test" is too abstract a term | 11:08 |
| ssam2 | s/abstract/generic/ | 11:08 |
| paulsherwood | oops, ww | 11:08 |
| ssam2 | I quite like https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests as a concrete proposal | 11:09 |
| ssam2 | I don't think it's got very far | 11:09 |
| paulsherwood | ssam2: 'test' is a start, better than nothing? | 11:09 |
| ssam2 | my 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 was | 11:10 |
| ssam2 | i'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 works | 11:11 | |
| rdale | in 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 function | 11:11 |
| richard_maw | you 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 in | 11:13 |
| persia | Or run in two phases: perform a build, cache it, run the tests, store the test results. | 11:13 |
| persia | Personally, 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 |
| persia | That 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_maw | persia: is that running test-commands after install-commands then? | 11:15 |
| richard_maw | or am I missing a larger point | 11:16 |
| *** locallycompact has joined #baserock | 11:16 | |
| ssam2 | it's e.g. testing gedit inside a running gnome-shell environment running on an x server | 11:16 |
| ssam2 | rather than running gedit's `make check` which will test some internal helper code but not much else | 11:17 |
| persia | My 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 |
| ssam2 | both of these things are useful, for different reasons | 11:17 |
| persia | Right. 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 |
| ssam2 | unless the component follows the https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests approach | 11:19 |
| richard_maw | persia: we could use a copy of the build directories *and* provide additional components in the staging area | 11:20 |
| persia | richard_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 |
| persia | ssam2: 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_maw | there is a concern that install-commands could produce something different than what was produced at build-commands time | 11:23 |
| ssam2 | yes | 11:23 |
| persia | I 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 patches | 11:24 |
| persia | richard_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_maw | still 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 artifact | 11:24 |
| richard_maw | persia: sounds like we need both styles then | 11:25 |
| persia | I think the suggestion is to lead an initiative for social change to encourage adoption of testing software post-install. | 11:25 |
| *** franred has quit IRC | 11:25 | |
| persia | Sadly. | 11:26 |
| ssam2 | richard_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 this | 11:26 |
| ssam2 | this is already works in a few gnome components, glib at least | 11:27 |
| ssam2 | -is | 11:27 |
| persia | autopkgtest does the same sort of thing, and there are tests for a moderate number of components using that framework | 11:29 |
| persia | http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst | 11:29 |
| edcragg | has 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 | |
| pedroalvarez | that one is new | 11:33 |
| edcragg | it gets None for some reason | 11:34 |
| bwh | rjek: I don't think it does assume that any more | 11:34 |
| richard_maw | edcragg: got a stack trace? | 11:34 |
| pedroalvarez | also morph --version please | 11:35 |
| richard_maw | bwh: 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 library | 11:35 |
| richard_maw | bwh: now you need to jump through many more hoops to get it to give you file paths as byte strings | 11:35 |
| bwh | rjek: There's some hack to convert non-UTF-8 byte sequences to unpaired surrogates | 11:36 |
| bwh | and then back | 11:36 |
| richard_maw | bwh: 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 path | 11:36 |
| bwh | yay | 11:36 |
| rjek | !yay | 11:36 |
| richard_maw | bwh: also, os.fs{en,de}code aren't round-trippable in all circumstances | 11:37 |
| edcragg | richard_maw: http://paste.baserock.org/eruboyisux | 11:37 |
| edcragg | pedroalvarez: bda9fe51c8e22d4c8c5ad8325094abd6ed25706d | 11:37 |
| richard_maw | grr, there's a wart in the implementation of subprocess making it difficult to work out exactly what failed there | 11:41 |
| richard_maw | you need to look at the .child_traceback value of that exception to see what actually broke | 11:41 |
| richard_maw | but it sounds like maybe the problem is that None was passed where it shouldn't | 11:41 |
| richard_maw | must be one of the arguments to runcommand, as everything under it is fairly well isolated | 11:42 |
| paulsherwood | richard_maw, persia - noted. that's what i would expect to do | 11: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 #baserock | 11:49 | |
| persia | paulsherwood: What is your worst case intended to achieve? In my mind, I'd rather have the tests be just part of foo. | 11:54 |
| paulsherwood | persia: 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 think | 11:55 |
| paulsherwood | but i agree, for most situations it would be preferable to have tests as part of foo | 11:56 |
| persia | If 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 |
| ssam2 | adding a separate 'test-depends' field would be fairly trivial, I think | 11:57 |
| paulsherwood | that 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 |
| paulsherwood | i'm ok with 'test-depends' too | 11:58 |
| ssam2 | it'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 world | 11:59 |
| paulsherwood | if 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 them | 11:59 |
| paulsherwood | ssam2: i'm in the process of implementing transitive-depends: False, not sure if that will actually be worth having, though :) | 12:00 |
| pedroalvarez | paulsherwood: just wondering, also for dependencies within a stratum? | 12:01 |
| paulsherwood | incidentally, 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 |
| paulsherwood | pedroalvarez: i don't understand your question, sorry? | 12:02 |
| locallycompact | where do default splitting rules live | 12:02 |
| paulsherwood | DEFAULTS iiuc | 12:02 |
| pedroalvarez | paulsherwood: so there are build-depends to depend on another stratum, and to depend on another chunks. IIRC both of them are transitive | 12:02 |
| paulsherwood | pedroalvarez: i'll be aiming to disable both in one go, i think | 12:03 |
| paulsherwood | (and then expecging jjardon to say 'but that's not quite what i wanted' :-)) | 12:03 |
| *** richard_maw has left #baserock | 12:04 | |
| pedroalvarez | hahaha | 12:04 |
| paulsherwood | so, thinking about this, in a non-transitive world... if i have bip-chunk in foo-stratum, and foo-stratum build-depends on bar-stratum | 12:07 |
| paulsherwood | i assume we're still expecting that bip depends on all of the contents of bar? | 12:08 |
| paulsherwood | in 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 things | 12:11 | |
| persia | No | 12:11 |
| pedroalvarez | that would be confusing I think | 12:12 |
| persia | Or, 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 recursive | 12:12 | |
| paulsherwood | pedroalvarez: the alternative, if we can't mix, is likely to be *extremely* long dependency lists | 12:12 |
| * paulsherwood has not yet proved this, though :) | 12:13 | |
| persia | Expanding, 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 |
| paulsherwood | persia: in which case, no strata as build-depends | 12:14 |
| persia | I'm happy with assuming bip *build-depends* on all of bar | 12:14 |
| * persia tries again with fewer overloaded words | 12:14 | |
| paulsherwood | heh | 12:14 |
| paulsherwood | i'm only thinking about build-depends at this point | 12:15 |
| rjek | English has a rich vocabulary, and still too many things are over-loaded. How do the French cope? | 12:15 |
| persia | Given 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 |
| rjek | I agree. But isn't that the whole reason we list build and run time dependencies separately? | 12:16 |
| persia | As a result, in system quux including bar, I would have no chunks (or split artifacts) from baz in quux. | 12:16 |
| paulsherwood | i'm only talking about build-depends. currently definitions has no concept of run-depends | 12:17 |
| rjek | Otherwise it'd be impossible to build a system that didn't include GCC :) | 12:17 |
| persia | paulsherwood: 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 |
| paulsherwood | yes | 12:18 |
| paulsherwood | unless stripped in the end system | 12:18 |
| paulsherwood | s/stripped/split/ | 12:18 |
| persia | So, 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 |
| persia | As we brought in the concept of "component" and had components include components, etc., I think we may have lost this. | 12:19 |
| ssam2 | definitions needs the concept of run-depends | 12:20 |
| paulsherwood | i'd be surprised if morph ever behaved like that | 12:20 |
| rjek | I 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 |
| ssam2 | currently, definitions authors manually declare each stratum that is included in a system | 12:21 |
| ssam2 | each stratum artifact, if you want | 12:21 |
| paulsherwood | which is workable, but not great, iiuc | 12:21 |
| ssam2 | which leads to huge pain whenever something is moved into a new stratum, yeah | 12:21 |
| paulsherwood | when run-depends was originally proposed, i pushed back because the actual implementation seemed destined to further complicate things | 12:22 |
| rdale | there are default stratum split rules for -runtime and -devel | 12:23 |
| * paulsherwood => food | 12:23 | |
| persia | If 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 |
| persia | The 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 without | 12:30 |
| persia | installing extra tools. | 12:30 |
| paulsherwood | i'm aiming for incremental improvements in small steps, pls let's not overkill this | 13:58 |
| rdale | have we agreed that we don't want transitive build depends for strata and chunks though? | 13:59 |
| paulsherwood | no, we haven't. i'm proposing to make ybd optionally (off by default) not install transitive dependencies | 14:01 |
| paulsherwood | because jjardon has a use-case, and i think it will be interesting to try out | 14:01 |
| rdale | ok | 14:02 |
| persia | My 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 |
| rdale | if 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 imho | 14:04 |
| persia | rdale: 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 |
| rdale | right | 14:06 |
| locallycompact | They're not 'transitive' dependencies if they're optional. | 14:07 |
| paulsherwood | persia: agreed. there will need to be a cache-key change for the option | 14: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 possibility | 14:09 | |
| persia | paulsherwood: The key for the cache key change is as rdale wrote: it shouldn't just be an extra bit. | 14:11 |
| persia | To 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 |
| gtristan | paulsherwood, https://people.gnome.org/~tvb/aboriginal.ogv <-- it happened :) | 14:12 |
| gtristan | time to go to the gym ... a bit late today | 14:13 |
| *** richard_maw has joined #baserock | 14:13 | |
| paulsherwood | gtristan: there's a baserock vimeo account we could move it to? | 14:14 |
| paulsherwood | w00t! anyway ;) | 14:14 |
| *** gtristan has quit IRC | 14:19 | |
| pedroalvarez | paulsherwood: I'll upload it there, if you are not doing it already | 15:02 |
| *** jonathanmaw has quit IRC | 16:00 | |
| *** jonathanmaw_ has joined #baserock | 16:00 | |
| *** jonathanmaw has joined #baserock | 16:00 | |
| *** jonathanmaw has quit IRC | 16:54 | |
| *** jonathanmaw has joined #baserock | 16:54 | |
| *** faybrocklebank has quit IRC | 16:56 | |
| pedroalvarez | franred: thanks for reviewing some patches :) | 17:12 |
| franred | pedroalvarez, no probs :) | 17:13 |
| *** franred has quit IRC | 17:18 | |
| *** ctbruce has quit IRC | 17:21 | |
| paulsherwood | pedroalvarez: tvm | 17:46 |
| pedroalvarez | that took ages to upload | 17:47 |
| pedroalvarez | https://vimeo.com/156570447 | 17:47 |
| *** jonathanmaw has quit IRC | 17:47 | |
| *** faybrocklebank has joined #baserock | 17:49 | |
| *** gtristan has joined #baserock | 17:52 | |
| pedroalvarez | gtristan: I think you can remove the videwo now https://vimeo.com/156570447 | 17:54 |
| *** faybrocklebank has quit IRC | 18:02 | |
| *** ssam2 has quit IRC | 18:02 | |
| gtristan | pedroalvarez, cool :) | 18:05 |
| *** edcragg has quit IRC | 18:13 | |
| *** locallycompact has quit IRC | 18:20 | |
| *** toscalix has quit IRC | 18:41 | |
| *** cosm has joined #baserock | 20:54 | |
| *** gtristan has quit IRC | 20:59 | |
| *** cosm has quit IRC | 21:07 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!