aswan: hello, is this something that might be caused by your push?

andrei_ciure|sheriffduty: i don't see anything there?

oh you backed it out

aswan: yeah, I updated the bug with the failure

okay, looking, thanks

I'll push a hotfix to that issue on autoland

rebase failure :(

will it take more than 5 minutes?

no

ok

:)

oh, it will, because I have no way to push an hotfix to autoland

easier to backout then?

:)

sure :)

done

thanks!

ok, I did a try push this time :)

:)

Gijs: ping

:janv could you please take a look treeherder.mozilla.org/#/jobs?repo=…ba47b946e7982&selectedJob=226760906

looking

oh sorry

opoprus, can you back it out please ?

yes

bogdan_tara: it was 3am, sorry. What was up?

Gijs: I think it was somthing about this push

Which he backouted out here: autoland/37d85347dd8c41f4e7ad33f89d611c6064f0ebed

dluca|sheriffduty: that's what I thought initially but the backout predated the IRC ping by 90 minutes

so now I dunno? :)

Gijs: Don't know either

bbouvier: hi, could you please take a look: treeherder.mozilla.org/#/jobs?repo=…c0bec6ed1f22&selectedJob=226777719?

huh, yes

sorry about this :/

ccoroiu|sheriffduty, it's a missing header, can i land a fix?

sur

e

will build locally and make sure it doesn't happen

ccoroiu|sheriffduty, do you know if this build is a debug or non-debug build?

Linux x64 debug

ccoroiu|sheriffduty, i've got a fix, checking locally

okay, thank you

bbouvier: it is still failing treeherder.mozilla.org/#/jobs?repo=…2fefd17c01e31&selectedJob=226786844

looking

sorry

thank you

i can't reproduce the non-unified build locally, the build system changed :/

ok i actually can, it's just more difficult than before\

ccoroiu|sheriffduty, here we go, i tried locally and could reproduce and make sure it was fine...

also opened bug 1525876 to search for ways to make local non-unified builds easier

bbouvier: it's green now, thank you for the fix

glandium: here's the config.log line for arc4random_buf for that android build: pastebin.com/raw/BQDZLCvM

glandium: no errors there

glandium: allow-shlib-undefined?

ccoroiu|sheriffduty, yw, thank you for letting me know about these failures

bbouvier: np

bz++

peterv: most likely

peterv: seems like it should be removed from the global LDFLAGS, and possibly added in a more targeted way, where required. (if it's actually still required)

peterv: it's been there for 8.5 years, it might be completely useless now

glandium: :-)

glandium: trying a build without

peterv: check the configure output :)

peterv: you should remove config.cache first, btw

(if you don't clobber)

bobowen: that sort of twiddling of windows-internal structures seems to be de rigueur amongst windows programmers

glandium: weird, configure check still seems to have passed

peterv: and it doesn't say "(cached)"?

glandium: I had clobbered

froydnj: yeah, can't say I like it much, but I think it's the best/simplest option

nbp: Hi, are you around?

dvarga|sheriffduty: yes

can you take a look at: treeherder.mozilla.org/#/jobs?repo=…f8cab1a50b1626d36a85eace9ae817f38ee

bobowen: I think I agree with you

dvarga|sheriffduty: don't tell me that a 1 line change broke the test suite?

glandium: yeah, didn't help: HAVE_ARC4RANDOM_BUF is defined but "ld: error: hidden symbol 'arc4random_buf' is not defined locally"

nbp: something it did broke the tests :)

dvarga|sheriffduty: ok :) This should be fine to back it out as this is a low priority.

ok, doing it now

dvarga|sheriffduty: The test case are not expecting to see a [Learn More] link in the expected result.

I guess

do you want do a fix or backout?

peterv: so, I installed ndk r15c... and arc4random_buf *is* there

dvarga|sheriffduty: backout, I have no idea how much time it will take.

peterv: which means the problem is not HAVE_ARC4RANDOM_BUF being defined when it shouldn't be

