| *** bochecha has quit IRC | 01:12 | |
| *** leopi has joined #buildstream | 06:20 | |
| *** tristan has joined #buildstream | 06:54 | |
| *** finn has joined #buildstream | 07:41 | |
| *** toscalix has joined #buildstream | 07:42 | |
| *** tiagogomes has quit IRC | 07:49 | |
| *** tiagogomes has joined #buildstream | 07:50 | |
| *** tiagogomes has quit IRC | 07:56 | |
| *** tiagogomes has joined #buildstream | 07:56 | |
| *** leopi has quit IRC | 08:36 | |
| *** jonathanmaw has joined #buildstream | 08:38 | |
| *** tpollard has joined #buildstream | 08:57 | |
| *** tiagogomes has left #buildstream | 09:04 | |
| *** tiagogomes has joined #buildstream | 09:04 | |
| *** toscalix has quit IRC | 09:09 | |
| *** leopi has joined #buildstream | 09:22 | |
| *** tiagogomes has quit IRC | 09:26 | |
| qinusty | Can I get a review https://gitlab.com/BuildStream/buildstream/merge_requests/627 again tristan? | 09:29 |
|---|---|---|
| *** ChanServ sets mode: +o tristan | 09:31 | |
| tristan | valentind, I've just set https://gitlab.com/BuildStream/buildstream/merge_requests/619 to merge, please take care of the backport :) | 09:31 |
| tristan | qinusty, as much as I really enjoy this MR... I need like, around 30min first :) | 09:32 |
| valentind | tristan, OK | 09:33 |
| *** tiagogomes has joined #buildstream | 10:07 | |
| qinusty | No worries tristan | 10:08 |
| * jonathanmaw wonders how long this channel has had +r | 10:10 | |
| jonathanmaw | juergbi: do you have time to check over https://gitlab.com/BuildStream/buildstream/merge_requests/633 ? | 10:10 |
| *** toscalix has joined #buildstream | 10:12 | |
| juergbi | will take a look | 10:13 |
| tristan | valentind, when you have a moment, can you please curate a list of things which still need backporting to 1.2, and make sure we are on top of these backports ? | 10:15 |
| valentind | tristan, OK | 10:15 |
| persia | jonathanmaw: I'm guessing about a week: I don't see it in the last week of logs, and it's been at least that long since the last spam spew. | 10:15 |
| jonathanmaw | tvm juergbi | 10:16 |
| tristan | valentind, besides that, we probably need to jump on fixing the broken plugins for jonathanmaw ... as he appears to be dropping the ball on his source mirroring branch side effects | 10:16 |
| jonathanmaw | yes, please | 10:18 |
| valentind | tristan, I have made a MR for setting "ruaml.yaml >= 0.15, < 0.15.52" i the requirements. Should I merge it right away on master and 1.2? | 10:20 |
| tristan | valentind, *yes* please :) | 10:22 |
| tristan | juergbi, ^^^^ that will fix ruamel.yaml on python 3.7 right ? | 10:22 |
| juergbi | tristan: yes, 0.15.51 works for me | 10:23 |
| valentind | OK I will test to see which exact range works with 3.7 | 10:23 |
| juergbi | 0.15 and 0.15.52 definitely fail, and 0.15.51 works | 10:23 |
| juergbi | the issue with 0.15 might also affect Python 3.6, not sure | 10:24 |
| valentind | >= 0.15.41, < 0.15.52 | 10:25 |
| valentind | That is the range. | 10:25 |
| tristan | juergbi, do you think pinning to exactly 0.15.51 will work ? | 10:25 |
| tristan | Or... do we need this "range" thing ? | 10:26 |
| tristan | I think if we have a version we know works, we should just pin to the most recent one known to work, right ? | 10:26 |
| valentind | tristan, It is just to make bisect faster. But we can pin, I do not mind. | 10:26 |
| *** cs_shadow has joined #buildstream | 10:27 | |
| valentind | tristan, Also packagers like to have a range. | 10:27 |
| valentind | It is that less to patch. | 10:27 |
| juergbi | fine either way for me | 10:28 |
| juergbi | but yes, if we specify a range, then we'd really want to make sure that the whole range works | 10:28 |
| juergbi | because it's quite possible 0.15.1 or so doesn't work | 10:28 |
| juergbi | otherwise I'd just specify < 0.15.52 without a starting point | 10:28 |
| valentind | juergbi, the range is from 0.15.41. I have tested. This is where it is fixed with python 3.7. | 10:29 |
| juergbi | ok, sounds sensible to specify that range, then | 10:30 |
| *** toscalix has quit IRC | 10:33 | |
| valentind | Actually 0.15.37 works. But there is no python3.7 build, so you need python3.7-dev then. I will keep .41. | 10:34 |
| valentind | .35 fails and .36 does not seem to exist. | 10:34 |
| *** finn_ has joined #buildstream | 10:46 | |
| *** finn has quit IRC | 10:47 | |
| valentind | Do we plan to have 1.2 support Python 3.7? | 10:56 |
| valentind | I mean the test suite. | 10:57 |
| *** bochecha has joined #buildstream | 11:09 | |
| tristan | valentind, that is a weird ambiguous question - IMO - A minor point bump of Python which breaks any existing Python projects; is a severe bug in Python | 11:10 |
| tristan | valentind, otherwise it should be Python 4 | 11:10 |
| valentind | tristan, I wondered about !615. | 11:11 |
| tristan | valentind, in otherwords, BuildStream 1.2 should support >= Python 3.5... which should include Python 3.100, or any version of python up until python 4 | 11:11 |
| valentind | tristan, the tests seem to fail with python3.7 without !615. It was not backported to bst-1.2. I suppose we need to backport this one. | 11:12 |
| * tiagogomes added code that `if < 3.6 do this or otherwise do that` to buildstream in the past | 11:12 | |
| tristan | valentind, yes, that looks like it's a necessary evil, but it is mostly a sign of irresponsibility of Python core developers | 11:12 |
| tristan | valentind, yes we need to backport that one, then :) | 11:13 |
| tristan | valentind, certainly | 11:13 |
| tristan | valentind, thanks for going through the list ! | 11:13 |
| tristan | tiagogomes, I *suppose* that most cases that we do that at all, are because Python >= 3.6 offers API which allows us to do something more optimally | 11:14 |
| valentind | tristan, There are lots of document fixes in master not in 1.2. I will go through them again. | 11:14 |
| tristan | In those cases, it's just a fact of life, unlike Python upstream breaking API | 11:14 |
| tristan | valentind, Those, I have considered rather unimportant for the 1.2 cycle | 11:15 |
| tristan | valentind, however we might come back and do them in backlog, they are not the priority | 11:15 |
| tiagogomes | tristan it was not due new API but rather a method which changed signature between minor releases | 11:15 |
| valentind | tristan, ok | 11:15 |
| tristan | tiagogomes, ugh :-/ | 11:15 |
| tristan | This, while slightly off topic, might be interesting for the distro install story: https://pex.readthedocs.io/en/latest/whatispex.html | 11:18 |
| tristan | Basically; Assuming we have all the pure-python requirements on hand at build time, could theoretically just compile them all together into a single executable bundle | 11:20 |
| tristan | and do away with any uncertainty about that python packages are on the host | 11:20 |
| tristan | s/that/what | 11:20 |
| tristan | valentind, juergbi is there an issue about what breakage python3.7 introduced ? | 11:23 |
| valentind | tristan, I do not remember seeing an issue. There is an issue for pylint, but this is in 1.2 I think. But not for juergbi's MR. | 11:24 |
| valentind | tristan, #481 is a bug that claims to affect 1.1.4. There is no milestone. Not backported. | 11:24 |
| valentind | #447 is a bug. It does not say what is affected. But I tested manually, 1.2 has it. It has no milestone. Not backported. | 11:28 |
| tristan | valentind, what is the full story... I'm talking with a python developer right now asking me for feedback | 11:28 |
| tristan | Which is the pep again ? how exactly does it break ? | 11:28 |
| tristan | 615 | 11:28 |
| valentind | The MR refers to 479 | 11:29 |
| tristan | yep | 11:30 |
| tristan | got it | 11:30 |
| tristan | sorry just needed a quick feedback | 11:30 |
| tristan | Was hoping to have a clearer story from upstream of how we can mitigate against unexpected breakage | 11:31 |
| tristan | thinking maybe they have a library for that, like six and nine | 11:31 |
| tiagogomes | meh, pylint is failing on setup.py now | 11:31 |
| valentind | tristan, What should I do with things that require backporting? I can add a label on the MR. But should I reopen the issue, and make sure it has the right milestone? Should I add a label on such reopened issue? | 11:35 |
| tristan | valentind, ummm, for now I suppose re-open and add the NeedsBackport tag would be good | 11:49 |
| tristan | So, according to https://www.python.org/dev/peps/pep-0479/#transition-plan... we "should have been seeing warnings with 3.6" helping us with the transition for PEP 479 | 11:50 |
| tristan | unfortunate that these fell through cracks | 11:50 |
| tristan | but they did make an effort | 11:50 |
| tristan | valentind, if you're going to do that for docs related things; then please add a comment with the reopen | 11:52 |
| tristan | valentind, or rather, just don't do that for docs related things | 11:52 |
| tristan | valentind, hold on to the list and let's figure out what to do with them, we could open a separate low priority issue to hold onto that list for instance | 11:53 |
| tristan | valentind, I just rather not cause any alarm about docs backports | 11:53 |
| jjardon | ha, valentind https://gitlab.com/BuildStream/buildstream/merge_requests/646 is failoing because the docker images actually have the latest python-ruamel, ie 0.15.52 | 11:56 |
| jjardon | chicken and egg problem here (docker images install what is specify in buildstream's setup.py); one solution is to use an older docker image to be able to merge that, then upgrade the docker image we use on another MR | 11:57 |
| valentind | jjardon, OK, well we can just have < 0.15.52 only and forget about the minimum version. | 12:05 |
| jjardon | valentind: sure | 12:05 |
| jjardon | valentind: still the buildstream CI will not pass because the docker image used there only have python-ruamel 0.15.52 | 12:06 |
| valentind | jjardon, But how does it work? It is supposed to break with this version. | 12:07 |
| jjardon | valentind: becaue the CI is using debian 9, ubuntu 18.04, fedora 27 and fedora 28; none of them have python 3.7 | 12:07 |
| valentind | jjardon, But I thought that 0.15.52 broke also on 3.6. | 12:08 |
| valentind | And why is not setuptools just downloading the right version anyway? | 12:08 |
| jjardon | valentind nope, only in python 3.7 | 12:09 |
| valentind | At it is forbidding it. | 12:09 |
| jjardon | valentind: the buildstream ci disables pip network installations | 12:09 |
| jjardon | (which is a good thing) | 12:09 |
| valentind | OK so if sys.version_info[0:2] >= (3, 7) we put the restrictions. | 12:10 |
| jjardon | valentind: that would work | 12:11 |
| juergbi | jjardon: https://gitlab.com/BuildStream/buildstream/issues/571 is Python 3.7-specific? | 12:11 |
| juergbi | don't see it mentioned there | 12:11 |
| juergbi | the fix broke Python 3.7 | 12:12 |
| jjardon | oh sorry | 12:13 |
| * jjardon re-reads everything | 12:13 | |
| valentind | jjardon, are you sure there is no 0.15.0 installed as well? | 12:13 |
| jjardon | valentind: sorry, It's the other way around; what is currently there works for python 3.6, but it doesnt for python 3.7. In your MR you are trying to put a minimal version greater than what is currently in the docker imnages, so it breaks | 12:15 |
| valentind | OK so removing the lower bound will make it build then. | 12:16 |
| jjardon | valentind: simply add the restrictions to python-ruamel <= 0.15.51 should fix it for everyone | 12:16 |
| jjardon | valentind: yup, sorry for the confusion. Thanks we have a juergbi around :) | 12:16 |
| * tristan hands qinusty another review round on !627 | 12:17 | |
| qinusty | Cheers! Working through them now :) | 12:17 |
| qinusty | re: Any(). TIL Generator Comprehensions | 12:18 |
| tristan | Should probably add this to our style guide but... avoid tail calling ! | 12:18 |
| tristan | We never want self.foo().bar() | 12:18 |
| tristan | That does: (A) cause exceptions to be harder to interpret (what went wrong exactly on that line ?)... (B) causes line based history to be weird (changing half of that line might be needed one day, we want the provenance of git blame to match with the reasoning of each individual change) | 12:20 |
| *** cs_shadow is now known as cs-shadow | 12:33 | |
| *** cs-shadow has joined #buildstream | 12:34 | |
| tristan | hmmm, still no bot around | 12:37 |
| tristan | maybe the bot needs a registered nick now, asides from not being in the channel at all ? | 12:37 |
| tristan | valentind, both !646 and !647 appear to need a rebase | 12:38 |
| valentind | tristan, thanks | 12:39 |
| cs-shadow | tristan: Hey! Do you think there's anything else left to do for the SourceTransform MR (!568) before it can be landed? | 12:39 |
| tristan | cs-shadow, so I replied your comments regarding the `pip download` approach, I didnt realize you already made those adjustments | 12:40 |
| tristan | cs-shadow, also; I wonder how it is supposed to work in practice... when we brainstormed `cargo`, it required at least that some environment vars or semantics be used in the build side of things | 12:41 |
| tristan | cs-shadow, I think whether or not we make it "just work" with the `pip` BuildElement, it needs some documentation clarity of how the results can later be used at build time right ? | 12:41 |
| cs-shadow | tristan: currently I'm envisioning that the element authors will add a manual step to do something like `pip install pip_dir/*` before they start the build. | 12:42 |
| cs-shadow | later `pip` element could make things a bit nicer by eliminating some boiler plate | 12:43 |
| tristan | cs-shadow, I doubt that can work | 12:43 |
| tristan | cs-shadow, i.e. we've made more sources available, that does not mean that `/` is somehow writable as a result | 12:43 |
| tristan | cs-shadow, I think what `pip` source is doing, is providing the source dependencies to the build directory, and then that needs to ensure that the right things get installed in %{install-root} | 12:44 |
| cs-shadow | tristan: oh right, they'll have to use `--prefix` and PYTHONPATH too. They'd have to set PYTHONPATH no matter which approach we choose as the sources will never be in site-packages | 12:44 |
| tristan | would be good to have an integration test proving that something works | 12:45 |
| tristan | i.e. that the result of a build of a python thing that used a `pip` source, can be run with `bst shell` and required using the implied dependency | 12:46 |
| cs-shadow | tristan: sounds like a good idea, I can add another tests that exercises this workflow | 12:47 |
| tristan | cs-shadow, right, I think that is a good start; from that test we can learn what is convenient and document accordingly; we can then file a separate issue for making the `pip` BuildElement help in automation of this workflow | 12:48 |
| cs-shadow | tristan: Regarding usage instructions, I have currently add a short note in the top-level docs for the pip plugin. Do you think that's enough or should we provide a more concrete example? | 12:48 |
| tristan | So, we need not add the extra automation to this issue, but lets see it work :) | 12:48 |
| tristan | cs-shadow, I don't block features on user facing examples and such, documentation inside the `pip` source plugin itself describing how it works and can be used is good enough :) | 12:49 |
| tristan | i.e. reference manual should always have 100% coverage of features (we've been doing pretty well with that so far) | 12:50 |
| tristan | user examples/guides/tutorials in "Using" section, can evolve asynchronously | 12:51 |
| cs-shadow | cool, i'll add that test and let you know | 12:51 |
| tristan | cs-shadow, ok I'll give a (hopefully final) review round tomorrow; I think there were some things unaddressed last time around, and disappearing comments (i.e. naming conventions for class attributes on plugins ?) | 12:52 |
| tristan | I presume that's all fixed; fwiw I have no problem really with the super verbose long names for those attributes :) | 12:53 |
| cs-shadow | tristan: yes, GitLab decided to close that for some reason but that should be fixed now and we have really loooong attribute names | 12:53 |
| cs-shadow | i too prefer that over introducing new terminology for this | 12:53 |
| tristan | yeah, over time I think we notice that we would have preferred verbose names if we could have turned back time | 12:55 |
| tristan | qinusty, errrr something just came to mind regarding your branch | 12:57 |
| qinusty | Go ahead | 12:57 |
| tristan | qinusty, similarly to how `fail-on-overlap` is considered, if set, in the cache key; we need the same for fatal-warnings | 12:57 |
| tristan | because when you change whether a warning is fatal or not, you need it to trigger a rebuild | 12:58 |
| tristan | qinusty, note that that should not effect cache key when no fatal warnings are configured (similarly to fail-on-overlap again, I think) | 12:58 |
| tristan | Oh, this introduces a very interesting question too | 12:59 |
| tristan | qinusty, the nature of "fatal-warnings: True" changes with time; as more warnings get added | 13:00 |
| tristan | that is an annoying consideration :-S | 13:00 |
| qinusty | Without individual plugins registering their warnings, we cannot keep track of what `fatal-warnings: True` really means | 13:00 |
| *** Nexus has left #buildstream | 13:00 | |
| *** Nexus has joined #buildstream | 13:00 | |
| tristan | qinusty, it doesnt matter whether they get registered or not, it's *still* a problem | 13:01 |
| tristan | qinusty, lets say today I build a specific tag of freedesktop-sdk with `fatal-warnings: True`, now it's in my cache | 13:02 |
| qinusty | yup | 13:02 |
| tristan | qinusty, then next week BuildStream adds a new CoreWarning, and I try to rebuild the same tag of freedesktop-sdk | 13:02 |
| tristan | The statement of "This cache key passed with all fatal warnings enabled" has changed, but the artifacts dont get rebuilt | 13:03 |
| tristan | This change of semantic needs to be captured in the key | 13:03 |
| qinusty | Which means that for each warning, core or not. The cache key needs to be made aware of it's consideration | 13:03 |
| tristan | Or... unless we had enumerated each individual warning's enabled-ness in the key, if True were specified, then it would be indeed | 13:04 |
| Nexus | meep? | 13:04 |
| Nexus | ok, when did we require registering> | 13:04 |
| valentind | tristan, !475/#76 are in milestone 1.2. But were not merged in 1.2. Is there a reason for that? | 13:04 |
| tristan | Nexus, in a previous iteration of qinusty's patch | 13:04 |
| Nexus | kk. I think we need to change our docs, when installing buildstream, we state we need python version >3.5 But if you use 3.6 or greater, buildstream seems to break for me | 13:04 |
| qinusty | Yup valentin is working on that Nexus | 13:05 |
| qinusty | 3.7 broke for me but a patch is in the works | 13:05 |
| Nexus | coolio, is there an ETA on that? | 13:05 |
| qinusty | pipelines? | 13:05 |
| qinusty | https://gitlab.com/BuildStream/buildstream/merge_requests/646 | 13:05 |
| tristan | qinusty, I'm a bit uncomfortable about additions of warning tokens magically changing cache keys, though | 13:05 |
| tristan | valentind, lets not backport that | 13:06 |
| Nexus | kk, MacOSX seems to really dislike using 3.5 >:( | 13:06 |
| valentind | Should we change the milestone? Or was there a reason to use the milestone? | 13:06 |
| qinusty | But tristan, if you change your fatal-warnings. It needs to change the cache key. If the definition of fatal-warnings: True changes, the cache key needs to change. | 13:06 |
| tristan | valentind, I just punted it's milestone to 1.4, it shouldn't matter much though; there is some disparity about what the meaning of the milestone means | 13:06 |
| qinusty | Considering True means all | 13:06 |
| tristan | qinusty, That is true, what I am uncomfortable with, is that changing the version of BuildStream causes the meaning of "fatal-warnings: True" to change | 13:08 |
| tristan | qinusty, this is tricky | 13:08 |
| tristan | qinusty, I don't have an answer off hand; but starting to think we should not have a way to blindly enable all warnings to be fatal | 13:08 |
| tristan | qinusty, conversely, one could say that features freeze in a given release branch; and only there are cache keys currently guaranteed stable | 13:09 |
| tristan | But then there is the question of external plugins changing code | 13:09 |
| qinusty | Not only could they change their warnings, but they could change the cause of a warnings | 13:10 |
| qinusty | s/warning/warnings | 13:10 |
| *** leopi has quit IRC | 13:10 | |
| Nexus | s/warnings/warning/ | 13:12 |
| Nexus | unless you wanted warningss | 13:12 |
| qinusty | :( | 13:12 |
| Nexus | :) | 13:12 |
| Nexus | *in golum voice * they cause all of the warnings's | 13:13 |
| *** bethwhite_ has joined #buildstream | 13:20 | |
| tristan | qinusty, I think the sensible thing to do right now, is back out the support for the sweeping `fatal-warnings: True` statement altogether | 13:24 |
| * jmac notices all his recent messages have been rejected due to not being registered | 13:25 | |
| qinusty | Open an issue to consider future implementation? | 13:25 |
| tristan | qinusty, it's a tricky problem, and if we are able to find a good solution for it; there's nothing stopping us from doing that later | 13:25 |
| *** bethwhite_ has quit IRC | 13:25 | |
| *** leopi has joined #buildstream | 13:26 | |
| *** edb has joined #buildstream | 13:27 | |
| tristan | qinusty, on a related note, it would be nice to extend the cachekey test for this; although it may involve creating a new directory in the cachekey tests dir | 13:27 |
| qinusty | I'll give it a go | 13:28 |
| qinusty | Well spotted though, I hadn't quite understood the importance of the cache keys, but now that you've explained their role. It is definitely important to consider the effect this has. | 13:28 |
| tristan | it slipped my mind before that we needed to consider this part; but then I noticed that fail-on-overlap was considered and why it was | 13:30 |
| tristan | that was a separate issue which was raised after having implemented fail-on-overlap functionality, cause we also missed that first time around | 13:31 |
| *** tristan has quit IRC | 13:34 | |
| * qinusty wonders what version of python we use in buildstream CI | 13:40 | |
| * cs-shadow wonders if we should use tox to handle such issues and not rely on the versions that come with the distros | 13:41 | |
| *** tristan has joined #buildstream | 13:43 | |
| *** ChanServ sets mode: +o tristan | 13:43 | |
| Nexus | qinusty: 3.5.3 | 13:43 |
| Nexus | platform linux -- Python 3.5.3, pytest-3.7.1, py-1.5.4, pluggy-0.7.1 -- /usr/bin/python3 | 13:43 |
| * qinusty is getting lots of lint errors that don't show up on CI | 13:44 | |
| valentind | tristan, Done with finding things needing backporting. 5 issues and 2 MR. | 13:46 |
| valentind | https://gitlab.com/BuildStream/buildstream/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Needs%20Backport | 13:46 |
| valentind | https://gitlab.com/BuildStream/buildstream/merge_requests?scope=all&utf8=%E2%9C%93&state=all&label_name[]=Needs%20Backport | 13:46 |
| valentind | Should I go ahead and backport them? | 13:46 |
| tristan | valentind, :) | 13:47 |
| tristan | valentind, yes please ! thanks a lot for that, I know it's boring | 13:47 |
| tristan | valentind, after that, please pick up where jonathanmaw left off; using source mirroring features will be important for the 1.2 cycle | 13:47 |
| tristan | As someone who has been participating in freedesktop-sdk project a lot, I'm sure you are familiar already with the pain it causes for that feature to be lacking :) | 13:48 |
| valentind | Gitlab is so slow today. | 13:52 |
| jjardon | indeed | 13:52 |
| laurence | tristan, valentind, this morning those issues were assigned to qinusty ?? | 13:53 |
| laurence | well, before we quickly moved on, anyway | 13:53 |
| valentind | laurence, what issues? | 13:53 |
| laurence | the source mirroring technical debt ones .... | 13:53 |
| laurence | maybe makes sense for valentind to do so instead though | 13:54 |
| qinusty | It's fine with me either way :) | 13:54 |
| *** toscalix has joined #buildstream | 14:16 | |
| qinusty | Sorted https://gitlab.com/BuildStream/buildstream/merge_requests/627 tristan, True is no longer valid for `fatal-warnings`. All concerns from review addressed | 14:31 |
| Nexus | Do we need to keep our yaml files as commented maps? | 14:54 |
| jmac | We may have to modify BuildStream to accept CommentedMap objects instead of dicts, if we're going to continue using ruamel | 14:55 |
| qinusty | If we intend to write back to them | 14:55 |
| jmac | Which we do, and AFAIK ruamel is returning CommentedMaps by default now, so it doesn't matter if you want to write back to them | 14:56 |
| qinusty | Does anyone know why the latest tag for our testsuites don't work on dockerhub? | 15:01 |
| *** leopi has quit IRC | 15:02 | |
| jmac | Got an error log? | 15:03 |
| *** leopi has joined #buildstream | 15:03 | |
| qinusty | Error response from daemon: manifest for buildstream/testsuite-fedora:lastest not found | 15:03 |
| jmac | Ah, no idea about that | 15:03 |
| cs-shadow | i can see a typo in "lastest" | 15:04 |
| cs-shadow | could that be the cause? | 15:04 |
| *** leopi has quit IRC | 15:07 | |
| qinusty | unfortunately nope | 15:13 |
| qinusty | I think it's because we don't build our docker images with the 'latest' tag | 15:13 |
| qinusty | Which seems to be a bit of a trend with images | 15:13 |
| cs-shadow | oh right! We do have a latest tag for the user-facing buildstream-fedora image but not for the testsuite ones | 15:14 |
| qinusty | https://medium.com/@mccode/the-misunderstood-docker-tag-latest-af3babfd6375 | 15:16 |
| qinusty | I guess that makes sense | 15:16 |
| qinusty | latest is simply the latest build which was submitted WITHOUT a tag | 15:16 |
| *** toscalix has quit IRC | 15:27 | |
| WSalmon | If i create a workspace and change somethings and build it and then decided i dont care about the changes and close the workspace. when i run bst build should it just use the cached build that's source no longer exists or rebuild from the original source | 16:00 |
| *** leopi has joined #buildstream | 16:58 | |
| *** jonathanmaw_ has joined #buildstream | 17:16 | |
| *** jonathanmaw has quit IRC | 17:17 | |
| *** xjuan has joined #buildstream | 17:30 | |
| cs-shadow | juergbi: tristan: tlater: I have created a buildstream-ci account on PyPi - https://pypi.org/user/buildstream-ci, and added all of your emails to increase its bus factor. Please verify the email when you get a chance and let me know if I should add anyone else | 17:48 |
| cs-shadow | also, you'll get spammed once more when I repeat the process for test pypi :) | 17:48 |
| juergbi | cs-shadow: the verification link brings me to the login page. and registering my own account won't work anymore because the email address is already associated with buildstream-ci | 17:53 |
| juergbi | adding email addresses of different people to a single account might not be how PyPi is meant to be used | 17:54 |
| cs-shadow | juergbi: oh right! I also need to share the username/password. What do you think will be the best way to do that? | 17:54 |
| juergbi | wouldn't it be possible to associate multiple accounts with a single pypi project instead? | 17:55 |
| cs-shadow | Yes, we can do that but we'll need one "shared" account if we want to publish from GitLab CI | 17:55 |
| cs-shadow | so, wanted to ensure that it's not just me who can recover that account | 17:56 |
| cs-shadow | Perhaps I shouldn't be using people's primary email ids for this purpose | 17:56 |
| juergbi | yes, this sounds like a good precaution but because pypi doesn't allow a single email address to be associated with multiple usernames, we should do it slightly differently | 17:56 |
| juergbi | not sure what the best approach is. for my side I could create an email alias. and we could store the password in a gitlab protected variable | 17:58 |
| cs-shadow | that sounds like a good idea. I don't have any admin superpowers so someone might need to temporarily make me an admin so that I can add this variable | 17:59 |
| juergbi | sure | 18:00 |
| *** xjuan has quit IRC | 18:27 | |
| *** finn_ has quit IRC | 18:27 | |
| *** tiagogomes has quit IRC | 18:27 | |
| *** tpollard has quit IRC | 18:27 | |
| *** johnward has quit IRC | 18:27 | |
| *** mablanch has quit IRC | 18:27 | |
| *** mohan43u has quit IRC | 18:27 | |
| *** phildawson has quit IRC | 18:27 | |
| *** tiagogomes_ has quit IRC | 18:27 | |
| *** jennis has quit IRC | 18:27 | |
| *** WSalmon has quit IRC | 18:27 | |
| *** lantw44 has quit IRC | 18:27 | |
| *** coldtom has quit IRC | 18:27 | |
| *** qinusty has quit IRC | 18:27 | |
| *** adds68 has quit IRC | 18:27 | |
| *** skullman has quit IRC | 18:27 | |
| *** Trevinho has quit IRC | 18:27 | |
| *** ironfoot has quit IRC | 18:27 | |
| *** ironfoot has joined #buildstream | 18:27 | |
| *** skullman has joined #buildstream | 18:27 | |
| *** finn_ has joined #buildstream | 18:27 | |
| *** WSalmon has joined #buildstream | 18:27 | |
| *** phildawson has joined #buildstream | 18:27 | |
| *** tpollard has joined #buildstream | 18:27 | |
| *** tiagogomes_ has joined #buildstream | 18:27 | |
| *** jennis has joined #buildstream | 18:27 | |
| *** xjuan has joined #buildstream | 18:27 | |
| *** lantw44 has joined #buildstream | 18:27 | |
| *** adds68 has joined #buildstream | 18:27 | |
| *** coldtom has joined #buildstream | 18:27 | |
| *** tiagogomes has joined #buildstream | 18:27 | |
| *** qinusty has joined #buildstream | 18:27 | |
| *** Trevinho has joined #buildstream | 18:27 | |
| *** mohan43u has joined #buildstream | 18:27 | |
| *** johnward has joined #buildstream | 18:27 | |
| *** mablanch has joined #buildstream | 18:28 | |
| *** xjuan has quit IRC | 18:49 | |
| *** brlogger has joined #buildstream | 18:58 | |
| *** jonathanmaw has joined #buildstream | 19:16 | |
| *** aiden has quit IRC | 19:17 | |
| *** mablanch has quit IRC | 19:17 | |
| *** ironfoot has quit IRC | 19:17 | |
| *** jonathanmaw_ has quit IRC | 19:17 | |
| *** tristan has quit IRC | 19:17 | |
| *** edb has quit IRC | 19:17 | |
| *** cs-shadow has quit IRC | 19:17 | |
| *** slaf has quit IRC | 19:17 | |
| *** milloni has quit IRC | 19:17 | |
| *** bethw has quit IRC | 19:17 | |
| *** valentind has quit IRC | 19:17 | |
| *** laurence has quit IRC | 19:17 | |
| *** hergertme has quit IRC | 19:17 | |
| *** paulsherwood has quit IRC | 19:17 | |
| *** pro[m] has quit IRC | 19:17 | |
| *** awacheux[m] has quit IRC | 19:17 | |
| *** asingh_[m] has quit IRC | 19:17 | |
| *** cgmcintyre[m] has quit IRC | 19:17 | |
| *** Demos[m] has quit IRC | 19:17 | |
| *** jjardon[m] has quit IRC | 19:17 | |
| *** mattiasb has quit IRC | 19:17 | |
| *** kailueke[m] has quit IRC | 19:17 | |
| *** ssssam[m] has quit IRC | 19:17 | |
| *** oknf[m] has quit IRC | 19:17 | |
| *** inigomartinez has quit IRC | 19:17 | |
| *** rafaelff[m] has quit IRC | 19:17 | |
| *** abderrahim[m] has quit IRC | 19:17 | |
| *** albfan[m] has quit IRC | 19:17 | |
| *** theawless[m] has quit IRC | 19:17 | |
| *** connorshea[m] has quit IRC | 19:17 | |
| *** alatiera has quit IRC | 19:17 | |
| *** m_22[m] has quit IRC | 19:17 | |
| *** tintou has quit IRC | 19:17 | |
| *** Nexus has quit IRC | 19:17 | |
| *** benbrown has quit IRC | 19:17 | |
| *** csoriano has quit IRC | 19:17 | |
| *** tintou has joined #buildstream | 19:17 | |
| *** cs-shadow has joined #buildstream | 19:18 | |
| *** csoriano has joined #buildstream | 19:18 | |
| *** ironfoot has joined #buildstream | 19:19 | |
| *** paulsherwood has joined #buildstream | 19:19 | |
| *** benbrown has joined #buildstream | 19:20 | |
| *** Nexus has joined #buildstream | 19:20 | |
| *** hergertme has joined #buildstream | 19:21 | |
| *** laurence has joined #buildstream | 19:23 | |
| *** slaf has joined #buildstream | 19:23 | |
| *** aiden has joined #buildstream | 19:23 | |
| *** mablanch has joined #buildstream | 19:24 | |
| *** milloni has joined #buildstream | 19:24 | |
| *** bethw has joined #buildstream | 19:24 | |
| *** valentind has joined #buildstream | 19:25 | |
| *** tristan has joined #buildstream | 19:33 | |
| *** kailueke[m] has joined #buildstream | 19:59 | |
| *** jonathanmaw has quit IRC | 19:59 | |
| *** ssssam[m] has joined #buildstream | 20:06 | |
| *** albfan[m] has joined #buildstream | 20:06 | |
| *** abderrahim[m] has joined #buildstream | 20:07 | |
| *** kailueke[m] has quit IRC | 20:23 | |
| *** tristan has quit IRC | 20:23 | |
| *** valentind has quit IRC | 20:23 | |
| *** bethw has quit IRC | 20:23 | |
| *** milloni has quit IRC | 20:23 | |
| *** mablanch has quit IRC | 20:23 | |
| *** laurence has quit IRC | 20:23 | |
| *** ironfoot has quit IRC | 20:23 | |
| *** csoriano has quit IRC | 20:23 | |
| *** cs-shadow has quit IRC | 20:23 | |
| *** tintou has quit IRC | 20:23 | |
| *** tlater has quit IRC | 20:23 | |
| *** juergbi has quit IRC | 20:23 | |
| *** mohan43u has quit IRC | 20:23 | |
| *** tpollard has quit IRC | 20:23 | |
| *** phildawson has quit IRC | 20:23 | |
| *** WSalmon has quit IRC | 20:23 | |
| *** finn_ has quit IRC | 20:23 | |
| *** skullman has quit IRC | 20:23 | |
| *** ironfoot has joined #buildstream | 20:23 | |
| *** skullman has joined #buildstream | 20:23 | |
| *** juergbi has joined #buildstream | 20:23 | |
| *** cs-shadow has joined #buildstream | 20:23 | |
| *** finn_ has joined #buildstream | 20:23 | |
| *** phildawson has joined #buildstream | 20:23 | |
| *** tintou has joined #buildstream | 20:23 | |
| *** tristan has joined #buildstream | 20:23 | |
| *** laurence has joined #buildstream | 20:23 | |
| *** mohan43u has joined #buildstream | 20:23 | |
| *** mablanch has joined #buildstream | 20:24 | |
| *** bethw has joined #buildstream | 20:24 | |
| *** milloni has joined #buildstream | 20:24 | |
| *** valentind has joined #buildstream | 20:24 | |
| *** tlater has joined #buildstream | 20:24 | |
| *** csoriano has joined #buildstream | 20:24 | |
| *** tpollard has joined #buildstream | 20:24 | |
| *** WSalmon has joined #buildstream | 20:24 | |
| *** csoriano has quit IRC | 20:24 | |
| *** csoriano has joined #buildstream | 20:25 | |
| *** leopi has quit IRC | 20:30 | |
| *** tristan has quit IRC | 20:30 | |
| *** csoriano has quit IRC | 20:43 | |
| *** milloni has quit IRC | 20:43 | |
| *** valentind has quit IRC | 20:43 | |
| *** tlater has quit IRC | 20:43 | |
| *** WSalmon has quit IRC | 20:43 | |
| *** tpollard has quit IRC | 20:43 | |
| *** WSalmon has joined #buildstream | 20:43 | |
| *** tpollard has joined #buildstream | 20:43 | |
| *** csoriano has joined #buildstream | 20:43 | |
| *** milloni has joined #buildstream | 20:43 | |
| *** valentind has joined #buildstream | 20:43 | |
| *** tlater has joined #buildstream | 20:44 | |
| *** oknf[m] has joined #buildstream | 20:57 | |
| *** theawless[m] has joined #buildstream | 21:16 | |
| *** bochecha has quit IRC | 21:22 | |
| *** inigomartinez has joined #buildstream | 21:39 | |
| *** connorshea[m] has joined #buildstream | 21:44 | |
| *** cgmcintyre[m] has joined #buildstream | 21:44 | |
| *** mattiasb has joined #buildstream | 22:02 | |
| *** m_22[m] has joined #buildstream | 22:08 | |
| *** asingh_[m] has joined #buildstream | 22:27 | |
| *** alatiera1 has joined #buildstream | 22:28 | |
| *** alatiera1 is now known as alatiera2 | 22:30 | |
| *** alatiera2 is now known as alatier4 | 22:30 | |
| *** alatier4 is now known as alatier6 | 22:32 | |
| *** alatier6 is now known as alatiera | 22:32 | |
| *** awacheux[m] has joined #buildstream | 22:36 | |
| *** pro[m] has joined #buildstream | 22:51 | |
| *** jjardon[m] has joined #buildstream | 22:54 | |
| *** Demos[m] has joined #buildstream | 23:07 | |
| *** rafaelff[m] has joined #buildstream | 23:14 | |
| *** kailueke[m] has joined #buildstream | 23:22 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!