On Tue, Oct 15, 2019 at 10:56 PM Rob Landley <r...@landley.net> wrote: > > On 10/10/19 8:52 PM, enh wrote: > > On Sun, Oct 6, 2019 at 11:38 AM Rob Landley <r...@landley.net> 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.)
yeah, i sent you that patch too the other day if you do want to go the easy route. like i said, as far as i could find from searching, most uses of -P were to explicitly set it to 1. this is one reason why i like that toybox --help tries to be nice and clear about what the defaults are. i suspect the folks who wrote -P1 learned xargs from --help and were worried by -P, --max-procs=MAX-PROCS run at most MAX-PROCS processes at a time but didn't bother/know how to experiment. > 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? basically, this is about ^ and $, and whether they match start/end of _line_ or start/end of _input_. (one sad thing about Android's switch to OpenJDK is that my docs for java.util.regex.Pattern were lost. IMHO they were the clearest concise Perl-compatible regex docs around.) > (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 Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net