[16:33:09] Meeting started by itchka [16:33:31] Meeting chairs are: itchka, bero [16:33:59] Current subject: Cooker Report (set by itchka) [16:34:33] itchka: that Requires: is exactly how you require a kernel module -- note, however, that it works only on properly packaged modules, not on stuff like modules dkms builds on the fly or something [16:34:34] bero: Can you give us a summary please. [16:35:10] Cooker looked really great yesterday, but something broke plasmashell last night. We're currently trying to figure out what exactly is going on there [16:35:26] when that's fixed (and possibly akonadi is fixed as well), we'll be looking good [16:35:46] clang 10 rc3 has been released today and I'm currently building it [16:35:47] akonadi is broken in rolling as well [16:36:02] it has fixes for all problems we've reported since we moved to the 10 branch [16:36:13] so clang is definitely looking good [16:36:18] That's good news [16:36:44] gcc 10 still has problems building the kernel, but we have a gcc9.2 compat package now that builds kernels fine, so we have working kernels (both clang and gcc variants, and both release and rc) again [16:37:00] essentially as soon as plasmashell is fixed, we're ready for cp cooker rolling [16:37:52] Rolling is busted..is it fixable if the plasmasheel problem proves intractable. [16:38:20] I can't build packages on it. [16:42:40] It's fixable, but the best fix is to copy rolling to it, everything else is just a load of extra work for something that will be thrown out soon anyway [16:51:17] Ok [16:51:33] Lets hope teh cp happens soon. [16:59:57] I've fixed the nazi drivers for kernel-5.5 [17:02:19] I've enabled the modesetting driver and automated the install. I'm not rebuilding the initrd just blacklisting nouveau via a grub command line. [17:15:43] Nothing else on cooker I guess. [17:16:30] .topic 4.2 Release. Timing [17:17:46] chwido seems to have forgotten me! [17:18:30] .help [17:19:35] Current subject: 4.2 Release. Timimg (set by itchka) [17:19:51] Doh [17:20:15] Any opinions? [17:25:43] itchka: You're a chwido operator but not a channel operator, let me fix that [17:25:57] should work now [17:26:13] IMO we have 2 options... [17:26:52] We can either say we've already done a lot (new toolchain, KDE 5.18, ...) and release 4.2 as a smaller update fairly quickly [17:27:19] or? [17:27:46] or we can be more ambitious and take up all the things on the todo list, like calamares OEM mode, FS changes for crosscompiler support, properly done 32bit libs so wine32 and wine64 can coexist etc. [17:28:46] bero: That lot will take quite a while I'd see that almost as a 5.0 release [17:29:00] yes [17:29:45] we should still aim at a release this year given Qt 6 is probably coming near the end of this year [17:29:49] Option 1: seems the sane one. [17:29:50] which will mean more major changes [17:30:44] Perhaps we should go for all the stuff you mentioned before Qt6? [17:33:07] yes, IMO that's the plan... [17:34:38] That sounds fine to me we will need quite a bit of time to get all that done..specially the wine libs. [17:35:54] That kind of implies that the i686 repo will end the release after next. [17:41:22] unless we still need it for something like those boxes in Ethiopia [17:41:34] We still don't know for 100% sure what CPUs they have [17:41:52] We know "older CPUs from an age where computers had 512 MB RAM" [17:41:57] which could really be both [17:42:09] I'll chase that one up. [17:43:48] The other thing is that they may all be fitted with nvidia graphics cards!!! [17:44:16] which wouldn't be a problem, the older cards work perfectly fine with nouveau [17:44:39] it's not like they want to play high-end 3D games on a 4K display [17:46:41] Not so sure about that :) [17:48:15] Want and able to are of course two completely different things [17:49:08] Does this dbus-broker thing work? Does it bring anything to the party? [17:57:07] seems to work perfectly so far [17:57:18] it doesn't bring all that much, but it's a lot faster than dbus-daemon [17:57:35] doesn't matter that much though given dbus mostly exchanges small messages once in a while [17:58:26] Btw I'll deploy dbus-broker tommorow [17:58:34] I guess anything that saves machine cycles has to be good. [17:59:02] yes -- it's good, but won't really affect a lot [17:59:23] As long as it's stable! [18:00:05] seems to be [18:00:14] bero: Did you see the link I posted about the Helios 500 sub-woofer> [18:00:30] yes, but didn't get to try it out yet [18:00:41] also not sure if I'd actually notice the difference if it started working [18:01:25] Surely you are not tone deaf :) [18:02:30] When it works it make quite a big difference but I don't seem to be able to make it work reliably. [18:04:11] At one point I had the sub-woofer showing up in system setting but for the life of me I can't make it happen again. [18:14:40] So release could take place next Friday id plasmashell and akonadi are fixed this weekend? [18:14:51] id=if [18:16:00] IMO yes, but that's a big if and we should probably get some more opinions on whether or not we want to release that quickly [18:16:43] brb, checking if plasmashell starts with locally built qt [18:18:08] it doesn't [18:18:17] trying local mass rebuild of anything kde [18:21:40] Wonder what broke it? [18:22:25] Dnf history may help [18:23:02] Anyways I have one system that is not up to date, I'll run dnf upgrade and see what may be a potential culprit [18:23:27] Good plan [18:23:32] tpg: Try installing just the qt update without anything else, it's the one I suspect most [18:32:12] bero another weird gcc lock https://abf.io/build_lists/3213851 [18:32:30] strace [18:32:32] clone(child_stack=0xffffc6e45bc0, flags=CLONE_VM|CLONE_VFORK|SIGCHLD) = 57375 [18:32:34] close(4) = 0 [18:32:35] read(3, "", 16) = 0 [18:32:36] close(3) = 0 [18:32:38] wait4(57375, [18:36:54] it forks, then waits for the other process, which never exist... Try without -pipe, that's easier to debug [18:39:49] pipe2([3, 4], O_CLOEXEC) = 0 [18:39:50] clone(child_stack=0xfffff6553a10, flags=CLONE_VM|CLONE_VFORK|SIGCHLD) = 40680 [18:39:52] close(4) = 0 [18:39:54] read(3, "", 16) = 0 [18:39:55] close(3) = 0 [18:39:57] wait4(40680, [18:39:58] looks same [18:40:20] such command /usr/bin/gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I. -I../mpglib -I.. -O2 -fomit-frame-pointer -c psymodel.c -fPIC -DPIC -o .libs/psymodel.o [18:44:44] it is some flags, if i do ./configure everything works fine [18:56:14] fdrt: tpg: bero: itchka: Notice anything odd about this: https://abf.openmandriva.org/build_lists/711924 [18:56:18] ? [18:56:50] "Build complete" but there is no option to publish? [18:56:59] Build can be published only from 4.1 branch [18:59:35] How? [18:59:47] That page is from 4.1 branch [19:02:07] it's built from another branch [19:03:33] Well the point is QA does not know how to move a package in this state, what do we do with it, or should it be left as is? [19:03:55] ben79: IMO reject it because it was built from the wrong branch [19:04:53] OK, thanks [19:11:15] Cooker ISO's built today, the goal was to build Cooker with "idealized" or compatible packages for what ever use they might be. [19:11:45] It looks like the *may* be what is about to become Rolling [19:11:57] And *maybe* Lx 4.2? [19:14:21] It sounded like we're talking a 4.2 release with changes in Cooker now? [19:18:32] ben79: yes, we're at least considering it [19:18:59] Any ETA on cp cooker2rolling? [19:29:40] ben79: as soon as we've figured out what update broke plasmashell startup [19:31:42] updating all packages except qt [19:33:04] oddly enough, falkon has fixed itself, I didn't change anything and it works again [19:38:04] bero: Can you take over the chair please. I have to cook now. [19:38:15] sure [19:38:34] So I just built Cooker ISO's where plasmashell is not working? [19:39:18] So, do we have anything else on 4.2= [19:39:19] ? [19:39:40] ben79: highly likely -- that is, unless it's caused by updating [19:40:15] ben79: everyone who has installed all cooker updates today is seeing plasmashell crashes, I don't think we've tried anything on a fresh box so far [19:40:51] I'm not in cooker so did not realize that [19:43:07] Just created VM with new x86_64 ISO and it boots to black screen with mouse cursor [19:47:52] not entirely unexpected [19:48:15] I'm currently rebuilding kf and plasma to make sure it's not an ABI issue we missed [19:48:55] bero: funny, if i put to optflags only -O2 build stucks if optflags is empty lame builds fine [19:49:01] probably toolchain issue [19:49:26] yes, but it's odd that it would do stuff at -O2 given that's what most distros use [19:49:50] you'd think someone else would notice [19:50:08] I also just tried, it builds perfectly on cooker even if I force gcc or gcc9.2 [19:50:20] yes [19:50:24] dunno why [20:13:34] bero crashing for me too [20:13:52] but I selected 7 packages [20:15:58] bero selected packages I installed as last, so looks like one of them is culprit https://imgur.com/ZUoxrIS [20:16:07] python-qt5-xml python-qt5-core [20:16:59] hmm, that's weird [20:17:25] If this was caused by an updated package I have a working cooker VM up running and the broken cooker ISO also up running those 2 are on the cooker iso but not working cooker [20:17:33] I think we can rule out lib64qt5test5 -- that's a development package, nothing should use it except for testing [20:17:57] We can also rule out krfb, that's an application that's not being run in a default session [20:18:54] lib64qt5printsupport5, also unlikely but not completely impossible, chances are that would crash only while trying to access a printer or create a pdf [20:19:31] lib64qt5network5 -- possible but unlikely because falkon and kvirc (both of which use it) are working [20:19:58] lib64qt5opengl5 -- also possible but unlikely because applications keep working [20:20:20] kquickcharts -- I don't think anything in plasma uses it on startup [20:20:43] let me downgrade one by one [20:20:48] lib64selinux3 -- possibly. We don't use selinux heavily but of course an ABI change in a library can break things pretty badly [20:21:01] but then again I think the previous version had a different soname so it shouldn't affect anything [20:21:31] oh wait I misread it and it's lib64selinux1 [20:21:37] so what I said about sonames doesn't apply [20:22:50] downgrading selinux [20:22:51] I don't see any selinux packages on cooker iso [20:22:53] rebooting [20:27:55] I've rebuilt libsepol and libselinux 2.9 locally, they don't seem to make a difference [20:33:28] ben79: We can rule out python-* because I just removed python-qt* (it's all optional) and plasmashell still crashes [20:33:28] yes, downgra selinux no [20:33:46] sry typo [20:33:53] so lib64qt5opengl5 is the most likely one now IMP [20:33:54] IMO [20:33:55] maybe opengl? [20:34:10] somewhat makes sense because plasmashell uses it and probably kvirc doesn't [20:34:10] why openmp disabled in oma? [20:34:33] fdrt: what makes you think it is? It isn't... at least it isn't supposed to be and I know it works in stuff like ImageMagick [20:34:51] bero i mean rpm package [20:35:32] fdrt: what package? There's 2 OpenMP implementations, one is part of LLVM (and part of the llvm package), the other is part of gcc (libgomp, part of the gcc package) [20:36:50] bero https://github.com/OpenMandrivaAssociation/rpm/blob/master/rpm.spec#L546 [20:37:06] ## TODO: Enable by default once mock+ABF are fixed [20:37:07] %bcond_with openmp [20:37:54] https://github.com/OpenMandrivaAssociation/rpm/blob/master/rpm.spec#L72 <--- looks like there's some issue with mock and/or ABF? [20:38:01] no issues [20:38:04] I don't know who put it there, but the comment seems to give a reason [20:38:13] it's working on abf fine [20:38:14] Eighth_Doctor: any idea what that is about? [20:45:04] bero btw qt 5.15.0-0.beta1.1 was last know good? [20:45:13] at least it worked for me [20:45:27] the odd thing is there's really not much of a difference between .1 and .2 [20:46:03] this is not a opengl [20:46:09] downgrading now network [21:00:40] penguin is no more angry [21:00:51] penguin is now happy :) [21:01:43] bero I order to shoot qt5network [21:01:57] hmm... weird [21:02:07] there's exactly nothing that should have changed in qtnetwork [21:02:22] just try downgrade it [21:02:24] I wonder if it links statically to any libraries that have been updated or some other weird stuff [21:02:51] i downgraded packages one by one [21:02:56] one package and reboot [21:03:16] so this should be culprit [21:03:32] I don't want to reboot my box right now because it's in the middle of building stuff -- but will definitely try as soon as it's done [21:06:17] ruru[m] ben79 tpg christann can you install this packages and test if it fix issues with cooker? http://file-store.openmandriva.org/api/v1/file_stores/0da07ce9a1896ed81e192418deca773cf02f0192 [21:06:44] sudo dnf downgrade package_name.rpm [21:07:48] bero the actual bugs are in clang open mp [21:07:57] It works fine in ROSA abf [21:08:20] what is the bug? [21:09:25] AngryPenguin: will do. [21:12:19] bero it is broken and races with itself, causing rpmbuild to randomly exit with error [21:17:15] suspects rpm makes some implementation specific assumptions about openmp, given clang openmp is used heavily in science [21:19:26] AngryPenguin: On not working Cooker ISO I downgraded that package and logged out/login and... [21:19:33] that seems to fix [21:26:19] good [21:26:25] thanks for tetsing [21:26:35] bero ^^ confirmed [21:38:22] time for another test, firefox nightly on wayland with hardware decoding h264 via vaapi :) [21:38:27] brb [21:39:04] yeah, I installed all the other upgraded lib64qt5 except lib64qt5network5 and cooker still working in VM [21:41:11] brb, my box is done building... [21:51:31] works here too [21:51:42] but I can't say I'm happy about it, that makes finding the problem a lot harder [21:51:52] because the difference between qtnetwork .1 and .2 is exactly nothing :/ [21:54:59] So a solution that does not make sense... Or is possible that one package was a corrupted build? [22:00:29] bero just revert all changer from .2 [22:00:43] *changes [22:01:46] After the downgrade, cooker is now working here. [22:03:03] and it's getting even weirder [22:03:24] if I distro-sync, it breaks again (as expected) but if I downgrade qtnetwork, it remains broken [22:03:33] so it looks like rebuilding kf* stuff has some effect [22:03:39] unless my box is somehow uniquely botched [22:06:56] upgraded cooker except lib64qt5network5: system working [22:18:19] [MIRROR] lib64KF5ModemManagerQt6-5.67.0-3-omv4002.znver1.rpm: Interrupted by header callback: Server reports Content-Length: 138576 but expected size is: 138560 [22:18:19] [MIRROR] lib64KF5NetworkManagerQt6-5.67.0-3-omv4002.znver1.rpm: Interrupted by header callback: Server reports Content-Length: 336804 but expected size is: 335908 [22:18:19] [MIRROR] lib64KF5ModemManagerQt6-5.67.0-3-omv4002.znver1.rpm: Interrupted by header callback: Server reports Content-Length: 138576 but expected size is: 138560 [22:18:19] [MIRROR] lib64KF5NetworkManagerQt6-5.67.0-3-omv4002.znver1.rpm: Interrupted by header callback: Server reports Content-Length: 336804 but expected size is: 335908 [22:18:19] [FAILED] lib64KF5NetworkManagerQt6-5.67.0-3-omv4002.znver1.rpm: No more mirrors to try - All mirrors were already tried without success [22:18:24] Qt 6? [22:19:28] no, lib64KF5NetworkManagerQt.so.6 [22:19:42] that has been at 6 for a long time [22:19:58] Content-Length differing is because of rebuilds without release bump [22:20:09] will fix in a second [22:20:16] just tweaking some BuildRequires [22:22:29] I'm hoping for things to slow down enough so I can upgrade a couple of cooker systems while I know what to do to keep things working. [22:35:58] And looks like I got 'em upgraded now, for the moment. [22:48:34] Is the meeting still going? Shouldn't somebody close it? [22:51:44] Are we done? [22:52:13] Meeting ended by itchka. Total meeting length: 379 minutes