LTIB for Raspberry Pi rc4 is posted to: https://drive.google.com/#folders/0B5oPSqrs5WbUNndYZ0pxTm10NkE
This makes the changes suggested above. Most especially, it makes the post-install script echo sudo commands rather than executing them. The question of whether or not to host the RPi toolchains in the gpp is still unresolved, as this is a policy decision beyond my pay grade. My understanding is that these are GNU toolchains, made with crosstool-ng, and rpm-packaged by Mike Goins and myself. I'm going to leave this one up to Stuart. If you don't wish to host the toolchain package file, please suggest an alternative and I will gladly make the change. In other news, I've managed to port several interesting packages to the Pi using LTIB, including PocketSphinx, AdvanceMAME and AdvanceMess. I look forward to announcing LTIB's general availability to the Pi community. On Mon, Oct 1, 2012 at 5:56 AM, Stuart Hughes <[email protected]> wrote: > Hi Sean, > > My preference would be to store the script and prompt the user at the end of > the post_install script to run this by hand and tell them what commands to > run. That way they need to figure out if it's safe and if they have plugged > in an SD card in the right place etc. > > Regards, Stuart > > > On 01/10/12 09:49, Sean C. Malloy wrote: >> >> Re: sudo >> >> I can think of 3 courses of action: >> >> 1) make LTIB run the post-install script as root, eliminating the need for >> sudo. >> >> 2) change LTIB to prompt the user to add mount and loconfig(?) to their >> sudoers file >> >> 3) change the the rpi's post-install script to do nothing; put the shell >> script that makes the SD card image in the platform directory, and let the >> user run it manually. >> >> Sent from my iPhone >> >> On Oct 1, 2012, at 3:05 AM, Stuart Hughes<[email protected]> wrote: >> >>> Hi Mike, >>> >>> I second your comment about sudo, you should be able to automate builds >>> and so prompting users is not really practical. >>> >>> Toolchains can be stored at the GPP, but this is dependent on being sure >>> that anything stored on the GPP has a freely distributable license. You'd >>> expect that toolchains should be okay as gcc/binutils/glibc are GPL, but I >>> worry that if this is derived from some commercial vendors variant they may >>> have something in there that cannot be distributed. >>> >>> Also, due to ISP limitation (2 minute timeout) toolchains generally need >>> to be FTP'd to the GPP, the upload script won't usually succeed before the >>> time limit. Also if we do put the toolchain there, we must have all the >>> corresponding sources used to build the toolchain uploaded to. Maybe it's >>> worth resurrecting the ability of LTIB to download from places other than >>> the GPP? >>> >>> Regards, Stuart >>> >>> On 30/09/12 13:48, Mike Goins wrote: >>>> >>>> On Wed, Sep 26, 2012 at 7:15 PM, Sean Malloy<[email protected]> >>>> wrote: >>>>>> >>>>>> there will be a RC3 of rpi_boot.tar.gz that contains this >>>>>> license >>>>>> file and up-to-date /boot code >>>>>> from https://github.com/raspberrypi/firmware/tree/master/boot. >>>>> >>>>> RC3 of rpi_boot*.diff.gz is available. >>>> >>>> Reviewing the patch now and running the build. Just a few more >>>> questions. >>>> >>>> "Be sure to run "sync" before removing the card from the reader." >>>> >>>> I have found that running "blockdev --flushbufs /dev/[blockdev]" is >>>> much better at flushing out to block devices since sync concerns >>>> itself primarily with file-systems. I'm not sure if newer versions of >>>> sync do this automatically. We may consider adding this to the >>>> mksdimage script. >>>> >>>> Speaking of which. The post build script prompts for sudo password. >>>> This is a bit unconventional for ltib (and tougher for some automation >>>> systems, but doable). Like your note said, probably needs to be moved >>>> to deployment since ltib somehow is capable of doing these types of >>>> operations (not sure how myself, but looking at it now). It may be >>>> possible to put this operation in the rpi_boot.spec since that is run >>>> as root (and is relatively easy to do). >>>> >>>> What is the license on the original toolchain? I failed to find it >>>> anywhere in the github files we used to create the RPM. I am sure it >>>> is permissive, but wanted to make sure. >>>> >>>> Stuart, is it feasible to keep list member generated toolchains at the >>>> GPP? Sean, can you find out if the maintainer of the current tools at >>>> github is willing to accept and check in our rpm version of the >>>> toolchain? This may be the best alternative if not using GPP. >>> >>> >>> _______________________________________________ >>> LTIB home page: http://ltib.org >>> >>> Ltib mailing list >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/ltib > > -- Sean C. Malloy [email protected] _______________________________________________ LTIB home page: http://ltib.org Ltib mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/ltib
