| *** ghishadow_ has joined #buildstream | 03:15 | |
| *** ghishadow_ has quit IRC | 03:21 | |
| *** tristan has joined #buildstream | 05:56 | |
| *** ChanServ sets mode: +o tristan | 05:56 | |
| *** ghishadow_ has joined #buildstream | 06:47 | |
| *** ghishadow_ has quit IRC | 06:51 | |
| *** tristan has quit IRC | 07:48 | |
| *** tristan_ has joined #buildstream | 07:48 | |
| *** tristan_ is now known as tristan | 07:48 | |
| *** ChanServ sets mode: +o tristan | 07:49 | |
| *** ssam2 has joined #buildstream | 10:18 | |
| tristan | ugh, I've been turning in circles searching for a bug that didnt exist | 12:28 |
|---|---|---|
| paulsher1ood | ? | 12:28 |
| tristan | I have to ostree delete the artifact key to provoke a build that I already built | 12:31 |
| tristan | And, since there is also an extract directory... it wont reextract something already built (what I was overlooking) | 12:32 |
| tristan | So, my attempts to try splitting rules, always showed me the previously composed artifact | 12:32 |
| tristan | Had me looking for what was broken, when in fact the splitting was working correctly | 12:32 |
| tristan | Seems the only remaining problem is a 'garbage in garbage out' problem (which is just to say, the splitting rules themselves could be improved across the stack, handling special cases left and right and providing nicer output) | 12:34 |
| paulsher1ood | aha | 12:49 |
| *** tristan has quit IRC | 13:19 | |
| *** tristan has joined #buildstream | 13:40 | |
| *** ChanServ sets mode: +o tristan | 13:41 | |
| ssam2 | It's hard to make it easy to write splitting rules | 13:41 |
| ssam2 | the way they are implemented in Baserock definitions isn't good at all | 13:42 |
| ssam2 | but since they combine and override each other and are ordered, they just are quite complicated | 13:43 |
| tristan | ssam2, yeah | 14:13 |
| tristan | ssam2, but this is something thats just all around true | 14:14 |
| tristan | for instance, living in solviet rpm, manually written manifests split YOU ! | 14:14 |
| tristan | I think this is the right balance, just some things need tweaking | 14:15 |
| tristan | One thing I'd like, is to really build glibc/gcc into /lib | 14:15 |
| tristan | and not /lib64, regardless of whether we're building 64bit... _unless_ you go and define a multilib system | 14:15 |
| tristan | you only really want obnoxious /lib64 if you want multilib | 14:16 |
| tristan | but the workaround will be for glibc/gcc to capture that manually (which is what baserock does already) | 14:16 |
| tristan | well, to be fair you do get globbing with rpm as well | 14:17 |
| tristan | but you dont get to generalize in your /etc/rpm/macros | 14:18 |
| ssam2 | i think I found that lib64/ is quite hardcoded in GCC on x86_64 | 14:18 |
| tristan | ssam2, a crazy idea I had was to use something like this: https://github.com/idank/bashlex | 14:27 |
| tristan | but not sure that one is good enough... | 14:27 |
| tristan | In order to detect functionally equivalent shell scripts | 14:27 |
| tristan | would be pretty neat | 14:27 |
| tristan | but just a thought at this point :) | 14:27 |
| paulsher1ood | tristan: one of the things i learned before ybd was to resist adding superfluous dependencies... | 14:28 |
| tristan | paulsher1ood, indeed | 14:29 |
| ssam2 | ha, that is crazy! | 14:29 |
| tristan | the weight is however reduced when they are pure python | 14:29 |
| tristan | ssam2, :) | 14:29 |
| paulsher1ood | tristan: not in my experience | 14:29 |
| ssam2 | wow, http://www.explainshell.com/ is cool though | 14:30 |
| ssam2 | like a richard maw code -> english converter ;-) | 14:30 |
| ssam2 | ah it's just showing the docs for each thing it finds, I thought it was somehow generating a sentence describing the shell code you put into it | 14:31 |
| tristan | paulsher1ood, when you wrap up into setuptools in the standard ways, you gain some measure of ability to wrap up your dist tarball and all of it's dependencies in one go | 14:31 |
| tristan | that is not true for system dependencies, but it should be true for the pure python ones at least, you have your eggs and such | 14:32 |
| paulsher1ood | tristan: i mainly want you to keep bearing in mind that ideally bst should run on many arch, with minimal pain to setup, and minimal friction from dependency breakages | 14:33 |
| tristan | yes I understand, I'm conservative | 14:34 |
| paulsher1ood | :) | 14:34 |
| tristan | with many arch, pure python should not be problematic | 14:34 |
| tristan | really, it's a matter of properly bundling, but I am conservative still | 14:35 |
| tristan | I dont want to get into a situation where automated docker jobs are relying on a moving git target and need to access internet to pip install things | 14:35 |
| tristan | setuptools should solve at least _this_ problem | 14:35 |
| paulsher1ood | quite | 14:35 |
| paulsher1ood | and i want big-endian arches support too :) | 14:36 |
| tristan | ./setup.py sdist --some-option etc | 14:36 |
| tristan | should get you something with all the (python) dependencies you need | 14:36 |
| tristan | as long as you have an interpretor for arch, it should run | 14:36 |
| * paulsher1ood wonders about ostree, for example... | 14:37 | |
| tristan | exactly, that falls outside of the category of easily available pure python stuff :) | 14:37 |
| tristan | I dont believe it will be problematic to provide multi-arch, however it is certainly linux specific | 14:38 |
| tristan | damn gitlab :-S | 14:38 |
| * tristan wants it to update pages ! | 14:38 | |
| tristan | but but... damn runners, CI fails because its... a task on gitlab... which fails to clone buildstream.git which is... also on gitlab | 14:39 |
| tristan | but hey, lets use the network ! | 14:39 |
| tristan | and fail ! | 14:39 |
| tristan | :) | 14:39 |
| tristan | OK ! https://buildstream.gitlab.io/buildstream/ updated | 14:47 |
| tristan | Now with compose element: https://buildstream.gitlab.io/buildstream/elements/compose.html#module-compose | 14:47 |
| * tristan is falling behind on test coverage, though | 14:48 | |
| * paulsher1ood sees "it's" again and screams inside :) | 14:49 | |
| tristan | oh | 14:50 |
| * tristan has actually been making a conscious effort to _never_ put it's anywhere | 14:50 | |
| * paulsher1ood thinks there should be a pep for this | 14:50 | |
| tristan | because the rules make absolutely no sense | 14:50 |
| paulsher1ood | you have it on the third line of that page :) | 14:51 |
| tristan | the apostrophe is used to denote ownership | 14:51 |
| tristan | in which case that it's is correct, of course | 14:51 |
| * tristan removes it | 14:52 | |
| paulsher1ood | except for the special case of its :) | 14:52 |
| tristan | weird | 14:52 |
| tristan | see, no sense at all :) | 14:52 |
| paulsher1ood | you could have a rule that expressly prohibited "it's" and as a result you'd have to use "its" or "it is" | 14:52 |
| paulsher1ood | anyway, i have dragons to slay... | 14:53 |
| tristan | yes, its for it is, preferable over it's for the thing that belongs to it ? | 14:53 |
| tristan | heh | 14:54 |
| tristan | so now we have quite comprehensive warnings for overlaps, and the files we refuse to stage because they would purport to replace a non-empty directory | 14:56 |
| tristan | at the same time of this compose thing, since I had to walk though symlink thinking a bit again (havent changed policy, but it bit me for a moment) | 14:57 |
| *** tristan has quit IRC | 15:07 | |
| *** tristan has joined #buildstream | 15:31 | |
| *** ChanServ sets mode: +o tristan | 15:31 | |
| *** ssam2 has quit IRC | 18:29 | |
| *** tristan has quit IRC | 20:03 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!