**** BEGIN LOGGING AT Wed Jun 06 03:00:10 2018
Jun 06 09:21:11 <gondor> hi everybody
Jun 06 09:21:53 <gondor> what 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?
Jun 06 09:22:17 <rburton> write a recipe which builds a package that contains that file
Jun 06 09:22:21 <gondor> KERNEL_MODULE_AUTOLOAD will create 1 .conf file there per entry
Jun 06 09:22:53 <gondor> so can't use an existing yocto mechanism at this point?
Jun 06 09:26:48 <gondor> the yocto docs say:
Jun 06 09:26:54 <gondor> Specify it as follows:
Jun 06 09:26:54 <gondor>      KERNEL_MODULE_AUTOLOAD += "module_name1 module_name2 module_name3"
Jun 06 09:26:54 <gondor>                     
Jun 06 09:26:54 <gondor> Including 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.
Jun 06 09:27:49 <gondor> it'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 line
Jun 06 09:28:07 <gondor> but by experimenting it seems that yocto does the last one
Jun 06 09:30:10 <rburton> does it matter?
Jun 06 09:33:26 <gondor> yeah, 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 order
Jun 06 09:33:54 <gondor> I need some kernel modules to be loaded in a particular order
Jun 06 09:35:02 <gondor> looks like I'll have to stick with adding the file through a recipe as you suggested
Jun 06 09:35:22 <gondor> would have preferred to use the yocto AUTOLOAD mechanism though
Jun 06 10:15:06 <RP> kanavin: https://autobuilder.yocto.io/builders/nightly-x86-64/builds/1080/steps/BuildImages_2/logs/stdio - any ideas why that could break like that?
Jun 06 10:27:06 <RP> rburton: deciding to add in the mesa upgrade was a disaster, sorry :(
Jun 06 10:27:21 <rburton> mesa is great at pain :)
Jun 06 10:27:55 <RP> rburton: still one mystery selftest regression to isolate too
Jun 06 10:28:16 <RP> rburton: and the gitsm patch broke, again. I've replied on list about that
Jun 06 10:29:00 <rburton> RP: 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 packagegroups
Jun 06 10:29:12 <rburton> RP: i'll push the needed fixes to meta-mingw now
Jun 06 10:31:08 <RP> rburton: don't I have those?
Jun 06 10:32:24 <rburton> dunno haven't looked at next ;)
Jun 06 10:32:36 <rburton> one sec rebasing
Jun 06 10:32:56 <rburton> RP: drop '2018-06-05 13:49 Ross Burton                              o qemu: only build SDL UI if X11 is enabled'
Jun 06 10:35:07 <RP> rburton: ok
Jun 06 10:37:58 <RP> rburton: I've updated the branch and sent that staticdev fix
Jun 06 12:06:08 <yocti> New news from stackoverflow: Yocto: oe_runmake failed, iMX6 Apalis <https://stackoverflow.com/questions/50719943/yocto-oe-runmake-failed-imx6-apalis>
Jun 06 12:12:21 <sveinse> When is the next yocto release scheduled?
Jun 06 12:12:41 <sveinse> Will Qt 5.11 be a part of any yocto release any time soon?
Jun 06 12:15:07 <nayfe_> sveinse: maybe ask mikko.gronoff@qt.io directly ?
Jun 06 12:15:23 <rburton> sveinse: "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)
Jun 06 12:15:48 <nayfe_> as rburton says :)
Jun 06 12:16:32 <JaMa> sveinse: 5.11 is already in meta-qt5/master for couple months
Jun 06 12:16:44 <JaMa> with the final revision in jansa/master currently
Jun 06 12:32:09 <otavio[m]> RP: hello. We found that bitbake 1.38 branch did not update it's version. It still shows 1.37
Jun 06 12:35:30 <RP> otavio[m]: oops. Fixed
Jun 06 12:37:06 <otavio[m]> :-)
Jun 06 12:37:27 <otavio[m]> RP: I am checking mesa error too
Jun 06 12:37:52 <RP> otavio[m]: thanks
Jun 06 13:00:57 <sveinse> rburton: Isn't "rocko" or "sumo" a Yocto release? https://wiki.yoctoproject.org/wiki/Releases
Jun 06 13:09:28 <varjag> dear people, what's the canonical way to rebuild an image after you change/rebuild the kernel?
Jun 06 13:15:56 <RyFa> My guess would be to remove the tmp and rebuild - but im pretty new to the project. Id love to hear someone confirm that
Jun 06 13:16:27 <RyFa> Im also trying to udate the kernel for my image
Jun 06 13:26:59 <varjag> RyFa: that's what i've been doing, but it takes half a workday initially
Jun 06 13:27:40 <varjag> then i tried bitbake -c cleanall the image, and then bitbake it again
Jun 06 13:27:55 <varjag> but it fails complaining some cryptodev module missing
Jun 06 13:29:29 <RyFa> Yeah, Initial builds take a super long time unfortunately, but for a major change such as a kernel, id expect it to be necessary.
Jun 06 13:29:46 <RyFa> Do you happen to get that same error in every case?
Jun 06 13:29:51 <varjag> that's not a major change
Jun 06 13:29:56 <varjag> to generate an image
Jun 06 13:30:12 <varjag> it's not like i was rebuilding the host toolchain
Jun 06 13:30:23 <varjag> yeah same
Jun 06 13:30:29 <varjag> guess i go bug our vendor with this
Jun 06 13:31:06 <RyFa> do oyu have a cryptodev recipe somewhere in your project?
Jun 06 13:31:20 <varjag> not me
Jun 06 13:31:25 <RyFa> check this out: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=cryptodev
Jun 06 13:31:36 <varjag> but it's yocto, so billion of the vendor layers mixed
Jun 06 13:31:47 <RyFa> you may be able to add one based on this
Jun 06 13:32:05 <varjag> mm thanks i'll look at this
Jun 06 13:32:53 <varjag> but it builds fine from clean state with the same recipe, that's what is strange
Jun 06 13:36:52 <RyFa> hhm yeah - its beyond my knowledge
Jun 06 13:37:16 <marka> there is no reason to kill tmp when you change the kernel
Jun 06 13:38:24 <marka> I am not sure what you are observing but everything should just work
Jun 06 13:39:14 <marka> even 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 again
Jun 06 13:40:54 <varjag> ha.. does it have to be virtual/kernel?
Jun 06 13:41:03 <varjag> because i am rebuilding the vendor package name
Jun 06 13:41:17 <marka> I use virtual/kernel as it saves me having to figure out what kernel is in play
Jun 06 13:41:18 <varjag> bitbake linux-variscite..
Jun 06 13:41:41 <varjag> bitbaking this one does not invalidate the cache
Jun 06 13:41:52 <varjag> if i bake image it runs no tasks
Jun 06 13:42:07 <marka> then your image is not using this kernel
Jun 06 13:42:35 <varjag> doubt it, the changes i did in the kernel tree show up in sysfs
Jun 06 13:43:38 <varjag> hm.
Jun 06 13:44:27 <marka> if you are changing linux-variscite and then rebuilding your image and no tasks are run
Jun 06 13:44:40 <marka> then there is no dependency in the image on linux-variscite
Jun 06 13:45:11 <marka> do 'bitbake <your_image> -e | tee outme'
Jun 06 13:45:32 <marka> then 'grep PREFERRED_PROVIDER_virtual/kernel outme'
Jun 06 13:46:10 <marka> if virtual/kernel is not linux-variscite then it is just a clinger
Jun 06 13:46:28 <varjag> marka: i .bbappended varistite recipe to use my repo with the set of device drivers i need
Jun 06 13:46:45 <varjag> and when i build it from clean state, the drivers show up with node names i assigned
Jun 06 13:47:03 <varjag> ok i'll look into that..
Jun 06 13:47:18 <mario-goulart> Hey marka.  Sorry, I hadn't seen your messages here yesterday.
Jun 06 13:47:28 <marka> mario-goulart: no problem
Jun 06 13:48:34 <marka> varjag: 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 used
Jun 06 13:49:13 <varjag> ok, i'll check, thanks
Jun 06 13:50:10 <marka> it is often worth the time to setup a "pure" yocto build with core-image-minimal and qemu-x86-64 to compare against
Jun 06 13:51:36 <marka> you can setup a shared DL_DIR to save some time and disk space
Jun 06 13:53:49 <rburton> sveinse: rocko/sumo/etc are oe-core and poky releases
Jun 06 14:03:33 <kanavin> RP: no idea, have never seen this kind of checksum failure before
Jun 06 14:03:54 <kanavin> RP: "libgstfft-1.0-0-1.14.0-r0.0.core2_64: sha256 check failed: 36b24cf863c232197c9660029fb5590665a86023b32f17d5a2d000e5c0e7e1c1 vs 178f1e86a46fe8457d768d65d0b3cdaa0022611705af7fb89131bf6f5a54c357"
Jun 06 14:04:35 <kanavin> RP: 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 happen
Jun 06 14:09:25 <RP> kanavin: indeed. I don't understand it
Jun 06 14:09:35 <RP> kanavin: another question since you're here :)
Jun 06 14:10:01 <kanavin> RP: I am transitioning to 'kanavin_home' nickname :)
Jun 06 14:10:07 <kanavin> but so far, this one still works :)
Jun 06 14:10:13 <RP> kanavin: I can use either :)
Jun 06 14:10:49 <RyFa> So, 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?
Jun 06 14:11:02 <RP> kanavin: https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/1099/steps/Running%20oe-selftest/logs/stdio
Jun 06 14:11:33 <RP> kanavin: 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?
Jun 06 14:12:20 <kanavin> RP: 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'
Jun 06 14:12:21 <kanavin> :)
Jun 06 14:13:39 <RP> kanavin: no more info in there
Jun 06 14:15:43 <kanavin> RP: you probably need this patch: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=ce12d183bb0a3366d37855e18452ac6ee6215be3
Jun 06 14:15:55 <kanavin> RP: but it's already in master I think :/
Jun 06 14:16:34 <RP> kanavin: I think that was already in that build, yes
Jun 06 14:17:31 <kanavin> can 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 postuns
Jun 06 14:17:46 <kanavin> or preuns
Jun 06 14:22:49 <RP> kanavin: http://dan.rpsys.net/log.do_rootfs.39609
Jun 06 14:25:08 <kanavin> RP: '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'
Jun 06 14:25:26 <kanavin> RP: this de-installation is not handled through dnf, but through rpm directly, and so extra verbosity is not in effect
Jun 06 14:25:44 <kanavin> RP: don't remember right now where in rootfs.py or package_manager.py that happens
Jun 06 14:26:45 <RP> kanavin: ah, we should perhaps try and improve that if we can then...
Jun 06 14:27:27 <kanavin> RP: yes, certainly. It's not hard, just add the necessary command line switch to rpm invocation. I can't do this right now though.
Jun 06 14:28:01 <RP> kanavin: do you know what the switch is offhand?
Jun 06 14:29:12 <kanavin> RP: -v, or maybe even -vv :) just looked up in the manpage
Jun 06 14:29:39 <kanavin> ah, -v is already there
Jun 06 14:29:41 <kanavin> -vv then
Jun 06 14:31:14 <RP> kanavin: thanks, lets see if I can add debugging assume it reproduces
Jun 06 14:31:20 <kanavin> RP: "            args = ["-e", "-v", "--nodeps", "--root=%s" %self.target_rootfs]" in package_manager.py
Jun 06 14:32:58 <RP> kanavin: thanks :)
Jun 06 14:38:56 <RP> kanavin: would you believe this isn't much more helpful :(
Jun 06 14:39:08 <kanavin> RP: :-(
Jun 06 14:39:42 <RP> kanavin: https://pastebin.com/u79apLR2
Jun 06 14:48:18 <kanavin> RP: try -d. Just reading source code for rpm, man page is not helpful :)
Jun 06 14:49:02 <kanavin> RP: ah, wait
Jun 06 15:03:51 <kanavin> RP: note that both prerm scripts fail, and they're different. It's as if they don't even begin to execute.
Jun 06 15:07:18 <kanavin> RP: maybe we're best off bisecting this? It certainly used to work, didn't it?
Jun 06 15:07:56 <RP> kanavin: 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 logs
Jun 06 15:08:26 <kanavin> RP: I guess that's the most we can get out of rpm :-/
Jun 06 15:09:07 <RP> fray: any ideas on getting more info from rpm preun?
Jun 06 15:09:34 <RP> kanavin: shadow preun only calls update-altnatives afaict too
Jun 06 15:14:52 <kanavin> RP: 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.
Jun 06 15:20:28 <RP> kanavin: I'm not surprised :(
Jun 06 15:24:17 <kanavin> RP: let me try another idea, wait a moment
Jun 06 15:25:49 * armpit the joys of backporting spectre
Jun 06 15:30:34 <kanavin> RP: no, false lead. Something breaks down before shell executes actual lines, I believe
Jun 06 15:38:42 <fray> for the rpm preun, you can inject some script stuff into the rpm macros (something that is run prior to the execution of the script....
Jun 06 15:39:00 <fray> but if the preun fails, then the scriptlet that failed will remain on the disk int he tmp location as well..
Jun 06 15:39:26 <fray> so 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'
Jun 06 15:52:23 <RP> kanavin: that would match the 127 exit code
Jun 06 16:06:31 <kergoth> RP: 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.
Jun 06 16:07:05 <RP> kergoth: no
Jun 06 16:07:13 <kergoth> k
Jun 06 16:08:17 <RP> rburton, kanavin: I reproduced that failure on centos7 with master, so its nothing in -next
Jun 06 16:08:34 <RP> which is good and bad
Jun 06 16:28:44 <khem> RP: https://pastebin.ca/4038573
Jun 06 16:29:01 <khem> RP: thats the gcc8 SDK output when someone specifies -mspe
Jun 06 16:29:59 <RP> khem: can you build gcc with spe enabled though?
Jun 06 16:30:07 <khem> no
Jun 06 16:30:19 <RP> khem: that is no longer possible at all?
Jun 06 16:30:19 <igor> hi guys, how can I build an ISO image?
Jun 06 16:30:19 <khem> the backend is different now
Jun 06 16:30:40 <khem> we need to add another tuple to supported machines
Jun 06 16:30:40 <igor> I set IMAGE_FSTYPES = "iso hddimg", but it is building only hddimg
Jun 06 16:31:21 <igor> on log.do_bootimg I saw that INITRD is not set
Jun 06 16:31:44 <igor> so I tried to set INITRD = "${INITRD_LIVE}", but it did not work
Jun 06 16:32:08 <igor> so, there is a default initramfs to put on INITRD var to build a iso?
Jun 06 16:32:18 <RP> khem: I still think there may be a problem lurking in there, I'm having trouble explaining it though :/
Jun 06 16:32:35 <khem> igor: meta/conf/machine/include/x86-base.inc:NOISO ?= "1" you need to set NOISO = "0"
Jun 06 16:33:11 <igor> Thank you very mutch Khem
Jun 06 16:33:17 * RP thinks NOISO needs to die in favour of IMAGE_FSTYPES
Jun 06 16:33:21 <khem> RP: a subset of freescale ppc impl used SPE newer PPC impls from them has altivec
Jun 06 16:33:43 <rburton> RP: yes, that burnt me recently too
Jun 06 16:34:23 <khem> RP: so older ppc from freescale is primarily what uses spe
Jun 06 16:34:54 <khem> the newer ones they dont have spe and thats also probably one reason there is no interest in maintaining it upstream
Jun 06 16:35:00 <RP> khem: we don't have any machines in core which use spe right?
Jun 06 16:35:24 <khem> I think our ref board is can you tell me the name :(
Jun 06 16:35:34 <igor> another 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 executing
Jun 06 16:35:59 <RP> rburton, kanavin: 762a3f229c42b734160334fb462beaf576353a58 breaks, 6db8b6a77723f1e3a34d61ffd96c196e03ace164 does not
Jun 06 16:36:01 <igor> I put a deltask bootimg on my recipe because I didnt found how to remove image-live from inherited classes
Jun 06 16:36:19 <igor> there is a better way to do that or deltask is the best option?
Jun 06 16:36:49 <RP> igor: bootimg isn't a task, its a class
Jun 06 16:37:14 <igor> on branch sumo it is a task on image-live called do_bootimg
Jun 06 16:37:52 <igor> it runs build_hddimg and build_iso
Jun 06 16:37:58 <RP> igor: hmm, I see what you mean. I think that task is needed as part of image-live
Jun 06 16:38:07 <igor> yes
Jun 06 16:38:15 <igor> but my image is tar.bz2 and dont need this
Jun 06 16:38:36 <RP> igor: what do you have IMAGE_FSTYPES set to?
Jun 06 16:38:48 <igor> IMAGE_FSTYPES = "tar.bz2"
Jun 06 16:39:58 <RP> igor: can you check that with bitbake -e ?
Jun 06 16:40:01 <igor> on bitbake -e , the build_live function is returning empty string, but the image-live class still include in BBINCLUDED
Jun 06 16:40:14 <igor> yes
Jun 06 16:40:48 <RP> rburton, kanavin: This is looking like http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b7f6638962b0348ae93c1d5a7696c80e2b7933ed as the change which breaks it :/
Jun 06 16:41:22 <RP> igor: that seems odd :(
Jun 06 16:41:43 <RP> igor: you're not trying to do this in individual images are you?
Jun 06 16:41:45 <igor> RP: #   "tar.bz2" IMAGE_FSTYPES="tar.bz2"
Jun 06 16:42:15 <khem> RP: our ref board in core is mpc8315erdb which is e300c3 core which is implementing proper FPU and doesnt have SPE AFAICT
Jun 06 16:42:22 <rburton> fwiw i've an image recipe that does successfully build just a targz
Jun 06 16:42:46 <igor> RP: but when I see the var BOOTIMG_EXTRA_SPACE for example, it was set by image-live.bbclass
Jun 06 16:42:51 <khem> rburton/RP: is it possible for you to boot a gcc8 image on a ref board
Jun 06 16:43:01 <igor> and other vars too
Jun 06 16:44:37 <rburton> khem: i've a nuc
Jun 06 16:44:45 <RP> rburton: would be interesting to know if it still inherited the class though...
Jun 06 16:45:37 <igor> i'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_FSTYPES
Jun 06 16:46:12 <igor> it was fixed few days ago, but the task do_bootimg sill added
Jun 06 16:46:33 <igor> but I solved this problema putting deltask bootimg on my recipe
Jun 06 16:46:41 <rburton> RP: it isn't
Jun 06 16:47:01 <RP> Saur: around?
Jun 06 16:55:00 <RP> fray: does anything jump out to you in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b7f6638962b0348ae93c1d5a7696c80e2b7933ed as causing that preun problem?
Jun 06 16:55:18 <fray> looking
Jun 06 16:57:10 <fray> the setCloseOnExec will certainly change behavior.. but this would only be a problem if the script was being passed to the receiver inline or something
Jun 06 16:57:22 <fray> lua change, as far as I know we're not using lua in any preuns
Jun 06 16:57:45 <fray> ++open_max = sysconf(_SC_OPEN_MAX);
Jun 06 16:57:45 <fray> ++if (open_max == -1) {
Jun 06 16:57:45 <fray> ++open_max = 1024;
Jun 06 16:57:45 <fray> ++}
Jun 06 16:57:45 <fray> ++for (fdno = 3; fdno < open_max; fdno++) {
Jun 06 16:57:46 <fray> ++flag = fcntl(fdno, F_GETFD);
Jun 06 16:57:46 <fray> ++if (flag == -1 || (flag & FD_CLOEXEC))
Jun 06 16:57:47 <fray> ++continue;
Jun 06 16:57:47 <fray> ++fcntl(fdno, F_SETFD, FD_CLOEXEC);
Jun 06 16:57:48 <fray> ++}
Jun 06 16:57:48 <fray> ++}
Jun 06 16:57:54 <fray> Ohhh.. this would be closing pseudo stuff too...
Jun 06 16:58:18 <fray> could that be causing a problem?
Jun 06 16:58:45 <RP> fray: yes, that could
Jun 06 16:59:21 <fray> second patch file changes the above, but conceptually it's still doing the same thing
Jun 06 17:00:00 <fray> also iterates over /proc -- but proc will be able to see the pseudo fds
Jun 06 17:00:22 <fray> so ya.. it's likely breaking the connection on exec with pseudo -- but I don't know the exact ramifications of that
Jun 06 17:00:43 <fray> (and it's breaking them cause it's blindly adjusting -all- fds, not just the ones that rpm itself created)
Jun 06 17:01:16 <RP> fray: I wonder if the "+x" bit disappears on the script
Jun 06 17:01:31 <fray> as in set +x?
Jun 06 17:01:36 <fray> or execute
Jun 06 17:01:47 <RP> fray: execute
Jun 06 17:01:53 <RP> hence the exit 127
Jun 06 17:01:59 <fray> scriptlets SHOULD be executed as 'interpreter <script>'
Jun 06 17:02:12 <fray> if you are getting 127, that seems an aweful lot like the interpreter failed
Jun 06 17:02:36 <fray> going to look quick to verify what I said is still true
Jun 06 17:02:50 <fray> (this master?)
Jun 06 17:04:23 <fray> there is also the code:
Jun 06 17:04:28 <fray> +           if (getenv("RPM_NO_CHROOT_FOR_SCRIPTS") != NULL) {
Jun 06 17:04:28 <fray> +               rpmChrootOut();
Jun 06 17:04:28 <fray> +               rc = runExtScript(plugins, prefixes, script->descr, lvl, scriptFd, &args, script->body, arg1, arg2, &script->nextFileFunc);
Jun 06 17:04:28 <fray> +               rpmChrootIn();
Jun 06 17:04:42 <fray> so that will affect where the scriptlet is trying to run, as well as the script engine
Jun 06 17:05:51 <RP> fray: yes, this is master
Jun 06 17:08:12 <fray> so ya.. I'd say the first thing to try is disable the close all fds on exec thing..
Jun 06 17:08:26 <fray> if that fixes the problem, then it's likely either pseudo or some other glibc thing
Jun 06 17:08:36 <fray> (like nss...)
Jun 06 17:09:52 <fray> ohh other thing..  rpm -qp <package> --scripts  take a look and verify the preun is reasonable.. ;)
Jun 06 17:11:35 <RP> fray: I did read the spec file. What is odd is this works on some machines but not centos7
Jun 06 17:12:22 <fray> that seems strange -- unless say '/bin/bash' (or /usr/bin/bash) is hardcoded into the scriptlet, and it's not hte interpretor on the running machine
Jun 06 17:12:36 <fray> I think rpm -qp <...> --scripts will show you that
Jun 06 17:13:44 <RP> fray: interestingly, #!/bin/sh is encoded in, and it isn't in the postinst
Jun 06 17:13:48 <fray> preinstall scriptlet (using /bin/sh):
Jun 06 17:13:48 <fray> # base-files - preinst
Jun 06 17:13:48 <fray> set -e
Jun 06 17:13:48 <fray>     #!/bin/sh -e
Jun 06 17:13:48 <fray>     if [ x"$D" = "x" ]; then
Jun 06 17:13:52 <fray> ya.. something like that..
Jun 06 17:14:03 <RP> fray: this is shadow
Jun 06 17:14:54 <fray> in 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 file
Jun 06 17:14:59 <fray> (generated spec file)
Jun 06 17:15:15 <fray> I can try to activate RPM and build shadow stuff...  I don't have any current builds that I found
Jun 06 17:16:22 <fray> (BTW I am using CentOS 7 as well)
Jun 06 17:16:43 <RP> fray: the reproducer is IMAGE_FEATURES += "read-only-rootfs"  bitbake core-image-sato on centos 7
Jun 06 17:17:04 <fray> ok. I'll try that next once I get just shadow built and inspect it
Jun 06 17:19:27 <kanavin_home> fray: 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 here
Jun 06 17:20:02 <fray> 'which debugging' are you referring to?
Jun 06 17:20:23 <fray> RPM 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..
Jun 06 17:20:34 <fray> by default though scriptlet output is silenced to /dev/null
Jun 06 17:20:57 <RP> kanavin_home: I think some filehandle is disappearing so it isn't running anything
Jun 06 17:21:05 <kanavin_home> fray: '-vv' when installing or removing packages
Jun 06 17:21:36 <fray> preuninstall scriptlet (using /bin/sh):
Jun 06 17:21:36 <fray> # shadow - prerm
Jun 06 17:21:36 <fray> #!/bin/sh
Jun 06 17:21:36 <fray> if [ "$1" = "0" ] ; then
Jun 06 17:21:36 <fray> set -e
Jun 06 17:21:36 <fray>         update-alternatives --remove  passwd /usr/bin/passwd.shadow
Jun 06 17:21:37 <fray>         update-alternatives --remove  chfn /usr/bin/chfn.shadow
Jun 06 17:21:37 <fray>         update-alternatives --remove  chsh /usr/bin/chsh.shadow
Jun 06 17:21:38 <fray>         update-alternatives --remove  chpasswd /usr/sbin/chpasswd.shadow
Jun 06 17:21:38 <fray>         update-alternatives --remove  vipw /sbin/vipw.shadow
Jun 06 17:21:39 <fray>         update-alternatives --remove  vigr /sbin/vigr.shadow
Jun 06 17:21:39 <fray>         update-alternatives --remove  nologin /sbin/nologin.shadow
Jun 06 17:21:40 <fray> fi
Jun 06 17:21:41 <fray> that is what I got..  which all seems reasnable
Jun 06 17:22:05 <RP> fray: note how it starts with #!/bin/sh where as the postinst doesn't
Jun 06 17:22:15 <fray> ya, doesn't matter
Jun 06 17:22:39 <fray> the 'using /bin/sh' is what should actually be invoked.. the other is simply an annotation.. and actually it starts with "# shadow - prerm"  ;)
Jun 06 17:23:38 <fray> it should be the equivalent of:
Jun 06 17:23:42 <fray> cat << EOF
Jun 06 17:23:44 <fray> <scriptlet>
Jun 06 17:23:45 <fray> EOF
Jun 06 17:24:00 <fray>  /bin/sh <file scriptlet was written to>
Jun 06 17:24:15 <fray> (unless they've changed something I'm not aware of recently)
Jun 06 17:24:19 <RP> fray: ok, curious if you can reproduce
Jun 06 17:24:45 * fray is testing the task accounting.. it's still working.. :)  only two fetches at once
Jun 06 17:28:05 <kanavin_home> RP: I do wonder if '    rpm: Restore performance in Docker containers' is the commit we're after
Jun 06 17:28:29 <fray> my guess is it is, and it's related to changing all file descriptions
Jun 06 17:31:44 <RP> kanavin_home: bisection says yes
Jun 06 17:31:57 <kanavin_home> RP: that is a bit of a :-(
Jun 06 17:32:10 <kanavin_home> as I think those patches are direct backports from rpm upstream?
Jun 06 17:32:31 <RP> kanavin_home: well, yes. Upstream don't have pseudo around for example though
Jun 06 17:32:39 <RP> so I can at least see how this might break
Jun 06 17:33:33 <kanavin_home> RP: previously rpm blindly closed the first 1024 fds though and that worked for us. not sure what they changed so that it breaks now.
Jun 06 17:33:48 <kanavin_home> I guess we need to notify Peter
Jun 06 17:40:06 <fray> it didn't look like it blindly closed 1024 fds before.... it looks like this three patch series added that
Jun 06 17:40:09 <RP> kanavin_home: unless pseudo uses high number fds for its own use?
Jun 06 17:40:27 <RyFa> Hey 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"
Jun 06 17:40:32 <fray> the third in the series adds the capability to look in /proc for the actual pids being used
Jun 06 17:40:39 <kanavin_home> fray: it did
Jun 06 17:40:43 <fray> so lets say it is a pid above 1024.. then it would now know it
Jun 06 17:41:39 <mrk377> webserver 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?
Jun 06 17:41:46 <kanavin_home> fray: -       open_max = sysconf(_SC_OPEN_MAX);
Jun 06 17:41:46 <kanavin_home> -       if (open_max == -1) {
Jun 06 17:41:46 <kanavin_home> -           open_max = 1024;
Jun 06 17:41:46 <kanavin_home> -       }
Jun 06 17:41:46 <kanavin_home> -       for (fdno = 3; fdno < open_max; fdno++) {
Jun 06 17:41:46 <kanavin_home> -           flag = fcntl(fdno, F_GETFD);
Jun 06 17:41:46 <kanavin_home> -           if (flag == -1 || (flag & FD_CLOEXEC))
Jun 06 17:41:47 <kanavin_home> -               continue;
Jun 06 17:41:47 <kanavin_home> -           fcntl(fdno, F_SETFD, FD_CLOEXEC);
Jun 06 17:41:48 <kanavin_home> -       }
Jun 06 17:41:48 <kanavin_home> +       rpmSetCloseOnExec();
Jun 06 17:42:00 <fray> I thought that was the second hunk
Jun 06 17:42:10 <fray> I don't have the patch up on my screen anymore though
Jun 06 17:43:36 <fray> just re-read it.. you are right.. it was blindly closing before
Jun 06 17:43:41 <kanavin_home> RP: could well be. Just like I told you, that newly added /proc iteration code has *no* debugging whatsoever in it :(
Jun 06 17:43:55 <kanavin_home> so someone needs to add it ad hoc to see what is actually being closed
Jun 06 17:44:33 <fray> I 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)
Jun 06 17:47:20 <kanavin_home> fray: that will make Docker using people very unhappy, particularly Peter Kjellerstedt
Jun 06 17:47:22 <kanavin_home> is he here?
Jun 06 17:49:21 <fray> ya, but if it makes everyone else unhappy..  that's a valid tradeoff..
Jun 06 17:49:39 <fray> ok.. I got the failure on my CentOS box you guys are talking aobut..
Jun 06 17:49:56 <fray> I'll start yanking RPM patches and see if it goes away.. (I assume running it a second time does not normallyf ix it)
Jun 06 17:55:35 <fray> ...and ninja fails AGAIN to build DNF.. retry
Jun 06 17:55:51 <fray> it always seems to fail the first time around, but always on different files.. :|
Jun 06 17:56:11 <fray> I'm tempted to restrict DNF to a small number of build threads
Jun 06 18:04:49 <fray> I disabled the /proc stuff and it still failed..
Jun 06 18:04:57 <fray> disabling the Facctor-out-and-unify now
Jun 06 18:07:02 <RP> fray: the failure should be in do_rootfs
Jun 06 18:07:14 <fray> yup.. thats where it failed
Jun 06 18:07:19 <RP> fray: ok
Jun 06 18:07:45 <fray> I removed the last 2 of the three patches and it still failed.. so I'm assuming it's either the 1st or something unrelated
Jun 06 18:08:56 <RP> fray: note that there is a revert in the previous commit too
Jun 06 18:09:33 <RP> fray: I bisected it to these two commits, I didn't test the midpoint (yet)
Jun 06 18:09:42 <fray> ok
Jun 06 18:13:43 <RP> fray: its useful to know its reproducible though, thanks
Jun 06 18:14:33 <RP> that midpoint is rebuilding lots so will take a while to test
Jun 06 18:21:49 <khem> RP: looking more into it, I think we are at a cross road for ppc
Jun 06 18:22:25 <khem> RP: it seems most of fsl ppc uses SPE except SoCS based on e6500 cores
Jun 06 18:22:31 <Crofton|work> khem, if no one steps up, we should drop it
Jun 06 18:22:45 <khem> right now its holding gcc8 ransom
Jun 06 18:22:50 <Crofton|work> also, any suggetions on my FORTRAN problem :)
Jun 06 18:23:02 <khem> did you reply to my question
Jun 06 18:23:03 <RP> Crofton|work: use a modern language ;-)
Jun 06 18:23:53 * Crofton|work curses scipy
Jun 06 18:24:02 <Crofton|work> khem, yes
Jun 06 18:24:06 <khem> RP: we can switch to using spe backend and that will give us most supported ppc machines we have but its a backend with no maintainers
Jun 06 18:24:27 <Crofton|work> I find the spec.in gfile only
Jun 06 18:24:33 <RP> khem: right, someone should really step up who cares about ppc to do this...
Jun 06 18:25:29 <fray> kanavin_home:  If I remove: #           file://0001-Factor-out-and-unify-setting-CLOEXEC.patch \
Jun 06 18:25:39 <fray> and the two susbequent ones it now works..
Jun 06 18:25:42 <khem> RP: minimum I can do is to enable -mno-spe option to be recognised with normal ppc backend so we can drop http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=f21a0d7ff3383f98a0e7b3e16ad210945946e1e1
Jun 06 18:25:51 <khem> that will let people use gcc7 for ppc
Jun 06 18:25:52 <fray> if I KEEP that one, and remove only the subsequent two it does NOT work
Jun 06 18:25:59 <fray> so something is wrong in the refactoring
Jun 06 18:26:25 <Crofton|work> khem,
Jun 06 18:26:27 <Crofton|work> [balister@prague build-pi]$ find ./tmp-glibc/ -name "libgfortran.spec*"
Jun 06 18:26:27 <Crofton|work> ./tmp-glibc/work-shared/gcc-7.3.0-r0/gcc-7.3.0/libgfortran/libgfortran.spec.in
Jun 06 18:26:30 <khem> We folks who are interested in SPE can pin to gcc7 and we can move on
Jun 06 18:26:49 <khem> Crofton|work: is it in sysroot of the package you are building
Jun 06 18:26:49 <Crofton|work> ah khem  really cares :)
Jun 06 18:27:03 <Crofton|work> look carefully
Jun 06 18:27:07 <Crofton|work> I search all of tmp
Jun 06 18:27:15 <Crofton|work> and only see .in version
Jun 06 18:27:41 <kanavin_home> fray: the refactoring moved from hardcoding first 1024 fds to iterating over open ones in /proc/self/fd
Jun 06 18:27:48 <khem> hmm if you enabled fortan in gcc then you should have had one
Jun 06 18:27:54 <kanavin_home> so probably they now close something they should now
Jun 06 18:28:27 <fray> it's the patch 0001-Factor-out-and-unify-setting-CLOEXEC.patch
Jun 06 18:28:29 <fray> if applied it failed
Jun 06 18:28:43 <fray> I don't see any obvious reason why it would fail, or why the refactoring code is wrong
Jun 06 18:28:51 <khem> Crofton|work: no way, I have no interest in ppc as all that 'We' is just to pretent inclusive
Jun 06 18:29:01 <fray> the 0001-Factor... patch seems straight forward though
Jun 06 18:29:19 <fray> and it claimes to be accepted upstream in a newer version of RPM
Jun 06 18:29:41 <RP> khem: 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...
Jun 06 18:30:03 <fray> the only difference I see is:
Jun 06 18:30:03 <fray> -       xx = fcntl(fdno, F_SETFD, FD_CLOEXEC);
Jun 06 18:30:09 <fray> +               fcntl(fdno, F_SETFD, FD_CLOEXEC);
Jun 06 18:30:13 <fray> which should not be a problem
Jun 06 18:30:26 <Crofton|work> khem exactly
Jun 06 18:31:31 <Crofton|work> https://paste.debian.net/1028244/
Jun 06 18:31:44 <Crofton|work> the fortan binary is there, but no spec file is created
Jun 06 18:32:05 <kanavin_home> fray: bizarre, it doesn't seem to actually change the code?
Jun 06 18:32:23 <khem> Crofton|work: do you have libgfortan built ?
Jun 06 18:33:19 <khem> RP: I can switch to using powerpcspe backend as well, I wonder if we have non fsl ppc users
Jun 06 18:33:23 <khem> they will be at a loss
Jun 06 18:33:34 <Crofton|work> apparently not
Jun 06 18:33:52 <fray> kanavin_home agreed.. but it doesn't work with the patch, and does work with it (on my system)
Jun 06 18:34:10 <khem> RP: 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 warning
Jun 06 18:34:17 <fray> makes 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 conflict
Jun 06 18:34:40 <kanavin_home> fray: are you super-sure though? maybe you mixed up the patches
Jun 06 18:34:46 <Crofton|work> fark
Jun 06 18:35:31 <Crofton|work> DEPENDS = "gcc-runtime"
Jun 06 18:35:37 <fray> no.. I yanked them one at a time from the openembedded-core/meta/recipes-devtools/rpm/rpm_4.14.1.bb
Jun 06 18:35:39 <fray> I can repeat it..
Jun 06 18:36:13 <khem> so what are folks doing with github repositories, migrating to gitlab :)
Jun 06 18:36:14 <fray> I just enabled the 0001- patch (and only that) and I'm building again.. will probab be 5-10 mins
Jun 06 18:36:29 <RP> fray: I'm trying that too, see if I can confirm
Jun 06 18:36:54 <Crofton|work> khem, thanks
Jun 06 18:36:57 <Crofton|work> I owe you a coke
Jun 06 18:37:01 <fray> ahh I have this run already in the sstate-cache.. so it might take less time
Jun 06 18:37:58 <khem> Crofton|work: I like the columbian one ;)
Jun 06 18:38:56 * kanavin_home lives under a rock, what's the problem with github?
Jun 06 18:38:59 <fray> yup.. failed when I re-enabled the patch
Jun 06 18:39:11 <khem> Crofton|work: https://asteroidos.org/ is based on OpenEmbedded why dont we add this to front page
Jun 06 18:39:12 <fray> github will soon be owned by Microsoft.. apparently that makes a difference to some
Jun 06 18:39:36 <Crofton|work> and gitlab is hosted on Azure I hear
Jun 06 18:39:55 <fray> I'll care about github when MS screws it up.. until then, whatever..
Jun 06 18:40:13 <fray> I didn't care about sourceforge until they started to put ads and intersituals everywhere.. that was the end of me using them
Jun 06 18:40:19 <khem> I think MS has embrased OSS after new CEO
Jun 06 18:40:43 <kanavin_home> khem: embraced in a way that benefits Azure mostly
Jun 06 18:41:30 <khem> RP: 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 arches
Jun 06 18:42:05 <khem> I already see it rotting. Last commit to this backend in gcc was on march 4th
Jun 06 18:42:38 <RP> khem: My worry is the shared single cross gcc powerpc binary for both spe and non-spe
Jun 06 18:43:02 <fray> kanavin - 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..
Jun 06 18:43:05 <RP> fray: confirmed, that patch does seem to break ot
Jun 06 18:43:12 <khem> I am sure RP will be happy about github :)
Jun 06 18:43:12 <fray> RP.. I'm not crazy then
Jun 06 18:43:37 <khem> RP: cant stand on two boats anymore since they are diverging the route
Jun 06 18:44:45 <khem> I think most of OE users of ppc are using fsl SoCs and that backend is going away
Jun 06 18:45:04 <RP> khem: I think you're right :(
Jun 06 18:45:05 <khem> the supported backend is nice but probbably not many users for OE
Jun 06 18:45:19 <RP> khem: this is what is worrying me
Jun 06 18:46:42 <khem> so 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 same
Jun 06 18:48:37 <RP> khem: I think so
Jun 06 18:48:58 <khem> OK let me redo the gcc8 patches for ppc portions
Jun 06 18:49:24 <khem> the arm tuning we can do as a seprate item lets not hold gcc8 for that
Jun 06 18:50:56 <fray> bingo
Jun 06 18:50:57 <fray>    181: 000000000000fae0   119 FUNC    GLOBAL DEFAULT   11 rpmSetCloseOnExec
Jun 06 18:50:57 <fray>    181: 000000000000fae0   119 FUNC    GLOBAL DEFAULT   11 rpmSetCloseOnExec
Jun 06 18:50:57 <fray>    181: 000000000000fae0   119 FUNC    GLOBAL DEFAULT   11 rpmSetCloseOnExec
Jun 06 18:50:57 <fray>    180: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND rpmSetCloseOnExec
Jun 06 18:50:57 <fray>    180: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND rpmSetCloseOnExec
Jun 06 18:50:57 <fray>    180: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND rpmSetCloseOnExec
Jun 06 18:51:09 <fray> that's readelf.. the function is defined in ALL THREE librpms..
Jun 06 18:51:13 <fray> so likely it's going nuts
Jun 06 18:52:08 <fray> wait...
Jun 06 18:52:25 <fray> no.. my mistake
Jun 06 18:52:39 <fray> it's onluy defined in librpmio.so* which is correct
Jun 06 18:53:33 <fray> ok.. so I'm at a loss as to why it fails.. the only difference seens to be a functional call vs not
Jun 06 18:58:31 <RP> fray: compiler bug on centos7?
Jun 06 19:01:01 <RP> fray: actually, take a look at doScriptExec() in rpmscript.c
Jun 06 19:01:10 <RP> fray: the int xz
Jun 06 19:01:12 <RP> er, xx
Jun 06 19:01:53 <RP> fray: what does that if (xx == 0) do?
Jun 06 19:05:06 * RP tries deleting that
Jun 06 19:09:10 <fray> where do you see the if xx == 0?
Jun 06 19:09:39 <fray> or 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 it
Jun 06 19:11:16 <RP> fray: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/taa&id=e8dbc36b4dd61c7b747076be63a46b59ed3a5cf5
Jun 06 19:11:58 <fray> huh
Jun 06 19:12:20 <fray> ya.. that definitely should be gone..
Jun 06 19:12:45 <fray> cause xx will be undefined if the other setters don't work..
Jun 06 19:13:11 <fray> if anything, i'd say the function be adjusted to return a similar return code and xx = rpmSetCloseOnExec() run
Jun 06 19:13:19 <fray> but that is probably not necessary
Jun 06 19:13:38 <fray> alternative would be at the top of the function set xx = 0... since there are intermediate steps that set xx if they fail..
Jun 06 19:13:56 <fray> (without of course checking porior xx if it'd been set)  ;P
Jun 06 19:14:09 <RP> fray: well, if xx is meant to be ignored...
Jun 06 19:14:10 <fray> i.e. this is a mess
Jun 06 19:14:19 <fray> thats the thing, other parts of the code it's meant to be ignored..
Jun 06 19:14:25 <RP> fray: yes, its very confused
Jun 06 19:14:38 <fray> it LOOSK like if scriptFd == NULL, then the last XX will be from the setfd. otherwise it'll be from the Fclose
Jun 06 19:15:13 <fray> I suspect the xx check is supposed to be from the Fclose.. but not sure.. (maybe git can tell me0
Jun 06 19:15:18 <RP> fray: fwiw it works with that patch
Jun 06 19:15:38 <RP> so we at least know why it breaks
Jun 06 19:16:15 <RP> kanavin_home: mystery partly solved :)
Jun 06 19:16:18 <fray> yup
Jun 06 19:16:59 <fray> ok.. at the time that was originally written.. the LAST two 'xx' values were:
Jun 06 19:17:07 <fray> +       xx = chdir("/");
Jun 06 19:17:12 <fray> +       if (rpmtsSELinuxEnabled(ts) == 1) {
Jun 06 19:17:12 <fray> +           xx = rpm_execcon(0, argv[0], argv, environ);
Jun 06 19:17:12 <fray> +       }
Jun 06 19:17:13 <RP> still in upstream git https://github.com/rpm-software-management/rpm/blob/master/lib/rpmscript.c#L222
Jun 06 19:17:35 <fray> ya.. my guess is that CentOS 7 doesn't zero 'xx'.. while newer glibc/gcc does
Jun 06 19:17:38 <fray> thus the issue
Jun 06 19:17:58 <RP> fray: yes, different compilers, different results
Jun 06 19:18:20 <fray> but 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..
Jun 06 19:18:32 <RP> fray: agreed on both counts
Jun 06 19:18:35 <fray> with an alternative to set xx = 0 when defined at the top
Jun 06 19:19:53 <RP> fray: I'll submit a pull request to remove it, see what is said
Jun 06 19:24:05 <kanavin_home> RP: fray: I don't get it, xx does seem to be uncoditionally assigned before it's accessed?
Jun 06 19:24:29 <kanavin_home> xx = setenv("PATH", path, 1);
Jun 06 19:25:49 <kanavin_home> ah wait, does the { } block create new scope in C?
Jun 06 19:26:50 <kanavin_home> if so, then reusing xx, and giving it a generic name in the first place is very silly indeed
Jun 06 19:27:51 <RP> kanavin_home: there shouldn't be different scope there
Jun 06 19:28:26 <kanavin_home> RP: then I don't understand :)
Jun 06 19:28:47 <kanavin_home> xx is set (through assignment from setenv) before it's accessed
Jun 06 19:29:01 <RP> https://github.com/rpm-software-management/rpm/pull/447
Jun 06 19:30:47 <RP> kanavin_home: hmm. That is horrible code style.
Jun 06 19:33:43 <RP> kanavin_home: I'm also confused now, as you say, it should get zeroed
Jun 06 19:35:10 <RP> kanavin_home: I think its a gcc 4.8.5 compiler bug :(
Jun 06 19:35:22 <RP> kanavin_home: {} does create scope but it shouldn't change xx here
Jun 06 19:35:32 <RP> well, it shoud
Jun 06 19:36:38 <RP> kanavin_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 it
Jun 06 19:37:53 <kanavin_home> RP: I'm trying to find an authoritative source on how such inner blocks behave
Jun 06 19:38:28 <kanavin_home> is it like a C function, and so only a 'copy' of xx is assigned to and then thrown away?
Jun 06 19:39:10 <RP> kanavin_home: that is how it appears to behave...
Jun 06 19:40:14 <kanavin_home> RP: maybe I just quickly write a toy program to verify instead
Jun 06 19:44:06 <RP> kanavin_home: I'm mixing up the compiler warnings :/
Jun 06 19:45:53 <RP> no, I'm not, the compiler error messages are broken due to inlining
Jun 06 19:47:02 <kanavin_home> RP: xx = setenv("PATH", path, 1); <----- does this actually set xx to something else than zero?
Jun 06 19:47:20 <kanavin_home> if it does, then the subsequent call doesn't happen
Jun 06 19:47:25 <marka> varjag
Jun 06 19:48:13 <RP> kanavin_home: The setenv() function returns zero on success, or -1 on error, with errno set to indicate the cause of the error.
Jun 06 19:49:02 <kanavin_home> RP: yeah, then execv happens only if it's zero
Jun 06 19:49:28 <RP> kanavin_home: ../../git/lib/rpmscript.c:209:5: warning: ‘xx’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Jun 06 19:49:37 <RP> kanavin_home: compiler seems to worry about this
Jun 06 19:51:38 <RP> kanavin_home: we patch out that setenv
Jun 06 19:51:53 <JPEW> FYI: -Wmaybe-uninitialized doesn't do static analysis, so it will complain even if code flow make is impossible for the variable to be used uninitialized
Jun 06 19:52:04 <kanavin_home> RP: !!!!!
Jun 06 19:52:18 <kanavin_home> RP: I guess I can have dinner now :)
Jun 06 19:53:06 <RP> kanavin_home: the patch is from this Alex guy... ;-)
Jun 06 19:57:11 <kanavin_home> RP: 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 used
Jun 06 19:58:28 <RP> kanavin_home: makes a change from it being my fault. This code is horrible. I'm going to leave the pull request open, see what happens
Jun 06 19:59:35 <kanavin_home> RP:  'There are now ways this function can fail to set xx at all' isn't a correct claim though
Jun 06 20:01:40 <kanavin_home> RP: basically if you amend my patch, this should be sorted
Jun 06 20:02:12 <kanavin_home> either set xx to zero where it was set from setenv, or not check it before execv
Jun 06 20:52:17 <RP> kanavin_home: agreed. I've cancelled it
Jun 06 20:54:41 <woglinde> hi
Jun 06 20:55:16 <woglinde> was there a special git login url for the yocto git?
Jun 06 20:57:20 <woglinde> for developers of course
Jun 06 20:59:33 <RP> woglinde: special in what way?
Jun 06 21:00:07 <woglinde> that I can push to the master branch of meta-java
Jun 06 21:00:40 <woglinde> or maybe my ssh key was removed git://git.yoctoproject.org/meta-java
Jun 06 21:01:37 <RP> woglinde: ah, you may need to use push.yoctoproject.org ?
Jun 06 21:01:56 <woglinde> hm oh okay is that documented somewhere?
Jun 06 21:02:21 <RP> woglinde: not sure, halstead might
Jun 06 21:03:37 <halstead> woglinde: I'm traveling so I missed the context. What's up?
Jun 06 21:03:42 <woglinde> ah okay
Jun 06 21:03:47 <woglinde> will try with push
Jun 06 21:04:24 <woglinde> hm and found it now
Jun 06 21:04:27 <woglinde> https://wiki.yoctoproject.org/wiki/Poky_Contributions
Jun 06 21:06:43 <woglinde> hm does not work either
Jun 06 21:08:46 <woglinde> hm ssh://git@git.yoctoproject.org/meta-java still works too
Jun 06 21:09:24 <woglinde> and that worked for pushing
Jun 06 21:09:38 <woglinde> good to have the emails from 4 years ago
Jun 06 21:12:43 <halstead> woglinde: that will work at the moment but not always. You might have proxy settings to update for the new URL.
Jun 06 21:13:20 <khem> RP: so here is new patches http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master
Jun 06 21:13:31 <khem> RP: addressed both ppc and arm tune issues
Jun 06 21:13:48 <khem> http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=635c8757bf852c8a4248009f241c19146431cacd
Jun 06 21:14:24 <khem> ppc change is booting qemuppc and testimage works too
Jun 06 21:14:54 <khem> I am now building for rpi3 and see if I get gcc-runtime issue due to march/mcpu conflict
Jun 06 21:56:12 <armpit> halstead, do you deal with patch queue ?
Jun 06 21:57:09 * armpit we need to list who is admin for that
Jun 06 21:57:26 * armpit needs sumo-master added for both core and meta-or
Jun 06 21:57:47 <RP> khem: that looks much better! :)
Jun 06 21:57:58 <RP> khem: have you talked to zeddii about the kernel patches?
Jun 06 22:07:37 <RP> armpit: list where? I think part of the trouble is the maintainers have changed but halstead should be able to help
Jun 06 22:09:22 <armpit> RP, a list of who has admin privileges. it should be on OE wiki
Jun 06 22:09:35 <RP> armpit: agreed
Jun 06 22:09:43 <armpit> or who to email if there are issues
Jun 06 22:15:08 <RP> armpit: arbrindle (not in this channel but on irc) may be able to help too
Jun 06 22:15:36 <armpit> k
Jun 06 22:16:53 <RP> khem: If I can get the current patches in -next resolved, I'll look at testing gcc8 next
Jun 06 22:45:33 <khem> RP: 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 in
Jun 06 22:46:01 <khem> RP: raspberrypi3 worked well testimage passed as well
Jun 06 22:46:13 <khem> so its looking ok so far.
Jun 06 22:46:19 <RP> khem: ok, we're looking good :)
Jun 06 22:46:49 <khem> I am now running world builds for musl/glibc on pi and qemux86_64 tonight to see how it fairs with my reference builds
Jun 06 22:47:24 <khem> but stage them if AB is free
Jun 06 22:49:17 <khem> so we can get better coverage, only arm/ppc is interesting other should not change
Jun 06 22:50:54 <RP> khem: its next in the queue once I resolve the current patches (which are building)
Jun 06 22:51:09 <khem> ok cool
Jun 06 23:35:34 <RP> khem: Its started to run now so we'll have results tomorrow
Jun 07 00:25:35 <clsulliv> RP: I think your emails to the list are getting bounced
Jun 07 00:25:40 <clsulliv> you show up as openembedded-core-bounces@lists.openembedded.org
**** ENDING LOGGING AT Thu Jun 07 03:00:04 2018