| gitlab-br-bot | buildstream: issue #233 ("Do not push artifact that have been downloaded from the cache") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/233 | 01:17 |
|---|---|---|
| *** ruben has quit IRC | 01:25 | |
| *** ruben has joined #buildstream | 01:28 | |
| *** ruben has quit IRC | 01:31 | |
| *** Prince781 has joined #buildstream | 02:06 | |
| *** Prince781 has quit IRC | 03:57 | |
| *** mcatanzaro has quit IRC | 04:16 | |
| *** noisecell has joined #buildstream | 06:34 | |
| *** noisecell has quit IRC | 06:37 | |
| *** noisecell has joined #buildstream | 06:39 | |
| *** noisecell has quit IRC | 06:53 | |
| *** noisecell has joined #buildstream | 06:53 | |
| *** aday has joined #buildstream | 09:17 | |
| *** adds68 has joined #buildstream | 09:37 | |
| *** adds68_ has joined #buildstream | 09:58 | |
| *** adds68 has quit IRC | 09:59 | |
| *** ssam2 has joined #buildstream | 10:13 | |
| *** adds68_ has quit IRC | 10:44 | |
| *** adds68_ has joined #buildstream | 10:44 | |
| ssam2 | juergbi, my worry about overlayfs, which i haven't researched much yet, is how well it works at layering many filesystems | 10:47 |
| ssam2 | the interface seems to only support layering 2 | 10:47 |
| juergbi | yes, i don't know whether it would be suitable for the many-layer case | 10:48 |
| juergbi | however, it would be very useful for the current hardlinking approach | 10:48 |
| ssam2 | ah, yes it would | 10:49 |
| juergbi | as we can separate the writes into the upper layer (which could still be FUSE for #38 and other things) | 10:49 |
| juergbi | https://gitlab.com/BuildStream/buildstream/commit/0e0990c5557f3b454f54f412d3c28c4bd4b4aaf7 | 10:49 |
| juergbi | ssam2: does the above patch look good to me as a short term solution for now? | 10:50 |
| juergbi | eh, to you | 10:50 |
| ssam2 | makes sense, yeah | 10:50 |
| ltu | reminder that there's the monthly meeting at 14:00 UTC today. Any additions to the agenda, please go ahead and respond to my mail to the last from last week. | 10:51 |
| juergbi | it fixed the issue for vala for me even with -j32 | 10:51 |
| ssam2 | tlater, can you reply to the agenda mail to add this UNIX-platform staging iussue ? | 10:52 |
| *** aday has quit IRC | 10:53 | |
| * tlater is in the process of doing so | 10:54 | |
| gitlab-br-bot | buildstream: merge request (juerg/fuse-rlimit->master: Increase the soft limit for open file descriptors) #260 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/260 | 10:55 |
| *** adds68_ has quit IRC | 10:56 | |
| gitlab-br-bot | buildstream: issue #232 ("fd leak when generating epiphany tarball") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/232 | 10:57 |
| gitlab-br-bot | buildstream: merge request (juerg/fuse-rlimit->master: Increase the soft limit for open file descriptors) #260 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/260 | 10:57 |
| *** adds68 has joined #buildstream | 11:00 | |
| *** aday has joined #buildstream | 11:07 | |
| *** adds68 has quit IRC | 11:31 | |
| *** adds68 has joined #buildstream | 11:31 | |
| *** toscalix has joined #buildstream | 12:02 | |
| *** noisecell has quit IRC | 12:02 | |
| *** aday has quit IRC | 12:03 | |
| *** aday has joined #buildstream | 12:04 | |
| tlater | Do workspace commands not fetch anymore? | 12:05 |
| * tlater sees a lot of workspace-related test failures while rebasing his completions branch | 12:05 | |
| *** adds68 has quit IRC | 12:08 | |
| *** adds68 has joined #buildstream | 12:09 | |
| *** ruben has joined #buildstream | 12:14 | |
| *** ruben has quit IRC | 12:26 | |
| *** jonathanmaw has joined #buildstream | 12:30 | |
| juergbi | hm, i'm not aware of a change in that regard | 12:37 |
| tlater | I'm not sure what's happening here | 12:38 |
| tlater | As far as I can tell it looks like the elements are put in the FetchQueue as expected | 12:39 |
| tlater | But they are never actually fetched | 12:39 |
| tlater | Trying to set `skip_cached=False` makes buildstream get stuck calculating some cache key | 12:39 |
| * tlater thinks about just rewriting the branch from scratch | 12:40 | |
| tlater | Hm, the process() method of the fetch queue isn't even called | 12:42 |
| *** tristan has joined #buildstream | 12:46 | |
| * tlater suspects this broke with the element state changes | 12:58 | |
| juergbi | tlater: if skip_cached=False didn't work anymore, `bst fetch` would also be broken, wouldn't it? | 13:02 |
| tlater | Yeah, which confuses me | 13:02 |
| gitlab-br-bot | buildstream: merge request (completion-optimizations->master: WIP: Completion optimizations) #256 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/256 | 13:04 |
| gitlab-br-bot | buildstream: issue #234 ("Allow viewing build logs from artifacts") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/234 | 13:07 |
| *** mcatanzaro has joined #buildstream | 13:14 | |
| gitlab-br-bot | buildstream: merge request (completion-optimizations->master: WIP: Completion optimizations) #256 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/256 | 13:21 |
| *** sstriker has joined #buildstream | 13:36 | |
| gitlab-br-bot | buildstream: merge request (completion-optimizations->master: WIP: Completion optimizations) #256 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/256 | 13:44 |
| gitlab-br-bot | buildstream: merge request (212-git-source-needs-a-way-to-disable-checking-out-submodules->master: WIP: Resolve "Git source needs a way to disable checking out submodules") #259 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/259 | 13:46 |
| gitlab-br-bot | buildstream: merge request (completion-optimizations->master: Completion optimizations) #256 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/256 | 13:51 |
| ssam2 | buildstream team IRC meeting is starting in 9 minutes in #buildstream-meetings | 13:51 |
| ssam2 | all welcome | 13:51 |
| *** sstriker has quit IRC | 13:51 | |
| *** sstriker has joined #buildstream | 13:52 | |
| gitlab-br-bot | buildstream: merge request (completion-optimizations->master: Completion optimizations) #256 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/256 | 13:53 |
| *** mib_u3lusx has joined #buildstream | 13:55 | |
| *** mib_u3lusx has left #buildstream | 13:56 | |
| *** mib_u3lusx has joined #buildstream | 13:57 | |
| *** gnurlu has joined #buildstream | 13:58 | |
| *** dplayle has joined #buildstream | 13:58 | |
| *** dplayle has quit IRC | 14:01 | |
| *** Benjamin has joined #buildstream | 14:10 | |
| *** noisecell has joined #buildstream | 14:26 | |
| *** hashpling has joined #buildstream | 14:46 | |
| *** ssam2 has quit IRC | 14:50 | |
| *** ssam2 has joined #buildstream | 14:50 | |
| *** noisecell has quit IRC | 15:01 | |
| mcatanzaro | Regarding https://gitlab.com/BuildStream/buildstream/issues/232. "Disable parallel builds" is not a really great solution for build software.... | 15:05 |
| ssam2 | agreed :-) | 15:06 |
| ssam2 | https://gitlab.com/BuildStream/buildstream/commit/0e0990c5557f3b454f54f412d3c28c4bd4b4aaf7 should hopefully fix the issue | 15:06 |
| ssam2 | if not ... we are going to be reworking all this code in due course anyway | 15:06 |
| ssam2 | we need to fix the infamous issue #38 for example (https://gitlab.com/BuildStream/buildstream/issues/38) | 15:06 |
| ssam2 | so now that we know it's an issue, we can mitigate it | 15:07 |
| *** gnurlu has quit IRC | 15:08 | |
| juergbi | mcatanzaro: please let me know whether the issue is fixed for you as well in master | 15:09 |
| mcatanzaro | juergbi: I'll try master in a sec (but I doubt raising the rlimit for open files actually does anything on Linux?) | 15:09 |
| juergbi | it fixed the issue for me. why don't you think this would help on Linux? | 15:10 |
| juergbi | it does depend on what the soft and hard limits are set to on your system / for your user, though | 15:10 |
| juergbi | we can hopefully avoid requiring that many file descriptors in the future but that will take a while | 15:11 |
| mcatanzaro | juergbi: Is the soft limit really lower than the hard limit? OK, I'll try | 15:12 |
| mcatanzaro | Anyway, I'm now more worried about https://gitlab.com/BuildStream/buildstream/issues/227#note_57840688 (new comment) | 15:13 |
| juergbi | you can check ulimit -n vs. ulimit -n -H | 15:13 |
| juergbi | it's 1024 vs 4096 here | 15:13 |
| juergbi | taking a look | 15:14 |
| mcatanzaro | Oh cool! | 15:16 |
| *** hashpling has quit IRC | 15:18 | |
| juergbi | oh, maybe that's a cache key conflict | 15:18 |
| mcatanzaro | juergbi: I tried the new version and it did avoid the fd limit, thanks | 15:18 |
| juergbi | thanks for testing | 15:18 |
| juergbi | tristan: the potential cache key issue we talked about a week ago or so: the cache key of the platform-specific bootstrap/toolchain does not apply to weak cache keys | 15:19 |
| juergbi | so it's actually trivial to get (weak) cache key conflicts right now with different platforms and i suspect that's what's happening here | 15:20 |
| juergbi | or maybe not | 15:27 |
| *** noisecell has joined #buildstream | 15:29 | |
| tristan | juergbi, whooooops | 15:31 |
| juergbi | probably not the exact issue here but still something we need to fix | 15:31 |
| tristan | juergbi, the question is whether to backport a fix to 1.0 I guess ? | 15:31 |
| tristan | well | 15:31 |
| tristan | ahhh I guess it can happen for weak cache keys yes | 15:32 |
| juergbi | mcatanzaro: libbsd.so exists here in the sandbox | 15:38 |
| tlater | ssam2: Is there a reason the docker plugin hasn't landed in buildstream-external yet? | 15:38 |
| juergbi | error 24 is actually the same file descriptor issue again | 15:38 |
| ssam2 | no blockers as far as I know | 15:38 |
| juergbi | mcatanzaro: did you see these test failures with master or was this before the update? | 15:38 |
| mcatanzaro | juergbi: It's from before the update, I'll try again | 15:39 |
| tlater | Could we land that and the alpine image? I'd like to merge my docs for that soonish. | 15:39 |
| ssam2 | what do you think juergbi ? | 15:39 |
| ssam2 | sorry to pull you 3 ways at once :) | 15:39 |
| juergbi | i haven't reviewed these changes but i don't have any general objections | 15:41 |
| tlater | jonathanmaw could have a look, I suppose, he's probably closest to the plugin code atm | 15:42 |
| jonathanmaw | tlater: would that be !9: "Add Docker source plugin" by ssam2 ? | 15:44 |
| * tlater believes so | 15:44 | |
| tristan | juergbi, I started hacking something for it just to see, and here is my conundrum | 15:44 |
| * jonathanmaw can have a look | 15:45 | |
| tristan | juergbi, I want to ultimately use the execution environment to inform cache keys, and have the sandbox inform a unique key much like plugins do | 15:45 |
| tristan | but there is no sandbox at cache key calculation time :-S | 15:46 |
| tristan | juergbi, I guess it would be safe to assume at least that once a project is loaded, the execution environment of an element is resolved and will not change | 15:47 |
| persia | Can we be confident that a sandbox is deterministic based on description, and do we have the sandbox description at cache key calculation time? | 15:47 |
| tristan | We dont want that rule by sandbox type, at least | 15:47 |
| persia | Ah, right. | 15:48 |
| tristan | I.e. we want a sandbox type which can provide alternative execution enviroments | 15:48 |
| tristan | Creating a sandbox for each element will increase the memory footprint a lot (but I'm not really sure what that footprint *is* right now) | 15:49 |
| tristan | hmm, it's not a lot of data though, mostly static code | 15:49 |
| tristan | hrm, requires churn anyway | 15:50 |
| tristan | sandbox directory configuration at least | 15:50 |
| jmac | I keep getting "bwrap: execvp sh: No such file or directory" while trying to write manual install rules, and I can't remember what it means | 15:53 |
| juergbi | tristan: i would definitely expect the information at load time to suffice | 15:53 |
| ssam2 | jmac, it either means your sandbox has no /bin/sh, or it has a symlink at /bin/sh that points to something that doesn't exist, or you are missing the dynamic loader such as /lib/ld-linux.so.2 | 15:54 |
| jmac | That's odd | 15:55 |
| jmac | Missing dependency on base/base-configure.bst | 15:56 |
| tristan | juergbi, it's a lot of churn to do it right, maybe we need a quicker fix | 16:00 |
| tristan | If we add something temporary directly in element.py, we can later delegate that to Sandbox() after some churn, without bumping the artifact version a second time | 16:02 |
| juergbi | for now we could put something like `uname -sm` in the cache key | 16:02 |
| juergbi | the cache key will still change again unless the Sandbox (at least on major platforms) produces exactly the same unique key | 16:03 |
| tristan | right, however it ends up being implemented (it may be that the Sandbox need only be told what the execution environment is) | 16:03 |
| tristan | juergbi, I'm assuming that the bwrap and chroot sandboxes will continue to calculate the cache key in the same way | 16:04 |
| tristan | although it will merit a break later when we add something like linux vs bsd into the mix | 16:04 |
| juergbi | yes, we'll need that\ | 16:05 |
| juergbi | right now, we're not at risk of conflict between linux and non-linux because ostree is linux-only | 16:05 |
| tristan | is there a generic way to get it in python ? | 16:05 |
| persia | Maybe inject more of uname in early to avoid the break? | 16:06 |
| tristan | or try to parse /etc/os-release and weird things like this | 16:06 |
| juergbi | that's way too specific | 16:06 |
| persia | I don't think /etc/os-release exists for most unices | 16:06 |
| juergbi | and we also don't want to make the cache key distro-specific on linux | 16:07 |
| tristan | more of uname looks good | 16:07 |
| persia | Indeed, I don't have /etc/os-release on a local Mach/Darwin environment. | 16:07 |
| tristan | and has a python layer | 16:07 |
| tristan | os.uname() | 16:08 |
| persia | I think we need to stick to things that are required by the Single UNIX Specification | 16:08 |
| tristan | so will maybe do something useful on windows even | 16:08 |
| persia | Not all of uname, as part of it is comment (often used for things like build ID, etc.) | 16:08 |
| tristan | the first field and the arch | 16:09 |
| tristan | Linux and x86_64 | 16:09 |
| persia | That seems a reasonable match. | 16:09 |
| juergbi | i'm wondering whether we actually might need to change the approach a bit for weak cache keys | 16:10 |
| persia | Be nice if we could get a userland string to go with that, but I'm not sure there is a portable way to do that (for things like GNU/BSD or similar) | 16:10 |
| juergbi | project options/variants that influence the bootstrap or something else low level (e.g., whether libselinux is used) are currently not taken into account for weak cache keys either | 16:11 |
| juergbi | well libselinux would be in the recursive dependency list but there might be something else that is not covered by dependency names | 16:11 |
| persia | juergbi: Unless the base runtime included libselinux, making it opaque to the build scripts | 16:12 |
| juergbi | indeed | 16:12 |
| juergbi | one alternative would be to bring weak cache keys closer to strong cache keys. just stripping out the source refs of dependencies but leave all other key contributions in | 16:13 |
| juergbi | i.e., command and option changes in dependencies would be reflected in weak cache keys, only code changes would be ignored | 16:14 |
| juergbi | hm, that's actually still not sufficient for the example of base image variants with project option conditionals | 16:15 |
| juergbi | (as the unique key doesn't include project options per se) | 16:15 |
| tristan | optionality significantly changes things which individually contribute to cache key | 16:15 |
| juergbi | yes but when stripping out source refs, we would lose some of that again | 16:16 |
| tristan | yes it's possible to weak cache key collide with something built against a depenedency with a different option turned on | 16:16 |
| tristan | stripping out source refs ?? | 16:16 |
| juergbi | for weak cache keys | 16:16 |
| tristan | Oh you mean the cache keys of the dependencies | 16:16 |
| juergbi | yes | 16:16 |
| juergbi | i was simply thinking about alternative possibilities | 16:16 |
| *** csoriano has quit IRC | 16:16 | |
| tristan | yes well, it is possible to collide with alternative configurations | 16:17 |
| *** csoriano has joined #buildstream | 16:17 | |
| juergbi | yes and i this might be a practical issue for GNOME where non-strict is even in the recommendation | 16:17 |
| tristan | juergbi, I'm not sure how problematic that is in practice though | 16:17 |
| juergbi | it depends on who has push access to the remote cache, i suppose | 16:17 |
| tristan | I'm reluctant to strengthen cache keys with optionality :-/ | 16:18 |
| juergbi | the biggest practical risk i see right now for GNOME is weak cache key conflicts for different architectures | 16:21 |
| juergbi | the rest is mainly theoretical for now but we should further look into it | 16:22 |
| tristan | juergbi, is there an issue number for this ? | 16:22 |
| tristan | arch/os thing ? | 16:22 |
| juergbi | i don't think so. can file one | 16:23 |
| tristan | hold on... | 16:23 |
| gitlab-br-bot | buildstream: merge request (cache-keys-os-arch->master: Cache keys to consider OS and machine arch) #261 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/261 | 16:27 |
| tristan | juergbi, !261 above should do it I think | 16:27 |
| juergbi | yes, that looks like a reasonable change. we may have to give this more thoughts in the future, though | 16:32 |
| gitlab-br-bot | buildstream: issue #235 ("Add the ability to generate manifest files") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/235 | 16:39 |
| jmac | Is there a pre-written element for getting Python setuptools onto a system? | 16:42 |
| ssam2 | how about https://gitlab.com/freedesktop-sdk/freedesktop-sdk/blob/master/sdk/elements/base/python3-setuptools.bst ? | 16:45 |
| jmac | I'll give it a try, thanks | 16:49 |
| *** ruben has joined #buildstream | 16:57 | |
| jmac | So many dependencies... | 17:00 |
| tlater | Ack | 17:00 |
| tlater | Did I just accidentally push to origin/master? | 17:00 |
| tlater | Why is the branch not protected? ;-; | 17:00 |
| tlater | Is it safe to force-push a branch without my last commit? | 17:01 |
| persia | jmac: Maybe base your work on a platform that contains the necessary dependencies? I know there are some based on debian, freedesktop-sdk, and baserock floating around. | 17:01 |
| persia | tlater: It is safe if nobody else has pulled. There is no logging of pulls. Less time is better when you change history. Better rule: don't change history. | 17:02 |
| persia | In an environment with active CI, CI always pulls very quickly, making force-push impossible to be safe. | 17:02 |
| * tlater is highly tempted to change history before someone pull | 17:02 | |
| tlater | 8s | 17:02 |
| persia | Common workaround for CI environments is to push a reversion commit, undoing all the changes. | 17:03 |
| jmac | That's an option | 17:03 |
| persia | good practice is to protect branches that are commonly pulled :) | 17:03 |
| * persia doesn'T actually know the policy for buildstream | 17:03 | |
| ssam2 | i think we don't have one | 17:03 |
| persia | tristan: juergbi: ^^ ?? | 17:03 |
| ssam2 | and i think if it is protected, those with superpowers can push anyway | 17:04 |
| ssam2 | so i would say let's enable protection for 'master' | 17:04 |
| persia | ssam2: Yes they can. | 17:04 |
| * persia believes in only giving robots superpowers, but that requires lots of time programming the robots | 17:04 | |
| *** ruben has quit IRC | 17:05 | |
| tlater | I wasn't even aware I had permissions to push to master :| | 17:05 |
| *** ruben_ has joined #buildstream | 17:05 | |
| * tlater figures this commit can't hurt much, since it's only docs, but still feels annoyed at the implications on history | 17:05 | |
| juergbi | force push on public master branches should really be avoided | 17:06 |
| *** ruben_ is now known as ruben | 17:06 | |
| juergbi | nobody might notice in this case but we should probably still not do it | 17:06 |
| tlater | I'll just keep the commit and hope for it to get lost under lots of merges this week | 17:06 |
| jmac | I don't think anyone intends to | 17:07 |
| persia | tlater: Submit an MR correcting the bits that need correcting soonest, maybe? | 17:07 |
| *** noisecell has quit IRC | 17:07 | |
| persia | juergbi: Do you have sufficient superpowers to protect public master so that it is hard to accidentally push there? | 17:07 |
| tlater | persia: Far from complete, unfortunately, I pushed a .rst file to see what gitlab would spit out when rendering it | 17:07 |
| juergbi | master is already protected | 17:08 |
| tlater | Ah | 17:08 |
| juergbi | only 'Masters' can push | 17:08 |
| persia | tlater: Were I in your shoes, I'd consider finishing that bit of work my highest priority. I have made that class of mistake before when working with CI, which led to more intensity than I usually commit in trying to restore the branch to a status I was happy others using (at the time, I was in a far different timezone than other developers, which made that easier). | 17:09 |
| persia | juergbi: Are any other permissions associated with "Master"? | 17:09 |
| juergbi | maybe membership management? i'm not sure | 17:09 |
| *** toscalix has quit IRC | 17:10 | |
| tlater | You can specify permissions for individual users - perhaps 'Master' is just too generic | 17:10 |
| persia | That was my thought. If someone can override protection without knowing, perhaps we're not being careful enough about permissioning. | 17:11 |
| *** ruben has quit IRC | 17:12 | |
| ssam2 | i presume tlater was given master permissions to be able to configure CI | 17:12 |
| *** adds68_ has joined #buildstream | 17:14 | |
| *** ruben has joined #buildstream | 17:14 | |
| *** ruben has quit IRC | 17:14 | |
| *** adds68 has quit IRC | 17:15 | |
| *** ruben has joined #buildstream | 17:16 | |
| persia | That makes sense, and is a good thing. I suppose it's just communications that need improvement. I don7t want to take away superpowers, just reduce accidents. | 17:17 |
| *** ruben has quit IRC | 17:17 | |
| tlater | Hrm, I suppose I'd have made the same mistake otherwise - did not realize I had my master branch checked out | 17:18 |
| * tlater is sorry for the disruption :| | 17:18 | |
| persia | The nice part of the disruption is that we now have a draft policy for force push: "force push on public master branches should really be avoided". | 17:19 |
| jmac | It needs work | 17:19 |
| *** ernestask has joined #buildstream | 17:20 | |
| *** ssam2 has quit IRC | 17:41 | |
| *** jonathanmaw has quit IRC | 18:01 | |
| jjardon[m] | Hi, can anyone here guide me where do you want this info? https://gitlab.com/BuildStream/buildstream/issues/226 | 18:04 |
| jjardon[m] | also, any news about the possibility to have a pre-release tag? | 18:05 |
| persia | jjardon[m]: We discussed having a dev release next week in today's meeting. Would that meet your needs? | 18:07 |
| jjardon[m] | sure | 18:08 |
| *** adds68_ has quit IRC | 18:08 | |
| jjardon[m] | Its more a conviniant thing so I can tell possible users of our project to "Use this tag" instead "use this SHA" | 18:09 |
| gitlab-br-bot | buildstream: issue #230 ("Error when trying to "bst shell" in a component") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/230 | 18:32 |
| gitlab-br-bot | buildstream: merge request (image-authoring->master: Image authoring documentation) #262 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/262 | 18:44 |
| tlater | ^ That is the MR to fix my oopsie from earlier, but I don't think it should be merged before a few other things are merged | 18:46 |
| tlater | I guess this will have to happen tomorrow | 18:46 |
| * tlater departs, still somewhat shaken | 18:48 | |
| jjardon[m] | tlater: in our project no one can push directly to master, all the changes should go through merge request. we can do the same here but maybe still allow tristan juergbi to commit directly to master | 19:40 |
| jjardon[m] | tristan: do you want me to activate review aprovals, so at least 1 person needs to approve before merge? | 19:41 |
| *** adds68_ has joined #buildstream | 19:45 | |
| persia | While I personally like the "all changes need to be approved by the robot" model, it does break common git workflow and require using a web UI to do things. | 19:46 |
| persia | (even if the robot is just counting folk who pressed the "approve" button) | 19:47 |
| *** mcatanzaro has quit IRC | 19:55 | |
| jjardon[m] | persia: you can approve from the command line. But yeah as I said is totally configurable | 20:00 |
| juergbi | strictly applied it can conflict with the current policy of only fast forward merges | 20:01 |
| juergbi | as branches in other repositories can't be rebased in the web UI | 20:01 |
| jjardon[m] | persia: not sure if it breaks the git workflow though: you still need someone to aprove your patch even if you send it attached in an email | 20:01 |
| jjardon[m] | ah, thats a limitation yes | 20:02 |
| persia | The webUI doesn't have a rebase button? Wow! This is the first time I've ever heard about a UI feature where gerrit is ahead of other tooling :) | 20:05 |
| juergbi | persia: it normally does | 20:06 |
| juergbi | the issue is that the source branch may be in a different repo and then there is no rebase possibility for me as approver | 20:07 |
| persia | But not when you enable the feature jjardon[m] is describing? | 20:07 |
| persia | Ah, right, that makes sense. The approver would need to have access to the source branch to do that. | 20:07 |
| juergbi | exactly | 20:07 |
| juergbi | we grant developer access to contributors, so everyone could create branches in the main repo at least after the first contribution | 20:08 |
| juergbi | but it's not always the case | 20:08 |
| persia | Does that mean that approvers would be able to rebase those contributions using the UI? | 20:08 |
| juergbi | yes, it works for branches in the main repo | 20:09 |
| juergbi | (if the rebase is possible without conflicts) | 20:09 |
| persia | Ah, right, then my preference would be to turn it on, and allow a very small number of special people to push manually for the special case of rebasing out-of-repo MRs. | 20:09 |
| persia | And, yes, I don't imagine any robot can safely rebase where the rebase isn't clean: git assumes that requires human intelligence, and I suspect it is right. | 20:10 |
| juergbi | this could indeed be sensible | 20:10 |
| juergbi | one thing that gitlab could support but doesn't is allowing to change the source branch of an existing MR | 20:10 |
| juergbi | then i could manually rebase it and push it to a new branch in the main repo, updating the MR | 20:10 |
| persia | Or allow collaboration on MR source branches in some way. | 20:11 |
| juergbi | yes | 20:11 |
| connorshea[m] | this'd be the issue for that https://gitlab.com/gitlab-org/gitlab-ce/issues/22292 | 20:15 |
| *** ernestask has quit IRC | 20:19 | |
| connorshea[m] | also this is the best issue I can find for changing the source branch https://gitlab.com/gitlab-org/gitlab-ce/issues/32952 | 20:19 |
| connorshea[m] | also Carlos opened an issue for this, apparently https://gitlab.com/gitlab-org/gitlab-ce/issues/39756 | 20:22 |
| *** valentind has joined #buildstream | 21:04 | |
| persia | connorshea[m]: Thanks! Those are great to be able to track easily. | 21:19 |
| jjardon[m] | Hi! Is it possible to build for armv7 with aarch64 runners? I think I'm hitting a incompatibility when trying to doing that: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/merge_requests/54#note_57921777 | 21:31 |
| *** mcatanzaro has joined #buildstream | 22:13 | |
| *** aday has quit IRC | 22:32 | |
| *** mcatanzaro has quit IRC | 22:40 | |
| *** adds68_ has quit IRC | 23:06 | |
| *** valentind has quit IRC | 23:12 | |
| *** tristan has quit IRC | 23:27 | |
| *** mcatanzaro has joined #buildstream | 23:45 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!