| 02:34.14 | *** join/#oe pidge (~pidge@2a02:8084:0:3000:c159:c7f5:95d9:42ff) |
| 02:37.59 | *** join/#oe hillct (~hillct@cpe-45-37-78-233.nc.res.rr.com) |
| 04:52.23 | *** join/#oe SorenHolm (~quassel@5634f191.rev.stofanet.dk) |
| 05:40.33 | *** join/#oe clio (~andrej@85.159.109.222) |
| 06:09.39 | *** join/#oe hamis (~irfan@110.93.212.98) |
| 06:18.57 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 06:25.55 | *** join/#oe SorenHolm (~quassel@93.165.148.186) |
| 06:33.52 | *** join/#oe shoragan (~shoragan@debian/developer/shoragan) |
| 06:43.49 | *** join/#oe avall (avalluri@nat/intel/x-suidgjnvriywvvuj) |
| 06:46.31 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 06:50.31 | *** join/#oe ant_work (~ant__@host222-188-static.61-79-b.business.telecomitalia.it) |
| 07:08.41 | *** join/#oe woglinde (~henning@fb-n15-11.unbelievable-machine.net) |
| 07:11.01 | *** join/#oe vquicksilver (~nobody@gentoo/contributor/vquicksilver) |
| 07:14.38 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 07:31.51 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 07:31.56 | mckoan | good morning |
| 07:58.20 | *** join/#oe SorenHolm (~quassel@93.165.148.186) |
| 08:11.04 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 08:12.36 | bluelightning | morning all |
| 08:13.09 | nrossi | morning |
| 08:15.14 | *** join/#oe aragua (~aragua@91-224-149-44.tetaneutral.net) |
| 08:17.23 | *** join/#oe awe00 (~awe00@lon92-h02-128-78-240-105.dsl.sta.abo.bbox.fr) |
| 08:18.09 | mckoan | hi bluelightning, nrossi |
| 08:19.00 | bluelightning | hi nrossi, mckoan |
| 08:42.33 | *** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 08:53.07 | blindvt` | Error, the PACKAGE_ARCHS variable does not contain TUNE_PKGARCH (cortexm1t2-vfp). |
| 08:53.28 | blindvt` | for DEFAULTTUNE := "cortexm1" |
| 09:05.58 | *** join/#oe belen (~Adium@192.198.151.44) |
| 09:13.59 | *** join/#oe ohama (~ohama@cicolina.org) |
| 09:22.28 | *** join/#oe tsramos (tsramos@nat/intel/x-nzllwgsmkmwlxvod) |
| 09:34.26 | *** join/#oe tsramos (~tsramos@192.55.55.37) |
| 09:38.57 | *** join/#oe pidge (~pidge@2a02:8084:0:3000:79ad:e357:68a1:683) |
| 09:52.32 | *** join/#oe JaMa (~martin@ip-86-49-34-37.net.upcbroadband.cz) |
| 09:53.52 | *** join/#oe anarsoul (~anarsoul@46.28.101.174) |
| 10:07.37 | *** join/#oe arfoll_ (arfoll@nat/intel/x-mtaeynkovbgtmnhv) |
| 10:08.11 | *** join/#oe belen1 (Adium@nat/intel/x-mtlcxwyhjojhsoxf) |
| 10:08.24 | *** join/#oe blitz00__ (stefans@nat/intel/x-txnhdxpptiuuqnjq) |
| 10:10.22 | *** join/#oe avall (avalluri@nat/intel/x-kixeczuixddjwqrt) |
| 10:36.49 | blindvt` | JaMa: does building qemuarm for DEFAULTTUNE := "cortexm1" work four you on current master? |
| 10:41.29 | blindvt` | JaMa: specifically, for me sanity complains about "does not contain TUNE_PKGARCH (cortexm1t2-vfp)" where indeed PACKAGE_ARCHS only contains ... "armv7a armv7a-vfp armv7at2-vfp cortexm1-vfp qemuarm" |
| 10:41.41 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 10:45.15 | blindvt` | (it would be handy if sanity bbclass would actually tell which PACKAGE_ARCHS it has seen, like http://paste.debian.net/167748/ ) |
| 10:45.25 | JaMa | blindvt`: please check how t2 got enabled and my guess is that |
| 10:45.26 | JaMa | PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} cortexm1-vfp" |
| 10:45.31 | JaMa | shouldn't have at |
| 10:45.32 | JaMa | PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} cortexm1-vfp" |
| 10:45.41 | JaMa | +PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} cortexm1-vfp" |
| 10:47.32 | blindvt` | JaMa: yea, the t2 handling is a bit .. erm .. non-obvious with all those suffix handling |
| 10:47.43 | JaMa | even the vfp shouldn't be enabled imho |
| 10:47.50 | JaMa | TUNE_FEATURES_tune-cortexm1 = "${TUNE_FEATURES_tune-armv7a} cortexm1" |
| 10:48.02 | JaMa | what's your list of TUNE_FEATURES? |
| 10:48.57 | blindvt` | In my local.conf i just have DEFAULTTUNE := "cortexm1" and ARM_INSTRUCTION_SET := "thumb" |
| 10:50.48 | blindvt` | JaMa: tune-cortexm1.inc hast just one TUNE_FEATURES_tune-cortexm1 = "${TUNE_FEATURES_tune-armv7a} cortexm1" here |
| 10:56.27 | *** join/#oe ohama (ohama@cicolina.org) |
| 10:57.02 | *** join/#oe nerdboy (~sarnold@gatekeeper.gentoogeek.org) |
| 10:58.18 | blindvt` | JaMa: I appended cortexm1t2-vfp to PACKAGE_EXTRA_ARCHS_tune-cortexm1 and sanity stopped to complain. the cortex-a do the same it seems. I didn't think through if this is sensible though. [I guess it is not at least doesn't feel like. Not sure of cortexm1 are even thumb1-capable -- i thought they weren't] |
| 11:01.30 | blindvt` | JaMa: i.e. http://paste.debian.net/167750/ |
| 11:02.33 | blindvt` | JaMa: but according to http://en.wikipedia.org/wiki/ARM_Cortex-M the cortex-m1 are v6-m and not v7 so isn't the PACKAGE_ARCHS that contain all those armv7* just wrong? |
| 11:04.29 | blindvt` | either way. it's now good enough for me to build me a non-arm image |
| 11:05.55 | JaMa | do you have bitbake -e output which shows how your TUNE_PKGARCH was set? |
| 11:06.15 | JaMa | that t2 and vfp are still very suspicious and the root cause of all this mess IMHO |
| 11:07.54 | blindvt` | JaMa: no, not readily. You should see it if you set your local.conf as per above 2 vars and "require conf/machine/include/tune-cortexm1.inc" in meta/conf/machine/qemuarm.conf i guess |
| 11:08.19 | blindvt` | instead of the existing require tune-*inc in qemuarm |
| 11:10.28 | blindvt` | JaMa: so yea, under the assumption that cortexm1 is v6 and not v7, the feature-arm-thumb.inc would not do the t2 mess, it seems. |
| 11:19.12 | *** join/#oe balkamos (balkamos@unaffiliated/motley) |
| 11:38.40 | blindvt` | JaMa: qemu-system-arm for versatilepb -cpu cortex-m3 segfaults with a NULL GIXState in gic_set_pending_private. Is there a reason that qemu-git uses some ancient (?) SRCREV? Unfortunately qemu-2.3.0 is not out of the door just jet, it seems |
| 11:38.53 | blindvt` | s/GIX/GIC/ |
| 11:39.14 | *** join/#oe pompomJuice (~pompomJui@196.211.8.18) |
| 11:52.05 | Crofton|work | apparently I work with oe-classic |
| 12:04.22 | bluelightning | Crofton|work: I didn't see your reply to Ed on the mailing list... |
| 12:04.34 | Crofton|work | I did reply .... |
| 12:04.42 | Crofton|work | then left twon for 3 days |
| 12:06.36 | *** join/#oe woglinde (~henning@fb-n15-11.unbelievable-machine.net) |
| 12:10.00 | *** join/#oe stefan__ (~chatzilla@67.71.118.29) |
| 12:13.35 | bluelightning | Crofton|work: your reply never made it to the ML, at least it's not in the archive |
| 12:13.41 | Crofton|work | fark |
| 12:13.44 | Crofton|work | let me check |
| 12:13.55 | bluelightning | I didn't say anything because I thought you had... |
| 12:17.34 | Crofton|work | It went to Ed only, forgot reply-all |
| 12:19.24 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 12:21.14 | bluelightning | Crofton|work: unfortunately it was missed on review as a result... oh well, at least the bug is fixed |
| 12:21.50 | Crofton|work | I'm still stumped at how someone could come up with oe-classic wrt to current work flow |
| 12:22.06 | *** join/#oe pidge (~pidge@2a02:8084:0:3000:79ad:e357:68a1:683) |
| 12:28.41 | *** join/#oe aragua (~aragua@91-224-149-44.tetaneutral.net) |
| 12:30.35 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 12:31.45 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 12:31.46 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 12:43.43 | Cyric | hey guys what is the easiest way to add a package in the build? for example libstdc++ |
| 12:43.47 | Cyric | or nano? |
| 12:46.23 | Crofton|work | Hopefully Ed doesn't think I am persecuting him :) |
| 12:46.40 | Crofton|work | https://bugzilla.yoctoproject.org/show_bug.cgi?id=7631 |
| 12:46.52 | bluelightning | Cyric: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage |
| 12:47.22 | *** join/#oe tsramos (~tsramos@134.134.137.75) |
| 12:49.34 | koen | adding a lib manually should set off a ton of alarm bells |
| 12:53.46 | *** join/#oe kscherer (~kscherer@128.224.252.2) |
| 12:54.33 | bluelightning | Cyric: adding libraries directly usually isn't needed, because we set up runtime dependencies on shared libs automatically |
| 12:55.27 | Cyric | well the problem is that i need qt5 qmake |
| 12:55.38 | Cyric | and is not in the repo |
| 12:56.25 | Cyric | so i would like to create a sysroot with OE and then use it for manually cross compiling and installing qt5 on the immage |
| 12:57.16 | Cyric | but i believe that the sysroot must have all the dependency required by QT5-qmake |
| 12:57.18 | woglinde | you need the meta-qt layer? |
| 12:57.36 | Cyric | the meta qt-layer does not include qmake |
| 12:57.48 | Cyric | at least not the version 5 |
| 12:58.06 | Cyric | only the qt4.8 but this is not good enought for me |
| 12:59.11 | Cyric | in general qmake is included in QTBase... but it seems that in this case has been removed |
| 13:00.01 | Cyric | i tried to bitbake meta-qt5-toolchain but it fails |
| 13:06.02 | *** join/#oe mwester (~mwester@174-125-252-51.dyn.centurytel.net) |
| 13:06.02 | *** join/#oe mwester (~mwester@nslu2-linux/mwester) |
| 13:12.27 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 13:17.11 | *** join/#oe tasslehoff (~Tasslehof@82.147.55.166) |
| 13:18.50 | *** join/#oe realBigfoot (~realBigfo@134.191.220.74) |
| 13:22.26 | Crofton|work | seems like we need a bbclass for people that use wic to manage building the required tools |
| 13:25.48 | bluelightning | at OEDAM JaMa suggested we have a class for calling wic from within the build system, that sounds like a good idea to me |
| 13:25.54 | *** join/#oe ntl (~ntl@99-127-51-4.lightspeed.austtx.sbcglobal.net) |
| 13:26.02 | bluelightning | we should probably enter a bug for that at minimum |
| 13:26.45 | Crofton|work | there are two pieces to the puzzle |
| 13:27.12 | Crofton|work | I just use a script with wic, but I would like a way to record the required utilities |
| 13:38.55 | *** join/#oe realBigfoot (~realBigfo@134.191.220.74) |
| 13:39.51 | *** join/#oe fray (~mhatle@192.40.192.95) |
| 13:42.51 | mckoan | why history commands are not persistent? |
| 13:43.16 | woglinde | ? |
| 13:43.19 | mckoan | s/not/no longer |
| 13:43.39 | mckoan | since I'm using YP dizzy I have new weird behaviour |
| 13:44.13 | mckoan | I wonder if is a new feature or a bug |
| 14:02.28 | *** join/#oe stefan1234 (~stefan@p4FF8314C.dip0.t-ipconnect.de) |
| 14:04.08 | bluelightning | mckoan: bash? busybox? something else? |
| 14:07.58 | mckoan | bluelightning: YP default, /bin/sh -> /bin/bash |
| 14:09.43 | bluelightning | actually the default is busybox ;) |
| 14:09.46 | bluelightning | but anyway |
| 14:12.57 | *** join/#oe tsramos (tsramos@nat/intel/x-euduksnzoydgkkwp) |
| 14:18.01 | mckoan | bluelightning: doh! |
| 14:20.57 | bluelightning | mckoan: is it possible a dependency got added that has pulled in bash whereas previously you had busybox? |
| 14:23.40 | mckoan | bluelightning: may be, actually I realized that only today |
| 14:24.06 | mckoan | bluelightning: lokks like a fsl standard behaviour |
| 14:27.56 | mago_ | where's the typical place in a oe build to inject a version number into a rootfs? i'd like the repo manifest file that was used to build the image into its rootfs. Is rootfs postprocessing the way to go? |
| 14:28.25 | woglinde | mago_ yes |
| 14:29.01 | woglinde | I made a snippet and require it in each image |
| 14:29.10 | woglinde | for our private layers |
| 14:29.23 | woglinde | but we do not need the whole manifest |
| 14:29.43 | mckoan | woglinde: same here |
| 14:29.54 | mago_ | cool, that was my next question.. how to make this injection into all standard images of our distro. i was thinking i'd create a new "core-image"-like class and let all my images inherit that |
| 14:30.17 | mago_ | woglinde: what do you ship with a build if not the whole manifest? |
| 14:30.40 | woglinde | mago machine |
| 14:30.45 | woglinde | and such on |
| 14:31.24 | *** join/#oe shinobi (~shinobi@78.176.131.144) |
| 14:31.33 | *** part/#oe shinobi (~shinobi@78.176.131.144) |
| 14:32.04 | woglinde | mago a uuid create by uuid distro distro version date |
| 14:32.22 | woglinde | and the image name of course |
| 14:33.46 | mago_ | woglinde: hm, okay. but won't that change for each rebuild? |
| 14:34.01 | mago_ | i would like something that i can use to reproduce that exact build at a later time |
| 14:34.11 | *** join/#oe peteru (nobody@60-242-171-118.static.tpgi.com.au) |
| 14:45.18 | woglinde | mago sure thats the reason |
| 14:45.25 | woglinde | to have a manifest |
| 14:45.47 | woglinde | so we can verify a machine has the image it should have |
| 14:45.55 | woglinde | and not some developer stuff |
| 14:46.20 | woglinde | but when you use opkg update upgrade |
| 14:46.38 | woglinde | the information might be outdated ;) |
| 14:49.46 | *** join/#oe tsramos (~tsramos@134.134.137.75) |
| 14:51.30 | *** join/#oe tsramos (tsramos@nat/intel/x-ethbkbbbdrqqgdmq) |
| 14:53.19 | *** join/#oe aragua (~aragua@91-224-149-44.tetaneutral.net) |
| 14:54.40 | pompomJuice | can anyone see anything obviously broken in the following user password config: |
| 14:54.43 | pompomJuice | EXTRA_USERS_PARAMS_append = 'usermod -p "`cat ${WORKDIR}/secret-root.txt | mkpasswd -m sha-512 -s`" root;' |
| 14:55.07 | pompomJuice | The result is an image that wont authenticate |
| 14:55.30 | pompomJuice | doing a usermod command exactly like that on a device works perfectly |
| 14:57.43 | bluelightning | pompomJuice: I believe our version of usermod provides a -P option to take the plaintext password, I'd suggest using that |
| 14:58.05 | bluelightning | pompomJuice: also, if you're using _append, always put a leading space in the value |
| 14:58.22 | pompomJuice | aah ok |
| 14:58.25 | pompomJuice | I will try those |
| 14:58.32 | woglinde | pompomJuice we use openssl passwd -1 |
| 14:58.35 | pompomJuice | what you say, "our usermod" |
| 14:58.54 | woglinde | that produces a working passwd for /etc/passwd |
| 14:58.54 | bluelightning | pompomJuice: OE patches that option in |
| 15:00.09 | pompomJuice | let me try that -P |
| 15:00.37 | pompomJuice | my colleague set us up that command but he never tested it |
| 15:04.13 | bluelightning | I'm assuming btw that you've considered the security implications of having every device have the same root password on it... |
| 15:04.53 | pompomJuice | I guess we thought it might be a maintenance nightmare if all are on some random password? |
| 15:05.07 | pompomJuice | but no |
| 15:05.14 | pompomJuice | we are kinda noobish when it comes to security |
| 15:06.11 | pompomJuice | nobody is supposed to have this password but me |
| 15:06.43 | woglinde | okay I am heading home |
| 15:06.47 | woglinde | till later maybe |
| 15:06.59 | pompomJuice | EXTRA_USERS_PARAMS_append = ' usermod -P "`cat ${WORKDIR}/secret-root.txt`" root;' |
| 15:07.12 | pompomJuice | would that backtick cat command work inside your usermod mechanism? |
| 15:07.20 | pompomJuice | I dont want the password in our VCS |
| 15:08.27 | woglinde | pompomJuice hehe good idea |
| 15:09.22 | pompomJuice | the secret-root.txt is fetched and destroyed on each build. It originates from a location that only I can access. |
| 15:09.42 | pompomJuice | surely someone could look at the file during do_rootfs... but still |
| 15:11.59 | pompomJuice | only I know what is cooking on our buildserver |
| 15:14.05 | bluelightning | it'll be in the log/run files for the task |
| 15:14.20 | bluelightning | only the hashed value should end up on the target though |
| 15:14.54 | bluelightning | the issue is if someone reverses or otherwise obtains that password, they then have root access to every other device with the same image on it |
| 15:19.36 | *** join/#oe Aethenelle (~Aethenell@199.15.128.78) |
| 15:25.19 | *** join/#oe SorenHolm (~quassel@5634f191.rev.stofanet.dk) |
| 15:30.34 | Crofton|work | http://stackoverflow.com/questions/tagged/openembedded |
| 15:30.59 | Crofton|work | thansk to everyone keeping an eye on this |
| 15:40.04 | *** join/#oe tsramos (tsramos@nat/intel/x-qpweyulhaqwzcymf) |
| 15:40.51 | *** join/#oe SorenHolm (~quassel@5634f191.rev.stofanet.dk) |
| 15:59.09 | Crofton|work | http://pastebin.com/4Ck2Txuu |
| 15:59.14 | Crofton|work | libarchive fails |
| 16:19.48 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 16:25.44 | *** join/#oe sarahsharp (~sarah@134.134.139.72) |
| 16:33.14 | *** join/#oe SoylentYellow (~SoylentYe@209-234-137-234.static.twtelecom.net) |
| 16:42.21 | Crofton|work | cleansstate libarchive and restarting clears the hurdle |
| 16:42.25 | Crofton|work | RP, ^^^ |
| 16:43.13 | RP | Crofton|work: I think there is a patch on the list for that |
| 16:43.23 | Crofton|work | ok |
| 16:43.23 | Crofton|work | just checking |
| 16:43.25 | RP | Crofton|work: I'm not 100% convinced its right though |
| 16:43.32 | *** join/#oe kristoffer (~kristoffe@ua-83-227-162-207.cust.bredbandsbolaget.se) |
| 16:44.24 | Crofton|work | seems weird, glad someone else is thinking about it |
| 16:59.18 | *** join/#oe belen1 (Adium@nat/intel/x-wxttlqosgcltthpr) |
| 17:11.21 | *** join/#oe sarahsharp (sarah@nat/intel/x-fwjmndlhwainjcid) |
| 17:12.04 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 17:47.29 | *** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net) |
| 18:30.13 | *** join/#oe SoylentYellow (~SoylentYe@209-234-137-234.static.twtelecom.net) |
| 18:37.36 | Jin^eLD | RP: short question, from your perspective, is it generally OK to use an bb.event.RecipePreFinalise handler to preprocess some variables? I'm referring to my multi-kernels suggestion, wondering if the direction I took makes sense at all? |
| 18:39.45 | kergoth | do note that use of RecipePreFInalise is only appropriate if you're okay operating against unfinalized variables (e.g. you don't care that values you get will not have appends/prepends/overrides/etc applied), unless you want to manually finalize and then use that input to alter the unfinalized datastore. cant' speak to this particular case, lacking context. i'm sure rp will comment, but figured i'd speak up in case he's elsewhere |
| 18:41.27 | Jin^eLD | kergoth: well yes its a case where I need to do some preprocessing/manual finalization (couldn't find another way) |
| 18:41.33 | kergoth | nods |
| 18:42.19 | Jin^eLD | but before I do another spin of the patch it'd be cool to have a hint from the grandmaster if this makes sense at all, because some concerns were raised if this would have impact on performance etc. |
| 18:43.54 | kergoth | fair enough |
| 18:53.56 | *** join/#oe bluelightning (~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209) |
| 18:53.56 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 18:57.45 | *** join/#oe nerdboy (~sarnold@gentoo/developer/nerdboy) |
| 19:00.16 | *** join/#oe SoylentYellow (~SoylentYe@209-234-137-234.static.twtelecom.net) |
| 19:13.49 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 19:30.52 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 19:34.09 | dv_ | anybody ever experienced internal compiler errors with m4-native, OE dizzy, and gcc 4.8.2 (ubuntu 14.04) ? |
| 19:38.37 | dv_ | huh. works fine now after a reboot. that's weird. |
| 19:41.00 | *** join/#oe sarahsharp (sarah@nat/intel/x-bekzunrshhzvojdm) |
| 19:53.37 | *** join/#oe SorenHolm (~quassel@5634f191.rev.stofanet.dk) |
| 19:57.19 | *** join/#oe stefan_schmidt (~stefan@pD9F78BD2.dip0.t-ipconnect.de) |
| 20:04.53 | *** join/#oe stefan__ (~chatzilla@modemcable100.141-19-135.mc.videotron.ca) |
| 20:17.12 | *** join/#oe oldtopman (~oldtopman@unaffiliated/oldtopman) |
| 20:20.26 | *** join/#oe sarahsharp (sarah@nat/intel/x-tyhbfsuqkrhgvjbm) |
| 20:34.58 | *** join/#oe hillct (~hillct@cpe-45-37-78-233.nc.res.rr.com) |
| 20:40.38 | *** join/#oe Aethenelle (~Aethenell@199.15.128.78) |
| 20:58.40 | *** join/#oe ant_home (~ant__@host231-254-dynamic.11-79-r.retail.telecomitalia.it) |
| 21:12.40 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 21:14.53 | *** join/#oe stefan1234 (~stefan@p4FF823C7.dip0.t-ipconnect.de) |
| 21:22.12 | *** join/#oe _dv_ (~quassel@chello062178118086.5.14.vie.surfer.at) |
| 21:30.54 | *** join/#oe anselmolsm (~anselmols@192.55.54.36) |
| 21:31.40 | *** part/#oe anselmolsm (~anselmols@192.55.54.36) |
| 21:49.45 | *** join/#oe Crofton-bot` (~supybot@108.44.120.244) |
| 21:50.32 | bluelightning | _dv_: ICE with a -native recipe means it's your host's compiler failing |
| 21:50.56 | kergoth | gets a qemu-native ICE on ubuntu all the time, thankfully its transient, the second bitbake always succeeds |
| 21:50.57 | bluelightning | which can mean one of two things: host compiler bug, or hardware issues |
| 21:54.20 | kergoth | that's worrisome, i just hit an ICE in nativesdk-qemu.. you'd think it'd be a problem with this VM or th emachine it's on, but it's only ever qemu doing this here |
| 21:57.42 | *** join/#oe Crofton-bot (~supybot@pool-71-171-10-165.ronkva.east.verizon.net) |
| 22:01.42 | *** join/#oe Crofton-bot` (~supybot@108.44.119.236) |
| 22:04.45 | *** join/#oe Crofton|work (~balister@108.44.119.236) |
| 22:11.46 | *** join/#oe Crofton-bot (~supybot@pool-108-44-115-55.ronkva.east.verizon.net) |
| 22:14.13 | RP | Jin|away: FWIW RecipePreFInalise is really as a last resort and if you can do it a different way, I'd prefer to. Equally there are some things which really can only be done with it. |
| 22:15.07 | RP | Jin|away: With the multiple kernels thing, I think we should probably add support for this directly into the kernel classes. We should also take the opportunity to clean up some of the classes, particularly around linux-yocto |
| 22:15.24 | RP | Jin|away: that is my take anyway :) |
| 22:15.45 | *** join/#oe mario-goulart (~user@email.parenteses.org) |
| 22:17.23 | khem` | kergoth: its worth to have gcc-native |
| 22:23.31 | RP | khem`: I have a recipe for nativesdk-gcc btw. Its horrendous though due to relocatability issues with gcc :( |
| 22:24.01 | RP | khem`: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=0ec9a92d3e2e4f1d6fd2b38a2395d19e301b634c - see rp.patch in there |
| 22:24.27 | khem` | hmm EXEC_PREFIX should be enough |
| 22:24.51 | khem` | GCC_EXEC_PREFIX points to a dir if we preserve it then it will relocate itself |
| 22:25.16 | RP | khem`: its not that simple since we relocate libdir and base_libdir |
| 22:25.16 | *** join/#oe Crofton|work (~balister@pool-108-44-115-55.ronkva.east.verizon.net) |
| 22:25.39 | khem` | sysroot ? |
| 22:25.47 | RP | khem`: doesn't help |
| 22:25.52 | khem` | hmm |
| 22:26.09 | khem` | oh nativesdk |
| 22:26.18 | khem` | not native right ? |
| 22:26.22 | RP | khem`: right |
| 22:26.35 | khem` | thats a different beast yes I agree |
| 22:26.59 | khem` | has 46 more recipes to get world building with musl |
| 22:27.02 | RP | khem`: I ended up extending the spec syntax :/ |
| 22:27.11 | khem` | wow |
| 22:27.13 | khem` | thats gross |
| 22:27.25 | khem` | I should look at the patch |
| 22:27.32 | RP | khem`: yes ;-) |
| 22:27.46 | RP | khem`: I hope that isn't 46 more patches to OE-Core for musl btw. I'm getting worried about the shear number of patches we're carrying for it |
| 22:28.10 | RP | We're trying to reduce the number of patches, not collect them :/ |
| 22:28.12 | khem` | RP: they are getting upstreamed very fast |
| 22:28.22 | khem` | so I promise by 1.10 they will be gone |
| 22:28.38 | khem` | Yes I am in that camp too |
| 22:29.04 | khem` | thats why I am tryin to create git trees and gitify our patches for components |
| 22:29.08 | khem` | so its easier |
| 22:29.13 | khem` | hopefully |
| 22:29.41 | khem` | good thing is musl's patches 80% are real fixes |
| 22:29.51 | khem` | which is making package better |
| 22:29.57 | khem` | its not one of hack just for musl |
| 22:30.08 | khem` | some of them are |
| 22:30.18 | khem` | but thats small number |
| 22:30.22 | RP | yes, that helps |
| 22:30.40 | khem` | thats the reason upstream package maintainers are accepting them |
| 22:30.47 | RP | the xorg hack is atrocious mind ;-) |
| 22:30.48 | khem` | except kernel :) |
| 22:31.08 | khem` | there is a reason why lazy binding is wrong |
| 22:31.13 | khem` | I like what we do with musl |
| 22:31.24 | khem` | time to pick kidlets |
| 22:41.05 | *** join/#oe vmeson (~rmacleod@24-212-184-107.cable.teksavvy.com) |
| 22:45.09 | awozniak | how do I prevent patchfiles from being used and .tar.gz files from being unpacked when they're part of the SRC_URI ? |
| 22:45.58 | kergoth | boolean url parameters. unpack= and apply= |
| 22:46.10 | kergoth | e.g. http://foo.bar/baz.tar.gz;unpack=no |
| 22:46.16 | kergoth | iirc anyway |
| 22:46.56 | kergoth | 1/0 yes/no true/false are all valid |
| 22:47.14 | kergoth | i think yes/no is the convention, however |
| 22:47.15 | awozniak | thanks kergoth |
| 22:47.24 | kergoth | since it reads like english |
| 22:47.25 | kergoth | np |