**** BEGIN LOGGING AT Fri Sep 04 02:59:58 2015
Sep 04 03:48:48 <nerdboy> seebs: guinness with your cookie?
Sep 04 03:49:21 <nerdboy> seebs: maybe an Airplane! joke is in there somewhere...
Sep 04 03:50:05 <nerdboy> (technically 5 or 6 but who's counting)
Sep 04 08:00:36 <mckoan> good morning
Sep 04 08:04:52 <bluelightning> morning all
Sep 04 09:37:35 <drou> hi guys
Sep 04 09:48:57 <bluelightning> hi drou
Sep 04 10:22:12 <lpapp> good morning
Sep 04 10:22:22 <lpapp> I can see this in the manual about the post installation scripts: "
Sep 04 10:22:23 <lpapp> The script defined in the post-installation function is called when the root filesystem is created. If the script succeeds, the package is marked as installed. If the script fails, the package is marked as unpacked and the script is executed when the image boots again. "
Sep 04 10:22:40 <lpapp> I thought it was running once the package is installed, which can happen later than putting it into the image
Sep 04 10:23:09 <lpapp> so this description confuses me a bit. Is this bad expectation not to always be like that depending on whether the package is part of the image?
Sep 04 10:27:09 <T0mW> Interesting, so, it sounds like the post install script gets another chance to got do its' work?  I wonder why they did it that way, rather than ERROR out the building of the image?
Sep 04 10:28:31 <T0mW> lpapp: very early in the morning for the others to appear on the channel.  try asking again in another two hours?
Sep 04 10:30:10 <lpapp> bluelightning is here, so what can go wrong? ;-)
Sep 04 10:30:29 <T0mW> heh
Sep 04 10:30:55 <T0mW> so he is, maybe still getting coffee?
Sep 04 10:30:56 <lpapp> but yes, it is almost noon, and still early for me :)
Sep 04 10:31:20 <T0mW> UTC-4
Sep 04 10:31:54 <bluelightning> I am here...
Sep 04 10:32:05 <T0mW> bluelightning: really?
Sep 04 10:32:30 <bluelightning> T0mW: a while ago we had a large number of scripts that simply would not execute on the host (e.g. ones that require doing something specific to the target arch)
Sep 04 10:32:43 <bluelightning> we have mechanisms to handle most of those now though
Sep 04 10:32:59 <T0mW> ah, ok
Sep 04 10:33:31 <bluelightning> FWIW if you're building an image with read-only-rootfs in IMAGE_FEATURES it will error out in that case, because there won't be a chance to run it on first boot
Sep 04 10:33:55 <T0mW> bluelightning: like Larry Wall said, when you invent your own language (sic) you can do what you want.
Sep 04 10:34:21 <bluelightning> well, I'd like to think we do what makes sense for the majority of use cases ;)
Sep 04 10:34:39 <T0mW> bluelightning: there are always tradeoffs.
Sep 04 10:34:47 <bluelightning> postinstall script execution on package install is the package manager's responsibility rather than ours directly
Sep 04 10:35:17 <bluelightning> (when building the image / on first boot, we are more directly involved though)
Sep 04 10:35:59 <T0mW> I always check to ensure my recipes / changes are propagated into the image. np
Sep 04 10:36:22 <lpapp> ok, so it ought to work as per expectation for package installation, too?
Sep 04 10:36:40 <lpapp> I.e. if I say ls /tmp, it will list the files in that directory when I install the package using pkg list foo?
Sep 04 10:36:42 <T0mW> well, next Friday, I'll be looking for work.  getting RIF'ed.
Sep 04 10:37:16 <lpapp> sorry to hear that.
Sep 04 10:38:53 <T0mW> it was a good job, worked from home on an interesting project, learned lots of new stuff.
Sep 04 10:40:44 <lpapp> yeah, and new challenges are also cool
Sep 04 10:42:07 <bluelightning> T0mW: sorry to hear that, best of luck with finding something new
Sep 04 10:42:14 <bluelightning> lpapp: yes
Sep 04 10:42:36 <T0mW> looks like all the Yocto work is on the west coast, but, time for change.
Sep 04 10:44:09 <lpapp> bluelightning: ah, ok, great.
Sep 04 10:44:12 <lpapp> bluelightning: thanks.
Sep 04 10:44:38 <drou> does anyone know if there is any way to have a splash screen before starting the desktop manager ? to avoid all kernel messages and so on
Sep 04 10:44:54 <T0mW> psplash
Sep 04 10:46:20 <T0mW> drou: iirc, set kernel cmd line to include 'quiet loglevel=3'
Sep 04 10:47:39 <T0mW> you get a small amount of text when the bootloader passes control the kernel, then psplash takes over.
Sep 04 10:48:28 <drou> psplash looks good to me.
Sep 04 10:48:30 <bluelightning> if you have "splash" in IMAGE_FEATURES that should bring the psplash package in , or you could do it in IMAGE_INSTALL
Sep 04 10:48:50 <drou> alright thanks
Sep 04 10:50:14 <T0mW> drou: if you need help customizing the splash image, contact me?
Sep 04 10:50:38 <drou> sure, thanks
Sep 04 11:12:04 <drou> T0mW: is there a way to add a splash image before the desktop manager is started ? i'm using grub.
Sep 04 11:12:34 <drou> after the desktop manager is started, i have a blank screen for about 5 secs
Sep 04 11:14:08 <T0mW> I'm using u-boot and splashing the screen from there on wakeup. then, u-boot passes control the kernel where psplash starts early from init, there is a black screen for about 1..2 seconds while matchbox starts before the desktop appears.
Sep 04 11:14:32 <T0mW> I still get text on reboot / shutdown showing when X terminates though.
Sep 04 11:14:49 <drou> well ok, but my first target is x86 tbh
Sep 04 11:15:01 <T0mW> ARM cortex here.
Sep 04 11:16:03 <T0mW> The desktop version of the project is something I was playing with and did not have time to really fine-tune it before I got the word I was being laid off.
Sep 04 11:16:23 <T0mW> it ran a turn-key app.
Sep 04 11:17:06 <T0mW> matchbox ran a the app on starttup without a "desktop"
Sep 04 11:18:07 <CTtpollard> can anyone recommend a yocto book?
Sep 04 11:20:23 <drou> i'm using openbox. anyways, is there a something that explains the psplash parameters ?
Sep 04 11:20:29 <drou> INITSCRIPT_PARAMS = "start 0 S . stop 20 0 1 6 ."
Sep 04 11:21:58 <T0mW> that would be the sysvinit runlevels and ordering.
Sep 04 11:23:34 <T0mW> "start 0 S' would be /etc/rcS.d (startup) S00psplash, so, it runs as the first item in the startup list.
Sep 04 11:25:41 <T0mW> "stop 20 0 1 6" is killed as 20th step when entering runlevels 0 (halt), 1 (single user), or 6 (reboot).
Sep 04 11:27:20 <T0mW> killed is a misnomer, it doesn't kill itself, if you look at the /etc/init.d/psplash script, it only "runs", it doesn't look to see what method to run as (Start / Killed).
Sep 04 11:31:05 <T0mW> what I like about psplash is that it shows some graphic during the boot process and shows the user a boot progress bar that informs them of the booting activity
Sep 04 11:31:57 <T0mW> after all, how many people understand the kernel / sysvinit boot messages? :P
Sep 04 11:31:57 <drou> So we can't stop/kill it after n secs or right after something started from systemd?
Sep 04 11:32:14 <drou> not me :p
Sep 04 11:32:25 <T0mW> W00T we don't use systemd
Sep 04 11:33:12 <T0mW> I'm not ready to trust using a largely unfinish boot manager on my products. Sysvinit is well proven.
Sep 04 11:33:24 <T0mW> YMMV
Sep 04 11:35:37 <T0mW> I don't see why you cannot do a 'killall psplash', then have the next app take control of the video...
Sep 04 11:37:34 <drou> sure, but i asked this because i don't have any psplash process running. i thought there was something like a timeout that kills the psplash binary
Sep 04 11:37:41 <T0mW> If you don't want the progress bar, comment out that section of psplash source.
Sep 04 11:39:41 <drou> i didn't have this as well. maybe there is something wrong with my image. actually i only had a white screen
Sep 04 11:40:40 <T0mW> I haven't delved into how psplash follows the boot progress and decides when to terminate. It will terminate after the final step of the desired runlevel is completed.  For example, if in runlevel 3 (drop to console), it will allow bash to take over the video when the last 'S99*' step has completed.
Sep 04 11:41:34 <T0mW> again, not sure about systemd, I simply deal with that beast on my suse box but will not use it in my embedded projects.
Sep 04 11:44:13 <T0mW> admittedly, systemd does seem to offer some interesting benefits, like keeping a daemon running if it terminates, but I feel better having total control over my boot process, not have it disrupted by a decision by someone outside of my control and have my product start behaving differently due to a git pull on the Yocto base.
Sep 04 11:44:38 <drou> ok, so the best way is to have all my applications started in /etc/rcS.d/ and the splashscreen will disappear at the very last step?
Sep 04 11:45:29 <drou> completely agree with you, maybe i can use another supervising system
Sep 04 11:47:14 <T0mW> it will complete after the runlevel is finished (/etc/inittab target level)
Sep 04 11:48:28 <T0mW> you always pass through runlevel rcS.d, but rc[1,3,5].d are the target levels, when the target level completes, psplash will terminate.
Sep 04 11:50:00 <drou> ok i got it
Sep 04 11:51:02 <T0mW> If I were writing a splash with progress bar, I would tally up the number of 'Sxx' scripts of the target runlevel, watch stdout for the sysvinit / systemd progress messages to move my bar, then die when the last count is reached.
Sep 04 11:51:17 <T0mW> assuming that is possible, hen
Sep 04 11:51:20 <T0mW> assuming that is possible, heh
Sep 04 11:52:17 <T0mW> I would have to have a very compelling reason to abandon sysvinit, just because systemd is shiny / new is not good-enough.
Sep 04 11:56:18 <drou> actually i'm not an expert, i'm just trying things. but in fact, if i find another way to supervise/deamonize my apps, i'll probably drop systemd, i understand that systemd & sysvint are completely asynchronous
Sep 04 11:59:06 <T0mW> no, sysvinit is synchronous, it follows an ordered process that you specify.
Sep 04 11:59:22 <T0mW> it will launch in sequence
Sep 04 12:01:45 <T0mW> having said that, if you start the network (S01networking) your interfaces may not yet be ready to use on the next step (e.g. S02nfsserver).  You may have to move nfsserver start to 20 (S20nfsserver) which, effectively, puts a "delay" between the network start and a networking app.
Sep 04 12:39:58 <drou> Yes, i meant both systems in parallel
Sep 04 13:19:43 <rburton1> seebs: there doesn't appear to be a pseudo 1.7.2 tarball up yet
Sep 04 16:16:50 <ebolton> hey all, strange issue...I'm trying to install an SDK on a 64-bit Ubuntu machine and getting this error, "Setting it up...ls: cannot access /opt/poky/1.7.2/environment-setup-*: No such file or directory"
Sep 04 16:17:05 <ebolton> SDk installs fine on the machine it was created on, they're both Ubuntu based
Sep 04 17:22:47 <RP> seebs: bad news: https://autobuilder.yoctoproject.org/main/builders/buildtools/builds/473/steps/BuildImages/logs/stdio
Sep 04 17:46:30 <JaMa> RP: the postinst_intercept patches were sent as RFC, I've just noticed they were added to master-next
Sep 04 17:47:00 <JaMa> RP: I believe they work OK, but it's possible that I haven't discovered all possible env/intercept combinations
Sep 04 17:47:11 <JaMa> RP: because I was testing mostly the update_font_cache one
Sep 04 17:52:17 <kergoth> hmm
Sep 04 17:55:36 <JaMa> also this snippet:
Sep 04 17:55:39 <JaMa>             try:
Sep 04 17:55:40 <JaMa>                 subprocess.check_output(script_full)
Sep 04 17:55:40 <JaMa>             except subprocess.CalledProcessError as e:
Sep 04 17:55:40 <JaMa>                 bb.warn("The postinstall intercept hook '%s' failed (exit code: %d)! See log for details!" %
Sep 04 17:55:42 <JaMa>                         (script, e.returncode))
Sep 04 17:56:01 <JaMa> looks a bit strange as there normally isn't any output from intercept hook in the log
Sep 04 17:56:24 <JaMa> any objections to send the output to log.intercept_<script_name> ?
Sep 04 18:00:04 <kergoth> the called process error has a member with the output, but as you say, check_output() suppresses/captures the output by default
Sep 04 18:00:18 <kergoth> either that should be check_call(), or it needs to use the output from the exception
Sep 04 18:00:20 <kergoth> afaik anyway
Sep 04 18:00:26 <kergoth> well spotted there
Sep 04 18:24:02 <seebs> ... Did I do the thing where I forgot to actually send halstead the pseudo 1.7.2 tarball? I bet I did.
Sep 04 18:25:40 <seebs> Oh, wait. I did, I just sent the patch out before getting an ack.
Sep 04 18:35:57 <halstead_> seebs: RP put it up 2 hours ago I think.
Sep 04 18:42:28 <seebs> nooooooo
Sep 04 18:42:48 <seebs> What the heck.
Sep 04 18:43:02 <seebs> Is it possible that your systems are hosted in an environment that is haunted by angry ghosts?
Sep 04 18:44:34 <seebs> To be fair, buildtools-tarball wasn't a target I was testing, but that looks general.
Sep 04 18:44:37 <halstead_> seebs: maybe? They are on the third floor of a medical facility. Are you seeing problems now?
Sep 04 18:44:42 <seebs> But I am pretty sure that I tested with my patches on at least two machines, and did not see that... WTF.
Sep 04 18:44:56 <seebs> "operation not supported" is a very strange outcome.
Sep 04 18:59:26 <T0mW> okay, I give up, after googling and grep'ing, I cannot figure out how the contents of /etc/version, in the image, is determined.
Sep 04 19:01:30 <kergoth> T0mW: grep -nrI sysconfdir.\*version
Sep 04 19:01:47 <T0mW> looks like: meta/lib/oe/rootfs.py?
Sep 04 19:01:50 <kergoth> yep
Sep 04 19:02:20 <T0mW> See, all I have to do is ask and I'll find myself before anyone anwers, why is that?
Sep 04 19:02:52 <T0mW> BUILDNAME
Sep 04 19:07:50 <seebs> Yeah.
Sep 04 19:08:04 <seebs> Now trying to reproduce that failure, no luck yet.
Sep 04 19:08:26 <seebs> I don't know yet.
Sep 04 19:08:40 <seebs> I at least figured out why my nearly-but-not-quite perfectly up to date tree didn't reproduce the opkg ones, but the new cross-localedef stuff RP posted, I have no idea.
Sep 04 19:08:46 <seebs> Yeah, I am not yet reproducing that one.
Sep 04 19:09:29 <T0mW> kergoth: YAY!
Sep 04 19:13:19 <seebs> Oh, huh. Apparently when I request buildtools-tarball, I don't build glibc-locale? Hmm.
Sep 04 19:16:14 <seebs> Victory! Manually building glibc-locale produces the failure.
Sep 04 19:33:09 <kergoth> buildtools tarball is almost entirely nativesdk packages built by crosssdk tools, i wouldn't expect it to build target packages like glibc-locale, but *shrug*
Sep 04 19:35:53 <malkauns> how do i install wireless-regdb in yocto?
Sep 04 20:03:54 <seebs> okay that's new
Sep 04 20:03:56 <seebs> it looks like there's an fcntl failing that's causing this error, but I don't know which fcntl op or why.
Sep 04 20:07:40 <rburton> kergoth: your host contamination patch shows that everyone who uses tar in ptest install functions (common idiom) is broken
Sep 04 20:29:00 <nerdboy> seebs: strace?
Sep 04 20:31:36 <seebs> yeah, probably.
Sep 04 20:32:11 <seebs> fcntl appears to be a red herring, looks like the actual issue is that mkdir appears to be somehow managing to hand back errno 95 (ENOTSUPP). And I am not at all sure why/how, and I note that the directory does seem to get made, so.
Sep 04 20:32:49 <nerdboy> so was it angry ghosts or just a momentary warpage of the time-space continuum?
Sep 04 20:32:53 <seebs> But hey, I can reproduce the failure, now.
Sep 04 20:33:11 <seebs> I am not sure why that build was making glibc-locale and mine wasn't, but I can do it on purpose. Can't reproduce it outside of bitbake yet, but narrowing in.
Sep 04 21:29:19 <seebs> bwahaha!
Sep 04 21:29:25 <seebs> I found the bug, and technically it is Not My Fault.
Sep 04 21:29:38 <seebs> ... I think.
Sep 04 21:29:57 <seebs> I would have to reread the spec, but the problem is that mkdir() is succeeding but setting errno as a side-effect.
Sep 04 21:30:11 <seebs> And localedef is doing
Sep 04 21:30:23 <seebs> if (output_path == NULL && ! no_archive) { print error message }
Sep 04 21:30:28 <seebs> cannot_write_why = errno;
Sep 04 21:30:35 <seebs> and then using cannot_write_why as a test for whether something went wrong.
Sep 04 21:30:49 <seebs> Which is to say, it is assuming that if errno has a value, it means that something went wrong, and this is not correct.
Sep 04 21:31:09 <seebs> That said, it is probably my fault that mkdir() can now set errno to 95 unexpectedly.
Sep 04 21:32:28 <seebs> ... it is.
Sep 04 21:32:36 <seebs> because I called fchmodat() with AT_SYMLINK_NOFOLLOW.
Sep 04 21:40:34 <seebs> RP: Assuming this test passes, 1.7.3 should be out in about half an hour? Also I would like to set glibc's localedef code on fire. For sound technical reasons.
Sep 04 22:07:57 <RP> seebs: ok, if it comes out we should have room over the weekend for another build
Sep 04 22:08:24 <RP> seebs: It looks like I have other things breaking the build atm too :/ (my own patch for a change)
Sep 04 22:19:09 <seebs> If you would be so kind, if you encounter more pseudo stuff over the weekend, could you cc my home address? I may forget to check work email over the weekend, things are being unduly busy.
Sep 04 22:19:24 <seebs> I am really offended by that glibc code, btw. I mean, yes, my bug triggered it, but that code is just plain wrong.
Sep 04 23:16:57 <khem`> seebs: which code
Sep 04 23:20:01 <seebs> in localedef, the thing causing the "operation not supported" errors.
Sep 04 23:20:21 <seebs> Which is that after glibc has checked that mkdir succeeded, it unconditionally stashes errno, and later, if errno is non-zero, reports this as a fatal error.
Sep 04 23:20:27 <seebs> The stashed errno, that is.
Sep 04 23:20:46 <seebs> So if errno gets set, even though the actual return value indicated success, it's treated as an error anyway, and this is silly.
Sep 04 23:21:52 <Snert__> seems like if errno gets set for any reason it should reflect that it's been set.
Sep 04 23:22:03 <seebs> Not in general.
Sep 04 23:22:16 <seebs> Lots of things are allowed to set errno when nothing has gone wrong.
Sep 04 23:22:24 <seebs> The famous example is printf() setting errno to ENOTTY when no error has occurred.
Sep 04 23:22:54 <seebs> Generally, if something has a return value that indicates success or failure, and it indicates success, it is antiproductive to look at errno.
Sep 04 23:23:56 <Snert__> different interpretations of how it shouldbe I guess.
Sep 04 23:24:19 <Snert__> but that's open source so gotta love it.
Sep 04 23:25:45 <seebs> The C/posix specs are pretty clear; do not check errno if you do not have a thing telling you that there was an error.
Sep 04 23:26:00 <seebs> errno is for telling you *which* error, not whether or not there was an error.
Sep 04 23:26:12 <Snert__> but no enforcement.
Sep 04 23:26:16 <seebs> (I also didn't see anything zeroing errno out, but maybe there was one somewhere.)
Sep 04 23:26:30 <seebs> Well, the enforcement is that if you do it, you produce random weird error messages that have nothing to do with anything actually going wrong
Sep 04 23:26:39 <seebs> ... which is exactly what happened in this case. :)
Sep 04 23:26:50 <Snert__> why allow a check to errno when no error occured?
Sep 04 23:27:02 <Snert__> why is it not enforced.
Sep 04 23:27:18 <seebs> Because C does not in general inforce much of anything.
Sep 04 23:27:21 <seebs> enforce, even.
Sep 04 23:27:30 <seebs> It is not in the spirit of C to prevent you from doing silly things.
Sep 04 23:27:39 <Snert__> so I've heard.
Sep 04 23:28:03 <seebs> More generally, I'm not sure how you *could* enforce it. Someone can always write "x = errno;"
Sep 04 23:37:07 <seebs> Hmm. Well, they do zero it out, I still think the code is silly.
Sep 04 23:52:26 <Snert__> I jsut don't do weird stuff.
Sep 04 23:52:49 <Snert__> it would never occur to me to deal with errno if there was no error.
Sep 04 23:53:12 <Snert__> but me noob amateur coder.
Sep 05 00:03:32 <seebs> The only place it usually makes sense is something like getchar() which returns the same value for "failure" and "end of file", so you set errno to zero, then call it, then check errno if you care.
**** ENDING LOGGING AT Sat Sep 05 02:59:58 2015