08:09 <Odkrain> hey

08:40 <kxkamil2> could someone help with info about mailing list for Libva on https://lists.freedesktop.org/mailman/listinfo/

08:40 <kxkamil2> there is: Moved to: https://lists.01.org/mailman/listinfo/intel-vaapi-media

08:41 <kxkamil2> imho it should be: Video Acceleration API, moved to: https://github.com/intel/libva

17:24 <bentiss> daniels: (or anyone else knowing about how s3.fd.o is used): do we need more than 30 days of expiration of objects in artifacts and mesa-lava? (I'm not adding any policy for tracie-*)

17:27 <daniels> bentiss: nope, both are fine as we assume that storage could vanish at any time, so re-upload if required

17:27 <bentiss> daniels: k, I'll add those 2 policies to reduce s3.fd.o usage (on the new cluster)

17:34 <karolherbst> who is still on ikiwiki and wants a redesign? We have something (check #dri-devel) just wondering if anybody here is interested to get a revamp of their wiki. We could also just update _all_ the wiki at once, but I personally prefer if people would move away from CGI + cgit based deployment and just move to gitlab pages anyway.

17:36 <daniels> fwiw the main thing 'blocking' www.fd.o itself moving is the vast amount of stuff it has - e.g. everyone's release tarballs - so we'd need to start moving those out to something like s3 or gitlab release artifacts project-by-project and set up redirects

17:36 <daniels> I'd recommend starting with any other wiki to build up momentum, or breaking off the sub-wikis into their own pages repos

17:36 <karolherbst> yeah...

17:37 <karolherbst> I think it's fair to keep the tarballs where they are

17:37 <karolherbst> it's just easier to mess up with the wiki if projects use pages for it :)

17:52 <bentiss> daniels: how much data are we speaking of (for the tarballs?)

17:53 <daniels> bentiss: 5.3GB

17:54 <bentiss> daniels: ok, so peanuts to host on s3.fd.o

17:54 <bentiss> it should be easy enough also to tune opa so we can have people upload files themselves

17:54 <daniels> yeah, trivial for s3 but more painful if every wiki page update pushes a 5.3GB zip of artifacts which pages has to try to chew through :P

17:55 <bentiss> 5.3 GB is for the entire server or just mesa?

17:55 <daniels> bentiss: nope, that's just www.fd.o

17:55 <daniels> which has a totally random collection of stuff

17:55 <daniels> fontconfig, pulseaudio, etc

17:56 <daniels> /srv/mesa.freedesktop.org/archive/ on annarchy is 12GB ...

17:57 <bentiss> but I mean we should have the old tarballs hosted on s3.fd.o, so we can remove the need for annarchy and then have the frontends on gitlab pages?

17:58 <bentiss> so we won't push 5.3 GB per page deployment, no?

17:58 <daniels> yeah, that would be fantastic

17:58 <daniels> especially since I have nfi how well backed up the old servers are these days

17:59 <bentiss> daniels: well, s3.fd.o is not a lot more backed up, just more resilient as it's spread on 3 machines

18:01 <bentiss> anyway, something to work on later, as I still have a couple of bits to terminate on the old cluster (down to s3.fd.o which should be good tomorrow-ish, harbor.fd.o and the pages from the root level DNS)

18:05 <daniels> backups: not great

18:05 <daniels> cornelius# tail -5 log

18:05 <daniels> 15-Nov 18:04 bacula-dir JobId 0: Fatal error: Version error for database "bacula". Wanted 16, got 15

18:05 <daniels> 15-Nov 18:04 bacula-dir JobId 0: Fatal error: Could not open Catalog "MyCatalog", database "bacula".

18:05 <daniels> 15-Nov 18:04 bacula-dir JobId 0: Fatal error: Version error for database "bacula". Wanted 16, got 15

18:05 <daniels> 15-Nov 18:04 bacula-dir ERROR TERMINATION

18:05 <daniels> Please correct configuration file: /etc/bacula/bacula-dir.conf

18:06 <bentiss> mhh.. looks like quite some wikis have been spammed too -> ldtp.freedesktop.org/moin/data.pre160/pages/atlantic(2d)city(2d)ballys(2d)casino(2d)131(2f)MoinEditorBackup or libdlo.freedesktop.org/moin/data/pages/Lease_A_Dumpster_When_Cleaning_Out_Your_Parent_s_Residence/cache

18:10 <karolherbst> how did this even happen?

18:10 <bentiss> karolherbst: that was just a sample of 2 there are a lot of them

18:11 <karolherbst> yeah sure... but I mean, it's not in git, so maybe a vuln in ikiwiki or the web server or something funky?

18:11 <daniels> nah, that was when the wikis were in moinmoin, pre-cgit, and iirc open registration

18:11 <karolherbst> I see

18:12 <daniels> nice: SMART Health Status: DATA CHANNEL IMPENDING FAILURE DATA ERROR RATE TOO HIGH [asc=5d, ascq=32]

18:12 <bentiss> oops...

18:12 <daniels> (luckily only one disk out of 8, and it's RAID so we can lose one)

18:12 <karolherbst> RIP

18:12 <daniels> have pinged keithp to arrange a new one

18:12 <bentiss> we probably better get those data out on s3.fd.o sooner than later

18:13 <daniels> that being said, most of the disks were manufactured in 2010, so the fact only one has died is pretty astonishing

18:13 <daniels> (istr the last time we needed to replace one was pre-COVID)

18:13 <daniels> bentiss: well yeah, everything on the old machines needs to not be there ...

18:14 <daniels> emersion: did you ever get anywhere with gabe2 btw?

18:14 <emersion> hm

18:14 <emersion> I installed mailman3

18:14 <emersion> imported dri-devel archives

18:14 <emersion> then stopped

18:14 <emersion> partly because I'm a bit disappointed with mailman3

18:15 <daniels> only a bit? :P

18:15 <emersion> partly because I need to figure out the postfix stuff

18:15 <emersion> ;_;

18:15 <daniels> lmk if I can help with Postfix at all; I think I'm at fault for almost all of the bizzare configuration that's grown on there through the last 19 years

18:16 <emersion> okay, I'll try to have a look again

18:16 <daniels> so happy to either help shed light on it, or try to improve it as penance

18:16 <emersion> then we need to find a good mailing list to migrate first, low traffic but still used a bit

18:16 <emersion> then iron out any issues

18:16 <emersion> then migrate more...

18:17 <karolherbst> just start with dri-devel, people would notice any problems quickly (or not)

18:17 <karolherbst> :D

18:17 <karolherbst> though

18:17 <karolherbst> you can migrate the nouveau one first I think

18:17 <karolherbst> it has quite low traffic, but is still used

18:17 <emersion> ack

18:17 <emersion> wayland-devel would be fine too probably

18:18 <daniels> yeah, it would probably make sense to use us as a guinea pig, given the near-100% correlation of list admins and people with root on fd.o

18:21 <emersion> thanks for bugging me about this btw

18:22 <emersion> pinging me continuously about something is a good way to make me do it

18:23 <daniels> emersion: I can relate ...

18:27 <daniels> bentiss: fwiw, all the moin/data.pre160 dirs can be nuked - those were when we upgraded from moinmoin 1.whatever to 1.60, which required a migration step - we kept the old data for posterity, but 13 years on I think it's safe to say we probably won't need it