**** BEGIN LOGGING AT Mon Aug 03 02:59:58 2015 Aug 03 09:02:08 moin Aug 03 09:04:50 nano changed license to GPLv3 7 years ago (http://svn.savannah.gnu.org/viewvc/trunk/nano/COPYING?revision=4147&root=nano&view=markup), but meta-oe still stats GPLv2 Aug 03 14:57:43 fsdun: ouch, that sort of thing is what LIC_FILES_CHKSUM is supposed to catch Aug 03 14:57:48 * kergoth yawns Aug 03 15:02:00 kergoth, I think it was already wrong when Martin imported the recipes from the SHR repository Aug 03 15:02:27 * fsdun should check if he still has the old repositories on a disk Aug 03 15:05:03 is it reasonable to implement a check License <-> LIC_FILES_CHKSUM ? Aug 03 15:05:47 i don't understand the question. Aug 03 15:06:30 if you grep for the license checksum of the nano package it only yields GPLv3 packages Aug 03 15:08:04 that just indicates that when LIC_FILES_CHKSUM was added to the recipe, the person adding it didn't check the license files to make sure LICENSE was accurate. not ideal, but just user error Aug 03 15:08:25 * kergoth yawns Aug 03 15:08:49 the license information is up to recipe author to get right.. we're not lawyers and we shouldn't be expected to be.. so it's a bug if you find it's wrong.. propose a fix and it will likely be accepted Aug 03 15:09:30 indeed Aug 03 15:10:20 (this is why all of the OE/YP folks always say that if you are building a commercial product it's up to you to review the licenses with your lawyers.. only they can tell you what your obligations are.. the work we do is simply to assist in prepping any discussion w/ legal..) Aug 03 15:10:46 so it's a bug, one I'd personally consider severe/high priority if the license info is wrong, but it's a bug Aug 03 15:11:05 yeah, lots of companies end up using something like blackduck or manual review, file-by-file, since they can't assume the declared metadata is 100% accurate, something tiny could be floating aorund that was missed Aug 03 15:11:13 not fun stuff Aug 03 15:11:14 but same checksums indicate that the license should be the same. If not you should recheck your license Aug 03 15:11:27 the checksums are -rarely- the same between recipes.. Aug 03 15:11:28 again, the point of checksumming is to catch license changes Aug 03 15:11:35 but if the original checksum was wrong, it's not very useful Aug 03 15:11:39 yeah. we're using blackduck Aug 03 15:11:42 yeah, we checksum not just license files, but headers, etc Aug 03 15:11:54 all of the files get generated slightly differently.. but the check is that the checksum listed is the one that is listed.. but that doesn't verify reading contents Aug 03 15:12:49 yeah, license checksumming doesn't validate that its license is what we think it is, that can't be done easily without manual review or something like blackduck, its purpose is simply to ensure that when it changes, we notice Aug 03 15:13:14 and thats dependent on the person adding the checksum in the first place having checked things out and included the necessary files in it Aug 03 15:13:38 but if you have matching checksum there shoulb be a intersection of licenses within the packages Aug 03 15:14:15 nope. often there's no license file, full license text in the headers, or different copyright strings, etc. it's not going to match byte for byte in a lot of cases Aug 03 15:14:21 not vice versa because you could check the checksum of a file which has a different formating Aug 03 15:14:55 but again, that's not its purpose at this time. if you want to try to improve it to do more validation, you're welcome to attempt it Aug 03 15:15:04 exactly. you cannot macht GPLv3 to f27defe1e96c2e1ecd4e0c9be8967949, but f27defe1e96c2e1ecd4e0c9be8967949 to GPLv3 Aug 03 15:16:37 there it is, i added the first nano recipe for 1.2.1 in 2003. huh. i thought it was earlier than that, given we often used it in our getting started guides. though that could have been before the getting started guide took its later form.. Aug 03 15:16:39 huh Aug 03 15:17:43 weird, why did i use := for SRC_URI and S in the first recipe? that was silly. maybe we didn't have good enough expansion caching back then Aug 03 15:17:56 looks like it was before the sane default for S, and before shlibs Aug 03 15:17:58 hehe Aug 03 15:18:50 the only 'md5sums' we could match to are: Aug 03 15:18:50 oe-core/meta/files/common-licenses Aug 03 15:21:32 BTW I just did a comparison (oe-core only) of what is in the recipes in 'meta' compared to the contents of the license folder.. the only mathcing checksums I got were: Aug 03 15:21:37 ad1419ecc56e060eccf8184a87c4285f GFDL-1.1 Aug 03 15:21:37 801f80980d171dd6425610833a22dbe6 GPL-2.0 Aug 03 15:21:37 0835ade698e0bcf8506ecda2f7b4f302 MIT Aug 03 15:21:37 058f6229798281bbcac4239c788cfa38 tcl Aug 03 15:21:37 9475885294e17c0cc0067820d042792e unfs3 Aug 03 15:21:38 a6eeeed43d498c22a835382533356462 XSL Aug 03 15:21:50 heh Aug 03 15:22:02 every other 'standard license' has some kind of deviation in it causing different checksums to be generated.. tabs, spaces, extra new lines, etc.. Aug 03 15:22:40 (I'm actually surprised we match 6 of them.. I was expecting one or two) Aug 03 15:23:33 I think the best we could do is take the license checksums between recipes, and the declared LICENSE filed in the recipes.. if the checksum matches, the declared license should match.. Aug 03 15:24:40 yes. Aug 03 15:25:29 even then we can't check for an exact match, only an intersection Aug 03 15:25:33 if md5 doesn't produce any collisions Aug 03 15:25:38 or inclusion of that license somewhere in the license values Aug 03 15:25:49 since recipes often are affected by multiple licenses Aug 03 15:26:23 but if we build an intersection of all licenses and get an empty list something might be wrong Aug 03 15:26:31 kergoth, ya.. and thats the reason I don't believe anyone has implemented that before Aug 03 15:27:16 in oe-core/meta I found (via a simple grep) 741 entries.. of those, 425 are unique Aug 03 15:36:54 (ohh and of the recipes w/ duplicable md5sums.. there are 55 unique checksums..) Aug 03 15:37:55 kergoth, btw. this is bug #8090 if you read it in #oe logs Aug 03 15:38:26 k Aug 03 15:46:53 stupid question (of which google isn't much help): does anyone have any recommendations (other than "don't") on how to set up custom OE layers in perforce? I don't want to use the perforce fetcher, I want to store my layers in perforce. If someone's already done this and can provide tips, I'd greatly appreciate it Aug 03 15:48:08 doesn't seem like bitbake/oe would care where you happen to store your layers, you're responsible for checking them out before the build anyway Aug 03 15:49:44 kergoth, true, probably I'm confusing the setup of layers with managing metadata about how to fetch layers... Aug 03 15:51:56 hmm. you might be the first perforce user outside of Harman I ever met :P Aug 03 15:52:01 or maybe my thinking is being muddied by trying to set something up which is easy to work with and develop in along with making "release" builds... Aug 03 15:52:11 fsdun, I am not a perforce user by choice :) Aug 03 15:54:11 the typical usage for layer storage seems to be as a git repo, which I grok and understand and have some scripts for setting up layers and oe directories and configuration files and doing builds, but perforce makes that much more annoying and difficult and so I thought maybe someone else has gone through similar pain and wrote something down Aug 03 15:55:13 i've known quite a few folks using perforce, and others using clearcase, though ithink most of the perforce use git-p4 and whatnot Aug 03 15:55:40 its possible, but even with git there's no standard for multiple repository management and layer fetching, lots of folks use whatever works for them. i imagine that's the case for perforce as well Aug 03 15:56:09 presumably git-p4 might be an option for you too, though your management might not agree Aug 03 15:56:10 :) Aug 03 15:56:58 i heard of a p4 sync manager, but never used it Aug 03 16:00:17 kergoth, I'm using git-p4 personally, I guess I shall broach the topic with mgmt :) Aug 03 16:00:25 fsdun, I'll look into that, thanks! Aug 03 18:32:48 is there a way I can save data from a build to drive toaster for demos? **** ENDING LOGGING AT Tue Aug 04 02:59:58 2015