From alessioigorbogani at gmail.com Tue Sep 4 08:49:07 2012 From: alessioigorbogani at gmail.com (Alessio Igor Bogani) Date: Tue, 4 Sep 2012 10:49:07 +0200 Subject: [Aboriginal] Build from version control system repos instead of from tarballs Message-ID: Hi All, Can Aboriginal grabs sources from git(Linux, musl, uclibc, busybox) and hg(toybox) repos instead of from tarballs? Thanks! Ciao, Alessio 1346748547.0 From rob at landley.net Fri Sep 7 19:23:05 2012 From: rob at landley.net (Rob Landley) Date: Fri, 07 Sep 2012 14:23:05 -0500 Subject: [Aboriginal] Build from version control system repos instead of from tarballs Message-ID: <504A4999.50901@landley.net> Sorry for the delay answering, thunderbird is totally melting down. I left it trying to check email for 12 hours and it failed. I can see this in the web archive, but not in my email. > Hi All, > > Can Aboriginal grabs sources from git(Linux, musl, uclibc, busybox) > and hg(toybox) repos instead of from tarballs? > Thanks! Yes, I do it for testing all the time, but the procedure's a bit strange. The way I do it is: mkdir -p build/packages hg clone http://landley.net/hg/toybox build/packages/alt-toybox USE_ALT=toybox ./build.sh i686 Which is easy to do, but takes some explaining to understand what's going on here: 1) USE_ALT says to use an alternate version of this package. This is a whole separate parallel version of a source package, with separate tarball, package cache, and patches. (Same build scripts though.) A) The tarball (if any) is downloaded from the ALT= in download.sh (and stored as packages/alt-$PACKAGENAME-0.tar.bz2 in case you're wondering). B) The package cache for it is build/packages/alt-$PACKAGENAME C) Patches (if any) are applied from sources/patches/alt-$PACKAGENAME*.patch files. You can build alternate versions of more than one package at a time by comma separating them, ala USE_ALT=busybox,toybox,linux . (You can even have getconfig spit out a different config file for alt stuff, ask me about that if you care. It falls back to spitting out the normal one by default, and 99% of the time that's all I need these days.) 2) If there's no tarball in packages and no URL to download it from, but the extracted package cache entry in build/packages exists, download.sh leaves it alone. So by specifying "use the alt- version of this package" and then supplying the package cache version of it myself using a source control checkout, I can test more or less behind the build system's back. This works because for most packages I don't have an ALT= URL specified (or it's commented out), and I haven't got any alt- patches checked into the repo. (When I do need them they're generally just symlinks to the release version patches.) If you _do_ have patches, the setupfor function notices that there's no sha1-for-source.txt in the package cache version, assumes it hasn't been patched yet, and applies the patches (listing the sha1sums it applied there, but no tarball sha1sum when there isn't one). If you take advantage of this, you can do a "git clean -fdx && git checkout -f" or similar in the package cache to undo this before your next bisect step, and it'll try to reapply them next build. You can set ALLOW_PATCH_FAILURE=1 if you don't mind patches failing to apply, but mostly for testing I just break down and "HOST_EXTRA=perl ./host-tools.sh" (or put the symlink in build/host by hand) so I don't need to apply the perl removal patches while bisecting a kernel bug. Does that answer your question? I've thought about teaching the build to check a "repositories" directory at the top level (next to "packages") and use the source out of there if it finds it, but what do I do about patches then? (Apply the ones the tarball takes? Never apply them and have it be the user's problem?) Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. 1347045785.0 From onefang at gmail.com Sat Sep 8 00:54:05 2012 From: onefang at gmail.com (David Seikel) Date: Sat, 8 Sep 2012 10:54:05 +1000 Subject: [Aboriginal] A possible solution for your email woes. In-Reply-To: <504A4999.50901@landley.net> References: <504A4999.50901@landley.net> Message-ID: <20120908105405.00315e0a.onefang@gmail.com> Sending this to the list as well as you Rob, in case you need to pick it up from the lists web archives still. On Fri, 07 Sep 2012 14:23:05 -0500 Rob Landley wrote: > Sorry for the delay answering, thunderbird is totally melting down. I > left it trying to check email for 12 hours and it failed. I can see > this in the web archive, but not in my email. Dunno if this will help you, but it helped me. Mind you, for my non thunderbird email client it was more of an annoyance than a melt down, but the basic problem is similar I think. The scanning for email took too long. In your case I think you mentioned before that the new email scan locks up thunderbird for long periods of time. In my case the new email scan slows things down and locks out a few of the menus. Which tends to only be a problem when my 'net is down and the time taken is increased by 'net timeouts. Coz in my case it locks out the Exit menu, and I often just want to exit when the 'net is down. So instead of having my email client spend a long time trying to scan and filter a dozen remote email servers that might be down, I use fetchmail + maildrop and a local email server to do the scanning + filtering in the background. My email client then just does a quick scan of my local IMAP server, with no filtering. All over with quickly for the client, and no 'net timeouts to make the slowdown / menu lockout a pain. YMMV, but it was a big help for me. It might also help if you finally get around to ditching thunderbird like you keep saying you should. B-) As a bonus, my local email server is IMAP, so I can access it from multiple clients and share the mail box / folder structure. For instance, from my new Android phone while I'm in bed or at the other end of the house. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rob at landley.net Sun Sep 9 01:55:49 2012 From: rob at landley.net (Rob Landley) Date: Sat, 08 Sep 2012 20:55:49 -0500 Subject: [Aboriginal] Build from version control system repos instead of from tarballs In-Reply-To: References: Message-ID: <504BF725.4010100@landley.net> On 09/04/2012 03:49 AM, Alessio Igor Bogani wrote: > Hi All, > > Can Aboriginal grabs sources from git(Linux, musl, uclibc, busybox) > and hg(toybox) repos instead of from tarballs? > Thanks! To add a little _more_ fun to this, binutils commit 397a64b350470350c8e0adb2af84439ea0f89272 is the last gplv2 version of binutils (after 2.17, before 2.17.50, the next commit coverted gas to gplv3), but I can't find a place to download that from as a tarball. I want the default build to use wget instead of git clone because wget is in busybox and git clone isn't: keeping the smallest possible build environment down to just 7 packages requires some compromises. I'm thinking about ways to simplify the package cache dance I mentioned earlier. Possibly the package cache should be packages/cache and then the procedure should be: 1) comment out the tarball URL in download.sh 2) remove the patches you don't want applied from sources/patches 3) git clone packages/cache/thingy And then just remove the alt- infrastructure because having two different versions of the same tarball in play at once is just silly. You can clone the build scripts repo into another directory and play around in there (or do branching if that's more your style, all that "shelve" stuff). Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. 1347155749.0 From idunham at lavabit.com Thu Sep 27 02:32:02 2012 From: idunham at lavabit.com (idunham at lavabit.com) Date: Wed, 26 Sep 2012 19:32:02 -0700 (PDT) Subject: [Aboriginal] binutils tarballs... Message-ID: <18012.132.241.18.69.1348713122.squirrel@lavabit.com> Hello, Binutils release-style tarballs can _almost_ be built using make -f src-release binutils.tar.bz2 MAKEINFO=makeinfo #or true There will be a binutils-2.17.50.tar.bz2 file, but I forget whether it lands in $PWD or ../ However, there is still one catch: one file (something/*.texinfo, IIRC) isn't built. You'd need to rename it or manually invoke makeinfo, then make again. Also, you may want to check that all the needed files are included (diff/sort -u the list of files in 2.17 & 2.17a for a general idea). This is allegedly the reason that the original tarballs got removed. HTH, Isaac Dunham PS.: 1348713122.0 From idunham at lavabit.com Sun Sep 30 07:01:41 2012 From: idunham at lavabit.com (Isaac Dunham) Date: Sun, 30 Sep 2012 00:01:41 -0700 Subject: [Aboriginal] [musl] microblaze port committed In-Reply-To: <20120929054156.GA20623@brightrain.aerifal.cx> References: <20120929054156.GA20623@brightrain.aerifal.cx> Message-ID: <20120930000141.0167901f.idunham@lavabit.com> On Sat, 29 Sep 2012 01:41:57 -0400 Rich Felker wrote: > Hi all, > > I've committed the initial (and seemingly fully-working) version of > the microblaze port. Several caveats: > > 1. Upstream binutils has a serious bug in gas whereby the relocations > it generates for symbols with local weak definitions cannot be > resolved by the linker. Patch at: > http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11155 > > 2. The toolchain binaries from Xilinx seem to produce .o files > incompatible with standard binutils, and vice versa. Pick one or > the other; don't mix them. For Landley's sake, I'll mention what we discussed on IRC (+ some details): -The Xilinx toolchain is binutils 2.16 + gcc 4.1.2 (GPLv2); binutils support was merged upstream in 2009, so Aboriginal would need the Xilinx EDK toolchain (see http://git.xilinx.com/?p=mb_gnu.git;a=summary ofor source) -Rich says that on microblaze, due to the way relocations are handled, using -Bsymbolic instead of -Bsymbolic-functions gives a libc.so that is either minimally broken or fully operational. (Mips also works with -Bsymbolic.) -The possibility of using mapfiles instead of -Bsymbolic-functions was mentioned, but Rich doubts that they were supported in older binutils. > 3. Threads are untested because qemu is broken, at least my version of > qemu (app-level emu) has a bug where clone() does not advance the > program counter properly in the child, so it starts a forkbomb-like > cascade of clone syscalls (thankfully just linear growth rather > than exponential). Ow. Rob, any thoughts on an Aboriginal port? -- Isaac Dunham 1348988501.0