Wednesday, 2018-06-06

*** bavery_fn <bavery_fn!~bavery@> has quit IRC00:05
*** georgem <georgem!~georgem@> has quit IRC00:14
*** georgem <georgem!~georgem@> has joined #yocto00:15
*** anujm <anujm!~anujm@> has joined #yocto00:27
*** nighty- <nighty-!> has joined #yocto00:43
*** learningc <learningc!> has joined #yocto00:46
*** martinkelly1 <martinkelly1!> has quit IRC00:51
*** learningc <learningc!> has quit IRC00:53
*** learningc <learningc!> has joined #yocto00:54
*** learningc <learningc!> has quit IRC00:56
*** learningc <learningc!> has joined #yocto00:57
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto01:09
*** kaspter <kaspter!~Thunderbi@> has joined #yocto01:17
-YoctoAutoBuilder- build #1037 of nightly-mips-lsb is complete: Failure [failed BuildImages_1] Build details are at
*** sno <sno!> has quit IRC01:31
-YoctoAutoBuilder- build #1139 of nightly is complete: Failure [failed] Build details are at
*** clement_ <clement_!> has quit IRC01:48
*** clement_ <clement_!> has joined #yocto01:49
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC01:55
*** kaspter <kaspter!~Thunderbi@> has quit IRC01:56
*** kaspter <kaspter!~Thunderbi@> has joined #yocto01:59
*** warthog9 <warthog9!> has joined #yocto02:40
*** warthog9 <warthog9!> has quit IRC02:52
*** dreyna <dreyna!> has quit IRC03:00
*** majuk <majuk!> has quit IRC03:03
*** majuk <majuk!> has joined #yocto03:03
*** majuk <majuk!> has quit IRC03:08
*** warthog9 <warthog9!> has joined #yocto03:12
*** bavery_fn <bavery_fn!~bavery@> has joined #yocto03:32
*** warthog9 <warthog9!> has quit IRC03:33
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC03:34
*** bavery_fn <bavery_fn!~bavery@> has quit IRC03:34
*** dlan <dlan!~dennis@> has joined #yocto03:35
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto03:35
*** warthog9 <warthog9!> has joined #yocto03:44
*** agust <agust!> has joined #yocto04:17
*** sno <sno!> has joined #yocto04:21
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto05:00
*** kaspter <kaspter!~Thunderbi@> has quit IRC05:01
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC05:02
*** CoLa|work <CoLa|work!~cordlandw@> has joined #yocto05:09
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC05:15
*** behanw <behanw!uid110099@gateway/web/> has quit IRC05:28
*** ariel <ariel!~quassel@> has joined #yocto05:40
*** desert <desert!~quassel@> has quit IRC05:40
*** pohly <pohly!> has joined #yocto05:47
*** jmtt <jmtt!~jmtt@2601:1c0:6a00:8a30:d353:600c:82e0:9c5c> has quit IRC05:48
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto05:59
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has quit IRC06:17
*** fitzsim <fitzsim!> has quit IRC06:25
*** t0mmy <t0mmy!~tprrt@> has joined #yocto06:28
*** Bunio_FH <Bunio_FH!~bunio@> has joined #yocto06:46
*** lfa <lfa!~lfa@> has joined #yocto06:48
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto06:56
*** Bunio_FH1 <Bunio_FH1!> has joined #yocto07:00
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC07:00
*** fl0v0 <fl0v0!> has joined #yocto07:00
*** Bunio_FH <Bunio_FH!~bunio@> has quit IRC07:01
*** Kakounet <Kakounet!> has joined #yocto07:05
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto07:07
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC07:12
*** rajm <rajm!~robertmar@> has joined #yocto07:14
*** diego_r <diego_r!> has joined #yocto07:18
*** behanw <behanw!uid110099@gateway/web/> has joined #yocto07:22
*** mckoan|away is now known as mckoan07:23
*** marble_visions <marble_visions!~marble_vi@> has quit IRC07:43
*** marble_visions <marble_visions!~marble_vi@> has joined #yocto07:44
*** varjag <varjag!> has joined #yocto07:53
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:103c:8119:fc4:f434> has joined #yocto08:00
*** skz81 <skz81!> has joined #yocto08:00
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:103c:8119:fc4:f434> has quit IRC08:02
*** anujm <anujm!~anujm@> has quit IRC08:29
*** kaspter <kaspter!~Thunderbi@> has joined #yocto08:42
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC08:44
*** anujm <anujm!~anujm@> has joined #yocto08:51
*** gondor <gondor!> has joined #yocto09:21
gondorhi everybody09:21
gondorwhat is the mechanism for adding a .conf file in /etc/modules-load.d/ directory, file which should have a 1 per line list of modules?09:21
rburtonwrite a recipe which builds a package that contains that file09:22
gondorKERNEL_MODULE_AUTOLOAD will create 1 .conf file there per entry09:22
gondorso can't use an existing yocto mechanism at this point?09:22
gondorthe yocto docs say:09:26
gondorSpecify it as follows:09:26
gondor     KERNEL_MODULE_AUTOLOAD += "module_name1 module_name2 module_name3"09:26
gondorIncluding KERNEL_MODULE_AUTOLOAD causes the OpenEmbedded build system to populate the /etc/modules-load.d/modname.conf file with the list of modules to be auto-loaded on boot. The modules appear one-per-line in the file.09:26
gondorit's not clear from this snippet if the build system will create 1 file including these 3 entries, one per line, or 3 files with one entry per line09:27
gondorbut by experimenting it seems that yocto does the last one09:28
rburtondoes it matter?09:30
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto09:32
gondoryeah, I need a .conf file in /etc/moudles-load.d/ in which I specify a list of modules, and by this the listed modules will be loaded in the given order09:33
gondorI need some kernel modules to be loaded in a particular order09:33
*** alinucs <alinucs!> has joined #yocto09:34
gondorlooks like I'll have to stick with adding the file through a recipe as you suggested09:35
gondorwould have preferred to use the yocto AUTOLOAD mechanism though09:35
*** nighty- <nighty-!> has quit IRC09:38
*** kaspter <kaspter!~Thunderbi@> has quit IRC09:55
*** kaspter <kaspter!~Thunderbi@> has joined #yocto09:56
*** sjolley <sjolley!~sjolley@> has quit IRC10:04
*** richardgolledge <richardgolledge!~richardgo@> has quit IRC10:12
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto10:13
RPkanavin: - any ideas why that could break like that?10:15
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto10:15
*** mckoan is now known as mckoan|away10:26
RPrburton: deciding to add in the mesa upgrade was a disaster, sorry :(10:27
*** lukma <lukma!> has quit IRC10:27
rburtonmesa is great at pain :)10:27
RPrburton: still one mystery selftest regression to isolate too10:27
RPrburton: and the gitsm patch broke, again. I've replied on list about that10:28
rburtonRP: re my qemu patches on top of martin's, you just want the middle two in my branch to fix up the local.conf and packagegroups10:29
rburtonRP: i'll push the needed fixes to meta-mingw now10:29
RPrburton: don't I have those?10:31
rburtondunno haven't looked at next ;)10:32
rburtonone sec rebasing10:32
rburtonRP: drop '2018-06-05 13:49 Ross Burton                              o qemu: only build SDL UI if X11 is enabled'10:32
RPrburton: ok10:35
RPrburton: I've updated the branch and sent that staticdev fix10:37
*** sjolley <sjolley!~sjolley@> has joined #yocto11:00
*** Bunio_FH1 <Bunio_FH1!> has quit IRC11:00
*** Bunio_FH <Bunio_FH!~bunio@> has joined #yocto11:02
*** warthog9 <warthog9!> has quit IRC11:04
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has quit IRC11:25
*** nayfe_ <nayfe_!a5e14c82@gateway/web/freenode/ip.> has joined #yocto11:25
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto11:31
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has quit IRC11:32
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto11:33
*** lfa <lfa!~lfa@> has quit IRC11:33
*** Kakounet <Kakounet!> has quit IRC11:33
*** lfa <lfa!~lfa@> has joined #yocto11:34
*** aratiu <aratiu!~adi@> has quit IRC11:45
*** aratiu <aratiu!~adi@> has joined #yocto11:46
*** slips <slips!> has quit IRC11:47
*** slips <slips!> has joined #yocto11:52
*** lukma <lukma!> has joined #yocto11:57
yoctiNew news from stackoverflow: Yocto: oe_runmake failed, iMX6 Apalis <>12:06
*** droman <droman!> has joined #yocto12:06
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto12:08
sveinseWhen is the next yocto release scheduled?12:12
sveinseWill Qt 5.11 be a part of any yocto release any time soon?12:12
nayfe_sveinse: maybe ask directly ?12:15
rburtonsveinse: "yocto" doesn't release.  oe-core is on a six-monthly schedule.  as for meta-qt5 you'll want to ask the meta-qt5 maintainers directly (or send a patch)12:15
nayfe_as rburton says :)12:15
JaMasveinse: 5.11 is already in meta-qt5/master for couple months12:16
JaMawith the final revision in jansa/master currently12:16
*** nighty- <nighty-!> has joined #yocto12:20
*** rubdos <rubdos!> has quit IRC12:20
*** Kakounet <Kakounet!> has joined #yocto12:28
otavio[m]RP: hello. We found that bitbake 1.38 branch did not update it's version. It still shows 1.3712:32
*** rubdos <rubdos!> has joined #yocto12:35
RPotavio[m]: oops. Fixed12:35
otavio[m]RP: I am checking mesa error too12:37
RPotavio[m]: thanks12:37
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto12:55
*** behanw <behanw!uid110099@gateway/web/> has quit IRC13:00
sveinserburton: Isn't "rocko" or "sumo" a Yocto release?
*** marka <marka!~masselst@> has joined #yocto13:01
*** RyFa <RyFa!> has joined #yocto13:08
varjagdear people, what's the canonical way to rebuild an image after you change/rebuild the kernel?13:09
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC13:13
RyFaMy guess would be to remove the tmp and rebuild - but im pretty new to the project. Id love to hear someone confirm that13:15
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto13:16
RyFaIm also trying to udate the kernel for my image13:16
*** WillMiles <WillMiles!> has joined #yocto13:18
varjagRyFa: that's what i've been doing, but it takes half a workday initially13:26
varjagthen i tried bitbake -c cleanall the image, and then bitbake it again13:27
varjagbut it fails complaining some cryptodev module missing13:27
RyFaYeah, Initial builds take a super long time unfortunately, but for a major change such as a kernel, id expect it to be necessary.13:29
RyFaDo you happen to get that same error in every case?13:29
varjagthat's not a major change13:29
varjagto generate an image13:29
varjagit's not like i was rebuilding the host toolchain13:30
varjagyeah same13:30
varjagguess i go bug our vendor with this13:30
RyFado oyu have a cryptodev recipe somewhere in your project?13:31
varjagnot me13:31
RyFacheck this out:
varjagbut it's yocto, so billion of the vendor layers mixed13:31
RyFayou may be able to add one based on this13:31
varjagmm thanks i'll look at this13:32
varjagbut it builds fine from clean state with the same recipe, that's what is strange13:32
*** sno <sno!> has quit IRC13:34
*** sno <sno!> has joined #yocto13:36
RyFahhm yeah - its beyond my knowledge13:36
markathere is no reason to kill tmp when you change the kernel13:37
markaI am not sure what you are observing but everything should just work13:38
*** gondor <gondor!> has quit IRC13:38
markaeven doing something like 'bitbake virtual/kernel -c menuconfig' will invalidate the necessary stamps which will then rebuild what needs to be rebuilt when you bitbake your image again13:39
varjagha.. does it have to be virtual/kernel?13:40
varjagbecause i am rebuilding the vendor package name13:41
markaI use virtual/kernel as it saves me having to figure out what kernel is in play13:41
varjagbitbake linux-variscite..13:41
varjagbitbaking this one does not invalidate the cache13:41
*** bavery_fn <bavery_fn!bavery@nat/intel/x-qatogafhrqxkiktz> has joined #yocto13:41
varjagif i bake image it runs no tasks13:41
markathen your image is not using this kernel13:42
varjagdoubt it, the changes i did in the kernel tree show up in sysfs13:42
markaif you are changing linux-variscite and then rebuilding your image and no tasks are run13:44
markathen there is no dependency in the image on linux-variscite13:44
*** stephano <stephano!> has joined #yocto13:44
markado 'bitbake <your_image> -e | tee outme'13:45
markathen 'grep PREFERRED_PROVIDER_virtual/kernel outme'13:45
markaif virtual/kernel is not linux-variscite then it is just a clinger13:46
varjagmarka: i .bbappended varistite recipe to use my repo with the set of device drivers i need13:46
varjagand when i build it from clean state, the drivers show up with node names i assigned13:46
varjagok i'll look into that..13:47
mario-goulartHey marka.  Sorry, I hadn't seen your messages here yesterday.13:47
markamario-goulart: no problem13:47
markavarjag: check that your image doesn't just have linux-variscite as an RDEPENDS but it actually properly being defined as the kernel that should be used13:48
varjagok, i'll check, thanks13:49
markait is often worth the time to setup a "pure" yocto build with core-image-minimal and qemu-x86-64 to compare against13:50
markayou can setup a shared DL_DIR to save some time and disk space13:51
rburtonsveinse: rocko/sumo/etc are oe-core and poky releases13:53
kanavinRP: no idea, have never seen this kind of checksum failure before14:03
kanavinRP: "libgstfft-1.0-0-1.14.0-r0.0.core2_64: sha256 check failed: 36b24cf863c232197c9660029fb5590665a86023b32f17d5a2d000e5c0e7e1c1 vs 178f1e86a46fe8457d768d65d0b3cdaa0022611705af7fb89131bf6f5a54c357"14:03
kanavinRP: one possibility is that the package files got overwritten somehow between creating the repo index and making a rootfs with it, but that's not supposed to happen14:04
*** varjag <varjag!> has quit IRC14:08
RPkanavin: indeed. I don't understand it14:09
RPkanavin: another question since you're here :)14:09
kanavinRP: I am transitioning to 'kanavin_home' nickname :)14:10
kanavinbut so far, this one still works :)14:10
RPkanavin: I can use either :)14:10
RyFaSo, I recently upgraded my project from Pyro to Sumo, and updated my specified kernel from 4.10 to 4.14 and now Im getting some new errors with my linux modules during the do_rootfs stage of the build. An examle error reads: "- nothing provides kernel-module-gobiserial-4.14.30-yocto-standard needed by linux-mod-gobiserial-2.28-r0.genericx86_64" Any ideas how I should address this?14:10
*** agust <agust!> has quit IRC14:10
RPkanavin: error: %preun(shadow-4.2.1-r0.0.core2_64) scriptlet failed, exit status 127 - is there somewhere I can get more info about that?14:11
kanavinRP: yes, should be 'ERROR: Logfile of failure stored in: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/temp/log.do_rootfs.39609'14:12
RPkanavin: no more info in there14:13
kanavinRP: you probably need this patch:
kanavinRP: but it's already in master I think :/14:15
RPkanavin: I think that was already in that build, yes14:16
kanavincan you share that log then? at least for postinsts it should print a line by line trace of their execution, and I believe the same should happen for postuns14:17
kanavinor preuns14:17
*** agust <agust!> has joined #yocto14:24
kanavinRP: 'NOTE: Running /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/recipe-sysroot-native/usr/bin/rpm -e -v --nodeps --root=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs base-passwd update-rc.d run-postinsts shadow'14:25
kanavinRP: this de-installation is not handled through dnf, but through rpm directly, and so extra verbosity is not in effect14:25
kanavinRP: don't remember right now where in or that happens14:25
RPkanavin: ah, we should perhaps try and improve that if we can then...14:26
kanavinRP: yes, certainly. It's not hard, just add the necessary command line switch to rpm invocation. I can't do this right now though.14:27
RPkanavin: do you know what the switch is offhand?14:28
kanavinRP: -v, or maybe even -vv :) just looked up in the manpage14:29
kanavinah, -v is already there14:29
kanavin-vv then14:29
RPkanavin: thanks, lets see if I can add debugging assume it reproduces14:31
kanavinRP: "            args = ["-e", "-v", "--nodeps", "--root=%s" %self.target_rootfs]" in package_manager.py14:31
RPkanavin: thanks :)14:32
*** majuk <majuk!> has joined #yocto14:35
RPkanavin: would you believe this isn't much more helpful :(14:38
kanavinRP: :-(14:39
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC14:41
*** learningc <learningc!~User@> has joined #yocto14:45
*** mrk377 <mrk377!442d9918@gateway/web/freenode/ip.> has quit IRC14:47
kanavinRP: try -d. Just reading source code for rpm, man page is not helpful :)14:48
kanavinRP: ah, wait14:49
*** Bunio_FH <Bunio_FH!~bunio@> has quit IRC14:56
*** anujm <anujm!~anujm@> has quit IRC15:00
*** rcw <rcw!~rcw@> has joined #yocto15:01
kanavinRP: note that both prerm scripts fail, and they're different. It's as if they don't even begin to execute.15:03
*** nayfe_ <nayfe_!a5e14c82@gateway/web/freenode/ip.> has quit IRC15:03
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto15:05
*** rcw <rcw!~rcw@> has quit IRC15:06
*** AbleBacon <AbleBacon!~AbleBacon@unaffiliated/ablebacon> has joined #yocto15:06
*** rcw <rcw!~rcw@> has joined #yocto15:06
kanavinRP: maybe we're best off bisecting this? It certainly used to work, didn't it?15:07
RPkanavin: I can start reverting things to try and track it down, in theory its a problem in -next. I just don't like the lack of logs15:07
kanavinRP: I guess that's the most we can get out of rpm :-/15:08
RPfray: any ideas on getting more info from rpm preun?15:09
RPkanavin: shadow preun only calls update-altnatives afaict too15:09
*** Bunio_FH <Bunio_FH!~bunio@> has joined #yocto15:09
kanavinRP: I remember I had to insert ad hoc logging into rpm for some issues. They can print lots of irrelevant stuff, then when things break, critical pieces of info are missing.15:14
*** comptroller <comptroller!> has joined #yocto15:16
*** Bunio_FH <Bunio_FH!~bunio@> has quit IRC15:17
*** cfriedrich <cfriedrich!> has quit IRC15:18
RPkanavin: I'm not surprised :(15:20
*** droman <droman!> has quit IRC15:22
*** diego_r <diego_r!> has quit IRC15:23
*** diego_ <diego_!> has joined #yocto15:23
kanavinRP: let me try another idea, wait a moment15:24
* armpit the joys of backporting spectre15:25
kanavinRP: no, false lead. Something breaks down before shell executes actual lines, I believe15:30
*** rcw <rcw!~rcw@> has quit IRC15:36
*** rcw <rcw!~rcw@> has joined #yocto15:36
*** clement <clement!> has quit IRC15:36
*** clement_ is now known as clement15:36
frayfor the rpm preun, you can inject some script stuff into the rpm macros (something that is run prior to the execution of the script....15:38
fraybut if the preun fails, then the scriptlet that failed will remain on the disk int he tmp location as well..15:39
frayso if you are debugging a failure, you don't have to do anything else.. if you are debuggign a 'success', then you can muck with the RPM parameters to say add 'set -x'15:39
*** jcstach <jcstach!~jcstach@> has quit IRC15:41
*** warthog9 <warthog9!> has joined #yocto15:44
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC15:49
RPkanavin: that would match the 127 exit code15:52
*** jcstach <jcstach!> has joined #yocto15:54
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto15:56
*** mihai- is now known as mihai15:58
*** scottrif <scottrif!> has joined #yocto15:59
*** gabrbedd <gabrbedd!> has joined #yocto16:02
kergothRP: any objection to adding the oe-core date-based yocto release tags to the version matrix in the Releases wiki page alongside the bitbake version? The mapping from poky release to oe-core release is unclear, currently.16:06
RPkergoth: no16:07
*** fl0v0 <fl0v0!> has quit IRC16:07
RPrburton, kanavin: I reproduced that failure on centos7 with master, so its nothing in -next16:08
RPwhich is good and bad16:08
*** Kakounet <Kakounet!> has quit IRC16:08
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto16:11
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto16:13
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC16:18
*** skz81 <skz81!> has quit IRC16:19
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto16:20
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC16:21
*** skz81 <skz81!> has joined #yocto16:22
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto16:23
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto16:25
*** learningc <learningc!~User@> has quit IRC16:28
khemRP: thats the gcc8 SDK output when someone specifies -mspe16:29
*** igor <igor!bb6c2acb@gateway/web/freenode/ip.> has joined #yocto16:29
RPkhem: can you build gcc with spe enabled though?16:29
RPkhem: that is no longer possible at all?16:30
igorhi guys, how can I build an ISO image?16:30
khemthe backend is different now16:30
khemwe need to add another tuple to supported machines16:30
igorI set IMAGE_FSTYPES = "iso hddimg", but it is building only hddimg16:30
igoron log.do_bootimg I saw that INITRD is not set16:31
igorso I tried to set INITRD = "${INITRD_LIVE}", but it did not work16:31
igorso, there is a default initramfs to put on INITRD var to build a iso?16:32
RPkhem: I still think there may be a problem lurking in there, I'm having trouble explaining it though :/16:32
khemigor: meta/conf/machine/include/ ?= "1" you need to set NOISO = "0"16:32
igorThank you very mutch Khem16:33
* RP thinks NOISO needs to die in favour of IMAGE_FSTYPES16:33
khemRP: a subset of freescale ppc impl used SPE newer PPC impls from them has altivec16:33
rburtonRP: yes, that burnt me recently too16:33
khemRP: so older ppc from freescale is primarily what uses spe16:34
khemthe newer ones they dont have spe and thats also probably one reason there is no interest in maintaining it upstream16:34
RPkhem: we don't have any machines in core which use spe right?16:35
khemI think our ref board is can you tell me the name :(16:35
igoranother question: I build a tar.bz2 image and inherited core-image. when I ran bitbake -e I see that image-live are included and bootimg task are executing16:35
RPrburton, kanavin: 762a3f229c42b734160334fb462beaf576353a58 breaks, 6db8b6a77723f1e3a34d61ffd96c196e03ace164 does not16:35
igorI put a deltask bootimg on my recipe because I didnt found how to remove image-live from inherited classes16:36
igorthere is a better way to do that or deltask is the best option?16:36
RPigor: bootimg isn't a task, its a class16:36
igoron branch sumo it is a task on image-live called do_bootimg16:37
igorit runs build_hddimg and build_iso16:37
RPigor: hmm, I see what you mean. I think that task is needed as part of image-live16:37
igorbut my image is tar.bz2 and dont need this16:38
RPigor: what do you have IMAGE_FSTYPES set to?16:38
igorIMAGE_FSTYPES = "tar.bz2"16:38
RPigor: can you check that with bitbake -e ?16:39
igoron bitbake -e , the build_live function is returning empty string, but the image-live class still include in BBINCLUDED16:40
RPrburton, kanavin: This is looking like as the change which breaks it :/16:40
RPigor: that seems odd :(16:41
RPigor: you're not trying to do this in individual images are you?16:41
igorRP: #   "tar.bz2" IMAGE_FSTYPES="tar.bz2"16:41
khemRP: our ref board in core is mpc8315erdb which is e300c3 core which is implementing proper FPU and doesnt have SPE AFAICT16:42
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC16:42
rburtonfwiw i've an image recipe that does successfully build just a targz16:42
igorRP: but when I see the var BOOTIMG_EXTRA_SPACE for example, it was set by image-live.bbclass16:42
khemrburton/RP: is it possible for you to boot a gcc8 image on a ref board16:42
igorand other vars too16:43
rburtonkhem: i've a nuc16:44
RPrburton: would be interesting to know if it still inherited the class though...16:44
igori'm on branch sumo, and few days ago, I had a error to build this image because do_bootimg has the dependency ${PN}:do_image_ext4 and I have no ext on my IMAGE_FSTYPES16:45
igorit was fixed few days ago, but the task do_bootimg sill added16:46
igorbut I solved this problema putting deltask bootimg on my recipe16:46
*** diego_r <diego_r!> has joined #yocto16:46
rburtonRP: it isn't16:46
*** diego_ <diego_!> has quit IRC16:46
RPSaur: around?16:47
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC16:48
*** rajm <rajm!~robertmar@> has quit IRC16:51
RPfray: does anything jump out to you in as causing that preun problem?16:55
fraythe setCloseOnExec will certainly change behavior.. but this would only be a problem if the script was being passed to the receiver inline or something16:57
fraylua change, as far as I know we're not using lua in any preuns16:57
fray++open_max = sysconf(_SC_OPEN_MAX);16:57
fray++if (open_max == -1) {16:57
fray++open_max = 1024;16:57
fray++for (fdno = 3; fdno < open_max; fdno++) {16:57
fray++flag = fcntl(fdno, F_GETFD);16:57
fray++if (flag == -1 || (flag & FD_CLOEXEC))16:57
fray++fcntl(fdno, F_SETFD, FD_CLOEXEC);16:57
frayOhhh.. this would be closing pseudo stuff too...16:57
fraycould that be causing a problem?16:58
RPfray: yes, that could16:58
fraysecond patch file changes the above, but conceptually it's still doing the same thing16:59
*** gtristan <gtristan!~tristanva@> has joined #yocto16:59
frayalso iterates over /proc -- but proc will be able to see the pseudo fds17:00
frayso ya.. it's likely breaking the connection on exec with pseudo -- but I don't know the exact ramifications of that17:00
*** igor <igor!bb6c2acb@gateway/web/freenode/ip.> has quit IRC17:00
fray(and it's breaking them cause it's blindly adjusting -all- fds, not just the ones that rpm itself created)17:00
RPfray: I wonder if the "+x" bit disappears on the script17:01
frayas in set +x?17:01
frayor execute17:01
RPfray: execute17:01
RPhence the exit 12717:01
frayscriptlets SHOULD be executed as 'interpreter <script>'17:01
*** tgraydon <tgraydon!~textual@> has joined #yocto17:02
frayif you are getting 127, that seems an aweful lot like the interpreter failed17:02
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto17:02
fraygoing to look quick to verify what I said is still true17:02
fray(this master?)17:02
fraythere is also the code:17:04
fray+           if (getenv("RPM_NO_CHROOT_FOR_SCRIPTS") != NULL) {17:04
fray+               rpmChrootOut();17:04
fray+               rc = runExtScript(plugins, prefixes, script->descr, lvl, scriptFd, &args, script->body, arg1, arg2, &script->nextFileFunc);17:04
fray+               rpmChrootIn();17:04
frayso that will affect where the scriptlet is trying to run, as well as the script engine17:04
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC17:04
*** diego_r <diego_r!> has quit IRC17:05
RPfray: yes, this is master17:05
frayso ya.. I'd say the first thing to try is disable the close all fds on exec thing..17:08
frayif that fixes the problem, then it's likely either pseudo or some other glibc thing17:08
fray(like nss...)17:08
*** mrk377 <mrk377!442d9918@gateway/web/freenode/ip.> has joined #yocto17:08
frayohh other thing..  rpm -qp <package> --scripts  take a look and verify the preun is reasonable.. ;)17:09
RPfray: I did read the spec file. What is odd is this works on some machines but not centos717:11
fraythat seems strange -- unless say '/bin/bash' (or /usr/bin/bash) is hardcoded into the scriptlet, and it's not hte interpretor on the running machine17:12
frayI think rpm -qp <...> --scripts will show you that17:12
RPfray: interestingly, #!/bin/sh is encoded in, and it isn't in the postinst17:13
fraypreinstall scriptlet (using /bin/sh):17:13
fray# base-files - preinst17:13
frayset -e17:13
fray    #!/bin/sh -e17:13
fray    if [ x"$D" = "x" ]; then17:13
frayya.. something like that..17:13
RPfray: this is shadow17:14
*** rcw <rcw!~rcw@> has quit IRC17:14
frayin the case I posted, /bin/sh is the script executor (and should be run directly), the contents 'set -e' was probably added by RPM itself..  and then #!/bin/sh -e was what OE provided as the scriptlet via the spec file17:14
fray(generated spec file)17:14
frayI can try to activate RPM and build shadow stuff...  I don't have any current builds that I found17:15
fray(BTW I am using CentOS 7 as well)17:16
RPfray: the reproducer is IMAGE_FEATURES += "read-only-rootfs"  bitbake core-image-sato on centos 717:16
frayok. I'll try that next once I get just shadow built and inspect it17:17
kanavin_homefray: RP: rpm should print each line of pre/post inst scriptlets as they are being executed, when debugging is enabled, and it isn't happening here17:19
fray'which debugging' are you referring to?17:20
frayRPM 4.x has a concept of verbose and silent on creating the packages..  only the scriptlet contents will be able to show you want it will actually do..17:20
frayby default though scriptlet output is silenced to /dev/null17:20
RPkanavin_home: I think some filehandle is disappearing so it isn't running anything17:20
kanavin_homefray: '-vv' when installing or removing packages17:21
*** rcw <rcw!~rcw@> has joined #yocto17:21
fraypreuninstall scriptlet (using /bin/sh):17:21
fray# shadow - prerm17:21
frayif [ "$1" = "0" ] ; then17:21
frayset -e17:21
fray        update-alternatives --remove  passwd /usr/bin/passwd.shadow17:21
fray        update-alternatives --remove  chfn /usr/bin/chfn.shadow17:21
fray        update-alternatives --remove  chsh /usr/bin/chsh.shadow17:21
fray        update-alternatives --remove  chpasswd /usr/sbin/chpasswd.shadow17:21
fray        update-alternatives --remove  vipw /sbin/vipw.shadow17:21
fray        update-alternatives --remove  vigr /sbin/vigr.shadow17:21
fray        update-alternatives --remove  nologin /sbin/nologin.shadow17:21
fraythat is what I got..  which all seems reasnable17:21
RPfray: note how it starts with #!/bin/sh where as the postinst doesn't17:22
frayya, doesn't matter17:22
fraythe 'using /bin/sh' is what should actually be invoked.. the other is simply an annotation.. and actually it starts with "# shadow - prerm"  ;)17:22
*** skz81 <skz81!> has quit IRC17:23
frayit should be the equivalent of:17:23
fraycat << EOF17:23
fray /bin/sh <file scriptlet was written to>17:24
fray(unless they've changed something I'm not aware of recently)17:24
RPfray: ok, curious if you can reproduce17:24
* fray is testing the task accounting.. it's still working.. :) only two fetches at once17:24
kanavin_homeRP: I do wonder if '    rpm: Restore performance in Docker containers' is the commit we're after17:28
fraymy guess is it is, and it's related to changing all file descriptions17:28
RPkanavin_home: bisection says yes17:31
kanavin_homeRP: that is a bit of a :-(17:31
kanavin_homeas I think those patches are direct backports from rpm upstream?17:32
RPkanavin_home: well, yes. Upstream don't have pseudo around for example though17:32
RPso I can at least see how this might break17:32
kanavin_homeRP: previously rpm blindly closed the first 1024 fds though and that worked for us. not sure what they changed so that it breaks now.17:33
kanavin_homeI guess we need to notify Peter17:33
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:4811:e8ec:aa33:10ab> has joined #yocto17:34
frayit didn't look like it blindly closed 1024 fds before.... it looks like this three patch series added that17:40
RPkanavin_home: unless pseudo uses high number fds for its own use?17:40
RyFaHey Folks, Ive been working through updating my project from Pyro to Sumo, and changing the kernel from 4.10 to either 4.12 or 4.14 - Im finally able to build my image but when it boots im getting "Kernel Panic Not Syncing... init not tainted 4.12.21-yocto-standard"17:40
fraythe third in the series adds the capability to look in /proc for the actual pids being used17:40
kanavin_homefray: it did17:40
frayso lets say it is a pid above 1024.. then it would now know it17:40
mrk377webserver question:  Using openembedded/webservers, what are recommendations in using either apache, cherokee, hiawatha, monkey, nginx, nostromo, or sthttpd?  I was wanting to use meteor and is there a recipe for meteor?17:41
kanavin_homefray: -       open_max = sysconf(_SC_OPEN_MAX);17:41
kanavin_home-       if (open_max == -1) {17:41
kanavin_home-           open_max = 1024;17:41
kanavin_home-       }17:41
kanavin_home-       for (fdno = 3; fdno < open_max; fdno++) {17:41
kanavin_home-           flag = fcntl(fdno, F_GETFD);17:41
kanavin_home-           if (flag == -1 || (flag & FD_CLOEXEC))17:41
kanavin_home-               continue;17:41
kanavin_home-           fcntl(fdno, F_SETFD, FD_CLOEXEC);17:41
kanavin_home-       }17:41
kanavin_home+       rpmSetCloseOnExec();17:41
frayI thought that was the second hunk17:42
frayI don't have the patch up on my screen anymore though17:42
frayjust re-read it.. you are right.. it was blindly closing before17:43
kanavin_homeRP: could well be. Just like I told you, that newly added /proc iteration code has *no* debugging whatsoever in it :(17:43
kanavin_homeso someone needs to add it ad hoc to see what is actually being closed17:43
frayI agree, I'd start with removing that patch..  (I'm stillb uilding on my CentOS 7 box..  DNF failed, but restarting fixed it.. there is definitely a race in it's makefile on large core machiens)17:44
kanavin_homefray: that will make Docker using people very unhappy, particularly Peter Kjellerstedt17:47
kanavin_homeis he here?17:47
*** martinkelly <martinkelly!> has joined #yocto17:47
frayya, but if it makes everyone else unhappy..  that's a valid tradeoff..17:49
frayok.. I got the failure on my CentOS box you guys are talking aobut..17:49
frayI'll start yanking RPM patches and see if it goes away.. (I assume running it a second time does not normallyf ix it)17:49
*** morphis__ <morphis__!> has joined #yocto17:53
fray...and ninja fails AGAIN to build DNF.. retry17:55
frayit always seems to fail the first time around, but always on different files.. :|17:55
frayI'm tempted to restrict DNF to a small number of build threads17:56
*** morphis_ <morphis_!> has quit IRC17:57
*** rcw <rcw!~rcw@> has quit IRC17:58
*** rcw <rcw!~rcw@> has joined #yocto17:59
*** denix is now known as darknighte18:03
*** darknighte is now known as denix18:04
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC18:04
frayI disabled the /proc stuff and it still failed..18:04
fraydisabling the Facctor-out-and-unify now18:04
*** tgraydon <tgraydon!~textual@> has quit IRC18:06
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC18:06
RPfray: the failure should be in do_rootfs18:07
frayyup.. thats where it failed18:07
RPfray: ok18:07
*** tgraydon <tgraydon!~textual@> has joined #yocto18:07
frayI removed the last 2 of the three patches and it still failed.. so I'm assuming it's either the 1st or something unrelated18:07
RPfray: note that there is a revert in the previous commit too18:08
RPfray: I bisected it to these two commits, I didn't test the midpoint (yet)18:09
RPfray: its useful to know its reproducible though, thanks18:13
RPthat midpoint is rebuilding lots so will take a while to test18:14
*** rcw <rcw!~rcw@> has quit IRC18:15
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto18:17
khemRP: looking more into it, I think we are at a cross road for ppc18:21
khemRP: it seems most of fsl ppc uses SPE except SoCS based on e6500 cores18:22
Crofton|workkhem, if no one steps up, we should drop it18:22
khemright now its holding gcc8 ransom18:22
Crofton|workalso, any suggetions on my FORTRAN problem :)18:22
khemdid you reply to my question18:23
RPCrofton|work: use a modern language ;-)18:23
* Crofton|work curses scipy18:23
Crofton|workkhem, yes18:24
khemRP: we can switch to using spe backend and that will give us most supported ppc machines we have but its a backend with no maintainers18:24
Crofton|workI find the gfile only18:24
RPkhem: right, someone should really step up who cares about ppc to do this...18:24
fraykanavin_home:  If I remove: #           file://0001-Factor-out-and-unify-setting-CLOEXEC.patch \18:25
frayand the two susbequent ones it now works..18:25
khemRP: minimum I can do is to enable -mno-spe option to be recognised with normal ppc backend so we can drop
khemthat will let people use gcc7 for ppc18:25
frayif I KEEP that one, and remove only the subsequent two it does NOT work18:25
frayso something is wrong in the refactoring18:25
Crofton|work[balister@prague build-pi]$ find ./tmp-glibc/ -name "libgfortran.spec*"18:26
khemWe folks who are interested in SPE can pin to gcc7 and we can move on18:26
khemCrofton|work: is it in sysroot of the package you are building18:26
Crofton|workah khem  really cares :)18:26
Crofton|worklook carefully18:27
Crofton|workI search all of tmp18:27
Crofton|workand only see .in version18:27
kanavin_homefray: the refactoring moved from hardcoding first 1024 fds to iterating over open ones in /proc/self/fd18:27
khemhmm if you enabled fortan in gcc then you should have had one18:27
kanavin_homeso probably they now close something they should now18:27
frayit's the patch 0001-Factor-out-and-unify-setting-CLOEXEC.patch18:28
frayif applied it failed18:28
frayI don't see any obvious reason why it would fail, or why the refactoring code is wrong18:28
khemCrofton|work: no way, I have no interest in ppc as all that 'We' is just to pretent inclusive18:28
fraythe 0001-Factor... patch seems straight forward though18:29
frayand it claimes to be accepted upstream in a newer version of RPM18:29
RPkhem: I'm trying not to spend all my time hacking but I'll try and run the test builds which will make me happier with the situation...18:29
fraythe only difference I see is:18:30
fray-       xx = fcntl(fdno, F_SETFD, FD_CLOEXEC);18:30
fray+               fcntl(fdno, F_SETFD, FD_CLOEXEC);18:30
fraywhich should not be a problem18:30
Crofton|workkhem exactly18:30
Crofton|workthe fortan binary is there, but no spec file is created18:31
kanavin_homefray: bizarre, it doesn't seem to actually change the code?18:32
khemCrofton|work: do you have libgfortan built ?18:32
khemRP: I can switch to using powerpcspe backend as well, I wonder if we have non fsl ppc users18:33
khemthey will be at a loss18:33
Crofton|workapparently not18:33
fraykanavin_home agreed.. but it doesn't work with the patch, and does work with it (on my system)18:33
khemRP: may be we can switch to this backend and then it will be deleted in gcc9 and we punt it too, that will be like a 1 year warning18:34
fraymakes me suspicious that the code is doing something odd.. or we have two libraries that now carry the same named function or.... some kind of hidden conflict18:34
kanavin_homefray: are you super-sure though? maybe you mixed up the patches18:34
Crofton|workDEPENDS = "gcc-runtime"18:35
frayno.. I yanked them one at a time from the openembedded-core/meta/recipes-devtools/rpm/rpm_4.14.1.bb18:35
frayI can repeat it..18:35
khemso what are folks doing with github repositories, migrating to gitlab :)18:36
frayI just enabled the 0001- patch (and only that) and I'm building again.. will probab be 5-10 mins18:36
RPfray: I'm trying that too, see if I can confirm18:36
Crofton|workkhem, thanks18:36
Crofton|workI owe you a coke18:36
frayahh I have this run already in the sstate-cache.. so it might take less time18:37
khemCrofton|work: I like the columbian one ;)18:37
* kanavin_home lives under a rock, what's the problem with github?18:38
frayyup.. failed when I re-enabled the patch18:38
khemCrofton|work: is based on OpenEmbedded why dont we add this to front page18:39
fraygithub will soon be owned by Microsoft.. apparently that makes a difference to some18:39
Crofton|workand gitlab is hosted on Azure I hear18:39
frayI'll care about github when MS screws it up.. until then, whatever..18:39
frayI didn't care about sourceforge until they started to put ads and intersituals everywhere.. that was the end of me using them18:40
khemI think MS has embrased OSS after new CEO18:40
kanavin_homekhem: embraced in a way that benefits Azure mostly18:40
khemRP: I think I will take this approach then, switch to powerpcspe backend in gcc8 and if the backend goes away we punt ppc from core supported arches18:41
khemI already see it rotting. Last commit to this backend in gcc was on march 4th18:42
RPkhem: My worry is the shared single cross gcc powerpc binary for both spe and non-spe18:42
fraykanavin - I know in the past RPM has had some problems when functions moved from one librpm* to another... or in one case to a common file because suddenly it was implemented in 3 different libraries that were usually loaded at the same tiem..18:43
RPfray: confirmed, that patch does seem to break ot18:43
khemI am sure RP will be happy about github :)18:43
frayRP.. I'm not crazy then18:43
khemRP: cant stand on two boats anymore since they are diverging the route18:43
khemI think most of OE users of ppc are using fsl SoCs and that backend is going away18:44
RPkhem: I think you're right :(18:45
khemthe supported backend is nice but probbably not many users for OE18:45
RPkhem: this is what is worrying me18:45
khemso I guess best use for oe users would be to switch to use spe backend for gcc8 and if no one picks up maintaining it in gcc then it will be removed from gcc on gcc9 and so we should plan for same18:46
RPkhem: I think so18:48
khemOK let me redo the gcc8 patches for ppc portions18:48
khemthe arm tuning we can do as a seprate item lets not hold gcc8 for that18:49
fray   181: 000000000000fae0   119 FUNC    GLOBAL DEFAULT   11 rpmSetCloseOnExec18:50
fray   181: 000000000000fae0   119 FUNC    GLOBAL DEFAULT   11 rpmSetCloseOnExec18:50
fray   181: 000000000000fae0   119 FUNC    GLOBAL DEFAULT   11 rpmSetCloseOnExec18:50
fray   180: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND rpmSetCloseOnExec18:50
fray   180: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND rpmSetCloseOnExec18:50
fray   180: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND rpmSetCloseOnExec18:50
fraythat's readelf.. the function is defined in ALL THREE librpms..18:51
frayso likely it's going nuts18:51
frayno.. my mistake18:52
frayit's onluy defined in* which is correct18:52
frayok.. so I'm at a loss as to why it fails.. the only difference seens to be a functional call vs not18:53
*** kaspter <kaspter!~Thunderbi@> has quit IRC18:58
RPfray: compiler bug on centos7?18:58
*** kaspter <kaspter!~Thunderbi@> has joined #yocto18:58
RPfray: actually, take a look at doScriptExec() in rpmscript.c19:01
RPfray: the int xz19:01
RPer, xx19:01
*** rcw <rcw!~rcw@> has joined #yocto19:01
RPfray: what does that if (xx == 0) do?19:01
*** t0mmy <t0mmy!~tprrt@> has quit IRC19:01
*** tgraydon <tgraydon!~textual@> has quit IRC19:02
* RP tries deleting that19:05
*** rcw <rcw!~rcw@> has quit IRC19:06
*** rcw <rcw!~rcw@> has joined #yocto19:07
fraywhere do you see the if xx == 0?19:09
frayor are you just talking about xx = <something>  usually XX means ignore the result.. the linter that RPM uses requires functions w/ return codes to well accept a return code.. even if you later ignore it19:09
*** WillMiles <WillMiles!> has quit IRC19:10
frayya.. that definitely should be gone..19:12
fraycause xx will be undefined if the other setters don't work..19:12
frayif anything, i'd say the function be adjusted to return a similar return code and xx = rpmSetCloseOnExec() run19:13
fraybut that is probably not necessary19:13
frayalternative would be at the top of the function set xx = 0... since there are intermediate steps that set xx if they fail..19:13
fray(without of course checking porior xx if it'd been set)  ;P19:13
RPfray: well, if xx is meant to be ignored...19:14
frayi.e. this is a mess19:14
fraythats the thing, other parts of the code it's meant to be ignored..19:14
RPfray: yes, its very confused19:14
frayit LOOSK like if scriptFd == NULL, then the last XX will be from the setfd. otherwise it'll be from the Fclose19:14
frayI suspect the xx check is supposed to be from the Fclose.. but not sure.. (maybe git can tell me019:15
RPfray: fwiw it works with that patch19:15
RPso we at least know why it breaks19:15
RPkanavin_home: mystery partly solved :)19:16
frayok.. at the time that was originally written.. the LAST two 'xx' values were:19:16
fray+       xx = chdir("/");19:17
fray+       if (rpmtsSELinuxEnabled(ts) == 1) {19:17
fray+           xx = rpm_execcon(0, argv[0], argv, environ);19:17
fray+       }19:17
RPstill in upstream git
frayya.. my guess is that CentOS 7 doesn't zero 'xx'.. while newer glibc/gcc does19:17
fraythus the issue19:17
RPfray: yes, different compilers, different results19:17
fraybut I'd say this is a real bug that needs to be reported upstream.. and I think your change of removing the xx is the best fix..19:18
RPfray: agreed on both counts19:18
fraywith an alternative to set xx = 0 when defined at the top19:18
RPfray: I'll submit a pull request to remove it, see what is said19:19
kanavin_homeRP: fray: I don't get it, xx does seem to be uncoditionally assigned before it's accessed?19:24
kanavin_homexx = setenv("PATH", path, 1);19:24
*** [Sno] <[Sno]!> has joined #yocto19:25
kanavin_homeah wait, does the { } block create new scope in C?19:25
kanavin_homeif so, then reusing xx, and giving it a generic name in the first place is very silly indeed19:26
RPkanavin_home: there shouldn't be different scope there19:27
kanavin_homeRP: then I don't understand :)19:28
*** sno <sno!> has quit IRC19:28
kanavin_homexx is set (through assignment from setenv) before it's accessed19:28
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC19:29
RPkanavin_home: hmm. That is horrible code style.19:30
RPkanavin_home: I'm also confused now, as you say, it should get zeroed19:33
RPkanavin_home: I think its a gcc 4.8.5 compiler bug :(19:35
RPkanavin_home: {} does create scope but it shouldn't change xx here19:35
RPwell, it shoud19:35
RPkanavin_home: although looking at the compile logs on a more recent system it does warn about xx being potentially uninitalised so there is a compiler warning for it19:36
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:4811:e8ec:aa33:10ab> has quit IRC19:37
kanavin_homeRP: I'm trying to find an authoritative source on how such inner blocks behave19:37
kanavin_homeis it like a C function, and so only a 'copy' of xx is assigned to and then thrown away?19:38
RPkanavin_home: that is how it appears to behave...19:39
kanavin_homeRP: maybe I just quickly write a toy program to verify instead19:40
*** kaspter <kaspter!~Thunderbi@> has quit IRC19:41
*** kaspter <kaspter!~Thunderbi@> has joined #yocto19:42
*** khem <khem!~khem@unaffiliated/khem> has quit IRC19:43
RPkanavin_home: I'm mixing up the compiler warnings :/19:44
RPno, I'm not, the compiler error messages are broken due to inlining19:45
*** fitzsim <fitzsim!> has joined #yocto19:46
kanavin_homeRP: xx = setenv("PATH", path, 1); <----- does this actually set xx to something else than zero?19:47
kanavin_homeif it does, then the subsequent call doesn't happen19:47
RPkanavin_home: The setenv() function returns zero on success, or -1 on error, with errno set to indicate the cause of the error.19:48
kanavin_homeRP: yeah, then execv happens only if it's zero19:49
RPkanavin_home: ../../git/lib/rpmscript.c:209:5: warning: ‘xx’ may be used uninitialized in this function [-Wmaybe-uninitialized]19:49
RPkanavin_home: compiler seems to worry about this19:49
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto19:49
RPkanavin_home: we patch out that setenv19:51
JPEWFYI: -Wmaybe-uninitialized doesn't do static analysis, so it will complain even if code flow make is impossible for the variable to be used uninitialized19:51
kanavin_homeRP: !!!!!19:52
kanavin_homeRP: I guess I can have dinner now :)19:52
RPkanavin_home: the patch is from this Alex guy... ;-)19:53
*** voxadam <voxadam!~adam@fedora/voxadam> has joined #yocto19:54
kanavin_homeRP: yes, it occured to me that it's all my fault :) patching out a variable setting and not bothering to check where it's then used19:57
RPkanavin_home: makes a change from it being my fault. This code is horrible. I'm going to leave the pull request open, see what happens19:58
kanavin_homeRP:  'There are now ways this function can fail to set xx at all' isn't a correct claim though19:59
kanavin_homeRP: basically if you amend my patch, this should be sorted20:01
kanavin_homeeither set xx to zero where it was set from setenv, or not check it before execv20:02
*** pohly <pohly!> has quit IRC20:04
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC20:32
*** marka <marka!~masselst@> has quit IRC20:33
*** rcw <rcw!~rcw@> has quit IRC20:37
*** dreyna <dreyna!> has joined #yocto20:39
RPkanavin_home: agreed. I've cancelled it20:52
*** woglinde <woglinde!> has joined #yocto20:54
woglindewas there a special git login url for the yocto git?20:55
woglindefor developers of course20:57
RPwoglinde: special in what way?20:59
woglindethat I can push to the master branch of meta-java21:00
woglindeor maybe my ssh key was removed git://
RPwoglinde: ah, you may need to use ?21:01
woglindehm oh okay is that documented somewhere?21:01
RPwoglinde: not sure, halstead might21:02
halsteadwoglinde: I'm traveling so I missed the context. What's up?21:03
woglindeah okay21:03
woglindewill try with push21:03
woglindehm and found it now21:04
*** gtristan <gtristan!~tristanva@> has quit IRC21:05
*** gtristan <gtristan!~tristanva@> has joined #yocto21:06
woglindehm does not work either21:06
*** mcastillo_ <mcastillo_!~mcastillo@> has joined #yocto21:07
woglindehm ssh:// still works too21:08
woglindeand that worked for pushing21:09
*** uniqdom <uniqdom!~mcastillo@> has quit IRC21:09
woglindegood to have the emails from 4 years ago21:09
*** mcastillo__ <mcastillo__!~mcastillo@> has joined #yocto21:10
*** mcastillo_ <mcastillo_!~mcastillo@> has quit IRC21:12
halsteadwoglinde: that will work at the moment but not always. You might have proxy settings to update for the new URL.21:12
khemRP: so here is new patches
khemRP: addressed both ppc and arm tune issues21:13
khemppc change is booting qemuppc and testimage works too21:14
khemI am now building for rpi3 and see if I get gcc-runtime issue due to march/mcpu conflict21:14
*** mcastillo__ <mcastillo__!~mcastillo@> has quit IRC21:16
*** Bunio_FH <Bunio_FH!~bunio@> has joined #yocto21:27
*** tgraydon <tgraydon!~textual@> has joined #yocto21:38
*** uniqdom <uniqdom!~mcastillo@> has joined #yocto21:40
*** woglinde <woglinde!> has quit IRC21:45
*** mrk377 <mrk377!442d9918@gateway/web/freenode/ip.> has quit IRC21:53
armpithalstead, do you deal with patch queue ?21:56
* armpit we need to list who is admin for that21:57
* armpit needs sumo-master added for both core and meta-or21:57
RPkhem: that looks much better! :)21:57
RPkhem: have you talked to zeddii about the kernel patches?21:57
*** woglinde <woglinde!> has joined #yocto21:59
*** dc13ff <dc13ff!uid190567@gateway/web/> has joined #yocto22:05
RParmpit: list where? I think part of the trouble is the maintainers have changed but halstead should be able to help22:07
*** woglinde <woglinde!> has quit IRC22:08
armpitRP, a list of who has admin privileges. it should be on OE wiki22:09
RParmpit: agreed22:09
armpitor who to email if there are issues22:09
RParmpit: arbrindle (not in this channel but on irc) may be able to help too22:15
RPkhem: If I can get the current patches in -next resolved, I'll look at testing gcc8 next22:16
*** gtristan <gtristan!~tristanva@> has quit IRC22:18
*** marquiz <marquiz!marquiz@nat/intel/x-inlcnhcewnksayps> has quit IRC22:25
*** stephano <stephano!> has quit IRC22:25
*** stephano <stephano!> has joined #yocto22:26
*** anujm <anujm!~anujm@> has joined #yocto22:28
*** marquiz <marquiz!marquiz@nat/intel/x-bihljojphtmouapm> has joined #yocto22:29
*** bavery_fn <bavery_fn!bavery@nat/intel/x-qatogafhrqxkiktz> has quit IRC22:43
khemRP: yes I have, he has already staged them but his changes are not applied yet, he planned to send a pull yesterday with these changes in22:45
khemRP: raspberrypi3 worked well testimage passed as well22:46
khemso its looking ok so far.22:46
RPkhem: ok, we're looking good :)22:46
khemI am now running world builds for musl/glibc on pi and qemux86_64 tonight to see how it fairs with my reference builds22:46
khembut stage them if AB is free22:47
khemso we can get better coverage, only arm/ppc is interesting other should not change22:49
RPkhem: its next in the queue once I resolve the current patches (which are building)22:50
khemok cool22:51
*** agust <agust!> has quit IRC22:51
*** majuk <majuk!> has quit IRC22:55
*** majuk <majuk!> has joined #yocto22:55
*** majuk <majuk!> has quit IRC23:00
*** scottrif <scottrif!> has left #yocto23:16
*** clsulliv <clsulliv!clsulliv@nat/intel/x-pcrberrwkzalmzhd> has quit IRC23:22
*** clsulliv <clsulliv!~clsulliv@> has joined #yocto23:23
*** anujm <anujm!~anujm@> has quit IRC23:25
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto23:26
*** bavery_fn <bavery_fn!~bavery@> has joined #yocto23:31
*** bavery_fn <bavery_fn!~bavery@> has quit IRC23:33
RPkhem: Its started to run now so we'll have results tomorrow23:35
*** nighty- <nighty-!> has quit IRC23:36
*** AbleBacon <AbleBacon!~AbleBacon@unaffiliated/ablebacon> has quit IRC23:42
*** tgraydon <tgraydon!~textual@> has quit IRC23:48

Generated by 2.11.0 by Marius Gedminas - find it at!