| persia | Is anyone in touch with jbicha about the Debian package? Seems it is still 1.2.4, which is confusing a user I happened to encounter in person this week, who wanted to use a project that requires 1.4+ | 01:16 |
|---|---|---|
| *** narispo has quit IRC | 01:25 | |
| *** narispo has joined #buildstream | 01:26 | |
| persia | User now sorted using pip, but the query still stands (for the next one). | 02:23 |
| *** rdale has quit IRC | 03:17 | |
| *** adds68 has joined #buildstream | 06:05 | |
| juergbi | laurence: why would we have to regenerate the committers list if we disable direct push access for maintainers? | 07:35 |
| *** qinusty has joined #buildstream | 07:42 | |
| laurence | juergbi, sorry was just registering my nick... | 07:43 |
| laurence | juergbi, here's what I was thinking: | 07:43 |
| laurence | juergbi, iirc the script is set to generate a) those with dev permissions and named access and b) maintainers and owners (as they automatically are committers). So in that case there is a chance that we may amend someone from being a maintainer to a dev with named access | 07:43 |
| laurence | However, that doesn't matter, now that I think about it | 07:44 |
| laurence | the committers themselves aren't changing | 07:44 |
| laurence | Anyway, could be a sensible thing to do - keep the gitlab permissions in line with the committers list | 07:44 |
| Kinnison | The point of locking master is that you could be the most highly powerful user (owner?) and still not push to master without first going and explicitly unblocking it | 07:47 |
| juergbi | for a) the script checks which users are allowed to merge | 07:47 |
| Kinnison | Not to demote existing users to different permissions levels | 07:47 |
| Kinnison | no? | 07:47 |
| juergbi | the proposed change would be to limit who is allowed to directly push (to nobody) but keep the users that are allowed to merge the same | 07:47 |
| juergbi | so the script shouldn't need to change and the same list should be generated | 07:47 |
| juergbi | Kinnison: correct | 07:48 |
| juergbi | at least that's how I understand it as well | 07:48 |
| Kinnison | it's what we do for certain branches in Rustup | 07:49 |
| Kinnison | though that's github, so I don't know if gitlab is directly equivalent | 07:49 |
| juergbi | it makes sense as everyone should (and normally is) anyway going through MRs | 07:49 |
| juergbi | and as I mentioned, it's quick to change for whatever emergency | 07:49 |
| laurence | fine by me, all good points, I'll keep out of it | 07:50 |
| juergbi | that wasn't the intention :) | 07:50 |
| laurence | juergbi, i know :) but i've not grasped it properly :) | 07:51 |
| *** bochecha has joined #buildstream | 07:52 | |
| *** ikerperez has joined #buildstream | 07:54 | |
| jjardon | persia: Ive tried to contact him directly a couple of times but no luck. If someone knows about Debian packaging I guess we could send a MR to https://salsa.debian.org/gnome-team/buildstream ? Not sure that's the normal Debian workflow though | 07:55 |
| Kinnison | The gnome team in Debian moves slowly, and after a release they'll likely be taking a bit of a break | 07:57 |
| Kinnison | For infra tooling they probably won't update until gnome needs buildstream updating | 07:58 |
| Kinnison | Filing an MR on salsa might work, but it'll depend on the team's individual behaviour | 07:58 |
| *** paulsherwood has joined #buildstream | 08:00 | |
| *** paulsherwood has joined #buildstream | 08:01 | |
| persia | jjardon: Thanks for checking. If things get really stuck, poke me, and I'll run an update, but it's generally better for the maintainer to do it (and a cursory check indicates this is listed as an individual, not a team). | 08:08 |
| persia | Kinnison: gnome-build-meta junctions freedesktop-sdk, so I'm guessing that using 1.4 becomes impiortant soon (it was an attempt to play with freedesktop-sdk and buildstream that led to the issue that caused me to be asked "maybe you know ..." earlier today). | 08:09 |
| *** rdale has joined #buildstream | 08:31 | |
| benschubert | I'm thinking about making 'Node._strip_node_info' public, as some plugins in bst-plugins-experimental would have their life much easier if that was the case. Any opinion? | 08:53 |
| Kinnison | I think it'd be reasonable to make that public, yes. That's the node_sanitize() equivalent isn't it? | 08:55 |
| benschubert | node_sanitize, and appartenly as_dict? Not remembering this one, but there is definitely some usages in bst-plugins-experimental | 08:56 |
| benschubert | (https://gitlab.com/BuildStream/bst-plugins-experimental/blob/master/bst_plugins_experimental/elements/collect_manifest.py#L84) | 08:57 |
| coldtom | i think this is probably fixable by making the plugins use Node objects rather than converting | 08:58 |
| benschubert | coldtom: that would be ideal, but https://gitlab.com/BuildStream/bst-plugins-experimental/blob/master/bst_plugins_experimental/elements/collect_manifest.py#L155 is explicitely not possible in BuildStream unless using the strip_node_info | 09:00 |
| *** phildawson_ has joined #buildstream | 09:06 | |
| *** traveltissues has joined #buildstream | 09:24 | |
| gitlab-br-bot | jennis opened issue #1135 (We often use a string instead of a PipelineSelection in Stream) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1135 | 10:06 |
| benschubert | jennis: ^ FastEnum? | 10:06 |
| jennis | yeah, it's not detrimental | 10:07 |
| jennis | Just for cleanliness | 10:07 |
| benschubert | juergbi for adding tests to ensure we handle buildbox-casd errors correctly, where would you put them? in tests/artifactcache? | 10:28 |
| juergbi | benschubert: not sure, maybe rather tests/internals? | 10:29 |
| benschubert | make sense, thanks! | 10:30 |
| gitlab-br-bot | marge-bot123 merged MR !1469 (build-all-option->master: Add 'dependencies' option to 'build' user config) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1469 | 10:34 |
| jjardon | what is the first BST_FORMAT_VERSION supported by bst master ? | 10:34 |
| *** tme5 has joined #buildstream | 11:13 | |
| tme5 | can anyone point me to docs of how to use the pip source? I'm getting an error because i'm using pip as the first source for an element | 11:17 |
| tme5 | i've looked here https://docs.buildstream.build/1.4.1/sources/pip.html but it doesn't mention that | 11:17 |
| coldtom | aiui pip sources are used to download the pip dependencies of your source, and require some actual source code | 11:22 |
| coldtom | i think you could just get a binary from pip by using a `local` source with the module you want listed in a `requirements.txt`, but that's quite hacky | 11:23 |
| tme5 | oh right | 11:23 |
| tme5 | i suppose i could also fetch the wheel from pypi with a remote source and do it that way | 11:24 |
| coldtom | that would be a lot nicer than the hack i just suggested :P | 11:25 |
| gitlab-br-bot | cs-shadow opened MR !1602 (chandan/fix-news->master: NEWS: Use past-tense, fix note about YAML cache) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1602 | 11:25 |
| cs-shadow | tme5: that's an unfortunate limitation of how previous source access currently works in BuildStream. Using a remote source is certainly a valid option if you only have a handful of dependencies. Be careful as you'll have to manage your transitive dependencies and version conflicts yourself that way. | 11:32 |
| cs-shadow | The documentation for the pip plugin is lacking and should be improved that to say that it can't be the first source | 11:32 |
| cs-shadow | if you do no need to use pip source in this case, the current workaround would be to have dummy first source, like a local source or something lightweight | 11:33 |
| gitlab-br-bot | jjardon opened issue #1136 (Buildstream should fail if it tries to build a project with a BST_FORMAT_VERSION not supported anymore) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1136 | 12:00 |
| jjardon | Hi, before start trying fixing all the failing tests, can anyone take a look to https://gitlab.com/BuildStream/buildstream/merge_requests/1603/ to check that one is the right approach? | 12:21 |
| juergbi | jjardon: a single linear format version number might not be ideal anymore. maybe it would be best to discuss this with tristan. he's back on Monday, afaik | 12:24 |
| jjardon | juergbi: sure, I only try to fix the immediate problem, which is people trying to use master and get confusing errors | 12:25 |
| jjardon | maybe we can go for this and refine later? No rush anyway, we can discuss when tristan come back | 12:26 |
| juergbi | yes and that's good. would probably make sense to get this in for the planned development snapshot | 12:26 |
| juergbi | I don't have any objections getting this in for now and refine it later if needed | 12:26 |
| benschubert | my only concern is, is format 18 still supported? | 12:27 |
| jjardon | I do not know, but 17 definitely isn't | 12:28 |
| benschubert | Ok, it might just be hard for users if they get 'format 18 is minimal version' and they are on 18 and it doesn't work :) Might be worth checking before, but as a temporary stop the bleeding, that seems good to me | 12:28 |
| jjardon | ok, cool | 12:29 |
| *** bochecha has quit IRC | 13:15 | |
| *** bochecha has joined #buildstream | 13:15 | |
| *** bochecha has quit IRC | 13:20 | |
| *** bochecha has joined #buildstream | 13:21 | |
| gitlab-br-bot | jjardon opened (was WIP) MR !1603 (jjardon/BST_FORMAT_VERSION->master: Fail if we try to build a BST_FORMAT_VERSION we do not support anymore) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1603 | 13:52 |
| jjardon | Can I have reviews, please? juergbi ^ | 13:54 |
| gitlab-br-bot | juergbi approved MR !1603 (jjardon/BST_FORMAT_VERSION->master: Fail if we try to build a BST_FORMAT_VERSION we do not support anymore) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1603 | 13:56 |
| gitlab-br-bot | jjardon closed issue #1136 (Buildstream should fail if it tries to build a project with a BST_FORMAT_VERSION not supported anymore) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1136 | 13:56 |
| gitlab-br-bot | jjardon merged MR !1603 (jjardon/BST_FORMAT_VERSION->master: Fail if we try to build a BST_FORMAT_VERSION we do not support anymore) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1603 | 13:56 |
| juergbi | marge wouldn't be happy ;) | 13:57 |
| jennis | :O | 13:57 |
| jjardon | ooops, sorry; there was nothing on the queue at least so I think she will not complain | 14:00 |
| jennis | shame 🔔 | 14:04 |
| jjardon | XD | 14:06 |
| gitlab-br-bot | BenjaminSchubert approved MR !1600 (jjardon/distutils->master: Use distutils plugin from bst-plugins-experimental) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1600 | 14:21 |
| benschubert | jjardon: https://gitlab.com/BuildStream/buildstream/-/jobs/293633050 the nightly tests are almost passing again. Take ages though. Would it be worth having a smaller target or are we fine with that? (I'm personally fine with it) Also, would you be fine with taking ownership of the freedesktop branch for them once I finally finished it? | 14:36 |
| jjardon | benschubert: that is great news! thanks | 14:39 |
| jjardon | benschubert: sure, please remind me what branch you use for this when done | 14:39 |
| coldtom | \o/ good work on getting the nightlies sorted! | 14:39 |
| benschubert | ok! I'll ping you, thanks! | 14:39 |
| benschubert | coldtom: it unveiled a surprisingly high number of bugs :( | 14:40 |
| * tlater[m] really likes the idea of 2.0.0.dev1 | 14:40 | |
| jjardon | benschubert: that is a actually a good thing though :) | 14:42 |
| benschubert | jjardon: definitely | 14:42 |
| tlater[m] | juergbi: Do you really think 2.0.0.dev1 would be such a big break? | 14:45 |
| tlater[m] | It's a totally different kind of snapshot than the development versions. | 14:45 |
| benschubert | ^ concerning pypi, if we are to publish them here, i *think* we need to follow this exact naming, that's how python should name its packages | 14:45 |
| tlater[m] | benschubert: Yeah, the discussion is whether to pick up PEP 440 versioning for the sake of making cs-shadow's life easier. | 14:47 |
| benschubert | tlater[m]: yep, that's what I mean, if we are to publish it to pypi, we need to follow it, otherwise 'pip install ' will fetch the latest version | 14:48 |
| * tlater[m] hopes we do | 14:52 | |
| tlater[m] | But I don't think it'd be impossible to jig around the version numbering for pypi's sake | 14:52 |
| benschubert | ah I see, yeah fair enough | 14:52 |
| cs-shadow | I was initially thinking about adding the .dev1 just for PyPI but I think it will lead to more confusions if`bst --version` and `pip show buildstream` don't match | 14:53 |
| tlater[m] | I also feel like .99 isn't obviously a development version. I'd probably have taken that as the latest version if I wasn't paying close attention. | 14:55 |
| benschubert | in a python world, i would definitely not expect it to be a python version | 14:57 |
| benschubert | *dev version | 14:57 |
| laurence | cs-shadow, just a small note - wrt maintainers and the committers file, you are indeed correct on the ML - ignore me! | 14:58 |
| gitlab-br-bot | jennis opened MR !1604 (jennis/split_contributing->master: Split up CONTRIBUTING) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1604 | 15:03 |
| cs-shadow | laurence: thanks for confirming | 15:04 |
| gitlab-br-bot | jennis approved MR !1602 (chandan/fix-news->master: NEWS: Use past-tense, fix note about YAML cache) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1602 | 15:07 |
| jennis | benschubert, cs-shadow, are you happy with: https://gitlab.com/BuildStream/buildstream/merge_requests/1590#note_216161723? | 15:09 |
| benschubert | good for my side | 15:10 |
| gitlab-br-bot | marge-bot123 merged MR !1600 (jjardon/distutils->master: Use distutils plugin from bst-plugins-experimental) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1600 | 15:13 |
| cs-shadow | jennis: one small note about sorting NEWS, looks good other than that | 15:16 |
| jennis | thanks cs-shadow | 15:18 |
| jennis | ermm I'm seeing an orange "cannot merge" triangle on marge when I assign her | 15:18 |
| cs-shadow | because of unresolved discussions? | 15:18 |
| jennis | Why would I just see it for marge and not for myself | 15:20 |
| jennis | Did we recently change it just so that maintainers can merge? | 15:20 |
| * cs-shadow hasn't touched anything | 15:21 | |
| jennis | cs-shadow, there is already a news entry for "introducing source checkout" | 15:22 |
| jennis | Perhaps I should just conflate my change with that entry | 15:23 |
| jennis | Or would you prefer it if we kept the entries separate? | 15:23 |
| cs-shadow | that seems sensible. I don't think people reading the NEWS have to know about the history of how changes were made :) | 15:23 |
| jennis | Agreed | 15:23 |
| jennis | cs-shadow, I've pushed the change: https://gitlab.com/BuildStream/buildstream/merge_requests/1590/diffs?commit_id=717b34335f54392c0d429b701afbcc3b3598b941 | 15:32 |
| gitlab-br-bot | cs-shadow approved MR !1590 (jennis/update_source_checkout->master: Ensure `source checkout` is symmetric to `artifact checkout`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1590 | 15:32 |
| cs-shadow | +1 thanks | 15:32 |
| jennis | thanks! | 15:33 |
| gitlab-br-bot | tlater reopened issue #773 (The command-line should provide access to artifacts) on buildstream https://gitlab.com/BuildStream/buildstream/issues/773 | 15:42 |
| *** bochecha has quit IRC | 16:23 | |
| *** phil has joined #buildstream | 16:30 | |
| benschubert | juergbi: seems like buildbox-casd doesn't handle SIGTERM, I get -15 as exit codes all the time :( | 16:31 |
| *** phildawson_ has quit IRC | 16:32 | |
| juergbi | oh, didn't realize that | 16:32 |
| juergbi | should fix that. although, I can't think of any real issues with immediate termination | 16:33 |
| benschubert | it's probably fine, but would be much nicer to handle it :) | 16:35 |
| *** tme5 has quit IRC | 16:36 | |
| benschubert | juergbi: I would have this : https://gitlab.com/BuildStream/buildstream/compare/master...bschubert%2Fensure-buildbox-alive buut if Buidlbox doesn't handle -15, I would need to update, should I update or should we push the issue to buildbox-casd? | 16:38 |
| juergbi | benschubert: would probably good to handle it in casd | 16:45 |
| juergbi | will anyway need a buildbox update relatively soon for !1601, could do this at the same time | 16:46 |
| gitlab-br-bot | MR !1601: WIP: Do not directly communicate with CAS server https://gitlab.com/BuildStream/buildstream/merge_requests/1601 | 16:46 |
| benschubert | Oh nice, ping me when it is ready to be reviewds :) | 16:46 |
| benschubert | should I open my PR like that then? | 16:46 |
| juergbi | sure, sounds good | 16:48 |
| *** narispo has quit IRC | 16:49 | |
| *** narispo has joined #buildstream | 16:51 | |
| gitlab-br-bot | BenjaminSchubert opened MR !1605 (bschubert/ensure-buildbox-alive->master: Report when Buildbox-casd is not alive at the end of a run) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1605 | 16:54 |
| gitlab-br-bot | marge-bot123 merged MR !1590 (jennis/update_source_checkout->master: Ensure `source checkout` is symmetric to `artifact checkout`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1590 | 17:34 |
| *** phil has quit IRC | 17:48 | |
| *** traveltissues has quit IRC | 18:20 | |
| gitlab-br-bot | marge-bot123 merged MR !1602 (chandan/fix-news->master: NEWS: Use past-tense, fix note about YAML cache) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1602 | 18:32 |
| *** slaf has quit IRC | 18:57 | |
| *** slaf has joined #buildstream | 19:01 | |
| *** slaf has joined #buildstream | 19:01 | |
| *** slaf has joined #buildstream | 19:01 | |
| *** cs-shadow has quit IRC | 21:08 | |
| *** rdale has quit IRC | 21:30 | |
| *** wberrier has joined #buildstream | 23:38 | |
| wberrier | I'm looking into using buildstream to cross compile some stuff, and found: | 23:46 |
| wberrier | https://wiki.gnome.org/Projects/BuildStream/Roadmaps/Initial2017/CrossBuilding | 23:46 |
| wberrier | in general, is buildstream not recommended for cross compiling environments? | 23:46 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!