**** BEGIN LOGGING AT Mon Dec 01 02:59:58 2014 Dec 01 07:51:55 kergoth`: congrats! Dec 01 08:09:21 morning all Dec 01 08:10:04 hi mago Dec 01 08:13:42 good morning Dec 01 08:29:20 kergoth` : Congrats! Dec 01 08:34:45 hi mckoan and ka6sox Dec 01 08:39:05 morning woglinde Dec 01 09:31:13 morning all Dec 01 09:38:52 hi bluelightning Dec 01 09:38:58 hi woglinde Dec 01 09:39:18 woglinde: you've sent Michael your public key right? Dec 01 09:46:27 bl yes I have Dec 01 09:48:37 woglinde: great... let me know when you have access and we can make the move official Dec 01 10:29:09 Hi all. Has anybody the chance to perform this quick test with openssh? http://lists.openembedded.org/pipermail/openembedded-core/2014-November/099342.html Dec 01 12:04:50 diego_r: That has not been my experience on most distros I used. Dec 01 12:05:12 diego_r: Stopping the service will prevent new connections, but it does not terminate existing ones. Dec 01 12:05:48 diego_r: Just as well, otherwise you'd be screwed when trying to administer a box remotely. Dec 01 13:00:39 bluelightning: hey! Dec 01 13:05:33 peteru: I see. Anyhow, on Yocto it doesn't close the connection even on shutdown. I'd consider at least this a good practice, but on Yocto ssh connection don't get closed properly on shutdown, your ssh client just hangs there. Dec 01 13:06:02 do you consider that "normal" too? Dec 01 13:19:10 Hi quys, one more question. If i have a copy of ARM7 sysroot on my pc HDD, is it possible to install there .ipk package using my host machine? Dec 01 13:19:39 sth like opkg Dec 01 13:20:08 spaszkoPL: was the sysroot created using a package manager like opkg? If not, you probably still can manually extract the files from an ipk to extend it Dec 01 13:20:35 Sysroot was created using Angstrom 2013.12 and bitbake. Dec 01 13:20:37 which BSP supports arm7? that's a micro controller Dec 01 13:22:09 My mistake :I was thinking about Cortex-A7 not ARM7 Dec 01 13:23:22 Ok so you suggest me to open .ipk by for example file roller and manually extract files? Dec 01 13:23:44 ARM alphabet soup :) Dec 01 13:24:41 Ok i will check this solution - seems working. Dec 01 13:24:45 thx :) Dec 01 13:46:51 Here is my solution:If you want to install .ipk to your sysroot, use "ar x yourfile.ipk && tar -zxf data.tar.gz -C path_to_sysroot". Dec 01 13:47:11 opkg -o /path/to/sysroot ? Dec 01 13:54:29 hi mago_ - FYI I did try your example layer and I can confirm that it fails (at "reappear") Dec 01 13:57:51 bluelightning: oh, okay. is that expected behaviour? Dec 01 13:58:03 mago_: I don't think it is, no Dec 01 13:58:22 mago_: well, actually... it might be, it just might not be desirable Dec 01 13:58:59 i think after re-running the test, it even failed at "fallback" (even though the test runs cleanall to setup test) Dec 01 13:59:14 I think the problem is the system does not re-scan the paths for new files, only deleted previously seen ones Dec 01 14:01:49 okay. I'm not even sure if this is a valid use-case, but that's the way we're doing things in our build right now -- a recipe, gets overridden by our "common company" layer, and then again overridden by a "product layer" Dec 01 14:02:46 thanks for testing the tree anyway, i guess my next step would be to pinpoint exactly where this scanning of paths occur in bitbake (or oe-core?) Dec 01 14:07:40 mago_: it's a function get_checksum_file_list() in bitbake/lib/bb/fetch/__init__.py which is effectively called from base.bbclass Dec 01 14:07:52 so it's split between them Dec 01 14:08:22 would you say a fix for this gets accepted into bitbake, or is it considered too weird of a use-case? Dec 01 14:11:30 it would depend on the impact (on performance and behaviour) Dec 01 14:11:38 I think it's a legitimate use case FWIW Dec 01 14:20:09 Ok. One more question. Is it possible to compile mesa recipe with usage of software gallium-llvm? Dec 01 14:20:51 in mesa.inc are some config options, but i don't understand how to set my image recipe to use this options. Dec 01 14:22:04 For example in mesa.inc is PACKAGECONFIG[gallium-llvm], but how to enable it in my recipe? Dec 01 14:23:35 PACKAGECONFIG_append_pn-mesa = " gallium-llvm" in your distro.conf or local.conf Dec 01 14:28:10 JaMa: hi Dec 01 14:31:38 JaMa: thx a lot :) Dec 01 14:31:43 someone is aware about performances issues of QT5.3 on wayland backend ? Dec 01 14:32:04 i built an image based on dizzy + meta-qt5 + wayland and weston Dec 01 14:32:22 but i get less than 1fps with QTCinematic Experience Dec 01 14:32:41 with the hich cpu load for this app Dec 01 14:34:18 captainigloo: By the way, because i don't have a lot of experience with meta-qt5. I crosscompiled QT manually, so i have a question. It's possible to use build meta-qt5 with qtquick with software opengl? Dec 01 14:34:30 spaszkoPL: yes Dec 01 14:34:41 with gallium-llvm Dec 01 14:34:45 i did that before Dec 01 14:35:24 so you can configure it in your recipe and then run bitbake and it's working, yeah? Dec 01 14:35:29 yes Dec 01 14:35:46 as JaMa said, by adding PACKAGECONFIG_append_pn-mesa Dec 01 14:35:52 Have you example config or sth? Dec 01 14:35:58 yes let me check Dec 01 14:36:15 Ok, and for Qt you have to also set the egl driver? Dec 01 14:36:47 It's very interesing for me. If it will work it will save a lot of my job. :) Dec 01 14:39:33 hum i put gles flavor for PACKAGECONFIG_GL Dec 01 14:43:03 spaszkoPL: http://pastebin.com/WAB9rW2Y Dec 01 14:43:14 it's my mesa_%.bbappend Dec 01 14:43:30 with that is let mesa build with gallium llvm driver Dec 01 14:43:38 it lets* Dec 01 14:44:00 it's for qemux86 or qemuarm Dec 01 14:44:32 change the _qemux86 with your machine name, or juste overide PACKAGECONFIG for all machines Dec 01 14:47:55 ok thx Dec 01 14:48:00 i will check this :) Dec 01 14:48:34 spaszkoPL: ah and you also need to bbappend qtbase_%.bbappend Dec 01 14:48:48 and add PACKAGECONFIG_GL = "gles2" Dec 01 14:48:55 captainigloo: changing it only for some MACHINEs will make mesa and all recipes which depend on it (or one of virtual/*gl*) MACHINE_ARCH Dec 01 14:49:36 and you don't need to have .bbappends you can append PACKAGECONFIGs from distro.conf or local.conf Dec 01 14:49:44 JaMa: hum i don't undersand Dec 01 14:50:05 captainigloo: _ overrides are bad for TUNE_PKGARCH recipes Dec 01 14:50:29 oh ok i see Dec 01 14:51:08 but if i don't do that, i get errors with meta-fsl-arm Dec 01 14:51:43 https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-graphics/mesa/mesa_%25.bbappend Dec 01 14:51:53 PACKAGECONFIG_remove_mx6 = "egl gles" Dec 01 14:52:30 so gles is removed, and so mesa can't configure correctly because gles is not found Dec 01 14:52:33 ah, they are already messing with it Dec 01 14:52:39 :) Dec 01 14:53:09 :-) Dec 01 14:53:10 also in ./qt5-layer/recipes-qt/qt5/qtbase_%.bbappend Dec 01 14:57:43 diego_r: Yes, that's normal too. If you want your ssh sessions to disconnect when one end goes away, you'll need to set your ssh alive timeouts. man both sshd_config and ssh_config and look for the string "alive" in both man pages. Dec 01 15:01:38 peteru: I see. That's strange to me anyhow. I get kicked out regularly on shutdown from Fedora, Ubuntu and Debian ssh hosts, so I thought it was a sort of a standard / best practice. Dec 01 15:06:04 In my experience, the optimal values for these settings are very much dependent on what pieces of networking equipment are between you and the other end. For example, NAT routers that have a short session timeout benefit from having the keep alives being set every 60 or so seconds, but have a reasonably large retry count. Dec 01 15:07:00 That way your conntrack sessions don't expire, but transient network issues don't sever your connection prematurely. Dec 01 15:08:42 On the other hand, if you want to have an ssh session to a machine that you can put to sleep, you probably don't want any keep alives so that you can just resume your sessions. Dec 01 15:14:45 peteru: I'm not talking about connections timeouts, but just the server gracefully closing connections to clients when he either gets stopped or shutdown. Dec 01 15:16:08 it looks like distributions take this as a bug : https://bugzilla.redhat.com/show_bug.cgi?id=626477 https://bugs.gentoo.org/show_bug.cgi?id=259183 https://bugs.archlinux.org/task/31250 Dec 01 15:23:51 diego_r: if we can fix this whilst preserving existing connections when stopping/restarting the service and _not_ shutting down / restarting the machine, then it would be good to do so IMO Dec 01 15:25:57 bluelightning: so you mean: keep connections when sshd service is stopped, but close them on shutdown? Dec 01 15:26:15 diego_r: yes Dec 01 15:26:41 I think spanky has it right in the gentoo bug tracker comment #9. Dec 01 15:26:52 diego_r: it would be worthwhile observing how other distros handle this Dec 01 15:36:18 For a system that reboots quickly, you'll get an ICMP UNREACHABLE as soon as TCP/IP stack is up and you try to communicate. If reboots are slow, the machine is gone or ICMP is firewalled, your keep alive timeouts will come into play. Dec 01 15:37:39 A wall message to let you know what happened should be sufficient. You can always type enter~. to get back to your local shell. CTRL+C may also work. Dec 01 15:40:12 If you start terminating openssh connections, are you going to do the same thing with dropbear, telnet, rsh, busybox? Dec 01 15:41:31 I certainly wouldn't be very impressed if the network scripts killed busybox when I issue init S from ttyS0. Dec 01 15:45:03 I really thought closing active connections when server is stopping was considered normal behaviour, but it looks like I was wrong, and that makes the whole thing more complicated to handle. Dec 01 15:46:40 peteru: bluelightning: anyway thank you for the comments on the matter. Dec 01 15:57:26 No worries. I'm not saying it's not possible to do, but as with many seemingly simple things that no one has fixed, the devil is in the details. When you start considering some of the corner cases, you might decide that the status quo is just fine. ;-) Dec 01 17:36:19 JaMa: about meta-qt5 and your jansa/master branch, https://github.com/meta-qt5/meta-qt5/blob/jansa/master/conf/distro/include/qt5-versions.inc Dec 01 17:36:27 it should be 5.3.99+5.4.0-rc1+git% Dec 01 17:36:32 isn't it ? Dec 01 17:38:49 captainigloo: right, will fix, thanks Dec 01 17:39:32 i'm building it right now, to see if it's better with wayland QPA Dec 01 18:26:37 I got a fetch failed for http://www.nazgul.ch/dev/nostromo-1.9.5.tar.gz and MIRRORS failed too. I'm wondering if my MIRRORS is set incorrectly? I'm looking for the file in http://sources.openembedded.org/nostromo-1.9.5.tar.gz (404 error) and http://mirrors.openembedded.org/nostromo-1.9.5.tar.gz (host unreachable). So I don't know what's wrong. Are these files not cached there? Or am I using the wrong path? Or is my MIRRORS va Dec 01 18:26:38 riable set improperly? Dec 01 18:30:37 awozniak: it may be that we don't mirror that file; the OE source mirrror doesn't mirror files automatically Dec 01 18:31:24 what's the commonly accepted way to add to mirrors? MIRRORS += in conf/local/conf ? Dec 01 18:31:36 urm, i mean conf/local.conf Dec 01 18:35:51 awozniak: local.conf is fine but you must use the correct syntax for the value Dec 01 18:36:16 awozniak: you might consider asking ka6sox (Tom King) to add the file to the OE source mirror as well Dec 01 18:36:26 bluelightning_: understood Dec 01 18:54:18 awozniak, do you have a reliable source for that file? Dec 01 18:54:23 one with a good checksum? Dec 01 18:54:29 I do not Dec 01 18:55:03 I'm also looking for http://0pointer.de/lennart/projects/nss-mdns/nss-mdns-0.10.tar.gz ; it seems the /lennart/ directory there no longer exists Dec 01 18:56:15 if you have corrected sources send a patch to the ML…if we need to mirror it (and you have a good file/checksum) I'll see it gets into the sourcemirror. Dec 01 19:20:46 ka6sox bluelightning_: I was able to get nss-mdns-0.10.tar.gz and nostromo-1.9.5.tar.gz from http://distcache.FreeBSD.org/ports-distfiles Dec 01 20:38:50 Can anyone help me understand what it means to create a distro-less image? What would it buy me or why would one go the route? Dec 01 20:47:36 mschuckmann: it just means with default configuration **** BEGIN LOGGING AT Mon Dec 01 21:20:39 2014 **** ENDING LOGGING AT Tue Dec 02 02:59:58 2014