**** BEGIN LOGGING AT Fri Jul 25 03:00:01 2014 Jul 25 08:06:34 Morning all, is anyone succeeded to ecryptfs a folder with an image of yocto? I always got the "rc = [-22]" error and don't know what to do next. For the moment I add ecryptfs to my kernel and tryied to add ecryptfs-utils from meta-ivi. Jul 25 08:39:01 morning all Jul 25 13:06:57 does Yocto forbid all the ports by default with core-image-minimal? I do not seem to be able to get an open port for gdbserver... Jul 25 13:08:05 telnet seems to work, but gdb cannot connect to the established gdbserver on port 2345. Jul 25 13:09:42 no firewall by default Jul 25 13:10:43 strange... Jul 25 13:12:06 then probably my gdbserver package is broken or something. Jul 25 13:14:03 I think the problem is that I was hoping for kindly ignoring this error message as gdbserver got installed: http://paste.kde.org/p7ykn96ub Jul 25 13:14:10 but I do not see such a package in my Yocto generation? Jul 25 13:28:13 I am not sure what this busybox-ntp is and how to fix it just yet. Jul 25 13:39:20 Configuring busybox-ntp. Jul 25 13:39:20 update-rc.d: /etc/init.d/ntpd: file does not exist Jul 25 13:39:25 why is it trying to do that I wonder? Jul 25 14:24:01 anyone know of any tools or have any suggestions on how to troubleshoot video issues under a yocto build? I have hardware that works with an old linux distro with vga=314, but when I use that under yocto I get what looks 4 copies of the screen going accross and all of it fitting in top 1/4 of the screen going down. It's like a refresh rate nightmare without X being involved. :( Jul 25 14:29:24 sorry I don't.. but that almost sounds like a problem with the frame buffer driver(s) Jul 25 14:35:40 could be: moving from a Linux 2.4 based distro to 3.4 is a bit of a nightmare. (My predecessor chose an already EOL product for the first deployment. :( ) Jul 25 14:37:36 finally upgrading from gcc-2.95? :) Jul 25 14:39:45 lpapp. Look at your busybox.bb and bbappends for it. Jul 25 14:41:37 scary, huh, JaMa? Actually, I've been using gcc 4.8 for a lot of work, but this one stupid device/application has been held hostage for way too long. And the only thing that used gcc-2.95 on this was the custom hardware driver. Jul 25 14:42:12 blloyd: did, but could not spot anything obvious, unfortunately. Jul 25 14:42:12 generally it used a gcc 3.X compiler, which was bad enough. Jul 25 14:44:11 lpapp: anyways, the error you listed is the the ntp post installer script which ran close to the gdb post-installation script. As long as the time is right on the box, it shouldn't cause gdb errors. I don't think gdb uses the wall clock anyways, so probably doesn't affect your gdb problem at all. Jul 25 14:45:42 and unless I missed a change, busybox-ntp is not available under an unmodified yocto setup. I have a .bbappend myself to enable it (which I may be canning in favor of meta-oe's ntp package). Jul 25 14:51:39 blloyd: the gdbserver seems to be broken Jul 25 14:52:01 I am trying to send characters over telnet via that port, but it does not seem to reply. I wonder what else could break it. Jul 25 14:52:58 do you have ssh access to the device? Jul 25 14:54:33 blloyd: sure Jul 25 15:20:10 JaMa: Can I merge the autotools patch now? Jul 25 15:26:02 RP: m4 or foreign or both? But I think I'm fine with both now Jul 25 15:26:44 test-dependencies.sh build is just finishing, will send report in 5 minutes or so and it doesn't look bad Jul 25 15:33:29 JaMa: m4 is the one I'd like to get in next. I think we've fixed most of the issues, any remaining ones shouldn't be too bad. foreign can wait a bit longer if needed Jul 25 15:33:49 JaMa: great, I'm pleased things are starting to look a bit better :) Jul 25 15:34:12 JaMa: I pushed the insane change in as I'd like it on all the builds to start getting people to see the issues reported Jul 25 15:34:28 hopefully it will generate a wave of patches Jul 25 15:36:18 RP: Uhg. wasn't the insane stuff already insane enough? Jul 25 15:37:18 lpapp: I suggest ssh in and check that gdb server is running. It can't respond if it isn't running. If it is, try a netstat and make sure the port you are hitting is shown in the list. Jul 25 15:39:57 blloyd: probably :) Jul 25 15:40:53 blloyd: no-no, it is running Jul 25 15:40:58 as I said, I can connect to it via telnet Jul 25 15:41:01 it just does not talk back. Jul 25 15:41:08 RP: I agree with both m4 is definitely fine and insane_qa is good improvement Jul 25 15:41:28 and btw, I started gdbserver manually, so it is not run automatically; that means it is running since I start manually in the foreground. Jul 25 15:41:43 peopele seem to react more to warnings in their own build, than some report sent to ML :) Jul 25 15:42:25 JaMa: yes, I'm hoping that will help :) Jul 25 15:44:49 RP: thanks for reassigning the bug, sorry if I messed up the bugzilla submission Jul 25 15:45:33 Marex: you didn't, I'm just hoping Eric has some better idea than me Jul 25 15:45:42 RP: thank you Jul 25 15:45:44 Marex: you can at least track it to a commit now Jul 25 15:47:09 RP: the problem is that the toolchain CFLAGS changed between 1.2 and 1.3 , it's only since 1.3 that they contain -O2 and -g flags Jul 25 15:47:25 RP: I will leave it to bugzilla now though, don't mean to pester you on IRC, just wanted to say thanks Jul 25 15:47:46 Marex: they've always had those flags Jul 25 15:48:04 Marex: I suspect in 1.3 we started passing extra flag options in that patch Jul 25 15:50:18 RP: ah yes, but I really have no clue how to fix it other than by filtering out the flags for OE_QMAKE_... Jul 25 15:51:21 Marex: that may in fact be the right solution Jul 25 15:51:36 RP: I'm not sure if that really scales Jul 25 15:51:55 Marex: well, there are some specific flags causing problems, lets filter those and see where we are? Jul 25 15:52:00 RP: once CFLAGS change again, the filter would have to be adjusted, so such solution would need some real thinking through first Jul 25 15:52:24 RP: you might be right actually Jul 25 15:52:26 Marex: I'm guessing there are a small number of flags qmake wants to control itself Jul 25 15:52:34 RP: yeah, seems that way Jul 25 15:52:50 RP: you do have a point actually Jul 25 15:53:01 ah ! Jul 25 15:54:10 RP: I will try cooking this solution to see where this gets me, thank you ! Jul 25 15:54:28 RP: I will update bugzilla with a patch if it looks good Jul 25 15:54:46 rburton: what was the option again not to accumulate 100 GB build stuff, just keep the latest? It was some rm/remove keyword, but I just cannot find it anymore. Jul 25 15:55:00 rm_old_work or something like that Jul 25 15:55:11 its in meta-oe iirc Jul 25 15:55:18 ah, rm_work Jul 25 15:55:23 or use rm_work to just clean away work dirs entirely Jul 25 15:55:31 Marex: please do put a summary of the discussion on the bug regardless but sounds good Jul 25 15:55:41 Marex: saves someone like eric duplicating anything Jul 25 15:56:41 rburton: yeah, thanks. Jul 25 15:58:22 RP: argh ... no, this cannot help, the QMAKE is picking CFLAGS themselves too Jul 25 15:59:58 RP: I dont have yocto 1.2 build here, but i have eldk 5.2.1 available (based on poky, no modifications to the toolchain stuff) Jul 25 16:00:07 RP: this is what we have in the CFLAGS there Jul 25 16:00:08 export CFLAGS=" -march=armv5te -marm -mthumb-interwork -mtune=arm926ej-s --sysroot=/opt/eldk-5.2.1/armv5te/sysroots/armv5te-linux-gnueabi" Jul 25 16:00:20 no -O* flags and no -g flags Jul 25 16:00:32 so the qmake does not pick up anything like that into the builds Jul 25 16:00:59 RP: for yocto 1.3 Jul 25 16:01:00 export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types" Jul 25 16:01:27 is it possible to have an image that inherit core-image in one layer and create another image in another layer that is based on the first one? Jul 25 16:01:32 I will have to sum this discussion up in a bit more coherent manner Jul 25 16:02:15 Marex: hmm, I see :/ Jul 25 16:02:31 RP: that's why "unset ..." worked Jul 25 16:02:32 Marex: most of that moved to CC instead of CFLAGS Jul 25 16:03:05 RP: the solution might be to see if qmake is not mistakenly using CFLAGS instead of OE_QMAKE_CFLAGS (?) Jul 25 16:03:25 RP: if qmake was using the later, then we could just fixup the later in the toolchain setup script and be done with it Jul 25 16:03:30 RP: if the former, then we have a problem Jul 25 16:03:37 Marex: possibly. or that the qte script shouldn't be exporting CFLAGS at all Jul 25 16:04:01 RP: the thing that's exporting CFLAGS is actually generic for all SDK toolchains Jul 25 16:04:16 RP: special-casing the qte one is not a way to go I think Jul 25 16:04:39 but then, I am no longer confident in my knowledge of this stuff, so it's better to see what Eric can come up with Jul 25 16:04:54 Marex: the qte one could just unset it Jul 25 16:05:06 with a comment explaining why Jul 25 16:05:08 RP: or filter it out Jul 25 16:05:19 Marex: yes, or filter Jul 25 16:05:20 RP: there's no need to unset everything, only the offenders Jul 25 16:05:29 heh Jul 25 16:05:50 RP: thanks, it's good talking such things through with someone else :) Jul 25 16:05:56 Marex: is there anything left that is useful in there? I suspect qmake would set -pipe Jul 25 16:06:30 there is something in LDFLAGS actually Jul 25 16:06:47 Marex: LDFLAGS != CFLAGS :) Jul 25 16:06:50 -Wl,--hash-style=gnu and such Jul 25 16:06:54 right Jul 25 16:06:55 RP: ah yes, sorry . Jul 25 16:07:05 RP: LDFLAGS would need filtering too, since they contain -Wl,-O1 Jul 25 16:07:37 so it's CFLAGS, CXXFLAGS, LDFLAGS and CPPFLAGS which would need filtering I think Jul 25 16:08:07 Marex: sounds about right Jul 25 16:08:57 RP: I will be off for a bit now, will get back to it shortly (today) Jul 25 16:09:00 thanks ! Jul 25 16:09:28 Marex: np Jul 25 16:15:28 Hello everyone! I'm having trouble finding a way to install systemd into a core-image-x11 derived image of mine. Jul 25 16:15:43 I see systemd_213.bb, but bitbake doesn't recognize that as a valid target. Jul 25 16:16:52 _213 is the version, the packages will be called systemd etc Jul 25 16:16:58 but see the manual for how to switch to systemd Jul 25 16:17:33 rburton: fyi, looks like rm_old_work currently lives in meta-shr (didn't remember seeing it in meta-oe so double checked) Jul 25 16:20:44 rburton: Thanks, is there a guide somewhere? Jul 25 16:21:13 I see that it has to be enabled via a variable called DISTRO_FEATURES, but I don't think simply defining it is the right way (inmy image .bb file). Jul 25 16:21:34 cubicool: http://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html#selecting-an-initialization-manager Jul 25 16:22:15 the yocto documentation is broad, at least read the table of contents so the major manuals so you're aware of what is covered Jul 25 16:23:57 Thanks, rburton. Jul 25 16:24:16 I have the bitbake, yocto, and yocto dev guides open, but my search terms were weak apparently. Jul 25 17:11:07 ok, does anyone have any good reading for KMS and yocto? The samples for syslinux setup use a video=vesafb vga=XYZ syntax, which from my current reading means pre-KMS setup. Jul 25 17:17:03 rm_old_work should move into the core and be considered as a default Jul 25 17:18:19 I did suggest that a while ago, IIRC I didn't get much of an enthusiastic response Jul 25 17:18:51 What I dislike about it today is the way its implemented means your checksums will all shift if you inherit it vs not inheriting it due to changing the task graph. but that wouldnt' be an issue if it was always included :) Jul 25 17:19:30 and surely we could fix that if needed... Jul 25 17:20:55 Do you guys know of anyone using Yocto with this: https://developer.nvidia.com/jetson-tk1 Jul 25 17:21:28 Because I am currently, and I'd like to submit my layers eventually. Jul 25 17:21:49 of course, yeah. i'd love to see rm_old_work go in on general principle, though personally i don't keep my tmpdirs around long enough for it to do much :) Jul 25 17:22:11 It actually works like a charm. I'm trying to get systemd working now, but that will require me making my own custom distro apparently, which looks fun (and not comlicated). Jul 25 17:27:05 Hello Jul 25 17:27:12 hey otavio Jul 25 17:27:27 I have a customer which is updating their SDK from 1.5 to 1.6 Jul 25 17:27:48 otavio: btw I have your & Daiane's book sitting in front of me, congrats! Jul 25 17:28:01 They found that calling the gcc byhand in 1.5 (not using $CC) works, while 1.6 fails. Jul 25 17:28:05 bluelightning: oh man Jul 25 17:28:18 bluelightning: I hope we did not so badly hehe Jul 25 17:28:28 otavio: looks pretty good to me so far Jul 25 17:28:34 :-D Jul 25 17:28:53 re gcc in the SDK, I'm sure I remember that being discussed not that long ago Jul 25 17:29:11 I think the conclusion is that we expect it to be called via $CC Jul 25 17:29:14 They found that calling the gcc byhand in 1.5 (not using $CC) works, while 1.6 fails. In case, with gcc 4.8.1 it does not need the sysroot param and finds out it fine Jul 25 17:29:36 RP: is that correct? Jul 25 17:29:39 bluelightning: isn't this a regression? Jul 25 17:30:26 otavio: no, its not. gcc *needs* that sysroot to be specified Jul 25 17:30:44 otavio: there is a default hardcoded into gcc, its luck whether you match or not Jul 25 17:30:58 RP: and why it used to work? (I am not complaining, but asking) Jul 25 17:31:05 RP: I see Jul 25 17:31:13 otavio: probably they didn't relocate that one Jul 25 17:31:31 * RP has been thinking of making the default "broken" to force the issue Jul 25 17:31:54 RP: I fully support Jul 25 17:32:06 RP: as /this/is/a/invalid/path/for/sysroot Jul 25 17:32:10 :) Jul 25 17:32:13 otavio: right Jul 25 17:32:26 otavio: in theory if we set that in the bintuils/gcc recipes we should be good Jul 25 17:34:41 in fact we should probably patch gcc to find that from the environment in the SDK to make things easier Jul 25 17:34:47 where can I find this dependency? gdbserver: unsatisfied recommendation for glibc-thread-db Jul 25 17:35:41 RP: yes; this would be good Jul 25 17:35:53 RP: as it'd allow broken makefiles which reset gcc to work Jul 25 17:36:06 otavio: "work". You'd lose the other flags Jul 25 17:36:17 RP: yes Jul 25 17:36:51 RP: it "work"; to be sincere I am unsure we ought to "work" or fail and force a proper fix Jul 25 17:36:55 I've just been fighting with a customer about this myself.. they claim "but it works!". I finally had to show them about a dozen cases where it didn't for them to start using '$CC' like they should Jul 25 17:37:07 in this case I'd rather a 'fail' then a 'maybe works' Jul 25 17:37:26 * RP would prefer "fail" Jul 25 17:37:43 fray_: yes; it does makes sense as it may end misbehaving due missing flags or causing different results Jul 25 17:38:29 that is probably why we've never gone the environment route Jul 25 17:38:45 ? Jul 25 17:40:11 in contrast to what I said earlier, setting the sysroot from the environment is probably a bad idea Jul 25 17:40:44 I make use of the sysroot parameter in the environment, but if the toolchain could automatically select it based on the CFLAGS, that would be very useful Jul 25 17:42:41 hi, quick question Jul 25 17:43:10 I need to make a recipe that should depend on the image recipe being build Jul 25 17:43:55 what variables should I use to get the location of the image from the deploy dir? Jul 25 17:47:18 Is it still possible to get GPE with Yocto? Jul 25 17:47:24 I have a client from back in 2007... Jul 25 17:47:55 cubicool: meta-gpe still exists in meta-oe but it isn't particularly actively maintained Jul 25 17:48:33 cubicool: someone would need to migrate the recipes from OE-Classic Jul 25 17:48:52 bbl Jul 25 17:50:01 Cool, thanks. :) Jul 25 17:57:36 so I have this: ./tmp/work/armv5te-foo-linux-gnueabi/eglibc/2.17-r3/packages-split/eglibc-thread-db Jul 25 17:57:47 lpapp: I suggest $TCLIBC-dbg as a dependency. Jul 25 17:57:48 but why cannot I see it in ./tmp/deploy/ipkg somewhere? Jul 25 17:58:10 why is no package created? Jul 25 17:58:17 gdb depends on thread db DEBUGGING symbols being available. Jul 25 17:58:22 blloyd: it is not my recipe; it is the standard gdb in meta. Jul 25 17:58:53 I am just trying to install the gdbserver from it without modification; I oughta be able to do so with core-image-minimal, right? Jul 25 17:59:07 (after building the gdb recipe myself afterwards) Jul 25 17:59:09 just add $TCLIBC-dbg to your image and see what happens. :) Jul 25 17:59:49 I do not follow; why is gdb not working out-of-the-box in Yocto's meta layer? Jul 25 18:00:17 I suggest you rebuild your image, and use EXTRA_INCLUDE += "$TCLIBC-dbg gdb-server" in your local.conf to get the extra programs you want. Jul 25 18:00:17 are you claiming it may be a bug or it is the intended way that everyone adds such things to images? Jul 25 18:00:32 I do not have "my image"; I use core-image-minimal. ;) Jul 25 18:00:38 which is an upstream image in Yocto. Jul 25 18:00:49 In -most- cases, you would be using cross-gdb.. so you don't wnat debug symbols on the target.. Jul 25 18:01:06 if you are trying to debug on the target, then you will want to install at a minimu the target gdb and target libc debug symbols.. Jul 25 18:01:19 nope Jul 25 18:01:30 that would be quite big which we cannot afford; however, we can afford gdbserver. Jul 25 18:01:38 in order ot debug something with threading you need both the libthread_db.so and some ofthe other glibc dbg symbols.. Jul 25 18:01:49 fray_: there is one set of symbols that gdb must have to function. In fact, the kernel needs them too to form a valid multi-threaded core dump.... Jul 25 18:01:50 gdbserver doesn't need -anything- extra on the target to work Jul 25 18:02:09 blloyd, I'm not aware of any.. but perhaps something has changed? Jul 25 18:02:26 well, it gives a warning, but anyway, my gdbserver seems to be broken. Jul 25 18:02:27 I've always dropped gdbserver onto the target.. and then used the -dbg packages to construct a local sysroot that I can debug Jul 25 18:02:35 I cannot talk to it the way that it would talk back. Jul 25 18:02:44 not even from telnet, let alone the host arm gdb. Jul 25 18:03:10 done much with multi-threaded apps? That's the only time the problem I am discussing comes into play? Jul 25 18:03:38 I do my remote debugging w/ gdbserver via the network.. so as long as the network is up.. and the host and target don't haev firewall rules preventing it.. it's worked.. but the last time I did any serious debugging was YP 1.5 based Jul 25 18:03:45 I haven't needed to do so in 1.6 or master Jul 25 18:03:47 All I get is "Connected timed out". Jul 25 18:04:53 gdbserver 192.168.0.32:2345 /usr/bin/foo Jul 25 18:04:57 Process /usr/bin/auth created; pid = 23710 Jul 25 18:04:57 Listening on port 2345 Jul 25 18:05:13 ok, I haven't used gdb-server a lot, so it might avoid the issue (perhaps getting what it needs from the remote debugger?), but the information gdb needs for threading is stripped from the pthread library. Jul 25 18:05:49 and that looks like you have gdb-server on your box already to be that far. Jul 25 18:06:38 yes, I have, and I can connect to it with telnet Jul 25 18:06:57 but if I type +?3F in telnet, I do not see anything coming back from the server. Jul 25 18:07:03 which makes me think the gdbserver is broken. Jul 25 18:07:18 (have no clue how to unbreak it :( ) Jul 25 18:16:13 huh, apparently flex requires flex-native to build its ptest bits, so it can run flex itself. Jul 25 18:16:17 * kergoth adds to todo Jul 25 18:19:34 You know, this is just a side note, but the rampant incompetence of many engineering teams (with vast funds and influence) is so frustrating here in Atlanta it makes me very much want to turn to the dark side. Jul 25 18:19:57 This group thinks Samba is "too hard" so lets put our private, business-critical data on ... wait for it ... Dropbox. Jul 25 18:20:07 dark side is good Jul 25 18:20:14 i hope it's at least in an encrypted disk image Jul 25 18:20:16 heh Jul 25 18:20:26 Patent filings, etc. I just. I don't even. Jul 25 18:20:37 Firmware source code. Jul 25 18:21:01 having that on any server you don't control is a recipe for disaster, and thats not considering the fact that the dropbox employees could get to it Jul 25 18:21:06 I already have Samba setup for them (windows users) on a Linode we host... it works fine. Jul 25 18:21:24 its pretty disturbing that they think samba is hard.. not that i'm a big fan of it, but hey, at least it's not nfs Jul 25 18:21:29 :) Jul 25 18:21:50 To them it's a Z drive. Jul 25 18:21:57 And that's still too hard. Jul 25 18:22:07 One guy is a Ph. D. EE, other is a MS EE. Jul 25 18:22:08 i'm curious about what the dark side is in this context :) Jul 25 18:22:21 The Dark Side is me taking these companies hostage. Jul 25 18:22:33 ahh, right. death star time Jul 25 18:22:55 People and their obseession with the latest buzzword stuff. Jul 25 18:22:57 You know what? Jul 25 18:23:01 FUCK THE CLOUD. Jul 25 18:23:32 I hope that's in a log somewhere and shows up when a future employer googles me. Jul 25 18:32:39 hmm, where can I find the x86_64 gdb on the host in the yocto environment that can debug the arm binary of mine on the host? Jul 25 18:34:22 I tried to use my own arm gdb, but that does not seem to be compatible with the gdbserver Yocto generates :( Jul 25 19:05:34 seebs: could use an opinion on something meta-sourcery related when you have a few minutes Jul 25 19:05:47 Sure. Jul 25 19:07:04 I started working on breaking up the recipe into multiple again. I'm wondering if you think this seems cleaner or not. I figure it'll be much easier to opt-in//opt-out of particular components from the external toolchain when they're separate recipes. and the generic sysroot extraction is less specific to the sourcery toolchain. see https://github.com/kergoth/meta-sourcery/tree/recipe-split. Jul 25 19:07:10 https://github.com/kergoth/meta-sourcery/blob/recipe-split/recipes-devtools/gcc/gcc-runtime-external.bb is an example sysroot extraction recipe Jul 25 19:07:33 https://github.com/kergoth/meta-sourcery/blob/recipe-split/recipes-devtools/gcc/gcc-external-cross.bb sets up the symlinks/wrappers in the sysroot to be able to run the toolchain binaries Jul 25 19:08:52 Did I send you the current meta-sourcery tree we're using? I know I sent one at one point, I don't recall how current it was. Jul 25 19:08:57 this has no multilib handling yet, i realize. https://github.com/kergoth/meta-sourcery/blob/recipe-split/classes/common-license.bbclass sets up automatic LIC_FILES_CHKSUM to the common license files if LICENSE is set and LIC_FILES_CHKSUM isn't. https://github.com/kergoth/meta-sourcery/blob/recipe-split/classes/external-toolchain.bbclass is the core of the recipes including sysroot extraction, and external-toolchain-cross.bbclass just handles Jul 25 19:08:57 symlinking/wrapping external binaries into cross Jul 25 19:09:00 I ask because I did at least some of that. Jul 25 19:09:06 In particular, I did multlibs. Jul 25 19:09:09 I remember looking at one, but i think it was quite a while ago Jul 25 19:09:46 I think I had multilibs working, and also had cross/cross-canadian working. Jul 25 19:10:04 And it might be worth looking at it as a possible starting point, although I think at this point it's missing some significant changes from your branch. Jul 25 19:14:12 I'm particularly proud of the generic sysroot extraction, though i admit the code probably isn't ideal. It searches multiple base paths in the external toolchain, and also checks multiple alternate locations within the sysroot using a MIRRORS-like mechanism. perhaps we can pull in the best of the two meta-sourcery trees Jul 25 19:14:37 https://github.com/kergoth/meta-sourcery/blob/recipe-split/classes/external-toolchain.bbclass#L23-L34 Jul 25 19:17:36 on the plus side, the main thing i wanted to know, whether a broken up recipe is a good thing, i have an answer to, since we both did it independently Jul 25 19:17:51 Yeah, I think my breakout is different from yours, but it's definitely a good idea. Jul 25 19:18:05 anyone know why we make /home as drwxr-sr-x (i.e. the "s") -- it has fray 's fingerprints on it but he's only guilty of importing it. Jul 25 19:18:06 Mine specifically aims to make it easier to rebuild libc, because that's a common customer requirement. Jul 25 19:18:28 I would assume the intention is to make home directories default to /home's group instead of root's group? Jul 25 19:22:06 I was hoping that aligning the recipe structure to precisely mirror hte upstream recipes would make it easier, it could even be done as a bbclassextend of 'external'. I also was focused on making the extraction generic, such that it should work with other toolchains than just sourcery, and could in theory be used to extract something from the host sysroot (that is, /) to support a native machine more easily Jul 25 19:22:08 * kergoth ponders Jul 25 19:28:55 that kind of hurts my head. imagine there are no recipes in meta-sourcery, just a few bbclasses which are used via BBCLASSEXTEND to create versions of the main recipes which pull things from an existing sysroot, and bbappends to the toolchain recipes which extend them and tweak the FILES variables to make them less greedy. Jul 25 19:31:17 Hmm. That's an interesting idea. Jul 25 19:31:27 Ours has additional magic because of space/speed issues. Jul 25 19:31:49 We don't actually ship with the entire tree unpacked; we bundle up sets of related multilibs into cpio archives, which we gzip. Jul 25 19:32:02 ah, right, i remember you mentioning that. that's quite interesting Jul 25 19:32:16 If you bundle the whole set up, it takes way too long to read things from the archives. Also, bzip2 is an order of magnitude or so slower to decompress. Jul 25 19:32:48 But if you bundle subsets, it tends to go pretty smoothly and get good results, and is about the same speed as copying from a raw filesystem. Jul 25 19:33:06 I was thinking about switching to cpio instead of cp even for fully extracted toolchains, to avoid cp annoyances. heh Jul 25 19:33:08 that's pretty cool Jul 25 19:33:10 And if you were putting the extracted archives in git, which kills/breaks symlinks, it eliminates a ridiculous quantity of duplicated files. Jul 25 19:33:37 I'll go grab the current tree and put it somewhere you can look at. I've been using it at least somewhat successfully with a 4.9 preview drop. Jul 25 19:34:22 cool, i'd certainly be interested in that. it'd be nice to have a best-of-both-worlds setup. i particularly like your toolchain wrapper generation to deal with tuning arguments and whatnot Jul 25 19:35:29 kergoth -- someone here thinks they found a bug with one of your commits.. :) Jul 25 19:35:40 commit b45c9ed40bb4f893f99127a21776aef3ae888ad7 Jul 25 19:35:41 that happens :) what's the issue? Jul 25 19:35:44 Author: Chris Larson Jul 25 19:35:49 Date: Tue Sep 30 16:30:41 2003 +0000 Jul 25 19:35:53 Add base-files 3.0.10 (from debian). Jul 25 19:35:54 :) Jul 25 19:35:55 haha Jul 25 19:35:59 wow, that's old Jul 25 19:36:01 that's an oe-classic commit number bTW Jul 25 19:36:33 the issue is when the base-files was transitioned into the newer style stuff in commit 1295a2da65762726681b781337970b44b520f0d3 (Oct 2004) ;) Jul 25 19:37:26 the 'dirs2775' perm files, /home, /usr/src and /var/lib/local all lost their group names.. Jul 25 19:37:37 so they becmae 2775 root:root.... before they were.. Jul 25 19:37:55 2775 root:staff, 2775 root:src 2775 root:staff.. (from what I can tell) Jul 25 19:38:12 so the 2775 root:root is a bit 'umm odd'.. and could be a security hole in some odd context. Jul 25 19:38:19 ANYWAY.. I told him to file a bug.. :P Jul 25 19:38:27 but thought you'd like a 10 year old defect Jul 25 19:39:04 My oldest defect is one I filed against NeXTStep 0.8 or so. Jul 25 19:39:10 Which I believe is still present in modern OS X. Jul 25 19:39:21 It was *accepted* as a defect, way back when, but never got fixed. Jul 25 19:39:27 hmm, I don't see anything in the commit that removes a chgrp or chown. in fact, the previous removed /usr/src Jul 25 19:39:39 The bug: If you have a password containing control characters, LoginWindow doesn't accept it, even though a console login would. Jul 25 19:40:05 the commit 1295a2da65762726681b781337970b44b520f0d3 added those in.. the previous version (original version that is) had some chowns in it.. Jul 25 19:40:09 And thus, my brief period of using ^S^E^E^B^S as a password ended. It lasted about an hour. To this day, I've never seen a password-cracker which even *tries* control characters, though. Jul 25 19:40:56 anyway.. ignoring the historical non-sense.. I don't think there is any reason for those three to be set 2775 root:root.. Jul 25 19:41:31 agreed Jul 25 19:41:53 so base-files and files/fs-perms.txt needs to be fixed Jul 25 19:45:07 as far as i can tell, the chowns in base-files were always commented out Jul 25 19:45:08 * kergoth shrugs Jul 25 19:46:03 the bitbake import really obscured some of the things, so I'm not sure Jul 25 19:46:18 'er.. bitbake -- bitkeeper Jul 25 19:46:22 (god I hated that system) Jul 25 19:46:34 yeah, bk had that annoying thing where the creation of new empty files was separate from the content Jul 25 19:46:48 made the imports all ugly Jul 25 20:10:13 Man, I hate it when I've hacked on a feature so long that the git historyi s just mangled and i have to go back and completely rework the history nearly from scratch Jul 25 20:10:14 not fun Jul 25 20:15:18 ya.. I try not to do that... but it seems to happen every now and then Jul 25 20:15:28 lots of rebase and manual edits at that point Jul 25 20:16:01 lol.. bitbake/oe-core just ran my 20 CPU (40 w/ HT) and 128 GB of ram "out of resources" building toolchain components.. Jul 25 20:16:22 the bitbake parallel of 40 and the make -j 40 ran it our of some resource.. Jul 25 20:16:30 I dropped the -j to 16 and it's MUCH happier Jul 25 20:17:08 * kroon wishes he had a 40 core/128GB system Jul 25 20:17:13 try make -j -l40 Jul 25 20:17:18 too bad it's only mine temporarily.. Jul 25 20:17:48 (it's a multiple developer access machine, but I'm the only one on it since I'm currently setting it up) Jul 25 20:17:54 sweet :) Jul 25 20:18:46 I wonder what JaMa uses for his world/test-dependencies builds Jul 25 20:19:18 -j 8 only Jul 25 20:20:01 ah Jul 25 20:20:39 but a lot of ram for 60G tmpfs Jul 25 20:21:06 Yeah, i try not to mess up the history too, its usually when the task isn't a priority and/or gets set aside for a long period of time before i get back to it. its easy to cheat and pause the task by checking in the current state blindly :) Jul 25 20:41:56 Hmm, its a pain to set things like file-checksums and vardepvalue when overrides are involved Jul 25 21:00:46 fray_, i gave you credit for the research in bug 6579 Jul 25 21:00:48 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=6579 normal, Undecided, ---, richard.purdie, NEW , Default fs-perms.txt has odd settings for /home and other dirs Jul 25 21:02:06 lol Jul 25 21:30:13 * darknighte signs out of IRC for the weekend Jul 25 21:42:46 paulg: fancy just sending a patch for it? :) Jul 25 21:43:04 paulg: it does look a bit crazy so I'm happy to see it fixed Jul 25 21:43:38 RP, can do. Jul 25 21:44:38 I was discussing with fray_ in another channel that it kind of sucks that we have the information stored in two places... Jul 25 21:44:52 fs_perms and the base_files recipe. Jul 25 21:45:22 ya.. fs-perms SHOULD have corrected any change he made in the fs-perms files.. Jul 25 21:45:53 but for one of them it didn't.. it didn't change an existing symlink to dir.... Jul 25 21:46:08 I tried to clobber the /var/log --> /var/volatile/log symlink from an appended fs-perms.txt Jul 25 21:46:28 I know the file got parsed, cause it fixed up the kooky perms discussed above. Jul 25 21:46:50 I would have throught that it would have warned if nothing else.. Jul 25 21:47:04 but looking at the code I'm not seeing it.. and I'm forgetting it.. Jul 25 21:47:06 anyway fray_ put me onto doing the bbappend for base_files, so hopefully that will let me get my log files on disk. Jul 25 21:48:29 'er.. I'm forgetting how I originally implemented it.. Jul 25 21:49:42 it was intended originally though that any changes to fs-perms.txt would apply everywhere or at a minimum a QA warning would be generated saying it failed to apply.. Jul 25 21:49:56 it may simply be a case of fixing a 'link' to a 'dir' was missed in the original work Jul 25 22:01:51 seems /var/mail should be root:mail and not root:root as well, given that it is chmod 2775 Jul 25 22:02:39 fray_, will the fs-perms.txt processing get angry if the system configuration doesn't create a mail uuid, yet I ask for it in there? Jul 25 22:02:51 yes.. Jul 25 22:02:53 I have a whole set of bb files now for building GDAL, OpenSceneGraph, GeographicLib, and a bunch of utility osg libraries. Am I replicating work? Jul 25 22:02:55 er, group id. Jul 25 22:03:02 any group ids used must be defined prior to usage Jul 25 22:03:42 setting /var/mail to 2775 doesn't make sense if it is root:root Jul 25 22:04:23 ooh sweet. just checked my booted system and id mail exists. Jul 25 22:04:37 is /var/mail in base-files? Jul 25 22:04:37 uid=gid = 8 Jul 25 22:04:43 lemme check Jul 25 22:05:40 yes Jul 25 22:05:44 and it is wrong :) Jul 25 22:05:47 dirs4775 = "/var/mail" Jul 25 22:06:05 should be 2775 based on what is in fs-perms.txt and what ubuntu has. Jul 25 22:06:09 * paulg fixes Jul 25 22:07:44 that directory should have been "corrected" Jul 25 22:08:31 oddly on my deployed target, it didn't get created _at_all_ Jul 25 22:08:53 that is what I expected actually Jul 25 22:08:54 * paulg wonders if dirs4775 is even parsed Jul 25 22:09:08 do_install_append_linuxstdbase() { Jul 25 22:09:08 for d in ${dirs3755}; do Jul 25 22:09:08 install -m 0755 -d ${D}$d Jul 25 22:09:08 done Jul 25 22:09:08 for d in ${dirs4775}; do Jul 25 22:09:09 install -m 2755 -d ${D}$d Jul 25 22:09:09 done Jul 25 22:09:10 } Jul 25 22:09:15 only processed if -linuxstdbase- is defined.. Jul 25 22:09:26 otherwise, it's only generated "on-demand" Jul 25 22:09:49 yeah, that looks wrong. Jul 25 22:09:54 so it's not -really- 4775.. someone just used '4' Jul 25 22:10:02 dirs4775 using -m 2775 :) Jul 25 22:10:20 same with the 3755 one. Jul 25 22:10:24 kind of misleading. Jul 25 22:10:32 ya, they used it as a counter.. Jul 25 22:10:43 thats really confusing.. Jul 25 22:10:45 ouch. Jul 25 22:11:01 should have been something like dirs775-lsb dirs2775-lsb Jul 25 22:11:08 I didn't even see that pattern. Jul 25 22:17:11 fray, I'm thinking of renaming those to have names that don't suck, but that would break anyone who is currently bbappending them now. Jul 25 22:17:21 it shouldn't.. Jul 25 22:17:29 they're only active if the 'lsb' distro feature is enabled Jul 25 22:17:30 should be easy enough to resolve, just reference the old vars in your new ones Jul 25 22:17:33 Do we treat that as a sacred API, or just do the right thing and fix the suckage? Jul 25 22:17:35 * kergoth yawns Jul 25 22:18:14 I'd fix it.. I don't think this one is sacred Jul 25 23:47:45 RudiStreif: hey Jul 26 01:08:43 anyone have webkit-gtk_2.4x in a staging area somewhere? Jul 26 01:09:22 anyone even tried it? **** ENDING LOGGING AT Sat Jul 26 03:00:00 2014