IRC logs for #buildstream for Tuesday, 2019-08-20

*** narispo has quit IRC01:24
*** narispo has joined #buildstream01:25
*** narispo has quit IRC01:55
*** narispo has joined #buildstream01:55
*** narispo has quit IRC04:20
*** narispo has joined #buildstream04:20
*** narispo has quit IRC04:49
*** narispo has joined #buildstream04:50
*** persia has quit IRC05:49
*** persia has joined #buildstream06:00
*** persia has quit IRC06:03
*** persia has joined #buildstream06:05
*** persia has quit IRC06:05
*** persia has joined #buildstream06:05
*** narispo has quit IRC06:10
*** narispo has joined #buildstream06:11
*** narispo has quit IRC06:41
*** narispo has joined #buildstream06:41
juergbiKinnison: are you happy with my replies in !1499?07:02
gitlab-br-botMR !1499: Use buildbox-casd for CAS access https://gitlab.com/BuildStream/buildstream/merge_requests/149907:02
* Kinnison was in the process of checking through it all, yep, 👍07:08
juergbita, let's hand it off to marge, then07:10
juergbiand then I'll hide for the rest of the week ;)07:11
Kinnisonhehe07:11
*** narispo has quit IRC07:11
gitlab-br-botmarge-bot123 merged MR !1499 (juerg/casd->master: Use buildbox-casd for CAS access) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/149907:12
*** narispo has joined #buildstream07:12
Kinnisonjuergbi: while you wait, maybe you can get back to !1542?07:13
gitlab-br-botMR !1542: Support strict build dependencies https://gitlab.com/BuildStream/buildstream/merge_requests/154207:13
benschubertNice juergbi !07:14
juergbiI will07:14
*** phoenix has joined #buildstream07:21
*** tpollard has joined #buildstream07:30
*** phoenix has quit IRC07:32
*** phoenix has joined #buildstream07:32
*** phoenix has quit IRC07:35
*** phoenix has joined #buildstream07:38
*** narispo has quit IRC07:43
*** narispo has joined #buildstream07:43
*** rdale has joined #buildstream07:57
benschubertphil: do you remember the rational behind https://gitlab.com/BuildStream/buildstream/merge_requests/1291/diffs#b907e842cc9fd582114f61e5cb32cc3c87d9c258 ? :)08:01
*** narispo has quit IRC08:13
*** narispo has joined #buildstream08:13
*** ikerperez has joined #buildstream08:15
jennisUhh nice juergbi!08:19
jennisKinnison, I've replied to your review comments08:19
* Kinnison responds to the only one which needs a response08:20
jennisok thanks, mhmm passing the ArtifactCache into the Project08:22
jennisWould anyone object to this?08:22
KinnisonJust into that function, not into Project's __init__08:23
jennisoh right, I misinterpreted08:23
*** tme5 has joined #buildstream08:33
*** phoenix has quit IRC08:33
*** raoul has joined #buildstream08:56
*** jonathanmaw has joined #buildstream08:57
*** traveltissues has joined #buildstream09:05
*** narispo has quit IRC09:07
*** narispo has joined #buildstream09:07
jennisKinnison, the function in ArtifactCache takes the element and the key, not the ref09:12
Kinnisonjennis: Oh?09:12
jennisArtifactCache.contains()... Not sure if it's worth adding a contains_ref() method?09:12
jennisOr keeping as is09:12
KinnisonBleh, skip it for now09:12
Kinnisonadd a comment saying why it's open-coded there for now though please09:12
jennisaye aye09:12
*** phoenix has joined #buildstream09:37
*** phoenix has quit IRC09:39
tpollardIs anyone happy to approve? https://gitlab.com/BuildStream/website/merge_requests/12409:42
traveltissuestpollard, i don't have approval rights there sorry09:44
benschuberttpollard: It's on the website? But isn't the website for bst 1.2 currently?09:44
benschubertBecause if so, No mention of BuildBox casd should be made on the website until the 2.0 release09:45
tpollardI suppose that's a wider question09:47
juergbiit's on the website but like this: "BuildStream master also requires buildbox-casd: Install BuildBox"09:48
juergbithe latter being a link09:48
juergbiwe don't currently have separate install instructions for 1.2 and master09:48
juergbiand master documentation points to the shared install instructions: https://docs.buildstream.build/master/index.html09:49
benschubertjuergbi: ah, that's unfortunate, ok :)09:50
juergbiI didn't feel like restructuring the whole website for the casd branch ;)09:50
juergbiand I think it's not too bad with that note09:50
* tpollard tends to agree 09:50
laurenceit does say 'for buildstream master you'll need buildbox'09:53
benschubertlaurence: I was just very confused because https://buildstream.build/install.html doesn't have any reference to master09:58
benschubertand that is the official page for installation guides09:58
benschubertso we maybe should not speak about source install there but link to the other page?09:58
tme5could there just be a link to the install instructions in the docs? then there is no confusion as you choose the docs version you want10:00
laurenceremove the install guide from the website entirely, and have two install guides, one in each version of the docs - master and stable ?10:04
laurenceand link to the docs from the website10:04
* tlater[m] thinks this is best10:05
laurencei think for us it probably is10:05
laurenceit's a bit sad because install should be on the website10:05
tlater[m]We could even host the docs on the website10:05
laurencebut it's not that important10:05
tlater[m]It's all static HTML anyway10:05
*** narispo has quit IRC10:07
*** narispo has joined #buildstream10:07
gitlab-br-botaevri opened (was WIP) MR !1554 (aevri/nomp->master: Remove uneccesary _platform.multiprocessing) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/155410:32
tlater[m]This image needs buildbox, guys: https://gitlab.com/BuildStream/buildstream-docker-images/blob/master/buildstream/nightly.Dockerfile10:32
* tlater[m] scrambles10:32
tlater[m]We should have a "installed new dependency" checklist ;)10:32
tlater[m]This makes me wonder if we should start depending on our own docker images with FROM10:45
tlater[m]It would make updating these things a lot simpler, only need to do it in one place...10:45
benschuberttlater[m]: normally the jinja templates should be able to take care of most of things. Moreover, we test on way more than just the fedora image used for the image we publish10:47
tlater[m]Yeah, that's fair enough, but it's a little difficult to add a new dependency, no?10:48
tlater[m]Maybe I'm reading the repository wrong10:48
benschuberttlater[m]: the problem comes when you need to install differently per OS10:50
tlater[m]Yeah, but that's always a problem. I don't like that we need to do this per-image even when they share an OS10:50
benschubertthat's not the case10:51
benschubertwe need to do it once for the testsuite once for the public image10:51
benschubertbecause they don't share all dependencies10:51
tlater[m]Ok, I'm definitely reading the repo wrong then :)10:51
benschubertand if we want, we can always define a jinja include and extract a specific part away :)10:51
tlater[m]That said, it'd be nice if the public image and testsuite shared the part of the image that is the same10:52
tlater[m]Because then we'd be forced to fix our docker images before publishing buildstream with a new dpeendency10:52
benschuberttlater[m]: I was pretty sure tests were run in the image before publishing. Am I mistaken?10:52
benschuberttlater[m]: https://gitlab.com/BuildStream/buildstream-docker-images/-/jobs/275651069 ah no, we just do bst --version10:53
tlater[m]Yeah10:53
benschubertupdating the check here could be a good thing if you have an idea though :)10:53
* tlater[m] should sit down and think through that :|10:54
tlater[m]I still think building the test images FROM the production images would make more sense10:55
benschubertbut that would complicate the whole pipeline a lot :)10:55
benschubertand we don't want to publish the images if anything failed10:55
tlater[m]Hm, yeah, that's fair enough.10:58
* tlater[m] starts building the buildstream docker images with buildstream10:58
*** phil has quit IRC10:59
*** phil has joined #buildstream10:59
tme5benschubert, thanks for your comments, do you think it's ok to run the entire test in a subprocess, for those that use them?11:17
tme5and also I was considering trying to get a pytest marker to do what you want, as I don't think loaders are really part of the user API11:18
tme5I can't see any reason why the whole test couldn't be, in fact it would probably simplify things, as there is a lot of duplicate arg passing and setup between the parent and child11:21
juergbitme5: for the internal storage tests, I expect this to be fine. not sure about the artifactcache tests, though, as they also use the `cli` API11:22
benschuberttme5: One problem I can see would be with fixtures that would be required to run in the subprocess. Otherwise I think we can run everythin in the sp.11:22
benschubertYou can customize pytest test collection and build the tests on the fly :)11:22
benschubertI also wonder if we could use pytest-xdist to give it to us for free actually, juergbi tme511:24
benschubertsince it runs tests in subprocesses already11:24
benschubertif we could specify that some tests need an isolated runner11:25
benschubertthat would be stopped and restarted after the test11:25
benschubertwe would be able to remove all the rest and just run tests normally :)11:25
juergbimaybe, don't know xdist that well11:25
benschuberthttps://pypi.org/project/pytest-xdist/ we already use it for the multiprocessing of tests on Master11:26
benschuberton CI11:26
benschubertif we have a way of telling xdist to kill after the test...11:27
benschuberthttps://github.com/pytest-dev/pytest-forked we could also get some inspiration from that11:27
benschuberttme5: having a custom collection and replicating part of pytest-forked should give us a nice, correct reporting and such I guess11:32
ironfootI'm trying to create some symlinks in a script element, and I'm currently running `ln -sf /ostree "%{SOME_PATH}"/ostree` in one of the commands.11:45
ironfootsymlink is created, but in a weird way:11:46
ironfootlrwxrwxrwx 1 pedrotegra pedrotegra   12 Aug 20 12:41 ostree -> ../../ostree11:46
ironfootwhat magic is this :/11:47
benschubertironfoot: are you thinking aobut the "../.." ? We are translating every symlink to a relative one as part of putting files in the CAS11:47
ironfootyes, that's exactly what I'm talking about11:48
ironfootand that would explain it11:48
ironfootI guess to avoid that I can make them relative11:53
juergbiironfoot: is this on 1.x stable or master?11:58
juergbithere should be no symlink mangling in master anymore11:58
ironfootjuergbi: 1.x12:06
ironfootWhat was the reason for this?12:06
juergbithe reason for the mangling in 1.x or the reason why we stopped doing that?12:06
juergbisee https://gitlab.com/BuildStream/buildstream/merge_requests/114012:07
gitlab-br-botmarge-bot123 merged MR !1554 (aevri/nomp->master: Remove uneccesary _platform.multiprocessing) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/155412:08
*** phil has quit IRC12:17
ironfootthe reason for the mangling in 1.x12:29
ironfootI wonder if I should be moving to master12:29
ironfootthanks for the information though, I got it doing what I wanted :)12:37
*** alexandrufazakas has joined #buildstream13:06
*** qinusty has left #buildstream13:07
*** qinusty has joined #buildstream13:07
qinusty.13:08
*** alexandrufazakas has left #buildstream13:08
qinustyHey has anyone ran through the buildbox setup for fedora? https://buildstream.build/buildbox_install.html13:09
qinustydespite installing uuid-devel I'm getting "Package 'uuid', required by 'virtual:world', not found"13:09
* tpollard just lazily took the binary13:09
qinustyhmm, that could work but would require someone to manually update it D:13:11
traveltissuesqinusty, your pkg-config path is set correctly?13:18
qinustyNot sure, I just followed the docs :/ It's not having issues with the other packages e.g. "Found grpc++, version 1.18.0"13:20
cs-shadowQuestion about our CI agents - I have a periodic job to build bst-plugins-container at 0400 UTC, that fails almost regularly due to Docker not running on the agents.13:20
cs-shadowI was wondering if that's coinciding with some other cleanup on workers? Am I just getting unlucky or do we have some such schedule maintenance for the workers?13:20
tlater[m]ironfoot: Do you know? ^13:21
tpollardjennis: when does the cleanup scrip cron run?13:21
*** traveltissues has quit IRC13:22
jennistpollard, every hour13:23
jennisbut removes stuff older than 1 day13:23
tpollardYep that's what I thought...13:23
*** traveltissues has joined #buildstream13:23
*** phildawson has joined #buildstream13:24
cs-shadowjennis: do we also restart the Docker daemon while doing that?13:28
cs-shadow(Otherwise removing old stuff shouldn't cause this particular failure)13:28
jenniscs-shadow, not that I'm aware of. The script looks for any droplet labelled "runner-" that is older than a day and destroys it13:30
qinustyDoes anyone here make use of the buildstream:nightly docker image?13:31
cs-shadowjennis: okay, thanks for checking13:31
qinustyRunning `bst --version` gets me "Illegal instruction (core dumped)"13:31
juergbiqinusty: it builds fine in Fedora when building the docker image: https://gitlab.com/BuildStream/buildstream-docker-images/blob/master/testsuite/fedora-30.Dockerfile13:31
* cs-shadow will change the schedule time as a hail mary13:31
qinustyhuh strange juergbi, I was taking https://gitlab.com/BuildStream/buildstream-docker-images/blob/master/buildstream/nightly-extra.Dockerfile and attempting to build buildbox-casd ontop13:32
qinustyrunning into issues with the dependencies listed at https://buildstream.build/buildbox_install.html13:32
juergbihave you checked the cmake log? there might be some more info13:33
jennisah, qinusty, I've just reproduced this :/13:35
qinustyWhich?13:35
qinustyillegal instruction or fedora ? :D13:35
jennishttps://paste.gnome.org/pgn1hatrh13:36
jennisYeah, just trying to run buildstream in the nightly13:36
qinustyYeah, I had noticed this a week or so ago but forgot to raise it13:36
tme5i was getting that!13:36
tme5on my machine, when i first installed buildstream13:37
qinustyoh13:37
qinustynot inside docker?13:37
tme5no13:38
benschuberttme5: do you remember how you fixed it?13:38
tme5oh, actually it was while installing13:39
jennisqinusty, tme5: I've filed https://gitlab.com/BuildStream/buildstream-docker-images/issues/46 to keep track of this13:40
tme5i have absolutely no recollection of how i fixed it13:40
tme5i'm sorry lol13:40
tlater[m]juergbi: On the client end, we check if an artifact already exists on the server based on its proto before we send its cas blobs.13:51
tlater[m]As far as I understand CAS, this shouldn't be necessary, because the blobs won't upload if they already exist anyway13:52
tlater[m]is this correct, or am I going to tank performance by removing that check?13:52
juergbitlater[m]: can you point me to the code in question? this might be a check to avoid uploading lots of bytes the other end already has13:55
tlater[m]juergbi: https://gitlab.com/BuildStream/buildstream/blob/master/src/buildstream/_artifactcache.py#L40813:56
tlater[m]If this is just about protos, it doesn't matter, but we upload CAS blobs after that check13:57
juergbiah ok, so removing that would retain the findmissingblobs call done by send_directory13:58
juergbiso it shouldn't actually upload blobs that aren't missing on the server13:58
tlater[m]Right, gotcha13:58
tlater[m]Thanks :)13:59
*** CTtpollard has joined #buildstream14:00
juergbithe artifact proto presence check should still be faster, though14:00
juergbinot sure whether the difference would be significant14:00
*** tpollard has quit IRC14:01
tlater[m]Well, once we start thinking about split artifacts that will have to be thrown out the window anyway14:05
tlater[m]I could first check if the artifact proto is somewhere, but that doesn't guarantee that a cas server actually has the blobs.14:05
*** CTtpollard is now known as tpollard14:08
tpollardindeed14:08
juergbiyes, there isn't really any other way with completely independent artifact and CAS server14:11
tme5benschubert, it's a bit messy (because of use of undocumented internals), but I'm pretty sure pytest-forked is very easily adaptable to run on appropriately marked tests!14:29
tme5which is nice14:29
tme5i'll have a look and see if there are any issues with running the whole test in a subproc14:30
tme5i suppose we are fine with using pytest internals, as testing/runcli.py already uses some14:38
tlater[m]tme5: It's fine in the test suite14:39
tlater[m]Just make sure it's well marked as something that may break.14:39
tme5ok, will do14:41
benschuberttme5: they're public API on pytest even though not super documented, so that's fine :)14:44
tme5great15:00
*** rocklee has joined #buildstream15:03
*** rocklee has quit IRC15:04
*** narispo has quit IRC15:54
*** narispo has joined #buildstream15:54
*** tpollard has quit IRC16:03
*** tpollard has joined #buildstream16:08
*** tpollard has quit IRC16:10
*** tme5 has quit IRC16:32
*** phildawson_ has joined #buildstream16:34
*** phildawson has quit IRC16:36
*** traveltissues has quit IRC16:36
*** jonathanmaw has quit IRC17:00
*** phildawson_ has quit IRC18:18
*** narispo has quit IRC18:24
*** narispo has joined #buildstream18:24
*** narispo has quit IRC18:55
*** narispo has joined #buildstream18:55
*** traveltissues has joined #buildstream18:59
adds68tlater[m], have you ever come across: Handshake failed with fatal error SSL_ERROR_SSL: error:1000009c:SSL routines:OPENSSL_internal:HTTP_REQUEST. ? :D19:25
adds68tlater[m], on a pull server19:26
*** phoenix has joined #buildstream19:33
*** phoenix has quit IRC19:38
*** phoenix has joined #buildstream19:38
*** phoenix has quit IRC19:42
*** phoenix has joined #buildstream20:12
*** phoenix has quit IRC20:16
*** phoenix has joined #buildstream21:06
*** narispo has quit IRC21:09
*** narispo has joined #buildstream21:09
*** phoenix has quit IRC21:09
*** phoenix has joined #buildstream21:11
*** phoenix has quit IRC21:18
*** rdale has quit IRC22:17
*** narispo has quit IRC23:37
*** narispo has joined #buildstream23:37

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