nbp: ok

although the shlib-undefined thing probably breaks detecting things that *are* missing

glandium: well, don't know what's going on then

glandium: I'm open to a different fix, but I don't know what that would be

peterv: so, the problem is that it is in libc.so, but it's not in stdlib.h until android-21

so the problem is still on the configure end

because the ndk is fucked up

I gathered that much

:-)

peterv: ok, autoconf 2.13 doesn't have a pre-existing test for that. Newer versions of autoconf have AC_CHECK_DECL.

peterv: I'll look at it tomorrow

glandium: I'll obsolete the patch for now then

peterv: done already

flod: github.com/mozilla/addons-frontend

bbouvier: Hi, can you please take a look:

treeherder.mozilla.org/#/jobs?repo=…0s%28tp6-5%29&selectedJob=226839541 , is a highly frequent failure

looking

opoprus, 99% sure it's not related to my push

TheOne: github.com/mozilla/addons-frontend/…mo/pages/LanguageTools/index.js#L41

flod: github.com/mozilla/addons-frontend/…4f5b00edaf3ab/src/core/languages.js

so.. I was reading news.ycombinator.com/item?id=19055312 the other day

and, well, it's awfully easy to blame the web developers

But firefox has some annoying quirks too

like this site sets color in .class { } rule - if I inspect and set background-color it gets ignored

from past experience firefox is super finicky about how specific rules for form fields have to be

Er. sorry this site pkginfo.devuan.org

it's kind of annoying really. firefox will inherit color without inheriting background-color. I kinda sympathise for Chrome's "effit, we're gonna ignore dark themes"

and yes, I realise firefox is just honouring spec 😃

where would I go to ask questions on Wasm?

SneakyNachos: the #wasm channel, perhaps

emilio: what is your preferred way to separate code, multiple differentials or just pushing to history so you can use the tool?

argh

So when I try to run mochitests locally in Firefox in a debug build....

They just hang at the "setting up web server" stage

opt works fine....

(this is new since yesterday; this worked fine before!)

Is this something known?

My artifact build from this morning’s (GMT) pull works fine

artifact debug build?

mach mochitest --headless docshell/test/navigation/test_triggeringprincipal_frame_nav.html

is the exact command I am running

