01:56airlied: skeggsb, agd5f : just cc'ed yoo on a pci link speed email
01:59skeggsb: airlied: i have no idea what the real pmu ucode does there these days, but it wouldn't shock me if we did need some kind of opt-out
02:00imirkin: airlied: karol has done lots of investigation on all the pcie link stuff
02:05airlied: imirkin: good point, cc'ed as well
08:24MrCooper: imirkin: please don't push directly to Mesa master anymore; use MRs and merge them with Marge
08:36eric_engestrom: MrCooper: is it time to lock Mesa and disallow direct push?
08:36eric_engestrom: I think it is :)
08:37MrCooper: I'd be in favour of that
08:50MrCooper: fun fact from https://gitlab.freedesktop.org/mesa/mesa/pipelines/charts : there were 363 successful CI pipelines in the main Mesa project in January, exactly the same as in June and August 2019
09:53hakzsam: MrCooper: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1530360 no llvm-9-dev package with testing looks like
09:55MrCooper: you haven't actually switched to testing, see my latest comment
10:09hakzsam: MrCooper: I assume we want to replace llvm-8-dev by llvm-9-dev in the arm build image?
10:09hakzsam: I mean, not adding
10:32hakzsam: MrCooper: interesting failure https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1530792
10:34MrCooper: looks like libdrm-dev needs to be installed for building dEQP; maybe it was pulled in by something else before
10:35MrCooper: actually, it'll be needed for the Mesa build jobs as well
10:35hakzsam: not sure how it worked before
11:13MrCooper: hakzsam: it was probably pulled in by other packages in buster
11:15hakzsam: MrCooper: oh I didn't replaced buster by testing in the arm test image
12:47hakzsam: MrCooper: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1531671 hmm?
13:06MrCooper: hakzsam: looks like python3-setuptools needs to be installed as well
13:12MrCooper: BTW, it's not 2019 anymore :)
13:13ccr: the future is now.
13:14hakzsam: MrCooper: right :)
14:04benjiG: hi all, does anyone else has notice issues while retrieving patches for patchwork ? It seems that it doesn't add the link tag
14:16hakzsam: MrCooper: making progress https://gitlab.freedesktop.org/hakzsam/mesa/pipelines/104272
14:18imirkin_: MrCooper: i can just mail patches then. i have no interest in dealing with MR's. [or maybe find other places to invest time in]
14:18MrCooper: mailing patches won't do anything without somebody making an MR for them
14:18imirkin_: yeah i know
14:19MrCooper: hakzsam: looks like some dEQP tests are missing, maybe it still needs more dependencies?
14:25hakzsam: I need to figure out which ones
15:23imirkin_: MrCooper: btw, what problem did my push cause?
15:25MrCooper: who said it caused a problem? The issue is that it's not the current established procedure, which has safeguards to catch various problems, among other benefits from MRs
15:25imirkin_: i thought you implied it. my bad.
15:26MrCooper: it would have wasted some CI resources if there were any MRs in Marge's queue
15:28imirkin_: there's been a lot of unilateral "established procedure" changes of late =/
15:29imirkin_: anyways, since i generally work at times when most people don't, shouldn't really affect much i guess
15:30MrCooper: unilateral? All change were reviewed before merging
15:31imirkin_: i don't remember seeing a discussion about requiring MR's
15:32MrCooper: what shouldn't affect much? I hope you're not implying you intend to continue pushing directly
15:32imirkin_: i was implying that, yes.
15:33MrCooper: keep in mind that push access is not a right but a privilege to be used responsibly
15:33imirkin_: i feel like i do that.
15:33imirkin_: [use it responsibly]
15:33MrCooper: the CI pipeline can only effectively catch problems if MRs are used for everything
15:34imirkin_: the CI pipline certainly won't catch anything in nouveau commits - there's no hardware tests done afaik
15:35imirkin_: [on nouveau, that is. i know some other hardware is hooked up.]
15:35MrCooper: it would catch compile failures at least
15:35imirkin_: not sure i've ever pushed one of those... seems exceedingly rare at best.
15:36MrCooper: look, everyone can come up with excuses like that
15:36imirkin_: (except the times when i knew i was likely to have compile failures, like when i was updating boolean -> bool -- CI was very useful then)
15:36MrCooper: everybody else has no problem following the procedure
15:37MrCooper: what makes you so special?
15:37imirkin_: if the community votes to require MR's, i certainly won't push directly
15:37imirkin_: i've seen no such thing thus far. perhaps i missed it.
15:38MrCooper: the community has voted de facto if nothing else
15:38imirkin_: i remember a long discussion about allowing MR's - people seemed in favor. nothing about requiring them.
16:34dcbaker: kisak: sorry I didn't notice that before, I've pulled it into the branch again. Sorry for all the mess in 19.3.3
16:36kisak: cool thanks, it just looked like it was trying to fall through the cracks.
17:03dcbaker: kisak: thanks, I've had a really nasty cold the last two weeks and a lot of things are slipping through the cracks :/
17:50Venemo: dcbaker: speedy recovery :)
17:51dcbaker: Venemo: thanks!
17:53Venemo: imirkin: just out of curiousity, what is it about MRs that you don't like?
18:20imirkin_: Venemo: gitlab ui ... logging in, dealing with the slowness, etc
18:20imirkin_: Venemo: i've totally unsubscribed from gitlab (i.e. configured it to not send me notifications)
18:21robclark: I've not tried it myself, but supposedly you can do all the gitlab things from cmdline using web api..
18:24Venemo: imirkin_: for me, I basically push my stuff to my branch, git gives me a URL, I clickety click and there is the MR.
18:26imirkin_: yeah, but i'm not normally logged into gitlab
18:26imirkin_: and i have the stupid 2fa thing set up, probably shouldn't have done that
18:28imirkin_: and i dislike gitlab because it's a closed/gated community, vs open mailing list.
18:43Kayden: I don't use 2fa, and generally don't have to repeatedly log in
18:44Kayden: I also don't see how it's a closed/gated community. Almost everything is publicly visible without logging in. Accounts are free and only require an email address.
18:44Kayden: if you're just wanting to follow what's going on as a lurker, it's a lot easier to go to a website and browse than it is to sign up for a list, set up mail filters, etc
18:45Kayden: in the old setup, if you wanted to file a bug, you'd have to create a special FDO bugzilla account just to do that
18:46Kayden: now you can either make a gitlab account, or sign in with github, gitlab.com, your gmail account, or even twitter
18:46Kayden: so you may not even have to make an extra account just to participate anymore
18:46emersion: you still need an account to submit patches
18:47emersion: it's possible to make it so people don't have to create an account to participate in the bug tracker
18:47Kayden: we have never once done that, however
18:47Kayden: as far as I'm aware
18:47emersion: yeah, i've only seen this in other communities
18:48Kayden: there are a lot more bug reporters than code contributors, so I think if we required an account to file or comment on bugs, requiring one for contributions is not really prohibitive
18:48Kayden: and I've seen a lot of merge requests from new people still
18:48Kayden: (it marks first contributions with a *1*)
18:49emersion: i've submitted a patch on the ML previously, and submitting it on GitLab marked the MR with the *1*
18:49emersion: so it's not a 100% reliable indicator
18:49Kayden: that's fair
18:49Kayden: technically to sign up for the mailing list you supply an email address and create a password (or else it randomly generates one)
18:50emersion: yeah, the current ML system isn't great
18:50Kayden: whereas to sign up for gitlab you....supply an email address and create a password
18:50emersion: Ml archives are also a pain to use
18:50Kayden: I just don't think it's materially different in terms of openness
18:50emersion: … and you can't send messages without registering on the ML (or you need to wait for approval?)
19:00Venemo: I guess what I wanted to say is, would it be possible for you to consider giving a chance to gitlab for like a couple of weeks and maybe see if it really is as terrible as you think imirkin_ ? maybe it's not so bad after all
19:12vsyrjala: could be almost usable if you're willing to write your own tools for it
19:59imirkin_: Venemo: i'm a part-time contributor. the point is i don't have it up 100% of the time. so every time i have to deal with it, it's a drag.
20:00imirkin_: Kayden: ML is a single central place for all activity. with gitlab, there's no good way to see everything, looking at diffs is slow (compared to email, or cgit, both of which are blazingly fast), and if you accidentally don't subscribe to some obscure thing, you end up missing stuff.
20:08airlied:clicked on a star and got subscribed to everything
20:13krh: https://gitlab.freedesktop.org/mesa/mesa/merge_requests is a single central place for all activity
20:13krh: more structure and a lot less lossy than ML
21:22airlied: vsyrjala: there seems to be some issue with the build bug on and cea modes
21:23airlied: "05:28 < aegl> Is my gcc 4.6 just too old to figure out BUILD_BUG_ON(cea_mode_for_vic(8)->vtotal != 262) (drivers/gpu/drm/drm_edid.c)?
21:23airlied: 05:30 < aegl> ia64 build is broken. git bisect says: f7655d42fcee ("drm/edid: Add CTA-861-G modes with VIC >= 193")
21:23airlied: 07:14 < rdd> aegl, similar happens on x86_64 with newer gcc
21:23airlied: 07:19 < rdd> and kernel build bot reported it last week
23:03vsyrjala: airlied: yeah, someone also sent a +always_inline patch privately. asked them to post to the list
23:04vsyrjala:wants a real constexpr
23:05HdkR: I've heard other people wanting that as well