daniels changed the topic of #freedesktop to: https://www.freedesktop.org infrastructure and online services || for questions about freedesktop.org projects, please see each project's contact || for discussions about specifications, please use https://gitlab.freedesktop.org/xdg or xdg@lists.freedesktop.org
aswar002_ has quit []
aswar002 has joined #freedesktop
shashanks_ has joined #freedesktop
shashanks__ has quit [Ping timeout: 480 seconds]
<robclark>
daniels: is "we broke patchwork beyond repair" reason enough to switch to gitlab MRs?
* robclark
ducks
<karolherbst>
just enable it for drm-misc and move on :P
<karolherbst>
there is literally no reason not to, is there?
<daniels>
the main reason is that the repo isn’t there, which was going to be another Christmas project
privacy has quit [Quit: Leaving]
<robclark>
IIRC there were two things to solve for kernel trees to use gitlab MRs.. (1) how to deal with drive-by patches and treewide patchsets from non gitlab users, and (2) how to deal with committer + sob to follow kernels patch custody rules.. the later could be dealt with if gitlab (or margebot) added sob and used committer email/name of whoever clicked "Merge" or assigned to margebot (with appropriate controls on who can do
<robclark>
that).. the former, I don't have a good idea about
hololeap has quit [Quit: Bye]
hololeap has joined #freedesktop
<karolherbst>
ohh I see.. nobody migrated the repo yet :')
<karolherbst>
robclark: 1. some maintainer just picks them and submits an MR or pushes them directly (which we don't have to disallow at first anyway) 2. I actually wrote a dim patch for that
<karolherbst>
but we can't really automate that process anyway
<karolherbst>
and as in mesa, we can always require contributors or maintainers to add those before merging
<karolherbst>
that dim patch simply edits the commits and pushes
<karolherbst>
to make it less painful... I also wanted to allow for some interactive editing there, so you can pick which patches gets which tag, but that's kinda uhh... more involved
<karolherbst>
anyway
<karolherbst>
the first and the only first step is to just allow merge requests with manual tagging after the repo was migrated. And change nothing else. git cli pushes and everything is still allowed. We should simply also allow merge requests on top
<robclark>
yeah, for the "some maintainer just picks them" we've been leaning heavily on patchwork.. but maybe if dim doesn't rely on patchwork we could use that
<karolherbst>
yeah.. my dim patch just uses the gitlab web API and `jq`
<karolherbst>
we can pimp it and add all the fancy things we want. The issue is just what happens if multiple review in parallel and other funky things
<karolherbst>
alternatively.. we have a both, but that the interfaces gets ... interesting
<karolherbst>
we could also have a dim script which comments on the MR in a language a bot would understand, which then adds the tags :D
jarthur has quit [Ping timeout: 480 seconds]
Leopold___ has joined #freedesktop
Leopold_ has quit [Ping timeout: 480 seconds]
larunbe has joined #freedesktop
jarthur has joined #freedesktop
bmodem has joined #freedesktop
thaytan has joined #freedesktop
marcheu has joined #freedesktop
privacy has joined #freedesktop
ximion has quit [Quit: Detached from the Matrix]
sima has joined #freedesktop
i-garrison has quit [Remote host closed the connection]
i-garrison has joined #freedesktop
<lumag>
daniels, oh, my. that's kind of bad Christmas self-present :-( I condole with you :-(
<lumag>
Maybe we can switch to patchwork.kernel.org?
<lumag>
But it is likely that the major issue is the existing data :-(
<lumag>
One bonus side of using pw.k.o is that b4 directly works with it.
<vsyrjala>
from my pov loss of ci is the really serious problem here. i915 development is on ice until that can be brought back
<vsyrjala>
or do we have enough functionality there that it somehow works?
AbleBacon has quit [Read error: Connection reset by peer]
i509vcb has quit [Quit: Connection closed for inactivity]
mczaplin has joined #freedesktop
<pinchartl>
is ~10GB acceptable for a container image on the shared runners ?
<pinchartl>
(that's the lowest we could possibly achieve, coming from an initial 231GB, currently at 80GB)
<pinchartl>
(and currently *not* running on the shared runners)
<daniels>
lumag: I’m happy to supply a database dump if that helps
<daniels>
pinchartl: I think that’s probably fine yeah
<pinchartl>
daniels: nice :-)
<pinchartl>
if it's not, we'll keep running it in our own runner
<pinchartl>
it's "just" more maintenance
mvlad has joined #freedesktop
bmodem has quit [Ping timeout: 480 seconds]
<jani>
daniels: from our pov the only reasonable move is to get the existing patchwork back asap. there's just no way we could switch to any other patchwork without notice and some migration period
<daniels>
jani: ooi I wonder if it might be quicker to rush it back as an internal or 01.org service if I can give you the db dump?
<emersion>
can we put it in an outdated container?
<jani>
daniels: still requires finding someone with the skills to set it up
<emersion>
how does the membership website run even? do we have a docker in regular host?
<jani>
which could take a while considering most folks who were originally involved in it are no longer around
<daniels>
emersion: nope, just uwsgi directly in the host, which is why it broke
<daniels>
we could put it in an ancient container perhaps yeah
<emersion>
where is it hosted? can't find the repo
<emersion>
the patchwork varant we use
<emersion>
variant*
<daniels>
emersion: the repo is gitlab/patchwork-fdo/patchwork-fdo, but what ran on emeril was much much older
<emersion>
oh it has a dockerfile even
<emersion>
erm, it seems like it's one to run tests
<emersion>
daniels: hm would you be more comfortable keeping that old version?
<emersion>
can you find the sha of that version?
<emersion>
i can't SSH in there
pkira has joined #freedesktop
privacy has quit [Quit: Leaving]
shashanks has joined #freedesktop
shashanks_ has quit [Ping timeout: 480 seconds]
psychon has quit [Remote host closed the connection]
<pkira>
I have some old documenation that says that mupuf has access to emeril.freedesktop.org, it also contains some info about deployment: https://paste.debian.net/1301631/
<pkira>
Last update of docs was about 3years ago..
peelz has quit [Read error: Connection reset by peer]
peelz has joined #freedesktop
psychon has joined #freedesktop
<daniels>
pkira: yep, that’s all still accurate
<daniels>
emersion: yeah, thinking about it we can use xorg_membership as a template since that’s also Django 3.2, then I can give you access to emeril as well as push all the local changes that are in there?
<emersion>
yeah, maybe to a "production" branch or something
<emersion>
assuming there are no secrets in there
<pkira>
emersion: btw I'll be happy to help if needed
<daniels>
pkira: upgrading the current repo to Django 4.2 would be amazing please, because 3.2 is EOL in April
<pkira>
daniels: sure, you can count on me
<emersion>
how "bad" are the changes between prod and git repo?
<mupuf>
You talking about xorg membership? It's always up to date, it gets deployed after every push to master
<pinchartl>
if you build the container image as part of the pipeline, and need scripts from the CI config repo to build that image, you will also need to pull them manually in FDO_DISTRIBUTION_EXEC
<pinchartl>
although I *think* a before_script would work there too
<pinchartl>
I haven't tried
<pinchartl>
other than that, it works quite fine
<pinchartl>
it also has a nice upside
<pinchartl>
during development of the test scripts, if a job fails
<jani>
somehow the gitlab yml files always seem more verbose and complicated than the github yml ones... :/
<pinchartl>
you can modify the script, push it to the -ci repository, which will not trigger a full CI pipeline
<pinchartl>
and just click the retry button for the failed job
<pinchartl>
which will re-run with the same .gitlab-ci.yml than before, *but*, because it's a new run, it will download the new script from the -ci tree
<jani>
...and the main repo won't be filled with "retry", "okay this time for real", "dammit", etc. commits when debugging the ci pipeline :p
<pinchartl>
if you make changes to the .yml file, though, you need to run a new pipeline on the main repo
<pinchartl>
as retrying a job uses the .yml that the job was created by, it won't get the updated one
<pinchartl>
if you have any question, let me know
<pinchartl>
this is rather fresh in my memory
* pinchartl
is thinking about making a talk about all this in a conference next year
<jani>
so the external workflow ymls are configured somewhere in the web ui of the main repo?
<pinchartl>
I have it set to gitlab-ci.yml@pinchartl/libcamera-ci
<jani>
I think something like this would be a requirement for any kernel work, because I don't think we really want to put them in the main kernel repo
<pinchartl>
it can also be any arbitrary http url
<pinchartl>
agreed
<pinchartl>
even drivers/gpu/drm/ci/ is already too much if you ask me :-)
<pinchartl>
it does have a gitlab-ci.yml file though...
<jani>
well, yes, but I'm also not going to stand in the way if someone else is doing something useful ;)
<pinchartl>
I'm not sure how up-to-date that file is though
<pinchartl>
FDO_UPSTREAM_REPO: helen.fornazier/linux # The repo where the git-archive daily runs
<pinchartl>
sounds like something in the drm/ namespace of fd.o would be better :-)
<__tim>
bentiss, AAAA record for annarchy is still there it seems (or there again)
<bentiss>
__tim: yes, it was working yesterday, so I re-enabled all the IPv6 we had, but now it's not :(
<bentiss>
daniels: have you made config changes to annarchy? the IPv6 is not bound anymore
<bentiss>
(or Mithrandir ^^ FWIW)
<Mithrandir>
Nope, haven't done anything there in a while
<bentiss>
k, thanks
egbert is now known as Guest11173
egbert has joined #freedesktop
Guest11173 has quit [Ping timeout: 480 seconds]
<daniels>
bentiss: nope, nothing, but it comes from DHCP so maybe we just need to get a new lease?
<bentiss>
daniels: maybe (I'm not root on this one, nor on kemper who doesn't seem to have IPv6 connectivity either)
<daniels>
bentiss: I just added it by hand and it appears to work now
<bentiss>
great :)
<daniels>
and same for kemper
<demarchi>
jani: regarding using a MR based workflow.... in the early days of xe, I've setup the xe repo to use xe/ci repo, where the yaml was maintained... the yaml is still there. CI also implemented the logic to work with it, but that has been retired a long time ago. Switching back to it would be hard without any planning
<bentiss>
daniels: thanks... and looking through the db, it seems that at least emeril also has issues
<daniels>
define 'issues'?
<daniels>
(you should have root on kemper and annarchy now btw)
<bentiss>
daniels: emeril and raostbeef are not answering to ping6 ;)
<bentiss>
(those are the last 2 I can see that we export on fd.o)
<daniels>
I just brought the roastbeef VM down completely
bmodem has joined #freedesktop
<bentiss>
that might explain :)
gert31 has joined #freedesktop
<bentiss>
emeril is back, I assume you fixed it
<daniels>
yeah
<daniels>
and you've now got root on emeril + lyle + teodor
<daniels>
(emeril is pw.fd.o, lyle/teodor are the two VM hosts)
<bentiss>
you have no idea how much I am happier now :)
Leopold___ has quit [Remote host closed the connection]
<daniels>
thanks, done that and archived it as well
<emersion>
sounds like your rewrite is better than mine
<daniels>
emersion: I haven't looked at uWSGI yet, I mostly just tried to untangle the environments and get the tests consistently passing
<daniels>
emersion: sorry if we've duplicated work here - I'd thought you were racing to the hack that could work quickly and I was down in the weeds for the thing which would take longer :\
<emersion>
oh no no worries at all
AnuthaDev has joined #freedesktop
<daniels>
ok, so I guess the next two things are a) exposing postgres into the container (and also remembering htf to do postgres db upgrades), and b) making uwsgi work
<daniels>
(and figuring out how I've broken the settings in prod)
<emersion>
daniels: any way to test the deploy task before we merge?
<emersion>
where are SSH_* coming from?
<emersion>
not sure we really need to ship nginx in the container, but maybe it makes things easer
<emersion>
easier
<emersion>
when i tried, i got uwsgi running, but couldn't find the right --module arg