(well, close enough; there's some env vars to point to the objdir)

jkt: don't mind much, whatever is easier for you

froydnj: So I added it to the BUILDTIME_LICENSE_WHITELIST and still get the "Package fuchsia-cprng has an unreviewed license file: LICENSE" error

jkt: oh, ugh, I see, fuchsia-cprng uses a license file instead of a standard license marker

froydnj: but then so does searchfox.org/mozilla-central/sourc…d_party/rust/fuchsia-zircon/LICENSE

I guess we would have to lie a little bit more and say fuchsia-cprng is a "runtime" package, as you have done

jkt: yes, but searchfox.org/mozilla-central/sourc…y/rust/fuchsia-zircon/Cargo.toml#18

which we consider to take precedence

froydnj: ah I see thanks

froydnj: do you know who I can ping for review for the license?

jkt: I would argue that this change doesn't need license review, since the package isn't actually used

jkt: but I believe mhoye is the person you want to talk to, and you should explain the situation

jkt: why are we pulling it in if it's not used?

bholley: an update to uuid, updates rand which then depends on fuchsia-cprng

bholley: cargo sees it as a dependency, and we have no way to tell cargo "hey, we're never going to use this"

froydnj: so there's some functionality that the rand crate needs from fuchsia-cprng, but only for codepaths we don't use?

bholley: yes

I think in the ideal situation we would submit a patch to rand to make fucshia-cprng an optional dep

that may or may not be tractable

we have this situation today, but the fuchsia crates in question now declare their licenses slightly differently, so we are running into this difficulty

but it's very risky to import some code into m-c, and say "it's ok because we're not using it"

because then somebody else comes along and wants to use it

and they're like "great, it's already in m-c"

even optional deps are still going to get pulled in, because cargo

bholley: yeah I am cagey about that too. Unless we have a way to make cargo not do that

froydnj: wait what, really? cargo vendors stuff for features that aren't used?

"it's ok because we're not using it" is a little more defensible in this case because the crate(s) in question are OS-specific functionality

("aren't used" => aren't activated via the Cargo.toml manifest)

bholley: yes, because cargo has no way of knowing at vendoring time what features you're going to use (and tbf, we compile with different features depending on flags, so we couldn't even declare features up front) or OSes/archs you're going to compile for

bholley: cf alexcrichton/cargo-vendor #70

it's not quite the use case here, but close

froydnj: but shouldn't it at least be able to figure out the maximum set of features that are addressable from the top-level Cargo.toml?

bholley: dependencies don't just depend on features, though

or rather, can be pulled in via target-specific attributes, not only features

sure, but we could could make the target-specific attribute dependent on a feature, I'd think

which would also solve dropbox's use-case

I am not clear on how that would work

fucshia-prng would only get compiled if you had both the fuchsia flags enabled _and_ were on fuchsia

s/flags/feature/

and so if cargo update can statically determine that the fuchsia feature will never be enabled, it can cull the dependency regardless of the eventual target arch

but vendoring can't statically know that you're never going to compile for fuchsia (unless you added something like what dropbox wants, right?)

froydnj: It can if you do what I propose, I think

froydnj: I'm saying make the fuchsia dep conditional on fuchsia_feature && is_fuchsia_target

froydnj: |cargo vendor| can't reason about is_fuchsia_target. But it can reason about fuchsia_feature

bholley: but presumably fuchsia_feature gets automatically set somewhere on is_fuchsia_target?

froydnj: no

froydnj: that would make it redundant

froydnj: I'm saying we provide a way to statically disable fuchsia support

froydnj: via a feature

bholley: sure, I get that part

bholley: it seems like that would require actual fuschia users to always set up the appropriate feature?

froydnj: yes, or it could be a default-on feature

that can be turned off

I'm not saying we necessarily need to fix this for this case, but I do think this is going to come up again

and it might block somebody importing a crate they really want

oh, this has definitely come up several times before, and fuchsia bits have featured in at least one of those discussions

froydnj: ok, I think cargo vendor must already be doing what we want here

froydnj: because crossbeam-channel is an optional dep of the style crate: searchfox.org/mozilla-central/sourc…ervo/components/style/Cargo.toml#33

froydnj: and I don't see it in third_party/rust

froydnj: that matches my intuition / recollection that dependencies behind unreachable feature flags don't get vendored

bholley: huh, indeed

bholley + froydnj I'm wondering if I should file an update bug specifically just for the uuid. I don't know for certain if it's a 100% dependency and then we can document this discussion above.

so the question then becomes how to make the rand crate do what we want, and ideally without having to specify a bunch of no-fuchsia stuff in using crates

and maybe a couple of other crates too

Standard8: it looks like one of my local patches, but now I need to figure out "wtf"

oh

Now why the test harness is not reporting a crash!

myk: 🎉 🎉

lina: inorite?!

hehe

myk: srsly, I'm so excited to start using rkv. and the rust xpcom helpers, too :-) thank you for working on this and getting it over the finish line!

lina: me too, and you bet!

Still the best pun at mozlando

I'll remember "key value proposition" 'til my end of days

chutten: it's great we didn't make a hash of it

I dunno. I like breakfast potatoes.

lina: as a js developer, I Object to that pun.

is there any example of rust code in firefox, that implements an IDL interface, which is used from internal JS (e.g. firefox UI code) ?

dylan: I guess this is as good of a place as any to arrays your objections

KaiE: myk just landed one :-) bugzilla.mozilla.org/1490496 implements an XPIDL interface in Rust that's called from chrome JS

just in time to answer that question!

myk: Is that the first one?

although it's only autolanded, not mozilla-central-ized

lina, great, thanks a lot! myk, is it the first one?

