*** bavery_fn <bavery_fn!~bavery@134.134.139.72> has quit IRC | 00:05 | |
*** georgem <georgem!~georgem@216.21.169.52> has quit IRC | 00:14 | |
*** georgem <georgem!~georgem@216.21.169.52> has joined #yocto | 00:15 | |
*** anujm <anujm!~anujm@192.198.146.173> has joined #yocto | 00:27 | |
*** nighty- <nighty-!~nighty@kyotolabs.asahinet.com> has joined #yocto | 00:43 | |
*** learningc <learningc!~User@mti-37-145.tm.net.my> has joined #yocto | 00:46 | |
*** martinkelly1 <martinkelly1!~martin@97-113-238-55.tukw.qwest.net> has quit IRC | 00:51 | |
*** learningc <learningc!~User@mti-37-145.tm.net.my> has quit IRC | 00:53 | |
*** learningc <learningc!~User@mti-37-145.tm.net.my> has joined #yocto | 00:54 | |
*** learningc <learningc!~User@mti-37-145.tm.net.my> has quit IRC | 00:56 | |
*** learningc <learningc!~User@mti-37-145.tm.net.my> has joined #yocto | 00:57 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 01:09 | |
*** kaspter <kaspter!~Thunderbi@115.216.25.198> has joined #yocto | 01:17 | |
-YoctoAutoBuilder- build #1037 of nightly-mips-lsb is complete: Failure [failed BuildImages_1] Build details are at https://autobuilder.yocto.io/builders/nightly-mips-lsb/builds/1037 | 01:30 | |
*** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has quit IRC | 01:31 | |
-YoctoAutoBuilder- build #1139 of nightly is complete: Failure [failed] Build details are at https://autobuilder.yocto.io/builders/nightly/builds/1139 | 01:41 | |
*** clement_ <clement_!~clement@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC | 01:48 | |
*** clement_ <clement_!~clement@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 01:49 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 01:55 | |
*** kaspter <kaspter!~Thunderbi@115.216.25.198> has quit IRC | 01:56 | |
*** kaspter <kaspter!~Thunderbi@115.216.25.198> has joined #yocto | 01:59 | |
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 02:40 | |
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC | 02:52 | |
*** dreyna <dreyna!~dreyna@unknown-157-218.windriver.com> has quit IRC | 03:00 | |
*** majuk <majuk!~majuk@75-163-138-15.clsp.qwest.net> has quit IRC | 03:03 | |
*** majuk <majuk!~majuk@75-163-138-15.clsp.qwest.net> has joined #yocto | 03:03 | |
*** majuk <majuk!~majuk@75-163-138-15.clsp.qwest.net> has quit IRC | 03:08 | |
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 03:12 | |
*** bavery_fn <bavery_fn!~bavery@134.134.139.76> has joined #yocto | 03:32 | |
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC | 03:33 | |
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC | 03:34 | |
*** bavery_fn <bavery_fn!~bavery@134.134.139.76> has quit IRC | 03:34 | |
*** dlan <dlan!~dennis@58.246.136.202> has joined #yocto | 03:35 | |
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 03:35 | |
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 03:44 | |
*** agust <agust!~agust@p50886E4C.dip0.t-ipconnect.de> has joined #yocto | 04:17 | |
*** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has joined #yocto | 04:21 | |
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 05:00 | |
*** kaspter <kaspter!~Thunderbi@115.216.25.198> has quit IRC | 05:01 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 05:02 | |
*** CoLa|work <CoLa|work!~cordlandw@91.239.177.14> has joined #yocto | 05:09 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-xtgyggmdkjduuypj> has quit IRC | 05:15 | |
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-ivzdmznlrwkgvjnw> has quit IRC | 05:28 | |
*** ariel <ariel!~quassel@192.100.196.178> has joined #yocto | 05:40 | |
*** desert <desert!~quassel@201.157.98.178> has quit IRC | 05:40 | |
*** pohly <pohly!~pohly@p54BD5098.dip0.t-ipconnect.de> has joined #yocto | 05:47 | |
*** jmtt <jmtt!~jmtt@2601:1c0:6a00:8a30:d353:600c:82e0:9c5c> has quit IRC | 05:48 | |
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 05:59 | |
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 06:17 | |
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC | 06:25 | |
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto | 06:28 | |
*** Bunio_FH <Bunio_FH!~bunio@213.46.252.136> has joined #yocto | 06:46 | |
*** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 06:48 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 06:56 | |
*** Bunio_FH1 <Bunio_FH1!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 07:00 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 07:00 | |
*** fl0v0 <fl0v0!~fvo@i577A65C8.versanet.de> has joined #yocto | 07:00 | |
*** Bunio_FH <Bunio_FH!~bunio@213.46.252.136> has quit IRC | 07:01 | |
*** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-84-4.fbx.proxad.net> has joined #yocto | 07:05 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 07:07 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 07:12 | |
*** rajm <rajm!~robertmar@148.252.241.226> has joined #yocto | 07:14 | |
*** diego_r <diego_r!~diego@host57-224-static.7-79-b.business.telecomitalia.it> has joined #yocto | 07:18 | |
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-plepxhujbpbssqku> has joined #yocto | 07:22 | |
*** mckoan|away is now known as mckoan | 07:23 | |
*** marble_visions <marble_visions!~marble_vi@46.101.108.79> has quit IRC | 07:43 | |
*** marble_visions <marble_visions!~marble_vi@46.101.108.79> has joined #yocto | 07:44 | |
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has joined #yocto | 07:53 | |
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:103c:8119:fc4:f434> has joined #yocto | 08:00 | |
*** skz81 <skz81!~SKZ@LFbn-1-7725-55.w92-167.abo.wanadoo.fr> has joined #yocto | 08:00 | |
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:103c:8119:fc4:f434> has quit IRC | 08:02 | |
*** anujm <anujm!~anujm@192.198.146.173> has quit IRC | 08:29 | |
*** kaspter <kaspter!~Thunderbi@115.216.25.198> has joined #yocto | 08:42 | |
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 08:44 | |
*** anujm <anujm!~anujm@192.198.146.173> has joined #yocto | 08:51 | |
*** gondor <gondor!~gond@5-13-163-253.residential.rdsnet.ro> has joined #yocto | 09:21 | |
gondor | hi everybody | 09:21 |
---|---|---|
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? | 09:21 |
rburton | write a recipe which builds a package that contains that file | 09:22 |
gondor | KERNEL_MODULE_AUTOLOAD will create 1 .conf file there per entry | 09:22 |
gondor | so can't use an existing yocto mechanism at this point? | 09:22 |
gondor | the yocto docs say: | 09:26 |
gondor | Specify it as follows: | 09:26 |
gondor | KERNEL_MODULE_AUTOLOAD += "module_name1 module_name2 module_name3" | 09:26 |
gondor | 09:26 | |
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. | 09:26 |
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 | 09:27 |
gondor | but by experimenting it seems that yocto does the last one | 09:28 |
rburton | does it matter? | 09:30 |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 09:32 | |
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 | 09:33 |
gondor | I need some kernel modules to be loaded in a particular order | 09:33 |
*** alinucs <alinucs!~abo@static-176-158-51-218.ftth.abo.bbox.fr> has joined #yocto | 09:34 | |
gondor | looks like I'll have to stick with adding the file through a recipe as you suggested | 09:35 |
gondor | would have preferred to use the yocto AUTOLOAD mechanism though | 09:35 |
*** nighty- <nighty-!~nighty@kyotolabs.asahinet.com> has quit IRC | 09:38 | |
*** kaspter <kaspter!~Thunderbi@115.216.25.198> has quit IRC | 09:55 | |
*** kaspter <kaspter!~Thunderbi@115.195.44.89> has joined #yocto | 09:56 | |
*** sjolley <sjolley!~sjolley@134.134.139.73> has quit IRC | 10:04 | |
*** richardgolledge <richardgolledge!~richardgo@82.109.252.34> has quit IRC | 10:12 | |
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 10:13 | |
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? | 10:15 |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-yiblfizfvdwnlprp> has joined #yocto | 10:15 | |
*** mckoan is now known as mckoan|away | 10:26 | |
RP | rburton: deciding to add in the mesa upgrade was a disaster, sorry :( | 10:27 |
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has quit IRC | 10:27 | |
rburton | mesa is great at pain :) | 10:27 |
RP | rburton: still one mystery selftest regression to isolate too | 10:27 |
RP | rburton: and the gitsm patch broke, again. I've replied on list about that | 10:28 |
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 | 10:29 |
rburton | RP: i'll push the needed fixes to meta-mingw now | 10:29 |
RP | rburton: don't I have those? | 10:31 |
rburton | dunno haven't looked at next ;) | 10:32 |
rburton | one sec rebasing | 10:32 |
rburton | RP: drop '2018-06-05 13:49 Ross Burton o qemu: only build SDL UI if X11 is enabled' | 10:32 |
RP | rburton: ok | 10:35 |
RP | rburton: I've updated the branch and sent that staticdev fix | 10:37 |
*** sjolley <sjolley!~sjolley@134.134.139.73> has joined #yocto | 11:00 | |
*** Bunio_FH1 <Bunio_FH1!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 11:00 | |
*** Bunio_FH <Bunio_FH!~bunio@213.46.252.136> has joined #yocto | 11:02 | |
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC | 11:04 | |
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has quit IRC | 11:25 | |
*** nayfe_ <nayfe_!a5e14c82@gateway/web/freenode/ip.165.225.76.130> has joined #yocto | 11:25 | |
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto | 11:31 | |
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has quit IRC | 11:32 | |
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto | 11:33 | |
*** lfa <lfa!~lfa@217.19.35.51> has quit IRC | 11:33 | |
*** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-84-4.fbx.proxad.net> has quit IRC | 11:33 | |
*** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 11:34 | |
*** aratiu <aratiu!~adi@80.97.64.55> has quit IRC | 11:45 | |
*** aratiu <aratiu!~adi@80.97.64.55> has joined #yocto | 11:46 | |
*** slips <slips!~slips@201.51-174-113.customer.lyse.net> has quit IRC | 11:47 | |
*** slips <slips!~slips@201.51-174-113.customer.lyse.net> has joined #yocto | 11:52 | |
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has joined #yocto | 11:57 | |
yocti | New news from stackoverflow: Yocto: oe_runmake failed, iMX6 Apalis <https://stackoverflow.com/questions/50719943/yocto-oe-runmake-failed-imx6-apalis> | 12:06 |
*** droman <droman!~david@nat01.ifae.es> has joined #yocto | 12:06 | |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 12:08 | |
sveinse | When is the next yocto release scheduled? | 12:12 |
sveinse | Will Qt 5.11 be a part of any yocto release any time soon? | 12:12 |
nayfe_ | sveinse: maybe ask mikko.gronoff@qt.io directly ? | 12:15 |
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) | 12:15 |
nayfe_ | as rburton says :) | 12:15 |
JaMa | sveinse: 5.11 is already in meta-qt5/master for couple months | 12:16 |
JaMa | with the final revision in jansa/master currently | 12:16 |
*** nighty- <nighty-!~nighty@s229123.ppp.asahi-net.or.jp> has joined #yocto | 12:20 | |
*** rubdos <rubdos!~rubdos@ptr-1uzevqefjgxdm5wv65h.18120a2.ip6.access.telenet.be> has quit IRC | 12:20 | |
*** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-84-4.fbx.proxad.net> has joined #yocto | 12:28 | |
otavio[m] | RP: hello. We found that bitbake 1.38 branch did not update it's version. It still shows 1.37 | 12:32 |
*** rubdos <rubdos!~rubdos@ptr-1uzevqefjgxdm5wv65h.18120a2.ip6.access.telenet.be> has joined #yocto | 12:35 | |
RP | otavio[m]: oops. Fixed | 12:35 |
otavio[m] | :-) | 12:37 |
otavio[m] | RP: I am checking mesa error too | 12:37 |
RP | otavio[m]: thanks | 12:37 |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 12:55 | |
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-plepxhujbpbssqku> has quit IRC | 13:00 | |
sveinse | rburton: Isn't "rocko" or "sumo" a Yocto release? https://wiki.yoctoproject.org/wiki/Releases | 13:00 |
*** marka <marka!~masselst@128.224.252.2> has joined #yocto | 13:01 | |
*** RyFa <RyFa!~ryan.farr@74-92-46-229-NewEngland.hfc.comcastbusiness.net> has joined #yocto | 13:08 | |
varjag | dear 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 IRC | 13:13 | |
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 | 13:15 |
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto | 13:16 | |
RyFa | Im also trying to udate the kernel for my image | 13:16 |
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 13:18 | |
varjag | RyFa: that's what i've been doing, but it takes half a workday initially | 13:26 |
varjag | then i tried bitbake -c cleanall the image, and then bitbake it again | 13:27 |
varjag | but it fails complaining some cryptodev module missing | 13:27 |
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. | 13:29 |
RyFa | Do you happen to get that same error in every case? | 13:29 |
varjag | that's not a major change | 13:29 |
varjag | to generate an image | 13:29 |
varjag | it's not like i was rebuilding the host toolchain | 13:30 |
varjag | yeah same | 13:30 |
varjag | guess i go bug our vendor with this | 13:30 |
RyFa | do oyu have a cryptodev recipe somewhere in your project? | 13:31 |
varjag | not me | 13:31 |
RyFa | check this out: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=cryptodev | 13:31 |
varjag | but it's yocto, so billion of the vendor layers mixed | 13:31 |
RyFa | you may be able to add one based on this | 13:31 |
varjag | mm thanks i'll look at this | 13:32 |
varjag | but it builds fine from clean state with the same recipe, that's what is strange | 13:32 |
*** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has quit IRC | 13:34 | |
*** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has joined #yocto | 13:36 | |
RyFa | hhm yeah - its beyond my knowledge | 13:36 |
marka | there is no reason to kill tmp when you change the kernel | 13:37 |
marka | I am not sure what you are observing but everything should just work | 13:38 |
*** gondor <gondor!~gond@5-13-163-253.residential.rdsnet.ro> has quit IRC | 13:38 | |
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 | 13:39 |
varjag | ha.. does it have to be virtual/kernel? | 13:40 |
varjag | because i am rebuilding the vendor package name | 13:41 |
marka | I use virtual/kernel as it saves me having to figure out what kernel is in play | 13:41 |
varjag | bitbake linux-variscite.. | 13:41 |
varjag | bitbaking this one does not invalidate the cache | 13:41 |
*** bavery_fn <bavery_fn!bavery@nat/intel/x-qatogafhrqxkiktz> has joined #yocto | 13:41 | |
varjag | if i bake image it runs no tasks | 13:41 |
marka | then your image is not using this kernel | 13:42 |
varjag | doubt it, the changes i did in the kernel tree show up in sysfs | 13:42 |
varjag | hm. | 13:43 |
marka | if you are changing linux-variscite and then rebuilding your image and no tasks are run | 13:44 |
marka | then there is no dependency in the image on linux-variscite | 13:44 |
*** stephano <stephano!~stephano@c-67-189-76-218.hsd1.or.comcast.net> has joined #yocto | 13:44 | |
marka | do 'bitbake <your_image> -e | tee outme' | 13:45 |
marka | then 'grep PREFERRED_PROVIDER_virtual/kernel outme' | 13:45 |
marka | if virtual/kernel is not linux-variscite then it is just a clinger | 13:46 |
varjag | marka: i .bbappended varistite recipe to use my repo with the set of device drivers i need | 13:46 |
varjag | and when i build it from clean state, the drivers show up with node names i assigned | 13:46 |
varjag | ok i'll look into that.. | 13:47 |
mario-goulart | Hey marka. Sorry, I hadn't seen your messages here yesterday. | 13:47 |
marka | mario-goulart: no problem | 13:47 |
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 | 13:48 |
varjag | ok, i'll check, thanks | 13:49 |
marka | it is often worth the time to setup a "pure" yocto build with core-image-minimal and qemu-x86-64 to compare against | 13:50 |
marka | you can setup a shared DL_DIR to save some time and disk space | 13:51 |
rburton | sveinse: rocko/sumo/etc are oe-core and poky releases | 13:53 |
kanavin | RP: no idea, have never seen this kind of checksum failure before | 14:03 |
kanavin | RP: "libgstfft-1.0-0-1.14.0-r0.0.core2_64: sha256 check failed: 36b24cf863c232197c9660029fb5590665a86023b32f17d5a2d000e5c0e7e1c1 vs 178f1e86a46fe8457d768d65d0b3cdaa0022611705af7fb89131bf6f5a54c357" | 14:03 |
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 | 14:04 |
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has quit IRC | 14:08 | |
RP | kanavin: indeed. I don't understand it | 14:09 |
RP | kanavin: another question since you're here :) | 14:09 |
kanavin | RP: I am transitioning to 'kanavin_home' nickname :) | 14:10 |
kanavin | but so far, this one still works :) | 14:10 |
RP | kanavin: I can use either :) | 14:10 |
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? | 14:10 |
*** agust <agust!~agust@p50886E4C.dip0.t-ipconnect.de> has quit IRC | 14:10 | |
RP | kanavin: https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/1099/steps/Running%20oe-selftest/logs/stdio | 14:11 |
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? | 14:11 |
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' | 14:12 |
kanavin | :) | 14:12 |
RP | kanavin: no more info in there | 14:13 |
kanavin | RP: you probably need this patch: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=ce12d183bb0a3366d37855e18452ac6ee6215be3 | 14:15 |
kanavin | RP: but it's already in master I think :/ | 14:15 |
RP | kanavin: I think that was already in that build, yes | 14:16 |
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 | 14:17 |
kanavin | or preuns | 14:17 |
RP | kanavin: http://dan.rpsys.net/log.do_rootfs.39609 | 14:22 |
*** agust <agust!~agust@p50886E4C.dip0.t-ipconnect.de> has joined #yocto | 14:24 | |
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' | 14:25 |
kanavin | RP: this de-installation is not handled through dnf, but through rpm directly, and so extra verbosity is not in effect | 14:25 |
kanavin | RP: don't remember right now where in rootfs.py or package_manager.py that happens | 14:25 |
RP | kanavin: ah, we should perhaps try and improve that if we can then... | 14:26 |
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. | 14:27 |
RP | kanavin: do you know what the switch is offhand? | 14:28 |
kanavin | RP: -v, or maybe even -vv :) just looked up in the manpage | 14:29 |
kanavin | ah, -v is already there | 14:29 |
kanavin | -vv then | 14:29 |
RP | kanavin: thanks, lets see if I can add debugging assume it reproduces | 14:31 |
kanavin | RP: " args = ["-e", "-v", "--nodeps", "--root=%s" %self.target_rootfs]" in package_manager.py | 14:31 |
RP | kanavin: thanks :) | 14:32 |
*** majuk <majuk!~majuk@75-163-138-15.clsp.qwest.net> has joined #yocto | 14:35 | |
RP | kanavin: would you believe this isn't much more helpful :( | 14:38 |
kanavin | RP: :-( | 14:39 |
RP | kanavin: https://pastebin.com/u79apLR2 | 14:39 |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 14:41 | |
*** learningc <learningc!~User@210.195.54.102> has joined #yocto | 14:45 | |
*** mrk377 <mrk377!442d9918@gateway/web/freenode/ip.68.45.153.24> has quit IRC | 14:47 | |
kanavin | RP: try -d. Just reading source code for rpm, man page is not helpful :) | 14:48 |
kanavin | RP: ah, wait | 14:49 |
*** Bunio_FH <Bunio_FH!~bunio@213.46.252.136> has quit IRC | 14:56 | |
*** anujm <anujm!~anujm@192.198.146.173> has quit IRC | 15:00 | |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 15:01 | |
kanavin | RP: 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.165.225.76.130> has quit IRC | 15:03 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 15:05 | |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 15:06 | |
*** AbleBacon <AbleBacon!~AbleBacon@unaffiliated/ablebacon> has joined #yocto | 15:06 | |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 15:06 | |
kanavin | RP: maybe we're best off bisecting this? It certainly used to work, didn't it? | 15:07 |
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 | 15:07 |
kanavin | RP: I guess that's the most we can get out of rpm :-/ | 15:08 |
RP | fray: any ideas on getting more info from rpm preun? | 15:09 |
RP | kanavin: shadow preun only calls update-altnatives afaict too | 15:09 |
*** Bunio_FH <Bunio_FH!~bunio@89.146.36.42> has joined #yocto | 15:09 | |
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. | 15:14 |
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 15:16 | |
*** Bunio_FH <Bunio_FH!~bunio@89.146.36.42> has quit IRC | 15:17 | |
*** cfriedrich <cfriedrich!~cfriedric@en.cgn-4.gcxi.de> has quit IRC | 15:18 | |
RP | kanavin: I'm not surprised :( | 15:20 |
*** droman <droman!~david@nat01.ifae.es> has quit IRC | 15:22 | |
*** diego_r <diego_r!~diego@host57-224-static.7-79-b.business.telecomitalia.it> has quit IRC | 15:23 | |
*** diego_ <diego_!~diego@host57-224-static.7-79-b.business.telecomitalia.it> has joined #yocto | 15:23 | |
kanavin | RP: let me try another idea, wait a moment | 15:24 |
* armpit the joys of backporting spectre | 15:25 | |
kanavin | RP: no, false lead. Something breaks down before shell executes actual lines, I believe | 15:30 |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 15:36 | |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 15:36 | |
*** clement <clement!~clement@LNeuilly-657-1-4-190.w81-250.abo.wanadoo.fr> has quit IRC | 15:36 | |
*** clement_ is now known as clement | 15:36 | |
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.... | 15:38 |
fray | but if the preun fails, then the scriptlet that failed will remain on the disk int he tmp location as well.. | 15:39 |
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' | 15:39 |
*** jcstach <jcstach!~jcstach@4.59.252.60> has quit IRC | 15:41 | |
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 15:44 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 15:49 | |
RP | kanavin: that would match the 127 exit code | 15:52 |
*** jcstach <jcstach!~jcstach@ec2-54-177-74-133.us-west-1.compute.amazonaws.com> has joined #yocto | 15:54 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-wtdhqqjjoaoemlgj> has joined #yocto | 15:56 | |
*** mihai- is now known as mihai | 15:58 | |
*** scottrif <scottrif!~scottrif@47-40-108-60.dhcp.knwc.wa.charter.com> has joined #yocto | 15:59 | |
*** gabrbedd <gabrbedd!~beddingfi@li680-65.members.linode.com> has joined #yocto | 16:02 | |
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. | 16:06 |
RP | kergoth: no | 16:07 |
kergoth | k | 16:07 |
*** fl0v0 <fl0v0!~fvo@i577A65C8.versanet.de> has quit IRC | 16:07 | |
RP | rburton, kanavin: I reproduced that failure on centos7 with master, so its nothing in -next | 16:08 |
RP | which is good and bad | 16:08 |
*** Kakounet <Kakounet!~Thunderbi@che44-1-88-163-84-4.fbx.proxad.net> has quit IRC | 16:08 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 16:11 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 16:13 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 16:18 | |
*** skz81 <skz81!~SKZ@LFbn-1-7725-55.w92-167.abo.wanadoo.fr> has quit IRC | 16:19 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 16:20 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 16:21 | |
*** skz81 <skz81!~SKZ@LFbn-1-7725-55.w92-167.abo.wanadoo.fr> has joined #yocto | 16:22 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 16:23 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 16:25 | |
*** learningc <learningc!~User@210.195.54.102> has quit IRC | 16:28 | |
khem | RP: https://pastebin.ca/4038573 | 16:28 |
khem | RP: thats the gcc8 SDK output when someone specifies -mspe | 16:29 |
*** igor <igor!bb6c2acb@gateway/web/freenode/ip.187.108.42.203> has joined #yocto | 16:29 | |
RP | khem: can you build gcc with spe enabled though? | 16:29 |
khem | no | 16:30 |
RP | khem: that is no longer possible at all? | 16:30 |
igor | hi guys, how can I build an ISO image? | 16:30 |
khem | the backend is different now | 16:30 |
khem | we need to add another tuple to supported machines | 16:30 |
igor | I set IMAGE_FSTYPES = "iso hddimg", but it is building only hddimg | 16:30 |
igor | on log.do_bootimg I saw that INITRD is not set | 16:31 |
igor | so I tried to set INITRD = "${INITRD_LIVE}", but it did not work | 16:31 |
igor | so, there is a default initramfs to put on INITRD var to build a iso? | 16:32 |
RP | khem: I still think there may be a problem lurking in there, I'm having trouble explaining it though :/ | 16:32 |
khem | igor: meta/conf/machine/include/x86-base.inc:NOISO ?= "1" you need to set NOISO = "0" | 16:32 |
igor | Thank you very mutch Khem | 16:33 |
* RP thinks NOISO needs to die in favour of IMAGE_FSTYPES | 16:33 | |
khem | RP: a subset of freescale ppc impl used SPE newer PPC impls from them has altivec | 16:33 |
rburton | RP: yes, that burnt me recently too | 16:33 |
khem | RP: so older ppc from freescale is primarily what uses spe | 16:34 |
khem | the newer ones they dont have spe and thats also probably one reason there is no interest in maintaining it upstream | 16:34 |
RP | khem: we don't have any machines in core which use spe right? | 16:35 |
khem | I think our ref board is can you tell me the name :( | 16:35 |
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 | 16:35 |
RP | rburton, kanavin: 762a3f229c42b734160334fb462beaf576353a58 breaks, 6db8b6a77723f1e3a34d61ffd96c196e03ace164 does not | 16:35 |
igor | I put a deltask bootimg on my recipe because I didnt found how to remove image-live from inherited classes | 16:36 |
igor | there is a better way to do that or deltask is the best option? | 16:36 |
RP | igor: bootimg isn't a task, its a class | 16:36 |
igor | on branch sumo it is a task on image-live called do_bootimg | 16:37 |
igor | it runs build_hddimg and build_iso | 16:37 |
RP | igor: hmm, I see what you mean. I think that task is needed as part of image-live | 16:37 |
igor | yes | 16:38 |
igor | but my image is tar.bz2 and dont need this | 16:38 |
RP | igor: what do you have IMAGE_FSTYPES set to? | 16:38 |
igor | IMAGE_FSTYPES = "tar.bz2" | 16:38 |
RP | igor: can you check that with bitbake -e ? | 16:39 |
igor | on bitbake -e , the build_live function is returning empty string, but the image-live class still include in BBINCLUDED | 16:40 |
igor | yes | 16:40 |
RP | rburton, kanavin: This is looking like http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b7f6638962b0348ae93c1d5a7696c80e2b7933ed as the change which breaks it :/ | 16:40 |
RP | igor: that seems odd :( | 16:41 |
RP | igor: you're not trying to do this in individual images are you? | 16:41 |
igor | RP: # "tar.bz2" IMAGE_FSTYPES="tar.bz2" | 16:41 |
khem | RP: our ref board in core is mpc8315erdb which is e300c3 core which is implementing proper FPU and doesnt have SPE AFAICT | 16:42 |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 16:42 | |
rburton | fwiw i've an image recipe that does successfully build just a targz | 16:42 |
igor | RP: but when I see the var BOOTIMG_EXTRA_SPACE for example, it was set by image-live.bbclass | 16:42 |
khem | rburton/RP: is it possible for you to boot a gcc8 image on a ref board | 16:42 |
igor | and other vars too | 16:43 |
rburton | khem: i've a nuc | 16:44 |
RP | rburton: would be interesting to know if it still inherited the class though... | 16:44 |
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 | 16:45 |
igor | it was fixed few days ago, but the task do_bootimg sill added | 16:46 |
igor | but I solved this problema putting deltask bootimg on my recipe | 16:46 |
*** diego_r <diego_r!~diego@host57-224-static.7-79-b.business.telecomitalia.it> has joined #yocto | 16:46 | |
rburton | RP: it isn't | 16:46 |
*** diego_ <diego_!~diego@host57-224-static.7-79-b.business.telecomitalia.it> has quit IRC | 16:46 | |
RP | Saur: around? | 16:47 |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 16:48 | |
*** rajm <rajm!~robertmar@148.252.241.226> has quit IRC | 16:51 | |
RP | fray: does anything jump out to you in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b7f6638962b0348ae93c1d5a7696c80e2b7933ed as causing that preun problem? | 16:55 |
fray | looking | 16:55 |
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 | 16:57 |
fray | lua change, as far as I know we're not using lua in any preuns | 16:57 |
fray | ++open_max = sysconf(_SC_OPEN_MAX); | 16:57 |
fray | ++if (open_max == -1) { | 16:57 |
fray | ++open_max = 1024; | 16:57 |
fray | ++} | 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 | ++continue; | 16:57 |
fray | ++fcntl(fdno, F_SETFD, FD_CLOEXEC); | 16:57 |
fray | ++} | 16:57 |
fray | ++} | 16:57 |
fray | Ohhh.. this would be closing pseudo stuff too... | 16:57 |
fray | could that be causing a problem? | 16:58 |
RP | fray: yes, that could | 16:58 |
fray | second patch file changes the above, but conceptually it's still doing the same thing | 16:59 |
*** gtristan <gtristan!~tristanva@199.241.135.253> has joined #yocto | 16:59 | |
fray | also iterates over /proc -- but proc will be able to see the pseudo fds | 17:00 |
fray | so ya.. it's likely breaking the connection on exec with pseudo -- but I don't know the exact ramifications of that | 17:00 |
*** igor <igor!bb6c2acb@gateway/web/freenode/ip.187.108.42.203> has quit IRC | 17:00 | |
fray | (and it's breaking them cause it's blindly adjusting -all- fds, not just the ones that rpm itself created) | 17:00 |
RP | fray: I wonder if the "+x" bit disappears on the script | 17:01 |
fray | as in set +x? | 17:01 |
fray | or execute | 17:01 |
RP | fray: execute | 17:01 |
RP | hence the exit 127 | 17:01 |
fray | scriptlets SHOULD be executed as 'interpreter <script>' | 17:01 |
*** tgraydon <tgraydon!~textual@134.134.139.72> has joined #yocto | 17:02 | |
fray | if you are getting 127, that seems an aweful lot like the interpreter failed | 17:02 |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 17:02 | |
fray | going to look quick to verify what I said is still true | 17:02 |
fray | (this master?) | 17:02 |
fray | there 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 |
fray | so that will affect where the scriptlet is trying to run, as well as the script engine | 17:04 |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-yiblfizfvdwnlprp> has quit IRC | 17:04 | |
*** diego_r <diego_r!~diego@host57-224-static.7-79-b.business.telecomitalia.it> has quit IRC | 17:05 | |
RP | fray: yes, this is master | 17:05 |
fray | so ya.. I'd say the first thing to try is disable the close all fds on exec thing.. | 17:08 |
fray | if that fixes the problem, then it's likely either pseudo or some other glibc thing | 17:08 |
fray | (like nss...) | 17:08 |
*** mrk377 <mrk377!442d9918@gateway/web/freenode/ip.68.45.153.24> has joined #yocto | 17:08 | |
fray | ohh other thing.. rpm -qp <package> --scripts take a look and verify the preun is reasonable.. ;) | 17:09 |
RP | fray: I did read the spec file. What is odd is this works on some machines but not centos7 | 17:11 |
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 | 17:12 |
fray | I think rpm -qp <...> --scripts will show you that | 17:12 |
RP | fray: interestingly, #!/bin/sh is encoded in, and it isn't in the postinst | 17:13 |
fray | preinstall scriptlet (using /bin/sh): | 17:13 |
fray | # base-files - preinst | 17:13 |
fray | set -e | 17:13 |
fray | #!/bin/sh -e | 17:13 |
fray | if [ x"$D" = "x" ]; then | 17:13 |
fray | ya.. something like that.. | 17:13 |
RP | fray: this is shadow | 17:14 |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 17:14 | |
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 | 17:14 |
fray | (generated spec file) | 17:14 |
fray | I can try to activate RPM and build shadow stuff... I don't have any current builds that I found | 17:15 |
fray | (BTW I am using CentOS 7 as well) | 17:16 |
RP | fray: the reproducer is IMAGE_FEATURES += "read-only-rootfs" bitbake core-image-sato on centos 7 | 17:16 |
fray | ok. I'll try that next once I get just shadow built and inspect it | 17:17 |
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 | 17:19 |
fray | 'which debugging' are you referring to? | 17:20 |
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.. | 17:20 |
fray | by default though scriptlet output is silenced to /dev/null | 17:20 |
RP | kanavin_home: I think some filehandle is disappearing so it isn't running anything | 17:20 |
kanavin_home | fray: '-vv' when installing or removing packages | 17:21 |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 17:21 | |
fray | preuninstall scriptlet (using /bin/sh): | 17:21 |
fray | # shadow - prerm | 17:21 |
fray | #!/bin/sh | 17:21 |
fray | if [ "$1" = "0" ] ; then | 17:21 |
fray | set -e | 17:21 |
fray | update-alternatives --remove passwd /usr/bin/passwd.shadow | 17:21 |
fray | update-alternatives --remove chfn /usr/bin/chfn.shadow | 17:21 |
fray | update-alternatives --remove chsh /usr/bin/chsh.shadow | 17:21 |
fray | update-alternatives --remove chpasswd /usr/sbin/chpasswd.shadow | 17:21 |
fray | update-alternatives --remove vipw /sbin/vipw.shadow | 17:21 |
fray | update-alternatives --remove vigr /sbin/vigr.shadow | 17:21 |
fray | update-alternatives --remove nologin /sbin/nologin.shadow | 17:21 |
fray | fi | 17:21 |
fray | that is what I got.. which all seems reasnable | 17:21 |
RP | fray: note how it starts with #!/bin/sh where as the postinst doesn't | 17:22 |
fray | ya, doesn't matter | 17:22 |
fray | the '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!~SKZ@LFbn-1-7725-55.w92-167.abo.wanadoo.fr> has quit IRC | 17:23 | |
fray | it should be the equivalent of: | 17:23 |
fray | cat << EOF | 17:23 |
fray | <scriptlet> | 17:23 |
fray | EOF | 17: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 |
RP | fray: ok, curious if you can reproduce | 17:24 |
* fray is testing the task accounting.. it's still working.. :) only two fetches at once | 17:24 | |
kanavin_home | RP: I do wonder if ' rpm: Restore performance in Docker containers' is the commit we're after | 17:28 |
fray | my guess is it is, and it's related to changing all file descriptions | 17:28 |
RP | kanavin_home: bisection says yes | 17:31 |
kanavin_home | RP: that is a bit of a :-( | 17:31 |
kanavin_home | as I think those patches are direct backports from rpm upstream? | 17:32 |
RP | kanavin_home: well, yes. Upstream don't have pseudo around for example though | 17:32 |
RP | so I can at least see how this might break | 17:32 |
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. | 17:33 |
kanavin_home | I guess we need to notify Peter | 17:33 |
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:4811:e8ec:aa33:10ab> has joined #yocto | 17:34 | |
fray | it didn't look like it blindly closed 1024 fds before.... it looks like this three patch series added that | 17:40 |
RP | kanavin_home: unless pseudo uses high number fds for its own use? | 17:40 |
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" | 17:40 |
fray | the third in the series adds the capability to look in /proc for the actual pids being used | 17:40 |
kanavin_home | fray: it did | 17:40 |
fray | so lets say it is a pid above 1024.. then it would now know it | 17:40 |
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? | 17:41 |
kanavin_home | fray: - 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 |
fray | I thought that was the second hunk | 17:42 |
fray | I don't have the patch up on my screen anymore though | 17:42 |
fray | just re-read it.. you are right.. it was blindly closing before | 17:43 |
kanavin_home | RP: could well be. Just like I told you, that newly added /proc iteration code has *no* debugging whatsoever in it :( | 17:43 |
kanavin_home | so someone needs to add it ad hoc to see what is actually being closed | 17:43 |
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) | 17:44 |
kanavin_home | fray: that will make Docker using people very unhappy, particularly Peter Kjellerstedt | 17:47 |
kanavin_home | is he here? | 17:47 |
*** martinkelly <martinkelly!~martin@65-122-179-226.dia.static.qwest.net> has joined #yocto | 17:47 | |
fray | ya, but if it makes everyone else unhappy.. that's a valid tradeoff.. | 17:49 |
fray | ok.. I got the failure on my CentOS box you guys are talking aobut.. | 17:49 |
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) | 17:49 |
*** morphis__ <morphis__!~morphis@pD9ED633E.dip0.t-ipconnect.de> has joined #yocto | 17:53 | |
fray | ...and ninja fails AGAIN to build DNF.. retry | 17:55 |
fray | it always seems to fail the first time around, but always on different files.. :| | 17:55 |
fray | I'm tempted to restrict DNF to a small number of build threads | 17:56 |
*** morphis_ <morphis_!~morphis@pD9ED79F6.dip0.t-ipconnect.de> has quit IRC | 17:57 | |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 17:58 | |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 17:59 | |
*** denix is now known as darknighte | 18:03 | |
*** darknighte is now known as denix | 18:04 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 18:04 | |
fray | I disabled the /proc stuff and it still failed.. | 18:04 |
fray | disabling the Facctor-out-and-unify now | 18:04 |
*** tgraydon <tgraydon!~textual@134.134.139.72> has quit IRC | 18:06 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-wtdhqqjjoaoemlgj> has quit IRC | 18:06 | |
RP | fray: the failure should be in do_rootfs | 18:07 |
fray | yup.. thats where it failed | 18:07 |
RP | fray: ok | 18:07 |
*** tgraydon <tgraydon!~textual@134.134.139.72> has joined #yocto | 18:07 | |
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 | 18:07 |
RP | fray: note that there is a revert in the previous commit too | 18:08 |
RP | fray: I bisected it to these two commits, I didn't test the midpoint (yet) | 18:09 |
fray | ok | 18:09 |
RP | fray: its useful to know its reproducible though, thanks | 18:13 |
RP | that midpoint is rebuilding lots so will take a while to test | 18:14 |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 18:15 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 18:17 | |
khem | RP: looking more into it, I think we are at a cross road for ppc | 18:21 |
khem | RP: it seems most of fsl ppc uses SPE except SoCS based on e6500 cores | 18:22 |
Crofton|work | khem, if no one steps up, we should drop it | 18:22 |
khem | right now its holding gcc8 ransom | 18:22 |
Crofton|work | also, any suggetions on my FORTRAN problem :) | 18:22 |
khem | did you reply to my question | 18:23 |
RP | Crofton|work: use a modern language ;-) | 18:23 |
* Crofton|work curses scipy | 18:23 | |
Crofton|work | khem, yes | 18:24 |
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 | 18:24 |
Crofton|work | I find the spec.in gfile only | 18:24 |
RP | khem: right, someone should really step up who cares about ppc to do this... | 18:24 |
fray | kanavin_home: If I remove: # file://0001-Factor-out-and-unify-setting-CLOEXEC.patch \ | 18:25 |
fray | and the two susbequent ones it now works.. | 18:25 |
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 | 18:25 |
khem | that will let people use gcc7 for ppc | 18:25 |
fray | if I KEEP that one, and remove only the subsequent two it does NOT work | 18:25 |
fray | so something is wrong in the refactoring | 18:25 |
Crofton|work | khem, | 18:26 |
Crofton|work | [balister@prague build-pi]$ find ./tmp-glibc/ -name "libgfortran.spec*" | 18:26 |
Crofton|work | ./tmp-glibc/work-shared/gcc-7.3.0-r0/gcc-7.3.0/libgfortran/libgfortran.spec.in | 18:26 |
khem | We folks who are interested in SPE can pin to gcc7 and we can move on | 18:26 |
khem | Crofton|work: is it in sysroot of the package you are building | 18:26 |
Crofton|work | ah khem really cares :) | 18:26 |
Crofton|work | look carefully | 18:27 |
Crofton|work | I search all of tmp | 18:27 |
Crofton|work | and only see .in version | 18:27 |
kanavin_home | fray: the refactoring moved from hardcoding first 1024 fds to iterating over open ones in /proc/self/fd | 18:27 |
khem | hmm if you enabled fortan in gcc then you should have had one | 18:27 |
kanavin_home | so probably they now close something they should now | 18:27 |
fray | it's the patch 0001-Factor-out-and-unify-setting-CLOEXEC.patch | 18:28 |
fray | if applied it failed | 18:28 |
fray | I don't see any obvious reason why it would fail, or why the refactoring code is wrong | 18:28 |
khem | Crofton|work: no way, I have no interest in ppc as all that 'We' is just to pretent inclusive | 18:28 |
fray | the 0001-Factor... patch seems straight forward though | 18:29 |
fray | and it claimes to be accepted upstream in a newer version of RPM | 18:29 |
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... | 18:29 |
fray | the 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 |
fray | which should not be a problem | 18:30 |
Crofton|work | khem exactly | 18:30 |
Crofton|work | https://paste.debian.net/1028244/ | 18:31 |
Crofton|work | the fortan binary is there, but no spec file is created | 18:31 |
kanavin_home | fray: bizarre, it doesn't seem to actually change the code? | 18:32 |
khem | Crofton|work: do you have libgfortan built ? | 18:32 |
khem | RP: I can switch to using powerpcspe backend as well, I wonder if we have non fsl ppc users | 18:33 |
khem | they will be at a loss | 18:33 |
Crofton|work | apparently not | 18:33 |
fray | kanavin_home agreed.. but it doesn't work with the patch, and does work with it (on my system) | 18:33 |
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 | 18:34 |
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 | 18:34 |
kanavin_home | fray: are you super-sure though? maybe you mixed up the patches | 18:34 |
Crofton|work | fark | 18:34 |
Crofton|work | DEPENDS = "gcc-runtime" | 18:35 |
fray | no.. I yanked them one at a time from the openembedded-core/meta/recipes-devtools/rpm/rpm_4.14.1.bb | 18:35 |
fray | I can repeat it.. | 18:35 |
khem | so what are folks doing with github repositories, migrating to gitlab :) | 18:36 |
fray | I just enabled the 0001- patch (and only that) and I'm building again.. will probab be 5-10 mins | 18:36 |
RP | fray: I'm trying that too, see if I can confirm | 18:36 |
Crofton|work | khem, thanks | 18:36 |
Crofton|work | I owe you a coke | 18:36 |
fray | ahh I have this run already in the sstate-cache.. so it might take less time | 18:37 |
khem | Crofton|work: I like the columbian one ;) | 18:37 |
* kanavin_home lives under a rock, what's the problem with github? | 18:38 | |
fray | yup.. failed when I re-enabled the patch | 18:38 |
khem | Crofton|work: https://asteroidos.org/ is based on OpenEmbedded why dont we add this to front page | 18:39 |
fray | github will soon be owned by Microsoft.. apparently that makes a difference to some | 18:39 |
Crofton|work | and gitlab is hosted on Azure I hear | 18:39 |
fray | I'll care about github when MS screws it up.. until then, whatever.. | 18:39 |
fray | I didn't care about sourceforge until they started to put ads and intersituals everywhere.. that was the end of me using them | 18:40 |
khem | I think MS has embrased OSS after new CEO | 18:40 |
kanavin_home | khem: embraced in a way that benefits Azure mostly | 18:40 |
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 | 18:41 |
khem | I already see it rotting. Last commit to this backend in gcc was on march 4th | 18:42 |
RP | khem: My worry is the shared single cross gcc powerpc binary for both spe and non-spe | 18:42 |
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.. | 18:43 |
RP | fray: confirmed, that patch does seem to break ot | 18:43 |
khem | I am sure RP will be happy about github :) | 18:43 |
fray | RP.. I'm not crazy then | 18:43 |
khem | RP: cant stand on two boats anymore since they are diverging the route | 18:43 |
khem | I think most of OE users of ppc are using fsl SoCs and that backend is going away | 18:44 |
RP | khem: I think you're right :( | 18:45 |
khem | the supported backend is nice but probbably not many users for OE | 18:45 |
RP | khem: this is what is worrying me | 18:45 |
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 | 18:46 |
RP | khem: I think so | 18:48 |
khem | OK let me redo the gcc8 patches for ppc portions | 18:48 |
khem | the arm tuning we can do as a seprate item lets not hold gcc8 for that | 18:49 |
fray | bingo | 18:50 |
fray | 181: 000000000000fae0 119 FUNC GLOBAL DEFAULT 11 rpmSetCloseOnExec | 18:50 |
fray | 181: 000000000000fae0 119 FUNC GLOBAL DEFAULT 11 rpmSetCloseOnExec | 18:50 |
fray | 181: 000000000000fae0 119 FUNC GLOBAL DEFAULT 11 rpmSetCloseOnExec | 18:50 |
fray | 180: 0000000000000000 0 FUNC GLOBAL DEFAULT UND rpmSetCloseOnExec | 18:50 |
fray | 180: 0000000000000000 0 FUNC GLOBAL DEFAULT UND rpmSetCloseOnExec | 18:50 |
fray | 180: 0000000000000000 0 FUNC GLOBAL DEFAULT UND rpmSetCloseOnExec | 18:50 |
fray | that's readelf.. the function is defined in ALL THREE librpms.. | 18:51 |
fray | so likely it's going nuts | 18:51 |
fray | wait... | 18:52 |
fray | no.. my mistake | 18:52 |
fray | it's onluy defined in librpmio.so* which is correct | 18:52 |
fray | ok.. so I'm at a loss as to why it fails.. the only difference seens to be a functional call vs not | 18:53 |
*** kaspter <kaspter!~Thunderbi@115.195.44.89> has quit IRC | 18:58 | |
RP | fray: compiler bug on centos7? | 18:58 |
*** kaspter <kaspter!~Thunderbi@115.195.44.89> has joined #yocto | 18:58 | |
RP | fray: actually, take a look at doScriptExec() in rpmscript.c | 19:01 |
RP | fray: the int xz | 19:01 |
RP | er, xx | 19:01 |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 19:01 | |
RP | fray: what does that if (xx == 0) do? | 19:01 |
*** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC | 19:01 | |
*** tgraydon <tgraydon!~textual@134.134.139.72> has quit IRC | 19:02 | |
* RP tries deleting that | 19:05 | |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 19:06 | |
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 19:07 | |
fray | where do you see the if xx == 0? | 19:09 |
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 | 19:09 |
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 19:10 | |
RP | fray: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/taa&id=e8dbc36b4dd61c7b747076be63a46b59ed3a5cf5 | 19:11 |
fray | huh | 19:11 |
fray | ya.. that definitely should be gone.. | 19:12 |
fray | cause xx will be undefined if the other setters don't work.. | 19:12 |
fray | if anything, i'd say the function be adjusted to return a similar return code and xx = rpmSetCloseOnExec() run | 19:13 |
fray | but that is probably not necessary | 19:13 |
fray | alternative 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) ;P | 19:13 |
RP | fray: well, if xx is meant to be ignored... | 19:14 |
fray | i.e. this is a mess | 19:14 |
fray | thats the thing, other parts of the code it's meant to be ignored.. | 19:14 |
RP | fray: yes, its very confused | 19:14 |
fray | it LOOSK like if scriptFd == NULL, then the last XX will be from the setfd. otherwise it'll be from the Fclose | 19:14 |
fray | I suspect the xx check is supposed to be from the Fclose.. but not sure.. (maybe git can tell me0 | 19:15 |
RP | fray: fwiw it works with that patch | 19:15 |
RP | so we at least know why it breaks | 19:15 |
RP | kanavin_home: mystery partly solved :) | 19:16 |
fray | yup | 19:16 |
fray | ok.. 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 |
RP | still in upstream git https://github.com/rpm-software-management/rpm/blob/master/lib/rpmscript.c#L222 | 19:17 |
fray | ya.. my guess is that CentOS 7 doesn't zero 'xx'.. while newer glibc/gcc does | 19:17 |
fray | thus the issue | 19:17 |
RP | fray: yes, different compilers, different results | 19:17 |
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.. | 19:18 |
RP | fray: agreed on both counts | 19:18 |
fray | with an alternative to set xx = 0 when defined at the top | 19:18 |
RP | fray: I'll submit a pull request to remove it, see what is said | 19:19 |
kanavin_home | RP: fray: I don't get it, xx does seem to be uncoditionally assigned before it's accessed? | 19:24 |
kanavin_home | xx = setenv("PATH", path, 1); | 19:24 |
*** [Sno] <[Sno]!~sno@b2b-78-94-80-58.unitymedia.biz> has joined #yocto | 19:25 | |
kanavin_home | ah wait, does the { } block create new scope in C? | 19:25 |
kanavin_home | if so, then reusing xx, and giving it a generic name in the first place is very silly indeed | 19:26 |
RP | kanavin_home: there shouldn't be different scope there | 19:27 |
kanavin_home | RP: then I don't understand :) | 19:28 |
*** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has quit IRC | 19:28 | |
kanavin_home | xx is set (through assignment from setenv) before it's accessed | 19:28 |
RP | https://github.com/rpm-software-management/rpm/pull/447 | 19:29 |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 19:29 | |
RP | kanavin_home: hmm. That is horrible code style. | 19:30 |
RP | kanavin_home: I'm also confused now, as you say, it should get zeroed | 19:33 |
RP | kanavin_home: I think its a gcc 4.8.5 compiler bug :( | 19:35 |
RP | kanavin_home: {} does create scope but it shouldn't change xx here | 19:35 |
RP | well, it shoud | 19:35 |
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 | 19:36 |
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:4811:e8ec:aa33:10ab> has quit IRC | 19:37 | |
kanavin_home | RP: I'm trying to find an authoritative source on how such inner blocks behave | 19:37 |
kanavin_home | is it like a C function, and so only a 'copy' of xx is assigned to and then thrown away? | 19:38 |
RP | kanavin_home: that is how it appears to behave... | 19:39 |
kanavin_home | RP: maybe I just quickly write a toy program to verify instead | 19:40 |
*** kaspter <kaspter!~Thunderbi@115.195.44.89> has quit IRC | 19:41 | |
*** kaspter <kaspter!~Thunderbi@115.195.44.89> has joined #yocto | 19:42 | |
*** khem <khem!~khem@unaffiliated/khem> has quit IRC | 19:43 | |
RP | kanavin_home: I'm mixing up the compiler warnings :/ | 19:44 |
RP | no, I'm not, the compiler error messages are broken due to inlining | 19:45 |
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has joined #yocto | 19:46 | |
kanavin_home | RP: xx = setenv("PATH", path, 1); <----- does this actually set xx to something else than zero? | 19:47 |
kanavin_home | if it does, then the subsequent call doesn't happen | 19:47 |
marka | varjag | 19:47 |
RP | kanavin_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_home | RP: yeah, then execv happens only if it's zero | 19:49 |
RP | kanavin_home: ../../git/lib/rpmscript.c:209:5: warning: ‘xx’ may be used uninitialized in this function [-Wmaybe-uninitialized] | 19:49 |
RP | kanavin_home: compiler seems to worry about this | 19:49 |
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 19:49 | |
RP | kanavin_home: we patch out that setenv | 19:51 |
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 | 19:51 |
kanavin_home | RP: !!!!! | 19:52 |
kanavin_home | RP: I guess I can have dinner now :) | 19:52 |
RP | kanavin_home: the patch is from this Alex guy... ;-) | 19:53 |
*** voxadam <voxadam!~adam@fedora/voxadam> has joined #yocto | 19:54 | |
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 | 19:57 |
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 | 19:58 |
kanavin_home | RP: 'There are now ways this function can fail to set xx at all' isn't a correct claim though | 19:59 |
kanavin_home | RP: basically if you amend my patch, this should be sorted | 20:01 |
kanavin_home | either set xx to zero where it was set from setenv, or not check it before execv | 20:02 |
*** pohly <pohly!~pohly@p54BD5098.dip0.t-ipconnect.de> has quit IRC | 20:04 | |
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 20:32 | |
*** marka <marka!~masselst@128.224.252.2> has quit IRC | 20:33 | |
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 20:37 | |
*** dreyna <dreyna!~dreyna@unknown-157-219.windriver.com> has joined #yocto | 20:39 | |
RP | kanavin_home: agreed. I've cancelled it | 20:52 |
*** woglinde <woglinde!~henning@x5ce7b54a.dyn.telefonica.de> has joined #yocto | 20:54 | |
woglinde | hi | 20:54 |
woglinde | was there a special git login url for the yocto git? | 20:55 |
woglinde | for developers of course | 20:57 |
RP | woglinde: special in what way? | 20:59 |
woglinde | that I can push to the master branch of meta-java | 21:00 |
woglinde | or maybe my ssh key was removed git://git.yoctoproject.org/meta-java | 21:00 |
RP | woglinde: ah, you may need to use push.yoctoproject.org ? | 21:01 |
woglinde | hm oh okay is that documented somewhere? | 21:01 |
RP | woglinde: not sure, halstead might | 21:02 |
halstead | woglinde: I'm traveling so I missed the context. What's up? | 21:03 |
woglinde | ah okay | 21:03 |
woglinde | will try with push | 21:03 |
woglinde | hm and found it now | 21:04 |
woglinde | https://wiki.yoctoproject.org/wiki/Poky_Contributions | 21:04 |
*** gtristan <gtristan!~tristanva@199.241.135.253> has quit IRC | 21:05 | |
*** gtristan <gtristan!~tristanva@199.241.135.253> has joined #yocto | 21:06 | |
woglinde | hm does not work either | 21:06 |
*** mcastillo_ <mcastillo_!~mcastillo@191.125.190.5> has joined #yocto | 21:07 | |
woglinde | hm ssh://git@git.yoctoproject.org/meta-java still works too | 21:08 |
woglinde | and that worked for pushing | 21:09 |
*** uniqdom <uniqdom!~mcastillo@186.10.37.93> has quit IRC | 21:09 | |
woglinde | good to have the emails from 4 years ago | 21:09 |
*** mcastillo__ <mcastillo__!~mcastillo@191.125.179.123> has joined #yocto | 21:10 | |
*** mcastillo_ <mcastillo_!~mcastillo@191.125.190.5> has quit IRC | 21:12 | |
halstead | woglinde: that will work at the moment but not always. You might have proxy settings to update for the new URL. | 21:12 |
khem | RP: so here is new patches http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master | 21:13 |
khem | RP: addressed both ppc and arm tune issues | 21:13 |
khem | http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=635c8757bf852c8a4248009f241c19146431cacd | 21:13 |
khem | ppc change is booting qemuppc and testimage works too | 21:14 |
khem | I am now building for rpi3 and see if I get gcc-runtime issue due to march/mcpu conflict | 21:14 |
*** mcastillo__ <mcastillo__!~mcastillo@191.125.179.123> has quit IRC | 21:16 | |
*** Bunio_FH <Bunio_FH!~bunio@89.146.36.42> has joined #yocto | 21:27 | |
*** tgraydon <tgraydon!~textual@134.134.139.76> has joined #yocto | 21:38 | |
*** uniqdom <uniqdom!~mcastillo@186.10.37.93> has joined #yocto | 21:40 | |
*** woglinde <woglinde!~henning@x5ce7b54a.dyn.telefonica.de> has quit IRC | 21:45 | |
*** mrk377 <mrk377!442d9918@gateway/web/freenode/ip.68.45.153.24> has quit IRC | 21:53 | |
armpit | halstead, do you deal with patch queue ? | 21:56 |
* armpit we need to list who is admin for that | 21:57 | |
* armpit needs sumo-master added for both core and meta-or | 21:57 | |
RP | khem: that looks much better! :) | 21:57 |
RP | khem: have you talked to zeddii about the kernel patches? | 21:57 |
*** woglinde <woglinde!~henning@x5ce7b54a.dyn.telefonica.de> has joined #yocto | 21:59 | |
*** dc13ff <dc13ff!uid190567@gateway/web/irccloud.com/x-xofrlhxirvyyanqg> has joined #yocto | 22:05 | |
RP | armpit: list where? I think part of the trouble is the maintainers have changed but halstead should be able to help | 22:07 |
*** woglinde <woglinde!~henning@x5ce7b54a.dyn.telefonica.de> has quit IRC | 22:08 | |
armpit | RP, a list of who has admin privileges. it should be on OE wiki | 22:09 |
RP | armpit: agreed | 22:09 |
armpit | or who to email if there are issues | 22:09 |
RP | armpit: arbrindle (not in this channel but on irc) may be able to help too | 22:15 |
armpit | k | 22:15 |
RP | khem: If I can get the current patches in -next resolved, I'll look at testing gcc8 next | 22:16 |
*** gtristan <gtristan!~tristanva@199.241.135.253> has quit IRC | 22:18 | |
*** marquiz <marquiz!marquiz@nat/intel/x-inlcnhcewnksayps> has quit IRC | 22:25 | |
*** stephano <stephano!~stephano@c-67-189-76-218.hsd1.or.comcast.net> has quit IRC | 22:25 | |
*** stephano <stephano!~stephano@c-67-189-76-218.hsd1.or.comcast.net> has joined #yocto | 22:26 | |
*** anujm <anujm!~anujm@192.198.146.171> has joined #yocto | 22:28 | |
*** marquiz <marquiz!marquiz@nat/intel/x-bihljojphtmouapm> has joined #yocto | 22:29 | |
*** bavery_fn <bavery_fn!bavery@nat/intel/x-qatogafhrqxkiktz> has quit IRC | 22:43 | |
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 | 22:45 |
khem | RP: raspberrypi3 worked well testimage passed as well | 22:46 |
khem | so its looking ok so far. | 22:46 |
RP | khem: ok, we're looking good :) | 22:46 |
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 | 22:46 |
khem | but stage them if AB is free | 22:47 |
khem | so we can get better coverage, only arm/ppc is interesting other should not change | 22:49 |
RP | khem: its next in the queue once I resolve the current patches (which are building) | 22:50 |
khem | ok cool | 22:51 |
*** agust <agust!~agust@p50886E4C.dip0.t-ipconnect.de> has quit IRC | 22:51 | |
*** majuk <majuk!~majuk@75-163-138-15.clsp.qwest.net> has quit IRC | 22:55 | |
*** majuk <majuk!~majuk@75-163-138-15.clsp.qwest.net> has joined #yocto | 22:55 | |
*** majuk <majuk!~majuk@75-163-138-15.clsp.qwest.net> has quit IRC | 23:00 | |
*** scottrif <scottrif!~scottrif@47-40-108-60.dhcp.knwc.wa.charter.com> has left #yocto | 23:16 | |
*** clsulliv <clsulliv!clsulliv@nat/intel/x-pcrberrwkzalmzhd> has quit IRC | 23:22 | |
*** clsulliv <clsulliv!~clsulliv@134.134.139.74> has joined #yocto | 23:23 | |
*** anujm <anujm!~anujm@192.198.146.171> has quit IRC | 23:25 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-zndwzbygrqkrknvg> has joined #yocto | 23:26 | |
*** bavery_fn <bavery_fn!~bavery@134.134.139.72> has joined #yocto | 23:31 | |
*** bavery_fn <bavery_fn!~bavery@134.134.139.72> has quit IRC | 23:33 | |
RP | khem: Its started to run now so we'll have results tomorrow | 23:35 |
*** nighty- <nighty-!~nighty@s229123.ppp.asahi-net.or.jp> has quit IRC | 23:36 | |
*** AbleBacon <AbleBacon!~AbleBacon@unaffiliated/ablebacon> has quit IRC | 23:42 | |
*** tgraydon <tgraydon!~textual@134.134.139.76> has quit IRC | 23:48 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!