**** BEGIN LOGGING AT Mon Apr 15 02:59:57 2013 Apr 15 08:08:40 morning all Apr 15 08:11:50 good morning bluelightning Apr 15 08:12:56 hi mattnie Apr 15 08:53:32 I need swig for building a custom package: is there a yocto layer containing the recipe? I've found in meta-oe but I'm not sure which is the proper way to include it (apart from extracting the single recipe from meta-oe) Apr 15 08:58:24 david-e_: typically one would just add the meta-oe subdirectory of the meta-openembedded repo to bblayers.conf Apr 15 08:58:56 bluelightning: fine, thanx Apr 15 11:36:09 hi. i enabled PAM via DISTRO_FEATURES_append and it works for most services like SSH etc., but not for login. the wiki page on PAM_Integration says tinylogin is used per default, but within the tinylogin recipe and src there does not seem to be an option for PAM and it does not link again libpam as well. so how can this be enabled and/or how can i disable tinylogin and use busysbox login with PAM support instead? Apr 15 11:40:55 schramae: those are good questions. tinylogin is rather stale at this point and we plan to change it in 1.5 to use busybox. We've put off this for a while as we didn't want a suid busybox binary Apr 15 11:41:22 schramae: If you're willing to accept a suid version, you should be able to switch it out for the busybox version easily enough Apr 15 11:43:44 RP: would be ok for now, as i need a quick solution to reliably set ulimits. how can i switch it? i enabled login + PAM in busybox cfg, but tinylogin still gets installed. grep shows up VIRTUAL-RUNTIME_login_manager ?= "tinylogin", but i'm not sure if this is used by core-image-minimal. Apr 15 11:44:22 schramae: change that for busybox Apr 15 11:44:59 RP: i'll try, thanks. and take a nap during rebuild... ;) Apr 15 12:24:29 RP: worked, thanks! this should def. be mentioned in https://wiki.yoctoproject.org/wiki/PAM_Integration - my problem with yocto 1.3 was that, though /etc/limits existed and i changed it to my needs, the rtprio ulimit was only set correctly after doing a "su username" again and the ulimits for memlock and niceness where not set at all. i tried to debug it, but stopped after an hour, as checking the bash sources did not help and tools as strace etc. failed Apr 15 12:24:29 (i use original bash instead of busybox) Apr 15 13:17:24 schramae: Its a wiki so please add information to it! :) Apr 15 13:42:52 RP: i don't have a login and the page says that new accounts are only created after approval. but i'm leaving the company tomorrow and the mail adress will became void, so... Apr 15 13:43:28 schramae: if you request an account I can approve ASAP Apr 15 13:47:55 RP: done Apr 15 13:49:06 schramae: approved :) Apr 15 13:49:40 RP: thx :) Apr 15 15:07:16 JaMa: please let me know if the INC_PR patch for connman is ok; tahnks Apr 15 15:07:28 JaMa: thanks Apr 15 15:10:42 cristianiorga: looks good Apr 15 15:11:55 JaMa: thanks Apr 15 15:48:09 cristianiorga: connman 1.13 is out 6 days ago, even though the website still says 1.12, is there any chance of getting it in for 1.4? It has a DHCP Provisioning patch I need. Apr 15 15:48:41 otherwise I can backport it for the meantime Apr 15 15:48:50 jackmitchell: no. Apr 15 15:48:54 jackmitchell: freeze was yesterday, and connman is famed for breaking :) Apr 15 15:49:11 rburton: I thought as such, I've noticed it being a pain ;) Apr 15 15:49:46 local patch and .bbappend it is! Apr 15 15:50:54 jackmitchell: feel free to send a patch when you can say that it works, nothing like starting 1.5 with network breakage! :) Apr 15 16:32:53 fray, What's up? Apr 15 16:33:23 halstead I'm working on a download script (for WR) to make sure I have mirrored locally all of the downloads, and git repositories reference by oe-core and meta-yocto.. Apr 15 16:33:34 however, one thing I've been seeing since Friday.. Apr 15 16:33:45 linux-yocto-* repositories are taking forever to download.. Apr 15 16:33:58 The clone process is requiring multiple hours of connection and I'm only getting 100 KB/s max.. Apr 15 16:34:18 Are there any mirrors anywhere for these? or do we have a problem on the git.yoctoproject.org site.. or? Apr 15 16:34:46 fray, Are you cloning using http:// or git:// Apr 15 16:34:49 (those are the only git repos that I'm having horrible download times on.. so I suspect it's a size) Apr 15 16:34:50 git Apr 15 16:34:58 least I assume it's git.. Apr 15 16:35:02 since it's oe-core doing the fetch Apr 15 16:35:16 * fray goes to check Apr 15 16:35:40 url = git://git.yoctoproject.org/linux-yocto-3.2.git Apr 15 16:42:13 fray, Our bandwidth usage is pretty high right now. That may contribute. I only see 1 timeout of the git-daemon. Apr 15 16:43:17 fray, You could try http:// and see if Apache does a better job than git-daemon. Apr 15 16:43:49 fray, http://git.yoctoproject.org/git/linux-yocto-3.2 Apr 15 16:47:25 Ya, no timeouts.. just slow Apr 15 16:48:31 http, I'm getting 900 KiB/s Apr 15 16:48:41 ohh and now it's dropping down to 475.. still a lot faster Apr 15 16:48:56 is the git server being flooded? Apr 15 16:49:03 just spiked back up to 1 MiB/s Apr 15 16:49:09 (thats my line speed here) Apr 15 16:50:04 fray, No. The server is basically idle but the connection it shares is being used heavily right now. Apr 15 16:50:51 Hmm.. I switched to git, from http.. and now I'm getting an error.. huh Apr 15 16:51:18 [mhatle@msp-mhatle-lx2 test]$ git clone git://git.yoctoproject.org/linux-yocto-3.2.git Apr 15 16:51:19 Cloning into 'linux-yocto-3.2'... Apr 15 16:51:19 fatal: Could not read from remote repository. Apr 15 16:51:23 any idea what I'm doing wrong? Apr 15 16:51:27 fray, I can check with the other admins who share our connection. Apr 15 16:51:29 was just going ot try to compare speeds Apr 15 16:53:41 ya, this worked on Friday and suddenly isn;'t Apr 15 16:53:42 git clone git://git.yoctoproject.org/linux-yocto-3.8.git Apr 15 16:53:52 fray, I think I just caused that. Fixing it. Apr 15 16:53:57 ok :) Apr 15 17:04:12 fray, Clones are working again. Apr 15 17:04:23 ahh yes Apr 15 17:04:36 just starting one now.. we'll see if the speed is comparable to http Apr 15 17:05:38 it's not a perfect comparison by any means.. but the git downlod seems to have a lot more variation in it then the http did.. Apr 15 17:05:58 I've so far gotten between 350 and 800 KiB/s.. the http was varying between 500 and 1 MiB Apr 15 17:06:21 git just dropped to 158 KiB Apr 15 17:06:39 guys, thanks very much again for all the support. bye. Apr 15 17:06:42 I wonder if there is some kind of processing bottleneck going on when the git server due to the number of users.. (in comparison to the http server) Apr 15 17:09:16 just started an http download.. and it's dropped to 250 KiB a few times.. so it might just be overall load Apr 15 17:12:33 fray, Still looking into bandwidth contention. Apr 15 17:12:57 dunno.. this might be entirely normally.. but with the larger linux-yocto repositories, it can take -hours- to download.. Apr 15 18:18:43 Hey I have BB_NO_NETWORK set to 1 but I would like to disable it for all recipes from 1 layer Apr 15 18:18:52 any smart way of doing it ? Apr 15 18:19:02 one way is to disable it in each recipe Apr 15 18:19:11 but thats kind of cumbersome and not so cool Apr 15 18:23:10 fray, The low speed is caused by lots of people downloading 1.3.1 and others mirroring 1.4-M5. Apr 15 18:23:17 ok Apr 15 18:23:38 as long as it's 'expected' I'm fine.... Apr 15 18:23:54 fray, Not much we can do except to wait until everyone has a copy. Apr 15 18:23:57 khem: I don't think there's an easy way to do that Apr 15 18:24:13 if something was possible in layer.conf Apr 15 18:24:15 would be ideal Apr 15 18:24:28 khem: layer.conf will apply things at the global level Apr 15 18:24:35 I know Apr 15 18:25:10 khem: the only alternative I can think of would be an inc file that does BB_NO_NETWORK_pn-blah for each recipe in the layer Apr 15 18:25:35 bluelightning: actually, I will just have different coding practices Apr 15 18:25:43 for internal and external layers Apr 15 18:26:27 bluelightning: btw. I sent a revised sntp/systemd patch addressing your comments Apr 15 18:26:38 khem: yep saw that, looks reasonable Apr 15 18:26:42 k Apr 15 18:26:46 send an ack then Apr 15 18:26:52 will do Apr 15 18:27:00 so JaMa can be comfortable :) Apr 15 18:27:18 thx Apr 15 18:27:31 khem: seen my reply on it? Apr 15 18:27:55 JaMa: I am sitting in same parc 55 hotel that we went for ELC :) Apr 15 18:28:16 khem: actually yes I'll ack it in v3 after JaMa's comment has been addressed :) Apr 15 18:28:27 khem: isn't there another conference now? Apr 15 18:29:20 collaboration summit 2013? Apr 15 18:32:06 JaMa: bluelightning yes I will send v3 later Apr 15 18:32:14 JaMa: yes collab summit Apr 15 18:46:43 mooing Apr 15 21:33:42 halstead: Did we run out of space on one of the ABs? Apr 15 21:36:24 RP, Which one? No alerts. Apr 15 21:37:37 RP, The nas just filled. Apr 15 21:37:44 halstead: it was spread all over. I wonder if this is a malfunction in the diskspace checking code in bitbake :/ Apr 15 21:37:49 halstead: ah Apr 15 21:37:50 RP, I'll clear some. Apr 15 21:37:56 halstead: thanks Apr 15 21:38:21 RP, The alerts for the nas were disabled because of the super high load. Apr 15 21:39:10 halstead: ok, as long as it wasn't the disk space checking fix I merged earlier today ;-) Apr 15 21:47:52 RP, I have checked in with pidge and we are resuming our regular disk clearing strategy. Apr 15 21:47:52 RP, We will have plenty of room in about 10 minutes. Apr 15 21:48:07 halstead: ok, thanks :) Apr 15 21:48:45 halstead: let me know when we can fire another build... Apr 15 21:49:29 RP, I'll let you know when it's clear. There should be enough room to start now but it might run slowly for a bit. Apr 15 21:50:22 RP, Shall I respond to all the build failure e-mail? Apr 15 22:01:00 halstead: good idea, tell people we know why it happened Apr 15 22:16:34 halstead: I'm just going to start it if that is ok? Apr 15 22:17:22 halstead: acutally, looks like we may need to restart the buildmaster :/ Apr 15 22:22:53 RP, I can do that. Apr 15 22:23:29 halstead: thanks **** ENDING LOGGING AT Tue Apr 16 02:59:58 2013