**** BEGIN LOGGING AT Mon Nov 18 02:59:57 2019 Nov 18 07:02:45 New news from stackoverflow: Flashing custom Yocto image to Jetson Nano production module eMMC? Nov 18 07:50:56 good morning Nov 18 07:51:09 good morning to you Nov 18 08:14:30 * alessioigor waves all Nov 18 08:14:33 Is there a way to have two images of the same MACHINE using a different WKS_FILE file reducing at minimum the additional build requirements? If I make two different MACHINE files (of the same physical machine) Bitbake builds the same identical kernel two times! Nov 18 08:27:58 alessioigor: You can override WKS_FILE in an image recipe Nov 18 08:28:00 alessioigor: I'm not entirely sure but can't this variable be part of the image recipe? It looks like the default is in image_types_wic which is included in image.bbclass (via IMGCLASSES) Nov 18 11:06:44 rburton, I think sato has been py2-free for a while now, the only thing that still needs py2 is u-boot and py2 itself, or did you make additional patches? Nov 18 11:19:37 Hi, I have a short question regarding licenses: Is there a difference between "GPL-2+" "GPL-2.0" "GPLv2" and "GPLv2+". Nov 18 11:20:00 These strings are all found in my license.manifest-file Nov 18 11:21:47 If I look on gnu.org/licenses, there only listed gpl1/2/3 nothing with + Nov 18 11:37:06 + means 'or later' Nov 18 11:39:50 ThomasD13: You can look at https://spdx.org/licenses/ for the full list of identifiers. The ones with '+' are in the deprecated list at the bottom Nov 18 11:40:48 kanavin: literally ripped out the recipe to verify :) Nov 18 11:41:02 i thoguht uboot was fixed Nov 18 11:41:18 ah, no Nov 18 11:41:21 nuts Nov 18 11:41:30 why did that not pop up in my grep Nov 18 11:46:29 Marex: is there a good reason why u-boot needs py2, or should we be able to switch to py3 with no changes Nov 18 11:49:57 rburton: u-boot/master should support python3 already Nov 18 11:50:02 rburton: or the conversion is mostly done Nov 18 11:50:10 i'll swap and see what happens :) Nov 18 11:50:10 Tartarus: ^ Nov 18 11:50:29 rburton: would be great if AUH could upgrade U-Boot automatically :) Nov 18 11:50:42 the recipe hardcodes PYTHON to the py2 we build Nov 18 11:51:03 can't remember why it fails. is it because there's multiple recipes that need to update in lockstep? Nov 18 11:52:52 rburton: yep Nov 18 11:53:05 rburton: I wonder if that could be somehow fixed Nov 18 11:53:25 auh could be taught that some recipes need to be bundled Nov 18 12:03:34 New news from stackoverflow: Yocto SYSTEMD_SERVICE to install a parameterized service ("@.service") Nov 18 12:06:20 rburton: oooh, how ? :) Nov 18 12:12:23 kanavin, do you mean a piece of software can be licensed under GPLv2 OR GPLv3 ?? Nov 18 12:19:20 I want to find from which recipe the files in /etc/init.d/ come from,how do I search that? Nov 18 12:21:29 if you don't have INHERIT += "rm_work" in your conf/local.conf, a `find -name ` in BUILDDIR (tmp/work) should give you what you want Nov 18 12:30:18 ok,that gives me a path to core-ima-minimal, I search for the recipe where the files are added to the image Nov 18 12:31:11 kayterina: you should have that same file in some workdir of some package, e.g. WORKDIR/package-split or /packages or /image Nov 18 12:31:39 if not... check you actually have those repositories in any package (if not, you have rm_work inherited somewhere) Nov 18 12:32:06 if you can't find it anyway, that might be added in the image recipe directly? look for classes inherited by your image recipe? Nov 18 12:32:34 brainstorming with you, not 100% sure what I'm saying is correct Nov 18 12:33:39 or git grep for the filename in the metalayers directly , might also give some hints :) Nov 18 12:34:00 metalayers? Nov 18 12:34:40 kayterina: poky/ or meta-*/ , the list of those which are applied is in conf/bblayers.conf Nov 18 12:35:01 a,yes,ok. Nov 18 12:35:44 now I'm thinking, since I want to remove them, I can do that in a higher layer without ever knowing how they get into the image? Nov 18 12:35:46 Marex: that works if it's explicit in the recipe, sometimes it's part of make/cmake/autotools install step Nov 18 12:35:58 qschulz: indeed Nov 18 12:36:41 kayterina: you should do it in the matching package .bbappend Nov 18 12:37:44 kayterina: as Marex said, you should modify the original recipe. You usually don't want an image to change the "behavior" of a package by removing one of its files IMO Nov 18 12:38:55 wait, I found it. it was from poky/meta/-rcore/initscripts Nov 18 12:39:05 I think. Nov 18 12:39:07 thanks Nov 18 12:49:23 ThomasD13, yes, exactly Nov 18 12:49:33 you can choose Nov 18 13:10:43 is Paul Eggleton on IRC by any chance? Nov 18 13:12:38 How can I get the local-archive smaller? It is 3 Megabytes bytes on target /usr/lib/locale/locale-archive. Nov 18 13:13:19 I tried GLIBC_GENERATE_LOCALES = "en_US.UTF-8", IMAGE_LINGUAS = "en-us", ENABLE_BINARY_LOCALE_GENERATION = "1", GLIBC_SPLIT_LC_PACKAGES = "1" Nov 18 13:40:47 so...I want to remove a list of "install -m 0644 ${WORKDIR}/functions ${D}${sysconfdir}/init.d". I can't just put them inside a do_install_remove = "..." in my .bbappend? Nov 18 13:42:53 kayterina: do_install_append you mean I think, otherwise yes, from there rm ${D}${sysconfdir}/init.d/foo should be good and not too ugly Nov 18 13:43:15 kayterina: or a do_install_prepend and you remove it from ${B} both are more or less identical Nov 18 13:47:09 qschulz: look for bluelightning Nov 18 13:50:42 is there an emacs recipe? Nov 18 13:51:37 a recent one? Nov 18 13:51:51 this one is 13 years old: https://github.com/openembedded/openembedded/tree/master/recipes/emacs Nov 18 13:54:01 nm Nov 18 13:54:49 hmm. i thought i had a good one, but now i see this was blacklisted: https://layers.openembedded.org/layerindex/recipe/54286/ Nov 18 13:58:33 kayterina: if you've built it already, oe-pkgdata-util find-path /etc/init.d/somefile Nov 18 14:06:19 Hi, how to solve file name conflicts in bitbake fetcher and download cache? have multiple recipes which include test data in data.tar which results in conflicts depending on build and download order in download cache. Could bitbake fetcher add checksums or similar to all file names? Nov 18 14:11:37 mcfrisk: https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#http-ftp-fetcher Nov 18 14:12:16 rburton: 1.6? :) Nov 18 14:12:23 ha, sorry, blame google :) Nov 18 14:12:37 hello there. I have a terribly structured recursive Makefile utilizing wireless driver and trying to build it with module.bbclass. After `extend_recipe_sysroot` succeeds, `do_install` fails with `make: *** No rule to make target 'modules_install'. Stop.`. any ideas? Nov 18 14:12:38 https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#http-ftp-fetcher Nov 18 14:13:09 cengiz_io: your makefile doesn't have a modules_install rule? Nov 18 14:13:13 mcfrisk: I've toyed with the idea of putting files in a domain named subdir but its hard with mirroring, hard to find an ideal solution Nov 18 14:14:02 rburton there are tens of Makefiles actually... with suffixes like Makefile.6 Makefile.7 Makefile.8-threads etc. Nov 18 14:14:13 I know that Makefile.6 is being used mostly. Nov 18 14:14:17 The package bluez5 has following license information in my license.manifest file: LICENSE: GPLv2+ & LGPLv2.1+ Nov 18 14:14:35 Does it mean this package contains code which is licensed under both licenses? Nov 18 14:14:57 And what is the difference to "|" ? Nov 18 14:15:18 For example dbus: "LICENSE: AFL-2.1 | GPLv2+" Nov 18 14:16:19 | - or.. & and Nov 18 14:16:19 rburton and that Makefile.6 only has `install` target. I think I'll need to create a `modules_install` target right? Nov 18 14:16:39 it is still your responsibility to read the license and make your own determination Nov 18 14:16:57 fray: Does it mean i can chose for dbus if I distribute it under AFL-2.1 or GPLv2+ ?? Nov 18 14:17:07 cengiz_io: yes. module.bbclass expects a fairly standard build tree. Nov 18 14:17:15 you will have to read the license, but generally that is the indication Nov 18 14:17:23 and I'm fully supporting that.. Nov 18 14:17:34 cengiz_io: looks like you can set MODULES_INSTALL_TARGET='install' in your recipe Nov 18 14:17:36 but mediatek didn't care. Nov 18 14:17:36 if you read the class Nov 18 14:18:06 rburton ah yes! that's the final part of do_install.. let me try that Nov 18 14:18:30 okay, thank you fray. Thats still confusing to me ;) Nov 18 14:18:50 read the text of the license, it is the only way to understand this stuff.. Nov 18 14:19:08 and if you don't understand that, you will need to find a lawyer to read it and explain it to you Nov 18 14:20:44 The point that I can chose which license I will use confuses me. As far as I understand is that combined work which consists of GPLv2 code, only can be relicensed with GPLv2/v3 or Affero Nov 18 14:21:20 the license from the original author, and subsequent contributors is what makes up the software. Nov 18 14:21:49 rburton thanks. it worked. to some degree.. now I need to fix their hardcoded install target paths inside their Makefile. Nov 18 14:21:55 if the original author says "Buy me a beer and you can use it commercially, or you have to release all of your code into the public domain" then they've licensed it with a dual license.. Nov 18 14:22:02 * cengiz_io wants to cut himself Nov 18 14:22:05 as long as all contributors to the code agree, it remains dual licensed. Nov 18 14:22:12 cengiz_io: hooray vendor modules Nov 18 14:22:25 if you combine that with other code.. and the other code has something in it that prevents the first license, then the second is what you would need.. Nov 18 14:22:59 licensing is complicated.. the best we can do is provide a quick reference, but only you can read the license and consult a lawyer for the proper interpretation of an individual license, as well as the licenses for any system you create.. Nov 18 14:23:18 ahhh okay. so "|" indicates dual licensing. Now I understood, perfect thank you! Nov 18 14:23:28 *multiple* Nov 18 14:24:15 term 'dual license' is confusing on it's own.. sometimes it's an '&', and sometimes it's an '|'.. thus the indicication in the field Nov 18 14:26:48 when i get this message from bitbake, https://paste.centos.org/view/8758b4f8, does it mean that there are no recipes for those components? Nov 18 14:26:54 RP: what is a domain name in this context, layer name? I would just add the expected checksum to the file name. at least with checksumming in place my problem was detected and builds failed.. Nov 18 14:27:53 this appears to be coming from a specific configure call.. which means that some particular program is trying to find something that either doesn't exist or it doesn't know how to get to Nov 18 14:29:07 mcfrisk: I was thinking of the actual domain from the URL but it doesn't help Nov 18 14:31:22 fray: are you talking to me? if so, then yes, that was apparent to me, but i still have the question Nov 18 14:31:52 RP: ah, ok, like git fetcher does with the directory path Nov 18 14:31:53 there is a severe lack of context in your pastebin Nov 18 14:32:20 it is what hapepened when i "bitbake emacs" (after unblacklisting it). Nov 18 14:32:35 mcfrisk: right, the "everything in a directory" mode of the wget backend has bothered me for a while Nov 18 14:32:49 that is likely why it was blacklisted then.. You will have to dig into the component and fix it Nov 18 14:33:11 with this error, I'd say the first step is to ensure that either those components are disabled in emacs -- or you've included them as dependencies in the recipe.. Nov 18 14:33:25 assume that has been done, then you will need to dig into the configure components and fix them for cross compiling Nov 18 14:34:52 is there not a working emacs recipe in oe? Nov 18 14:35:24 i'd rather not reinvent the wheel.. Nov 18 14:35:56 search layers.openembedded.org -- I don't see one myself there. Nov 18 14:36:06 emacs is pretty heavyweight for an embedded system Nov 18 14:36:14 i see. thanks for the confirmation Nov 18 14:36:27 yes, and it won't be used in the production, but i need it for development Nov 18 14:37:30 last version I can find is in pyro Nov 18 14:37:42 and it was blacklisted Nov 18 14:37:49 yes, that's what i saw Nov 18 14:37:55 presuably it was removed from the next version because nobody cared to fix it Nov 18 14:38:16 qemu: uncaught target signal 11 (Segmentation fault) - core dumped - the recipe will be removed on 2017-09-01 unless the issue is fixed Nov 18 14:38:28 yup, i saw that Nov 18 14:38:35 so there you go, it's been removed for over 2 years and nobody has stepped in to fix it/resubmit it Nov 18 14:38:51 looks like i may be the lucky guy.. Nov 18 14:40:06 maybe i don't HAVE to have it.. Nov 18 14:40:30 i like/prefer running gdb inside it, but i could probably just run it standalone Nov 18 16:09:17 hi I am trying to add meta-selinux into a Yocto 2.4-based BSP provided by vendor but I found that I can't successfully build meta-selinux's 2.4 branch. I have to try to pick some fixes from master branch to continue but is still not yet succeed. Is there any other actively developed 2.4 branch or some other way to build against Yocto 2.4 BSP? Thanks. Nov 18 16:12:38 johnnylintw: I've used meta-selinux master branch on yocto 2.5, maybe that helps. Nov 18 16:12:47 Marex: so i see several py3 fixes in master, a few too many to be bothered backporting. is there an ETA for the 2020.01 release ('some time in january 2020 is an acceptable answer ;) Nov 18 16:18:23 mcfrisk: thanks for the info! I've tried to build meta-selinux master branch on 2.4 too, but bitbake just gave me version not match error. so maybe I just need to find some way to ignore that checking? Nov 18 16:18:54 hi all, let's say I have 20 recipes which I tag with the same tag name. How do I easily update the SRCREV and keep everything in sync without spending too much time on that? Nov 18 16:20:33 common include file that is written/managed by a script Nov 18 16:21:42 Hello. Anyone using the meta-raspberrypi layer? For some reason my root fs is read only when I write an SD card, and I have a hard time finding out what is causing this. Nov 18 16:23:01 fray: what do you put in that file? Nov 18 16:23:09 johnnylintw: modify LAYERSERIES_COMPAT_selinux in meta-selinux/conf/layer.conf Nov 18 16:23:29 because that's not really recommended to have tags in SRCREV for exanmmple Nov 18 16:23:45 variables that define the branch/tag/commit id or whatever.. then you have the recipe either require (error if it's not present) or include (no error -- but then you need recipe defaults) Nov 18 16:24:25 rburton: Release v2020.1 is scheduled for 6 January 2020 Nov 18 16:24:31 rburton: quote from IRC Nov 18 16:24:34 https://github.com/WindRiver-Labs/wrlinux/blob/WRLINUX_10_19_BASE/recipes-kernel/linux/srcrev.inc Nov 18 16:24:50 https://github.com/WindRiver-Labs/wrlinux/blob/WRLINUX_10_19_BASE/scripts/gen-linux-srcrev.sh Nov 18 16:24:52 look at those two Nov 18 16:26:08 (script generates the .inc) Nov 18 16:27:45 fray: thanks for sharing! Nov 18 16:28:18 fray: tell me if I'm wrong but modifying a line in your .inc file will trigger a rebuild even if that line isn't useful to all recipes right? Nov 18 16:28:56 mcfrisk: thanks! it is building now! Nov 18 16:33:09 Marex: thanks Nov 18 16:33:19 rburton: sure :) Nov 18 16:33:29 qschulz: only if you touch a variable that is used in a recipe Nov 18 16:34:16 rburton: alright, thanks Nov 18 16:34:45 fray: since we mentioned it earlier today, did you consider using auh? what made you not use it? Nov 18 16:36:48 auh? Nov 18 16:41:48 fray: http://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/ Nov 18 16:41:53 ohh that thing.. Nov 18 16:42:09 it's for recipe upgrades.. I don't consider srcrevs changing to be recipe upgrades Nov 18 16:42:26 upgrading is when you have 'releases' that move.. Nov 18 16:43:12 fray: doesn't mean auh can't handle it though ;-) Nov 18 16:43:25 fray: so you're among those having some kind of myrecipe_git.bb and then update the SRCREV only? Nov 18 16:43:47 qschulz it completely depends on the situation.. Nov 18 16:43:48 I'm still new to how people are using Yocto differently so eager to learnt he different usecases, not judging :) Nov 18 16:44:00 do YOU control the upstream and the recipe? then I prefer a _git recipe w/ SRCREV change Nov 18 16:44:12 if you only control the recipe, then AUH (or similar process) is the better way Nov 18 16:44:54 fray: I control the upstream and the recipe yes Nov 18 16:44:59 qschulz: FWIW if we could get devupstream (the class) working with native recipes, I'd love to have poky-bleeding working again Nov 18 16:45:13 (which tested upstream git versions of things) Nov 18 16:45:16 I find it easier to control the srcrev via the inc then.. since I can trigger it via a cron job, or a post-commit hook, etc.. Nov 18 16:45:33 the reference I posted is controlled by a daily cron job.. so once a day (or prior to a release) it is updated.. Nov 18 16:45:53 during development, the developer just 'rm srcrev.inc' and then it uses that absolutle latest from the tree.. Nov 18 16:46:04 so it enables the on-going development, but also locks it down to concrete versions as needed Nov 18 16:46:49 it's all about what process works for you.... there are a ton of ways of doing this.. some are better (dependencing on circumstance) then others.. but there are also a lot of 'wrong' ways of doing it.. Nov 18 16:46:57 AUH, scripting a srcrev.. they're reasonable.. Nov 18 16:47:11 forcing the system to always use AUTOREV is incorrect, since it breaks reproducibility.. Nov 18 16:49:53 fray: yeah I know about AUTOREV, great for bootstrapping your thing but horrible afterwards Nov 18 16:49:56 mcfrisk: my build just failed due to some patches in selinux :p seems like I still need to match the yocto version (?) Nov 18 16:50:06 exactly.. it's a good development tool, but not release Nov 18 16:55:38 is https://errors.yoctoproject.org is not responding, anyone else seeing this issue? Nov 18 16:56:33 armpit: same here! Nov 18 16:56:48 k, thanks Nov 18 16:57:18 halstead, can you take a look? Nov 18 16:57:28 ping works Nov 18 16:58:13 armpit, yes Nov 18 16:58:20 thanks Nov 18 17:00:23 johnnylintw: or just disable the patches and bbappends which you don't need. one way to do this is to BBMASK the paths in your distro configuration. Nov 18 17:02:25 armpit, Whatever is happening with errors is overwhelming the database. Nov 18 17:02:41 mcfrisk: okay. let me try again. thx~! Nov 18 17:03:41 halstead, that does not sound good. Nov 18 17:04:26 New news from stackoverflow: ERROR: /usr/bin/pcap-config should not be used Nov 18 17:08:44 mcfrisk: btw, just wondering if there is a proper way to use meta-selinux? use its master branch anyway or it's better to match the yocto version? those non-master branches make me want to use them lol Nov 18 17:13:41 armpit, Back online for now. I'm not sure if the layerindex update or something on the error-reporting-system was causing DB trouble. I'm separating them onto different database servers to isolate. Nov 18 17:14:10 k Nov 18 17:14:19 thanks for looking into this Nov 18 17:22:54 johnnylintw: IMO, with yocto and all meta layers, use the latest version that you can :) shipping products using old layer versions with old open source SW is not a good idea, even if some odd BSP layer depends on that specific yocto version.. Nov 18 17:27:57 agreed. latest versions means less exposure to security issues.. but you still need to update after release Nov 18 17:28:04 llvm/clang community seems to be doing interesting things, first going for github pull requests and now discord and discourse for discussiosn https://lists.llvm.org/pipermail/llvm-dev/2019-November/136880.html Nov 18 17:28:27 such a large community base and taking bold decisions, Nov 18 17:29:29 huh, bold indeed Nov 18 17:30:34 https://llvm.discourse.group/ Nov 18 17:31:13 mcfrisk: fray: thanks. agreed...will try to make the latest one works on my side rather than trying to make old branch work Nov 18 17:35:04 kergoth: lot of univerisities are using llvm for research for past 10-15 years and these students are now getting into work force Nov 18 17:39:21 khem: I did look at the community discussion on github pull requests and a few people were not very happy :/ Nov 18 17:39:57 RP: yes, few and that always is going to be the case Nov 18 17:40:36 it will be interesting to observe how it pans out for the community Nov 18 17:40:59 since llvm started almost same time as OE or maybe a bit earlier Nov 18 17:41:14 khem: it will be interesting to watch Nov 18 17:42:23 khem: questions pending your reply: Release 2.7.2 and Disband SWAT? Nov 18 17:42:40 indeed, I will naturally participate on these new frameworks and processes so will also help me understand more from inside out Nov 18 17:42:55 yes thanks gearing up :) Nov 18 17:43:06 its monday morning here Nov 18 17:43:32 khem: just prepping your queue as if I wait until later I miss it :) Nov 18 18:10:43 yeah heh my mornings are all on phone Nov 18 18:13:28 khem, I fixed that and the 'email' problem by getting a new job Nov 18 18:18:45 fray: I see the mail Nov 18 18:21:42 I now have 1 meeting a day.. and only a few emails to deal with.. taking a while to get used to not being interrupt driven in my work Nov 18 19:06:49 RP, oeqa, does it have the ability to define a test to run last? Nov 18 19:08:59 or to not run in parallel ? ie a reboot test Nov 18 20:00:04 is it possible to configure Toaster as a "read-only" service just to show me historical information about my Bitbake builds? Nov 18 20:40:12 khem: gnome is on discourse now i think too Nov 18 20:40:29 discourse? Nov 18 20:42:23 Crofton|work: Chat platform: https://www.discourse.org/ Nov 18 20:57:20 rburton: yeah gnome is on gitlab as well along with other freedesktop stuff, so they are going strong :) Nov 18 20:59:52 glibc is experimenting with gerrit yuck but anyway its better Nov 18 21:49:16 i wish github's pull request system was better at code review. not having an interdiff for branch changes is a serious oversight imo Nov 18 21:49:31 still better than email though.. Nov 18 21:49:43 heretic :) Nov 18 21:49:47 oh gerrit.... Nov 18 21:50:33 I have *way* too much experience using that Nov 18 21:50:35 i keep meaning to try reviewboard at some point, never got around to it though.. Nov 18 22:16:44 armpit: in short, no Nov 18 22:17:10 armpit: would have to be a selftest which could then "own" the running instance Nov 18 22:17:45 k Nov 18 22:17:56 wbn: if you have event logs for the build, yes Nov 18 22:18:04 wbn: but we don't save those by default iirc Nov 18 22:26:47 I much prefer email for reviews. If what is in the email isn't enough, I'll load it into git myself and do the comparisons.. I hate using web or graphical tooling for code reviews, it's incredibly slow compared to just reading an email and hitting 'reply' Nov 18 22:35:47 fray: I suspect part of it is use, but I know what you mean Nov 18 22:36:03 * RP worries a push to modern tech could alienate most of our current reviewers Nov 18 22:38:28 Hmm, nasm doesn't generate reproducible debug info :( Nov 18 22:41:03 JPEW: :( Nov 18 22:41:08 JPEW: did you see the bug I filed? Nov 18 22:41:55 #13606 ? Nov 18 22:42:03 oops Nov 18 22:42:08 13633 Nov 18 22:42:08 #13633 Nov 18 22:42:13 Ya, I saw that one Nov 18 22:42:19 JPEW: finally caught something Nov 18 22:42:24 JPEW: not sure what is in there... Nov 18 22:43:06 JPEW: I tested reproducibility enabled by default and "stuff" broke too :( Nov 18 22:43:22 Oh really? I wouldn't have expected that Nov 18 22:43:58 JPEW: I filed a load of bugs about it. I think the recipetool fix may help a lot Nov 18 22:44:05 Ok. Nov 18 22:44:09 JPEW: somehow its triggering a double free in opkg too :( Nov 18 22:44:16 * RP is trying to debug that one now Nov 18 22:44:19 Eww, that's strange Nov 18 22:44:22 since I doubt anyone will reproduce Nov 18 22:44:50 I don't seem to have ssh access to centos7-ty-2 Nov 18 22:46:05 And I have to go home now. I'll try to take a look at whats different in those packages tomorrow Nov 18 22:46:35 JPEW: I put the tarball in the bugzilla entry Nov 18 23:49:37 adelcast: around? Nov 18 23:51:10 hey RP, yep, saw your ticket about that nasty bug Nov 18 23:51:30 adelcast: right, I have made some progress on debugging it thankfully Nov 18 23:52:00 yes, looks like you root caused it already Nov 18 23:52:20 adelcast: I have some worries about opkg's error handling though Nov 18 23:52:20 I am hoping I can spend some time tomorrow to reproduce it, then get a fix Nov 18 23:52:51 adelcast: I at least can explain where the double free comes from and how to fix that Nov 18 23:52:59 error handling has always been less than ideal, yes.... Nov 18 23:53:20 adelcast: is there a reason it logs errors to a buffer it "saves for later" ? Nov 18 23:53:52 I don't think so no...this was before my time, but I can't think of a good reason Nov 18 23:54:04 adelcast: I'd be very tempted to make it output to stderr immediately as the current behaviour just confuses me Nov 18 23:54:28 adelcast: I fixed it to error "properly" and I get no output now to say what happened Nov 18 23:54:51 It does explain a lot of unusual opkg errors over the years though - thought it was bitbake losing things Nov 18 23:55:43 make sense to me, eating errors is just bad Nov 18 23:56:01 I'll take a look at it to see what it will take Nov 18 23:57:26 adelcast: I think its so it prints all the errors at the end of the output Nov 18 23:57:58 which makes sense....as long as you don't crash, hehe Nov 18 23:58:11 adelcast: right :/ Nov 19 00:01:19 adelcast: I think I've perhaps done the best I can with this and it may be better to let you take a look from here Nov 19 00:01:50 adelcast: I'm hoping you can at least reproduce it now you know where the double free is and the kind of package that is triggering it Nov 19 00:02:09 adelcast: let me know if you need more info from me I guess or if I can help further Nov 19 00:03:14 thanks RP, I quickly looked at the ticket and I think I have everything I need to fix the particular bug Nov 19 00:03:33 after that, I'll try to get rid of the error buffering Nov 19 00:03:53 I agree, that buffering is just confusing Nov 19 00:03:58 adelcast: thanks, much appreciated! Nov 19 00:04:05 np, =) Nov 19 00:04:41 adelcast: I still haven;t figured out how reproducibile builds generate empty packages but I'm not sure I want to know ;-) Nov 19 00:05:24 hehe, mm, well, I assume maybe those are virtual packages to group packagroups? Nov 19 00:08:35 adelcast: yes, I'm guessing timestamps disappear from the tar file or something which makes it empty Nov 19 00:08:52 adelcast: and we probably only detect double free on some libcs Nov 19 00:10:29 hmm, locally it has module info in that package Nov 19 00:12:26 ok, a problem for tomorrow, should sleep! Nov 19 00:13:03 adelcast: thanks again. I put my fix the double free patch into the bug, I suspect there is a bit more needed to avoid the underlying empty file error though **** ENDING LOGGING AT Tue Nov 19 02:59:58 2019