| *** lachlanmackenzie has quit IRC | 03:47 | |
| *** lachlanmackenzie has joined #baserock | 04:02 | |
| *** gtristan has quit IRC | 04:59 | |
| *** gtristan has joined #baserock | 05:33 | |
| paulsherwood | malinus: hello | 05:48 |
|---|---|---|
| *** franred has joined #baserock | 06:29 | |
| *** franred has quit IRC | 06:43 | |
| *** fay has joined #baserock | 07:04 | |
| *** fay is now known as faybrocklebank | 07:04 | |
| *** franred has joined #baserock | 07:05 | |
| *** franred has quit IRC | 07:21 | |
| *** toscalix has joined #baserock | 07:25 | |
| *** ctbruce has joined #baserock | 07:26 | |
| *** CTtpollard has quit IRC | 07:43 | |
| *** CTtpollard has joined #baserock | 07:45 | |
| *** christopherphang has joined #baserock | 08:07 | |
| *** cphang has quit IRC | 08:07 | |
| *** christopherphang is now known as cphang | 08:08 | |
| *** paulwaters_ has joined #baserock | 08:18 | |
| *** franred has joined #baserock | 08:50 | |
| *** tiagogomes has joined #baserock | 09:20 | |
| cphang | Hi! I've had a first pass at one of the issues on ybd (#237 https://gitlab.com/baserock/ybd/issues/237). If anyone could have a look at it, that'd be great thanks! | 09:32 |
| cphang | http://paste.baserock.org/ukiquvipoz | 09:32 |
| paulsherwood | cphang: any reason why you prefer paste over submitting a pull request? | 09:34 |
| cphang | paulsherwood, apologies, I wasn't sure if I'm awaiting an access request whether I could do a PR? | 09:36 |
| paulsherwood | cphang: no need to apologise :) i think the default way is to create your own fork in gitlab, and then trigger the pr from there (but i just remembered it's acalled a Merge Request in gitlab :-)) | 09:37 |
| cphang | Ahh okay! I'll do that thanks :) | 09:39 |
| gtristan | Is 'description' a valid field for chunks and just vastly unused ? Or is it only valid for strata ? | 09:40 |
| paulsherwood | gtristan: i think it's valid | 09:41 |
| paulsherwood | http://git.baserock.org/cgit/baserock/baserock/spec.git/tree/schemas/chunk.json-schema | 09:41 |
| paulsherwood | the canonical definition of current format is at https://docs.baserock.org/spec/ iirc | 09:42 |
| pedroalvarez | for anything, I'd say | 09:42 |
| gtristan | ok got it... | 09:43 |
| gtristan | Any thoughts on adding a 'license' field for chunks ? (maybe was discussed before ? maybe a huge pain in the ass since it's damn hard to enforce correctness there ?) | 09:44 |
| franred | gtristan, what do you want to put in license? | 09:44 |
| gtristan | franred, a keyword, not a huge text, like: MIT | GPLv2 | GPLv3 | MPL | Custom | 09:45 |
| franred | gtristan, that should be something that should be generated afterwards -- given that same source could build different libraries/binaries with different licenses | 09:46 |
| paulsherwood | -1 | 09:46 |
| gtristan | it's something yocto does have, not sure what things they are doing with it, for my own selfish purposes; it would simply be to encode the required field into generated rpms | 09:46 |
| franred | where source for us is chunk | 09:46 |
| cphang | paulsherwood, the merge request should be there now | 09:46 |
| franred | paulsherwood, is that -1 for me or for gtristan ? | 09:46 |
| paulsherwood | cphang: i'll review soon | 09:47 |
| paulsherwood | franred: you, i'm afraid :) let me try to explain... | 09:47 |
| franred | paulsherwood, we are facing that problem in a project at the moment ;-) -- using debian packages. Im afraid here Im right | 09:47 |
| gtristan | franred, in fact from what you are saying, a chunk is a decent place to encode it; since the chunk also defines *how* that source code will be built (hence under what license) | 09:47 |
| franred | licenses | 09:48 |
| pedroalvarez | scary topic this one | 09:48 |
| * paulsherwood doesn't think so, but thinks it's confusing for people | 09:48 | |
| franred | gtristan, ok, then we will need to get the build tool to check that what you are producing is the license you claim you are producing | 09:48 |
| gtristan | franred, I think yocto attempted some automation of enforcement on this front, but it's not an exact science unfortunately :-S | 09:49 |
| CTtpollard | yocto's model is flawed as hell | 09:49 |
| CTtpollard | well, without spdx/fossology support working | 09:49 |
| rjek | Beware upcoming pedanticity: Licence is the noun, license is the verb. Excactly same rule as advice/advise and device/devise. | 09:49 |
| franred | rjek, cheers | 09:50 |
| paulsherwood | to be clear, bitbake/yocto recipes have metadata which is created manually by people, having (presumably) assessed what licencing actually applies in the source | 09:50 |
| franred | gtristan, we are looking at this at the moment and it is very tricky even when you are shipping debian package which it suppose you know what are in they | 09:51 |
| rjek | paulsherwood: How often do they get it wrong? :) | 09:51 |
| paulsherwood | if their assessment is wrong, or the licencing changes without people updating the metadata in the recipes, then the licence metatata is wrong | 09:51 |
| paulsherwood | rjek: i don't know if there is any data on that | 09:51 |
| rjek | Debian have astonishingly strong rules about this and tooling to scan every source file and guess licence; a project may be GPL but it may include MIT-licenced stuff left right and centre | 09:52 |
| rjek | I suppose it gets even trickier if you want to list copyright holders (Debian do) | 09:52 |
| paulsherwood | downstream users of recipes may or may not check the validity of the metadata | 09:52 |
| franred | yes, or multiple licences, depending on the library/plugins you are using. And parsing the source for finding the licences are not easy as you might think | 09:52 |
| paulsherwood | in any case, whatever the metadata says, the actual licence situation should be checked based on the actual licence(s) present or claimed in the code. and even that may be wrong (by mistake or tampering) | 09:53 |
| paulsherwood | franred: i implemented http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/scripts/licensecheck.py which calls a parser script that was written by debian folks | 09:54 |
| gtristan | franred, I think when it comes to 'deployment', even if the upstream source has included multiple licensing options; you usually settle on a single one right ? | 09:55 |
| paulsherwood | but it remains, adding a licence field is just an opportunity to have metadata which may be wrong, but accidentally believed by users. | 09:55 |
| gtristan | or perhaps you can also distribute upstream code with multiple license options | 09:56 |
| paulsherwood | franred: have you been running the debian script (http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/scripts/licensecheck.pl or equivalent) | 09:57 |
| franred | gtristan, no, really. There are libraries in Qt for example which are lgplv3 while the core is gpl - a costumer could claim that you are using lgplv3 when your chunk (qt) for you is gpl | 09:57 |
| franred | paulsherwood, thanks, I will see if that can solve any problems in our project and see how behaves for us | 09:57 |
| gtristan | franred, ah I see what you mean, in which case the licence needs to be something at the artifact splitting level | 09:58 |
| gtristan | rjek, did I get that pedantically correct ? | 09:58 |
| gtristan | heh | 09:58 |
| rjek | gtristan: "artefact" :D | 09:59 |
| franred | gtristan, agree :) | 09:59 |
| gtristan | crap ! | 09:59 |
| franred | paulsherwood, I've checked with nowster - that script checks source code licence, which means that you are getting all the possible licences that code can produce. So you still need to know if that code is used or not to build/create your library or binary. | 10:08 |
| franred | as pedroalvarez said, it is tricky and scary :) | 10:09 |
| gtristan | I'm sure that some text in a comment saying "It is not acceptable to distribute this software under the MIT license because..." would also produce false positives | 10:12 |
| gtristan | in the end, this kind of thing will probably always require some measure of human responsibility, so I guess the question which remains, if we were to integrate such metadata; we would need to be careful about where accountability for that lies | 10:14 |
| gtristan | it could be a supported feature for which we do not include such metadata in gbo definitions repositoy(ies), or gbo could grow a definitions repo/branch with much more strict guidelines | 10:17 |
| jmacs | Also, bear in mind that your licence information could be invalidated by each commit to the source repository | 10:20 |
| gtristan | exactly, but as we track specific commits to build, it means that accepting an upgrade (change of ref: field) requires such re-verification | 10:20 |
| gtristan | (if we do maintain a branch for which we advertise correctness of such licence metadata) | 10:21 |
| gtristan | or well, even providing such metadata is a risk of advertising it's correctness | 10:21 |
| * jmacs wonders how many people have proposed a standard for embedding licence metadata into code | 10:21 | |
| gtristan | that would be interesting indeed, to track that at the binary level in some way even | 10:22 |
| paulsherwood | franred: in any case, i believe all of the above supports my view that having a licence: field is a bad idea | 10:34 |
| *** paulwaters_ has joined #baserock | 10:35 | |
| pedroalvarez | I thought you were saying it was a good idea, and fran that it wasn't | 10:38 |
| * SotK thought that that was franred's view too, and is confused | 10:39 | |
| paulsherwood | oops... my apologies. | 10:39 |
| paulsherwood | i confused gtristan and franred | 10:40 |
| paulsherwood | and everyone | 10:40 |
| pedroalvarez | no worries, good to see that almost everyone here agrees with that | 10:40 |
| paulsherwood | sorry. i disagree with *gtristans* suggestion, and agree with franred, so my -1 was for gtristan, not franred. | 10:41 |
| * paulsherwood should give up, for today ;) | 10:41 | |
| franred | :) | 10:46 |
| gtristan | heh | 10:59 |
| * gtristan is starving by now -> back in an hour... | 10:59 | |
| *** gtristan has quit IRC | 11:04 | |
| paulsherwood | https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet ? | 11:09 |
| *** gtristan has joined #baserock | 11:47 | |
| gtristan | Ok so we've established that generally people think it's a bad idea to support licence tagging in definitions format | 11:52 |
| gtristan | But we probably acknowledge that it's a requirement for some users (or we have some other scheme in mind about how licence tagging is supposed to make it into packages, for people who do build rpm/debian packages from ybd generated artifacts ?) | 11:53 |
| gtristan | So what about user defined extensible metadata in definitions ? | 11:53 |
| gtristan | What is our position for: User has a specific use case for storing specific metadata in *thier* definitions, and is allowed to extend the tooling through some extension points which will make use of the data they define ? | 11:54 |
| * paulsherwood will have to think | 11:58 | |
| * locallycompact adds "and still validate" | 11:59 | |
| jmacs | I see we explicitly disallow additional properties at most points in our schema | 12:01 |
| locallycompact | the caveat I've introduced in V10 is that the schema isn't expected to validate files directly | 12:03 |
| locallycompact | since doing so doesn't say anything about the resulting type, due to the morph: field could pull in any number of fields | 12:03 |
| locallycompact | so it validates after morph: fields have been evaluated and popped out | 12:04 |
| locallycompact | so there's room for some (simple) logic there | 12:04 |
| * gtristan envisions some kind of future where plugins can be added to the tooling, by A.) scoping out some semantic specific for plugins to extend definitions, say a 'user-data-${plugin-name}' scope is allowed for any chunk/strata/system/cluster... B.) plugin can optionally provide a validation extension... C.) ybd is broken down into a set of reusable components, like defslib, allowing additional tooling to be easily written to operate on definitions | 12:08 | |
| gtristan | too fancy maybe ? | 12:08 |
| jmacs | What's the argument against just allowing arbitrary fields in definitions? | 12:10 |
| gtristan | jmacs, I think namespace is important, if I start using an arbitrary custom tag in my extension of ybd... and baserock evolves to use that same name (can be likely even), then I dont want things to break ? | 12:16 |
| paulsherwood | jmacs: only that users can easily mistype existing fields, and outlawing unknown ones makes it easy to spot that error | 12:16 |
| pedroalvarez | maybe it's possible to allow an "extra" field that has whatever you want, not validated | 12:18 |
| gtristan | pedroalvarez, that's sort of what I'm suggesting with "user-data", however "user-data-${plugin-name}" is more extensible | 12:19 |
| gtristan | so I can extend something that is already extended with something else, and not clash with existing integrated plugins | 12:19 |
| gtristan | something like defslib could provide convenience functions like: user_data = get_plugin_meta (chunk, 'plugin-name') | 12:21 |
| gtristan | of course, I'm not altogether sure just how many use cases there could be for such a thing, so it seems maybe too elaborate :) | 12:22 |
| jmacs | I like that approach | 12:24 |
| tiagogomes | I was about to point out that user-defined fields could be written with "X-" as a prefix, as it happens with custom email and http headers, but looks like that convention was deprecated. | 12:41 |
| gtristan | tiagogomes, and the convention with html/js plugins is to use "data-" prefixes for any html attributes one might use from a JS plugin... the idea being that the DOM wont grow "data-" prefixed attributes | 12:56 |
| gtristan | but that sux | 12:56 |
| gtristan | because it fails to recognize that competing plugins will stomp on eachothers namespaces | 12:56 |
| gtristan | (not that there is really anything sane about DOM/JS/CSS anyway but...) | 12:57 |
| *** anahuelamo__ has quit IRC | 14:47 | |
| *** anahuelamo__ has joined #baserock | 14:48 | |
| *** gtristan has quit IRC | 14:51 | |
| *** gtristan has joined #baserock | 15:17 | |
| *** franred has quit IRC | 16:07 | |
| *** ctbruce has quit IRC | 16:20 | |
| *** toscalix has quit IRC | 17:04 | |
| tiagogomes | Hey, who are the reviewers of sandboxlib ? | 17:19 |
| *** ctbruce has joined #baserock | 17:24 | |
| *** paulwaters_ has joined #baserock | 17:32 | |
| *** rdale has quit IRC | 19:30 | |
| *** rjek has quit IRC | 19:43 | |
| *** rjek has joined #baserock | 19:44 | |
| *** ctbruce has quit IRC | 20:17 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!