**** BEGIN LOGGING AT Wed Mar 09 02:59:58 2016 Mar 09 07:30:18 zeddii: sorry for pinging you directly but I guess you are one of the maintainers for linux-yocto mailing list Mar 09 07:30:43 I've been trying to subscribe to the list for like one and a half week now Mar 09 07:30:56 i do not get any confirmation emails or anything from the list Mar 09 07:31:00 :( Mar 09 07:33:08 halstead: ^ Mar 09 07:35:18 Hi Mar 09 07:43:35 bluelightning: thanks :) Mar 09 07:43:51 let's hope someone gets around to this Mar 09 08:09:08 Do I need to configure busybox-syslog or does it start logging by default? I can't find any log file on my system but it's running Mar 09 10:41:24 Hi all. How can i let yocto sign all my packages and also restrict my package manager to only accept packages signed by me? Mar 09 10:41:52 I've been searching through the entire mega-manual for 2.0 and didn't find anything interesting besiedes sign_rpm.bbclass Mar 09 10:42:05 Also googling arround only yielded http://comments.gmane.org/gmane.linux.embedded.yocto.general/28097 Mar 09 10:43:03 make sure it just pulls from your servers? Mar 09 10:43:29 LetoThe2nd: doesn't prevent anyone to build and rpm that has got the appropriate toolchain and install it Mar 09 10:43:48 i want to prevent someone fiddling arround with our setup Mar 09 10:44:07 Anticom: which you are not entitled to prevent IIRC, given some legislature - let me find the link Mar 09 10:45:21 LetoThe2nd: Well i know that synology has their ipkg only accept their packages. Under the hood their NAS also runs linux. So is that some license thing of yocto project itself or what exactly is preventin me from doing that? Mar 09 10:45:38 you can raise up barriers by not offering an easy way, but IIRC you are not allowed to cryptographically restrict any updates. Mar 09 10:45:55 LetoThe2nd: i'm not talking about updates Mar 09 10:46:03 i'm talking about installing additional stuff Mar 09 10:46:07 Anticom: well a) is that synology didn't ask us/me, and you are wrong in terms that i can copy anything to a nas and run it. Mar 09 10:46:16 been there, done that. Mar 09 10:46:40 LetoThe2nd: but you can't install a package you've cross-compiled and packaged yourself without any modifications Mar 09 10:46:40 its just that they do not offer anything not signed by them through their repositories - which is what i just told you. Mar 09 10:46:55 there are tricks to unlock it but by default they're rejected Mar 09 10:47:20 Moreover i just mentioned synology because i don't think they would do anything illegal on that scale Mar 09 10:47:39 hm Mar 09 10:47:49 i wouldn't bet on their compliance. i guess its more like "nobody cared to sue them to that degree so far." Mar 09 10:47:54 LetoThe2nd: well the problem is, that we don't offer OTA updates currently Mar 09 10:48:42 LetoThe2nd: so what is your recommendation? Mar 09 10:49:46 Anticom: my recommendation is: raise barriers in term by not giving them root access, not offering uploading of blank packages. you can always pipe what they manually upload through some gpg-signing and then act accordingly Mar 09 10:50:27 and give them root access only after ticking a NV marker, basically saying "you're totally on your own. not our problem anymore." Mar 09 10:50:57 LetoThe2nd: sadly that's not how our customer relationship works Mar 09 10:51:03 they just won't accept that Mar 09 10:51:18 Anyhow the documentation on that topic seems to be missing in the manual Mar 09 10:51:37 Anticom: still your customer relationship has to adhere legislation, and i will not recommend or comment anything else. Mar 09 10:53:10 you're obliged to tell them its licensing, you're obliged to hand out source. and in many cases, you're also obliged to enable them to modify it. Mar 09 10:54:04 LetoThe2nd: we do ship the source of the OS packages if anyone requests them Mar 09 10:54:07 that's not the issue Mar 09 10:54:31 However i still don't see, what exactly prevents us from securing a given state on a device Mar 09 10:55:35 ah yes, it was: https://en.wikipedia.org/wiki/Tivoization Mar 09 10:56:17 Anticom: i'm not saying you can't "secure" your own update path. just gpg-sign what ever you hand out Mar 09 10:56:37 been there, done that :-) Mar 09 10:56:51 LetoThe2nd: And i'm not allowed to configure my package manager in such a way it rejects all packages not signed by us? Mar 09 10:57:27 Anticom: you can configure it that way, you just have to offer a "i know what i'm doing, so screw software warranty switch" Mar 09 10:58:03 LetoThe2nd: and there's no common yocto-way to do that? Mar 09 10:58:39 like i said several times already, i don't use package management. to use your words: "its not how our customer relationship works." Mar 09 10:59:28 Anyone else on that topic maybe? Mar 09 11:06:37 LetoThe2nd: So from how i am reading the wiki page on Tivoization, restricting software to run on a specific hardware as long as the same software could run on different hardware is okay with GPLv2 basically Mar 09 11:06:43 Or am i missunderstanding that? Mar 09 11:07:14 Anticom: bbl, lunch. Mar 09 11:07:20 enjoy Mar 09 11:11:04 folks - what does virtual/update-alternatives do ? Mar 09 11:12:40 raykinsella78: See the comments in the source: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/update-alternatives.bbclass it seems to help you with the alternatives system Mar 09 11:13:18 ok thanks Mar 09 11:16:29 raykinsella78: for example if you have multiple editors on your device you can choose the default one to be used using update-alternatives Mar 09 11:19:09 Anticom: Thanks - looking for a way to disable it. Mar 09 11:20:18 Anticom: its only v3 with the tivoisation clauses, and OE has a "no v3" button. but, if you're entering this territory, speak to a lawyer :) Mar 09 11:21:19 (https://www.gnu.org/licenses/gpl-faq.html#Tivoization) Mar 09 11:21:48 rburton: i've looked at the license.manifest for our image. There are some packages (e.g. bash) that are licensed under GPLv3. I'm not that fit with licensing stuff. What does that mean in pracise? Mar 09 11:21:52 practice* Mar 09 11:22:35 you need to sort out as an org if gplv3 is acceptable or not in your system Mar 09 11:23:31 the tldr is "stops the user running code they wrote", ie signature-checking bootloader Mar 09 11:23:49 Okay and besides not being practial, whitelisting the packages, that ship with GPLv3 and preventing any others is not an option either? Mar 09 11:24:34 you can set a INCOMPATIBLE_LICENSES to blacklist gplv3 from entering the image, and it will fall back to gplv2 forms if available (or fail to build) Mar 09 11:25:18 So it's an all-or-nothing thing? either drop GPLv3 stuff and go for restricting packages or open doors wide? Mar 09 11:25:52 well the question is do you want to stop any and all attempts at running user-build software on your product Mar 09 11:26:33 if the user can reflash an image through the bootloader, you're fine with v3 anyway Mar 09 11:26:54 or copy a binary to the device over ssh Mar 09 11:27:31 rburton: the basic problem is, that our users often don't know what they're doing. This may cause the devices to malfunction and we have to repair them again. We just want to make it harder for them to tinker with our devices. And having a message "Please confirm you know what you're doing" never stopped anyone :/ Mar 09 11:28:15 wait what? if it's possible to flash an entirely other image to the device it's okay to reject unsigned packages? Mar 09 11:28:28 the image lives on an SD card which can easily be flashed Mar 09 11:28:33 there you go then Mar 09 11:28:40 great news! Mar 09 11:28:43 you're not stopping someone rebuilding the entire image from scratch and booting it Mar 09 11:29:09 okay so now the only thing that's left is the missing documentation on how to configure yocto :] Mar 09 11:29:09 if you had a bootloader in flash that checked a signature on the rootfs, then that would be in violation Mar 09 11:29:39 yeah no idea how to do that with opkg, and opkg is still only has in-progress support for signing anyway Mar 09 11:31:01 rburton: we're currently using rpm anyway Mar 09 11:31:40 I've found this http://comments.gmane.org/gmane.linux.embedded.yocto.general/28097 which kind of might get me to sign my packages but i dunno how to tell yocto to configure rpm to reject unsigned packages Mar 09 11:34:45 this is less a yocto question and more a rpm question Mar 09 11:35:17 rburton: I was just hoping there was some undocumented trick, since e.g. packaging is abstracted away too Mar 09 11:35:33 Guess i'm not lucky today Mar 09 12:22:43 well isn't hiding/abstracting the packaging process away exactly what i told you earlier? Mar 09 12:23:17 11:49 < LetoThe2nd> Anticom: my recommendation is: raise barriers in term by not giving them root access, not offering uploading of blank packages. you can always pipe what they manually upload through some gpg-signing and then act accordingly Mar 09 12:23:25 le sigh Mar 09 12:24:02 besides, IANAL - for reliable details, i'd suggest to contact dr. carsten emde @ oasdl. he knows things like that. Mar 09 12:24:12 s/oasdl/osadl/ Mar 09 12:25:55 and by the way, "our users often don't know what they're doing" is just the reason why we don't believe in package management ;-) Mar 09 12:28:10 LetoThe2nd: So how are you deploying and applying updates? Mar 09 12:28:19 Reflashing the entire system? Mar 09 12:31:13 of course. Mar 09 12:31:24 so we are sure the state is coherent. Mar 09 12:32:13 the road of manual package updates with dependencies leads straught to hell, if the system doesn't have access to a repository to resolve. Mar 09 12:32:54 LetoThe2nd: And how do you handle configuration stuff? Mar 09 12:34:07 imagine your application consists of packages a, b andc, with revisions. lets call them a1, b1, c1. c is depending on same or higher revision of b and a, b is depending on the same or higher revision of a. so you start with (a1, b1, c1). Mar 09 12:34:17 then you hand out b2, because of bugfixes. Mar 09 12:35:02 but probably that doesn reach all systems, if updates are manual. then you hand out c2. now, whom will you hand b2 also? how to tell them what to do? Mar 09 12:35:44 that kind of combinatorial complexity is something we are convinced that we cannot handle. Mar 09 12:35:44 All needed updated packages will be provided in an archive and left there forever Mar 09 12:36:07 i thought you don't have OTA? e.g. no repository? Mar 09 12:36:11 and the runtime package manager will ensure not to install any package when it depends on a not provided dependency Mar 09 12:36:38 LetoThe2nd: I said we're deploying updates via an archive which will be copied to the device Mar 09 12:36:44 atm at least Mar 09 12:36:54 OTA updates may be enabled somewhen in the future Mar 09 12:37:04 but they'll remain optional even then Mar 09 12:37:48 As long as our RDEPEND of our packages is maintained correctly there shouldn't be an issue with runtime updates Mar 09 12:39:30 well, if you think you can handle that infrastructure... Mar 09 12:40:06 and the complaints of the users saying "update didn't work, there was an error displayed" (when your runtime pm 'took care') Mar 09 12:40:48 but again, its your product, your maintenance, your everything. i just can tell you what we saw in our systems. Mar 09 12:41:20 LetoThe2nd: Sure and i appreciate that - honnestly :) Mar 09 12:42:17 and configuration stuff is no magic in complete image updates. its just an additional rw partition that gets mounted somewhere. Mar 09 12:42:52 even if you go for runtime pm, make sure you can later offer a full image upgrade as a kind of emergency measure. Mar 09 12:43:21 mind that runtime pm is not only the cost in memory, its also that you need to provide an ui, testing, documentation, etc. Mar 09 12:43:37 together with infrastructure and maintenance, it becomes quite costly. Mar 09 12:45:15 so if you go for it, make really *absolutely* sure that the one who has to pay for it afterwards knows about those secondary costs, and is willing to pay. Mar 09 13:05:31 Hello, is there a way to copy a whole folder in a recipe ? Mar 09 13:07:52 minipada: just call cp in proper task Mar 09 13:08:45 thx Mar 09 13:18:41 rburton: sorry for pinging you directly Mar 09 13:19:02 rburton: can you help with linux-yocto mailing list subscription issue i am in? Mar 09 13:49:05 awaisb: did you reply to the confirmation mail? Mar 09 13:49:31 rburton: i am not getting any confirmation emails... :( Mar 09 13:49:45 check your spam folder Mar 09 13:50:25 if nothing in there, mail michael@yoctoproject.org Mar 09 13:50:56 nothing there :( ill email michael then, thanks Mar 09 13:51:15 possibly your mail server is rejecting the mail from our server Mar 09 13:54:06 hmmmm Mar 09 13:55:59 but i am subscribed to other mailman run lists Mar 09 13:56:01 oh Mar 09 13:56:55 it's not possible to have a different PREFERRED_PROVIDER_foo for two images that are part of the same build (bitbake invocation), right? Mar 09 13:57:04 rburton: on another mailing list (meta-amd) which is probably on the same server i had the same problem Mar 09 13:57:05 that seems like it'd be messy to implement... Mar 09 13:57:20 and i had to contact the administrator directly for subscription Mar 09 13:57:26 well lets see Mar 09 13:59:41 * Ulfalizer pokes rburton Mar 09 14:36:20 has anyone built gnome-session from the jethro branch of meta-gnome? I'm getting implicit-function-declaration errors during do_compile Mar 09 17:10:12 Has anyone used icecc in recent history? Mar 09 17:10:53 It seems like the icecc-create-env is fairly old and misbehaving when I try it. One of the .so's that gcc needs gets left out. Mar 09 18:26:03 can anyone help with gcc-cross-i586? I'm trying to upgrade meta-ada, I'm pretty much starting from scratch again. It's not configuring correctly, because inside tmp/work/x86_64-linux/gcc-cross-i586/4.9.3-r0/gcc-4.9.3/build.x86_64-linux.i586-poky-linux/gcc/ada/gcc-interface/Makefile I'm getting ./config/i386/t-linux64 instead of $(srcdir)/config/i386/t-linux64 Mar 09 18:26:46 this is fine inside gcc/ because that's where config/ is. Mar 09 18:56:58 RP: a bb.fatal() from a variable expansion results in a traceback due to BBHandledException being wrapped in ExpansionError, and therefore not captured as such at higher levels. thoughts? do we care exactly where a bb.fatal() came from? I'm thinking possibly not, but am unsure, I hate to throw away context, but it's ugly to see a traceback if it's a bb.fatal too Mar 09 20:11:07 what is the reason IPK packaging uses --prefer-arch-to-version for images by default? Mar 09 20:18:22 denix: IIRC some weird intel BSP was using older version of some package for GPU than what other package architectures were using Mar 09 20:20:30 denix: crownbay for xorg it seems https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg22117.html Mar 09 20:25:15 JaMa: heh, thanks! it bit me few times already. any time to overwrite it from a distro config? it's set in a package_ipk.bbclass unconditionally... Mar 09 20:28:25 have you tried? OPKG_ARGS_remove = "--prefer-arch-to-version" Mar 09 20:31:13 okay, so Mar 09 20:31:20 a week later, and having learned a great deal about a number of interesting things Mar 09 20:31:23 JaMa: I can sure try :) what other distros do? Mar 09 20:31:34 the problem is that bash provides its own broken definitions of getenv and setenv Mar 09 21:11:41 kergoth: I'm unsure. Capturing it into bugzilla to ponder might be good though? Mar 09 21:16:16 seebs: is this in connection with pseudo? Mar 09 21:16:24 Yeah. Mar 09 21:16:34 seebs: FWIW we've been running with an increased timeout patch and haven't seen any more failures Mar 09 21:16:54 There was this really strange problem in which, if I did "pseudo bash", the pseudo server that got started would be running in a pseudo environment, even though it definitely shouldn't have. Mar 09 21:17:10 Turns out, if you're in bash, and you call unsetenv, you get bash's implementation of unsetenv which doesn't actually change environ. Mar 09 21:17:22 Because they "know" that they will be able to fix up the actual environment before they spawn a child process. Mar 09 21:17:49 Anyway, I've redone a bunch of the startup code, and I am pretty sure that I have identified multiple race conditions which were probably causing issues and making the timeouts be more of a problem than they would. Mar 09 21:18:42 seebs: so we need to test a new version of pseudo? Mar 09 21:18:48 Basically, because of that, if you ran bash when a server wasn't started, you'd end up with bash trying to spawn a server which would try to reexec itself... and in the process it would try to report the exec to a server, causing it to spawn a server... Mar 09 21:19:17 I think it might be worth it. The branch I'm working on also has a thing to report a possible cause of timeout issues involving the sqlite memory database. Which would mostly be useful in that, if we were hitting the timeouts, we'd get useful logging. Mar 09 21:19:44 What I'd sort of like to do is set the retry value significantly lower (like 10-20) and see if we can get the failures, because in theory, we shouldn't see those failures even with a low retry value. Unless something's wrong. Mar 09 21:20:04 But I don't know how practical that would be. Also I need to get someone to code-review these changes, because they're more significant than I'm comfortable doing without code review. Mar 09 21:27:49 anyway, that is the answer to the mystery of why environ[N] could still have LD_PRELOAD=libpseudo.so when getenv("LD_PRELOAD") was null. Mar 09 21:28:05 Because bash uses names reserved for the implementation, which is a horrible thing to do and I wish people who aren't me would stop. Mar 09 21:28:23 (I feel that pseudo's "override implementation names" is at least sort of justified.) Mar 10 00:32:09 seebs: that does all sound very messy. Unfortunately we're not at a point where I have the build time to run such tests :( Mar 10 00:33:57 Yeah, I figured. So I think this one should probably wait for next pass, but I also think it may be worth backporting at some point because it probably will improve things noticably for at least some cases. Mar 10 00:34:13 Of course, now that I know what's happening, I can't believe it took me this long to figure out. Mar 10 00:34:54 seebs: hopefully we can find some time in M4 to try and resolve it once and for all **** ENDING LOGGING AT Thu Mar 10 02:59:58 2016