IRC logs for #baserock for Thursday, 2016-09-29

*** lachlanmackenzie has quit IRC03:47
*** lachlanmackenzie has joined #baserock04:02
*** gtristan has quit IRC04:59
*** gtristan has joined #baserock05:33
paulsherwoodmalinus: hello05:48
*** franred has joined #baserock06:29
*** franred has quit IRC06:43
*** fay has joined #baserock07:04
*** fay is now known as faybrocklebank07:04
*** franred has joined #baserock07:05
*** franred has quit IRC07:21
*** toscalix has joined #baserock07:25
*** ctbruce has joined #baserock07:26
*** CTtpollard has quit IRC07:43
*** CTtpollard has joined #baserock07:45
*** christopherphang has joined #baserock08:07
*** cphang has quit IRC08:07
*** christopherphang is now known as cphang08:08
*** paulwaters_ has joined #baserock08:18
*** franred has joined #baserock08:50
*** tiagogomes has joined #baserock09:20
cphangHi! 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
cphanghttp://paste.baserock.org/ukiquvipoz09:32
paulsherwoodcphang: any reason why you prefer paste over submitting a pull request?09:34
cphangpaulsherwood, apologies, I wasn't sure if I'm awaiting an access request whether I could do a PR?09:36
paulsherwoodcphang: 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
cphangAhh okay! I'll do that thanks :)09:39
gtristanIs 'description' a valid field for chunks and just vastly unused ? Or is it only valid for strata ?09:40
paulsherwoodgtristan: i think it's valid09:41
paulsherwoodhttp://git.baserock.org/cgit/baserock/baserock/spec.git/tree/schemas/chunk.json-schema09:41
paulsherwoodthe canonical definition of current format is at https://docs.baserock.org/spec/ iirc09:42
pedroalvarezfor anything, I'd say09:42
gtristanok got it...09:43
gtristanAny 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
franredgtristan, what do you want to put in license?09:44
gtristanfranred, a keyword, not a huge text, like: MIT | GPLv2 | GPLv3 | MPL | Custom09:45
franredgtristan, that should be something that should be generated afterwards -- given that same source could build different libraries/binaries with different licenses09:46
paulsherwood-109:46
gtristanit'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 rpms09:46
franredwhere source for us is chunk09:46
cphangpaulsherwood, the merge request should be there now09:46
franredpaulsherwood, is that -1 for me or for gtristan ?09:46
paulsherwoodcphang: i'll review soon09:47
paulsherwoodfranred: you, i'm afraid :) let me try to explain...09:47
franredpaulsherwood, we are facing that problem in a project at the moment ;-) -- using debian packages. Im afraid here Im right09:47
gtristanfranred, 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
franredlicenses09:48
pedroalvarezscary topic this one09:48
* paulsherwood doesn't think so, but thinks it's confusing for people09:48
franredgtristan, ok, then we will need to get the build tool to check that what you are producing is the license you claim you are producing09:48
gtristanfranred, I think yocto attempted some automation of enforcement on this front, but it's not an exact science unfortunately :-S09:49
CTtpollardyocto's model is flawed as hell09:49
CTtpollardwell, without spdx/fossology support working09:49
rjekBeware upcoming pedanticity: Licence is the noun, license is the verb.  Excactly same rule as advice/advise and device/devise.09:49
franredrjek, cheers09:50
paulsherwoodto be clear, bitbake/yocto recipes have metadata which is created manually by people, having (presumably) assessed what licencing actually applies in the source09:50
franredgtristan, 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 they09:51
rjekpaulsherwood: How often do they get it wrong? :)09:51
paulsherwoodif their assessment is wrong, or the licencing changes without people updating the metadata in the recipes, then the licence metatata is wrong09:51
paulsherwoodrjek: i don't know if there is any data on that09:51
rjekDebian 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 centre09:52
rjekI suppose it gets even trickier if you want to list copyright holders (Debian do)09:52
paulsherwooddownstream users of recipes may or may not check the validity of the metadata09:52
franredyes, 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 think09:52
paulsherwoodin 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
paulsherwoodfranred: 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 folks09:54
gtristanfranred, 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
paulsherwoodbut it remains, adding a licence field is just an opportunity to have metadata which may be wrong, but accidentally believed by users.09:55
gtristanor perhaps you can also distribute upstream code with multiple license options09:56
paulsherwoodfranred: have you been running the debian script (http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/scripts/licensecheck.pl or equivalent)09:57
franredgtristan, 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 gpl09:57
franredpaulsherwood, thanks, I will see if that can solve any problems in our project and see how behaves for us09:57
gtristanfranred, ah I see what you mean, in which case the licence needs to be something at the artifact splitting level09:58
gtristanrjek, did I get that pedantically correct ?09:58
gtristanheh09:58
rjekgtristan: "artefact" :D09:59
franredgtristan, agree :)09:59
gtristancrap !09:59
franredpaulsherwood, 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
franredas pedroalvarez said, it is tricky and scary :)10:09
gtristanI'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 positives10:12
gtristanin 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 lies10:14
gtristanit 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 guidelines10:17
jmacsAlso, bear in mind that your licence information could be invalidated by each commit to the source repository10:20
gtristanexactly, but as we track specific commits to build, it means that accepting an upgrade (change of ref: field) requires such re-verification10:20
gtristan(if we do maintain a branch for which we advertise correctness of such licence metadata)10:21
gtristanor well, even providing such metadata is a risk of advertising it's correctness10:21
* jmacs wonders how many people have proposed a standard for embedding licence metadata into code10:21
gtristanthat would be interesting indeed, to track that at the binary level in some way even10:22
paulsherwoodfranred: in any case, i believe all of the above supports my view that having a licence: field is a bad idea10:34
*** paulwaters_ has joined #baserock10:35
pedroalvarezI thought you were saying it was a good idea, and fran that it wasn't10:38
* SotK thought that that was franred's view too, and is confused10:39
paulsherwoodoops... my apologies.10:39
paulsherwoodi confused gtristan and franred10:40
paulsherwoodand everyone10:40
pedroalvarezno worries, good to see that almost everyone here agrees with that10:40
paulsherwoodsorry. 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
gtristanheh10:59
* gtristan is starving by now -> back in an hour...10:59
*** gtristan has quit IRC11:04
paulsherwoodhttps://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet  ?11:09
*** gtristan has joined #baserock11:47
gtristanOk so we've established that generally people think it's a bad idea to support licence tagging in definitions format11:52
gtristanBut 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
gtristanSo what about user defined extensible metadata in definitions ?11:53
gtristanWhat 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 think11:58
* locallycompact adds "and still validate"11:59
jmacsI see we explicitly disallow additional properties at most points in our schema12:01
locallycompactthe caveat I've introduced in V10 is that the schema isn't expected to validate files directly12:03
locallycompactsince doing so doesn't say anything about the resulting type, due to the morph: field could pull in any number of fields12:03
locallycompactso it validates after morph: fields have been evaluated and popped out12:04
locallycompactso there's room for some (simple) logic there12: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 definitions12:08
gtristantoo fancy maybe ?12:08
jmacsWhat's the argument against just allowing arbitrary fields in definitions?12:10
gtristanjmacs, 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
paulsherwoodjmacs: only that users can easily mistype existing fields, and outlawing unknown ones makes it easy to spot that error12:16
pedroalvarezmaybe it's possible to allow an "extra" field that has whatever you want, not validated12:18
gtristanpedroalvarez, that's sort of what I'm suggesting with "user-data", however "user-data-${plugin-name}" is more extensible12:19
gtristanso I can extend something that is already extended with something else, and not clash with existing integrated plugins12:19
gtristansomething like defslib could provide convenience functions like: user_data = get_plugin_meta (chunk, 'plugin-name')12:21
gtristanof 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
jmacsI like that approach12:24
tiagogomesI 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
gtristantiagogomes, 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 attributes12:56
gtristanbut that sux12:56
gtristanbecause it fails to recognize that competing plugins will stomp on eachothers namespaces12:56
gtristan(not that there is really anything sane about DOM/JS/CSS anyway but...)12:57
*** anahuelamo__ has quit IRC14:47
*** anahuelamo__ has joined #baserock14:48
*** gtristan has quit IRC14:51
*** gtristan has joined #baserock15:17
*** franred has quit IRC16:07
*** ctbruce has quit IRC16:20
*** toscalix has quit IRC17:04
tiagogomesHey, who are the reviewers of sandboxlib ?17:19
*** ctbruce has joined #baserock17:24
*** paulwaters_ has joined #baserock17:32
*** rdale has quit IRC19:30
*** rjek has quit IRC19:43
*** rjek has joined #baserock19:44
*** ctbruce has quit IRC20:17

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