**** BEGIN LOGGING AT Tue Jul 09 03:00:00 2013 Jul 09 05:10:56 Hi all, to which mailing list do I submit a patch to /build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/libdce/git-r1/git/wayland-drm-protocol.c, anyone knows? Jul 09 07:24:20 good morning Jul 09 09:03:06 Hi where can I find documentation on how to get X11 working properly when building with yocto :) Jul 09 09:03:20 fenrig: just works for me, what's the problem? Jul 09 09:04:48 (cross-posted from #oe) Hey, I have a question. I am trying to bitbake a package, and this package depends on another package. However... it seems as if the second package gets compiled for x86_64, while the project as a whole is ARM. This causes the first (dependent) package to fail, with an error that it ELFCLASS32 is (obviously) not right for building an ARM program. This is the error output: http://pastebin.com/727V2g9r Jul 09 09:04:49 rburton_: Well i'm at the moment making a image based on core-image-minimal with qtbase, so I assume (yes I know this isn't that good) that X will be included. But I just have to include X to have it working properly, no need to configure anything? Jul 09 09:04:57 It seems -c cleanall on perl or the original package does not help either. Anyone have any suggestions Jul 09 09:05:49 fenrig: probably best to start with something a bit bigger than minimal, there's a base x11 image you can start from Jul 09 09:05:57 good morning all Jul 09 09:06:36 rburton_: ah where can I find this image? Jul 09 09:07:15 fenrig: cunningly called core-image-x11 ;) Jul 09 09:08:39 rburton_: Very cunning indeed, thx for your help. Also do you have any documentation advice, I'm having a hard time with finding certain information Jul 09 09:09:09 fenrig: only the documentation on www.yoctoproject.org Jul 09 09:09:16 unless you have something more specific Jul 09 09:10:30 Well yes, I want to know more about existing images and how they work, especially the core-image-x11 Jul 09 09:10:57 fenrig: "how they work" is a bit general term Jul 09 09:11:13 you can get a list of images by doing something along the lines of ls */recipes/*/images/*.bb Jul 09 09:11:26 are you asking how OpenEmbedded works, or? Jul 09 09:12:12 no not really, I'm trying to find that out while I'm trying to get things working. At the moment I'm trying to include Qt in my image. Jul 09 09:12:54 and looking at core-image-x11 you'll see that adding the x11-base image feature gives you a base X stack Jul 09 09:14:10 huge netsplit :/ Jul 09 09:14:29 also about the rpm's that I generate (using yocto distro) can I manually install them later? And is there a package manager included for that or do I have to add one to the image? Jul 09 09:14:41 fenrig: yes Jul 09 09:14:56 if the image features contains package-management, you get your chosen package manager Jul 09 09:15:14 shouldn't he enable 'package-management' in distro features to get the package manager in the image? Jul 09 09:15:34 ah, image features, sorry Jul 09 09:15:42 okay cool :D Jul 09 09:15:55 thx guys you helped me out a lot. Jul 09 09:17:41 fenrig: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html contains all these answers Jul 09 09:18:12 rburton_: I have it open already, but I did not read everything already. Jul 09 09:18:30 but obviously I should. Jul 09 09:22:19 ohyeah, extracting the rootfs.tar.gz to a sd kaart, is there a good tool for this or just use tar? Jul 09 09:23:18 the rpi layer has tools to automate all that, some other layers seem to expect people to write their own script Jul 09 09:23:52 i'm using the beaglebone black here :p Jul 09 09:24:46 afaik, meta-ti doesn't have any tooling to create sd card images for you Jul 09 09:24:58 but i don't have anything that uses meta-ti, so don't expect me to know :) Jul 09 09:26:15 i'm actually using meta-beagleboard instead of meta-ti :) Jul 09 09:40:08 fenrig: nice to hear you survived to the first impact Jul 09 09:47:55 ant_work: Yes I'm quite suprised actually. I'm still a bachelor student that just passed his second year :D Jul 09 09:50:11 there are oddities in that layer, though. Probably purposedly done. Jul 09 09:53:27 Can any of you guys give a spot of advice over setting up a .bbappend to modify busybox? Jul 09 09:55:33 I want to change few vars set up by a lower layers defconfig. From what I can see you have to implement do_prepare_config_append() - the only example I can find just uses sed to replace strings, so is that it? Should I just replace instances of "# CONFIG_WIBBLE is not set" with "CONFIG_WIBBLE=y"? Is there a more intelligent way that you can go about it? Jul 09 10:05:38 pev: which version of the build system are you using? Jul 09 10:07:04 pev: if it's 1.4 (dylan) or above you can use config fragments with busybox, i.e. you just add the options you want to enable to a .cfg file and then add that to SRC_URI in a bbappend in your layer Jul 09 10:09:07 Does anyone here have any idea why a package I'm building for ARM would try to include an .so file that doesn't match its architecture? I've clean everything, and yet, it fails for including the wrong files. Any suggestions here? Jul 09 10:10:18 Stygia: because the makefile is using the wrong compilier? is the .so compiled for your build host? Jul 09 10:11:18 rburton_, The .so is for my target host, for some reason, I recipe I wrote tries to include this file, from an x86_64 dir. As in, another package (in x86_64) tries to depend on the correct .so file, and it fails due to ELFCLASS error. Jul 09 10:11:36 http://pastebin.com/727V2g9r Jul 09 10:11:42 rburton_, This is the output. Jul 09 10:12:04 rburton_, From do_compile I believe, this is what bitbake with no -D's showed. Jul 09 10:13:12 Stygia: run file on the .so it moans about, and compare it to a known-good one. Jul 09 10:13:22 Stygia: that will tell you exactly what sort of binary it is Jul 09 10:13:41 oh Jul 09 10:13:48 native perl is loading non-native perl modules Jul 09 10:13:50 that's the problem Jul 09 10:14:05 rburton_, Hmm? Well I have added tons of perl recipes. Jul 09 10:14:21 rburton_, But, they are being 'loaded' as RDEPENDS for my primary script (that depends on all the CPAN modules). Jul 09 10:14:27 you're running perl, so obviously that's perl-native Jul 09 10:14:29 rburton_, How can I prevent native perl from doing it that then? Jul 09 10:14:34 * rburton_ shrugs Jul 09 10:14:43 rburton_, I'm not completely certain I understand. Jul 09 10:14:53 are you messing with the perl path in your recipe? Jul 09 10:14:55 I've just created yet another cpan-related recipe. Jul 09 10:15:00 rburton_, No. Jul 09 10:15:06 try inherit perlnative Jul 09 10:15:16 rburton_, http://pastebin.com/AccF9C06 Jul 09 10:15:18 actually you must be doing that Jul 09 10:15:20 rburton_, This is all of it. Jul 09 10:15:40 rburton_, Uh sorry: bhttp://pastebin.com/AccF9C06 Jul 09 10:16:57 i'm fairly ignorant about how the perl classes work Jul 09 10:17:15 rburton_, That's how I feel about the entire BB system... Jul 09 10:17:47 for some reason your native perl binary is using target lib directory Jul 09 10:18:29 rburton_, Adding inherit perlnative above inherit cpan didn't help. Jul 09 10:18:45 rburton_, I suppose I will try "manually" installing this package, then... as it is possible the cpan modules are failing. Jul 09 10:21:04 Stygia: its likely a bug in the upstream build system Jul 09 10:21:43 rburton_, Quite possible I suppose. Jul 09 10:33:29 bluelightning: I'm not sure of the exact version - it's based on 1.4 but with a load of new upstream stuff from GIT (someone gave me the distro) Jul 09 10:34:18 pev: ok, then you'll very likely have config fragment support in your busybox recipe, so I'd suggest trying that Jul 09 10:34:30 bluelightning: Is there an example of that somewhere obvious I can see? I assume that only works for enabling extra CONFIG_ vars and that you can't disable ones that are already enabled? Jul 09 10:35:27 pev: if you add "CONFIG_XYZ_ Jul 09 10:35:28 er Jul 09 10:35:54 pev: if you add "# CONFIG_XYZ is not set" to your fragment that should turn off options that the defconfig has enabled Jul 09 10:38:46 oh, so quite smart then! Is there a standard fragment filename or string inside so I can grep through the tree to see an example of how to set one up? Jul 09 10:39:28 pev: the fragments all end in .cfg Jul 09 10:40:00 pev: you will probably find some examples in meta-intel Jul 09 10:43:00 Here we go : meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb Jul 09 10:43:12 I have a strange behavior while packaging libax25 Jul 09 10:43:17 I inherit autotools Jul 09 10:43:26 it automatically splits packages Jul 09 10:43:57 can you elaborate on that? Jul 09 10:43:58 Given that it's just via SRC_URI does it just assume it's modifying a file named .config in the root? Jul 09 10:44:14 pev, no Jul 09 10:44:19 however, libax25, and libax25-dev are incorrectly split Jul 09 10:44:34 libax25-dev should include only the headers, and libax25 sohuld include *.so files Jul 09 10:44:38 any ideas how to override them? Jul 09 10:44:50 eren: set FILES Jul 09 10:45:04 eren: but why should the lib package contain the .so symlinks? Jul 09 10:45:29 pev, the yocto kernel has configs for each particular machine stored in a git tree, and it generates the .config from that and your custom fragments Jul 09 10:45:43 (unless it's an evil upstream that drops modules into a libdir) Jul 09 10:46:53 rburton_: well, correct me if I am wrong, a isn't it normal for a library package to contain symlink? Jul 09 10:47:24 tf: Ok - this is for a busybox .config not a kernel, will it still work then? Jul 09 10:47:35 pev, ah, not sure Jul 09 10:47:50 pev: my appologies, I though you meant the kernel Jul 09 10:48:36 eren: .so symlinks belong into the dev package; the runtime package should contain the real, versioned libs Jul 09 10:49:02 eren: no. a normal library package contains eg libfoo.so.1.2 and a libfoo.so.1 symlink. the -dev package contains headers and libfoo.so symlink. Jul 09 10:49:11 tf : No worries, thanks for your help - I'll have a bodge and see what it does! :-) Jul 09 10:49:18 oh Jul 09 10:49:20 http://dpaste.com/1292444/ Jul 09 10:49:23 if you have a real .so file (not a symlink), that's generally a loadable module Jul 09 10:49:36 eren: yes, that's right Jul 09 10:49:38 then it's all normal right now Jul 09 10:49:51 thanks to autotools.bbclass! :) Jul 09 10:49:56 eren: thanks to bitbake.conf Jul 09 10:50:03 eren: this is how libraries work on linux Jul 09 10:50:18 rburton_: yeah, it is a bit hard to understand Jul 09 10:50:27 especially the versioning schema and links Jul 09 10:51:12 is there a way to check dependency information, other than ldd? Jul 09 10:51:21 it's not that complicated really. real library has major/minor version, abi-compat symlink with major version, and unversioned .so symlink for compile-time. Jul 09 10:51:37 use dpkg or rpm on the generated packages Jul 09 10:51:45 might be useful to add a helper to bb for that Jul 09 10:51:52 rburton_: I use dpkg Jul 09 10:52:19 I'm wondering if I should add DEPENDS vriable on bb Jul 09 10:52:32 eren: dpkg -I will help Jul 09 10:52:43 eren: but for library depends, they get generated for you Jul 09 10:53:46 okkie, I will leave as it is then Jul 09 10:53:54 it is just a small package, shouldn't be a big problem Jul 09 10:54:17 * eren time to package ax25-{tools, apps} Jul 09 10:54:34 thanks rburton_! Jul 09 10:57:50 Hmm another question, as I've given up on using the CPAN classes for this recipe... I've set LIBDIR=${libdir} when calling the Makefile.PL, and yet, it seems the recipe tries to install into /usr/local/ Jul 09 10:57:59 Does anyone know if there is a varible like local_libdir? Jul 09 10:58:31 the fix is to stop it installing into /usr/local, not to package up /usr/local/ Jul 09 10:58:39 as your perl won't be looking in there Jul 09 10:59:18 Hmm. Jul 09 10:59:22 I am just doing this: Jul 09 10:59:23 perl Makefile.PL BASE_DIR=${D} DESTDIR=${D} INSTALL_BIN=${bindir} LIBDIR=${libdir} BASELIBDIR=${base_libdir} MANDIR=${mandir} DATADIR=${datadir} Jul 09 10:59:32 Then perl Build build and in do_install perl Build install Jul 09 11:00:23 rburton_, So I'm a bit thrown off that it still installs into /usr/local/. I figured I'd already told it to use the paths from bb. Jul 09 11:06:11 Stygia: should you be specifying PREFIX ? Jul 09 11:06:19 bluelightning: rburton_: what's happened to the xinput-calibration patch? I've any recent sightnings of it... Jul 09 11:09:56 bluelightning, PREFIX? Jul 09 11:10:26 Stygia: I just googled installing perl modules and found this: http://www.perlmonks.org/?node_id=128077 Jul 09 11:10:57 Stygia: there they are suggesting passing PREFIX= on the perl Makefile.PL command line Jul 09 11:11:59 I'm not sure if that helps Jul 09 11:14:21 Ok... Next fun question :-) Does anyone know much about how quilt works in yocto? I've got a u-boot that has a couple of patches that get applied. If I do a "bitbake -c devshell u-boot" It opens up a devshell and an "ls -l patches/" shows the two patch files and a series file. Now this looks to me that yocto's used quilt to put the dir together (as the docs elude to) but it seems quilt isn't set up for use from the devshell - i.e. a "quilt series" doesnt Jul 09 11:14:21 pick up on whats there. Id have thought I should just be able to go straight into working with the patches in the dir? Jul 09 11:17:47 pev, pev that should just work Jul 09 11:18:17 bluelightning, Hmm. Before I got your advice, I managed to actually get this junk to compile. I sed'd both Makefile.PL and Build.PL to use values from BB for all paths, then used the cpan_build class... and it actually build. Jul 09 11:18:29 bluelightning, Thanks for your help anyway dude, you're invaluable. Jul 09 11:18:43 bluelightning, Uh, invaluable is good in English, yea? It doesn't mean worthless? Jul 09 11:18:59 Stygia: no problem Jul 09 11:19:09 Stygia: invaluable is correct, and I'm glad you think so :) Jul 09 11:19:50 bluelightning, I will admit I think the OE documentation is hard to deal with... it's distributed, not well-used, and generally, finding an answer to "How do I X" is hard (For me at least). IRC helps so much. Jul 09 11:21:50 bluelightning, I didn't even know there was a CPAN class when I started writing all these CPAN recipes, until someone here on IRC, probably you or rburton_ I think, told me about it. That must have saved me a few days work. :P Jul 09 11:29:44 Okay so I've added ' IMAGE_FEATURES += "splash package-management x11-base" ' to my custom image Jul 09 11:30:38 and now I can issue X and Xorg, but it doesn't find a screen (when I boot from the anstrom distro from the internal flash, it does find a screen) Jul 09 11:31:02 btw i'm using the serial kernel interface for issueing commands and stuff :) Jul 09 11:40:19 I found out that meta-beagleboard does provide a config file for xorg, and it uses a .bbappend for xorg-xf86-config Jul 09 11:40:29 but for some reason it's not automatically added Jul 09 11:51:52 "beaglebone login: Starting Xserver \n Starting system message bus: open /dev/fb0: No such file or directory" Jul 09 11:51:59 that's what I get :/ Jul 09 11:54:44 tf: Hm, You're right it should - for whatever reason the devshell hides the output (?!) - if I do a "quilt series | less" I can see it...! also a bit puzzled as I run my build as a normal user but when I invoke devshell it starts in an xterm as root(!) which I don't remember giving it perms for... Jul 09 11:58:07 tf: Doing some digging around, it seems that if I run the devshell then do a "PSEUDO_UNLOAD=1 bash" in it then everything behaves better after..?! Jul 09 12:16:03 Hi Jul 09 12:16:27 I am trying to create a class which adds a new task after the do_deploy Jul 09 12:16:44 The class is the add to the recipe if that functions needs to be run Jul 09 12:17:40 when I add the class using "inherit " its shows the new task when I run listtasks for the receipe Jul 09 12:17:48 However that task is never run Jul 09 12:18:04 Can somebody tell me why it is never run ?? Jul 09 12:18:24 What do I need to do to make it the recipe run that task Jul 09 12:18:26 ??? Jul 09 12:24:28 you can use do_deploy_append Jul 09 12:30:13 Hi Is ANYBODY listening? Jul 09 12:32:35 pev: it's not really running as root Jul 09 12:33:07 pev: it's under pseudo, so pretending to be root to any program that asks within the shell, but has no additional permissions Jul 09 12:33:36 pev: (this is how images can be created containing files owned by root without you having to run the build system as root) Jul 09 12:33:56 I need to implement it as a bbclass so that it is generic Jul 09 12:34:10 Michael__: how are you doing addtask? Jul 09 12:34:21 can I post the example here Jul 09 12:34:32 Michael__: use pastebin.com or similar then paste the link here Jul 09 12:35:15 RP spending his sabatical herding cats? :)) Jul 09 12:37:22 its small I will paste here Jul 09 12:37:31 def findfile (sfilename, dir): import shutil import fnmatch import os matches = [] for root, dirnames, filenames in os.walk(dir): for filename in fnmatch.filter(filenames, sfilename): matches.append(os.path.join(root, filename)) return matches addtask do_signing after do_deploy python do_signing() { matches = [] signfiles = [] deploydir = d.getVar('DEPLOY_DIR_IMAGE', Jul 09 12:37:39 oops Jul 09 12:37:46 Michael__: just use pastebin please Jul 09 12:38:30 http://pastebin.com/043jpt8F Jul 09 12:39:16 Michael__: it needs to be: addtask signing after do_deploy Jul 09 12:39:58 ok Jul 09 12:40:03 I try that Jul 09 12:44:19 It still doesn't execute it Jul 09 12:44:58 Michael__: maybe add "before do_build" to that as well Jul 09 12:45:57 ok now it done it Jul 09 12:46:04 thanks a million Jul 09 12:46:49 such a simple thing and it took me ages Jul 09 12:47:51 I have one more question Jul 09 12:48:07 how do I add a dependency to another recipe in a bbclass Jul 09 12:48:08 ? Jul 09 12:48:28 I think it needs to be something like this Jul 09 12:48:59 do_func[deptask] = busybox:do_install Jul 09 12:49:01 ?? Jul 09 12:49:12 any ideas? Jul 09 12:49:31 Michael__: depends what kind of dependency :) Jul 09 12:50:51 Michael__: is this for a native tool that the function needs to use? Jul 09 12:50:58 basicly I need to secure sign the files. but that process to run is in another receipe which must be downloaded first Jul 09 12:51:31 Michael__: ok, that's pretty straightforward Jul 09 12:51:51 can you give an example Jul 09 12:52:00 see Jul 09 12:52:01 Michael__: do_signing[depends] += "somerecipe-native:do_populate_sysroot" Jul 09 12:52:02 if image: Jul 09 12:52:02 d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs') Jul 09 12:52:14 do_configure[depends] += "${INITRAMFS_TASK}" Jul 09 12:52:21 this is kernel.bbclass Jul 09 12:52:55 Michael__: it's "do_populate_sysroot" that is the key bit, after that the files installed by the recipe are actually installed to the sysroot Jul 09 12:53:19 ok Jul 09 12:54:54 how do I know where to access the location of the tool in systroot ? Jul 09 12:55:07 is it a matter of running the recipe and checking where it is? Jul 09 12:56:41 Michael__: if the other recipe installs its files to standard locations then you shouldn't need to know, the appropriate paths are already in PATH Jul 09 12:57:15 ok Jul 09 12:59:04 Do you thing this is a good way to secure sign files? basically this class has a variable SRC_SIGN.. which is set in the recipe and then it looks for it in the deploy_dir_image Jul 09 13:00:01 I'm not really sure what directory I should be looking Jul 09 13:00:45 hi. I'm facing some problems building a freescale arm image on my new build-host. bitbake isn't able to create the rootfs Jul 09 13:00:47 ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored. Jul 09 13:01:36 Michael__: what exactly are you signing? Jul 09 13:02:04 BTW, the build-host is a lxc container, which might be the problem Jul 09 13:02:29 any ideas? Jul 09 13:03:23 for example uImage the dtb file daemons Jul 09 13:05:45 uImage would be in the deploy/images dir, but 'normal' packages will not Jul 09 13:06:27 where should I look up those others then Jul 09 13:06:39 are you signing the packages or the files in the packages? Jul 09 13:06:51 It needs to be done for both Jul 09 13:07:20 the packages will be in deploy//arch Jul 09 13:07:40 but if you need to sing files in the packages, you probably want to do that during the package build, in the workdir Jul 09 13:09:04 klinger: we have seen other reports of this recently, but I'm not sure what the cause is Jul 09 13:09:12 seebs: any ideas? Jul 09 13:09:19 Michael__: files like uImage you could also sign in the workdir Jul 09 13:09:51 Could you give an example Jul 09 13:09:53 ? Jul 09 13:10:25 bluelightning: I built the same image on another machine two days ago, so I'm pretty sure LXC is the cause. Maybe some missing capabilities... Jul 09 13:11:26 klinger: is there a way with LXC to report requests on capabilities that aren't enabled/permitted? Jul 09 13:11:36 Michael__: e.g., see the structure of the workdir for the kernel pakcage Jul 09 13:11:50 the uImage ends up in the image/boot subdir Jul 09 13:13:27 bluelightning: I'm digging through the lxc documentation right now Jul 09 13:16:46 I dont have an image/boot dir Jul 09 13:16:58 in the workdir Jul 09 13:17:12 in tmp/work// Jul 09 13:23:25 yep those are in those package directory Jul 09 13:26:39 so those are in $WORKDIR/package/usr/source/uImage Jul 09 13:26:53 *it Jul 09 13:28:19 so I can access those files for the package directory Jul 09 13:28:50 how to do the addtask Jul 09 13:29:04 so that it would do it when that directory Jul 09 13:29:06 is ready Jul 09 13:29:23 addtask do_signn.. after ?? Jul 09 13:29:26 before ?? Jul 09 13:38:58 Michael__: how are these signatures intended to be verified? Jul 09 13:39:30 I dont know the answer to that Jul 09 13:39:48 I see Jul 09 13:39:54 basically its secure boot Jul 09 13:40:00 I dont know details Jul 09 13:40:28 Michael__: well, it might be worth noting that some package systems e.g. rpm have built-in support for signing (if enabled) Jul 09 13:40:38 I don't know if that has any bearing upon secure boot Jul 09 13:40:41 Michael__: ..../install == $D, the files there are ready when the do_install task finished Jul 09 13:42:48 so you Jul 09 13:42:58 can add your signing task after do_install Jul 09 13:43:28 Michael__: alternatively it is pretty easy to extend do_package, just create a function and add it to PACKAGEFUNCS Jul 09 13:43:59 Michael__: see package.bbclass for reference and buildhistory.bbclass for an example which does just this to look into the contents of each package (before the output package files are created) Jul 09 13:44:09 bluelightning: that might be better option indeed Jul 09 13:45:29 ok will take a look Jul 09 13:48:49 those files are huge Jul 09 13:48:52 :) Jul 09 13:49:31 yes, they have grown quite large over time Jul 09 13:53:50 ok I think I understand it. I will try to do it this way Jul 09 13:54:17 big thanks Jul 09 13:54:23 bye Jul 09 14:18:31 Hi erveryone, Does anyone know why qemugl is not present in poky 9.0.0? Jul 09 14:20:34 romain_: it was a patch we were carrying that didn't apply anymore, and there are other similar patches actually heading upstream. decision was to abandon our patch and wait for gl to merge upstream Jul 09 14:20:53 if you desperately need GL, i believe Tizen has a qemu gl patch Jul 09 14:22:26 Ok thanks for the answer Jul 09 14:24:14 Maybe I will try the Tizen patch in order to enable 3D acceleration Jul 09 14:38:15 If I understand the problem, the only gl implementation with poky 9 is with Mesa Jul 09 14:39:35 well, that's not a problem, run on x86 hw and you get hardware-accelerated GL. Jul 09 14:40:35 other board-specific GL implementations are in the relevant BSP layers Jul 09 14:41:05 Yes I understand but I try to enable gl passthrough with qemu Jul 09 14:42:14 so i recommend investigating the tizen sdk, i think they have gl passthrough and hopefully with a modern qemu. Jul 09 14:44:52 Ok I will take a look to the tizen project Jul 09 14:47:09 Or maybe I will evaluate the performance with virtualbox Jul 09 14:51:21 rburton_: Do you think that virtualbox could enable the 3D acceleration with a qemux86 image? Jul 09 14:51:36 no idea, never used virtualbox Jul 09 14:54:19 Is there a way to skip the regeneration of the configure script step using auto tools? Jul 09 14:54:52 In a package that inherits from autotools, that is. Jul 09 14:54:54 mulhern: no. Jul 09 14:55:24 rburton_: mulhern: er... can't you redefine do_configure to just run oe_runconf? Jul 09 14:55:30 yeah, about to say that Jul 09 14:55:40 if you really can't do it, then just don't use autotools.bbclass Jul 09 14:55:45 it's a hack and we try to avoid it, but it does work Jul 09 14:55:50 but ideally you'll fix upstream if their tarball doesn't autoreconf Jul 09 15:00:12 YPTM: Scott Rifenbark joined the call Jul 09 15:00:28 mulhern: rburton: They also don't supply a Makefile.am. Jul 09 15:01:52 YPTM: Paul Eggleton joined Jul 09 15:01:52 YPTM: davest is in the house Jul 09 15:02:00 YTPM: saul is dialing Jul 09 15:02:04 YPTM: polk joined Jul 09 15:02:08 YPTM: Denys is here Jul 09 15:02:13 YPTM: Darren is on Jul 09 15:02:13 YPTM: Tom Z here Jul 09 15:02:21 YPTM: LaurentiuP joined Jul 09 15:02:32 YPTM is on the bridge Jul 09 15:02:46 YPTM: Cristian present Jul 09 15:02:48 YPTM: AlexG here too :) Jul 09 15:02:51 YPTM: belen joined Jul 09 15:03:17 YPTM: welcome to the meeting, please let me know who's on the bridge Jul 09 15:03:47 YPTM: Any opens? Jul 09 15:04:05 YPTM: ross joining Jul 09 15:04:33 YPTM: mulhern joined Jul 09 15:05:05 YPTM: mark joined Jul 09 15:05:09 YPTM: Sean H. dialing in now Jul 09 15:05:20 YPTM: jzhang's on the call Jul 09 15:06:35 https://wiki.yoctoproject.org/wiki/WW27_-_2013-07-03-3_-_Fullpass_Yocto_1.5_M2.RC1 Jul 09 15:06:41 YPTM: Sean H. has joined Jul 09 15:07:41 fray: there seems to be an rpm/lsb issue 4814, do you have time to look at that? Jul 09 15:09:56 Matthew Weigel has joined Jul 09 15:13:25 sorry lost context, which RFC? Jul 09 15:14:25 Hi all, am I missing something about devshell? The BSP im using compiles fine if I build the kernel. However if I open the devshell for the kernel and execute a "make uImage" it fails Jul 09 15:14:42 arm-linux-gnueabi-ld: unrecognized option '-Wl,-O1 Jul 09 15:15:08 Shouldn't it be doing exactly the same thing or is something missing in my environment / make invocation? Jul 09 15:15:34 you need to call the make with the same arguments as the system does.. Jul 09 15:15:41 you can find those arguments using either the run file or the log. Jul 09 15:17:11 fray: Thanks - which log am I looking for? Jul 09 15:17:43 likely the build log.. Jul 09 15:19:40 I don't have any builds sitting around to look at right now.. sorry Jul 09 15:19:46 (I cleaned everything up yesterday) Jul 09 15:20:20 pev: temp/run.do_* under the work directory Jul 09 15:20:54 blueligtning_: How redefine? Jul 09 15:23:04 I am Jul 09 15:23:30 bluelightning_: Nice one, thanks! Jul 09 15:23:54 mulhern: one sec Jul 09 15:24:02 Now all I need to do is work out who builds the modules...! Jul 09 15:24:06 ugh, there's a number of recipes that suck pam in unconditionally rather than based on the distro feature Jul 09 15:24:09 fray did you seem my above about the rpm bug #4814? Jul 09 15:24:10 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4814 normal, Medium+, 1.5 M3, mark.hatle, NEW , rpm is broken on 1.5 M2 RC1 lsb images Jul 09 15:24:20 no.. will look Jul 09 15:24:29 kergoth: fun, fun. Jul 09 15:24:45 kergoth: approx how many? Jul 09 15:25:09 it looks to me like the rpm database is missing Jul 09 15:25:20 i.e. someone added the clean routine to the install set Jul 09 15:25:26 mulhern: see do_configure() in meta/recipes-devtools/tcltk/tcl_8.6.0.bb for an example Jul 09 15:25:31 kergoth: Oh great! I found that with util-linux (thus my patch). Jul 09 15:25:59 kergoth: that's why i added the warning to libpam :) Jul 09 15:26:10 I thought the pam stuff had been figured out.. :/ Jul 09 15:26:12 "dude, you're building stuff that won't work" Jul 09 15:26:33 but yes, everything needs to explicitly state pam requirements Jul 09 15:27:18 That's what I thought also, but the util-linux one popped up recently, it might have been a util-linux update or build timing change. Jul 09 15:27:33 rburton_: that warning is very helpful, thanks for adding it, i had no idea Jul 09 15:28:06 kergoth: added it because i spent half a day wondering why my pam stuff wasn't working, before discovering that adding the distro-feature helps ;) Jul 09 15:28:34 haha Jul 09 15:28:38 i hate those days Jul 09 15:33:22 it was one of those "but... why... oooooooooooh. whoops." moments. Jul 09 16:11:46 hi to all! here "http://downloads.yoctoproject.org/releases/yocto/yocto-1.4/toolchain/x86_64/" there's a cross-toolchain tarball for cross-compiling application. But the arm version is for armv5 based hardware. there's a tarball for armv7 based hardware? thanks! Jul 09 16:39:27 hi, is there an option for a bit more verbose output other than this: Jul 09 16:39:28 Currently 1 running tasks (165 of 1614): Jul 09 16:39:29 0: gcc-cross-initial-4.8.1-r0 do_compile (pid 12859) Jul 09 16:51:02 lpapp: do bitbake whatever|cat and you'll get a bit more detailed Jul 09 16:51:13 lpapp: or just tail the logs in the work directories if you want the compile lines Jul 09 16:51:23 (which would be crazy when you've got 8 threads and parallel make) Jul 09 16:51:38 fwiw, wind river linux does have a realtime log level changing feature Jul 09 16:55:35 well, the user needs to get some feedback stuff is not stuck. Jul 09 16:56:38 moin Jul 09 17:27:40 lpapp: the flip-side is that previously it did log the stages, and you had no idea what really was happening because it was scrolling past. Jul 09 17:29:31 rburton_: that would be fine because you could get an idea at the end of the compilation unit. Jul 09 17:29:35 just like gentoo does fwiw. Jul 09 17:38:56 rburton_: I need to leave and have to turn the PC off. Is there a way to suspend it, and continue from where it is, tomorrow? Jul 09 17:39:07 it would be a bit unproductive to start from scratch Jul 09 17:39:18 here it is now: Currently 1 running tasks (358 of 1614): Jul 09 17:39:19 0: linux-yocto-3.8.13+gitAUTOINC+f121c06ae8_f20047520a-r4.2 do_fetch (pid 19088) Jul 09 17:40:14 sadly git doesn't support resuming checkouts Jul 09 17:40:33 on SIGINT it will remove everything it downloaded Jul 09 17:40:55 well, yes, but I can wait for the build to start maybe. Jul 09 17:40:59 if it is a few minutes maximum. Jul 09 17:41:24 OE should really export a mechanism to allow --depth=1 clones, for the same reasons as outlined in https://git.gnome.org/browse/jhbuild/commit/?id=40b70d75563f783cf41c403e7c797ab683803c52 Jul 09 17:41:50 lpapp, but broadly speaking, you can just Control-C the thing, and yes, it will pick up where it left off Jul 09 17:54:02 Hi All, I just build fsl-image-core and trying to put it on P4080PCIE board using tftp server but getting this error - VFS: Mounted root (ext2 filesystem) readonly on device 1:0. Freeing unused kernel memory: 260k init INIT: version 2.88 booting /etc/init.d/rcS: line 27: /etc/hostname: Read-only file system Starting udev Missing devtmpfs, which is required for udev to run Halting... INIT: Switching to runlevel: 0 INIT: Sending processes t Jul 09 17:55:10 bluelightning: could you please help me with my question? You have been helping me so you might understand my question better. Pleaseeeeeeeeeeee Jul 09 17:56:16 Lahar: sounds like devtmpfs is not enabled in your kernel config Jul 09 17:56:47 bluelightning: Thank you very much for replying! Any idea how do I enable it? Jul 09 17:57:28 Lahar: if you haven't specified the kernel config yourself I suspect the BSP you are using has a bug Jul 09 17:58:02 bluelightning: oh ok so I should ask freescale people then Jul 09 17:58:23 Lahar: I think that's probably the best course yes Jul 09 17:58:41 bluelightning: Thank you very much for your help! really appreciate it. Jul 09 18:05:42 so good news, tizen's gl stuff is here: https://review.tizen.org/git/?p=sdk/emulator/qemu.git;a=tree;hb=5b17056e3d5c144103dd2c3d71466482093bfa8c. bad news, it's forked from qemu 1.2.0 Jul 09 18:06:27 we need a competition to do things for the YP with millions of $$ as prizes too Jul 09 18:07:27 heh, good luck with that :) Jul 09 18:08:21 That is an awesome idea. Someone should declare a $5M prize for "best improvement in pseudo's diagnostic messages", for instance. Jul 09 18:16:02 hm Jul 09 18:16:17 fairly lame that tizen copied spec files from at least fedora, stripping the changelog Jul 09 18:16:50 * walters recognizes his own signature in "Die libtool, die." =) https://review.tizen.org/git/?p=profile/ivi/gobject-introspection.git;a=blob;f=packaging/gobject-introspection.spec;h=1da5cbe9d7d4c33dcaf7a712ee0192bdd193918b;hb=HEAD Jul 09 18:42:12 Packages created by yocto are default .rpm... Is it easy to modify packages to be .tar.gz? Jul 09 18:45:17 packages are created in whatever format you select in your local.conf file Jul 09 18:45:32 see 'PACKAGE_CLASSES' Jul 09 18:48:26 ok Jul 09 18:48:51 there is option for 3 package classes. Is this full list? Jul 09 18:54:18 perhaps I can set the PACKAGE_CLASSES = package_tar Jul 09 18:56:47 look at meta/classes .. I believe there is a package_tar, I don't know how well it works Jul 09 18:57:59 thats where I found it. I will try run it tomo Jul 09 19:02:16 does bitbake build with all the cores possible as default, or I need to have the MAKEFLAGS set accordingly? Jul 09 19:02:37 the system builds for the machine you have configured.. Jul 09 19:02:43 or are you talking parallel builds? Jul 09 19:03:04 yes, parallel builds. Jul 09 19:03:22 top of the local.conf are settings for parallel package builds and parallel (make) arguments Jul 09 19:03:29 BB_NUMBER_THREADS ?= "32" Jul 09 19:03:32 PARALLEL_MAKE ?= "-j 32" Jul 09 19:03:44 (what I use on my builder.. 16 core + HT and 128 GB of ram) Jul 09 19:06:22 you seem to have a pretty hefty machine. :) Jul 09 19:06:32 yup.. very lucky Jul 09 19:33:26 is it possible somehow to get the built stuff removed automatically for the corresponding packages? Jul 09 19:33:41 the problem is that a fully poky requires a lot of GBs which I may not have available. Jul 09 19:36:43 lpapp, add INHERIT += "rm_work" to your local.conf Jul 09 19:38:24 don't forget downloads... Jul 09 19:38:48 but rm_work is probably the biggest space-saving option Jul 09 19:41:04 i ended up separating OEBASE SCRATCH and DL_DIR on my oo-classic build machine Jul 09 19:49:40 walters: problem is, I already started the build process. Can I remove some dedicated files manually? Jul 09 19:51:02 I guess it is the tmp folder into which I should look Jul 09 19:55:15 yup Jul 09 19:58:37 what can I safely delete in there? Jul 09 20:00:56 during a build? that might be a little dicey... Jul 09 20:01:29 the build stopped Jul 09 20:01:33 due to the space running out. Jul 09 20:01:41 but i would start with tmp/work/[mach]/* Jul 09 20:02:12 when is local.conf evaluated? Jul 09 20:02:32 if I set "rm_work" now, will it get evaluated if I restart the core image creation? Jul 09 20:02:41 when bitbake is launched if i understand your question... Jul 09 20:03:00 lpapp: yup Jul 09 20:03:20 I mean, does it even remove the old works? Jul 09 20:03:21 probably leave existing cruft tho Jul 09 20:03:37 or it is just taking the new builds into account for removal? Jul 09 20:03:57 the latter sounds correct Jul 09 20:04:26 Q: How do I create my own source download mirror ? Jul 09 20:04:26 A: Make a complete build with these variables set in your conf/local.conf: Jul 09 20:04:35 that is a bit ambiguous, isn't it ... Jul 09 20:04:41 deleting everything under tmp/work should be safe... Jul 09 20:04:42 what conf is it referring to? Jul 09 20:04:50 Can someone update the wiki to be more straight-forward/ Jul 09 20:05:00 it is not clear to me what it is referring to. Jul 09 20:05:04 https://wiki.yoctoproject.org/wiki/How_do_I Jul 09 20:05:14 right the first question. Jul 09 20:05:22 sorry, second. Jul 09 20:05:29 conf/local.conf is created for each build you run "oe-init... foo" for Jul 09 20:06:04 I cannot set stuff globally? Jul 09 20:06:13 so it's pretty much local.conf for tuning, bblayers.conf for layer config, etc Jul 09 20:06:15 I mean, rm work is not really target specific. Jul 09 20:06:21 it is a global behavior I would like to have. Jul 09 20:06:39 what you mean by "global" is probably in the machine defaults Jul 09 20:07:00 machine default means? Jul 09 20:07:54 meta-machine layers should have a conf/[distro|machine] set of config files Jul 09 20:08:20 eg, => https://github.com/sarnold/meta-raspberrypi/tree/master/conf Jul 09 20:08:22 well, I have several meta folders. Jul 09 20:08:28 that still does not make it clear. Jul 09 20:08:39 not all are meta-machine tho Jul 09 20:08:39 besides, by global, I really mean global. :) Jul 09 20:08:45 i.e. not separately for each meta, etc. Jul 09 20:09:00 I have no clue what you mean by machine., Jul 09 20:09:01 machine.* Jul 09 20:09:07 something under poky/conf then? Jul 09 20:09:21 poky/conf means? Jul 09 20:09:30 in the example, raspberrypi is a machine Jul 09 20:09:33 Yocto is a complex stuff as I see. :) Jul 09 20:09:46 is there a poky/conf dir? Jul 09 20:09:51 no Jul 09 20:09:56 first of all, I cloned poky. Jul 09 20:10:01 i'm not home right now, so i can't check easily Jul 09 20:10:29 hmm Jul 09 20:10:29 second, I do not have a conf file inside the poky folder.. I checked that as that would sound natural for a global conf. Jul 09 20:10:44 a conf *folder* Jul 09 20:11:09 folder is a file. Jul 09 20:11:56 technically everything is a file in linux... Jul 09 20:12:09 look in poky/meta-yocto/conf Jul 09 20:13:00 look at what? Jul 09 20:13:37 the conf files, etc Jul 09 20:13:59 that's probably the closest to "global" yocto config Jul 09 20:14:17 cannot we just have a global conf right in the root folder, or ~ ? :D Jul 09 20:14:22 why is it this complex? Jul 09 20:15:00 I would not imagine setting up a global setting is this unusual. Jul 09 20:16:08 anyway, could you please fix the wiki? Jul 09 20:16:17 I understand it is a bit vague for newcomers. Jul 09 20:25:46 I wonder why there is no ~/.yoctorc or concept. Jul 09 20:26:05 the current establishment seems 1) Weird with linux culture 2) Not intuitive at first glance. Jul 09 20:28:04 lpapp, having written a build system that i just switched from ~/.config to in-build-dir config, it's because you really want to be able to do two builds at once Jul 09 20:28:18 stable and development branch, etc Jul 09 20:28:40 those are not exclusive .... Jul 09 20:29:46 I spent 30-60 minutes with it Jul 09 20:30:03 and I still have not got the faintest idea about where to put and what to avoid the GB hell. Jul 09 20:33:08 seems it did not survive the automated stop ... http://paste.kde.org/~lpapp/792686/ Jul 09 20:33:11 * lpapp sighs Jul 09 20:33:34 * lpapp starts again from scratch that maybe 30 GB will be enough .... Jul 09 20:36:26 can someone please give me a file path where I can put an "rm work" config that will be valid for any kinda build? Jul 09 20:36:57 IMO, this should be one of the very first FAQ questions. Jul 09 21:05:01 lpapp: /poky/build/conf/local.conf Jul 09 21:22:49 lpapp: i'd try poky/meta/conf Jul 09 21:23:06 mulhern: mr_science I already checked the quick guide in the meantime. Jul 09 21:23:48 well, local.conf would be the typical place but it's not a "global" conf as you've requested Jul 09 21:24:04 we deserve a global conf Jul 09 21:24:20 please bring the ~/.yoctorc style back. Jul 09 21:25:15 depends on whether all *.conf files are read or not Jul 09 21:25:17 mulhern: there is no build folder initially ... Jul 09 21:25:39 you could try adding one in poky/meta/conf and see what happens Jul 09 21:25:56 do a "bitbake -e" and see if gets picked up Jul 09 21:25:59 mr_science: I really do not wanna mess locally. Jul 09 21:26:17 I will get back to yocto in my hobby when ~/.yoctorc exists. Jul 09 21:26:25 or you can live with local.conf for now... Jul 09 21:27:01 yocto is my side project too, as long as we're using oe-classic for work stuff... Jul 09 21:27:04 it is such a basic feature that even minimalistic programs implemented.... Jul 09 21:27:13 I really cannot understand how it is missing for Yocto. Jul 09 21:27:51 it would say odds are it's not "missing" rather it's hidden somewhere not obviuous to us... Jul 09 21:28:03 cat meta/conf/local.conf Jul 09 21:28:03 INHERIT += "rm_work" Jul 09 21:28:37 it is so well hidden that it makes users' life a royal pain. ;) Jul 09 21:28:50 check with bitbake -e | grep local Jul 09 21:29:09 if I use git clean -fdx Jul 09 21:29:17 it will be gone. Jul 09 21:29:25 so I need to redo /all/ the time for the ... sake. :) Jul 09 21:29:33 .yoctorc would be global to all your builds, not local. Jul 09 21:29:40 not sure i understand that one... Jul 09 21:29:54 if you want an equivalent, do what i do, add ~/.oe to BBPATH in your bblayers.conf and create a ~/.oe/conf/site.conf Jul 09 21:29:56 mr_science: using git master Jul 09 21:30:06 mr_science: what do you think will happen to the local non-versioned files? Jul 09 21:30:13 when you clean up the repository for good? Jul 09 21:30:33 i'd say try what kergoth said Jul 09 21:30:33 kergoth: I DO NOT WANNA MODIFY THE GIT SOURCE Jul 09 21:30:35 first of all, you can put your build dirs anywhre, not just inside poky Jul 09 21:30:37 I just wanna build it. Jul 09 21:30:40 i didn't tell you to modify the git source Jul 09 21:30:46 so shove your yelling up your ass Jul 09 21:30:49 I wanna have local global config without touching the damn source. Jul 09 21:30:52 listen to what i say, not what you want to hear Jul 09 21:31:16 you do not have to modify git in any way Jul 09 21:31:26 yes, you have to. Jul 09 21:31:29 i run plenty of builds with those dirs set entirely read only Jul 09 21:31:30 wrong. Jul 09 21:31:51 as for me, Yocto is is a pet project at this point. :) Jul 09 21:32:03 once it can have proper local global configuration, I will consider it. Jul 09 21:32:09 it is such a basic feature. Jul 09 21:32:18 the source should be able to parse a ~/.yoctorc off-hand. Jul 09 21:32:20 it can already do waht you want, you just don't want to bother to learn enough to accomplish it Jul 09 21:32:37 kergoth: you do not even understand the feature Jul 09 21:32:44 haha Jul 09 21:32:46 you are talking about build dirs Jul 09 21:32:50 who cares about build dirs? Jul 09 21:32:54 I wanna use the default stuff Jul 09 21:32:57 with a local global config Jul 09 21:33:05 no, he's telling you how to do what you want with the current implementation Jul 09 21:33:07 you did not even understand that simple bit. Jul 09 21:33:15 i already told you how to accmoplish what you want. it's a one line change to your build direcotry to make it obey a file in your homedir. trivial. Jul 09 21:33:15 the concept of suggesting kergoth does not know something is laughable Jul 09 21:33:17 mr_science: I DO NOT WANNA royal pain. Jul 09 21:33:23 if you're too lazy to do that, i really can't help you Jul 09 21:33:31 kergoth, /ignore him Jul 09 21:33:34 mr_science: you can work around everything, but I do not wanna. Jul 09 21:33:44 I wanna have a basic feature present off-hand. Jul 09 21:33:50 * kergoth rolls eyes and goes back to real work :) Jul 09 21:33:56 that doesn't sound like a workaround... Jul 09 21:34:19 mr_science: have you ever used essential unix tools? Jul 09 21:34:28 which handle a config file in the home directory off-hand? Jul 09 21:34:46 interesting, they did not do the way yocto is hacking around, and they have been around for decades. Jul 09 21:34:51 only since the early 90's... Jul 09 21:35:12 right, tell me why vim handles ~/.vimrc off-hand? Jul 09 21:35:22 or feh, ~/.fehrc Jul 09 21:35:24 et cetera Jul 09 21:35:25 in fact, most modern "things" have gone away from the ~/.foorc concept Jul 09 21:35:31 no Jul 09 21:35:40 kde4 is still having config stuff in the home folder. Jul 09 21:35:45 look in ~/config and ~/local Jul 09 21:35:51 or in /var/ Jul 09 21:35:53 a lot of folks don't understand the inherent flexibility which is a priority for bitbake, nor do they grasp that it's intended to meet all sorts of needs. one of the original design requirements for OE was that it was able to be entirely self contained, as buildroot is Jul 09 21:36:15 lpapp, you fail to understand the same user could run many parallel builds in different dirs Jul 09 21:36:28 ant_home: huh?! Jul 09 21:36:39 mr_science: please do not play word games Jul 09 21:36:47 mr_science: I believe, you understand the concept of "home config". Jul 09 21:36:59 a dedicated stuff which is parsed off-hand by the software. Jul 09 21:37:13 yeah, just no more umpty-ump .rc files everywhere... Jul 09 21:37:19 but honetly, it could be in etc, et cetera... could not care less. Jul 09 21:37:20 "local.conf" is named the way it is becaues that's what it is, local to the build. if you want to configure site-wide, you can use site.conf. Jul 09 21:37:43 all I care, I wanna run stuff off-hand with out-of-box config, and I expect it to work just like in many other projects ... Jul 09 21:37:50 still, kergoth gave you the answer you need, maybe just not the one you wanted Jul 09 21:37:50 I can see why one might want it to obey a dotfile, but it'd be difficult to meet everyone's needs with hardcoded behavior, which is why bitbake obeys BBPATH and BBFILES, to provide the necessarily flexiblity Jul 09 21:38:04 further, yocto is often just a starting point, not an end goal Jul 09 21:38:12 mr_science: no, he explained a workaround Jul 09 21:38:17 many projects build their own setup scripts and tools on top of it, such as angstrom and shr Jul 09 21:38:20 which I explained in the very beginning, I do not care. Jul 09 21:38:57 no, how you use a tool *correctly* i would not call a workaround Jul 09 21:39:29 yes, it makes so much sense to set "rm_work" many times when I wanna have a global config Jul 09 21:39:37 Personally, I find stuff to get irritated with in oe, yocto, and bitbake on a regular basis, I just don't think this is a valid instance of that, nor am I seeing a use case that'd be met by introducing use of a dotfile that can't already be met with greater flexibility by what it does today Jul 09 21:39:41 or make it totally tied to the build or source tree .... Jul 09 21:39:49 Is there anyway I can get do_qa_configure to be more informative? Jul 09 21:40:28 Crofton|work: heh, there's plnety of stuff I don't know, even about yocto (package_rpm is voodoo, i say!) but the implication that I don't understand how a dotfile works *is* laughable :) Jul 09 21:41:56 It says: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Jul 09 21:41:58 mr_science: anyway, I already lost my motivation to provide feedback Jul 09 21:42:02 there's an argument to be made that bitbake doesn't really follow unix philosophy Jul 09 21:42:07 this was a very hostile way of turning it down. Jul 09 21:42:28 mulhern: the autoconf log is config.log in the build directory, you should be able to examine that to find the problematic compiler execution Jul 09 21:42:59 kergoth: What kind of thing should I be looking for? Jul 09 21:43:23 as the message says, it's poking into your build machine instead of the sysroot. e.g. looking in /usr/include, /usr/lib, whatever Jul 09 21:43:32 best to check for problematic -I and -L Jul 09 21:43:36 * lpapp tries to avoid Yocto as much as possible until there is a truly global way of configuring it. Jul 09 21:43:41 could be something hardcoded in one of hte makefiles Jul 09 21:44:03 * lpapp does not wish to spend time to configure it each time something changes Jul 09 21:44:05 tough to crosscompile for arm if it's poking at x86 libraries :) (or what hve you) Jul 09 21:45:14 I could see an argument for moving just the settings which are not build specific, and which govern bitbake behavior exclusively into a dotfile, but at the time we were writing the code, we felt that introducing a second config file foramt when we already had one which we used everywhere would be unnecessary, from what i recall Jul 09 21:46:53 mulhern: what is in your recipe now for autoconf? i've had to add some autoreconf stuff before using the --cross argument Jul 09 21:46:57 every other week i feel like throwing bitbake out a window, but the rest of hte time i thank god i have it, because there just isn't anything else that meets the same needs. it has its annoyances and quirks, but it gets the jobd one, and the way the yocto project is helping compnaies to stop wasting money on the baseline setup which isn't their value add, thereby letting them focus on what *is*, is lovely Jul 09 21:47:27 in fact, I cannot mention a project where the configuration is this tiresome when possible. Jul 09 21:47:45 and it is totally os agnostic observation. Jul 09 21:48:33 coming to Yocto was a de-evolution to me in this sense. :) Jul 09 21:49:41 i guess i don't understand why you're so stuck on the preconceived idea of how it should be configured... Jul 09 21:50:07 because I think with user hat on, not developer? Jul 09 21:50:13 as the end users are actually users? Jul 09 21:50:26 mr_science: Nothing special, actually. I had to move an aclocal.m4 that came in the distribution to an acinclude.m4 so it wouldn't be destroyed. Jul 09 21:50:47 and as it seems, it is an architectural issue ... :( Jul 09 21:51:30 mulhern: make sure that didn't inclue other non-local macros that should be pulled from other packages. when oyu run aclocal, it pulls macros from all over and shoves them into aclocal.m4, so if their build ever used it, it could have more than just the bits you want kept. really depend on the buildsystem in question, of course. Jul 09 21:51:41 e.g. read it and make sure there's no AC_PROG_LIBTOOL and crap :) Jul 09 21:51:41 i've hit a handful of autotools-based recipes where i had similar errors Jul 09 21:52:10 usually doing autoreconf with the right args takes care of it Jul 09 21:52:56 * lpapp should check for existing bugreports in the hope of having had this reported already with many votes on it Jul 09 21:53:53 lpapp, please stop ranting and try to understand how it works instead Jul 09 21:54:08 there is no way your local.conf get rewritten after git pull Jul 09 21:54:24 if you have suggestions on making something better, that's one thing.. but just complaining doesn't solve anyone's problem Jul 09 21:54:48 I already told the master idea from the minute first. Jul 09 21:54:53 * fray routinely uses the same local.conf (and other configurations) for multiple builds and multiple machines Jul 09 21:54:59 please stop this "just complaining" incorrect tsuff Jul 09 21:55:01 stuff* Jul 09 21:55:03 it is not constructive. Jul 09 21:55:24 ant_home: I already understood what it means, but that is vastly different to what I need Jul 09 21:55:38 ant_home: please read back, and try to understand the whole conversation without half-reading it. Jul 09 21:55:50 lpapp, yes your complaing is not currently constructive.. what do you want the system to do, what doesn't it do for you? Jul 09 21:56:07 you're right I lack first part of it, though I get a bad impression Jul 09 21:56:07 fray: :( Jul 09 21:56:17 fray: you did not bother to read the conversation through. :( Jul 09 21:56:21 I wrote at least 5-10 times what I propose. Jul 09 21:56:26 and then why the current system is worse. Jul 09 21:56:30 Sorry, I'm not going to scroll back 14 pages to find the start.. Jul 09 21:56:44 I looked back over the last 5 minutes starting with complaints about somethign VIM related.. Jul 09 21:56:46 if you are not interested in the proposal and problem, why do you ask ? Jul 09 21:56:57 I still don't see what the problem is you are having and what you want Jul 09 21:57:21 if you keep rolling another page without reading the previous pages, it will get worse for others to read through ... Jul 09 21:57:44 the problem seems to be that quite a bit of disk space is used, and lpapp would like to automatically run rm_work as part of every build anywhere on the system to conserve disk space. Jul 09 21:57:47 fray: he wants a .yoctorc file to work instead of kergoth's answer Jul 09 21:58:03 ok.. Jul 09 21:58:08 anything more than that got lost in the noise... Jul 09 21:58:39 sounds like you want a local - local.conf to be loaded... Jul 09 21:58:55 a "global" local.conf... Jul 09 21:59:11 'local' as in his own, vs what everyone else uses Jul 09 21:59:18 global or semi-global, yes. Jul 09 22:00:06 "he wants" is a bit underestimation, a few people agreed upon this when I mentioned. Jul 09 22:00:25 our product(s) generate the local.conf for the user.. but in essence they have a series of include/require statements in addition to what the local.conf sample normally has you configure Jul 09 22:00:48 so my recommendation is simply use an include/require at the beginning/end of your local.conf to pickup your site config Jul 09 22:01:03 lpapp, see this usecase: I'm building Angstrom with rm_work and oe-core without it Jul 09 22:01:16 or if that is too complicated, put it in your own layer, and have the layer's layer.conf pull in those ocnfiguration settings Jul 09 22:01:39 fray: so you propose two steps instead of one Jul 09 22:01:47 surely, your user hat is off? Jul 09 22:01:48 no, I have you two alternatives Jul 09 22:01:55 actually three.. Jul 09 22:01:55 every new build needs a layer config Jul 09 22:02:09 1) write your own configuration program that generates the appropriate local.conf for your projects.. Jul 09 22:02:22 2) echo "include /home/user/.yoctorc" >> conf/local.conf Jul 09 22:02:31 adding your own layer config is about the same as what kergoth said... Jul 09 22:02:38 3) make your own layer with the include (or YOUR configuration) and include the layer Jul 09 22:02:45 ok, let us agree to disagree Jul 09 22:02:58 I will look for a bugreport and vote, and invite others who agree with me. Jul 09 22:03:18 once, it gets somewhat reasonable vote numbers, I will bring it up on the mailing list. Jul 09 22:03:22 or perhaps even before... Jul 09 22:03:40 ...and if it doesn't? :-) Jul 09 22:03:47 * fray waits to see your proposed code.... Jul 09 22:03:52 thing is, telling 3 steps to the end user instead of 1 is like taken the user hat off. Jul 09 22:04:04 not three steps, three -ways- of doing the same thing.. Jul 09 22:04:09 fray: seriously, you have not realized I am not proposing code? Jul 09 22:04:17 bitbake/oe/yocto project gives you all of the rope you could ever need to do whatever you need.. Jul 09 22:04:24 it's up to you to hang yourself Jul 09 22:04:29 code is seconday here. Jul 09 22:04:37 we are discussing *use case requirements*. Jul 09 22:04:49 lpapp: I think everyone is aware you are not offering code. Jul 09 22:05:00 You can have your use case requirements.. if you really need it.. implement it and submit it.. don't expect others to.. Jul 09 22:05:11 bitbake/oe/yocto project work by people submitting RFCs and code.. Jul 09 22:05:13 b46258: 23:04 * fray waits to see your proposed code.... Jul 09 22:05:19 b46258: that was a joke? Jul 09 22:05:36 fray: do not be hostile. Jul 09 22:05:38 if you think something is useful, start with an RFC.. hey I think this would be useful.. Jul 09 22:05:39 feedback is welcome. Jul 09 22:05:45 read the documentation. Jul 09 22:05:47 then submit code to implement it.. Jul 09 22:05:49 lpapp: not specifically a joke, but an ironic pointer to what would have a chance at changing minds. Jul 09 22:05:58 I'm being serious, just complaining about a problem (real or not) won't get it fixed.. Jul 09 22:06:17 b46258: I do not follow. Jul 09 22:06:21 unless your problem happens to be someone elses problem.. they're not going to work on a solution Jul 09 22:06:24 fray: no one is complaining. Jul 09 22:06:35 you brought up the "complaining hostile" handling of a proposal. Jul 09 22:07:01 I outlined my problems with the current way, and I explained why a one-step shot for any build, git, whatsoever scenarios. Jul 09 22:07:09 it is not called complaining. Jul 09 22:07:12 it is called discussion. Jul 09 22:07:33 it is called feedback Jul 09 22:07:34 currently if someone wants help setting up local.conf, their solution is to use one of the many oe/yocto based distributions that has their own "helper" infrastructure, or use hob.. Jul 09 22:07:41 it is called helping the project to move forward from my point of view. Jul 09 22:07:45 at first glance, this seems like a very circuituous way to address the actual problem you had, lpapp Jul 09 22:07:52 exactly Jul 09 22:08:04 ok, I will stop providing feedback here now. Jul 09 22:08:13 honestly, I spend my leisure time to improve things, and this is all I get. Jul 09 22:08:17 I do not need this. Jul 09 22:08:37 and by this, I do not mean disagreement because that is natural. Jul 09 22:08:45 and I think discussion got difficult and complaining easy when most people agreed there are ways to solve your problems and you said they are not acceptable. Jul 09 22:09:12 b46258: please stop this shit Jul 09 22:09:21 exactly.. there are many possible solutions within the existing architecture/implementation. If none of them are adequate, then explain why they're not... Jul 09 22:09:22 there is no complaining outside your brain and fray's. Jul 09 22:09:59 fray: sigh, I did many times, and there are several people here who understood. Jul 09 22:10:06 please ask them, I cannot help you apparently. Jul 09 22:10:17 I accept that others disagree with my proposal as it seemed about a few people. Jul 09 22:10:24 but I do not accept not listening to my words. Jul 09 22:10:30 or well, actually I do not care. Jul 09 22:14:05 it is so obviously not about whether I can hack stuff around Jul 09 22:14:07 or whether it is possible. Jul 09 22:14:14 lpapp, we are sorry for having put you in that bad mood. We'v got your point, you didn't want to see ours. Now pls go trolling elsewhere then maybe send a bugreport or better an RFC. Jul 09 22:14:17 there is a huge difference between possible and a very good solution. Jul 09 22:14:18 I'm not trying to argue with you. You've been very clear about what problems you've had, and what you think would improve that. Jul 09 22:14:38 ant_home: sorry, but I need to put you on ignore. Jul 09 22:14:48 ant_home: as you are not being objective here. Jul 09 22:15:31 lpapp, everyone here is open to new proposal. Send it and it will be preciously considered as always Jul 09 22:16:00 I will read cautiously next time the Yocto manual when it is writing "feedback is welcome" Jul 09 22:16:09 it is here turning out to be called "trolling" for one. Jul 09 22:16:35 that makes me sad... Jul 09 22:17:06 b46258: good to hear.. Jul 09 22:17:37 but "please stop this shit" does not really make me sympathetic to you. Jul 09 22:18:04 b46258: you started, not me. Jul 09 22:18:20 you accused me with "complaining" which is a well, very rude and unfriendly to say the least. Jul 09 22:18:45 where is the good faith? :) Jul 09 22:19:02 I was explaining where the good faith went, actually. Jul 09 22:19:05 anyway, I need to be careful with "feedback is welcome" in the Yocto project. Jul 09 22:19:28 "most people agreed there are ways to solve your problems and you said they are not acceptable." Jul 09 22:19:35 b46258: I do not wanna know your bad faith if good is "accusing others with complaining". Jul 09 22:20:34 maybe complaining is a really horrible thing to you, I dunno. *shrug* Jul 09 22:20:38 but yes, "stop this bad faith" would have been more adequate. Jul 09 22:20:57 I don't much mind it, but it *is* different from constructive criticism or feedback. Jul 09 22:22:04 yes, those are good faith, and you had a bad IMO. Jul 09 22:22:13 I am vastly more interested in addressing the actual problem you had, and working to make it not a problem, than I am with your proposed solution. Jul 09 22:22:30 I am not particularly concerned with what motivations you ascribe to me, either. :-) Jul 09 22:23:05 why do you continue if you are not interested in improving the situation? Jul 09 22:23:56 and no, putting stuff in the build is NOT a solution. Jul 09 22:23:59 ... Jul 09 22:24:03 what if you remove the build dir as I said before? Jul 09 22:24:08 say, in a month? Jul 09 22:24:13 and you can back in half a year? Jul 09 22:24:17 you need to re-read everything? Jul 09 22:24:29 instead of just storing an intermittent config file, and be happy when you come back? Jul 09 22:24:38 surely, that would be tiresome? Jul 09 22:24:52 or if you remove the build dir, and create another one elsewhere with different name, etc? Jul 09 22:24:53 maybe that is the problem, you are viewing the configuration file as intermittent.. it's not intended to be.. Jul 09 22:25:02 or what if the build dir is accessible by one user? Jul 09 22:25:10 by the config should be taken into account for each unix user? Jul 09 22:25:16 my reading of the chat log is that the actual problem you had was running out of disk space Jul 09 22:25:17 Those problems are currently unresolved. Jul 09 22:25:17 the configuration (local.conf) -is- the build control file, and what you would version in your local git (or similar) repository to ensure reproducability Jul 09 22:25:26 my proposal would solve those as far as I can tell. Jul 09 22:25:41 he was complaining earlier about using git clean -f and having his local.conf and all blown away, i tried to explain that he can put the build directory wherever he wants, but he didn't seem to grasp the concept Jul 09 22:25:45 heh Jul 09 22:25:56 adding rm_work to the build steps is the current solution, and the places in which you would need to add that are too tiresome and changing. Jul 09 22:26:09 b46258: current sucky solution, yes. Jul 09 22:26:13 yes, I never use the build directory in the same location as my git tree (poky, oe-core/bitbake or anything else).. build is always outside Jul 09 22:26:21 b46258: I need more than a sucky situation. Jul 09 22:26:27 as I explained at least 10 times now. Jul 09 22:26:32 and that gives me the ability to put my build tree into a repository if it's a build I need to reproduce in the future Jul 09 22:26:43 that is why I proposed a way for which I have not heard a rebruttal yet. Jul 09 22:26:43 but the *problem* is related to disk space, and your proposed solution is "~/.yoctorc" Jul 09 22:27:17 no Jul 09 22:27:23 the problem is explicitly not related to disk space Jul 09 22:27:30 one of the objections of the community is that sourcing in a ~/.yoctorc would cause a build to not be reproducable with different user environments.. Jul 09 22:27:31 maybe he doesn't realize that the setup scripts create the build directory default to your current directory, not relative to oe-core/poky? Jul 09 22:27:34 * kergoth shrugs Jul 09 22:27:36 since by definition ~/.yoctorc is user specific Jul 09 22:27:36 the problem is related to local global configuration. Jul 09 22:27:46 disk space is just one of those ... Jul 09 22:27:56 again, many projects managed it nicely... I am sure yocto can too. Jul 09 22:28:04 it is not a big deal, and fairly trivial concept IMHO. Jul 09 22:28:05 when creating a project you expect to reproduce, you would also need to backup not only the local.conf, but the 'global configuration' as well.. Jul 09 22:28:19 you say it's just one, and yet... what else do you want to put in there? :-) Jul 09 22:28:21 and it is not "unix/linux" way as someone raised earlier... that just did not make sense to me. Jul 09 22:28:30 It's really easy to forget you left that laying around. we defaulted to pulling in ~/.oe/ for mel and some users had weird things happening different from what the customers hit because they forgot they had a site.lconf lnaying around there :) Jul 09 22:29:11 kergoth, thats why we don't use that solution.. everything needed to reproduce a build is local to the build (project) directory.. Jul 09 22:29:15 * kergoth nods Jul 09 22:29:23 you can safely wipe the 'tmp', but everything else should be stored in your SCM Jul 09 22:29:36 b46258: see the faq for further ones. Jul 09 22:29:51 do not get stuck on one particular configuration when we are discussing a configuration architecture. Jul 09 22:30:17 The only things I could see bieng safe to set in such a file would be things like parallel make and the # of threads, but even that is really bound to the machine, not the user / home directory, so use of an nfs homedir across different hosts would cause problems Jul 09 22:30:35 * kergoth wanders off Jul 09 22:31:00 fray: you are not making any sense Jul 09 22:31:09 I already mentiond /etc and ~ several times. Jul 09 22:31:24 of course, both make sense with different scenarios. Jul 09 22:31:36 just one of those, different users can decide about different rm_work policies Jul 09 22:31:40 lpapp: I think you are confused. I am well aware that you are talking about configuration architecture. On the other hand, I don't think that's a particularly good way to solve the problem that led you to identify the lack of ~/.yoctorc as a problem. Jul 09 22:31:45 if you set variables outside of your build directory.. you have to store those in order to reproduce the build in the future.. Jul 09 22:31:54 this has nothing to do with rm_work, or the parallel build configurations.. Jul 09 22:32:09 it has exactly everything to do with configs. Jul 09 22:32:11 those three just happen to be ones that are believed to be safe to change Jul 09 22:32:13 what the user prefer. Jul 09 22:32:25 do you think git accidentally has config files? Jul 09 22:32:30 global, local, et cetera? Jul 09 22:32:34 just for joke? Jul 09 22:32:42 You aren't understanding me Jul 09 22:32:47 mkdir my-project Jul 09 22:32:49 cd my-project Jul 09 22:32:49 correct, I am totally lost. Jul 09 22:32:51 git init Jul 09 22:33:00 ~/git/poky/oe-init-env build Jul 09 22:33:01 git add build Jul 09 22:33:08 git commit -s -m "initial commit" Jul 09 22:33:12 make changes from there forward.. Jul 09 22:33:34 you can add to your .gitignore the build/tmp (and other directories) as needed Jul 09 22:33:44 b46258: you are entitled to forget many open source projects solving this very problem the way I propose. Jul 09 22:33:48 you can then come back in two years.. and downloads the same poky version.. and reproduce the system Jul 09 22:34:22 once you run oe-init-build-env your project is now configured and set Jul 09 22:34:30 fray: I already wrote several times build and source folders are not persistent Jul 09 22:34:34 home and etc area are. Jul 09 22:34:37 I haven't forgotten them, I'm just thinking about the user. Jul 09 22:34:39 for configuration. Jul 09 22:34:51 at that point you make changes to your configuration, but any change has the chance of triggering full rebuilds if the change is determined to affect the distribution configuration Jul 09 22:34:54 b46258: I think, you do not, and that is the root cause of my issue. Jul 09 22:35:21 lpapp, I disagree completely.. home and etc is not persistent.. but SCM controlled build folders are Jul 09 22:35:22 * lpapp is stepping aside Jul 09 22:38:58 lpapp: would you agree that running out of disk space like this is a problem? Jul 09 22:40:14 as I wrote several times, no. Jul 09 22:40:45 and actually, it is so totally annoying to spend this much time with fundamentally broken config stuff that I might just extend the config parser whatever language it is written in. Jul 09 22:41:17 and if nothing else, I can apply this patch on vanilla yocto. ;) Jul 09 22:41:54 there is nothing to 'extend' in the parser.. Jul 09 22:42:24 to read your magic ~/yocto.rc, go in and modify the base system configuration to load it Jul 09 22:42:53 edit meta/conf/bitbake.conf Jul 09 22:42:55 add at the top Jul 09 22:43:00 include ~/.yoctorc Jul 09 22:43:08 save that as your local patch and it'll likely work.. Jul 09 22:43:19 (I don't know off hand if '~' is resolved.. if not, that's easy to fix as well) Jul 09 22:44:09 sorry, but you are wrong. Jul 09 22:44:17 I will not edit anything at all Jul 09 22:44:22 nor will I require that from the end user. Jul 09 22:44:27 you just said you are going to edit the parser! Jul 09 22:44:37 A change to the 'parser' won't be accepted upstream.. Jul 09 22:44:45 a change to bitbake.conf or a similar existing file may be Jul 09 22:44:55 after my patch, the software should implicitly handle dedicated semi-global, and global files. Jul 09 22:45:27 that's what I just told you how to do Jul 09 22:45:56 bitbake -- the engine loads the local.conf, bblayers.conf and bitbake.conf file.. everything else happens based on those three Jul 09 22:46:05 which is what I call extending the parser, as in allow the parser to parse other files... Jul 09 22:46:18 so you need to add your 'global' inclusion into one of those three, only bitbake.conf isn't dynamically generated by the oe-init-build-env Jul 09 22:46:20 there is everything to extend around the parser. :) Jul 09 22:47:37 initially, it could be optional, and let us see what feedback it would be getting later ... Jul 09 22:47:53 go for it.. I can tell you right now it won't be accepted as a change to bitbake by the community. Jul 09 22:48:11 luckily it does not matter ... ;-) Jul 09 22:48:15 I gave you a way to have a constructive conversation within the community, and modify a file that is reasonable Jul 09 22:48:18 actually it does matter Jul 09 22:48:50 If you change something that the community won't accept, you are forking the project.. and at that point you are on your own Jul 09 22:49:08 if you are willing to maintain your own fork, great go for it..... Jul 09 22:49:17 hmm, you have apparently never heard about dpatch, quilt, et cetera .... Jul 09 22:49:23 but if you want the advantage of the open source community you need to work with them Jul 09 22:49:40 oh, your opinion is THE open source community? Jul 09 22:49:51 and other open people's opinion cannot be open source community to work with? Jul 09 22:49:55 I'm talking -any- open source community Jul 09 22:50:04 if you fork, you are on your own for maintenance.. Jul 09 22:50:06 one patch is easy.. Jul 09 22:50:11 100 patches is difficult Jul 09 22:50:15 1000 patches is impossible Jul 09 22:50:42 * lpapp is pointint to quilt and dpatch for reading for those who do not understand and talk about forks. Jul 09 22:50:49 pointing* Jul 09 22:51:14 (btw using quilt and dpatch for forking more then a couple of patches isn't worth the pain.. use git and your own branch) Jul 09 22:51:20 besides, this is not the first scenario when irc guys were too harsh Jul 09 22:51:35 but when I brought the subject to the mailing list (i.e. more official form), people were on my side. Jul 09 22:51:53 that is just how unfortunately irc works... rude and harsh people for constructive feedback at times. Jul 09 22:52:08 do not think you can discourage me to bring it up there, and maybe even got accepted ... ;-) Jul 09 22:52:19 I'm going to be blunt.. the feedback was constructive for the first few messages.. then you ignored us.. and have been arguing ever since Jul 09 22:52:53 there is a huge difference between ignoring (what you did when you did not wanna read my posts), and disagreeing. Jul 09 22:52:58 At this point, I'm happy to encourage others to bring their feedback to us.. we've made a large number of improvements over feedback.. but not everything sent back to the community is going to be implemented for a variety of reasons Jul 09 22:53:17 I of course read all the posts, and title them as "makes no sense" to me. Jul 09 22:53:22 I see no "posts", only IRC messages Jul 09 22:53:23 that is not quite called ignoring .... Jul 09 22:53:45 I've certainly encountered some pretty hostile IRC channels, but I've been pretty happy with #yocto. People are pretty patient with my occasional fussy days or silly questions. Jul 09 22:53:49 IRC is no different then a long running hallway conversation.. occasionally you need to summarize for people who weren't in the hallways when you staretd Jul 09 22:54:17 fray: it is very different .... Jul 09 22:54:19 you have the log to prepare ...... Jul 09 22:54:33 that makes a huuuuuge difference ... Jul 09 22:54:50 you cannot bring the time back in the hallway .... Jul 09 22:54:55 what log? I don't log IRC... I just have a couple of screen scroll back Jul 09 22:55:05 he beginning of this is long gone Jul 09 22:55:23 when you did not wanna read the message, it was only a few lines above you.... Jul 09 22:55:29 I can post the log if you do not believe me .... Jul 09 22:55:37 I told you I scrolled back and saw something about vim and couldn't figure out what you wanted.. Jul 09 22:55:42 I asked you to summarize.. easy.. Jul 09 22:56:17 also, you should probably consider logging stuff as that makes the world a lot better to place to live at .... Jul 09 22:56:24 this practical example proves that, too ...... Jul 09 22:56:35 to live in* Jul 09 22:56:44 sorry, I'm not going to log IRC.. I have absolutely no reason to.. you are free to log whatever you want Jul 09 22:57:03 then you have no rights to ask for summarization if you do not care to help yourself .... Jul 09 22:57:06 (If I'd been logging IRC, I'd have gigabytes of useless logs by this point.. it's simply not worth it) Jul 09 22:58:17 lpapp, never ever go for discussions on #beagle irc channel for any reason ;) We aren't truly the bad guys after all ;) Jul 09 22:59:10 fray: but your idea does not make sense to me anyway.... Jul 09 22:59:21 conf file is not meant to be doing controling logic .... Jul 09 22:59:26 yes it is Jul 09 22:59:34 like checking if a file exists, and include conditionally, et cetera .... Jul 09 22:59:41 in bitbake, the .conf files are used to load in everythign that is needed.. Jul 09 22:59:46 (for the global configuration space) Jul 09 22:59:50 yeah.. i am literaly amazed by how nice this channel is. i don't know any other place that would offer such a great patience in similar quite cumbersome circonstances... congrats #yocto ;-) Jul 09 23:00:13 ndec: clearly, you have never visited qt and kde channels. :) Jul 09 23:00:34 I tried to help the project, and I got "complaining, trolling" Jul 09 23:00:39 just two of those... Jul 09 23:00:49 look at the meta/bitbake.conf.. search for 'require conf/' and 'include conf/' Jul 09 23:00:54 I do not frequently get those in other channels .... Jul 09 23:01:06 you will see it is dynamically looking for a variety of configuration files and loading them if they exist.. Jul 09 23:01:12 require says it must exist, or it's an error.. Jul 09 23:01:19 include says load it if it exists, otherwise ignore it Jul 09 23:01:20 fray: looks like another architectural pitfall to me ... Jul 09 23:01:33 feel free to redo the architecture Jul 09 23:03:02 well, for me config is config for a reason ... because a simple designer or even artist could use it without any programming skills, including scripting stuff... Jul 09 23:03:41 if you put logic into it other than just configuration, it is called a script in my book .... Jul 09 23:04:23 yes, there is plenty of scripting possible in the bitbake .conf file format Jul 09 23:04:42 and BTW you don't even have to name your .conf files, ending in .conf.. that is just a convention.. you could call them all bob if you wanted Jul 09 23:05:30 yeah, so it makes so much sense to call a script file conf by default ...... Jul 09 23:05:43 * fray goes and renames everything to .script Jul 09 23:06:27 so it is worse than I thought.... Jul 09 23:06:32 * fray wonders if he should explain what the magic INHERIT variable does... and how the bbclasses can affect the global variable space Jul 09 23:06:42 it is not about a broken conf stuff, but there is actually no config interface.... Jul 09 23:06:45 only scripting..... Jul 09 23:07:57 perhaps I should stop the conversation to avoid the further bad surprises for today ... :-) Jul 09 23:10:52 also, your worry about reproducability is void by the fact that, you cannot guarantee everyone builds with the same core numbers anyhow... Jul 09 23:11:52 if you are truely concerned about reproducable builds.. you don't change your paralell numbers.. Jul 09 23:12:03 we just know from autobuilder results that it's safe to do so Jul 09 23:12:12 which is very unreal expectation to put it mildly ... Jul 09 23:12:52 also, I am not only not truly concerned, but it was you bringing that topic up ... Jul 09 23:15:26 fwiw, meta/conf/local.conf did not work ... Jul 09 23:16:20 I said to edit meta/conf/bitbake.conf Jul 09 23:19:00 I may be repeating part of what is said above but if you don't want to edit what comes from the poky git repository you should not be touching bitbake.conf... Jul 09 23:19:57 bluelightning ya, we're past that point.. Jul 09 23:20:04 ok Jul 09 23:20:09 he's convinced he has to edit the parser.. I'm trying to explain that won't be accepted Jul 09 23:20:36 I have skimmed over the scrollback Jul 09 23:20:45 lol Jul 09 23:21:05 there's no question, we have a steep learning curve Jul 09 23:21:42 but a lot of the way the system works is pretty well established and for pretty good reasons Jul 09 23:22:21 not so steep as all that... previous experience with classic helps, but the current docs are pretty damn good imho... Jul 09 23:22:56 diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf Jul 09 23:22:57 index 62a3936..a496f0d 100644 Jul 09 23:22:57 --- a/meta/conf/bitbake.conf Jul 09 23:22:57 +++ b/meta/conf/bitbake.conf Jul 09 23:22:57 @@ -1,3 +1,5 @@ Jul 09 23:22:57 +include ${@os.getenv("HOME")}/.oerc.conf Jul 09 23:22:57 + Jul 09 23:22:58 there that works Jul 09 23:23:02 ~/.oerc.conf Jul 09 23:23:12 * fray learned something new.. the file does need to end in .conf Jul 09 23:23:14 i still don't know sh*t, but that doesn't stop me from cranking out the rpi builds Jul 09 23:24:12 that said, i do try to "conform" to the bbappend guidance, etc Jul 09 23:24:13 mr_science: we've certainly tried to improve things, and will continue to do so Jul 09 23:24:49 mr_science: thanks, I'll pass on your comment about the docs to scottrif :) Jul 09 23:25:00 overall, yocto/poky docs are quite a bit better than the old stuff Jul 09 23:25:05 fray: you may, but someone else said osmething different. Jul 09 23:25:14 22:23 < mr_science> lpapp: i'd try poky/meta/con Jul 09 23:25:22 and we were discussing local.confs back then. Jul 09 23:25:38 what I posted before will work in -your- project's local.conf as well Jul 09 23:25:45 amazing what a difference it makes having actual technical writers. open source projects tend to de-emphasize the non-code work, to their detriment, really.. Jul 09 23:25:59 fray: I really do not need that complexity as an end user. Jul 09 23:26:01 so bitbake doesn't parse '~'.. so you need to use the HOME environment to get into your home directory Jul 09 23:26:12 yup Jul 09 23:26:17 fray: so, I will not actually do that. Jul 09 23:26:27 * mr_science uses $HOME in bblayers.conf Jul 09 23:26:28 because I think it makes no sense as an end user. Jul 09 23:26:29 so one line is more complex then you hacking on the parser.. ok.. go for it Jul 09 23:26:49 * kergoth chuckles Jul 09 23:26:59 fray: :( Jul 09 23:27:07 fray: you still have not bothered to read what I wrote. Jul 09 23:27:17 it is only you repeating the "parser code" Jul 09 23:27:18 fray: so, I will not actually do that. Jul 09 23:27:21 I clearly explained what I meant. Jul 09 23:27:22 because I think it makes no sense as an end user. Jul 09 23:27:25 yup, I read that Jul 09 23:27:26 lpapp: you're viewing this as an application; it's not really that, it's a complex build system Jul 09 23:27:47 bluelightning: it does not really matter whether it is an application or build system Jul 09 23:27:50 it does not matter a bit. Jul 09 23:28:04 I came in late and don't actually understand the goal. Is this just to have some kind of automatic inclusion of build settings that aren't in the build directory? If so, why? Jul 09 23:28:08 one thing matters for any kind of end user: how can I use the software with the least effort possible Jul 09 23:28:11 prior you said you were going to add another file to the parser (at a minimum).. the one line diff would prevent the change to the parser, and put it in the well known-global startup file for bitbake.. Jul 09 23:28:27 seebs, he wants a global configuration file Jul 09 23:28:28 seebs: read the log Jul 09 23:28:34 we will not repeat it for you. Jul 09 23:28:36 lpapp: the least effort possible is following the quick start guide, which tells you where to put everything Jul 09 23:28:52 fray: no no Jul 09 23:29:04 I have not ever mentioned "at least one more file". Jul 09 23:29:20 bluelightning: 1) except that I read and I had no clue Jul 09 23:29:33 2) Obviously, making a crap workflow and then documenting it is a silly idea in general Jul 09 23:29:34 Well, the thing is, lpapp. There's hundreds and hundreds of lines of discussion in the log. And I haven't got the motivation to re-read all of them to follow this. Simply put, I don't want anything right now, so I have low motivation to do things like page through hundreds of lines of discussion of something in order to find out even what's being discussed. Jul 09 23:30:01 me summarizes.. you don't want to confgiure local.conf, since you view it as transient (intermitent in your words).. so you want a dot file in your home directory to set key things, like the process count, rm_work... stuff that won't affect the end result of the build Jul 09 23:30:04 seebs: ok, fair enough, but the consequence is that you cannot follow Jul 09 23:30:07 it is your decision. Jul 09 23:30:27 that is a false summarization .... Jul 09 23:30:33 * fray offered 3 solutions, you said they were too complicated.. Jul 09 23:30:46 I can advice you 600 solutions. Jul 09 23:30:48 * fray read you wanted to change the parser, I said there is a simpler way.. and posted a patch.. Jul 09 23:30:49 lpapp: so, effectively telling people their project is crap is probably not the best way to get help Jul 09 23:30:55 Well, yeah. That was my point, I guess. Since I'm currently happy with the state of things, I'm not inclined to put effort into finding out what's going on. I am fine with "I can't follow this discussion", because nothing's ever happened to make me think I need to follow it. Jul 09 23:30:56 the point is not the quantity, but *quality* Jul 09 23:30:57 * fray avoids the intermediate discussion that went nowhere Jul 09 23:31:37 Which is indirectly intended as advice, I guess: If you want a change, you need to think about how to make other people also want this change. Otherwise, they will ignore it because they aren't interested. Jul 09 23:31:41 advise* Jul 09 23:31:54 When I have wanted changes to bitbake, I've usually started by trying to persuade other people that these changes would make *their* lives better. Jul 09 23:32:06 seebs: you are stating the obvious. Jul 09 23:32:10 Then people become interested in helping me make those changes happen, or making those changes happen without my involvement. Jul 09 23:32:11 and we went through all this. Jul 09 23:32:26 please do not play the smart guy, and that everyone else is silly Jul 09 23:32:30 and cannot realize the obvious. Jul 09 23:32:32 only you. Jul 09 23:32:34 You may think it's obvious, but people generally act as though they don't know it. I mean, heck. I do all the time. Jul 09 23:33:00 I have to consciously stop and think about how I am presenting my requests to people in order to present them effectively, otherwise I end up with things that no one is interested in, and nothing happens. Jul 09 23:33:12 I got an agreement with at least 5-10 people before discussing it in here in the first place, and that was all mentioned. Jul 09 23:33:21 yet, my feedback was called "complain", and "trolling". Jul 09 23:33:26 that frankly bugged me. Jul 09 23:33:28 and demotivated me. Jul 09 23:33:46 the original request was following by complaining that turned into trolling.. Jul 09 23:33:57 * lpapp is stopping it right now Jul 09 23:34:00 good luck guys Jul 09 23:34:03 the original request was valid and people responded with valid ways of doing what you wanted Jul 09 23:34:05 'k. Jul 09 23:35:44 I think I need to mention this to Jeff. Jul 09 23:35:51 he is responsible for community management. Jul 09 23:36:13 it is definitely not healthy to call users, and even the one putting effort into improving things "complaining" or "trolls". Jul 09 23:40:21 Hi, is there a reason why ppc e300c3 (MPC8315rdb) is tuned for soft float? Jul 09 23:40:34 * fray looks quickly.. Jul 09 23:41:14 I think most likely it's because you are a bad person and deserve only suffering. .. oh, wait. That's what causes pseudo failures. I think soft-float tunings are caused by the sins of your ancestors. Jul 09 23:41:46 or fsl's.. ;) Jul 09 23:41:54 * lpapp has just read back and no one said a thank you for the proposal regardless whether it is technically accepted or not. Jul 09 23:41:55 there are difference versions of the MPC8315rdb board.. Jul 09 23:42:10 * lpapp does not feel feedback welcoming here. Jul 09 23:42:14 many of them were the earlier e300c2 if I remember right Jul 09 23:43:24 lpapp: I'm sorry you feel you have had a negative experience here, but you must understand that it is how you have responded sometimes to people's advice that rubs people up the wrong way, and as human beings they respond in kind... the situation escalates and everyone ends up being frustrated Jul 09 23:43:41 fray's memory matches my vague recollection, the 8315rdb was a soft-float board at least sometimes. Jul 09 23:44:21 myopiate the other possibility is the e300c3 doesn't have a classic PPC floating point using but something unique.. or it could just be a bug in the tune-ppce300c3 file.. Jul 09 23:44:21 I think there are also some cases where a configuration is cloned from a similar-ish configuration, and no one notices that it's now set wrong. Jul 09 23:44:32 ya, that wouldn't surprise me in this case.. Jul 09 23:44:43 I think e300c3 should have standard floating point. *thinks* We had a bug report or query about this back in the WRL 3.x days or so, I think? Jul 09 23:45:07 I am rebuilding with hard float, wish me luck. Jul 09 23:45:10 looking at the latest oe-core, the e300c3 says it's soft-float.. Jul 09 23:45:18 e300c[1,2,3] manual says it has Jul 09 23:45:19 bluelightning: I am sorry for disagreeing with their workarounds. Jul 09 23:45:33 bluelightning: nothing anyone can change about technical disagreement. Jul 09 23:45:34 if you change the configuration to hard float.. and can verify that the floating point unit is used and it's not trapping.. it should get fixed.. Jul 09 23:45:54 myopiate the e300c2 definitely does NOT have hardware floating point.. the c1 might have Jul 09 23:45:55 bluelightning: but note how I did not call anyone with any bad name because I thought they technically do not make any sense to me. Jul 09 23:46:00 the e300mc also has floating point Jul 09 23:46:21 http://www.freescale.com/files/32bit/doc/ref_manual/e300coreRM.pdf Jul 09 23:46:45 page 1-3 says e300c2 is soft-float, while page 1-4 says the e300c3 is hard-float Jul 09 23:46:48 bluelightning: I do not even understand how pointing out an issue, and proposing something better can be "complaining" Jul 09 23:46:58 bluelightning: regardless whether it is the approved or declined way. Jul 09 23:47:11 bluelightning: I just simply do not understand how such a scenario can be evaluated as "complaining". Jul 09 23:47:50 bluelightning: not to even speak about calling this "trolling". Jul 09 23:47:52 "2) Obviously, making a crap workflow and then documenting it is a silly idea in general" <-- calling something "crap" is usually regarded as complaining, outside some specialized fields. Jul 09 23:47:56 lpapp: it's a little more nuanced than that... when you tell someone their design decisions are wrong (or even "crap") when they have spent considerable time working on them and proving them in the field, that is going to generate consternation Jul 09 23:48:03 fray, that manual says e300c3 does. (it also says c2 does not). Jul 09 23:48:12 fray, yes, recompiling things now. Jul 09 23:48:14 ya.. it's likely a bug then... Jul 09 23:48:23 I'll report my results. Jul 09 23:48:34 bluelightning: what should I say for things I think wrong... good, should I be a liar? Jul 09 23:48:45 bluelightning: or should I remain honest I was with my technical thoughts? Jul 09 23:48:46 if you can check the kernel though, make sure hte floating point emulation/trapping is disabled... if everything works (s[ecifically floating point).. then it was a bug in the current implementation Jul 09 23:48:56 lpapp: I can't tell whether that is a rhetorical question or an actual request for information. Jul 09 23:48:57 bluelightning: in any case, how is a technical disagreement "complaining"? Jul 09 23:49:06 bluelightning: especially when even a proposal was done? Jul 09 23:49:13 bluelightning: note, how I did not get any thank you. Jul 09 23:49:13 when you call something 'crap', it's no longer technical Jul 09 23:49:19 you have no gone into an emotional argument Jul 09 23:49:20 bluelightning: only "complaining" and "trolling". Jul 09 23:49:37 I don't really expect people to thank me, in general, unless I am doing them a personal favor. Jul 09 23:49:42 when you won't listen to proposed solutions (workaround, etc).. that borders on complaining.. Jul 09 23:50:09 lpapp: feel free to suggest changes, but when we explain why things are the way they are, you might care to put more stock in the explanations than you have been doing rather than ignoring them Jul 09 23:50:23 bluelightning: there was no any ignoring Jul 09 23:50:34 * lpapp is sad to see people here with bad faith Jul 09 23:50:48 it is probably Jeff's responsibility to fix it Jul 09 23:50:53 I will need to pass this role on to him. Jul 09 23:50:57 * fray doesn't work for Jeff Jul 09 23:51:05 it is a Yocto channel. Jul 09 23:51:12 (in fact I don't think any of the people here work for Jeff) Jul 09 23:51:14 So, again, was the "what should I say" thing a request for information, or a rhetorical device? Jul 09 23:51:19 if Jeff decides this channel does not represent the project mercifully, you can hardly say anything. Jul 09 23:51:27 *thinks* Jul 09 23:51:48 lpapp, I used 'trolling' and no doubt I was right Jul 09 23:51:52 if Jeff decides that anyone is not wanted in this channel, he is free to do as he needs for the sake of the project.. Jul 09 23:52:02 it wasn't an offense, re-read all pls Jul 09 23:52:03 but of course Jeff answers to the Yocto Project community and board.. Jul 09 23:52:05 lpapp, am I right to guess that English is not your first language? It occurs to me some of the communications problems here have to do with connotations of words, which are often hard for people to pick up. Jul 09 23:54:06 bluelightning: honestly, I have not had such hard times like here within this short while in any other irc channels lately in this amount. Jul 09 23:54:23 and not just me, I did not see feedback handled the way it was here today. Jul 09 23:55:32 bluelightning: and honestly, my reading about "feedback is welcome" in the documentation, and what I see here, is ... contradictory. Jul 09 23:55:56 but again, it is Jeff's responsibility to take up with this, and come up with proposals for solving this community issue. Jul 09 23:56:26 it's not the feedback you provided, but the manner in which you provided it Jul 09 23:56:59 21:26 < lpapp> I wonder why there is no ~/.yoctorc or concept. Jul 09 23:56:59 21:26 < lpapp> the current establishment seems 1) Weird with linux culture 2) Not intuitive at first glance. Jul 09 23:57:17 21:29 < lpapp> those are not exclusive .... Jul 09 23:57:20 21:30 < lpapp> I spent 30-60 minutes with it Jul 09 23:57:22 21:30 < lpapp> and I still have not got the faintest idea about where to put and what to avoid the GB hell. Jul 09 23:57:25 21:36 < lpapp> can someone please give me a file path where I can put an "rm work" config that will be valid for any kinda build? Jul 09 23:57:28 and walters responded to that Jul 09 23:57:28 21:37 < lpapp> IMO, this should be one of the very first FAQ questions. Jul 09 23:57:40 I don't know what "the GB hell" is. Jul 09 23:57:49 I honestly do not see any problem with "the manner in which you provided it" Jul 09 23:58:17 could you please point me that out? Jul 09 23:58:20 lpapp, I think the issue showed up more in the pages of conversation since then, where you said a lot of things that, at least to most people I know, would come across as hostile or confrontational. Jul 09 23:58:25 bluelightning: ^ Jul 09 23:58:43 seebs: sorry, I will ignore you now Jul 09 23:58:47 I noticed. Jul 09 23:59:03 Since I asked two or three times for answers to questions which would have allowed me to answer your questions. Jul 09 23:59:05 you were not here when we discussed it, yet you are trying to chim in about something you do not know. Jul 09 23:59:11 it is now not productive, sorry. Jul 09 23:59:14 lpapp: kergoth tried to tell you how he approached the same issue, you responded in all caps telling him you didn't want something he wasn't telling you to do Jul 09 23:59:16 Uh. Remember what you said about logs? Jul 09 23:59:19 I actually have all the logs. Jul 09 23:59:42 I have the entire history of the channel, and I've watched this conversation, and I've seen you ask questions about how what you said might be interpreted or why people would be offended. Jul 09 23:59:53 I also have the logs.. will they keep filling with this ? Jul 10 00:00:00 or now you are telling totally different than a few minutes ago? Jul 10 00:00:03 And guess what: My primary field of interest isn't programming. It's things like "why do people get offended by this". Jul 10 00:00:10 Or "how do I express this without people getting mad". Jul 10 00:00:11 and you have read it, yet you asked for summary/ Jul 10 00:00:12 ? Jul 10 00:00:22 well, sorry for putting it this way, but I am ignoring you now for a bit. Jul 10 00:00:29 Yeah. Jul 10 00:00:33 bluelightning: I told him several times I fully disagree. Jul 10 00:00:37 That's why people are accusing you of trolling, see. Jul 10 00:00:42 bluelightning: what is wrong about disagreeing? Jul 10 00:00:46 bluelightning: then he kept repeating Jul 10 00:00:57 bluelightning: the same stuff again, again, and again Jul 10 00:01:01 Because the moment someone shows up who actually has competent expertise to answer your specific questions about why people think you are complaining, you get mad and announce that you're ignoring them. Jul 10 00:01:06 bluelightning: I understood the first time as well, but I fully disagreed Jul 10 00:01:20 bluelightning: he did not stop iterating the same stuff, so I tried to emphasize. Jul 10 00:01:24 bluelightning: it is not any bad mannaer Jul 10 00:01:32 bluelightning: it is about making the point more clearly. Jul 10 00:01:41 You have repeatedly said and done things that would be *normally expected* to result in people being offended and insulted. Jul 10 00:01:41 it is not shouting, it is highlighting the point. Jul 10 00:01:57 bluelightning: with very bad faith, it is shouting yes. Jul 10 00:02:13 So, yeah. That is the sort of thing which gets categorized as trolling. And now I'll stop, and I apologize to the other channel folks for the traffic. Jul 10 00:02:39 lpapp: most often it's interpreted as shouting Jul 10 00:02:52 bluelightning: yes, for IRC newcomers with bad faith Jul 10 00:03:06 bluelightning: for an experienced IRC user with good faith, it is hardly an issue Jul 10 00:03:23 bluelightning: I get those all day along in other channels, and it is the right way of highlighting information to me, as well. Jul 10 00:03:24 lpapp: this is the internet, it's hard for people to convert textual communication into our interpretation of a discussion Jul 10 00:03:38 bluelightning: which is exactly why they SHOULD NOT have bad faith. Jul 10 00:04:11 I would even propose it as a channel guideline. Jul 10 00:04:17 lpapp: I can't speak for other channels, but in the ones I frequent, all caps is a rarity and usually because to my mind at least it equates to shouting Jul 10 00:04:17 does that make sense? Jul 10 00:04:38 anyway, we are debating fine points here Jul 10 00:04:58 I'm just trying to explain how people may have got annoyed and been less than polite as a result Jul 10 00:05:13 bluelightning: I understand they got annoyed by nuances. Jul 10 00:05:22 bluelightning: but that can only happen by bad faith which people should not have. Jul 10 00:05:38 bluelightning: hence my proposal is to make it as a channel guideline to have good faith in this channel. Jul 10 00:06:25 if people get annoyed by such nuances as capitals for highlighting the point, that is very bad. Jul 10 00:06:36 especially since anyone can come here with such a style for using capitals for good. Jul 10 00:06:40 lpapp: it's not *just* that Jul 10 00:06:45 without intending to be rude or harsh, whatsoever. Jul 10 00:07:07 it would be a very silly reason to become "unfriendly" and start throwing shit, like "trolling". Jul 10 00:07:56 I think only good channel guideline can defend this situation. Jul 10 00:08:39 in fact, just checked another channel, and sometimes even stars are used in combination with capitals to highlight important notes. :) Jul 10 00:08:54 I have actually known a number of people who mostly don't get mad or upset over "nuances" like typing in all caps and such. Jul 10 00:09:36 I think I know maybe six such people, and all of them are autistic. So I am thinking that a channel guideline equivalent to "you must be autistic to post here" might be unduly restrictive. Jul 10 00:10:40 bluelightning: so how about a channel guideline to have "good faith", and assume constructivity and do not go mad before capitals, etc? Jul 10 00:10:46 But the alternative is probably to accept that some people will take offense at some communications for reasons that are not entirely related to the intended communicative content of those communications. And adapt to this, possibly by trying to avoid things that consistently result in people being offended. Jul 10 00:11:28 because of capitals* Jul 10 00:11:48 lpapp: I was just giving you one example of how the situation escalated when it need not have Jul 10 00:11:56 lpapp: people don't have endless patience Jul 10 00:12:19 bluelightning: there is no need for any patience as a capital is simply not requiring patience. Jul 10 00:12:24 it is a void stuff for patience. Jul 10 00:13:06 ultimately people are humans, people will misinterpret, and they will get annoyed particularly if you criticise stuff that they work on, so you have to be careful how you do it Jul 10 00:13:09 in fact, it is necessary at times to highlight certain points of a conversation. Jul 10 00:13:55 they are not good maintainers for the project then if they get offended by constructive critics especially where even a valid proposal is brought up. Jul 10 00:14:19 I have lost at least one job for not knowing that. In retrospect, this is hilarious to me now. It was less funny then. Jul 10 00:14:28 backed by several people and projects, and in the end, I have been told here that it could actually even be accepted upstream. Jul 10 00:14:43 seebs, I thought you lost the same job multiple times... maybe not for this though Jul 10 00:14:58 of course the guy deciding he was going to "tell your boss you didn't know C" was amusing Jul 10 00:15:01 Ah, no, that was different. That was just layoffs and stuff. Jul 10 00:15:04 lpapp: so, based on a complete reading of the above, I'm not sure I'd characterise your feedback as entirely constructive Jul 10 00:15:35 But like 20 years ago, I had some kind of newbie QA job, and I got in ALL sorts of hot water and ultimately lost it because, unbeknownst to me, if a newbie QA contractor says the senior devs are producing crappy code, that goes over poorly. Jul 10 00:15:37 bluelightning: it is fully constructive. Jul 10 00:15:40 That said. Jul 10 00:15:48 bluelightning: I thoroughly explained a problem down to the details. Jul 10 00:16:09 bluelightning: and I proposed a solution discussed with several people based on tons of open source projects cross-platform. Jul 10 00:16:18 If I were writing a performance-critical thing, where failures and even *delays* could cost tens of thousands of dollars. And I were writing a case-insensitive string compare. I would not allocate copies of both strings, then smash case, then compare, then free the copies. Jul 10 00:16:47 But, and this is the important thing: Saying it was crap didn't get it fixed. Jul 10 00:17:00 If I had pursued that more tactfully, I might have been able to get it fixed AND continue collecting paychecks. Jul 10 00:17:01 bluelightning: and I was about to vote for an existing bugreport, or open a new one, and then bring up on the mailing list Jul 10 00:17:17 bugzilla.yoctoproject.org feel free to add you issue as a bug report Jul 10 00:17:17 bluelightning: one of the very ideal workflows if you ask me, really. Jul 10 00:17:25 this doesn't take voting or feedback.. just do it Jul 10 00:17:38 lpapp: so what I'd suggest is that at least in my timezone it's kind of late, and people's tempers probably aren't in the best shape... I for one need to get some sleep, so perhaps we can try to go back through the technical issues tomorrow Jul 10 00:18:11 Sleep good, BL! Jul 10 00:18:11 bluelightning: I already lost my motivation by called a troll, and complaining person. Jul 10 00:18:26 bluelightning: so you can guess my motivation to help Yocto in the future. Jul 10 00:18:41 by being* Jul 10 00:19:03 BTW, apropos of nothing: I've been working on pseudo's diagnostics in my spare time, there may be an update available soonish which has basically no impact on behavior except diagnostic messages. But that effect might be pretty nice. Jul 10 00:19:44 seebs: that sounds useful Jul 10 00:19:53 bluelightning: a few days ago I even offered my help with python 3. I would like to withdraw that after this incident. Jul 10 00:20:29 Phase 1 is done, PSEUDO_DEBUG now accepts lists of flags as well as numbers, so you can request things like "logging related to IPC" without picking up all the other stuff. Jul 10 00:21:09 And the computations of arguments for the call are inside the flag test, so expensive argument computations are skipped if the flag in question isn't set. Jul 10 00:21:28 Phase 2 is to add a lot more messages and improve the clarity of the diagnostics so they're more communicative. Jul 10 00:21:43 bluelightning: and not because of the technical disagreement, but by few people's reaction for a technical feedback. Jul 10 00:21:50 seebs, were there expensive computions outside of the debug before? Jul 10 00:21:56 Sort of. Jul 10 00:22:06 ahh any performance improvement is a good thing Jul 10 00:22:09 lpapp: well, that is entirely up to you... again, I'm sorry you feel like you've been mistreated Jul 10 00:22:43 In current pseudo outside me tree, if you define NDEBUG, you'll get no computations, but if it's there, then pseudo_debug(9999, "test", expensive_call()); will make expensive_call() regardless of the debug level. Jul 10 00:22:58 ahh Jul 10 00:23:28 In the new tree, pseudo_debug(DBGF_IPC, "test", expensive_call()) expands roughly to if (debug_flags & DBGF_IPC) { pseudo_diag("test", expensive_call()); } Jul 10 00:23:47 It's fancier than that, but not by a ton, and most of the extra fanciness is going to optimize away at compile time. Jul 10 00:23:57 bluelightning: see how many people jumped on me without even caring to read the history through. Jul 10 00:24:23 bluelightning: that generated a lot of additional noise (that is why I am not talking to everyone anymore, just you now) Jul 10 00:25:15 lpapp: based on my reading, I'm not sure they really needed to Jul 10 00:25:41 lpapp: anyway I really need to get some sleep, I will be back in here tomorrow (just as I am every day...) Jul 10 00:25:54 bluelightning: well, they asked for summarization and when they had been told to read the history, they refused... Jul 10 00:26:25 bluelightning: if they did not need, they should not ask for summarization. Jul 10 00:26:58 bluelightning: in fact, the first offensive "mood" was that when "complaining" was brought up. I think that made this very bad. Jul 10 00:27:26 bluelightning: and that is why I proposed the channel guide line modification so that it cannot happen yet again that people call others "complaining", just because they have a different vision. Jul 10 00:34:15 I'll just reiterate that when several different people explain why things are the way they are and you just say it should be like other applications without trying to understand what they're telling you, that is not really constructive Jul 10 00:34:25 anyway I am really going now Jul 10 00:36:18 reiterating does not make true though. :) Jul 10 00:36:20 it* Jul 10 00:36:51 as written many times, I did understand what that guy wrote, but I fully disagreed with doing it that way even if it is that is the best "way" with yocto/poky. Jul 10 00:37:36 I still do not understand "what mood you provided" is bad. Jul 10 00:37:45 so far, it is an unfounded statement. **** ENDING LOGGING AT Wed Jul 10 02:59:59 2013