[16:10:05] Meeting started by itchka [16:10:23] Meeting chairs are: bero [16:10:34] Meeting chairs are: itchka [16:10:41] Meeting chairs are: itchka, bero [16:11:06] it's less performant than the previous unfortunately [16:11:50] I have to go fairly early today so I'll chair until 18:00 then I must go. [16:11:59] .item 1 [16:12:38] Current subject: OMLx 4.1 release - Post-release comments, whether or not to do a 4.1.1 (set by itchka) [16:12:46] Here we go [16:13:38] So, as far as I'm concerned, 4.1 went pretty well, except we should have caught the clang kernel issues without having to respin final isos... [16:14:37] IMO we should probably make a 4.1.1 release with that fix and a few other bits already in updates soon, to make sure nobody is using any original spin 4.1 isos floating around... [16:14:42] any other thoughts? [16:15:35] The only comment I have is that akonadi is still giving problems. It runs ok for a while and then it stops fetching mail until it's restarted. kmail still works when it is in this state [16:16:45] akonadi is a pain, hope it'll be replaced for Plasma 6 [16:16:57] before we release 4.1.1, we should push steam fix to update repo, some packages still not publishied (missied in kahinah) https://abf.openmandriva.org/build_lists#?page=1&per_page=25&ownership=everything&status=12000&save_to_platform_id=315 [16:17:02] fortunately that's not extremely far away anymore, qt6 will likely be released in November [16:17:34] bero: But what will replace it? [16:18:00] AngryPenguin: agreed, that and the cryptsetup (which caused the original steam crash) [16:18:06] AngryPenguin: we did fix steam finally? [16:18:23] (we=you, ofc) [16:18:25] itchka: hopefully a more sane version of itself ;) [16:18:48] rugyada yes, cooker and rolling, packages still pending in testing for publishing in 4.1 [16:18:51] rugyada: let's say workarounded, we can't fix it properly because we don't have their source and can't fix it [16:19:11] that's great [16:19:27] but the crash was triggered by steam using libmount, libmount using cryptsetup, cryptsetup using our version of openssl and at the same time steam using its own version of openssl [16:19:54] so the dynamic linker has no way of knowing which openssl to call into for everything they call, and it guessed wrong [16:20:06] the real fix is for them to stop using their own internal copy of openssl [16:20:22] for now the workaround is to not use openssl in cryptsetup (which fortunately supports other crypto libraries as well) [16:20:33] bero: tpg has removed dnfdrgora [16:20:51] what?! [16:20:57] lol [16:20:57] from the iso I presume? [16:21:03] Yes [16:21:05] chwido bite tpg [16:21:05] Still not a good idea IMO [16:21:18] chwido: bite _TPG [16:21:21] Just thought I'd mention it [16:21:32] discover is working well now, but it doesn't give access to non-GUI packages... [16:21:35] arrrgh [16:21:37] I think removed from task-plasma [16:21:40] and even for GUI packages we have to add the metadata [16:21:48] so let's put dnfdragora back... [16:21:50] It's actually been removed from task-plasma if I recall correctly [16:22:18] itchka: [17:21] I think removed from task-plasma [16:22:25] discraper is worst software I ever seen [16:22:26] that sort-of makes sense, we should probably pull it in elsewhere [16:22:34] never worked for me on any distro... [16:22:44] AngryPenguin: +1 [16:22:54] It's the flatpacks he's after [16:23:29] I wouldn't say it's the worst I've ever seen (that would be GTK... And anything Microsoft and anything Crapple second), but I agree it's not exactly good [16:23:35] and flatcrap sucks [16:24:18] There is a bit of an issue with the repository chooser. [16:24:28] bero if flatpack suck then what would you call snap? [16:24:40] AngryPenguin: worse than Hitler? [16:24:46] xD [16:25:18] It requires root provs which is fine but the dialog to enter them takes a painfully long time to appear and sometimes appears under other windows. [16:27:16] well, what the repo picker does is call /usr/bin/kdesu [16:27:29] so outside of fixing kdesu there's little we can do to improve that [16:28:12] bero: could we call the dialog box first before editing? [16:28:21] no [16:28:39] because at that point we don't know what command needs to be called [16:29:17] can't we just use it to run the entire prog as su? [16:29:18] essentially repo picker is just a frontend around "kdesu dnf config-manager --set-enabled x y z" or "kdesu dnf config-manager --set-disabled x y z" [16:29:47] we could, but that would make all the security conscious people freak out [16:29:59] running anything with a UI as root is generally not considered safe [16:30:31] but IMO it's not a big deal [16:30:39] "don't like it, don't use it"... [16:30:55] It isn't it's just b annoying [16:30:57] but it would probably get us a few bad reviews [16:31:28] The curious thing is you don'yt see the same delays when you run systemctl. [16:32:25] but that runs sudo I think since it works with the users password [16:33:29] another thing we could try is run it through pkexec instead of kdesu [16:33:45] not the biggest fan of pk but it should work [16:34:24] Can we try that please. [16:34:42] If it's not too much work [16:34:46] sure [16:38:10] That's it from me on the latest release. Anyone else? [16:38:29] I minute and I'll move to the next item. [16:38:49] we should build new kernel, unfortunately build still failing https://abf.openmandriva.org/build_lists/691164 [16:38:51] same with clang [16:39:17] I have a local 5.5.3 build, not sure why it's failing in abf [16:39:19] looking... [16:39:19] Is there a prob with the current kernel? [16:39:21] itchka: you shoul write ".action bero does stuff with pkexec" [16:39:24] also trying to get 5.6-rc1 up [16:40:00] "whether or not to do a 4.1.1" <-- still no answered [16:40:21] From me: +1 for 4.1.1 as soon as we have a few more issues sorted out [16:41:03] ACTION: bero does stuff with pkexec [16:41:44] +1 from me too. We need to clean out any confusion with th emultiple isos [16:42:03] +1 [16:42:25] ACTION: bero fixes kernel builds in abf [16:44:41] OK shall I record an action "Create 4.1.1 release after new kernel and minor issue fixes" [16:44:51] works for me [16:44:55] looks like we don't have any -1s [16:45:18] ACTION: Create 4.1.1 release after new kernel and minor issue fixes [16:45:29] Moving on [16:46:10] Current subject: 2. OMLx 4.2/5.0 plans (set by itchka) [16:46:38] I guess you'll have some stuff to say here bero. [16:47:29] Obviously first question is 4.2 or 5.0 [16:48:15] I think we should reserve 5.0 for kde6 [16:48:18] I'm leaning towards 4.2, we can call it 5.0 when we pull in Plasma 6 or some other highly user visible change [16:48:45] agree [16:48:55] but at the same time we already have a load of under the hood changes (new compilers, new glibc) [16:49:44] There's a few other things we could get in, such as the filesystem layout changes we were already looking at for 4.1 [16:50:19] Qui? [16:51:55] What changes? [16:53:04] https://github.com/orgs/OpenMandrivaAssociation/projects/4 [16:53:09] A 4.2 list of ideas [16:53:22] Would be nice to have a discussion on these. Maybe ditch some and add new ones [16:53:31] indeed [16:54:44] I have to go can you take over chair please bero [16:54:53] sure [16:55:24] So, let's go through the list... [16:55:31] yes change cpu governor by default for more performance [16:55:45] IWD [16:55:58] I think we have IWD, but disable it by default because it's still not working well for some chipsets [16:56:11] Probably we should leave it at that for 4.2? [16:57:32] (unless the situation improves and we can switch to IWD for everything, but I think that's not very likely unless we want to wait a long time before 4.2) [17:00:16] ,AngryPenguin for znver1 id go with performance on default [17:00:30] tpg good [17:00:47] last time with 4.0 we go with conservative or sometings like this [17:00:52] bero well I've updated iwd to latest release, would be nice to give it atry [17:00:54] Speaking of znver1, anyone interested in znver2 and/or skylake (or some other current Intel) builds? [17:00:57] and thats why we see poor benchmarks [17:02:23] fdrt: HisShadow: How do we create new arches in ABF btw? Saw the comment to just create musl as a new arch, but there doesn't seem to be an obvious way to create an arch [17:05:26] bero how about to build per arch libraries? Like CleatLinix does [17:07:03] bero: there isn't let me create musl for you [17:07:11] tpg: how do they do it? Separate function implementations in the same file? different libraries in /lib/amd vs. /lib/intel, etc.? [17:07:49] bero: done [17:11:00] HisShadow: thanks [17:12:08] bero: although not sure how this'll work [17:12:31] wonders if chwido just said hi because HisShadow starts with Hi... Let's see if Chwido will greet me again after saying... [17:12:33] Hitler sucks [17:12:45] :) [17:14:55] bero they patched glibc to look on /lib/$cpuinstructions [17:15:18] Some libraries are build with two archs, one x86_64 as common one and second with tune for avx [17:15:35] Makes sense especially when combined with the cross-compiler friendly filesystem layout changes... [17:16:08] So they got /lib/libc.so and /lib/avx/libc.so [17:17:03] See here https://github.com/clearlinux-pkgs/glibc [17:17:34] Same they does with i686 [17:18:09] They build at one foo.spec a x86_64 and i686 binaries/so [17:18:53] bero: I mean supposedly you want a musl flavoured packages for every arch, but right now there's only 1 musl arch [17:19:16] So we may try to provide common and cruical libraries for tuned arch at one build [17:19:31] HisShadow: yes, but that's good for a start, essentially just want to get one going to see how feasible it is [17:20:45] bero: I guess making musl-{arch} would work better [17:21:13] HisShadow: yes, let's get started with musl-x86_64, then if it turns out to work well we can add musl-aarch64 and friends [17:29:42] next? [17:32:53] i need to fix chwido with hisshadow [17:34:15] Ihateregex.io/ [17:44:05] ashledombos[m]: huh? [17:54:01] ashledombos[m]: time to go 1 level up into context-free grammars [18:08:55] I think the other items are pretty much clear... [18:09:08] Do we have any other feature ideas for 4.2? [18:13:30] chwido reacts to sentence starting with hi HisShadow [18:13:57] HisShadow if i mention you first chwido reacts [18:14:39] Need to mprove regex [18:14:58] Bero I think we need more PR [18:15:05] For 4.2 release [18:15:34] People still remembers Mandrake, and I think we should make advantage of it [18:17:11] tpg: I agree, a lot of people are still surprised we exist... But how? [18:22:16] I guess we need more articles about what we are doing [18:23:40] For example, Fedora is doing new foo feature, which is not anything spectacular, and it is announced like groundbreaking change, that will have huge impact on people lives [18:23:41] yes... We've been trying to get some out (in particular thanks to ruru[m]), but it doesn't look like they're being spread widely... [18:24:14] yes, I've seen a lot of "OMG! Ubuntu just upgraded the kernel to 5.5! And only 3 months after OpenMandriva did!" style reports too [18:24:29] but it's probably a matter of them bribing the press to cover it ;) [18:26:03] Imho we need to get in touch with people who may have or have influence on opinions [18:26:52] agreed... Just don't know how [18:27:59] And create user experience stories like, " John, 30 years old from London says "I was wooboontoo user for 10 years and when I tried OpenMandriva Lx 4.1 my previous Linux experience was a lie" [18:28:17] I gave one of our USB sticks to Chris Simmonds (the guy who wrote the book about embedded linux programming) at FOSDEM, but of course his type of people usually already use something else and don't see much of a need to switch [18:29:01] Do we actually have any users who were using anything else before? Would indeed be good to have those stories, but as far as I can tell we don't have any users except those currently here [18:30:40] Anyways I'll try to figure out some ideas for PR and will share these with you all [18:31:03] great, thanks! [18:31:15] Like these days you do not have to switch, as dual boot is standard same as virtualbox [18:31:37] So you may have using many is at once [18:31:48] Even if it means you just installed it for one boot [18:34:00] There are lots of people out there who were using Mandrake/Mandriva and this brings good memories for them, like it was my first distro, first Linux experience, I was you'd and handsome, I was on college partying all the time on LAN parties :) [18:34:29] _TPG aside: we need to improve also the workflow of announces, maybe we need to improve news and short news spreading but all should come from our website first. though having some exclusive news for some newspapers is interesting also. [18:35:07] Somehow we forgot about that we are continuing Mandrake spirit and that means good memories too ;) [18:36:16] I noticed that OMV has a lot of anti-fans [18:36:18] Raphael +1 and it think we should announce even minor things which for use are trivial, but for others are some kind of black magic [18:37:12] AngryPenguin yes it had long time ago, and mostly that was done by FUD and fake news [18:38:18] tpg often as there is a post on reddit or elsewhere, there are people who claim that it is a dead system, a piece of shit etc. and they suggest other "mandriva" fork as a replacement [18:38:33] AngryPenguin mostly mageia fans [18:39:09] We can't do anythnig else than ignore [18:39:19] about PR, we can create "press release" and send it to IT website [18:39:24] with every new release [18:39:30] or with every new features [18:40:28] which of course also ties to the next point on the agenda [18:40:39] I remember few years ago when I working in IT website, we wrote practically about all such press release [18:40:45] 3. Announcement of rolling [18:40:50] so this is IMO good option [18:41:04] IMO the rolling tree is in a pretty good shape... [18:41:09] ready to announce [18:41:25] maybe announce it as "experimental" for now because we still need to sort out a few details [18:41:25] bero remember invoking .subject for logs ;) [18:41:40] Current subject: Announcement of rolling and other PR (set by bero) [18:42:01] but IMO it's ready to get users on it... [18:42:09] And that announcement could create some buzz [18:42:25] it's not every day that some distro improves its release model... [18:42:56] AngryPenguin a dead POS system does not used LLVM, LTO, PGO, latest plasma, kernel, and does not support 6 different desktop environment, am I right? [18:43:53] tpg: Not necessarily, but a dead POS system called brokenbuntu does some LTO and PGO and has spins with whatever number of different desktop environments ;) [18:47:06] People by nature like things to get plain and simple, and that is a nice field for all kind of fake news to live on. So if someone's mind still lives in 2010 it means his current opinions are still wrong and outdated even if they sound very 2020ish [18:49:59] bero brokenbuntu have shitloads of money from Mark Shuttleworth, which is something not to omit [18:52:14] AngryPenguin yes we need some short "what's new" section on our main site [18:53:06] tpg https://www.openmandriva.org/en/news/ [18:53:16] loot at short news [18:54:29] *look [18:54:38] maybe we need to make it more immediately visible [18:55:04] AngryPenguin I know that, and it does not looks good [18:55:07] Second it's not on our landing page [18:55:23] We are having too much subpages [18:55:43] And it is hard to find anything reliable [18:55:55] looks like we can't link to short news... [19:00:45] I'll prepare some lo-fi UX models of our new landingpage [19:02:06] I'll as my friends at my daily job who are user experience designers with good ideas and vision [19:03:14] Then we may talk on sonething visible [19:06:47] OMV at 45 place in distrowatch https://distrowatch.com/ [19:07:03] we can click here a bit more :) [19:07:39] +1 [19:07:53] Have you read this? https://cubiclenate.com/2019/07/06/openmandriva-review-from-an-opensuse-user/ [19:10:30] lol [19:10:31] "I would have preferred OpenMandriva had switched to using Zypper instead of DNF as I think Zypper is more mature and DNF doesn’t quite yet have feature parity with YUM. I must also say that DNF is great, I just happen to think Zypper is greater." [19:10:47] OMV support zypper now xD [19:12:11] AngryPenguin you may want to contact the reviewer about that his wish came true :) [19:12:17] Btw I've compiled a list of YouTube reviews [19:12:21] https://www.youtube.com/playlist?list=PLTAw7pAjQAvCvGwVwH_DyTx6kiyPTpNef [19:32:21] Nice to see we're getting some reviews [19:48:03] we have fixed almost everything we got as not-100%-ok reports from 4.0 reviews [19:48:24] nv drivers works? [19:48:31] anyone can confirm? [20:02:21] no idea... Nazividia-free systems here [20:04:11] bero I know, but when we release LX 4.0 many people complained that drivers are not available and they couldn't even install them directly from the nvidia.com website [20:04:45] there was even a video review (several people) who complained a lot about it. [20:06:01] nv 440 [20:06:03] nothing provides kmod(nvidia-440) = 440.44 needed by nvidia-440-cuda-opencl-440.44-1.x86_64 [20:06:05] DEBUG util.py:585: BUILDSTDERR: Problem 2: conflicting requests [20:06:06] DEBUG util.py:585: BUILDSTDERR: - nothing provides kmod(nvidia-440) = 440.44 needed by x11-driver-video-nvidia-440-440.44-1.x86_64 [20:06:08] DEBUG util.py:585: BUILDSTDERR: - nothing provides egl-wayland needed by x11-driver-video-nvidia-440-440.44-1.x86_64 [20:06:09] DEBUG util.py:585: BUILDSTDERR: Problem 3: conflicting requests [20:06:11] DEBUG util.py:585: BUILDSTDERR: - nothing provides libX11.so.6 needed by x11-driver-video-nvidia-440-32bit-440.44-1.x86_64 [20:06:12] D [20:06:17] https://abf.openmandriva.org/build_lists/677123 [20:06:23] look at test page [20:06:32] libX11.so.6 is the 32-bit version of libX11 [20:06:38] so enabling the 32-bit repos should fix this [20:06:51] but I wonder why the x86_64 driver would use 32-bit binaries... [20:07:07] and kmod(nvidia-440)? [20:07:10] but of course Nazividia brownshirts don't have brains, so I wouldn't put it past them to actually mess up like that [20:07:49] That should be provided by the Nazi driver itself I guess -- it's the kernel module [20:11:13] we need someone who has an nvidia card and could test these drivers [20:11:27] AFAIK itchka has one [20:13:02] good news on a different matter - chromium 80 finished building locally and works, so the fixes for clang 10 and libstdc++10 are working [20:14:01] good :) [20:18:27] 81 seems to be broken upstream, 81.0.4044.17 tarball doesn't even download [20:19:29] 81 beta [20:19:53] Maybe chrome dev 82 works? [20:20:25] doesn't even exist (except on windoze) [20:20:36] http://omahaproxy.appspot.com/ [20:20:48] linux dev 81.0.4044.17 [20:20:53] linux beta 80.0.3987.100 [20:20:58] linux stable 80.0.3987.100 [20:22:17] hmm [20:22:20] rugyada: any thoughts on rolling announcement? [20:22:29] looks like they not move dev to beta yet [20:22:56] and 81-dev doesn't compile, seems to be missing a file in the tarball [20:23:01] no obvious fix [20:25:13] bero: on if we want to announce it, or about the content? [20:26:04] rugyada: both... I think it's about time to announce it and generate some more publicity so the little attention we're getting for 4.1 doesn't die down... [20:26:59] agreed that's time to announce [20:27:21] re the content I need help and inputs [20:29:44] Maybe something along the lines of (do add some stuff there, this is going to be short...): [20:30:28] We've just released OpenMandriva 4.1 - the most up to date Linux distribution on the planet, featuring among other things kernel 5.5, Qt 5.14.1, Plasma 5.17.5, LibreOffice 6.4, ... [20:30:44] To make sure you don't fall behind, now we're announcing a new way to keep you up to date: OpenMandriva Rolling [20:31:17] while you can stay on 4.1 and will continue to get security updates, you can also opt to use OpenMandriva Rolling, our new rolling release branch. [20:31:59] taking note [20:31:59] Our previous development branch, cooker, will continue to be the main point of development that can break at any time - if you're using cooker and you don't mind us breaking your system every now and then, nothing changes for you. [20:32:41] But if you're a user who needs a system to remain working, while still wanting to get the latest and greatest features without having to wait for a new release, Rolling is for you [20:33:50] Development happens in Cooker (which, right now, is ahead of its time - using snapshots of upcoming toolchains such as Clang 10, gcc 10), and once deemed safe for general use is copied to rolling [20:35:17] We will also continue to provide stable releases (4.2, ...) for people who value things remaining the same without even potentially risky updates over having the latest and greatest features [20:37:21] The rolling branch has existed unannounced since the release of 4.0 - and was tested and refined in the 4.1 cycle. While, as with anything new, minor hickups may still happen, we don't expect rolling to break. [20:38:09] In order to switch to rolling, select the rolling repositories in om-repo-picker, edit /etc/yum.d/* files manually, or grab a rolling snapshot iso from [TBD, insert URLs] [20:38:28] Death to Microsoft, death to Crapple, death to Brokenbuntu! [20:38:39] :) [20:38:45] (without that last overly blunt statement of course ;) ) [20:39:03] yes [20:39:06] that's a very good start point [20:41:36] we should probably also add a link to cooker isos (should be done very soon, almost working again) for people who want to stay ahead of the edge [20:41:50] sure [20:41:53] will do [20:43:40] bbl [20:45:42] There are fairly new Rolling ISO's >>> https://abf.openmandriva.org/platforms/rolling/products/81/product_build_lists/3133 && https://abf.openmandriva.org/platforms/rolling/products/82/product_build_lists/3134 [20:46:51] The one question I have about announcing Rolling is how do we handle the periodic "cp -a cooker rolling"? How to explain short and sweet to users this and how to deal with? [20:48:37] One way *might* be to just make 'dnf distro-sync' the standard upgrade command for Rolling? [20:50:20] ben79 in free time can you push to updates https://abf.openmandriva.org/build_lists#?page=1&per_page=25&ownership=everything&save_to_platform_id=315&status=12000 [20:51:07] AngryPenguin: Yes, will do [20:51:11] i mean nextcloud, kpmcore and cryptosetup [20:51:27] all this tree packages missing in kahinah [20:51:34] so need to publish manually from abf [20:52:10] I still think we need two cookers one with a testing repo. We start off with both stable but everything that is done in the dev cooker is sent to the testing repo of the other. When dev cooker thinks they are stable we release the content of the testing repo. [20:52:24] I can do that too as long as I know exactly what packages and how they are named in ABF [20:52:38] IMO there's no reason not to make dnf distro-sync the standard upgrade command [20:53:00] but it shouldn't even be needed, usually cp cooker rolling will also bump version/release numbers [20:53:29] one thing we need to take care of is GUI updaters [20:53:51] not sure if discover and dnfdragora-updater do distro-sync or upgrade by default [20:57:16] ususally when we do 'cp cooker rolling' the main difference between distro-sync and upgrade is that distro-sync re-installs some packages, I don't know how important or usefult this is. [21:16:17] Woops! [21:41:44] So I wild guess. The answer to my question about rolling announcement is that we don't say anything about 'cp cooker rolling'. [21:42:43] If the ABF autoupgrade cooker to rolling is active there won't be that much change anyway except to packages on the black.list [21:43:10] AngryPenguin: Published those packages. [21:43:31] Thanks for the heads up. [21:43:48] ben79 thanks [22:10:00] Kool. Looks like I shut down another meeting... [22:12:50] we noot end :) [22:32:39] So Cooker should be close to ready for new ISO's? Just upgraded and there is this interesting error: https://imgur.com/a/XIUFSlI [22:33:24] chwido you are not making sense [22:33:41] .chwido you are not making sense [22:39:00] ben79: IMO we can mention how to properly upgrade rolling, and why... [22:39:38] OK, then we just need to get the correct wording. [22:39:39] ben79: that error is odd [22:39:50] ben79: Do you have kqtquickcharts installed? [22:40:19] does not look like it [22:40:32] installing it should fix you up, but I wonder why it's not pulled in automatically [22:41:51] which to install: kqtquickcharts.znver1 : Qt Quick plugin to render beautiful and interactive charts [22:41:51] lib64KF5QuickCharts5.znver1 : A QtQuick module providing high-performance charts. [22:42:08] both [22:42:11] OK [22:44:40] This is odd, not updated to KF 5.67: lib64KF5QuickCharts5-5.66.0-1-omv4001.znver1.rpm [22:45:06] hmm, maybe another package that broke in yesterday's DNS outage [22:45:09] fixing [22:47:51] bero: anyway the error is gone upon logout/login [22:48:27] and I've just checked, kqtquickcharts is the only 5.66 package still left (even though 5.67 was built yesterday) [22:48:36] so rebuilding it (already doing so) should get rid of the remains of 5.66 [22:48:55] Yeah it was the only 5.66 I had on this system [23:15:14] So proper way to upgrade Rolling? Normally 'dnf --refresh upgrade' when developers announce on Forum a 'cooker2rolling' has been done 'dnf --refresh --allowerasing distro-sync' ? [23:15:47] And it never hurts to use 'dnf --refresh distro-sync'? [23:16:09] I think that is in the ball park of correctness anyway. [23:16:47] Or announce in short news? [23:18:37] But he won't [23:18:53] .share [23:33:35] IMO there's no reason to use anything other than dnf --refresh --allowerasing --best distro-sync [23:33:41] Usually that will do the same as upgrade [23:33:50] and when it does something else, usually something else is what we want [00:17:38] bero: OK then we have our wording for Rolling upgrading. [00:20:46] ok, so I guess if anyone is still around we can move to the next topic? [00:20:54] Current subject: RISC-V update (set by bero) [00:21:53] So, just a quick update: In cooker we've updated to Clang 10, which finally introduces enough RISC-V support to make it feasible as the main compiler [00:22:08] so now we're finally using the same toolchain for everything [00:22:56] OK and OK [00:22:59] There's a mass build currently running to get risc-v rebuilt with clang, and hopefully catch up with the other arches while at it [00:23:02] https://abf.openmandriva.org/platforms/cooker/mass_builds/234 [00:23:26] so far about half the packages are failing, but that's expected because of risc-v falling out of sync with the other arches and a lot of libraries etc. still missing [00:23:51] in a second and third run of the mass build, things should start looking good [00:24:11] FWIW we could use a few more RISC-V builders (qemu or real) [00:27:16] And speaking of mass builds... [00:27:20] Current subject: Upcoming mass build (set by bero) [00:27:41] Because of the toolchain updates I'd like to run a mass build for the other arches soon as well (probably when clang 10 final is ready) [00:27:49] I don't think anyone has objections? [00:30:26] nope [00:35:03] Current subject: OMLx 4.1 alternative desktops ISO spins (set by bero) [00:35:13] So... Which ones do we want and when do we want them? ;) [00:35:59] most popular like lxqt, gnome, cinnamon, mate and xfce [00:37:32] of course if it succeeds [00:39:12] the last time, we test ISO with Gnome and xfce and both works fine [00:39:41] Small problem with cinnamon. Black screen appeared during startup. [00:39:56] maybe just missing packages [00:40:29] because cinnamon works fine when installed by dnf install cinnamon [00:40:46] so we have few desktop, we need just create iso and release it [00:43:47] I think in addition to those, it could also be good to push a liquidshell one -- it's so largely unknown that a distro picking it up might actually get its developers interested [00:45:21] good idea [00:51:30] every new desktop ISO = more news to share [00:52:51] bero btw. is it hard to create applications like om-feeling-like? [00:53:41] not very, you've seen how quickly we got it... [00:54:20] (and of course the usual rant: It would have taken a month longer to build something similar with gtk) [00:54:47] bero create one more for me [00:55:05] with all desktop to install [00:55:12] just like in om-feeling-like [00:55:22] makes sense... though we may want to build that as a calamares module [00:57:18] possible to add to calamares option to choose which packages to install? [00:57:55] just like in Mandriva xD [00:58:27] yes, crazy wanted to look into it [01:01:14] bero: I would but that requires to rm -rf whole *iso script and start over , and itchka doesn't want that some meh, once you guys agree on something I can try that for OM [01:02:13] crazy: IMO we should do it... We can always keep the current iso script as a backup, but it really needs improvements [01:02:52] AngryPenguin: for that to work I mean not only a rsync hack and fool the user to install or install over network ( which should not be done at all ) one need the rpm's on the iso [01:03:35] but then you can minimize live and rm -rf everything is not needed since you do not rsync anything over [01:04:16] also then I would argue to have 2 iso types , install one and try-live-with-all-kind-stuff-on-it [01:04:59] the install one can be does in a minimal env , browser , editor , konsole , dolphin and mini-plasma to start up [01:05:03] or even smaller [01:05:50] bero: Ok I can look at that [01:06:35] crazy: Fully agreed, that's exactly what we should have... [01:07:59] I'm all in favor of this. [01:08:50] agree :) [01:09:41] Would seem that an ISO/installer where users can select what to install could generate some much needed publicity. [01:10:35] bero: there is a second option in calamares to do that but I didn't tested it myself [01:11:16] and btw latest cala with latest kpmcore is broken in some instances with != LANG en_XXX [01:11:58] bero: I use myself sill the neinstall GUI bc I can hide groups of packages to prevent disasters :-) [01:12:40] eg: a core group is hidden and even the use deselects all by default or by accident it results in a working cli installation [01:13:14] yes, that makes most sense IMO... [01:13:32] Hmm, so hack kpmcore to export LANG=C before calling kpartx and friends? [01:15:33] bero: I'm hunting not sure yet [01:20:11] Let's hold off 4.1.1 until that one is fixed... [01:26:21] no go ahead with kpmcore , need some fix in cala [01:26:37] but there is something weird need to check on the cala tarballs [01:27:00] I think ade broke something since it used to work and git has different code lol [01:29:35] bero: it is only broken if you use github tarball [01:29:40] is messed up [01:30:11] that v3.2.18.tar.gz is generated from hell knows what [01:37:47] bero: does rpm has a way to only download a package you want + depends but not install ? [01:38:21] crazy: rpm doesn't resolve deps, but dnf has it: dnf --downloadonly whatever [01:38:35] bero: or dnf or any tool [01:38:51] dnf --downloadonly packagename [01:38:56] ok with that is more easy to do [01:39:08] no need to maintai rpm lists :-) [01:39:15] right [01:39:48] btw with such a iso even cli installs are possible [01:39:52] just saying [01:40:08] yes... another thing I've wanted for a long time [01:42:04] well for sevrer HW we can experiment with calamares on framebuffer but a server has usually some VGA chip like the one from IPMI so even use the efi fb to have some minimal vga output [01:42:11] that is fine for cala already [01:42:23] need to check whetevr it work in fb still [01:42:40] btw only this tarball is OK -> https://github.com/calamares/calamares/releases/download/v3.2.18/calamares-3.2.18.tar.gz [01:43:03] bero: if you use anything else , rebuild calamares with this source code [01:44:55] We're currently at 3.2.17.1... Updating to 3.2.18 and making sure we use the right tarball at the same time... [01:45:51] ok [01:48:11] bero: in any way kpmcore 4.1.0 fixes near all races [01:48:46] good, we already have that [01:50:42] bleh some of the 'devels' from 'cloned distros' are annoying me so much [01:51:09] they don't even care to effing read public documetation [01:51:44] now while grub by design only has us key layout on boot is a calamares bug :P [01:51:46] lol [01:51:47] what are they doing? Filing bug reports about calamares because they can't figure out how to make it say "My Non-Working OS" instead of "Stupiduserbuntu 90.12 LTS"? ;) [01:52:05] lots of these too yes [01:52:24] so lets calamares workaround that! [01:52:57] sure , lets assume I can workaround that for UEFI , what does happend when you install the distro grub package :) [01:52:59] :D [01:53:06] they don't even get that [01:53:34] since you need a special core.img is a distro matter not calamres lol [01:54:05] bero: need to search but there are even bug reports about fonts settings =) [01:54:12] HELP! I want to get rich by selling my own OS, a copy of Ubuntu that I'm selling for $50 because it has my desktop background and a different color menu! But stupid calamares still says Ubuntu instead of MySuperOS Pro Plus Plus Plus Professional Edition! Calamares sucks! I'll sue you for hurting my business! [01:54:23] lets make calamares clean your room :D [01:54:34] :D [01:55:36] bero: but ... the special OM user has the report of year 2019 lol [01:55:43] actually 2 [01:55:45] :D [01:57:20] bero: https://github.com/calamares/calamares/issues/1264 <- :P [01:57:41] can't find the other one but is weird too [01:59:19] bero: lets request an OEM ABF modules :-) [01:59:22] lol [01:59:59] the always practical blackcrack [02:01:01] there was some suff about drakXXX he requested but cannot find it right now [02:01:28] found it [02:01:32] https://github.com/calamares/calamares/issues/952 [02:01:38] =) [02:24:44] bero: luks stuff is still broken and there is some weird stuff with multiple HDD's [02:25:39] IMO not a big deal if it isn't a regression from what we shipped before... [02:25:50] If it was always broken, not as urgent to fix [02:27:50] will fix that soon just need to understand what changed [03:00:06] bero: I think I found the first sucker :-) [03:00:28] nice :) [03:03:20] one sucker left but for that one I need the kpmcore devel, I don't get that logic [03:03:44] Hardware question for developers: If user connects TV a monitor with hdme cable that means the TV is graphically connected but not audio connected? Sound would still come from computer audio system unless there is separate audio connection to TV? [03:03:54] bero: moment, I'll post you an patch for luks internalization issue [03:04:04] er, uh, hdme = hdmi [03:04:24] ben79: default plasma is that yes but you can change that [03:04:38] you can change it per source in systemsettings [03:05:41] OK, thanks, I'll try that some time. [03:06:52] ben79: you just need to change from default eg: the internal codec to HDMI one [03:07:13] but just for the TV one [03:07:28] OK [03:07:54] so then your monitor/laptop outputs internal codec = laptop/PC speakers and TV = HDMI [03:08:22] I use my laptop with smart tv sometimes [03:08:36] ben79: http://frugalware.eu/cala-luks-sucker1.patch [03:08:38] errr [03:08:44] bero: http://frugalware.eu/cala-luks-sucker1.patch [03:09:09] bero: for the multi HDD swap issue I don't know yes [03:09:19] maybe I get a clue tomorrow [03:09:33] Yeah I watched superbowl on TV streaming from my desktop. [03:19:01] bero: I don't get why to hell kmpcore translates fs'es [03:19:25] once you hit such a bug everything breaks [03:19:43] no lib/app out here expects translated FS names [03:20:43] If it were a Microsoft, Apple or GNOME library, I'd assume it's probably just to please Nazis... "If it says ext4 instead of Viertes Erweitertes Dateisystem, that's subhuman language and must be eradicated" ;) [03:20:50] but in the K world we don't do that... ;) [03:21:23] well nothing checks for Linux-Swap or the like [03:21:45] Ah... Swap might actually be the answer [03:22:13] well but kpmcore has all translated [03:22:13] There's probably people who have no idea what swap is, but who will understand a localized term [03:22:33] a simple fs = xfs vs fs = XFS can break stuff [03:22:49] true [03:22:51] or ETX Vier or whetver other crap [03:23:18] why the hell these need a translation [03:23:34] imagine the name in ,in or something [03:23:57] yes, doesn't make sense to translate those at all [03:24:20] probably lazyness .. [03:24:26] unless maybe in languages that write right to left, 4txe is more readable than ext4 or something odd... [03:24:46] eg: translate in the app/lib and pull in into GUI so I don't need to code the right thing [03:24:48] Not sure how Arabic, Hebrew etc. deal with words that don't originate from their language [03:25:14] is simple and not your work :-) [03:25:30] but probably the letters look different enough for anyone to notice that the word should be read in the "wrong" direction [03:25:55] usually if you want that add a tooltip or something [03:26:21] ext4 -> Your description in laguage X .. but that has to be done in the GUI [03:26:32] agreed [03:26:39] so you pull that from the lib and meh , who cares [03:28:29] I think the second bug is releated to that shit too [03:28:56] somehow from calamares code that just can't be [03:29:46] the condition for normal swap IF luks depends on if doesn't have luks which seems to be ignored [03:29:53] but this is an fs check too [03:30:58] probably I need review any ->fileSystem().name() instances [03:31:01] bleh [03:31:44] but uhh I hate that .. need to bug the kpmcore devel to split these functions that is a mess [03:32:11] fs_func_for_translate_the_hell_of_them() and othe normal [03:32:13] yes, maybe kpmcore can be fixed instead [03:32:39] he can for sure but that will need some interface changes [03:32:49] it is now mixed [12:41:04] fdrt, HisShadow hi guys, so, after having a play at yout docker-compose file, I got to a point of "database "rosa-build" does not exist" [12:41:18] gmoro hisshadow knows how to make a database [12:41:19] so I need to initialize the database beforehand right :) [12:41:22] yes [12:41:24] cool [12:43:43] still struggling with my docker network here as well, not sure how docker compose create the subnets, so not sure how to access the web UI [12:43:47] :) [12:45:07] I guess I need to add the mappings to it somehow [12:46:56] didn't really wanted a full DNS for it [12:47:19] bero we afcceted by https://bugzilla.redhat.com/show_bug.cgi?id=1794289 [13:21:15] how you look at to split repos to cooker/repository/x86_64/main/release//LETTER/*/rpm, e.g. http://abf-downloads.openmandriva.org/cooker/repository/x86_64/main/release/a/a2ps-4.14-31-omv4000.x86_64.rpm [13:41:51] HisShadow, I guess I need to run the rake file to create the database rake db:create ? and then load the schema? [13:41:58] chwido, oof! [13:51:29] bero TaiShan 2280 V2 delivered today, 128 kernels! [13:53:01] fdrt: That's some toy!!! [13:57:19] Will take a look at uboot-tools, probably caused by gcc 10... [13:57:25] yes it is [13:57:49] i want ti import ~900 rust packages [13:57:55] fdrt: not sure why we would want to split repos by letter? Looks like something that helps little, but gives us a load of extra headaches with tools... [13:58:05] okay [13:58:08] TaiShan is great news! Is it already running? [13:58:31] bero Andrew Gaidukov unpackeged it and installing ubuntu there [13:58:44] How loud are the fans? Is it something you could run in your bedroom or it a box that's better off in a datacenter? [13:58:48] yuck [13:59:02] I wouldn't waste 128 CPUs with brokenbuntu bloat... :/ [14:00:02] gmoro: I'll try to finish the guide by weekends, please ping me tomorrow evening [14:00:35] HisShadow, no problem [14:00:38] What arch is that fdrt? [14:00:44] itchka_ aarch64 [14:01:13] bero i built rootfs-synquacer.tar.xz can try install it [14:01:20] Wow that should speed things up a bit!!! [14:01:38] synquacer and TaiShan should be close enough [14:10:58] bero im pretty sure that predator-helios can't build riscv64, and need to install qemu packages [14:11:09] its always produce [14:11:10] DEBUG util.py:587: Failed: [14:11:12] DEBUG util.py:587: rpm-helper-0.24.17-9.noarch [14:11:13] DEBUG util.py:585: BUILDSTDERR: Error: Transaction failed [14:43:18] hi [14:43:23] see this https://www.phoronix.com/scan.php?page=news_item&px=Mesa-2020-PGO-LTO-Builds [14:43:48] yet again "WOW" news, that someone compiled something with LTO [14:44:15] somewhat fake news, as compiling mesa with PGO may be stupid [14:44:45] unless you are compiling mesa with PGO on your own hardware [14:53:11] exactly... [14:53:59] Next up: Oh WOW! Ubuntu is now 1000 times faster at sorting an already sorted list because that's how they set up their PGO profile for the sort tool! Ubuntu is great! Let's all pray to our God Shuttleworth! [14:55:13] fdrt: checking... [14:57:57] fdrt: you're right, the qemu bits weren't installed... Installing and restarting docker [14:58:42] no need to restart docker [14:58:46] just install qemu bits [14:59:03] already done [15:01:51] do we have any strong opinions on KUserFeedback ? [15:23:40] tpg: I don't... Looks like a tool that could provide some interesting feedback, but also like a tool that I doubt anyone will actually use [15:24:20] crazy: itchka_: Interesting news on the Predator power plug issue -- it's even weirder than we thought and seems to be caused by the GPU. https://bugzilla.kernel.org/show_bug.cgi?id=203035 [15:27:19] AngryPenguin i'm importing rust stuff to abf [15:30:15] itchka_: The workaround listed on that bug report is great, the box is now MUCH faster [15:30:26] echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level [15:30:27] echo "2 3" > /sys/class/drm/card0/device/pp_dpm_mclk [15:30:27] echo "3 4 5 6" > /sys/class/drm/card0/device/pp_dpm_sclk [16:01:34] bero: Investigating [16:15:40] .chair [16:15:59] * .chairs [16:16:58] Meeting ended by bero. Total meeting length: 1446 minutes