| 00:07.26 | *** join/#oe yegorich1 (~yegorich@mail.visionsystems.de) |
| 00:47.33 | *** join/#oe LocutusOfBorg (~locutusof@ubuntu/member/locutusofborg) |
| 03:04.35 | *** join/#oe sakoman (~steve@72.173.249.164) |
| 03:52.16 | *** join/#oe mattsm (~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net) |
| 04:20.43 | *** join/#oe davidlt (~davidlt@78-63-27-146.static.zebra.lt) |
| 06:16.41 | *** join/#oe B0ned1ger (~B0ned1ger@82-135-139-249.static.zebra.lt) |
| 06:46.07 | *** join/#oe AndersD (~AndersD@h-98-128-162-82.NA.cust.bahnhof.se) |
| 07:00.08 | *** join/#oe AndersD (~AndersD@h-98-128-162-82.NA.cust.bahnhof.se) |
| 07:19.12 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 07:31.02 | *** join/#oe RobertBerger (~rber@ppp-2-86-140-5.home.otenet.gr) |
| 07:39.04 | *** join/#oe frsc (~frsc@214-161-142-46.pool.kielnet.net) |
| 07:39.15 | *** join/#oe mrnuke (~mrnuke@2601:2c1:8501:182d::c66) |
| 07:42.45 | *** join/#oe cpriouzeau (~cpriouzea@165.225.94.93) |
| 07:47.05 | *** join/#oe B0ned1ge_ (~B0ned1ger@82-135-139-249.static.zebra.lt) |
| 08:08.34 | *** join/#oe LetoThe2nd (uid453638@gateway/web/irccloud.com/x-jmjktunsylolundo) |
| 08:12.17 | *** join/#oe ao2 (~ao2@host-79-35-138-11.retail.telecomitalia.it) |
| 08:15.00 | *** join/#oe florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 08:27.43 | *** join/#oe frsc (~frsc@214-161-142-46.pool.kielnet.net) |
| 08:31.20 | *** join/#oe cpriouzeau (~cpriouzea@165.225.94.93) |
| 08:41.38 | *** join/#oe leon-anavi (~Leon@78.130.197.211) |
| 09:18.08 | *** join/#oe eFfeM (~fmeulenbr@a97014.upc-a.chello.nl) |
| 09:30.50 | *** join/#oe leon-anavi (~Leon@78.130.197.211) |
| 09:45.46 | paulbarker | dl9pf: Thanks, I'll take a look today |
| 09:59.20 | *** join/#oe leon-anavi (~Leon@78.130.197.211) |
| 10:14.49 | *** join/#oe AndersD (~AndersD@h-98-128-162-82.NA.cust.bahnhof.se) |
| 10:19.07 | dl9pf | tnx |
| 10:33.04 | *** join/#oe B0ned1ger (~B0ned1ger@78-60-213-230.static.zebra.lt) |
| 10:36.44 | *** join/#oe B0ned1ger2 (~B0ned1ger@82-135-139-249.static.zebra.lt) |
| 10:41.53 | *** join/#oe B0ned1ger (~B0ned1ger@78-60-213-230.static.zebra.lt) |
| 11:00.22 | *** join/#oe B0ned1ger (~B0ned1ger@82-135-139-249.static.zebra.lt) |
| 11:01.42 | *** join/#oe cpriouzeau (~cpriouzea@165.225.94.93) |
| 11:37.09 | *** join/#oe B0ned1ger2 (~B0ned1ger@78-60-213-230.static.zebra.lt) |
| 11:38.41 | *** join/#oe B0ned1ger2 (~B0ned1ger@82-135-139-249.static.zebra.lt) |
| 12:44.55 | *** join/#oe B0ned1ger (~B0ned1ger@82-135-139-249.static.zebra.lt) |
| 12:54.39 | *** join/#oe georgem_home (uid210681@gateway/web/irccloud.com/x-wntomidrmdymlbrs) |
| 13:11.28 | *** join/#oe eduardas (~eduardas@82-135-139-249.static.zebra.lt) |
| 13:41.34 | *** join/#oe sakoman (~steve@72.173.249.164) |
| 14:07.28 | *** join/#oe sakoman (~steve@72.173.249.164) |
| 14:38.21 | *** join/#oe B0ned1ger2 (~B0ned1ger@78-60-213-230.static.zebra.lt) |
| 14:45.05 | *** join/#oe B0ned1ger (~B0ned1ger@82-135-139-249.static.zebra.lt) |
| 15:14.40 | *** join/#oe sakoman (~steve@72.173.249.164) |
| 16:06.19 | *** join/#oe leon-anavi (~Leon@78.130.197.211) |
| 16:08.12 | *** join/#oe frsc (~frsc@214-161-142-46.pool.kielnet.net) |
| 16:34.06 | *** join/#oe vmeson (~rmacleod@198-48-226-187.cpe.pppoe.ca) |
| 17:43.33 | *** join/#oe stephano (~stephano@73.240.0.134) |
| 17:53.12 | *** join/#oe B0ned1ger (~B0ned1ger@82-135-139-249.static.zebra.lt) |
| 19:17.14 | *** join/#oe ao2 (~ao2@host-79-35-138-11.retail.telecomitalia.it) |
| 20:04.54 | *** join/#oe LetoThe2nd (uid453638@gateway/web/irccloud.com/x-wzbciqvqhvkknenl) |
| 20:10.26 | fray | I'm helping someone diagnose a checksum problem. When they run bitbake-diffsig they get a message that "basehash changed from X to Y". Not the normal hash of task foo, or variable .... In this context what is the 'basehash'? Is that the checksumming of the files themselves (patches, recipe file, etc?) |
| 20:10.42 | PaulePanter | Hi. Dellâs iDRAC seems to use a GNU/Linux OS built with OpenEmbedded. |
| 20:10.43 | PaulePanter | https://dpaste.org/xbRS |
| 20:10.52 | PaulePanter | Does somebody know, where the source code for that is? |
| 20:12.48 | fray | You'll have to ask Dell. They need to make, at least hte Open Source parts available per licenses.. In the past Dell had an Open Source site you could go to and download the corresponding source -- but I don't know where that is |
| 20:13.26 | PaulePanter | https://opensource.dell.com/releases/ |
| 20:13.40 | PaulePanter | Yes, but shouldnât they need to also provide the scripts to actually build this? |
| 20:13.58 | PaulePanter | https://opensource.dell.com/releases/idrac9/ |
| 20:13.59 | fray | "Maybe". Depends on the component and the license of that component. |
| 20:15.11 | PaulePanter | https://opensource.dell.com/releases/idrac9/4.40.15.00/ has a 3.4 GB iDRAC_4.40.15.00_OpenSource.tar.gz. |
| 20:15.28 | fray | (my interpretation based on what I've been told and read).. They need to provide build instructions in the customary format for GPL and LGPL, but nothing else. The customary format could be makefiles, log files, scripts or some combination of it |
| 20:17.15 | fray | Nothing I know of would require them to show you how to build an image and deploy it onto a device... (there may be instances where special keys or instructions are needed to comply with GPLv3.. but that doesn't mean they have to let you reconstruct the whole image.. |
| 20:20.12 | kergoth | yeah... i don't think they're legally obligated to provide that. some companies like to, but that's at their discretion.. |
| 20:21.09 | fray | (FYI if I was distributing, I would build the product with multiple layers.. Open Source and non.. that way I could release all of the Open Source layers, the associated sources and there would be no questions about the 'customary' build methods.. then the closed source would stay with it's own layer, and wouldn't eb released..) |
| 20:22.48 | fray | In the end though, the recourse -- if you don't beleive what they shipped is adequate, contact them (not threaten) and explain why and try to get it escalated to their legal department. If/when that gets shut down, you'll need to find a copyright holder for one of the components in question, then they would have to pursue it... It's not a short process, but with that said people do make changes based on reasoned arguments (both from the public, and from argum |
| 20:22.54 | fray | copyright claims) |
| 20:23.31 | fray | Goal for any source requests should be license compliance, not monetary payout.. (IMHO) |
| 20:24.19 | PaulePanter | Thank you for the clarification. |
| 20:24.20 | PaulePanter | <PROTECTED> |
| 20:24.24 | PaulePanter | https://www.gnu.org/licenses/old-licenses/gpl-2.0 |
| 20:25.16 | fray | That is GNUs argument, which not everyone agrees with. (GPLv3 is more clear on this BTW, where you DO need certain installation components) |
| 20:26.24 | fray | AFAIK though, it's never been tested in court if 'make install' vs actual scripting for file construction on the image is required.. |
| 20:26.48 | fray | You would probably find experts on both sides, and I don't know what a judge would rule in those cases.. (might even vary by where you are in teh world the outcome) |
| 20:27.03 | PaulePanter | Great, the download is happening with 1 MB/s, and now 500 KB/s. |
| 20:27.33 | fray | just an FYI, I've downloaded the 4.40.15 and I'm looking at it quickly.. their download side is really slow.. |
| 20:28.36 | fray | So it DOES look like they include not only the source but also the layers and information |
| 20:28.46 | fray | So from that perspective, they do include (IMHO) all of the installation components |
| 20:28.53 | fray | READMEmeta-cgl-2.6meta-qt5-2.6 |
| 20:28.53 | fray | REQ_PACKAGE_LISTmeta-commonmeta-selinux-2.6 |
| 20:28.53 | fray | buildmeta-dracpoky-2.6 |
| 20:28.53 | fray | build.shmeta-oe-2.6setup |
| 20:28.53 | fray | externalsrcmeta-qt4-2.6sources-2.6 |
| 20:29.18 | fray | README shows how to run their scripts and some basic environment stuff.. the meta-* layers contain the parts and pieces I would expect [from a quick look].. |
| 20:29.31 | fray | and sources contains teh full source for the items.. |
| 20:29.37 | fray | so everything seems to be in order |
| 20:30.43 | fray | and I see things in there that cover some of the proprietary (non-open source) bits as well, which they definitely were not required to release. So this seems like they went beyond what they had to. |
| 20:31.02 | fray | All in all the 4.40.15 tarball looks good to me on the surface and is 'better' then most I've looked at in the past |
| 20:31.05 | PaulePanter | fray: Thank you for checking, and kudos to Dell. |
| 20:31.43 | PaulePanter | Letâs hope, they open their Git repository for these layers, and start contributing to upstream. |
| 20:32.22 | fray | I doubt they will, at least for the drac stuff cause they make a lot of money on that.. but the contributing back changes and such -- definitly, it would help everyone |
| 20:33.38 | fray | (usually the thing holding back people like Dell, they're working on really old software, so it becomes increasingly difficult to send meaningful patches upstream.. For instance this is based on Yocto Project 2.6, and we're now almost to 3.3 |
| 20:34.17 | PaulePanter | ;-) |
| 20:36.16 | PaulePanter | 2021-02-04 21:36:10 (2.81 MB/s) - âiDRAC_4.40.15.00_OpenSource.tar.gzâ saved [3614488066/3614488066] |
| 20:37.06 | fray | I must be geographically closer.. 9.3 MB/s |
| 20:42.38 | LetoThe2nd | pokes fray. for no good reason, just saw you around. |
| 20:45.22 | PaulePanter | Dell is even a Silver Member of the Yocto Project: https://www.yoctoproject.org/ecosystem/members/ |
| 20:45.37 | fray | Hey! I might be able to actually stream.. Finally got a better internet connection at home |
| 20:45.56 | fray | No more 30/3 (when it wants to work) DSL.. FTTH 1000/1000 now.. |
| 20:46.14 | PaulePanter | fray: I am in Berlin using Vodafone Cable (100 MBit/s) (formerly Kabel Deutschland). |
| 20:47.15 | PaulePanter | But Vodafone seems to have problems with certain Autonomous Systems like the DFN, certain fastly.com servers and so on. |
| 20:51.13 | fray | Ya, last time I used Vodafone, I have a 3G card from Germany and I was in Italy at a clients.. was nice, but VERY expensive (pay as you go). But that's about as much experience I have with them. :) |
| 20:51.51 | fray | And yes, Dell is actually a founding member of the Yocto Project. |
| 20:54.07 | PaulePanter | Oh, sorry, I confused the window. I actually donwloaded the file from a server in the DFN X-WiN network (German research net). |
| 20:55.19 | PaulePanter | Itâs 107KB/s with Vodafone. Even slower. |
| 21:14.02 | marex | pokes fray. just checking on meta-xilinx-standalone, any news ? :-) |
| 21:46.29 | fray | marex see the meta-xilinx mailing list for current status. As for libxil, I checked we've never released a libxil that was buildable within the Yocto Project build environment. |
| 21:46.51 | fray | You CAN build libxil using a Yocto Project SDK from the embeddedsw code and XSA and related, but that is outside the YP build environment. |
| 21:47.15 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 21:47.27 | fray | I'm still trying them to get the new code released that will let us integrate a libxil build within the environment, but I still don't have a date when that code will be available... even then it'll likely still be not-production ready.. |
| 21:53.03 | *** join/#oe B0ned1ger (~B0ned1ger@82-135-139-249.static.zebra.lt) |
| 22:02.17 | *** join/#oe mauz555 (~mauz555@2a01:e0a:994:7ed0:b4ab:dbf0:3788:4ca9) |
| 22:06.49 | *** join/#oe leon-anavi (~Leon@78.130.197.211) |
| 22:11.18 | marex | fray: does that means if I include meta-xilinx-standalone in a build, $ bitbake hello-world will work ? |
| 22:11.21 | marex | or does this still fail ? |
| 22:12.12 | marex | oh, it still fails, I see |
| 22:12.26 | marex | fray: well, xilinx did release the OE recipes, just not the matching sources :) |
| 22:22.19 | marex | fray: the thing is, I want to bitbake stuff with multiconfig and have it emit all system components, the ones for CA53, CR5 and others ... |
| 22:22.52 | marex | fray: it's impractical to have to bitbake part 1, then go deal with SDK and whatever somewhere outside of the build, then implant built blobs into the build, and then bitbake part 2 :( |
| 22:23.16 | marex | fray: esp. when the recipes are all there, its just the Makefiles which apparently exist somewhere in Xilinx, just nobody pushed them to git yet |
| 22:24.19 | marex | fray: I would even (with great difficulty) understand it might take years to release sources, but the sources are already released, it is just the Makefiles which are missing |
| 22:25.23 | marex | fray: and since the meta-xilinx-standalone gets updated with each release, I presume the Makefiles are not lost, but they are somewhere easily available too |