KaiE: hmm, good question; i think it may well be, yes

wow :)

Mossop: yes, i think so; at least i'm unaware of any other

Mossop, KaiE: yes, that looks correct; the only other non-testing code i can find that uses the xpcom crate (which provides the Rust-XPCOM bindings) is MozURL, but that doesn't get exposed to JS, only native code

myk, great, thanks for pioneering!

and it doesn't expose an IDL interface in any case; it just uses the xpcom crate for its refcounting functionality

KaiE: you bet!

it will serve as a helpful example, should have have to use rust for something in thunderbird

KaiE: sure; not that the cowpath still isn't entirely paved; but it should be somewhat easier to traverse, with this example

erm, s/not/note/

I might be able to wait until the cowpath gets trampled more

any dom peer around and willing to volunteer to review a simple webidl change?

KaiE: while you're waiting, want to do a code review? :)

dmajor, hah! I haven't even learned rust yet!

KaiE: I mean my unified build patch :)

dmajor, that sounds large. where is it?

KaiE: two lines ,bugzilla.mozilla.org/1520646#c2

dholbert: unless you're in the middle of an email, i'm happy to shoot a message to FB on our mailing list

miketaylr: thanks!

miketaylr: please do (just filed the bug before entering a meeting)

🦄👍

(that makes for an interesting combination...)

dmajor, sure, sorry for the delay, marking r+. We'll have to make a new release eventually, but there were very few changes, and nobody has aksed for an updated release yet.

dmajor, ok, we haven't released in 5 months, I'll schedule an nspr 4.21 to go together with nss 3.43 in march

mozilla 67

KaiE: great, thanks! I'm not in a super hurry on this, other than clearing it out of my dashboard, but as long as there's some other reason for a release, might as well ride along

the other changes have waited for 4 months, so let's do it hg.mozilla.org/projects/nspr/graph

KaiE: does my mozilla commit access work for NSPR too, or do you need to commit the change for me?

dmajor, I'll do the commit now

ok, thanks

it requires same access privs as nss

What does P3 mean in the necko world? Is that already the bucket for "anything else" or is P4/P5 also used?

miketaylr: thanks for sending the link to the new iconography, too. :D Though: I don't see a 20x20 sized png icon there... we only seem to have huge icons there

(and SVG)

I wonder if we have already-scaled PNG icons available somewhere?

hmmm

i would hope so

(looking at design.firefox.com/photon/visuals/product-identity-assets.html and only seeing giant PNG)

scaling down a 2000x2000 (or whatever it really is) won't end well

yeah

the "Download all" zip link at upper right just has the high-res (and SVG) stuff too

i'll ping bwinton on slack, he'll probably know

miketaylr: thanks

(the response was "use svg" ;P)

tnikkel: want to give feedback to the preliminary patch for imglib notifications, if I manage to upload an updated patch still today

tnikkel: or do you have strong opinions whether we should use separate main thread queue for this stuff or explicitly pulling the notifications when refreshdriver ticks?

is there a globally available `performance` object (for chrome code) that doesn't require a window?

there's code that gets it from the hidden window but I'd like to avoid that

smaug: eh, your method is okay. ideally i think in the refreshdriver would be better, but i won't block on that

tnikkel: I don't have strong opinions. Any reason why you think refreshdriver approach would be better?

felipe: Not really....

smaug: there isn't really a point in sending the notifications any earlier than a refreshdriver tick, the work we do based on the notifications is layout/painting/etc, ie what the refresh driver is for. clears a few more events from the main thread.

tnikkel: yeah, sounds reasonable. Just possibly a bit more work to implement that

smaug: but your patch would improve the situation, and doesn't stop us from doing the refreshdriver later

right

gbrown: do you know what the status of things are now that bug 1496773 has landed? Are there followups that still need to land? Does j.graham's phab revision in that bug still need to be landed?

kwierso: I don't fully understand the status. I'm trying to get some clarity via bug 1501562

today's nightly seems sometimes to irresponsible on mouse events..