<div dir="ltr"><div>We are extremely busy at work so coming back to this thread later than I intended. I also have mixed feelings about MSFT and GithHub but in some ways why not take advantage of them and exploit what they are offering. I don't believe there is any significant coupling to MSFT and it's a relatively simple and clean way to test on MacOS and you get other builds as a bonus. I don't think this would change your workflows Rob, I certainly wouldn't want to see you depend on it for release workflow as that *would* couple in an undesirable way.</div><div><br></div><div>I will update the build steps when I get a moment to cause them to appropriately fail when a test fails. The full build output is also emailed on a failure as well as available via the web ui which is something that I don't think you are seeing when you look the builds in my repository. </div><div><br></div><div>Regards,</div><div>Eric</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2020 at 9:46 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/16/20 3:27 PM, enh wrote:<br>
> On Mon, Jun 15, 2020 at 4:05 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br>
>><br>
>> On 6/15/20 1:42 PM, enh wrote:<br>
>>> On Mon, Jun 15, 2020 at 11:05 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br>
>>>>> i don't actually remember us ever having an aarch64-specific issue.<br>
>>>>> (funnily enough, a 32-bit x86 build would probably find more bugs,<br>
>>>>> since i don't think anyone regularly tests any 32-bit arch locally. i<br>
>>>>> certainly only find 32-bit issues when i try to run on an Android<br>
>>>>> emulator!)<br>
>>>><br>
>>>> I test it before releases, and I test the j-core stuff which is still only 32<br>
>>>> bit. But it's not tested nearly as regularly as the 64 bit stuff is.<br>
>>><br>
>>> (to be clear, i meant "at the time of commit". thanks to the 32-bit<br>
>>> x86 "cuttlefish" emulator testing, we do get testing every time i try<br>
>>> to sync AOSP. but .)<br>
>><br>
>> This wouldn't be at time of commit either, this would be at time of push to<br>
>> github. Which lately has been a day or so after my local commit on my laptop<br>
>> because I forget. :P<br>
> <br>
> as far as the other ~8 billion people on the planet are concerned,<br>
> that's the same thing :-)<br>
<br>
Yes, but 99.99% of them get it through you, then a phone manufacturer, than a<br>
telecom vendor on a collective 18 month delay, and very few of them are the ones<br>
who have to root cause the issue and come up with a patch.<br>
<br>
I admit this is probably a thing I should do, if for no other reason than I<br>
haven't got macos test hardware. (Unfortunately, the mac version of a raspberry<br>
pi appears to be $800: <a href="https://www.apple.com/shop/buy-mac/mac-mini" rel="noreferrer" target="_blank">https://www.apple.com/shop/buy-mac/mac-mini</a> .)<br>
<br>
>> Did you know that "lunch" without options does _not_ list sdk-eng? (Which sounds<br>
>> like it's building the sdk and not an aosp image to run under the emulator, but<br>
>> let's at least try what it says first...)<br>
> <br>
> there are lots of options not listed in there. (and i don't actually<br>
> know a way to see the full list.)<br>
<br>
I want to make a FAQ entry with "do this, this, and this, here's what the<br>
results mean". I expect multiple steps to involve "this runs overnight".<br>
<br>
The "download" part is: wget repo, repo init blah, repo sync (runs overnight).<br>
<br>
The "build" part is: cd $APSP && . build/envsetup.sh && lunch something && make<br>
(runs overnight)<br>
<br>
Then on day 3, you type "emulator" (at the envsetuped prompt) which I've never<br>
gotten to actually work for various reasons, most recently it said:<br>
<br>
emulator: WARNING: encryption is off<br>
Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"<br>
queryCoreProfileSupport: swap interval not found<br>
emulator: ERROR: VkCommonOperations.cpp:496: Failed to create Vulkan instance.<br>
E0616 13:12:24.550453924   31310 socket_utils_common_posix.cc:201] check for<br>
SO_REUSEPORT: {"created":"@1592331144.550415611","description":"SO_REUSEPORT<br>
unavailable on compiling<br>
system","file":"/mnt/tmpfs/src/android/emu-master-dev/external/grpc/src/core/lib/iomgr/socket_utils_common_posix.cc","file_line":169}<br>
emulator: ERROR: AdbHostServer.cpp:102: Unable to connect to adb daemon on port:<br>
5037<br>
<br>
And then pegged one CPU for an hour without ever drawing anything into the black<br>
rectangle.<br>
<br>
But if it DID work then presumably I'd adb shell into it somehow and work out<br>
how to run the test in there?<br>
<br>
>> Lovely. This thing really really REALLY cannot count. And at this point it's<br>
>> gonna be eating all 4 processors through dinner.<br>
>><br>
>> (I'd kill it and restart it with taskset, but I'm not sure how to "make clean"<br>
>> and I am that guy who hits every weird dependency bug from incomplete partial<br>
>> builds pretty much every time...)<br>
> <br>
> rm -rf out/<br>
<br>
Cool. Exactly what I was looking for.<br>
<br>
>>> in the Dijkstra sense (page 16 of<br>
>>> <a href="http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF" rel="noreferrer" target="_blank">http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF</a>), sure.<br>
>><br>
>> In the "I add tests for the thing I just noticed was broken all the time" sense too.<br>
> <br>
> i meant to also include a Dawkins "half an eye is better than no eye"<br>
> reference :-)<br>
<br>
Is there some phrase to encapsulate "this guy did interesting things when<br>
younger, then ossified into a loon"? Maybe a reference to Isaac Newton's Alchemy<br>
phase or Linus Pauling's "Vitamin C" phase? (Both of which were Waaaaaay before<br>
Bill Joy, Eric Raymond, J.K. Rowling, and Orson Scott Card did their swan dives.<br>
It's sad: I still occasionally want to link to 1990's dilbert comics that<br>
illustrates some point or other really well, but "Current Dude is Way Past His<br>
Sell-By Date" kinda blunts the impact...)<br>
<br>
(Yes I know about Death of the Author. It's adjacent, but not _quite_ the same<br>
thing? Sigh, another reason we need humanities departments and not just stem,<br>
"here's what tumblr and tvtropes have to say on this" isn't authoritative.)<br>
<br>
>> The qemu stuff is intended to let me automate it so I can run it more easily and<br>
>> often, but it doesn't help with the MacOS stuff because Apple went out of their<br>
>> way to stop MacOS from running under qemu because proprietary and tied to a<br>
>> hardware dongle in a keyboard controller.<br>
> <br>
> yeah, for my money the "we'll check you can still build on macos"<br>
> alone is worth it, macos being such a pain in the ass to deal with<br>
> otherwise.<br>
<br>
Indeed, but that provides regression testing without a development environment.<br>
If it finds a bug on macos, what do I _do_ about it?<br>
<br>
(I still have a todo item to dig into that ps library and try to do a<br>
portability.c to fill out at least _some_ of the ps fields, and I can come up<br>
with a freebsd test for that, and in THEORY going from freebsd to macos is like<br>
going from devuan to RHEL. Plenty of breakage but at least related species, and<br>
I've had bsd development environments running under kvm before, and can maybe<br>
poke Ed Maste to help there if I set aside time to work on it... :)<br>
<br>
>>>> And 32 bit argument processing has a known structural limitation (the "truncate<br>
>>>> -s 8G" thing) which I've mentioned here before. I know how to fix it, but the<br>
>>>> fix is intrusive enough I'm not sure it's worth doing?<br>
>>><br>
>>> (i'm much more interested in getting to where we have 64-bit-only,<br>
>>> both to replace the current 64/32 high end and the 32-only low end.)<br>
>><br>
>> I thought Android already mostly gave up 32 bit support (all those old phones<br>
>> and tablets I can't upgrade past Marshmallow), but the embedded space ain't gonna.<br>
> <br>
> L was the first 64/32 release. there has yet to be a 64-only release.<br>
> almost all devices today are 64/32, though very low-end stuff like<br>
> Android Go or watches or whatever are still 32-only.<br>
<br>
I should look at android go. Is that one of the "lunch" targets? (Unfortunately<br>
googling for "android lunch go" hits the fact you named a programming language<br>
go and wrote half your build system in it.)<br>
<br>
> the most recent development is that if you're a 64/32 device, you'll<br>
> get the 64-bit version of an app if the developer has both 64 and 32<br>
> versions (and if you have 32-bit native code, you're now required to<br>
> have the corresponding 64-bit code). but from toybox's perspective,<br>
> 64/32 devices are already 64-only --- there's no 32-bit toybox binary<br>
> lurking there.<br>
<br>
The "make root" stuff should automate 32 bit testing, at least under musl.<br>
<br>
>>> it's not a dependency though. just a convenience. right now, we have<br>
>>> humans doing this, and we can always go back to that if we have to.<br>
>>> but if MS is going to give you free CPU cycles to save a little bit of<br>
>>> human time...<br>
>><br>
>> That would be the "embrace" part, yes. First one's free, don't worry it's<br>
>> harmless you won't get hooked.<br>
> <br>
> i think the stated intent is to get the next generation of startups<br>
> hooked --- learn to code using github for open source stuff, why not<br>
> use the paid version when you start you company? (i'm personally<br>
> looking forward to the web editor they've talked about, if it's<br>
> anything close to Visual Studio Code --- which it ought to be, given<br>
> that that's just Javascript.)<br>
<br>
I'm aware they have a new CEO, but their core business has been monopoly<br>
leverage bundling for 40 years before that. (Right from the start with Ed<br>
Roberts that's what they were trying to establish, and Roberts got so badly<br>
screwed over by them he sold MITS in 1977 and went to med school. They got the<br>
IBM PC contract because they were the "standard" 8-bit BASIC, because Bill's<br>
mother was on the board of directors of the Red Cross with IBM's CEO, because<br>
Gates lied to Kildall about what time he'd set up the meeting with IBM at...)<br>
<br>
Ahem. Computer history hobby = I researched how this sausage was made at some<br>
length.<br>
<br>
>>>> Adding a .github subdirectory to the source would be a policy change. I'm happy<br>
>>>> with a fork doing it, but am uncomfortable putting it in the main repo. (Not<br>
>>>> fatally uncomfortable, but... ergh?)<br>
>>><br>
>>> but if it's in a fork, we don't get the benefit. that's basically back<br>
>>> to humans doing something that's a job for a computer...<br>
>><br>
>> I "git push" from the command line and don't look at the at the web gui for days<br>
>> if not weeks at a time. What does the output of this look like? (Yet more email?)<br>
> <br>
> i don't know that either. one thing i do know from other open source<br>
> projects on github is pull requests can be automatically built and<br>
> tested. that's pretty cool for both parties.<br>
<br>
Yeah, JCI was paying for proprietary github when I did a contract there in 2018.<br>
(And Jira. And whatever IBM's calling Rational Rose this decade.) Every pull<br>
request build failed the entire time I was there, it only ever built right when<br>
merged into mainline. I asked an admin why once, and I think the answer involved<br>
Jenkins running containers in a container and the build's source pull from<br>
upstream repos getting rate limited so there was a local mirror on the wrong<br>
subnet of the intranet?<br>
<br>
It's been a while. I think that admin fixed it by disabling the pull builds so<br>
at least we didn't have to kill 'em to get the real build started faster. It<br>
went in the "not my problem" bucket and I moved on...<br>
<br>
Presumably Microsoft Github still works until all the people who worked at<br>
github when Microsoft acquired them quit. That was the classic pattern:<br>
<br>
<a href="https://web.archive.org/web/19991013145536/http://www.pbs.org/cringely/pulpit/pulpit19990826.html" rel="noreferrer" target="_blank">https://web.archive.org/web/19991013145536/http://www.pbs.org/cringely/pulpit/pulpit19990826.html</a><br>
<br>
But who knows, maybe Microsoft is a different company now than it consistently<br>
was in its entire history before the current CEO started in 2014.<br>
<br>
Rob<br>
</blockquote></div>