[16:51] <Eickmeyer> So uh... who's idea was it to sync glib 2.68 from Experimental right before Beta Freeze? I've got a major regression now because of it.
[16:53] <RikMills> Copied from debian experimental in Primary Archive for Debian GNU/Linux by Sebastien Bacher
[16:56] <RikMills> out of curiosity, what regressed?
[16:57] <Eickmeyer> Ardour. It cannot build on glib 2.68.
[16:58] <Eickmeyer> I've been informed of that by upstream developers.
[16:58] <RikMills> urgh
[16:59] <Eickmeyer> They're getting ready to release 6.7 (archive has 6.5) which can, but we're way too late to be introducing new features.
[16:59] <Eickmeyer> seb128: ^
[17:00] <Eickmeyer> In the meantime, one of the cornerstones of Ubuntu Studio is going to suffer.
[17:01] <Eickmeyer> Found out from doko's email.
[17:09] <RikMills> so some things I am wondering while we wait. (a) I guess the fix is not able to be cherry picked without new features? (b) does the glib2.0 in proposed bork ardour in release at runtime, or just build? (c) does ardour get many SRU worthy things post release? (d) would 6.7 likley get ant bugfix releases soon post release?
[17:09]  * RikMills notes that it also borked flatpak tests
[17:25] <RikMills> Eickmeyer: looking at the test rebuild log, I see that the ardour FTBFS actually did not use 2.68 from proposed, but used 2.67.5-2 from the release pocket
[17:25] <RikMills> which make sense as the rebuild is targeted at that pocket
[17:26] <Eickmeyer> Right, but any upload I do will build against proposed.
[17:26] <Eickmeyer> Which FTBFS in my PPA testing.
[17:26] <Eickmeyer> Gotta go to the DMV, bbl
[17:27] <RikMills> Eickmeyer: the test rebuild says it is not the fault of the glib2.0 in proposed, but a regression against 2.67.5-2 in release
[17:28] <RikMills> i.e. the 2.68 upload is not the issue
[17:28] <RikMills> or if 2.68 causes a FTBFS, so did 2.67.5-2
[17:29] <Eickmeyer> RikMills: I have a separate build log reviewed by the Ardour devs blaming 2.68.
[17:29] <RikMills> Eickmeyer: there is a build log here from the rebuild that never uses https://launchpadlibrarian.net/529954677/buildlog_ubuntu-hirsute-amd64.ardour_1%3A6.5.0+ds0-1_BUILDING.txt.gz
[17:30] <RikMills> *never uses 2.68
[17:30] <RikMills> is the fail is the same, then it is not specifically 2,68
[17:30] <RikMills> anyway. come back to this later :)
[17:42] <RikMills> usr/include/glib-2.0/glib/gatomic.h:206:45: error: invalid conversion from ‘volatile void*’ to ‘void*’ [-fpermissive]
[17:42] <RikMills> that occurs with 2.67
[17:50] <RikMills> https://github.com/Ardour/ardour/commit/8b4edaa9506dc945cfbd8ed9869fd9b384a513d7
[17:50] <RikMills> https://github.com/Ardour/ardour/commit/cc7b8b1bc5fb19e0ec5e476741c55627d4b62ba9
[17:50] <RikMills> gcc-11 also seems to be an issue
[17:58] <Eickmeyer> RikMills: Well, the patches I have should fix that, but it'll have to be upgraded to Ardour 6.6 from 6.5, which includes some new features. Soooo... FFe time.
[18:01] <RikMills> Eickmeyer: on the plus side, you only have 6.5.0, so it is not as if you currently have mature release with several point bugfixes. in fact you would guess a newer one is more likely to get those (if they do them)
[18:04] <RikMills> or in other words, if they are vetting ready to release 6.7, they may not be caring much about bugs in 6.5
[18:04] <RikMills> generalisation, I admit
[18:07] <seb128> Eickmeyer, So uh... who's idea was it to sync glib 2.68 from Experimental right before Beta Freeze?
[18:08] <seb128> Eickmeyer, it was mine and that sync was from a rc version to the stable one, we were already on that serie since before feature freeze
[18:09] <seb128> sounds like you guys figured that out from the backlog, the issue started with 2.67 and not with that recent sync
[18:09] <Eickmeyer> seb128: Well, it caused a volunteer to have a major FTBFS even with that RC then, if that's the case.
[18:10] <Eickmeyer> Broke a major package.
[18:10] <seb128> Eickmeyer, well, new libraries or toolchain leading to need of fixing things isn't anything new, no much we can do about it
[18:11] <seb128> we updated to the new serie before feature freeze which should let enough time to sort out breakages
[18:11] <Eickmeyer> seb128: The only time anybody even knows about that stuff is if packages are rebuilt, which doesn't happen until right before beta freeze, which means us lowlife volunteers have to stop everything we're doing and fix stuff in a hurry.
[18:11] <RikMills> seb128: can you point me to the 2.68 RC launchpad build? LP is not showing me
[18:13] <seb128> RikMills, 2.67.x is the dev serie leading to 2.68, 2.67.5 was the last one before stable
[18:14] <RikMills> seb128: oh of course. KDE does not do that even/odd thing, so I forget. Thanks :)
[18:14] <seb128> np!
[18:15] <RikMills> well that cements the fact that it is not the sync in proposed that is the issue
[18:23] <Eickmeyer> RikMills, seb128: It also cements the fact that it introduced a regression after Ardour 6.5 had already been synced.
[18:24] <seb128> we can't avoid regression to happen sometime unless we never upgrade anything
[18:24] <seb128> maybe we should have an archive rebuild after ff though to catch problems
[18:25] <RikMills> ^ +1 to that
[18:25] <Eickmeyer> seb128: I think that would be best, rather than right before beta freeze when fixes are limited and have to pass through the release team, which makes extra work for them.
[18:25] <Eickmeyer> doko: ^
[18:25] <seb128> that would make sense indeed
[18:28] <Eickmeyer> sil2100: Conversation above.
[18:29] <Eickmeyer> Needless to say, I'm not a happy camper because now I've gotta rush to beat the beta freeze.
[18:30] <RikMills> unless ardour in release is broken on runtime, then I would suggest that you do not need to beat that freeze
[18:31] <RikMills> ^ sil2100 ?
[18:32] <RikMills> unless you want the new one in beta testing
[18:32] <cjwatson> Can you simplify the upgrade work by cherry-picking individual patches from ardour upstream rather than by doing a full upstream release upgrade?
[18:40] <Eickmeyer> cjwatson: Without the full upstream release, the patches are irrellevant.
[18:40] <Eickmeyer> (already asked about that)
[18:42] <cjwatson> You mean they can't be backported to the existing version?
[18:46] <Eickmeyer> cjwatson: Correct.
[18:46] <cjwatson> Surprising.
[18:47] <Eickmeyer> cjwatson: Considering this package is technically not endorsed by the upstream developers, which use their own build system, it's not that surprising.
[18:47] <Eickmeyer> In other words, they don't care that much.
[18:47] <cjwatson> My claim of "surprising" is based on 20 years of generally being able to successfully backport patches regardless of whether upstream cares :)
[18:47] <cjwatson> It does happen, but it's an extraordinary claim that requires extraordinary evidence IMO
[18:48] <Eickmeyer> Yeah, I see that point of view, but they built the commits on top of other commits.
[18:48] <cjwatson> Well, indeed, that's usually how it works
[18:49] <Eickmeyer> Basically it's a hole that I don't have time to go down, but it's a package that without it Ubuntu Studio becomes irrellevant to the Audio community, which is its biggest audience.