Comments for technomasochism

Comment on openembedded yocto native hello world by Philip

Philip — Sun, 15 Apr 2012 16:20:02 +0000

Thanks for the comment Rich! I’m with you on the Makefile convention. The “hello world” example I give follows this convention quite closely (I think).

My confusion came from the change in the bindir variable in the OE environment for “native” packages. The change being ${bindir} for a cross compiled package as /usr/bin but in the “native” environment it has ${exec_prefix} pretended to it. All the while ${D} remains unchanged. I had expected (incorrectly) to be able to simply pass DESTDIR=${D} in my do_install to oe_runmake in both environments without issue. Following the convention you identify makes working through this difference possible but it isn’t what caused my confusion.

Regardless the veil has been lifted! Yocto / OE + properly written Makefiles = awesomeness … though a distant second to Yocto / OE + autotools

Comment on openembedded yocto native hello world by Richard Purdie

Richard Purdie — Sun, 15 Apr 2012 11:25:44 +0000

This “craziness” does have a rational explaination. “native” targets are meant to run on the system they’re built on and run in the location they’re installed to. This means they install to a destination of “/” and PREFIX is inside the native sysroot directory.

We install them to a DESTDIR to allow us to manipulate them before they then get moved to a final DESTDIR of “/”.

Most Makefiles handle this correctly by doing:

DESTDIR ?= “”
prefix ?= “/usrr”
bindir ?= “$(prefix)/bin”

and then, importantly, install in the form:

install -d $(DESTDIR)$(bindir)

so both prefix and DESTDIR are used. Whilst this is a convention, its a widely adopted and followed one. As you’ve found, you can call into a custom makefile and set the variables manually if the makefile doesn’t follow the convention.

Comment on openembedded yocto native hello world by Philip

Philip — Sat, 14 Apr 2012 15:07:29 +0000

Makefiles have been my personal favorite for self inflicted pain for a while now … but seriously, I suffered through this exercise to get a recipe working for someone else’s software. It was either rewrite their build system to use autotools and get that accepted upstream, or figure out the ins and outs of the ‘native’ class / environment. I agree though, new projects should use autotools. But until every source tree out there is built with autotools someone will have to write recipes that can cope with hand written Makefiles.

Comment on openembedded yocto native hello world by tf

tf — Sat, 14 Apr 2012 06:20:53 +0000

I don’t tink there are many more reliable ways of self inflicting pain than handwriting makefiles for a project you intend to cross-compile. Save youself lot of pain and use autotools from the beginning, lof of work over many years went into the Poky autotools support.

Comment on Xen Network Driver Domain: How by technomasochism - Linux bridge forward EAPOL 8021x frames

technomasochism - Linux bridge forward EAPOL 8021x frames — Thu, 29 Mar 2012 02:08:07 +0000

[...] in that the networking hardware is shared between guests through a bridge hosted in dom0 (or a network driver domain in the case of XenClient XT). For most use cases the standard Linux bridge will route your traffic [...]

Comment on OE-Core Yocto gcc timeout by Philip

Philip — Tue, 20 Mar 2012 13:30:49 +0000

Thanks Scott, that’s some great info. I was following the Yocto quick start:

http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html

This means I’m using the complete Yocto build system, just not the default distro as you point out. I guess if you build “distro-less” like the quick start recommends you don’t benefit from the mirror system you point out above. That should be easy enough to fix.

Thanks again!

Comment on OE-Core Yocto gcc timeout by Scott Garman

Scott Garman — Mon, 19 Mar 2012 21:02:16 +0000

One advantage you get when you use the complete Yocto build system and default distro (Poky) is that our default meta-yocto layer includes a PREMIRROR which causes the build system to attempt to download tarballs from our mirror before hitting the upstream.

You can take advantage of this using your current distro by copying our PREMIRRORS and MIRRORS section into your distro config file:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/distro/poky.conf?h=edison

Regards,

Scott Garman

Comment on Understanding Multi-Level Security part #3 by technomasochism - LaTeX for your Resume / CV

technomasochism - LaTeX for your Resume / CV — Wed, 14 Mar 2012 22:54:56 +0000

[...] logical expressions for past homework exercises. I’ve also used it in blog posts for doing the same. It’s a very useful tool even if you’re just a using basic templates like [...]

Comment on Financial Site Password Policies by Philip

Philip — Wed, 14 Mar 2012 22:05:05 +0000

Seriously it’s just your life savings. No big deal. Really I’m curious to know how many customers actually dial into their bank account on a touch-tone phone? Comparing the number of people that use their website with those that use touch-tone access and the relative loss of security because of the existence of the latter system would be interesting. People in the infosec biz are always talking about “security metrics” and how they don’t exist but in situations like this it’s pretty easy to get numbers that actually mean something.

Comment on Financial Site Password Policies by Jason

Jason — Wed, 14 Mar 2012 16:28:45 +0000

I realize this article is old, but it validated the ranting e-mail I sent to Fidelity just a minute ago. I went to update my password today, which I should have done a long time ago, and I had to dial down my password generating utility to make something that worked. I use long, complicated, absurd passwords for important stuff like credit cards, banking, and… oh I don’t know, my life savings! If they want customers to be able to dial-in to their accounts by telephone, then they should create a separate authentication system for that with a telephone PIN or something. This is inexcusable.