| 00:03.02 | *** join/#oe systmkor (~systmkor@unaffiliated/systmkor) |
| 00:06.38 | *** join/#oe systmkor (~systmkor@unaffiliated/systmkor) |
| 00:48.11 | *** join/#oe tgoodwin (~tgoodwin@pool-100-16-75-90.bltmmd.fios.verizon.net) |
| 01:51.06 | *** join/#oe https_GK1wmSU (~deep-book@77.234.42.183) |
| 01:53.52 | *** part/#oe https_GK1wmSU (~deep-book@77.234.42.183) |
| 04:07.47 | *** join/#oe fischerm (~mfischer@207-114-172-147.static.twtelecom.net) |
| 04:24.36 | *** join/#oe tgoodwin (~tgoodwin@pool-100-16-75-90.bltmmd.fios.verizon.net) |
| 05:07.29 | *** join/#oe morphis (~morphis@pD9ED7115.dip0.t-ipconnect.de) |
| 05:15.58 | *** join/#oe morphis (~morphis@pD9ED7115.dip0.t-ipconnect.de) |
| 05:26.21 | *** join/#oe https___GK1wmSU (~deep-book@77.234.42.183) |
| 05:26.57 | *** part/#oe https___GK1wmSU (~deep-book@77.234.42.183) |
| 05:53.56 | *** join/#oe Jefro (~Jefro@50-0-152-82.dedicated.static.sonic.net) |
| 06:10.25 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 06:16.08 | *** join/#oe pohly (~pohly@p5DE8F1FB.dip0.t-ipconnect.de) |
| 06:17.05 | *** join/#oe eFfeM (~frans@f160137.upc-f.chello.nl) |
| 06:42.01 | mckoan | good morning |
| 06:42.14 | *** join/#oe eFfeM (~frans@f160137.upc-f.chello.nl) |
| 06:58.06 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 07:13.16 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-oqtizuqzlnpcodcj) |
| 07:26.58 | *** join/#oe ant_work (~ant__@host11-249-dynamic.16-79-r.retail.telecomitalia.it) |
| 07:34.24 | *** join/#oe morphis (~morphis@pD9ED7115.dip0.t-ipconnect.de) |
| 08:00.49 | *** join/#oe tgoodwin (~tgoodwin@pool-100-16-75-90.bltmmd.fios.verizon.net) |
| 08:07.34 | *** join/#oe ao2 (~ao2@host169-85-dynamic.53-82-r.retail.telecomitalia.it) |
| 08:14.36 | *** join/#oe tasslehoff (~Tasslehof@77.40.182.102) |
| 08:22.55 | *** join/#oe rburton (~textual@home.burtonini.com) |
| 08:23.43 | *** join/#oe armpit (~armpit@2601:202:4001:9ea0:b92e:2c89:e1d7:5c28) |
| 09:02.48 | *** join/#oe jackmitchell (~Thunderbi@lag-44-105-1001.ear1.London1.Level3.net) |
| 09:21.25 | *** join/#oe yann|work (~yann@LFbn-1-3552-118.w90-127.abo.wanadoo.fr) |
| 09:30.52 | *** join/#oe morphis (~morphis@pD9ED7115.dip0.t-ipconnect.de) |
| 10:24.59 | *** join/#oe stefan_schmidt (~stefan@p200300480969CFBB9A8389FFFE2E3FAE.dip0.t-ipconnect.de) |
| 10:33.22 | *** join/#oe ash_charles (~acharles@modemcable200.135-177-173.mc.videotron.ca) |
| 11:10.22 | *** join/#oe ao2_ (~ao2@host235-34-dynamic.16-87-r.retail.telecomitalia.it) |
| 11:22.59 | *** join/#oe Varti (~varthall@dynamic-adsl-78-12-160-162.clienti.tiscali.it) |
| 11:58.06 | *** join/#oe ldnunes (~ldnunes_@181.220.72.143) |
| 12:02.59 | *** join/#oe ao2__ (~ao2@95.237.16.34) |
| 12:14.47 | ndec | hi. i am overlaying glmark2 recipe in my own layer, and somehow oe picks the 'old' version, instead of the new one. not sure why. |
| 12:14.47 | ndec | glmark2: |
| 12:14.47 | ndec | <PROTECTED> |
| 12:14.47 | ndec | <PROTECTED> |
| 12:15.05 | ndec | could be it because PV is set 'in' the recipe, and the recipe file is glmark2_git.bb? |
| 12:23.18 | *** join/#oe christner (~dchristne@50-76-27-165-static.hfc.comcastbusiness.net) |
| 12:35.59 | *** join/#oe marka (~masselst@135-23-92-83.cpe.pppoe.ca) |
| 12:47.03 | Net147 | can I get access to compiler toolchain on bitbake host without having to populate an SDK, install it and source the environment? something like devshell but not specific to a recipe? |
| 12:53.37 | ensc|w_ | how is BBMULTICONFIG to be used? Is it expected that with 'BBMULTICONFIG="debug release"' a 'bitbake foo' is be a synonym of 'bitbake multiconfig:debug:foo multiconfig:release:foo'? here (oe + bitbake master), it seems that both BBMULTICONFIG and the 'multiconfig:...' target must be set which looks redundant to me |
| 12:57.26 | *** join/#oe ash_charles (~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157) |
| 13:13.40 | rburton | ndec: that won't make a difference, but meta-oe has a high priority and tends to override other layers. i noticed bitbake preferring the old re2c in meta-oe over the upgrade in oe-core last night. |
| 13:14.23 | *** join/#oe tasslehoff (~Tasslehof@77.40.182.102) |
| 13:15.03 | *** join/#oe stephano (stephano@nat/intel/x-tuzhquoflemjnhqi) |
| 13:21.15 | *** join/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 13:22.07 | RP | ensc|w: 'bitbake foo' is not a synonym of 'bitbake multiconfig:debug:foo multiconfig:release:foo' |
| 13:32.22 | ensc|w | RP: for what is BBMULTICONFIG required then? it seems to be completely redundant with the 'multiconfig:...' target |
| 13:34.59 | Crofton|work | rburton, we should figure out some reasonable ways to set payer priorities |
| 13:35.31 | rburton | meta-oe should be the same as core |
| 13:35.48 | Crofton|work | what is it now? |
| 13:36.10 | Crofton|work | also, how woould other layers relate |
| 13:36.24 | rburton | oe-core is 5, meta-oe is 6 |
| 13:36.35 | rburton | i'd say all "load of recipes" layers should be the same as core |
| 13:36.37 | Crofton|work | and other layers are higher |
| 13:36.55 | rburton | meta-gnome for some reason is 7 |
| 13:36.57 | Crofton|work | maybe we should rename name meta-oe to core-extended :) |
| 13:36.59 | rburton | its like they're just making up numbers |
| 13:36.59 | RP | ensc|w: it states which multiconfigs to parse |
| 13:37.13 | Crofton|work | rburton, that is what I suspect also |
| 13:39.03 | ensc|w | RP: but why does bitbake need to parse all (or any) multiconfig when I just say 'bitbake foo'? |
| 13:39.28 | ensc|w | multiconfigs seem to be implied by the actual 'multiconfig:...' target |
| 13:44.24 | *** join/#oe fabioberton[m] (fabioberto@gateway/shell/matrix.org/x-lzkhratfpmniayyy) |
| 14:09.40 | Crofton|work | bluelightning, awake? |
| 14:10.24 | bluelightning | Crofton|work: I am yes |
| 14:10.44 | RP | ensc|w: I guess that from an implementation perspective, setting BBMULTICONFIG was easier and it also made it easier to think about inter-multiconfig dependencies later |
| 14:11.00 | Crofton|work | do you mind if I submit a patch to not run the stripped QA thing for qwt in meta-qt4? |
| 14:11.08 | Crofton|work | is now an error in poky |
| 14:11.14 | RP | ensc|w: You're right you could theoretically figure out the multlibs but it wouldn't be easy with the current code structure |
| 14:11.17 | Crofton|work | and not really worth fixing with qt5 |
| 14:11.27 | RP | ensc|w: also, we do support bitbake mutliconfig:*:xxx |
| 14:11.28 | Crofton|work | qt5 version doesn't have the issue |
| 14:11.41 | bluelightning | Crofton|work: yep that should be fine |
| 14:11.50 | Crofton|work | ok |
| 14:12.02 | Crofton|work | wanted to check before submitting it |
| 14:12.23 | bluelightning | Crofton|work: if it were somewhere we maintain then I'd prefer fixing it, but that layer is on life support so it's different |
| 14:12.24 | Crofton|work | we also have a sip mismatch in pyro, which is breaking pyqt |
| 14:12.28 | Crofton|work | right |
| 14:12.39 | Crofton|work | I did check if fix was needed in qt5 |
| 14:12.44 | Crofton|work | different issues there :) |
| 14:12.47 | *** join/#oe bachp (bachpmatri@gateway/shell/matrix.org/x-shhinveosylyuwgl) |
| 14:16.23 | *** join/#oe ao2_ (~ao2@host62-212-dynamic.49-82-r.retail.telecomitalia.it) |
| 14:18.31 | khem | rburton: Just sent mesa/llvm updates |
| 14:25.40 | *** join/#oe tgoodwin (~tgoodwin@static-108-40-78-74.bltmmd.fios.verizon.net) |
| 14:44.15 | *** join/#oe snowkidind (~textual@216-15-40-124.c3-0.gth-ubr1.lnh-gth.md.cable.rcn.com) |
| 14:46.45 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 14:56.08 | ndec | rburton: thanks. that was the layer priority , indeed. easy to fix since our layer should have high priority.. |
| 14:56.17 | rburton | khem: they work \o/ |
| 14:57.14 | khem | rburton: you have to tell me . They built ok for me, |
| 14:57.58 | khem | layer priorities I realy dont like them, it just creates confusion |
| 14:58.27 | khem | and semantics doesnt cover all types of metadata |
| 14:59.18 | rburton | khem: i mean, mesa built with llvm |
| 14:59.37 | khem | ah you were asserting |
| 14:59.41 | khem | cool |
| 15:17.44 | *** join/#oe ntl (~nathanl@65-36-80-8.dyn.grandenetworks.net) |
| 15:37.32 | *** join/#oe mcars (~michael.c@mx1.millennium-space.com) |
| 15:41.13 | *** join/#oe ash_charles (~acharles@2607:fad8:4:6:2041:6d6c:cfc4:28fc) |
| 15:57.50 | *** join/#oe dolapevich (~seba@181.228.225.112) |
| 16:05.58 | Crofton|work | A topic for OEDEM: https://lwn.net/SubscriberLink/729366/7ee376c75461c395/ |
| 16:06.09 | Crofton|work | and layer priority guidance |
| 16:09.25 | rburton | oh i wonder what fedora is saying |
| 16:10.12 | rburton | not sure i'd want to redirect /usr/bin/python to py3 |
| 16:10.18 | rburton | seems like that will just break things |
| 16:11.28 | *** join/#oe Jefro (~Jefro@50-0-152-82.dedicated.static.sonic.net) |
| 16:11.35 | khem | rburton: archlinux is using py3 as py for many years |
| 16:12.04 | khem | so we need to see if we can get OE to not demand py2 |
| 16:12.12 | khem | or atleast not as py |
| 16:12.23 | rburton | khem: yes we can blame arch for this problem in the first place |
| 16:12.34 | rburton | a target doesn't contain py2 anymore |
| 16:12.39 | kergoth | we could always provide 'python' as python2 ourselves, i.e. add a little wrapper script under scripts/ the way we've done for so many other things |
| 16:12.43 | rburton | but a few pieces still expect py2 on the host |
| 16:12.47 | kergoth | we know our buildsystems will expect that |
| 16:13.18 | rburton | kanavin can probably remember what bits demanded py2 on the host, he patched several out |
| 16:13.22 | kergoth | though most won'te even need that, what with python-native |
| 16:13.33 | rburton | well pretty sure we don't even build that for eg sato |
| 16:13.37 | fray | well Fedora just extended their time scale to get rid of python3 requirements.. |
| 16:13.50 | fray | I think it's reasonable as long as a full transition 'off' before 2020.. (python2 EOL) |
| 16:14.08 | khem | yeah raise the danger bar and suddenly you are not in flood zone |
| 16:14.11 | fray | (and IMHO redirecting /usr/bin/python to python3 is insane.. even after 2020) |
| 16:14.28 | rburton | what fray said |
| 16:14.32 | kergoth | still, adding a script seems trivial. just make 'python' run 'python2' if it exists, 'python' otherwise, and adjust our sanity check to do that too |
| 16:14.33 | kergoth | agreed |
| 16:15.18 | fray | at WR we provide both python2 and python3 with our product. We can't rely on the host having a functioning version.. (RHEL 7 is pretty bad, and 6 is nearly unusuable by today's standards) |
| 16:15.18 | rburton | thanks to arch being arch, very little actually calls /usr/bin/python in oe |
| 16:15.20 | khem | fray: while I agree its crude way to force people to move forward, it is getting right results i.e. port to py3 |
| 16:15.47 | khem | and ensure that no new py code is written for py2 |
| 16:15.49 | fray | for a smaller distro like 'arch', they can get away with it.. but I don't expect Debian/Ubuntu or Fedora/RH/CentOS to do so |
| 16:15.58 | fray | no new code for py2 is a valid goal... |
| 16:16.16 | fray | but I'd prefer no /usr/bin/python -at all-, vs having it map to python3 |
| 16:16.28 | khem | before you fix leaks you need to shut the valve |
| 16:16.57 | fray | remove python2.. stop /usr/bin/python from existing.. that is how I'd handle it |
| 16:16.58 | kergoth | | ../../diffutils-3.6/lib/getopt1.c:50:55: error: expected ';', ',' or ')' before '*' token |
| 16:16.58 | kergoth | | getopt_long_only (int argc, char *__getopt_argv_const *argv, |
| 16:17.02 | rburton | fray: agreed |
| 16:17.03 | kergoth | ... huh. anyone seen this one before? |
| 16:17.33 | fray | hasn't seen that before |
| 16:17.43 | rburton | fray: remove py2 from test machine, make oe work. then remove from autobuilders so it can't sneak back in. |
| 16:17.52 | fray | rburton yup |
| 16:18.00 | rburton | if you want to be really sure, remove it from hosttools |
| 16:18.15 | khem | yeah remove it from hosttools |
| 16:18.21 | khem | is good |
| 16:18.21 | fray | that is what we've been trying to do for some of the products we building using the YP.. the build side, we don't care as much |
| 16:18.47 | fray | we have our how hosttools-tarball.. since the (morty) version didn't have everything needed to run toaster (and some other things) |
| 16:18.54 | fray | our -own- |
| 16:20.34 | rburton | from a glance at oe-core we only build python-native if we need to use python-scons-native or python-setuptools-native |
| 16:21.12 | rburton | scons only comes in if you build subversion-native |
| 16:21.39 | khem | rburton: http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=e5697ed41f3cf23b897e2ca9e55e994a386d8e64 |
| 16:21.44 | kergoth | not sure what you mean by that, considering distutils-base inherits pythonnative, last i checked |
| 16:21.47 | kergoth | did that change? |
| 16:21.57 | rburton | hm |
| 16:21.58 | khem | its final glibc 2.26 if you have cycles please throw it in |
| 16:22.07 | fray | might be a place to add a deprecated warning 'pythonnative'? |
| 16:22.08 | kergoth | pretty sure anything remotely python related sucks in python-native |
| 16:22.10 | rburton | damns |
| 16:22.14 | khem | before it releases tomorrow we still have a day to report problems |
| 16:22.16 | kergoth | it's in nearly every build i do, one way or another |
| 16:22.20 | rburton | well, luckily almost nothing needs py2 ;) |
| 16:22.27 | kergoth | yeah, true, not as much anymore |
| 16:22.51 | kergoth | is still mostly on morty at work, need to catch up with master |
| 16:23.14 | khem | kergoth: that error seems to me that its mixing getopt from libc and gnulib |
| 16:23.28 | kergoth | ah, thanks, will check the configure tests |
| 16:24.17 | fray | kergoth - day to day I'm using morty.. but I'm working on master (luckily) |
| 16:25.20 | kergoth | nice. i've gotten maybe 4-8 hours a week to do basic build sanity testing with master :\ |
| 16:25.25 | kergoth | need to work on the patch submission queue |
| 16:28.08 | fray | lol, I never said I get to build master ;) just working on master integration (bitbake mostly right now) :) |
| 16:28.15 | fray | luckily bitbake-selftest works.. ;) |
| 16:28.40 | kergoth | ah |
| 16:28.50 | kergoth | i need to take a look at that layer fetching series, haven't had time yet |
| 16:29.49 | fray | work so far was centered around basic infrastructure and making bitbake-layers work.. |
| 16:30.02 | fray | it's possible to define multiple layer indexes. (but not easily -- yet.. I've done it in testing) |
| 16:30.29 | khem | rburton: last time you reported locale issues with glibc patch, hoping this is addressed with this glibc patch |
| 16:30.35 | fray | (not easily is intentional until I get time to work on the toaster piece.. I'm trying to unify the interface between toaster and bitbake-layers layerindex-* |
| 16:30.41 | rburton | khem: fingers crossed |
| 16:30.51 | khem | rburton: did you pick the glibc ? |
| 16:31.01 | rburton | RP: bitbake server broke -g |
| 16:31.55 | rburton | oh no it didn't |
| 16:32.29 | kergoth | that reminds me, the NOTE about the server starting when running bitbake-layers add-layer or remove-layer is a bit silly, especially since there's no such note about shutting it down |
| 16:32.35 | fray | ...once the itnerfaces are unified.. then it should be pretty easy to implement the setup tool.. so you can just start with bitbake and pull down and entire project.. |
| 16:32.36 | rburton | khem: didnt see an update to the broken one? |
| 16:33.14 | rburton | awww we build python-native for quite a few bit |
| 16:33.25 | fray | kergoth I never worked in that section... Paul did add a small change to stop parsing when using the bitbake-layers layerindex-* commands.. really sped things up a lot |
| 16:33.35 | kergoth | nice |
| 16:33.39 | khem | rburton: I will send to ml |
| 16:33.53 | kergoth | i still need to submit the bits to let bitbake-layers only parse bblayers, not bitbake.conf, for the bblayers manipulation commands |
| 16:34.17 | fray | I don't think that is bitbake-layers, that digs into tinfoild oesn't it? |
| 16:34.26 | kergoth | not jsut tinfoil, even cooker |
| 16:34.31 | kergoth | which is why i haven't submitted it yet, it's a mess |
| 16:34.33 | fray | the load of the bitbake.conf through bblayers is pretty 'simple' |
| 16:34.38 | kergoth | cooker paress it in the constructor, iirc |
| 16:34.42 | fray | (speed wise).. it's the recipe parse that takes bloody forever |
| 16:34.42 | rburton | okay too late to chase py2 deps |
| 16:34.48 | kergoth | yeah, true |
| 16:35.02 | fray | the bitbake-layers already has a switch to disable the recipe parse piece.. |
| 16:35.25 | fray | I started hacking on a 'bitbake-setup' (just to test the other components) and ended up not being able to use tinfoil because of all of that.. |
| 16:35.45 | fray | I'm not too concerned cause I don't really need the cooker or UI backends.. and the data piece works fine without the others |
| 16:35.59 | fray | (and if data is initialized, then bb.fetch works) |
| 16:36.35 | kergoth | nods |
| 16:37.28 | fray | in the bitbake-contrib mgh/bitbake-setup layer the top commit is the little test bitbake-setup I have.. it only implements a query function right now.. calling it require the last parameter to be a .conf file to load.. the only required bit in the file is the reference to one or more upstream repository.. |
| 16:38.00 | fray | BBLAYERINDEX_URI = "http://layers.openembedded.org/layerindex/api/;type=restapi;branch=morty" |
| 16:38.15 | fray | put that in a new file, pass that in as the .conf and you can play with the basic query pieces |
| 16:38.29 | fray | += more layer indexes and you can verify multiple indexes load.. |
| 16:38.35 | fray | (pretty simple) |
| 16:39.25 | fray | I should add a dependency resolution query to the test functionaly.. (bitbake-selftest DOES do that kind of verification .. this is more for visual demo/debug) |
| 16:58.49 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 17:08.50 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 17:32.01 | *** join/#oe blight (~greg@213-47-235-68.cable.dynamic.surfer.at) |
| 17:32.01 | *** join/#oe blight (~greg@reactos/developer/blight) |
| 17:34.05 | *** join/#oe ash_charles (~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc) |
| 17:37.58 | rburton | grumble, bb whatdepends doesn't work with new bitbake |
| 17:38.16 | kergoth | yeah.. the tinfoil changes.. that command heavily used a bunch of internal stuff |
| 17:38.22 | kergoth | i think paul has added enough to tinfoil recnetly to fix it, though |
| 17:38.26 | kergoth | just never got around to it |
| 17:44.52 | *** join/#oe DJWillis (~djwillis@cpc123746-trow7-2-0-cust5.18-1.cable.virginm.net) |
| 18:02.33 | *** join/#oe micka (~micka@85-169-205-91.rev.numericable.fr) |
| 18:17.35 | *** join/#oe micka (~micka@85-169-205-91.rev.numericable.fr) |
| 18:29.46 | *** join/#oe itseris (~emikulin@76.77.65.2) |
| 18:33.02 | *** join/#oe micka (~micka@85-169-205-91.rev.numericable.fr) |
| 18:33.58 | *** join/#oe itseris_ (~emikulin@76.77.65.2) |
| 18:37.28 | *** join/#oe snowkidind (~textual@216-15-40-124.c3-0.gth-ubr1.lnh-gth.md.cable.rcn.com) |
| 18:49.28 | *** join/#oe tgoodwin_ (~tgoodwin@pool-100-16-75-90.bltmmd.fios.verizon.net) |
| 19:02.10 | *** join/#oe itseris_ (~emikulin@76.77.65.2) |
| 19:02.38 | *** join/#oe micka (~micka@85-169-205-91.rev.numericable.fr) |
| 19:10.26 | *** join/#oe ash_charles (~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157) |
| 19:14.59 | *** join/#oe armpit (~armpit@50-233-148-156-static.hfc.comcastbusiness.net) |
| 19:32.14 | *** join/#oe troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 19:55.56 | smurray | I'm seeing a build failure in glibc 2.25 building the i586 version in multilib on pyro, that ring bells for anyone? |
| 19:56.56 | smurray | https://www.irccloud.com/pastebin/MNB9r1Y2/ |
| 19:58.39 | smurray | s/i586/i686/ |
| 20:16.38 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 20:25.35 | *** join/#oe bluelightning (~paul@ip4d16fb7f.dynamic.kabel-deutschland.de) |
| 20:25.35 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 20:45.38 | *** join/#oe Leatherface (~leatherfa@helvetet.eu) |
| 20:55.42 | *** join/#oe itseris (~emikulin@76.77.65.2) |
| 20:56.43 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 21:03.46 | *** join/#oe micka (~micka@85-169-205-91.rev.numericable.fr) |
| 21:04.08 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 21:17.05 | *** join/#oe rburton (~textual@home.burtonini.com) |
| 21:18.24 | *** join/#oe yann|work (~yann@nan92-1-81-57-214-146.fbx.proxad.net) |
| 21:18.46 | *** join/#oe ant_home (~ant__@host228-232-dynamic.45-213-r.retail.telecomitalia.it) |
| 21:41.00 | *** join/#oe bluelightning (~paul@ip4d16fb7f.dynamic.kabel-deutschland.de) |
| 21:41.00 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 21:48.51 | *** join/#oe micka (~micka@85-169-205-91.rev.numericable.fr) |
| 21:56.03 | ant_home | khem, nice touch, thx. Would never imagined klibc builds with clang so easily |
| 21:57.27 | *** join/#oe ohama (ohama@cicolina.org) |
| 22:03.55 | *** join/#oe micka (~micka@85-169-205-91.rev.numericable.fr) |
| 22:05.15 | ant_home | khem, please send upstream. People are depressed: they are receiving only spam on the ML |
| 22:14.16 | khem | ant_home: it doesnt yet |
| 22:14.20 | *** join/#oe georgem_home (uid210681@gateway/web/irccloud.com/x-spupnqiijxwzonju) |
| 22:14.28 | khem | there is a header issue |
| 22:14.34 | khem | probably a minor one |
| 22:14.57 | khem | it wraps stdarg.h and clang does not like it |
| 22:15.39 | *** join/#oe roxell (~roxell@c-043070d5.07-21-73746f28.cust.bredbandsbolaget.se) |
| 22:15.39 | *** join/#oe roxell (~roxell@unaffiliated/roxell) |
| 22:16.22 | *** join/#oe yann|work (~yann@nan92-1-81-57-214-146.fbx.proxad.net) |
| 22:16.46 | ant_home | can you fix it with reordering? |
| 22:17.24 | *** join/#oe armpit (~armpit@50-233-148-156-static.hfc.comcastbusiness.net) |
| 22:22.44 | ant_home | khem, buildroot of today has gcc 7.x |
| 22:23.01 | ant_home | they defaults to arm code, not thumb |
| 22:23.15 | ant_home | I switched to thumb to reproduce the kernel issue |
| 22:23.33 | ant_home | let see |
| 22:24.03 | ant_home | gcc options defaults to empty? |
| 22:24.09 | ant_home | bah |
| 22:29.54 | *** join/#oe micka (~micka@85-169-205-91.rev.numericable.fr) |
| 22:32.24 | khem | ok |
| 22:40.01 | ant_home | buiulding with LTO |
| 22:40.23 | ant_home | I see there is OpenMP for LLVM |
| 22:40.31 | ant_home | did you try it? |
| 22:40.46 | ant_home | for linux-kernel >4.x? |
| 22:41.37 | *** join/#oe yann|work (~yann@nan92-1-81-57-214-146.fbx.proxad.net) |
| 22:46.17 | *** join/#oe stephano (~stephano@134.134.139.77) |
| 22:56.15 | ant_home | good night |
| 23:03.09 | *** join/#oe https_GK1wmSU (~deep-book@199.189.106.240) |
| 23:05.43 | *** part/#oe https_GK1wmSU (~deep-book@199.189.106.240) |
| 23:13.46 | *** join/#oe armpit (~armpit@50-233-148-156-static.hfc.comcastbusiness.net) |
| 23:21.43 | *** join/#oe sgw_ (~sgw_@73.93.153.118) |
| 23:25.54 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 23:27.51 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 23:29.13 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 23:45.38 | *** join/#oe sgw_ (~sgw_@134.134.139.72) |
| 23:49.03 | *** join/#oe micka (~micka@85-169-205-91.rev.numericable.fr) |
| 23:51.02 | *** join/#oe stephano (~stephano@134.134.139.78) |