**** BEGIN LOGGING AT Fri May 15 02:59:58 2015 May 15 07:55:59 denix: hmm, it seems that the date is always regenerated in that pdf :P May 15 08:05:29 hi May 15 08:05:49 is the FAQ at https://wiki.yoctoproject.org/wiki/FAQ weirdly broken for anyone else? May 15 08:08:36 I mean if I click that link, or navigate to it from the wiki, it just downloads a file called FAQ May 15 08:10:31 Baikonur: same from my side May 15 08:10:36 morning all May 15 08:11:06 bluelightning: ping for the slightly broken FAQ link that Baikonur posted May 15 08:11:29 it's https://wiki.yoctoproject.org/wiki/FAQ in case you dont see Baikonur's post May 15 08:12:59 Baikonur: chankit: I will email Michael H about it, thanks May 15 08:13:05 so I have the same question as yesterday: what is the proper way of customizing the permissions for serial consoles with Yocto? May 15 08:13:25 morning all May 15 08:16:34 bluelightning: my pleasure May 15 08:16:35 lpapp: same answer as yesterday, look into the udev scripts... May 15 08:17:09 bluelightning: you mean .bbappend and echo stuff into the permissions file in do_install_append? May 15 08:17:46 that would be one way yes May 15 08:18:36 just managed to get 3g connection working on my poky so all is good in the world <3 May 15 08:19:33 only took two days of work :) May 15 08:20:03 and that's just because I had done it earlier on debian May 15 08:22:50 Baikonur: using connman, modemmanager or something else? May 15 08:23:00 bluelightning: would that be the preferred way? May 15 08:23:20 lpapp: depends on the change you are making, but broadly, whatever works May 15 08:23:47 bluelightning: just pppd May 15 08:23:53 ah ok May 15 08:24:22 Baikonur: is there anything you'd recommend we do to make things easier? May 15 08:27:00 my major mistake was assuming that there would be a file at /etc/chatscripts/gprs since there had been at debian, but I think it's just my mistake May 15 08:27:42 we do lay some things out like debian, so I could understand the expectation May 15 08:45:30 Good day. Does anyone know how to enable NTFS-support to yocto? E.g. for mounting an externel USB-drive? I just need the name of the module which needs to be set to "=y" May 15 08:50:04 hb2331: not sure how https://www.yoctoproject.org/sites/default/files/kernel-lab-1.6.pdf can help but it does contain some guide on editing .config file for the kernel config May 15 08:51:27 chankit: So far I already added support for specific driver modules to the kernel. But I cant figure out how to add ntfs support (Dont know how to figure out the appropriate module name) May 15 08:53:47 hb2331: did u manage to get menuconfig working or are you just editing the .config file? May 15 08:54:49 hb2331: is CONFIG_NTFS_FS the options your looking for? May 15 08:54:50 both is possible May 15 08:55:08 YES that seems to be a hit May 15 08:55:13 this one looks good May 15 08:55:28 hb2331: you might also need CONFIG_NTFS_RW May 15 08:56:10 Thank you very much, that will be the solution for me :) May 15 08:56:11 hb2331: if you are thinking about using menuconfig, the command should be bitbake -c menuconfig linux-yocto May 15 08:56:21 hb2331: glad to hear that :-) May 15 10:21:13 bluelightning: I understand your point and thank that, but I still wonder why I have got these permissions with dylan, not daisy, by default: crw-rw---- 1 root dialout 4, 65 May 15 09:39 /dev/ttyS1 May 15 10:21:31 compared to daisy's crw------- 1 root root May 15 10:22:03 and we do not seem to set it in our layer either and even if it was so, it would be set for daisy, too, I believe, unless there is some more subtle issue somewhere. May 15 10:23:46 there is this line in both Yocto variants: ../meta/recipes-core/udev/udev/permissions.rules:56:SUBSYSTEM=="tty", GROUP="dialout" May 15 10:27:16 FWIW, I just booted a dylan image and a master image under qemu, and both had /dev/ttyS0 as root/root May 15 10:27:52 interesting May 15 10:28:10 did you have any udev issues during the boot? May 15 10:28:16 no May 15 10:28:17 I would suggest consulting the udev documentation and debugging the scripts (print out stuff, log to a file... whatever you need to do) May 15 10:29:02 yeah, I will do that when in no hurry, for now, I would use chgrp, I think. May 15 11:09:55 goodness, just noticed my devshell is root?! May 15 11:11:03 * joshuagl wonders how that's happening May 15 11:45:28 joshuagl: are you sure it's not just the effect of running under pseudo (like reporting id = 0)? May 15 11:52:40 pohly: oh, perhaps... May 15 11:59:29 yes, devshell is pseudo'd May 15 12:02:35 carry on, nothing to see here May 15 12:02:41 thanks rburton & pohly May 15 13:42:18 bluelightning: ping May 15 13:42:35 hi jedix May 15 13:43:07 rburton: saw my message regarding the bad plugins? May 15 13:43:17 bluelightning: hey, I emailed you regarding the HG fetcher. Did you get a chance to look at it? May 15 13:43:43 jedix: I did see your email, I hadn't had a chance to look at the code yet - unfortunately the hg fetcher is not my area of expertise either May 15 13:44:23 ah, okay. Thanks. May 15 13:45:19 Do you have a suggestion who I could ask? May 15 13:46:01 Volker Vogelhuber perhaps? May 15 13:46:10 ..I'm just going by the git log on the file May 15 13:46:45 otavio: yeah, merged into mut. sorry, failed to reply. May 15 13:48:53 jedix: I'm looking into it now May 15 13:49:22 rburton: good; once it is merged can we queue it for Fido as well? May 15 13:49:46 otavio: you'll have to ask joshuagl about that :) May 15 13:49:51 rburton: it is very harmless and is really the right config way for this specific case May 15 13:49:57 joshuagl: ! May 15 13:50:01 yeah, it is May 15 13:52:16 hello? what's this? May 15 13:52:28 bluelightning: thanks, I appreciate it May 15 13:52:50 joshuagl: it is regarding gst bad plugins patch in MUT May 15 14:00:37 * joshuagl looks up the patch May 15 14:01:13 happy to queue that for fido once it has landed in master May 15 14:04:34 jedix: so what are the exact circumstances under which ud.localpath will be a file rather than a directory? May 15 14:05:13 bluelightning: when looking at the cache dir, I believe is the only time May 15 14:05:28 jedix: by cache dir, do you mean DL_DIR? May 15 14:05:31 yeah May 15 14:05:50 jedix: I'm asking because I just built vim and what I have now is that ud.localpath is a directory, not a file May 15 14:06:34 bluelightning: ah.. so I had two projects with the same DL_DIR May 15 14:07:13 bluelightning: project A had internet and cached vim to DL_DIR, project B had BB_NO_NETWORK set to 1. project B deletes the vim archive that project A fetched May 15 14:08:48 bluelightning: but, vim fetched a tar.gz file for me.. most likely because that's what my PREMIRROR had May 15 14:08:59 joshuagl: thx; want me to ping you again? May 15 14:09:05 joshuagl: or you manage it? May 15 14:10:08 otavio: I'll try and remember to pull it in next time I review master, but please ping me if it doesn't appear May 15 14:11:40 jedix: ok, I'll reply to the email May 15 14:11:47 thanks May 15 14:12:29 joshuagl: thx May 15 15:02:18 jedix: I assume you saw http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib?id=9e24bde011479d9f22830080720510e52e9923d8 in master? May 15 15:03:14 jedix: what is really needed is some test in need_update which tests whether the revision is present in the current copy of the tree or not May 15 15:03:26 jedix: the git fetcher is the model for getting this right May 15 15:06:55 RP: I'll have a look. Thanks May 15 15:13:03 RP: That patch won't stop the hg fetcher from removing an archived repo May 15 15:14:19 jedix: I'm not claiming it solves your problem. It does remove the tarballs out the equation though May 15 15:16:09 jedix: I have no idea how you ask hg this but you need a "does this checkout in this directory have this revision" command. Once you have that, you need to integrate it into need_update May 15 15:16:37 jedix: in the git fetcher, this is _contains_ref() May 15 15:17:33 RP: and once I have that, the way the HG source is mirrored needs to be changed as well, right? May 15 15:18:44 jedix: I hadn't realised at the time but that last patch does look like it pulled out some of the hg mirroring code :/ May 15 15:18:45 since right now, there's just a tar file and in the future, the souce should be in ${DL_DIR}/hg/ May 15 15:19:07 jedix: the tar files simply aren't used after the patch in master May 15 15:22:09 bluelightning: thanks for yesterday's help - my workdir did change some time ago and required a clean build. sstate was masking the issue until it needed to rebuild... May 15 15:22:58 bluelightning: but I'm still having issues with nativesdk packages being rebuilt for different machines May 15 15:23:19 denix: ok, no worries May 15 15:23:23 RP: should nativesdk packages be shared between machines, when SDKMACHINE is the same? May 15 15:23:36 denix: yes May 15 15:23:39 denix: hmm... are you able to bitbake-diffsigs to see the difference? May 15 15:24:39 Task gcc-crosssdk-initial:do_configure couldn't be used from the cache because: blah-blah, different TUNEs May 15 15:26:55 RP: But uri_replace will still return a tar to try and fetch off the PREMIRROR/MIRROR.. May 15 15:27:44 so it still could be used, and seems to still remove my archived file when I cherry-pick that patch May 15 15:28:29 uri_replace in __init__.py May 15 15:28:52 bluelightning, RP: so, basically, gcc-crosssdk gets rebuilt between machines and its populate_sysroot forces all nativesdk packages to be rebuilt May 15 15:29:24 jedix: I'm a bit confused about how mirroring works at all with hg to be perfectly honest May 15 15:29:30 denix: that is not what should happen May 15 15:30:31 RP: well, I was using it by having a tar of the repo for a specific version.. which was then extracted and used. It appears that need_update was not being called if the fetcher had downloaded May 15 15:30:34 denix: can you pastebin that output somewhere please (from diffsigs) May 15 15:30:53 RP: sure, its bitbake -S printdiff though May 15 15:30:55 RP: if it had been called, well.. we know it would never work May 15 15:31:42 jedix: I'm not sure what you want me to say. I've done my best to describe how this problem should get fixed, at least as far as master is concerned May 15 15:32:49 jedix: need_update just checking random files is not correct May 15 15:32:50 RP: Thanks, I appreciate your time. I just think my patch is still useful for the archived repo case May 15 15:33:03 jedix: no, that patch is not correct, that much I'm pretty sure of May 15 15:33:34 RP: http://pastebin.com/8dy7QvLi May 15 15:34:40 RP: okay, I will look for a correct way of checking what I need. Thanks! May 15 15:37:26 and I sometimes see PR going backwards, but that's caused by rebuilding and not reused packages, I believe... May 15 15:38:09 that sounds wrong to me, PR ought never to go backwards unless I'm missing something May 15 15:38:21 at least with the PR server enabled May 15 15:38:47 only if a recipe explicity bumps pr and then you revert the change… May 15 15:38:50 denix: I just did a "bitbake meta-toolchain -S printdiff" locally, the ran diffsigs on the do_configure:gcc-crosssdk-initial stamp file May 15 15:39:01 denix: in my local copy there is no dependency on DEFAULTTUNE May 15 15:39:14 denix: can you mail be the gcc-crosssdk-initial sig file? May 15 15:39:16 rburton: right, yes May 15 15:41:28 can't PR still go backwards if you change the metadata back to a previous version so a previous sstate is pulled rather than building from scratch with an autoincrement? or did we fix that? May 15 15:41:39 "fix", since the behavior is debatable May 15 15:42:16 kergoth: you can still do that May 15 15:42:26 figured May 15 15:42:49 bluelightning, rburton: local PR server is enabled. this is multimachine build. each machine rebuilds nativesdk packages for some reason, bumping PR in the process. then when trying to build the first machine again, it complains its nativesdk packages has lower PR May 15 15:43:00 and denix likely has previous sstate it would restore to May 15 15:43:45 denix: the underlying issue is that the target tune shouldn't influence that recipe. It doesn't in my local build so I suspect some unintended side effect of some layer code, or something with the arm tunings May 15 15:44:57 RP: it's daisy, BTW - has anything changed in that area afterwards? I can quickly run some tests on more recent setups of mine... May 15 15:45:25 denix: its possible I guess, my memory is fuzzy on that May 15 15:45:45 denix: to be clear, a lot has changed/improved with this kind of thing so its possible May 15 15:47:28 RP: ok, do you still want to see the sig file? Is that siginfo for corresponding populate_sysroot? May 15 15:50:25 denix: The file will be something like tmp/stamps/i586-pokysdk-linux/gcc-crosssdk-initial-i586/*.do_configure.sigdata.* and yes, I'm interested. From the file you can see the code that brings in the dependency on DEFAULTTUNE. If we can see that it would give an idea of what is doing this May 15 15:54:37 denix: bitbake-diffsigs | grep DEFAULTTUNE would give the info I'm thinking about May 15 15:55:23 RP: ah, sigdata from stamps, not siginfo from sstate-cache... Ok, sent May 15 15:55:31 RP: let me try that May 15 15:57:28 RP: here - http://pastebin.com/8dNcHnjH May 15 16:00:16 denix: following this back, you get to List of dependencies for variable get_tune_parameters is set(['ABIEXTENSION', 'TUNE_CCARGS', 'BASE_LIB', 'TUNE_FEATURES', 'OVERRIDES', 'TARGET_FPU', 'TUNE_ARCH', 'PACKAGE_EXTRA_ARCHS', 'BASELIB', 'TUNE_PKGARCH']) (TUNE_ARCH depends on DEFAULTTUNE) May 15 16:06:41 denix: At a guess http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/recipes-devtools/gcc/gcc-common.inc?id=dabd58b030310541b89588ea55a0f372f5b40b52 May 15 16:07:42 RP: yeah, right! I just checked get_tunes_parameters in daisy and it excludes only AVAILTUNES, unlike master with many more vars... May 15 16:08:29 RP: thanks! I'll try to cherry-pick that and see if it help May 15 17:02:13 RP: ah, much better - only nativesdk-perl got repackaged, not rebuilt. -S printdiff points to nativesdk-libgcc:do_fetch and nativesdk-gcc-runtime:do_fetch for some reason... May 15 17:03:38 denix: quite an improvement then :) May 15 17:04:31 RP: indeed, thanks a lot! May 15 17:13:54 RP: so, debugging why nativesdk-perl got repackaged - it says its own do_package changed hash, nothing else is different. but comparing those 2 sigs of do_package shows they are identical... what else should I look at? May 15 17:16:03 denix: that sounds very odd since if the hash is the same, it could pull from sstate :/ May 15 17:16:43 denix: is rm_work involved? May 15 17:17:34 no rm_work May 15 17:18:22 denix: good ;-) May 15 17:18:34 and why did -S printdiff pointed towards do_fetch tasks of nativesdk-libgcc and nativesdk-gcc-runtime May 15 17:20:35 denix: -S does have some bugs. We've asked people to report reproducible corner cases like this where is does something odd... May 15 17:20:52 denix: I'm out of time today, need to head afk, sorry May 15 17:21:05 denix: be interesting to know if master does this though May 15 17:21:08 RP: no problem! have a good night and weekend! May 15 17:21:18 denix: thanks! May 15 17:21:36 and thanks for your help! May 15 17:35:33 denix: is the release you're on using shared sources for gcc & co? May 15 17:42:30 denix: if you're seeing lots of native do_fetch differences with printdiff, but no details on what's changed, you might need c9105597763be4bf5bc0ec97cc999566d0f10678 May 15 17:42:56 not sure as to the state of the version you're using, though, so not 100% on that, but it fixed that behavior of me with fido May 15 17:45:11 kergoth: thanks, let me try that May 15 17:46:03 kergoth: btw, I'm using daisy May 15 17:46:12 k May 15 18:22:57 kergoth: it didn't help with -S printdiff complaining about nativesdk-libgcc:do_fetch, but at least it didn't repackage nativesdk-perl w/o any reasons! more testing is required, but so far a good sign, thanks! May 15 19:55:51 hey folks, is there a way to configure what to compile/install without x support for hob ? **** ENDING LOGGING AT Sat May 16 02:59:59 2015