**** BEGIN LOGGING AT Fri Jan 18 02:59:57 2019 Jan 18 07:37:39 I'm using gcc and gccsdk 7.3% (in order to be able to compile linux-yocto_4.4% kernel) , in consequence gcc-sanitizers' build is crashing due to the non existence of sys/ustat.h. As far as I remember, sys/ustat.h has been removed from glibc Jan 18 07:40:02 My glibc is on version 2.28 Jan 18 07:42:09 Is it worth using an older version of glibc or shouild I just disable sanitize features from gcc? Jan 18 08:34:47 I know there is a way to assign functions to a specific machine, like IMAGE_BOOT_FILES_machine1. But is there a way to assign the same function to two machines? Jan 18 08:35:19 Or do I have to write it on two lines? IMAGE_BOOT_FILES_machine1 += "file" and IMAGE_BOOT_FILES_machine2 += "file" ? Jan 18 08:46:32 Hello guys, someone here knows how to remove task dependency in Yocto ? :) ( i have made a custom image class and it depends of do-image_cpio but i'm in a circular dependency :S Thx! Jan 18 08:48:54 Dont know if it works or if its recommended but could you try: do_image_cpio[depends] = "" Jan 18 08:48:57 ? Jan 18 08:51:53 BlauskaerM: Thx but i would like to remove a dependy or find how to change mine ^^ I have also try do_image_cpio[recrdeps] -= "do_image-custom" Jan 18 08:51:59 but doesn't work :( Jan 18 08:53:18 Is it possible to make a custom do_foobar() task depend on the src_uri file signatures - so it will run whenever any of the file signatures changes Jan 18 08:54:26 henriknj: the do-fecth doesn't do that already ? Jan 18 08:54:47 JP4u: Do you want to remove it all together or do you want to run do_image_cpio before or after do_image-custom ? Jan 18 09:04:24 BlauskaerM: in fact do_image_custom needs cpio.gz as input ( in order to build a custom fit image) so i have added do_image-custom[recrdeps] = "do_image_cpio" but doesn't do what i want ^^ Jan 18 09:06:16 #Could you try: do_image-custom[depends] += "" Jan 18 09:06:18 Damn Jan 18 09:06:35 What's the name of your image recipe? Jan 18 09:07:36 image recipe name : image-custom.bbclass Jan 18 09:08:29 i have also added do_image-custom[depends] with virtual/dtb:do_deploy / kernel:deploy and ${IMAGE_BASENAME}:do_build Jan 18 09:09:36 I had a simular problem the other day Jan 18 09:10:10 I don't understand why a task depends is between do_cpio and my custom image type :S Jan 18 09:11:09 The do_image function builds all image formats specified in IMAGE_FSTYPES and later moves them to the deploy folder with do_image_complete Jan 18 09:11:28 Do you need the cpio file for the wik image creation ? Jan 18 09:11:36 BlauskaerM: it's a good info Jan 18 09:12:07 BlauskaerM: Yes I need to put the .cpio.gz output file inside my custom type so i will try to change deps Jan 18 09:14:28 You could make the do_image_wic function dependent on do_image_cpio. But keep in mind that the files wont be present in the deply folder at this stage. If you want to add the cpio.gz file you could add it to the IMAGE_BOOT_FILES variable. Jan 18 09:15:03 In your image recepie. Could you try to add: do_imace_wic[depends] += image-cusom:do_image_cpio" Jan 18 09:15:06 And then Jan 18 09:15:26 IMAGE_BOOT_FILES += "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.cpio.gz" Jan 18 09:16:05 BlauskaerM: I'm going to make a try Jan 18 09:16:14 The cpio is finished but not in the deploy folder. But you can still find it in ${IMGDEPLOYDIR} Jan 18 09:17:46 Use IMAGE_BOOT_FILES += "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.cpio.gz;FILENAME" Jan 18 09:18:01 This will put the cpio file in to /boot with the name FILENAME Jan 18 09:19:39 Im taking this from one of my own recipes so the names might differ from yours Jan 18 09:20:00 BlauskaerM: thx i will adapt that and keep in touch :) Jan 18 09:20:08 BlauskaerM: thx for your time Jan 18 09:20:09 Use: bitbake image-cusom -e | grep -v "^#" | less Jan 18 09:20:13 To see your variables Jan 18 09:20:22 Good luck o/ Jan 18 09:21:25 New news from stackoverflow: configure: error: missing __attribute__ ((constructor)) support? Jan 18 09:28:50 BlauskaerM: I have to double check some steps but seems work :-) Thank you guy ;) Jan 18 09:30:35 JP4u: Live long and prosper Jan 18 09:31:32 BlauskaerM: thx Mr Spock Jan 18 09:51:22 Hi, I hope somebody can help me with understanding my "problem" I want to add some files in my rootfs under /usr/bin If i compile my qt application it will be created under packages-split -> projectname-tools folder. If i want to add the same file in another location for instance /test/application The application will be created under packages-split -> projectname. Can somebody help me understand this "issue"? It happend on a upg Jan 18 09:56:26 Guest59923: Maybe add a .bbappend on the QT recipe ? do_deploy_append() { } or set ROOTFS_POSTPROCESS_COMMAND_append ( dirty) Jan 18 09:58:40 yeah, i can also add projectname-tools to the image_install part. But i want to know why i need to add the -tools part to the projectname to get the application in the /usr/bin folder Jan 18 09:59:56 Guest59923: Ok i told you all i know... Jan 18 10:00:11 thanks :) Jan 18 10:09:42 Hi! "bitbake core-image-minimal" reports an error in do_package_write_ipk with "*** Error: Package name contains illegal characters, (other than [a-z0-9.+-])". I just added "package_ipk" and "opkg" and "package-management" in my local.conf to trigger that error. Do you have an idea what is going on here? Jan 18 10:11:01 It's suspicious that we have two spaces in the error message, as if there's an empty string Jan 18 10:13:09 sarah_connor: a bad copy/paste from windows ? Jan 18 10:13:43 JP4u: in local.conf? Jan 18 10:23:36 JP4u: im sure it does, but I have a custom task to do some variable expansion in the files Jan 18 10:26:32 JP4u: but I might just take a look at do_fetch and see how it is done there Jan 18 10:26:38 sarah_connor: maybe yes Jan 18 10:27:59 henriknj: you can also play with time stamp, it's dirty but you can force the fetch for each build Jan 18 10:28:07 JP4u: I'm quite sure I haven't copied from Windows, but to get sure I reverted the changes in local.conf and did them again with a linux editor and also called "dos2unix local.conf", but it does not help. Jan 18 10:28:29 henriknj: Some tasks are marked as "nostamp" tasks. No timestamp file is created when these tasks are run. Consequently, "nostamp" tasks are always rerun. Jan 18 10:28:55 JP4u: yeah im aware of that, and already tried that - didn't really work though Jan 18 10:29:05 sarah_connor: maybe pastebin some log :) Jan 18 10:29:46 henriknj: how do you set SRC_URI var ? from Git or personnal repo ? local files , Jan 18 10:29:54 just local files Jan 18 10:31:45 henriknj: personally I put all sources in a git repo with ${AUTOREV} to track the last commit of a branch, if i made some changes in the repo do_fetch function is run again Jan 18 10:32:27 JP4u: this is how the error appears: https://pasteboard.co/HX07la8.png Jan 18 10:35:46 JP4u: this is my current local.conf: https://pastebin.com/K7YzsG60 Jan 18 10:36:25 IMAGE_INSTALL_append = " opkg mytest" != IMAGE_INSTALL_append = "opkg mytest" try that ;) Jan 18 10:37:02 sarah_connor: I mean remove the first space after the = symbole Jan 18 10:37:07 or use += Jan 18 10:37:27 JP4u: trying... Jan 18 10:42:34 JP4u: no, it doesn't help. I wonder why the error message comes after "Subprocess output: kernel-module-snd-hwdep....", can you see a link between the error and that module? Jan 18 10:45:12 sarah_connor: I'm not an expert sorry... Jan 18 10:45:38 JP4u: anyway, thanks! Jan 18 10:45:58 sarah_connor: maybe check kernel driver recipe, are you sure is needed ? Jan 18 10:46:11 sarah_connor: have you made some changes inside meta-fsl ? Jan 18 10:46:48 JP4u: no, just added my own meta layer with just a helloworld.c Jan 18 10:47:16 the rest is pure yocto + fsl stuff Jan 18 10:49:17 sarah_connor: seems come from audio driver sound/core/snd-hwdep.ko Jan 18 10:49:35 maybe disable Alsa in kernel conf Jan 18 10:51:45 New news from stackoverflow: Yocto populate SDK - Receipe inherit from cmake Jan 18 10:52:02 JP4u: A strange thing is everytime I repeat "bitbake core-image-minimal" Subprocess output reports another kernel module Jan 18 10:53:00 sarah_connor: issue in cache ? maybe try -c cleanall on the kernel and/or image recipe Jan 18 10:54:45 JP4u: trying... Jan 18 10:55:01 Hi there, I posted here yesterday about an issue I had with parsing stuff. I don't know if this is reproductible with standard yocto and devtool (I'm using a vendor release) but the issue came from the do_patch function. Jan 18 10:56:16 from workspace/appends/linux-mainline_4.14.39-phy4.bbappend in the sdk, the do_patch function shall be replaced with do_patch[noexec] = "1" Jan 18 10:58:22 ok, I was debugging with yacar, so here is a little more details Jan 18 10:58:37 thanks @boucman_work :) Jan 18 10:58:44 basically, devtool generates a bbappend which contains "do_patch {:}" Jan 18 10:58:59 which (semantically) changes the do_patch into a nop Jan 18 10:59:25 problem is, in this vendor distro, there is some code, somewhere that seems to do a do_patch_append() Jan 18 10:59:31 so the nop wouldn't work. Jan 18 11:00:06 The situation is made worth because do_patch is actually python code, so the do_patch_append ends up adding python code to shell code (the ":" is the shell nop) Jan 18 11:00:36 so by generating do_patch[noexec] ="1" we cleanly disable do_patch in a way that has much less chances to break exotic setups Jan 18 11:01:03 remaining question (for us) : is there an upstream bug to fix :) Jan 18 11:03:18 rburton: -next ok with you? (I've dropped the bitbake.conf prefix change for now) Jan 18 11:06:49 RP: i haven't built-tested it yet, have you buildhistory-diff'd the upgrades? Jan 18 11:07:01 rburton: autobuilder should have! Jan 18 11:07:10 have you looked at the diff? :) Jan 18 11:07:49 rburton: no ;-) Jan 18 11:10:49 hmm, buildhistory is odd :/ Jan 18 11:12:15 rburton: http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/commit/?h=poky/master-next/qemux86&id=e3195d9809716652546a1ac69a75287ec707e79b is the one we want I think Jan 18 11:14:14 rburton: Looks like a lot of debug files disappeared Jan 18 11:15:32 * RP reports that on the list Jan 18 11:21:55 rburton: apart from that the diff looked ok but I'll let you run your process. I've run the GL patchset on top on the AB in the meantime Jan 18 11:28:35 RP: I made a demo video for that https://www.youtube.com/watch?v=0YBuku3JESc Jan 18 11:28:42 rburton: ^^^ Jan 18 11:29:02 not sure whe the video plays in 360p here, I did upload the HD version Jan 18 11:29:03 woo Jan 18 11:29:11 youtube needs time to reprocess Jan 18 11:30:03 I see higher res versions, 720p + 1080p Jan 18 11:31:00 probably missing codecs in browser Jan 18 11:31:09 kanavin: nice! :) Jan 18 11:31:35 RP: not sure if you noticed, v3 of the patch adds headless support Jan 18 11:31:49 so qemu renders into memory and makes that available via vnc or spice Jan 18 11:34:18 kanavin: I like that, we already use vnc on the autobuilders Jan 18 11:35:08 RP: I also added a couple of checks into selftest, so that gtk test runs only if DISPLAY is set, and headless test runs only if mesa drivers are available on the host machine Jan 18 11:35:32 RP: how is vnc used? is there a vnc client involved somehow? Jan 18 11:35:46 or just that qemu is configured to run a server, but nothing actually connects Jan 18 11:36:07 kanavin: we start a vnc server to make DISPLAY available for SDL Jan 18 11:36:13 we can in theory connect to it to debug if we wanted Jan 18 11:40:17 hi all Jan 18 11:41:50 RP: right, I think gtk opengl test will not be able to use that, as it is using GLX Jan 18 11:44:26 I have a package using cmake but my includes files is not shipped in SDK. Any recommendations ? Jan 18 11:51:58 New news from stackoverflow: Yocto parallel configuration packages files conflict Jan 18 11:59:27 How can I override do_image_wic with a machine value? Jan 18 12:00:49 Or, can every variable be overridden? Jan 18 12:06:08 BlauskaerM: basically yes Jan 18 12:07:53 So its possible to override do_image_wic to apply to a specific machine with do_image_wic_machine1 ? Jan 18 12:35:05 Jpu4: you ddin't install the image into the image that the sdk is based on? Jan 18 12:38:28 rburton: i described more my issue here : https://stackoverflow.com/questions/54252223/yocto-populate-sdk-receipe-inherit-from-cmake Jan 18 12:38:55 kanavin: you probably need to look through https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/128 Jan 18 12:40:32 those files should be in the -dev package for a start. you still haven't confirmed that the image depends on your recipe. Jan 18 12:42:21 i've set DEPENDS +="spdlog" in my recipe that depend of this package Jan 18 12:42:21 Do we have something like the wic templates (wks.in) for ordinary files? Jan 18 12:42:30 RP: yeah, has been watching anxiously for the past 20 minutes or so :) Jan 18 12:43:18 in my image.bb I've set CORE_IMAGE_EXTRA_INSTALL +="mypackage" Jan 18 12:43:43 henriknj: something like https://github.com/rossburton/meta-ross/blob/master/classes/bbin.bbclass? Jan 18 12:43:51 Jpu4: only packages explicitly in IMAGE_INSTALL will get their -dev packages in an SDK, if I recall correctly. Not those who are only pulled in as dependencies to other packages in IMAGE_INSTALL Jan 18 12:43:56 kanavin: not sure I understand some of the things failing there :/ Jan 18 12:44:03 Jpu4: erbo isn't correct Jan 18 12:44:55 oh :( Jan 18 12:45:05 RP: some are obvious (musl compile failures), others can be tricky, like qemu failing to start against vnc with the new gtk frontend Jan 18 12:45:42 rburton: yeah like that Jan 18 12:45:52 RP: But adding the missing -dev packages to TOOLCHAIN_TARGET_TASK should fix it, right? Jan 18 12:46:04 rburton: already implemented similar functionality myself, but would rather use something upstream Jan 18 12:46:05 henriknj: feel free to copy that and send me any improvements. as a proof of concept it worked well, but the todo is quite a big poblem Jan 18 12:46:23 henriknj: get the todo sorted somehow and we can merge it into oe-core... Jan 18 12:46:37 rburton: alright, ill look into it Jan 18 12:46:39 thanks Jan 18 12:49:00 I have to add something to export my includes files into SDK ? Jan 18 12:49:25 nope, if PN is in an image, then PN-dev will be in a SDK generated from that image Jan 18 12:49:48 did you check that the files don't exist, and its not cmake breaking instead? Jan 18 12:51:55 Yes. I checked. I installed the sdk and The file doesn't exist Jan 18 12:52:55 rburton: are you sure the -dev packages for all packages in an image ends up in SDK? Jan 18 12:56:32 erbo: package_manager.py, line 571. complementary packages are based on the actual list of installed packages. Jan 18 12:58:41 rburton: and that list contains packages pulled in as runtime dependencies too? Jan 18 12:59:05 its the list of packages *actually* installed in the sdk Jan 18 12:59:13 I know we have work-around for that behavior in a project currently on rocko, maybe things have changed Jan 18 12:59:34 nope. if you can replicate that not happening then please file a bug with the example Jan 18 13:00:27 Ok, I'll try it out using vanilla poky Jan 18 13:26:43 How can I override do_image_cpio with a specific machine? do_image_cpio_machine1 does not work =/ Jan 18 13:29:30 Yes. Files specified in FILES_${PN}-dev included in SDK Jan 18 13:29:35 thanks all Jan 18 13:33:02 hmm... meta-fsl-bsp-release/imx/meta-bsp/recipes-kernel/linux/linux-imx-src.inc contains 2 lines which could be the reason why do_package_write_ipk fails with "Package name contains illegal characters, (other than [a-z0-9.+-]) Jan 18 13:33:19 SRCBRANCH = "imx_4.9.88_2.0.0_ga" Jan 18 13:33:27 LOCALVERSION = "-${SRCBRANCH}" Jan 18 13:33:50 That variable LOCALVERSION contains underscore then Jan 18 13:34:41 Anybody here who knows about that piece of code? Jan 18 13:35:53 There was already a patch here https://lists.yoctoproject.org/pipermail/meta-freescale/2017-January/020119.html but it seems there are more places of that type of bug Jan 18 13:36:08 What should I do now? Jan 18 13:42:02 Any freescale gurus around here? :) Jan 18 13:43:34 The problem is I could try to hack with my half-knowledge but I think I'd more break than fix things :D Jan 18 13:46:49 Actually it would be nice if sources/poky/meta/classes/package_ipk.bbclass fixes the package name automatically and replaces the bad chars with e.g. "-" or at least outputs what the evil string is why things break Jan 18 13:47:15 ...there in do_package_write_ipk() Jan 18 14:35:44 Hi, is there an equivalent to BBMASK to hide a bbclass and an .inc file ? Jan 18 14:45:15 hi, why cannot use local git fetcher? Jan 18 14:45:37 this is my attempt: SRC_URI = " git:///home/lpapp/Projects/foo;protocol=file;nocheckout=1 \ Jan 18 14:45:46 SRCREV exists in /home/lpapp/Projects/foo Jan 18 14:46:06 is it because it is looking for the commit upstream, why? Jan 18 14:47:22 you havent' said what hte actual error is Jan 18 14:47:36 lpapp: try to add nobranch=1 Jan 18 14:49:14 lpapp, maybe this can help you https://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#building-software-from-an-external-source Jan 18 14:49:35 git clones from local repositories work fine, no magic required Jan 18 14:49:49 please say what the error is and people can stop guessing :) Jan 18 14:50:22 * zeddii blames aliens Jan 18 14:50:49 nah its never aliens. its dragons. Jan 18 14:51:09 * zeddii nods Jan 18 15:47:23 * RP likes dragons Jan 18 16:09:05 so no one knows how to hide a .bbclass and an .inc file ? :) Jan 18 16:17:48 meow`: other than tweaking BBPATH so it can't see the directories, or adding a dummy copy somewhere higher in BBPATH, no Jan 18 16:18:11 rburton: I assume you reviewed buildhistory now? Jan 18 16:23:39 RP: oh sorry, yes, fine Jan 18 16:23:50 RP: haven't reviewed the qemu pathbomb yet though Jan 18 16:24:02 rburton: it not ready yet Jan 18 16:30:44 re Jan 18 16:30:56 is there a way to 'uninherit' in .bbappend? Jan 18 16:31:06 varjag: no Jan 18 16:31:07 or should one make their own .bb instead Jan 18 16:31:31 RP: i see, thanks Jan 18 16:38:17 RP: ok, thanks! Jan 18 17:33:41 RP: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/virgl-gtk could be tested again, I fixed a few things, and there would be a clearer picture on what is still not working Jan 18 17:33:45 rburton ^^^ Jan 18 18:03:39 RP: that debug prefix map broke my nightly builds :) Jan 18 18:12:01 khem: it wasn't so bad for ours, just go issues but it did beak the -dbg packages Jan 18 18:12:16 kanavin: after the AB maintenance window Jan 18 18:12:27 kanavin: halstead can probably trigger it, or I will later Jan 18 18:12:27 yeah so whole night is lost on me Jan 18 18:12:45 khem: well, the point is to find these issues Jan 18 18:12:51 RP: I sent a patch to clean up STAGINGCC Jan 18 18:12:55 khem: it didn't merge Jan 18 18:13:02 khem: that is a win Jan 18 18:13:04 RP: yes thats right Jan 18 18:13:37 khem: nice to get rid of those! Jan 18 18:14:04 RP: yes, they were adding directories to path which dont exist or are not needed Jan 18 18:14:13 RP, I can start it. Just default master settings otherwise. Jan 18 18:14:26 halstead: yes please Jan 18 18:15:16 RP: I am thinking of renaming glibc/binutils/gdb recipes to not have version in recipe name inside the recipe Jan 18 18:15:39 I am mean to move the PV into recipe Jan 18 18:16:09 khem: why? Jan 18 18:16:15 makes it easly to upgrade as they use git fetcher Jan 18 18:16:45 khem: I'd much prefer we used tarball releases to be honest Jan 18 18:16:58 RP: it makes easy for me to maintain an overlay to switch to master versions of them Jan 18 18:17:01 khem: its much less overhead for fresh builds Jan 18 18:17:16 khem: how about we have git and tarball versions of the recipe? Jan 18 18:17:30 khem: we could even bring back poky-bleeding to test them Jan 18 18:17:39 * RP needs to head afk for a bit Jan 18 18:18:41 I think that would work too but how these components have developed release overtime is that minor releases are a simple bump in SRCREV instead of having a lot of patches in metadata Jan 18 18:20:41 RP: before you go afk I have bsp patches held up on http://lists.openembedded.org/pipermail/openembedded-core/2019-January/277944.html Jan 18 18:25:03 khem: rburton's devupstream class may be of use Jan 18 18:27:01 RP, https://autobuilder.yoctoproject.org/typhoon/#/workers/19 and perf-ubuntu1604 are attached. I skipped setting up KVM/qemu and the tun devices since they are not used. Jan 18 18:27:26 RP, I'm going to finish the rest of the machines now then start that build. Jan 18 18:32:38 RP: I got a question about the --with-sysroot=/not/exist configure opt to the compilers Jan 18 18:33:13 RP: in the commit you mention its purpose was to poison the build, to catch code that was making assumptions on the sysroot, that I get Jan 18 18:33:41 kergoth: good point I have meant to make is usable Jan 18 18:33:52 but also, Paul mentioned something on an email regarding that after using that option, we can share the same compiler per architecture, not per machine Jan 18 18:33:59 that I dont get Jan 18 18:34:12 is it just because the STAGING_TARGET_DIR will change per machine? Jan 18 18:34:17 khem: help ^^ hah Jan 18 18:53:27 New news from stackoverflow: Yocto Build git directory is missing for Kernel Jan 18 18:56:01 aehs29: that option adds a default sysroot (internal) to compiler and will be used when its not specified on cmdline Jan 18 18:56:15 which in OE is machine specific Jan 18 18:56:34 so if we poison the internal sysroot then we open it up Jan 18 18:58:39 aehs29: It means that we always need to pass in a path as the default is never right. We moved on and have a sysroot per recipe now Jan 18 18:59:32 halstead: sounds good thanks! Jan 18 19:01:10 khem: queued in -next Jan 18 19:02:21 aehs29: we do only built the compiler once per arch and this means the compiler paths arent arch specific Jan 18 19:05:07 RP: thanks superb Jan 18 19:05:44 RP: yeah with RSS it should be automatically poisoned Jan 18 19:16:58 RP: thanks, let me know :) Jan 18 19:17:13 RP: btw, slightly disappointed at lack of reaction to AUH Jan 18 19:24:31 kanavin, Are there changes that need to be pulled into the production AUH? Jan 18 20:01:05 kanavin, Started https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/131 Jan 18 20:02:41 kanavin: yes, could be better. Just patches from you/I so far Jan 18 21:19:29 RP: khem ok, thanks guys Jan 18 21:24:44 hi. where can i possibly find docs on how to create / manage opkg / ipk repositories (creating index, signing, etc) ? Jan 18 21:24:44 also, can anyone elaborate on how much yoctos's opkg diverged from openwrt's ? Jan 18 21:27:57 maybe adelcast Jan 18 21:29:00 Piraty: opkgwrt is based on an old fork of opkg, about 5 years old Jan 18 21:29:05 (last time I checked) Jan 18 21:29:55 at least they managed to move to cmake which probably makes some thing easier, but i didn't dive that deep to find out Jan 18 21:30:06 hi adelcast :) Jan 18 21:30:29 All their patches were integrated into upstream opkg a couple of years ago...but then they didn't move to use upstream opkg Jan 18 21:30:31 hi, =) Jan 18 21:30:46 oh, I wasn't aware of that!, I need to check it out....I would LOVE to move opkg to cmake Jan 18 21:31:39 a year ago someone contacted me, wanting to collaborate on the project, then decided to take on the move to cmake....I have some guidance but then didn't hear back from him again Jan 18 21:33:54 i didn't check the build of openwrt yet, but my router runs it, so it seems to work :D Jan 18 21:34:27 **checking openwrt repositorty Jan 18 21:35:38 how's the contribution process for yocto's ? mailing list? Jan 18 21:36:21 yep, opkg-devel@googlegroups.com Jan 18 21:36:37 g00gl3 yay Jan 18 21:37:19 wow, they have diverged a lot Jan 18 21:37:46 they forked opkg on 2011-04-08 Jan 18 21:39:32 they backported some of the newer stuff...I have no idea why they just used the latest opkg and upstream their changes Jan 18 21:40:41 I need to contact them to see if we can plan on merging the branches, makes no sense to me to have a fork Jan 18 21:43:05 regarding documentation for creating indexes....there is no man page, but the script itself now has documentation (recent change), so running opkg-make-index (0.4) should give you instructions on how to use it Jan 18 21:44:28 for signing you can follow the instructions here: https://github.com/balaji-reddy/OpkgCheckSignature/blob/master/opkg_signature_check.txt Jan 18 21:44:36 at some point that info should make it into one of the man pages Jan 18 21:45:13 adelcast, tehy are the fork :) Jan 18 21:46:14 hehe, yeah, I meant: "make no sense to me that they forked while there is an active upstream" Jan 18 21:55:10 I wonder if we had ustream then? Jan 18 21:55:21 maybe ask paulbarker if he knows history Jan 18 21:58:29 iirc opkg did lack a maintainer for a short time, no idea if it was when they forked, though Jan 18 21:58:51 surprised they didn't merge back when it was maintaineda gain, likely a lack of resources on their end Jan 18 22:37:50 thanks adelcast , will take a a look soon, and probably come back here for more ;) Jan 18 22:39:27 at least #openwrt-devel doesn't seem responsive in regard to opkg Jan 18 22:48:09 adelcast: I keep meaning to ask you, would there be any objection to patches adding SPDX license headers to opkg? Jan 18 22:48:29 adelcast: I think its time we looked at this for various Yocto Project things Jan 18 23:05:55 RP: not at all, makes sense to me Jan 18 23:21:03 QUESTION: If I have MACHINE_FEATURES += "efi pcbios" in my conf, but when running wic with a *.wks file line(part /boot --source bootimg-pcbios --ondisk sda --label boot --active --align 1024) it fails with "Couldn't find correct bootimg_dir, exiting". Jan 18 23:23:17 I'm curious what could cause this failure, although I have migrated to some new hardware and slight changes to recipes. Jan 18 23:25:37 is there a small/tiny distro that defaults to everything being read only except for a ramdisk so it is completely powerfailure agnostic? Jan 18 23:26:29 poky-tiny could be a decent starting point. could adjust to use musl and then use one of the initramfs recipes and configure your bootloader appropriately for the hardware in question Jan 18 23:27:26 so if I don't care about size, poky-tiny will meet the power failure agnostic part? Jan 18 23:28:18 or do I still need the initramfs recipe tweaks? Jan 18 23:28:20 not sure what you mean. any distro can build a read only rootfs by enabling the imag efeature for it Jan 18 23:28:40 distro and image are independent axes of the build. any image can be built for any distro Jan 18 23:28:45 hmm? thought most distros still want a writeable /var? Jan 18 23:28:50 I use: EXTRA_IMAGE_FEATURES =read-only-rootfs Jan 18 23:29:06 no, not just readonly rootfs; no writeable media period. Jan 18 23:29:10 just a ramdisk Jan 18 23:29:10 ds2: enabling a read only rootfs will automatically use tmpfs for certain areas, unless you use overlayfs or a data partition Jan 18 23:29:17 and? Jan 18 23:29:42 kergoth: got it. ro rootfs on desktop is a weaker definition Jan 18 23:29:45 tmpfs *is* a ramdisk. but booting an initramfs as your rootfs depends on the configuration of your bootloader for the particular machine/bsp, as i mentioned before Jan 18 23:29:59 to ensure your kernel cmdline is set correctly for that configuration Jan 18 23:30:23 not worried about bootloader bit... it is the userland blackmagic that I am unsure of Jan 18 23:31:23 so I don't care about the distro. just need to add EXTRA_IMAGE_FEATURES=read-only-rootfs to whatever distro, right? Jan 18 23:31:39 it's handled for you by the implementation of hte read-only-rootfs distro feature, generally Jan 18 23:32:30 systemd tmpfiles configurations and/or sysvinit volatiles helps to populate any tmpfs areas, volatile-binds recipe sets up bind mounts to make other areas writeable without losing existing directory contents Jan 18 23:32:43 there's a varaiblke to control which areas you need to be writable for your userland apps Jan 18 23:33:00 s/distro feature/image feature/ Jan 18 23:33:32 the default setup assumes you don't need to persist any user configuration, if you do, you'll need to make some tweaks Jan 18 23:33:48 arrange for the writable areas to be based on a user data partition rather than tmpfs, for example Jan 18 23:33:56 depends on your requirements, obviously Jan 18 23:34:01 or I can do it as a custom thing like a script with mtools ;) Jan 18 23:34:15 cool, this is easier then I expect Jan 18 23:34:28 if you want ot do something custom, you can basically do whatever you want, the read-only-rootfs bits is just how oe-core does it Jan 18 23:36:08 there are minimal rootfs images suitable for initramfs usage in oe-core, though a couple of them make assumptions about how they'll be used. initramfs-framwork is avaiable, but of course that's more for a typical boot the initramfs to switch to a real rootfs use case. all you really need is a tiny rootfs image (i.e. core-image-minimal) with IMAGE_FSTYPES set to cpio or cpio.gz Jan 18 23:37:06 some folks sidestep all the read-only-rootfs logic and tmpfs mount symlinks and bind mounting in favor of an overlayfs-based setup, your call exactly how you want to make things writable Jan 18 23:37:51 I want to avoid the kernel controlling a writeable FS. so the minimal seems to be what I want Jan 18 23:38:22 using mtools to write out data to presist seems to be the simpliest way Jan 18 23:38:23 of course, a full initramfs based setup probably doens't need any of that, obviously, i have no idea why i brought that up, probably due to the mention of read only. booting hte entire rootfs from ram makes it a nonissue Jan 18 23:38:26 * kergoth nods Jan 18 23:38:49 outside of yocto, some of that gets hairy Jan 18 23:38:52 using a small distro can still be of use to shrink the image by removing features from installed packages, i.e. optional deps on x11 Jan 18 23:39:06 or use musl instead of glibc, etc, to reduce initramfs size Jan 18 23:39:38 but its largely independent of the image. machine/distro/image orthogonality is a core feature of the project Jan 18 23:40:05 i think 90% of what i've written about in the past 15 minutes doesn't help you at all, but oh well, it's background if nothing else :) Jan 18 23:40:25 short answer: yes you can do what you want, just depends on your requirements Jan 18 23:40:55 or depends on my yocto skillz :D Jan 19 00:05:36 ds2: theres also a core-image-tiny which sets some of that (along with poky-tiny, the distro) Jan 19 01:19:55 9 **** ENDING LOGGING AT Sat Jan 19 02:59:56 2019