On 10/10/19 8:52 PM, enh wrote: > On Sun, Oct 6, 2019 at 11:38 AM Rob Landley <[email protected]> wrote: >> Where is this packaging done in AOSP? (I can dig my way to it eventually, but >> you'd probably know off the top of your head. :) > > system/sepolicy/private/file_contexts
*blink* *blink* *blink* Ah, system/sepolicy has a README, maybe I should start there. (I wonder what the .te extension stands for? Hmmm... the note at the end mentions setool, which I'm guessing is prebuilts/python/linux-x86/2.7.5/lib/python2.7/site-packages/setools which doesn't ahve a README... ah, but https://github.com/SELinuxProject/setools/blob/master/README.md does and no I'm not looking to _analyze_ the policy, I'm trying to find out what tool actually makes the resulting filesystem... Sigh. Google keeps bringing up stuff like https://www.oreilly.com/library/view/embedded-android/9781449327958/ch04.html which is 7 years old and talks about how closely the build is tied to a specific version of gnu make. :) Eh, poke at it later. >>> i can tell you already that one of the issues is going to be xargs -P >>> --- i almost sent you a patch last week that made -P a no-op (given >>> that the docs say "up to ... processes"); i don't know whether it >>> actually makes a difference to build times. >> >> While xargs is >> running, you can send its process a SIGUSR1 signal to increase >> the number of commands to run simultaneously, or a SIGUSR2 to >> decrease the number. >> >> Seriously?... >> Anyway, I might whip up an xargs -P if it's quick and I get a gap, but this >> SIGUSR increment/decrement thing is kind of _conceptually_ silly? (What... >> why...?) My xargs is dirty from a half-finished cleanup after the last patch I merged (the xopen of /dev/tty would fail _after_ the fork, potentially repeatedly), and you've sent me two more patches, so I shouldn't open that can of worms now I expect. :) > i don't know of anyone who wants the signal nonsense. actually, if you > think you can get the hard-coded -P 8 removed from the kernel, i think Ah, you use the header archive and I use the "just install them in the new directory" variant (which is a script I wrote as part of the perl removal stuff). That's why I hadn't noticed. > we could all forget about this. (the scary part is that searching all > the source available to me internally, -P 8 is basically the only use > of -P. there's the odd pointless -P 1, and one -P 100, but presumably > everyone's copy & pasted 8 from somewhere? too high for my MacBook Pro > which starts to melt around 4, and too low for my desktop, which can't > count that low.) > > i do wonder how long it would take for anyone to notice if we made -P > a no-op (and am very disappointed with myself that i didn't do that > long ago). I could just do that. (This is _supposed_ to be iobound, what are they doing that -P 8 helps? Invoking perl. Oh JOY. More perl to remove from the kernel build! And the -n1 means THEY DON'T KNOW HOW TO USE FIND... sigh.) Grumble grumble dowanna kernel tangent. Can't somebody ELSE remove this perl? Seriously, what is this: # Remove comments except SDPX lines find $cpio_dir -type f -print0 | xargs -0 -P8 -n1 perl -pi -e 'BEGIN {undef $/;}; s/\/\*((?!SPDX).)*?\*\///smg;' This is find $cpio_dir -type f -exec sed -i "something" {} \; isn't it? I mean I could convert the _perl_ if I wanted to but... perl? Really? Sigh, what's the "something". Ok, -p is "print loop" and -i is same as sed -i, I think "BEGIN {undef $/;}; is perl noise here, and then you have the s//smg. What does /smg mean? Let's see... https://perldoc.perl.org/perlop.html#Regexp-Quote-Like-Operators g is the same as sed s///g s means "treat string as single line" and m means "treat string as multiple lines"...? Seriously, perl? This is your idea of documentation? (Oh, perl 6 has been renamed to "Raku". I wonder what they'll rename Python 3 to?) Sigh. Not working this out at 1am. >> [a month later, still no release out. Yesterday I plugged toybox into the old >> aboriginal linux build again and this time I got most of the way through the >> gcc >> build, at which point the tar "no ../ files outside this directory" check is >> false positiving on "./" for some reason, gotta track that down. All the >> corner >> cases, gotta constantly regression test, old builds are a good way to do >> that. >> They test stuff I'd never think off...] > > releases have to be time-based or feature-based, you can't have both :-) I know, I know. I'm overdue. >>> but i'm not sure how many people >>> actually build it themselves rather than just suffer whatever happened >>> to be on whatever device they have. >> >> Given how many people are still sticking busybox on devices, I'd expect >> there's >> a demand for newer toybox binaries on older systems. (Especially if I get the >> rest of the 1.0 roadmap sorted.) > > aren't busybox users folks who've rooted their devices? so they can > just use the latest toybox anyway? Exactly. If you're going to root your device, I'd like to make installing current _toybox_ on it a good option. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
