**** BEGIN LOGGING AT Wed Jan 23 02:59:57 2019 Jan 23 03:43:27 New news from stackoverflow: Disable a standard systemd service in Yocto build Jan 23 07:44:13 Hi, when I want to add new packages to core-image-minimal for extending my distro, where can I get a list of package names which are available? Jan 23 07:47:21 I don't want to create new packages but include more standard packages Jan 23 08:01:45 linyoctox: What Yocto version are you using? Jan 23 08:02:17 linyoctox: Check out http://layers.openembedded.org/layerindex/branch/master/recipes/ Jan 23 08:02:35 linyoctox: Switch to your branch/version Jan 23 08:28:37 malanecora: sumo Jan 23 08:37:10 malanecora: your link leads me to a search page but not an overview list of packages (?) Jan 23 08:38:25 malanecora: How can I get the list there? Jan 23 08:38:58 linyoctox: You can install all the packages you can find there Jan 23 08:39:30 linyoctox: If yoou want a list, go to "Layers" and take a look inside Jan 23 08:40:36 malanecora: ah OK, thanks. So a recipe is a package I can install, right? Jan 23 08:44:24 New news from stackoverflow: Yocto openssl package not installing binary files Jan 23 08:54:24 linyoctox: Kind of Jan 23 08:54:46 linyoctox: A recipe can contain multiple (sub)packages Jan 23 10:30:56 Hi all, we have a common location for downloads for several users what is the proper solution to change the group permissions of downloaded files/git repo's ? Jan 23 11:18:09 I've just noticed that udevd starts 7s later in Thud than in Rocko, in addition it seems that it struggles with the network interfaces... Jan 23 11:18:51 It makes wlanx available at 60s, whereas it is available at 4s in Rocko Jan 23 11:27:47 malanecora: thanks, it's a good hint (y) Jan 23 12:07:09 Regarding the aforementioned issue with udev, anyone knows what could be its cause? Jan 23 12:08:25 I keep the same rules from the old config Jan 23 12:53:05 Just kernel version went from 4.4.113 to 4.4.164 Jan 23 13:12:45 hell! Jan 23 13:12:51 oops, heelO! Jan 23 13:12:57 eh, hello! Jan 23 13:13:23 anyone doing rust using meta-rust ? Jan 23 13:17:35 Is it possible to use shared libraries? I know it doesn't have stable abi, but as all deps would get rebuild if rustc would change, and as long as I upgrade whole system at a time. this shouldn't mater, but would save space Jan 23 13:55:32 Hi everyone. Is there any option to "deduce" the kernel's version and the drivers' version that would be in the image from the building files (before writing the image)?? Jan 23 13:58:06 nacknick: might even be in bitbake -e virtual/kernel Jan 23 14:02:29 LetoThe2nd - In what variable? What about the drivers? It all looks like a big chaos there Jan 23 14:02:54 nacknick: in waht is for you o grep ;-) Jan 23 14:06:30 I see udev (eudev) has been updated to 3.2.5 in Thud (from 3.2.2), can this update be the cause of the malfunctioning? Jan 23 14:22:48 uhm... I don't want to "vi /etc/opkg/opkg.conf" in my running yocto linux on my eval board everytime after I rebuilt the whole thing. How can I put my edit to that opkg.conf already in a recipe or something? Jan 23 14:27:14 Is there somewhere a tutorial how to put my edits to root-filesystem config files already in yocto recipe files (instead of editing those config files at runtime on the eval board which is running yocto linux)? Jan 23 14:27:37 you need to use a bbappend specif to your machine for the file that installs it Jan 23 14:29:02 These are both logs (old and new) Jan 23 14:29:03 https://pastebin.com/gMRDZTqF Jan 23 14:31:50 linyoctox: As Crofton|work says, you should write a opkg_%.bbappend in you own layer with "FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"", also bundle your desired opkg.conf file along it in the same folder Jan 23 14:32:43 nice! thnx. Understood Jan 23 14:34:09 malanecora, thanks for recalling exact details :) Jan 23 15:08:36 does make sense to compile cmdline and dtbs into the kernel? I already have kernel compiled for each machine... and then I don't have to deal with device tree loading in bootload Jan 23 15:17:45 Hi!, Jan 23 15:19:12 I need to create os image that runs a ruby application on a raspberry pi. I already build a base poky image with meta-raspberrypi. Now I need to install ruby and copy the source code of my project, any idea on how to do that?? Jan 23 15:19:21 linyoctox: fyi you can use recipetool appendfile to mostly automate the process of overriding target files. it'll figure out what package provides it, append that recipe, adjust filesextrapaths, etc Jan 23 15:19:36 or appendsrcfile to do the same for files in SRC_URI Jan 23 15:21:20 In the poky/meta directory there is a receipes-devtools where I can find some ruby recipies. Should I use that? Jan 23 15:22:07 I was thinking on creating my own layer that installs ruby, the ruby gems, copy my source code, and add start the app with systemd Jan 23 15:22:28 sounds like a good aproach?? I don't even know where to start though Jan 23 15:23:56 layers don't install packages, images do Jan 23 15:24:16 and you can pick what packages go into an image in local.conf, no need for a new layer for that, unless you want to create a new image recipe for easier long term maintenance Jan 23 15:26:58 mm, I think I might have some misunderstud concepts .... I'll take a new read on images/packages/recipe/layes Jan 23 15:29:46 What is with more complex stuff like adding users and give them passwords? Jan 23 15:30:05 Is it supported by recipes? Jan 23 15:31:52 yes, both recipes and images can do that Jan 23 15:33:46 https://www.yoctoproject.org/docs/2.6/dev-manual/dev-manual.html#extendpoky Jan 23 15:34:09 https://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html Jan 23 15:45:45 New news from stackoverflow: When to modify Poky vs creating a new distro Jan 23 15:52:32 if I want to find Jan 23 15:52:51 CAN driver version (from the image), how should I do it? Jan 23 16:03:47 kergoth: cool! Jan 23 16:07:10 anyone very familiar with compiling and installing selinux policy files? Jan 23 16:10:20 kergoth: zeddii maybe? Jan 23 16:17:32 trying to get container-selinux to build but it fails and i know squat about the policy file format Jan 23 17:06:08 What is the rules concerning when VAR_pn-recipe is used, and when it's not? E.g. SRCREV_pn-myrecipe is needed, but IMAGE_INSTALL_append_mymachine seems not. Does the latter imply that IMAGE_FEATURES_append_mymachine also works? Jan 23 17:13:10 https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides Jan 23 17:15:39 hi. it's me asking about opkg again. can ipk/debian packaging format handle package-alterantives, and is opkg capable of it? meaning: having two packages provide the same functionality (at least they pretend to) so dependencies are fulfulled correctly ? Jan 23 17:15:57 classic ecample is java packages in mainstream distros Jan 23 17:18:12 Piraty: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-update-alternatives Jan 23 17:18:13 kergoth: yeah, thanks. It does not specify precisely _how_ the specific variables allows for override in OE/Yocto. To me it seems like a little bit of magic :) Jan 23 17:18:28 thanks you JPEW Jan 23 17:18:31 sveinse: yes, it does Jan 23 17:19:17 as it says, it's controlled by OVERRIDES. go look at what OVERRIDES is set to in oe-core Jan 23 17:26:41 Hmm, I get the OVERRIDES suffix (I think), but I still don't see the difference between in-recipe scope and global scope. Please let me explain: Jan 23 17:28:30 If I have a recipe a, I can set any vars in that scope from global with VAR_pn-a. If I have an image recipe b, I seem to be able to set IMAGE_INSTALL_append and IMAGE_FEATURES_append from local.conf, not IMAGE_INSTALL_pn-b or IMAGE_FEATURES_pn-b for some reason Jan 23 17:29:05 ...yeah missing the _append suffix on the two latter Jan 23 17:32:03 Perhaps the _append and/or _someoverride pulls in the global var into the local scope Jan 23 17:33:42 adelcast: which protocals can opkg transfer over? everything that curl can right? Jan 23 17:34:55 yep, http and https Jan 23 17:38:55 still not seeing what you're referring to Jan 23 17:39:34 recipes essentially inherit the global metadata. they copy that datastore and then parse the recipe to add to it Jan 23 17:40:22 setting a variable globally and setting it in the recipe is basically the same thing, except that the former will affect multiple recipes, and the recipe can always override what the config metadata does, since its parsed later Jan 23 17:40:54 So for image recipe a, using IMAGE_FEATURES_append = " something" is completely equal to IMAGE_FEATURES_pn-a_append = " something" ? Jan 23 17:40:55 overrides are just conditionals. that's all. not magic Jan 23 17:41:10 no, those are completely different things Jan 23 17:41:30 FOO_someoverride_append will append to FOO_someoverride, then FOO_someoverride will *replace* the existing contents of FOO, overriding it Jan 23 17:41:40 FOO_append_someoverride will append to FOO conditional on the override Jan 23 17:42:19 So "pn_a" is an override? Jan 23 17:42:49 as i just said, conditionals are done with overrides Jan 23 17:42:57 the OVERRIDES variable controls what overrides will be applied Jan 23 17:43:10 OVERRIDES in oe-core has 'pn-${PN}' listed, which is why i told you to go read it Jan 23 17:43:20 so yes Jan 23 17:43:57 fyi, the FOO__append vs FOO_append_ difference is documented in the bitbake user manual at https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#variable-interaction-worked-examples Jan 23 17:44:34 the bitbake user manual link i already linked you to covers the override + append/prepend syntax. Jan 23 17:44:36 DEPENDS = "glibc ncurses" Jan 23 17:44:36 OVERRIDES = "machine:local" Jan 23 17:44:36 DEPENDS_append_machine = " libmad" Jan 23 17:44:50 use of pn- is no different than using machine Jan 23 17:44:55 it's all just a string listed in OVERRIDES Jan 23 17:46:33 I tried dumping OVERRIDES with bitbake -e, but there is no pn-${PN} in it Jan 23 17:46:38 https://github.com/openembedded/openembedded-core/blob/master/meta/conf/bitbake.conf#L724-L737 Jan 23 17:46:43 yes, there is Jan 23 17:46:50 it's the third entry Jan 23 17:46:53 as linked above Jan 23 17:47:07 bitbake -e shows you the expanded value Jan 23 17:47:40 if you used just 'bitbake -e', not 'bitbake -e yourrecipe', it would have shown pn-default or something, since it coudlj';t set PN from the recipe name when you're looking at global config metadata that isn't a recipe Jan 23 17:47:54 yeah, I found it, so I was wrong Jan 23 17:49:00 I have to digest this, It's not obvious how this behaves Jan 23 17:50:11 adelcast: ftps too? Jan 23 17:50:16 even sftp ? Jan 23 17:54:31 kergoth: ok, I think I might understand why my PV_pn-linux_append = "-myfeature" didn't work. Because I was appending the override. Is there a way I can from local.conf append to a specific recipe's PV? Jan 23 17:55:07 PV isn't in overrides, so not directly, but you can use inline python to deal with that. append it to any recipe but only return a value when the version matches Jan 23 17:55:58 if you're appending hte same variable you want to check, that's not going to happen, as that'd recurse. you can't append PV based on PV's existing value from the metadata due to how our expansion works (lazy) Jan 23 17:56:08 Piraty: yes, it should. The URL is directly passed to CURL (check opkg_download_curl.c), and curl supports both ftp and sftp Jan 23 17:56:21 now you could use anonymous python to do that, since it'd happen at a fixed point in time, and you can control whether it's expanded Jan 23 17:57:03 i.e. FOO_append = " ${'foo' if d.getVar('PV') == 'something' else ''}" would work, but PV_append = wouldn't, since it'd refer to its own value Jan 23 17:57:58 kergoth: interesting. PV_pn-linux_append = "new-full-version" surely worked from local.conf -- althou I am aware that using _append makes no sense based on what was just mentioned. But the recipe PV is overriden Jan 23 17:58:13 yes, it'd replace the existing value of PV Jan 23 17:58:38 same as just setting PV_pn-linux unless there are multiple _appends, since they're cumulative Jan 23 17:58:52 yep Jan 23 17:59:36 kergoth: thanks! Jan 23 17:59:43 no problem Jan 23 18:00:26 overrides itself is pretty sipmle, even our ofile format is for the most part, the real source of confusion is figuring out the order of operations. what happens when, in what circumstances, in what order Jan 23 18:00:30 s/ofile/file/ Jan 23 18:00:36 IMO anyway Jan 23 18:03:52 Using a global local.conf has its uses. My use case is a feature build, which only consitutes of changing the image packages and some distro features. Being able to plug this config changes into local.conf saves the layers from having to be branched out into feature branches. Jan 23 18:06:12 hi, i'm trying to add systemd init in my image.bb using: DISTRO_FEATURES_append = " systemd" and VIRTUAL-RUNTIME_init_manager = "systemd". However after build the image my system is not booting using systemd. Do I need any other variables to my image.bb ? Also, do I need to remove my tmp/ cache? sstate-cache/ or tmp-glibc/ and start from scratch again? Jan 23 18:09:12 ferlzc: I see in my distro that I use DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" as well in addition to VIRTUAL-RUNTIME_initscript="" (with comment that might not be needed any more) Jan 23 18:13:10 thanks, I will check that Jan 23 18:14:50 you can't change distro features ain an image Jan 23 18:14:54 well, you can, but it wont do anything Jan 23 18:15:44 oh, yeah, good catch :p Jan 23 18:44:39 Is there a list of steps somewhere for switching completely away from busybox to coreutils, etc.? It seems to be mentioned in VIRTUAL-RUNTIME overrides, etc. Jan 23 19:27:51 should do_populate_sdk honor ASSUME_PROVIDED? I have nativesdk-perl in ASSUME_PROVIDED, but it fails to install nativesdk-autoconf due to unresolved dependency Jan 23 19:30:52 are these all supported distributions as of thud? https://yoctoproject.org/docs/current/ref-manual/ref-manual.html#detailed-supported-distros Jan 23 19:45:15 Hello, quick question about the tzdata package. How can I set the default timezone? I see the recipe has a variable DEFAULT_TIMEZONE ?= "Universal". Do I have to append this recipe to modify that variable, or is this something I could overwrite from the distro.conf or local.conf? Jan 23 19:46:35 New news from stackoverflow: Ca't install my own syslog's syslog-startup.conf via Yocto Jan 23 19:49:34 huh, dataclasses are pretty cool Jan 23 19:54:35 denix: ASSUME_PROVIDED only works for bitbake dependencies, if you were to specify a runtime dependency (which nativesdk- effectively is) the package manager will still be looking for it Jan 23 19:55:55 denix: note that we had a special trick for keeping perl out of the buildtools (nativesdk-buildtools-perl-dummy), maybe you can use that in your case? Jan 23 19:56:47 denix: (note the SDK_PACKAGE_ARCHS += bit in buildtools-tarball.bb, that is required to get that to work) Jan 23 19:57:19 robbawebba: no, you could set that at the configuration level (since it's ?= ) Jan 23 19:58:26 bluelightning: thanks! Jan 23 20:01:27 are these all the supported distributions for thud? https://yoctoproject.org/docs/current/ref-manual/ref-manual.html#detailed-supported-distros Jan 23 20:02:29 i thought i saw a list of supported distros as a function of version somewhere Jan 23 20:05:59 RP: http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278278.html Jan 23 20:06:22 this was a long standing change I wanted to do, finally gcc 9 tipped me over to do it Jan 23 20:06:42 RP: all my local tests seems to have no regressions on qemuarm Jan 23 20:06:44 and rpi3 Jan 23 20:06:48 give it a shot Jan 23 20:12:45 yates: hmm, this looks out of date Jan 23 20:13:27 bluelightning: thanks. the strange thing that is used to work on rocko and before... Jan 23 20:14:53 denix: I'm not sure how it could have, it certainly wasn't intended to Jan 23 20:15:08 bluelightning: yeah, that's what i thought. fedora 26 is pretty old Jan 23 20:15:36 yates: here's the list that drives the warnings on startup at least: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf?h=thud#n66 Jan 23 20:15:53 updates to the manual are *supposed* to be driven from that Jan 23 20:16:22 cool Jan 23 20:16:27 that is from thud? Jan 23 20:16:36 yes, i see it in the url Jan 23 20:16:37 that's what we have in thud Jan 23 20:16:53 thanks Jan 23 20:17:44 who is Poky? :) Jan 23 20:18:03 i know, it's rburton_ in disguise! Jan 23 20:22:31 time to dig out the poky beaver costume :D Jan 23 20:26:18 I've emailed Scott R about updating the manual, FWIW Jan 23 20:31:24 bluelightning: you are fast as lightning! ... Jan 23 20:50:38 yates: heh... I'm actually a world class procrastinator a lot of the time :D Jan 23 20:56:10 bluelightning: thanks for the nativesdk-buildtools-perl-dummy.bb pointer! I've modified my sdk with it and making progress - have to extend DUMMYPROVIDES with tons of nativesdk-perl-module-* to satisfy nativesdk-autoconf... Jan 23 20:57:52 denix: right, for that it would need extending; buildtools was a pretty simple case Jan 23 20:59:22 bluelightning: specifying just nativesdk-perl-modules didn't work, have to list them individually... Jan 23 21:01:51 denix: right, since those are the dependencies you have to satisfy, there's not an actual dependency on nativesdk-perl-modules Jan 23 21:02:09 the other side of the equation :) Jan 23 21:02:53 yeah, runtime dependencies are picky... :) Jan 23 21:24:49 ok, had to list 18 perl modules in DUMMYPROVIDES Jan 23 22:39:20 denix: might be worth using a script or something to generate the provides based on the perl manifest Jan 23 22:50:48 you can write it in python ; ) **** ENDING LOGGING AT Thu Jan 24 02:59:56 2019