16:20:53 <itchka> #startmeeting
16:20:53 <chwido> Woof! Let's start the meeting. It's Wed Jan 30 16:20:53 2019 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:20:53 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:20:53 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:20:53 <chwido> Have a good meeting, don't bark too much!
16:21:16 * bero barks at chwido
16:21:35 <crazy> here too just somewhat ill .. let me get my hot tea first
16:22:05 <itchka> Here's the agenda
16:22:11 <itchka> 1. Report: ABF, cooker
16:22:12 <itchka> 2. Lx4 Release progress
16:22:14 <itchka> 3. AIB
16:22:15 <itchka> 4: AOB
16:22:33 <itchka> Ok I could do with a cuppa too.
16:23:04 <bero> come to think of it, me too
16:24:15 <rugyada> OM tea time
16:25:39 <itchka> Ahhh that's better :)
16:26:27 <itchka> A cup of malty Assam...
16:27:25 <rugyada> chwido: pingall tea meeting time
16:27:25 <chwido> tea meeting time
16:27:25 <chwido> Afsane[m] ashledombos[m] ben779 ben79 bero ChanServ christann chwido crazy dsilakov Eighth_Doctor fdrt_ gmoro herde[m] HisShadow_ Hobbyboy itchka itchka[m] JLP King_InuYasha Megaf Pharaoh_Atem proyvind RSSBot[afsanemat rugyada ruru[m] TravisCI[afsanem Xu_R
16:27:25 <chwido> An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:27:42 <fdrt_> bero add me to c64 please
16:27:49 <bero> fdrt_: sure
16:29:08 <crazy> back
16:29:28 <itchka> Ok lets start
16:29:34 <itchka> #item 1
16:29:53 <Eighth_Doctor> Hey
16:30:00 <itchka> #topic Report: ABF, cooker
16:30:21 <itchka> Off you go bero.
16:31:15 <fdrt_> ABF working :)
16:31:46 <bero> Currently things are looking good on both sides... ABF is working very well currently, and cooker is about as ready for release as it can get
16:32:03 <itchka> Good work fdrt_ :)
16:32:29 <bero> IMO we can go for beta -- before the final, we should make sure the Java mess is fixed up some more and the lxqt 0.14 update is finished
16:32:39 <bero> (currently happening)
16:32:39 <Eighth_Doctor> When do we plan to branch Lx4?
16:32:51 <bero> at RC time
16:33:46 <Eighth_Doctor> Ok, so then we should have the mirror stuff working before then
16:34:15 <Eighth_Doctor> I need to tweak the release and repos packages for that
16:34:33 <crazy> bero: bug 2420 need be solved first .. we broke lang-packs logic of any sort .. also dnfdragora-updater need fixing , I know how already just didn't got to develop an patch
16:35:18 <itchka> bero: Ok I'm still nervous about the beta label from the testing point of view. If we are not splitting QA can only address testing bugs on an ad hoc basis.
16:35:25 <Eighth_Doctor> We should use the rich dependencies for that
16:35:30 <crazy> bero: also I've fixed znver1 detection in dnfdragora
16:36:28 <rugyada> bero:  please rebuild om-cc and om-welcome, so we can see how many damages I made (or not) :P
16:36:38 <itchka> We also need to address the plethora of i586 files in the i686 repo.
16:36:42 <crazy> bero: anyway firsr we need fix runtime deps of the updater .. py3 xdg , cairosvg ( this one need fixing , rebuild ) -pillow ( missing )
16:37:57 <itchka> crazy: Do they just need bumping and a rebuild (except for pillow)?
16:38:47 <christann> Hi
16:38:54 <crazy> cairosvg need bumping and fixing
16:38:58 <itchka> christann: Hi
16:40:08 <itchka> I'm doing that now.
16:40:36 <bero> itchka: A simple "rm *i586.rpm" should fix that
16:41:15 <itchka> bero: Ok if there are no other implications I'll deal with that.
16:41:18 <bero> crazy: guess we need to rework the way the dictionaries are packaged then... Guess upstream's way of dealing with them isn't that great
16:41:33 <crazy> Eighth_Doctor: ( btw not sure why you got such much nicks :P ) .. is something like this for subprocess ok ? so we run dragora with wait=True and updater =false since seems to care self ? https://dpaste.de/chkR
16:41:46 <bero> itchka: the implications of that are just that stuff that never rebuilt since we switched i586->i686 will be gone -- nothing too bad
16:42:11 <bero> crazy: I've seen the znver1 fix, guess we need to extend that for armv7hnl too
16:42:22 <crazy> Eighth_Doctor: for a quick fix should be fine I think
16:42:59 <itchka> bero: I have seen duplicates where the same package exists for both arches.
16:43:48 <bero> itchka: yes, that is normal... When we did the "mv i586 i686" for bootstrapping, abf didn't understand that those i586 packages are just old versions that need to be removed when a newer version of the same package is built
16:43:55 <crazy> bero: also we need run sort test over whole repo for 2421 to find broken packages
16:45:21 <crazy> bero: but other then these things look good to me
16:45:59 <HisShadow_> bero: the abf does this by keeping track of file names in the previously published packages, by renaming them you break that
16:46:06 <crazy> bero: and probably we should split the -updater too .. there are some other updaers we could use :)
16:47:20 <HisShadow_> itchka: i'm working on what you asked me to do btw
16:48:09 <HisShadow_> itchka: I also need to upgrade gems that are used in ABF, they are kind of outdated from when I started in 2015-16
16:48:10 <itchka> HisShadow_: Thank you that is really good news.
16:50:15 <AngryPenguin> bero: maybe you know what package contains "QSignalSpy" ? I need it for shotcut
16:50:25 <itchka> HisShadow_:  Do you have a time to live estimate?
16:50:31 <crazy> AngryPenguin: qt5-base
16:51:04 <crazy> AngryPenguin: in OM some of the subpackages dunno which right now
16:51:16 <bero> QtTest to be more accurate (that is a subpackage of -base)
16:51:29 <bero> You probably want to add BuildRequires: cmake(Qt5Test) or so
16:52:22 <AngryPenguin> bero: crazy: thanks
16:52:37 <crazy> yw
16:54:02 <itchka> Just to let you all know..I had a discussion with HisShadow_ last week after the meeting about the publishing whitelist filter we discussed last week. He has kindly started to implement it so we should be able to filter out rogue packages during the beta phase.
16:54:56 <HisShadow_> itchka: just to clarify, you want a whitelist of packages that can be published or a black list of packages that can't be published? I can actually do both, it shouldn't be hard
16:55:29 <itchka> A whitelist of packages that can be published please.
16:55:42 <bero> both would be really useful for the future
16:57:28 <itchka> Yes I guess applying the blacklist to the update repo of a release would allow us to do all the plasma updates without disruption
16:58:50 <AngryPenguin> gtbase and cmake5test not help still -  fatal error: 'QSignalSpy' file not found
17:00:09 <bero> AngryPenguin: maybe a missing -I or something... the file lives in /usr/include/qt5/QtTest
17:01:43 <itchka> fdrt_: Is there any chance you could fix the "abf put" function in abf-console-client" It doesn't update the abf.yml file automatically with new sources anymore.
17:01:55 <fdrt_> i will look on it
17:02:03 <fdrt_> could you open github issue for that?
17:02:11 <itchka> sure
17:05:42 <HisShadow_> itchka: what do you mean by "a time to live estimate"?
17:06:37 <itchka> HisShadow_: How long will it take? :)
17:06:54 <itchka> fdrt_: Issue opened.
17:07:00 <fdrt_> cool
17:08:11 <itchka> It's probably a python3 issue..
17:09:05 <itchka> does abb do the abf.yml file?
17:09:40 <bero> yes
17:09:58 <HisShadow_> itchka: i'll try to get it done as soon as possible, doesn't help that I'm kind of busy with my job now, maybe this weekend or the middle of the next week hopefuly
17:10:39 <itchka> HisShadow_: That would be fine; thanks
17:16:18 <itchka> bero: Does abb automatically update abf.yml .  It's not really clear from the readme.
17:17:53 <itchka> so is it "abb store abf.yml"  that does the job?
17:18:29 <bero> you don't abb store the abf.yml file...
17:18:46 <bero> abb store whatever.tar.xz sends whatever.tar.xz to file-store and also adds it to .abf.yml
17:19:33 <itchka> Oh ok :) Just like the console client used to do it then leat till it broke
17:20:43 <itchka> Ah so you have to give it the source file. Ok so not quite like "abf put" which doesn't need the tarball name.
17:22:16 <bero> I've never used abf put
17:22:32 <itchka> I get access denied
17:23:49 <bero> echo auth=username:password >~/.abbrc
17:24:24 <bero> (where, obviously, username is your username and password is your password)
17:24:43 <bero> .abbrc is parsed as a shell script, so if your password contains a $ or so, you need to escape it
17:25:45 <itchka> Ok thanks..no idea what my filestore password is. Let's see if I can connect
17:25:58 <HisShadow_> it's the same one you have on abf
17:26:45 <itchka> Ah ok
17:26:48 <itchka> Thanks
17:30:20 <itchka> H'mm still not woking. No denied error now though.
17:30:48 <bero> what do you get now?
17:31:05 <itchka> abb store CairoSVG-2.2.1.tar.gz
17:31:07 <itchka> sha1sum = '2f9ed1a4f5fc8565750c6abec8cc2c99b025e7e3'
17:31:08 <itchka> check if file also stored... no
17:31:10 <itchka> try to store file CairoSVG-2.2.1.tar.gz
17:31:11 <itchka> check if file stored correctly... error: can't check
17:31:13 <itchka> curl output:
17:31:14 <itchka> aborting...
17:31:27 <bero> hmm, that looks right, except for those last 3 lines
17:31:34 <bero> did .abf.yml get created/updated?
17:31:46 <bero> also, is curl installed?
17:32:06 <itchka> Not updated checking on curl.
17:32:38 <itchka> curl-7.63.0-3.x86_64
17:32:50 <bero> that's what I have too
17:32:54 <bero> so that one works...
17:33:41 <itchka> I'll set -x and see if I can get more info
17:35:19 <itchka> Ir uses wget as well maybe it's that I don't have
17:36:58 <itchka> Nope got that too.
17:38:00 <bero> does your password contain any odd characters? $, space, `, ...?
17:39:38 <itchka> it has an @
17:40:03 <itchka> my loging that is
17:40:06 <bero> that may confuse curl...
17:40:19 <itchka> I'll try escaping it
17:42:32 <itchka> single backslash made no difference is there any other method?
17:46:02 <rugyada> what meeting topic now we are now?
17:47:00 <itchka> Item 1 abf and cooker
17:49:25 <itchka> #share New tools being created to control the flow of new packages into the repositorys. It is hoped this will minimise the possibility of breakage during major updates.
17:55:50 <itchka> crazy: I've fixed python-cairosvg locally just need to upload the new sources and I can build it on abf.
17:57:34 <itchka> Anything more on cooker?
17:57:41 <itchka> abf..
18:01:01 <itchka> bero: It's the @ https://stackoverflow.com/questions/10060093/special-characters-like-and-in-curl-post-data
18:07:03 <crazy> itchka: if you go with 2.x then I guess you fixed pillow too ;) afaik cairosvg 2.x need lxml and pillow
18:08:24 <itchka> You want python2-cariosvg ?  python2 is no longer supported.
18:09:09 <crazy> itchka: no .. I meant cairosvg version not python version
18:10:31 <itchka> H'mm that must be part of cairo.
18:12:05 <itchka> libsvg-cairo?
18:12:44 <itchka> crazy ^^
18:14:05 <crazy> itchka: no there py2/py3 cairosvg 1.0.xx and py3 only cairosvg 2.x see https://pypi.org/project/CairoSVG/ for what changed to 1.0.x
18:14:31 <crazy> you'll notice :
18:14:35 <crazy> Drop Python 2 support
18:14:35 <crazy> Drop pycairo support
18:14:35 <crazy> Rely on cairocffi, lxml, cssselect, pillow and tinycss
18:14:46 <crazy> :D
18:15:39 <crazy> I thin on latest version lxml dep gone .. but in general different depends to 1.x series
18:15:44 <crazy> *think
18:16:31 <itchka> Yes the earlier versions supported it but it's not python-cairosvg that you want is it?
18:17:25 <crazy> itchka: no we can use latest one .. is what I meant if you go with 2.x.x you fix the missing pillow package too :)
18:18:40 <bero> We have pillow
18:18:51 <bero> it's just named differently because it replaced some predecessor
18:18:55 <bero> python-imaging or so
18:18:55 <itchka> crazy: Ok I think I've fixed abb now so I'll try and build it on abf.
18:18:57 <bero> let me check
18:19:07 <crazy> bero: oh is why I could not find it by name
18:19:26 <bero> yes, it's python-imaging
18:19:34 <crazy> ok :D
18:19:49 <bero> path name is also still PIL (from Python Imaging Library) in pillow upstream
18:19:57 <bero> that's why we opted not to rename the package for now
18:20:06 <itchka> should I still update python-cairosvg?
18:20:08 <bero> just in case pillow gets discontinued and PIL gets revived or so
18:21:26 <crazy> itchka: yes
18:36:49 <itchka> Ok shall we move on
18:36:55 <itchka> #item 2
18:37:33 <itchka> #topic Lx4 Release progress
18:39:41 <itchka> Ok I guess we need to do a beta release soon. crazy I guess you have some things to finish and it would be nice if we could have HisShadow_ s lists in place before we release. I guess this would put us towards the end of next week.
18:41:18 <itchka> Any thought's?
18:52:20 <bero> IMO that's too late already
18:52:27 <bero> We should have released the final a year ago
18:52:40 <rugyada> ‎bero: will you please rebuild om-cc and om-welcome ?
18:52:59 <bero> delaying the beta waiting for infra that we don't really need if we follow a few simple rules isn't a good idea IMO
18:53:03 <bero> rugyada: sure
18:53:12 <rugyada> thanks :)
18:54:07 <christann> It is working well on 2 machines here.  I think that it is ready for a beta release.\
18:54:19 <rugyada> bero: om-welcome *should* be pretty good, om-cc needs more fixes.
18:55:12 <rugyada> bero: I fixed everything I found, and some more need to be discussed what we want there.
18:55:47 <bero> This is a good place and time to discuss what we want there...
18:56:24 <rugyada> bero:  mostly on om-cc we have a lot of old drak* whatever
18:56:40 <bero> yes -- should get rid of those...
18:57:19 <ben79> <itchka> Any thought's? >>> Yes, we're going to dither and discuss and take weeks to get a beta release done of we don't get a move on to just do it.
18:57:31 <itchka> There's a very important thing I noticed. The plasma tools do not provide for any group management. Thus we will have to retain drakuser.
18:57:43 <bero> kuser does
18:57:59 <rugyada> Configure your dvb devices
18:58:01 <rugyada> Install all the necessary dirver to use your dvb devices
18:58:03 <rugyada> /usr/bin/drakdvb
18:58:04 <rugyada> ******
18:58:06 <rugyada> Configure an UPS
18:58:07 <rugyada> Install all the necessary program to manage and configure your UPS
18:58:09 <rugyada> /usr/bin/drakups
18:58:10 <rugyada> ******
18:58:12 <rugyada> Add network hosts
18:58:13 <rugyada> Add all the known hosts of your network
18:58:15 <rugyada> /usr/bin/drakhosts
18:58:16 <rugyada> ******
18:58:18 <rugyada> Change the hostname
18:58:19 <rugyada> Change the name of your computer, or set particular DNS
18:58:20 <rugyada> /usr/bin/drakconnect --internet
18:58:22 <rugyada> ******
18:58:24 <rugyada> Configure internet Sharing
18:58:25 <rugyada> Share your internet connection
18:58:27 <rugyada> /usr/bin/drakgw
18:58:28 <rugyada> ******
18:58:30 <rugyada> Configure a proxy
18:58:31 <rugyada> If you are into a company network, probably you should set the right proxy
18:58:32 <rugyada> /usr/bin/drakproxy
18:58:34 <rugyada> ******
18:58:35 <rugyada> Configure a VPN
18:58:37 <rugyada> All the necessary to create and manage a VPN
18:58:39 <rugyada> drakvpn
18:58:40 <rugyada> ******
18:58:41 <rugyada> Configure a NFS share
18:58:43 <rugyada> Change or configure your NFS directory scharing
18:58:45 <rugyada> /usr/bin/draknfs
18:58:46 <rugyada> ******
18:58:48 <rugyada> Configure a SMB share
18:58:49 <rugyada> Change or configure your NFS directory scharing
18:58:50 <rugyada> /usr/sbin/draksambashare
18:58:52 <rugyada> ******
18:58:54 <rugyada> Configure a FTP Server
18:58:55 <rugyada> Install and configure your FTP server
18:58:57 <rugyada> /usr/sbin/drakwizard proftpd
18:58:58 <rugyada> ******
18:58:59 <rugyada> Configure a SSH Server
18:59:01 <rugyada> Install and configure a SSH server
18:59:02 <rugyada> /usr/sbin/drakwizard openssh
18:59:04 <rugyada> ******
18:59:06 <rugyada> Configure an Apache2 Server
18:59:07 <rugyada> Install and configure your http server
18:59:09 <rugyada> /usr/sbin/drakwizard apache2
18:59:10 <rugyada> ******
18:59:11 <rugyada> Configure a DHCP Server
18:59:13 <rugyada> Install and configure your DHCP server
18:59:15 <rugyada> uuuuh... sorry for flooding
18:59:37 <bero> I'm pretty sure none of those will actually work...
18:59:37 <itchka> Is kuser what comes with the system setting suite?
18:59:39 <bero> do they?
18:59:53 <bero> itchka: no, kuser is a port of the old kde4 user manager to new libraries
19:00:03 <ben79> # dnf search kuser
19:00:03 <ben79> kuser.x86_64 : Users and groups manager for KDE4
19:00:07 <ben79> KDE$ ?
19:00:13 <bero> used to be ;)
19:00:14 <ben79> KDE4 ?
19:00:17 <bero> need to update the description
19:00:26 <bero> we (mostly crazy) patched it to use newer libraries
19:01:04 <ben79> should we also make kuser a default package?
19:01:09 <itchka> Should we put that in the system setting suite then to replace the rather crap thing that is there at the moment.
19:01:13 <bero> I think so
19:05:02 <ben79> # action change description of kuser from "for KDE4" to something more appropriate
19:05:49 <ben79> # action make kuser default package and add to SystemSettings5
19:07:34 <crazy> well kuser would need some patch to at least check root .. it have ZERO kauth support nor any root check at all
19:07:47 <ben79> For OM-CC do we rewrite the modules we have software for and remove the ones we don't have software for?
19:08:11 <bero> ben79: yes, AFAIK that's the only realistic way
19:08:30 <crazy> bero: but while at that .. you really want keep that none sense root restrictions in kate/dolphin ?
19:08:51 <bero> no... they don't make sense IMO
19:09:11 <crazy> bero: konsole already removed that martin flösser shit
19:09:48 <bero> IMO it would even make sense to have menu entries for "Dolphin (as root)" and "Konsole (as root)"
19:10:12 <ben79> Realistically for replacing drakx tools not all will be replaced for Lx 4 release it will continue to be a WIP >>> Users aren't doing a great job of telling us what they want so we can legitimately say we have provided all you asked for! You don't ask so we did not do.
19:10:50 <rugyada> bero: I'd like to have in om-cc a handy link running omv-bug-report, but I did not get to have any command working (the command in /apps > file ) Maybe you can look at it..
19:10:50 <crazy> bero: ok then take : https://gitweb.frugalware.org/frugalware-current/raw/master/source/kde5/dolphin/allow-root.patch and https://gitweb.frugalware.org/frugalware-current/blob/master/source/kde5/kate/allow-root.patch
19:10:55 <crazy> bero: yes
19:11:31 <crazy> uhm should be https://gitweb.frugalware.org/frugalware-current/raw/master/source/kde5/kate/allow-root.patch
19:11:38 <itchka> kuser seems ok it does ask for authentication but it seems to want the root pwd rather than sudo even though it appeared to be invoked by kdsudo
19:11:59 <crazy> itchka: run as user from konsole
19:12:11 <crazy> it won't ask
19:12:27 <ben79> shouldn't root passwd and sudo be same? How many sysadmins is to many?
19:13:06 <crazy> ben79: itchka that's a matter of how you configure sudo
19:13:10 <itchka> It errrors out on /etc/shadow
19:13:29 <itchka> but still runs
19:13:36 <crazy> itchka: but is broken
19:13:58 <crazy> you don't have permissions on /etc/shadow as user
19:14:07 <itchka> Yeah it won't be writing to any files.
19:14:16 <ben79> crazy: itchka: If I run kuser from Konsole as user I get: Error opening /etc/shadow for reading.
19:14:58 <itchka> crazy: Root is ok on kate here if you are sudo
19:15:01 <crazy> that one really need have :  if (getuid() != 0) { .. nice_error_message }
19:15:19 <ben79> crazy: itchka: If I run kuser from Konsole as user and try to change something I get: Cannot open file /etc/passwd.bak for writing.
19:15:20 <crazy> itchka: that is none sense notice ?
19:15:44 <itchka> Cerianly is :)
19:15:52 <itchka> Certainly
19:16:33 <crazy> itchka: and no it depends on your sudo configuration again .. so if you allow 'root' why you deny 'root' kind weird martin logic trying to hide real bugs in kwin/session code
19:18:05 <crazy> itchka: and much more weird .. if you allow the desktop to run as root how can you deny dolphin then or just some parts .. is just agenda of that guy
19:18:31 <ben79> overthinking?
19:20:25 <crazy> ben79: there is no difference in the end if you run sudo , kdesu , gksu or run is pure root you run it with root rights .. that is . The bug he is7was tring to hide will occur either way .. with sudo foo or with foo as root
19:20:34 <ben79> Regarding kate and kwrite as root >>> as of right now I can open most files in / and edit them and then enter root passwd to save rewritten file, Ergo I can edit stuff in / all I want to with them.
19:20:56 <crazy> you cannot run kuser as 'user'
19:21:19 <crazy> but we can patch it to tell that
19:21:24 <ben79> I couldn't
19:21:25 <bero> at least not unless you do some seriously weird stuff...
19:22:16 <bero> "chgrp admins /etc/shadow /etc/group /etc/passwd; chmod g+rw /etc/shadow /etc/group /etc/passwd" or the likes would probably make kuser work
19:22:38 <ben79> As I recall in KDE4 kuser was not part of SystemSettings, also you had to open it with root passwd, don't think it was designed to run as user at all
19:22:47 <crazy> bero: really now .. you allow to run the whole desktop as root but parts ? .. so say start it root , log in and then you can use all but dolphin and kate ? c'mon
19:22:57 <crazy> bero: we should not do that
19:23:08 <bero> definitely not
19:23:23 <crazy> bero: we should add a : if (getuid() != 0) { check in kuser main()
19:23:28 <bero> I was wondering if there could be any use case for it for any users wanting to do weird stuff
19:23:31 <crazy> ( for now )
19:23:49 <bero> e.g. some weirdo company giving HR access to user management but not system settings or so
19:24:00 <ben79> Wow! OMA is making KUser Great Again.
19:24:16 <bero> but they can accomplish that by other means as well if they really want to
19:24:21 <bero> just limit sudo commands...
19:24:30 <itchka> How does the user manager in system settings work then?
19:24:49 <ben79> It wasn'
19:24:52 <crazy> bero: then that company sucks or is clueless on howto set the system for such usage
19:25:03 <crazy> since is simple
19:25:45 <ben79> the user manager in systemsettings5 does not really work, it does not manage anything
19:26:22 <crazy> that thing is broken and useless crap
19:26:26 <itchka> The fix for @ in the user name for abb store <archive> is to substitute %40 as the @
19:30:38 <itchka> crazy: python-cairosvg building
19:30:47 <crazy> itchka: thx
19:32:56 <itchka> If we are to spin a beta we need to start on the announcements. I guess it would be good to try and ship the nazi drivers at the same time to minimise on teh amount of grizzling.
19:33:20 <crazy> bero: for such an 'restricted' system you can deny anything but the allow_cmd list for users and then change default to rootpw on sudo and _not_ only users with root ( or any root group ) or users/groups configured to use somethings different can use sudo on everything
19:34:57 <crazy> eg this ( real example from our server ) .. :
19:35:04 <crazy> crazy@andromeda:~$ sudo vim /etc/shadow
19:35:04 <crazy> [sudo] password for [root@andromeda]:
19:35:48 <crazy> no such default command for user crazy or any of his group so it asks 'root' pass .. you don't know root pass ? .. well then you cannot do these :P
19:36:20 <crazy> ofc use crazy knows the root pass but is how it should work for such systems
19:36:43 <bero> sure
19:38:16 <crazy> I have much more weird setup on this server but is our main box so I need too have some restrictions
19:42:32 <crazy> also something else about the weird kill-root code .. they kill root on Linux but allow it on windows .. sureeeeee where you get a worm by just looking it booting rofl
19:49:50 <bero> probably because windoze doesn't have getuid() or so
19:53:14 <ben79> <itchka> If we are to spin a beta we need to start on the announcements. I guess it would be good to try and ship the nazi drivers at the same time to minimise on teh amount of grizzling.
19:54:14 <itchka> dsilakov: Looks like you are chasing down the same problem as I am python-setuptool-scm :)
19:54:19 <crazy> bero: they have API to get admin
19:55:20 <crazy> ben79: actually nvidia driver need sorting that spec file is from back 2008'ish or the like
19:55:41 <itchka> Yes ben79 we need a number of announcements. Do we need to revise anything in the release notes?
19:56:04 <itchka> crazy: It still works remarkabley well.
19:56:25 <crazy> first I would drop there is whole 32bit part .. do not support it .. we did a time but is such broken if you don't run some ancient setup
19:56:31 <itchka> I have updated it a bit though.
19:56:41 <crazy> itchka: well not really ..
19:57:10 <itchka> Only enough to make it work with the new manifests.
19:57:20 <crazy> goto nvidia on github and fid out how you can wipe 50% of your spec file by adding the now open sourced code
19:58:02 <bero> and of course any open bit is better than a closed bit...
19:58:31 <itchka> I don't have time for that now if I can update the source packages and build working rpms then that is going to have to be enough for now.
19:59:00 <crazy> after you wiped that 50% and 32bit crap .. you'll now notice you are on glvnd on cooker ..
19:59:25 <crazy> so symlinks and PATHs have to be corrected as well some 'missing' symlinks
20:00:01 <crazy> itchka: so no is not working by just dropping all to dkms and hope the best
20:00:21 <crazy> either we support or do not
20:01:22 <ben79> I don't think continuing with the current nvidia packages and approach is such a good idea
20:01:34 <itchka> Then the users will just have to build it from the .run file as I don't have time at the moment to do anything else.
20:01:40 <ben79> I thinks we need to start over with how we support nvidia
20:02:07 <ben79> and Lx 4 is the time to do it, OR we decide to not support nvidia at all
20:02:20 <crazy> itchka: NO we cannot support systems installed that from run
20:02:30 <crazy> these users are out of _any_ support
20:02:46 <crazy> please think about what that .run file does
20:03:14 <crazy> https://github.com/NVIDIA/nvidia-xconfig
20:03:19 <crazy> https://github.com/NVIDIA/nvidia-settings
20:03:35 <crazy> https://github.com/NVIDIA/nvidia-persistenced
20:03:55 <crazy> https://github.com/NVIDIA/nvidia-modprobe
20:04:19 <crazy> or even : https://github.com/NVIDIA/nvidia-installer
20:04:54 <crazy> so all these need be packages rm wiped from that spec .. no reason to use the blobs for these
20:04:58 <itchka> Well of course not we don't officially support nVidia any way I usually just do it as a favour to the people who can't get what they want from nouveau.
20:05:21 <ruru[m]> let's add a non-free-contrib repo and put nvidia unsupported there :)
20:05:41 <crazy> itchka: but then rm -rf nvidia* packages , and be honest to the users
20:06:23 <crazy> itchka: you cannot throw broken packages which looks working .. then point users to install from .run which breaks mesa , X , etc
20:07:33 <itchka> Look guys this is just noise we need to get on with the other stuff. We don't enable the restricted repos by default so nobody is being served broken packages.
20:08:28 <itchka> far better we spend time talking about how we are going to fix kuser so we can make a beta release.
20:08:44 <crazy> is simple .. we can support 'latest' driver only .. we can package all open source parts or at least open in therms you can build from source .. and so you can corrct even some things in xconfig , etc .. then separate kernel-part from X part again and there we go .. no need for 10k line broke spec file , throws all to dkms at the end and well that is
20:10:15 <crazy> no dkms at all , forget that , all dkms should die .. what we need is a list in ABF called kernel modules-rebuild , bump kernel , once build fire rebuild of all the list
20:10:46 <crazy> and should not matter is cooker , release etc
20:10:59 <ben79> We should not wait to decide how we are properly going to either support or not support nvidia, that is a big mistake IMO.
20:11:06 <crazy> if we go to support 'something' then we support it , if now wipe away
20:12:27 <crazy> ben79: we cannot support in term of 'driver does not work on my GPU' or the driver freeze my system .. all we can do is to have prober .rpm for kernel modules and X parts and that is all
20:13:10 <crazy> ben79: why we want that anyway ? .. well I do hate crapzilla too but we really do NOT want users to break the systems by running .run files
20:13:40 <ben79> Huh? I must have missed something
20:13:47 <crazy> install rpm , remove rpm is simple .. nothing broken , we got glvnd
20:14:11 <bero> crazy: you may want to pull https://github.com/OpenMandrivaAssociation/kuser/blob/master/kuser-16.08.3-rootonly.patch
20:14:27 <itchka> Yes it's all very well and good to go on some crusade about this but I don't see anyone offering to do the work...
20:16:39 <ben79> I thought crazy was
20:17:06 <ben79> Otherwise the discussion is useless
20:17:58 <bero> the only box in which I have nazividia crap is an ARM box -- can't check if the binary driver works there
20:20:11 <itchka> Somebody on the forums built the latest .run and it worked for him once he used gcc anyways.
20:21:05 <itchka> Either way those drivers shouldn't be getting in the way of a beta release.
20:21:15 <AngryPenguin> *will work until next major kernel update
20:21:50 <itchka> That's pretty much always the case with them.
20:22:09 <ben79> So what does need to be done for a Beta release?
20:23:49 <AngryPenguin> in my opinion we should provide nv proprietary driver for lx4
20:24:04 <itchka> Well I guess kuser should be fixed if possible; dnfdragora if I understand correctly still has a crash but that may be fixed once I can get this draned python-cairosvg package to build on abf
20:24:15 <itchka> It builds ok locally
20:24:51 <bero> probably we want to get rid of the new myspell package split
20:25:07 <ben79> What about kuser is broken? Here it works like it did in KDE4, it was always like KDE Partition Manager, You always have to enter root password first
20:25:37 <bero> I just fixed kuser...
20:25:48 <bero> It now checks for the right user ID and is launched through kdesu by default
20:26:01 <itchka> Good, good :)
20:26:27 <ben79> Ah
20:26:47 <ben79> Ok then we are ready to release beta on Friday?
20:28:25 <ben79> Or maybe just maybe, build a new ISO and test for 3 days and then release Beta?
20:28:37 <itchka> Are any changes to the release notes required?
20:29:13 <ben79> Yes, of course, that will be taken care of
20:29:40 <ben79> by our pubic relations staff
20:29:57 <ben79> aka ruru[m] and rugyada
20:30:34 <itchka> Well dnfdragora needs to be working properly before we spin.
20:30:49 <ben79> what does spin mean?
20:31:07 <itchka> create an iso
20:31:41 <ben79> What isn't working with dnfdragora?
20:32:26 <itchka> Last I saw here there was some sort of crash that locked up dnf
20:32:37 <itchka> I don't know the details
20:32:48 <ben79> Is there a bug report?
20:32:54 <rugyada> yes, we'll review release notes and change what changed accordingly, then someone from devs would be good to review the changes to see if everything is ok
20:33:01 <crazy> ben79: updater crashing
20:33:50 <ben79> is there a bug report?
20:34:25 <crazy> probably not but a video :P
20:35:12 <rugyada> cannot we remove updater from try?
20:35:19 <crazy> I know on how to fix it ( for now ) .. I just don't feel so good .. and coding with 39.8 fever is not such a good idea
20:35:41 <rugyada> tray*
20:35:44 <ben79> Have some chicken soup and get well then!
20:36:14 <ben79> Maybe some sleep too.
20:36:49 <rugyada> crazy: take care of you please
20:37:12 <crazy> ben79: I cannot sleep .. :/
20:37:31 <ben79> Yikes!
20:38:24 <bero> crazy: do you want me to send you a recording of my German teacher in school? He reliably put me to sleep some 20 years ago... ;)
20:38:37 <itchka> dnfdragora has dependencies in cooker/contrib
20:38:48 <crazy> ben79: I've explained bero PM what is wrong not sure he saw
20:38:57 <crazy> itchka: then these need be moved
20:39:01 <bero> I haven't... Let me check
20:39:18 <bero> itchka: which dependencies? The need to move to main...
20:40:02 <crazy> bero: you should set you PM stuff to turn on red on new messages :P is what I am doing here ..
20:40:08 <itchka> They all stem from python-cairosvg I will do a list
20:40:22 <ben79> So if we have to wait for dnfdragora to be fixed to release we
20:40:43 <ben79> So if we have to wait for dnfdragora to be fixed to release we're talking what  a week or two for beta release?
20:42:04 <ben79> I see, updating 86 packages with dnfdragora and it gets constipated
20:42:37 <crazy> ben79: thee is a fixme to split updater in separate package
20:42:47 <crazy> just let us fix the crash first
20:49:35 <ben79> So Beta release time frame is "Don't know yet"
20:50:34 <bero> IMO we shouldn't delay the beta any longer, it's been more than a month since the alpha already
20:50:47 <bero> we're getting to a point where the release will be obsolete the minute it's made
20:51:10 <ben79> Yes we are way overdue for some release
20:51:10 <bero> So if we can't fix that crash in time, let's just disable the updater for the beta
20:51:30 <ben79> So we do a release and call it Alpha2 and make itchka happy?
20:51:46 <bero> then we'd have to go straight from alpha2 to rc to keep a sane schedule...
20:52:21 <ben79> We've already broken any sane schedule
20:52:37 <bero> agreed, but let's not make it worse than it already is
20:52:38 <ben79> We're going to have to do our usual insane instead
20:52:58 <bero> 4-random-snapshot-20190130 is much better than 3 ever was
20:53:00 <ben79> Then we do a Beta release as is
20:53:51 <bero> I'd be very much in favor of that... It's better than the 3 release, and we know what we still need to fix
20:53:56 <itchka> crazy's needed packages are building now if they complete you may well have a fixed dnfdragora
20:54:16 <rugyada> I'd like to have a few time to test om-welcome at least before B release
20:55:26 <ben79> Back to my question: Do we at some time build an ISO, test for 3 days and release as Beta if nothing big, or test for 24 hours?
20:55:53 <itchka> Another thing that we should update are all the Apple I phone support libs which I think have now been brought up to work with IOS 12
20:55:58 <ben79> if no big issue come up I mean
20:56:45 <ben79> Let's not delay release on something like that please
20:57:16 <bero> ben79: sounds good to me
20:57:26 <bero> rugyada: would the 3 days be good enough?
20:57:40 <ben79> bero: let's decide on testing for 3 days or 24 hours
20:57:42 <bero> itchka: Let's update those bits, but without delaying the beta for it...
20:57:55 <rugyada> bero:  yes
20:57:58 <ben79> realistically 3 to 5 days
20:58:56 <rugyada> bero:  the sooner you rebuild them the better :)
20:58:57 <ben79> there aren't that many people testing
20:59:47 <ben79> I heard 3 days? OK with me.
21:01:20 <rugyada> > ‎<‎bero‎>‎ So if we can't fix that crash in time, let's just disable the updater for the beta <=== +1
21:11:45 <crazy> rugyada: we can fix crash , in fact I posted bero patch
21:12:01 <crazy> rugyada: already debugged .. I know why crashing
21:13:39 <rugyada> crazy:  ok that's great, but just in case whatever goes wrong let's disable and release
21:16:30 <rugyada> only showstoppers/blockers must prevent beta release
21:18:24 <crazy> we can disable for iso but that won't fix the problem
21:19:11 <crazy> is just a rm line of xdg autostart in iso script and is gone , won't start
21:19:49 <crazy> first we need fix myspell* stuff anyway
21:32:09 <itchka> ben79: Do you have any bugs?
21:32:38 <ben79> dnf update shows Traceback: RuntimeError: TransactionItem not found for key:
21:32:38 <ben79> https://issues.openmandriva.org/show_bug.cgi?id=2421
21:32:38 <ben79> myspell-en_GB and myspell-en_US removed from system.
21:32:38 <ben79> https://issues.openmandriva.org/show_bug.cgi?id=2420
21:36:01 <itchka> Ok ben79 do you agress that there is no need to discuss these as they are well know and already being targeted?
21:37:02 <crazy> ben79: and this https://crazy.dev.frugalware.org/py3-crash-2019-01-27_18.43.50.mkv ( the updater crash , has an report in the forums but cannot find it )
21:38:42 <ben79> https://forum.openmandriva.org/t/dnfdragora-updater-python3-7m-closed-unexpectedly/2368
21:39:07 <crazy> yeah this
21:39:56 <ben79> Yes we can not discuss the bugs
21:40:25 <ben79> But we have not agreed to do whatever about a Beta release we need to do that at all costs
21:40:40 <ben79> Let's agree to do something
21:41:42 <ben79> # action as soon as new packages are built, and set of ISO's to be built and tested for 3 days and if no major issues, release as Lx 4.0 Beta
21:41:48 <ben79> like that
21:42:06 <crazy> ben79: btw cannot build anything yet .. I can upload you a patched updater.py you can test with
21:44:10 <ben79> can't build anything?
21:49:15 <crazy> ben79: I can probably but cannot concentrate myself doing these right now
21:50:11 <ben79> Yeah, and I just found myself doing something I shouldn't, trying to rush someone that is ill and needs rest
21:50:36 <crazy> ben79: wget https://crazy.dev.frugalware.org/updater.py
21:51:05 <crazy> ben79: now on your system stop updater then run dnfdragora --exit
21:52:25 <crazy> sudo rm -rf /usr/lib/python3.7/site-packages/dnfdragora/updater.py
21:52:44 <crazy> sudo cp updater.py /usr/lib/python3.7/site-packages/dnfdragora/updater.py
21:53:27 <crazy> now from konsole run dnfdragora-updater
21:53:50 <crazy> open dragora from dialog , close it , open updates etc
21:54:07 <crazy> at the end exit the updater .. you should not get any crash
21:54:43 <itchka> bero: I need these two new packages added to main they are needed by the latest python-cairosvg. I've created to git hub repos for them. They are python-cssselect2 and python-tinycss2
21:55:31 <itchka> Guys I'm startving so I'm going to grab a bite to eat.
21:56:31 <crazy> ben79: and sry for letting you test like this ..
21:56:50 <ben79> I still get the traceback errors: Traceback (most recent call last):
21:56:50 <ben79> File "/usr/lib/python3.7/site-packages/pystray/_base.py", line 236, in inner
21:57:42 <crazy> well dnf clean stuff
21:57:44 <ben79> and now I can't dnfdragora-updater to open
21:58:16 <crazy> if it crashed you can right .. run dnfdragora --exit first
21:58:32 <crazy> that is very strange login upstream but is how it is
21:58:39 <crazy> *logic
21:59:14 <crazy> ben79: but test that in VB , even live iso
21:59:46 <ben79> I'm testing it in an installed system now and it ain't working so well
22:01:30 <ben79> dnf clean all has no effect on those traceback errors never has for me
22:01:53 <bero> itchka: adding
22:02:07 <crazy> ben79: if your dnf crashed before .. backend is locked .. can't do anything about
22:03:48 <bero> itchka: all added (and python-cairosvg moved from contrib to main too)
22:05:26 <crazy> bero: we can try package plasma-pk-updates also but don't know that one at all
22:05:49 <bero> true... I haven't looked at it so far either
22:05:57 <ben79> $ dnfdragora --exit
22:05:57 <ben79> method return time=1548885940.750910 sender=:1.257 -> destination=:1.256 serial=6 reply_serial=2
22:05:57 <ben79> boolean true
22:05:58 <bero> but given experiences with discover, I don't really trust anything pk
22:06:02 <crazy> bero: is what Fedora uses .. ( probably to hide the updater bug reported back in 2016 ? :P )
22:06:10 <bero> then again it's likely better than nothing
22:06:12 <crazy> https://github.com/KDE/plasma-pk-updates
22:06:40 <crazy> bero: well we can split the updater
22:06:58 <crazy> and let user decide which to use ( if at all ? )
22:07:49 <crazy> that dragora updater will need some sort re-write .. I don't think it will ever work right  as is
22:07:56 <bero> already done
22:08:02 <crazy> we can duct pate it but well
22:08:04 <bero> (splitting it, that is)
22:08:11 <bero> looking at plasma-pk-updates now
22:08:12 <crazy> *tape
22:08:19 <crazy> bero: ok thx :)
22:09:31 <ben79> blackcrack was right >>> drakxtools had the greatest updater of all time all the way back in 2007
22:11:36 <ben79> anyway I can accept defeat, we'
22:11:40 <ben79> anyway I can accept defeat, we'
22:11:50 <ben79> anyway I can accept defeat, we're stuck in limbo again
22:12:07 <ben79> or is it purgatory
22:13:29 <ben79> also the fact we keep coming up with things needing fixing means that while we want to do a release we really aren't ready
22:15:21 <itchka> Unfortunately that does seem to be the case...
22:17:08 <itchka> It was always goung to be difficult with such a major change.
22:19:51 <ben79> We need to make a list, hopefully short, of what we need to have done for a beta release, and Please make the list an #action and #share
22:20:52 <ben79> kuser, already done, dnfdragora? not sure what we're doing with that but if discover/PK is best we can do for an update GUI I suggest we
22:21:00 <ben79> kuser, already done, dnfdragora? not sure what we're doing with that but if discover/PK is best we can do for an update GUI I suggest we'd be better off without
22:21:18 <ben79> anything else?
22:22:33 <itchka> If I can do it I'd like to fit in the iphone support libs. Should just be a version bump and a rebuild
22:22:38 <ben79> OR we can realize that trying to make absolutely everything work is beyond the scope of what such a small group can do and realized that things can be fixed after a release
22:23:17 <rugyada> I updated live system and got dragora-update package splitted (and removed)
22:23:39 <rugyada> good.
22:24:13 <ben79> Then I'm confused what we are waiting of to do a Beta release?
22:25:15 <rugyada> ben79: for sure can be fixed after a *Beta* release
22:26:20 <bero> plasma-pk-updates is building too
22:26:59 <rugyada> ben79:  the languages issue maybe
22:27:02 <rugyada> ?
22:27:41 <ben79> Don't see that as an impediment
22:27:43 <bero> IMO that's not worth delaying the beta either, it's not really broken, it just ties a couple of language variants together (e.g. no way to install en_GB but not en_US or vice versa)
22:28:01 <rugyada> perfect
22:28:08 <bero> but will try to fix that tonight anyway
22:28:16 <ben79> Everyone in this meeting is using Lx 4 right now right, so why can't we do a beta release?
22:28:19 <bero> it's probably one of the more serious things that would be "nice to have" before beta
22:28:50 * bero has been using Lx4 for > 1 year, other than c64 not booting, haven't had any serious issues for a while
22:28:56 <crazy> Problem: conflicting requests
22:28:56 <crazy> - nothing provides python-cairosvg needed by dnfdragora-updater-1.1.1-3.x86_64
22:29:12 <bero> crazy: yes, that one is currently in contrib
22:29:16 <ben79> Because everything does not work? Everytime we've done a release in the past we had things that did not work.
22:29:28 <bero> I've already moved it to main, but not rebuilt it afterwards because itchka was working on the package anyway
22:29:37 <bero> so when he's done and builds it, it'll be in the right place
22:30:23 <crazy> bero: you just need to tell me about myspell* going to be fixed or not before beta .. cause I need disable cleaning of langs from calamares when not
22:31:02 <bero> crazy: SHOULD be fixed in time, currently looking at rewriting that package generator, it's a little weird anyway
22:31:31 <crazy> bero: even when not is not a problem .. we have know issues site
22:31:42 * ben79 I'm running out of time.
22:31:57 * ben79 But I think we need to do a release period,
22:32:05 <bero> +1
22:32:20 <rugyada> +1
22:32:49 * ben79 We also need to prepare outseleves for the idea that our final release will have things that don't work completely or we will be developing Lx 4 for another year which I want no part of
22:33:09 <bero> same here
22:33:18 <bero> It's better than 3 in just about every way thinkable
22:33:22 <bero> that's good enough
22:33:27 <rugyada> agree
22:33:31 <bero> of course we'll have 4.1 or 5.0
22:33:36 <bero> and hopefully with LESS lag
22:33:41 <bero> I'd like to release at least 4.1 this year
22:34:02 <bero> we need to get back to more frequent releases
22:34:05 <ben79> When was Lx 3 released 2016 right, it's 2019
22:34:49 <bero> yes, not much of a surprise some people think the project is dead
22:35:03 <ben79> It damn near is dead
22:35:56 <rugyada> 3.03 at the end of 2017
22:36:02 * ben79 so now we need a cleanse and a resurrection
22:36:08 <ben79> Lx 3.0
22:36:22 <ben79> was that 2015 I think it was 2016
22:36:46 <bero> And we shouldn't repeat the mistake of more releases based on the branched 4.0 tree
22:36:47 <ben79> 3.03 does not count that is just updated packages which would happen anyway
22:36:56 <bero> that's part of what made the time between 3.0 and 4.0 so long
22:37:33 <bero> I'd say 4.1, based on cooker, later this year.
22:37:59 <ben79> and 4.1 has seperate repos from 4.0?
22:38:01 <rugyada> 3.01 end 2016, 3.0 Aug 2016
22:38:50 <ben79> there really was only one Lx 3 release the others were just spins or new ISO's with updated packages that is not a real release
22:39:15 <ben79> and that was a mistake to do that that wayt
22:39:27 <rugyada> bero: we need cooker ISOs built regularly for internal testing
22:39:53 <bero> ben79: yes
22:39:56 <bero> rugyada: fully agreed
22:41:04 <ben79> God, grant me the serenity to accept the things I cannot change,
22:41:04 <ben79> Courage to change the things I can,
22:41:04 <ben79> And wisdom to know the difference.
22:41:16 <rugyada> bero: that would be great under several points of view
22:41:44 <bero> ben79: +1
22:41:57 <rugyada> under=from
22:43:21 * ben79 and I struggle with the wisdom to know the difference...
22:43:53 <rugyada> ben79: and find workarounds when available :)
22:44:42 <bero> plasma-pk-updates finished building -- ready for testing
22:44:58 <ben79> rugyada: yep that too
22:45:09 <crazy> fdrt: ping .. lx3 builders still broken when added as stack etc
22:45:29 <crazy> fdrt: see https://abf.openmandriva.org/build_lists/358928
22:45:37 <fdrt> it's weird because its deployed as a stack to c64
22:45:39 <fdrt> and working
22:45:57 <ben79> The thing I fear about this group and development is we seem to always keep trying to get one last thing in or one last thing "fixed" and we don't make the decision to just do a release
22:46:20 <crazy> Starting build with build_id 358927
22:46:20 <crazy> 
22:46:20 <crazy> {"status":500,"message":"translation missing: en.flash.500_message"}{
22:46:27 <crazy> no is not working
22:46:29 <ben79> It's time let's do, it
22:46:33 <bero> ben79: yes, we need to fix that
22:46:38 <bero> and I think this time we all agree on it
22:46:43 <fdrt> yes but working on bero's pc and on mine
22:46:45 <rugyada> I agree
22:46:45 <crazy> fdrt: not working just looks like is working
22:46:46 <fdrt> and on tanmad
22:47:00 <fdrt> i cant connect it with builder error
22:47:01 <crazy> well does not ;)
22:47:51 <crazy> http://abf.openmandriva.org:9000/#/containers/b9805d3eb74a9bdeafe95c7cb42323c0efcb5c878bfdac0a7ac99cda6f91762a/logs <-- c64 which I stopped too
22:48:01 <crazy> same errors on all lx3 builders
22:48:13 <crazy> only those started manually from somewhere are working
22:49:05 <crazy> all init fine , all get the build , all trying to start the build then all are flooded with the 500_* messages in a loop
22:49:31 <crazy> let me cancel ant build hanging forever too
22:50:38 <fdrt> i stopped already
22:51:16 <crazy> fdrt: ok thx :)
22:51:44 <crazy> fdrt: but why to hell crisb's ones started manually working ?
22:51:53 <fdrt> i dunno
22:51:58 <fdrt> it's not pissible but it is
22:52:11 <crazy> build token ? something else we are missing ?
22:53:15 <bero> fdrt: It doesn't need to be pissible, Chwido can do that when we go outside... Just as long as it's possible..... ;)
22:54:16 <bero> must be an environment variable or something...
22:54:32 <bero> or an older version of the container?
22:55:24 <ben79> #aktion: so we're waiting on some thing/things I'm not entirely sure of and then at some point someone is going to build ISO's and we test for 3 days and if all is somewhat kind of OK we then do Beta release.
22:55:54 <ben79> #skhare: so we're waiting on some thing/things I'm not entirely sure of and then at some point someone is going to build ISO's and we test for 3 days and if all is somewhat kind of OK we then do Beta release.
22:56:16 <itchka> ben79: :)
22:56:56 <ben79> We needs to become the #action distro instead of the #talk distro
23:00:26 <bero> agreed
23:00:29 <bero> in some ways we are
23:00:35 <bero> (who else has switched to clang?)
23:00:42 <bero> but when it comes to releases... not so much
23:02:15 <ben79> Obviously I was referring to our release history, or lack thereof
23:02:22 <itchka> ben79: We took on a massive task when we switched our packaging managment tools and I think we were a bit over optimistic as to how long it would take. The work that has been done now thoiugh will serve us well in the future.
23:02:43 <ben79> most users don't know if a distro uses clang or gcc
23:03:18 <ben79> I'm pretty well aware of all of that
23:04:29 <ben79> users see a distro that is still using what we release in 2016, users don't see how much work it is and was for half dozen part time devs to change package managers
23:05:23 <ben79> and I think none of us realized how much trouble it would be to ditch drakxtools and remove drakx from all scripts (which I doubt we are finished with)
23:05:48 <bero> there's still some crap left
23:05:55 <ben79> not to mention why do we have moondrake stuff in openmandriva???
23:06:04 <bero> but we should have made a 4.0 release ages ago anyway
23:06:15 <ben79> that all needs to go for mental health reasons
23:06:16 <crazy> bero: that plasma-pk-updates package seems to work fine .. I expected it to eat me :D
23:06:18 <bero> There was no need to cram it all into this release
23:06:44 <crazy> bero: quick tested on/from Live Iso too
23:06:49 <crazy> seems to work too
23:06:58 <ben79> I think the point is we've done what we could do and it is time to release and go to next steps
23:07:01 <bero> good... one more problem "solved"
23:07:15 <bero> right
23:07:33 <crazy> so we go for beta with s/dragora-updater/plasma-pk-updates/ ?
23:07:59 <bero> the last thing I really want to get in before final release (NOT before beta) is plasma 5.15 -- we shouldn't ship final with a RC of such a big component (even though it works perfectly)
23:08:02 <ben79> It sounds like Y'all have fixed almost everything mentioned earlier as holding back a Beta release so whadya say we do it
23:08:10 <bero> but the plasma 5.15 release schedule goes well with ours anyway
23:08:18 <bero> I'm all for it
23:08:58 <ben79> buuild an ISO when? test 3 days a BOOM! RELEASE! (yes I was shouting)
23:09:15 <crazy> bero: ok then after beta are we going to talks about final packages so I can try fix lxqt* iso too ? ( please note lxqt one is still weird )
23:09:35 <bero> sure
23:09:38 <bero> lxqt 0.14 is in btw
23:10:14 <ben79> maybe time to re-institute that "soft" freeze
23:10:21 <crazy> bero: I saw however on plasma iso we discovered bug after I dropped task-xxx  for the most parts
23:11:19 <crazy> plasma* one just uses task-printing* as task-* nothing else ( and I badly want fix this one too but the spec of that one is such weird not even sure where to start :D )
23:12:23 <crazy> bero: oh one more thing we need think about before release .. vbox package -> in-kernel-vbox-code need be in sync
23:12:38 <crazy> bero: we may need FAT warning in both packages
23:13:24 <crazy> vboxadd.service is not so happy on version miss matches
23:13:42 <bero> True
23:14:49 <crazy> when differences are not so big it just throws some warnings and disables control part but once they get bigger it kills all mods , that results probably in black screen booting VB
23:16:41 <bero> would also be nice to at least somewhat fix up the Java stack before the *final* release (NOT beta)
23:17:21 <bero> Got stuff up to -10 to build...
23:17:34 <bero> -11 tends to crash a lot
23:18:11 <bero> actually -11 succeeded on znver1 and crashed everywhere else
23:18:13 <bero> weird but true
23:18:21 <bero> usually znver1 and x86_64 should behave more or less the same
23:18:37 <crazy> crashed on build ?
23:18:58 <bero> yes -- https://abf.openmandriva.org/build_lists/358021
23:20:40 <crazy> bero: maybe OOM .. zwerg does not have swap
23:20:43 <crazy> hmm not
23:20:49 <crazy> I see these :
23:20:54 <crazy> [617602.215696] traps: ld-linux.so.2[30521] general protection fault ip:f7ea4021 sp:ffe43564 error:0 in libc.so[f7d5f000+176000]
23:20:54 <crazy> [617602.216391] traps: ld-linux.so.2[30526] general protection fault ip:f7eac021 sp:ffed64e4 error:0 in libc.so[f7d67000+176000]
23:21:16 <crazy> but that's 32bit something
23:23:37 <crazy> what ..
23:23:40 <crazy> SIGILL        No    No    Yes        Illegal instruction
23:23:49 <crazy> what the f...
23:24:11 <crazy> what kind Illegal instruction on 64bit .. AVX* maybe
23:24:37 <bero> maybe...
23:24:54 <crazy> zwerg does not have avx
23:24:56 <bero> will try to build it again to see if the same thing gets triggered on c64 or ant
23:25:12 <crazy> one more thing I noticed from build log
23:25:20 <crazy> something is adding -Werror
23:25:34 <crazy> really _not a good idea in java builds_
23:26:24 <crazy> bero: if it builds on ant/c64 then we need investigate what pulls in AVX *
23:26:55 <bero> also fails on aarch64, armv7hnl and i686 (but for different reasons)
23:26:58 <bero> http://file-store.openmandriva.org/api/v1/file_stores/f23f05806fe1a9c0a3b02cc790d46acc66b85954.log?show=true
23:27:01 <bero> looks like a real bug
23:27:38 <bero> Definitely broken code there...
23:27:47 <bero> class InterpreterMacroAssembler: public MacroAssembler {
23:27:47 <bero> protected:
23:27:48 <bero> 
23:27:48 <bero> protected:
23:27:48 <bero> using MacroAssembler::call_VM_leaf_base;
23:27:49 <bero> 
23:27:50 <bero> // Interpreter specific version of call_VM_base
23:27:51 <bero> using MacroAssembler::call_VM_leaf_base;
23:27:54 <crazy> I guess is same bug but now triggers different
23:27:54 <bero> looks like a merge gone wrong upstream
23:27:59 <bero> none of our patches touch that file
23:28:16 <crazy> O_O
23:28:36 <crazy> _rbit(Vd, SIMD_Arrangement(T & 1 | 0b010), Vn);
23:28:36 <crazy> ^
23:28:47 <crazy> all ponting to some SIMD* code
23:28:52 <crazy> *pointing
23:29:15 <crazy> yes looks like some broken merge
23:29:56 <bero> if they keep up broken merges like that, maybe at some point they'll be allowed to rename the project from openjdk to gopenjdk ;)
23:30:40 <crazy> :D
23:32:54 <bero> maybe they'll even qualify for a 7-digit donation from Ubuntu
23:41:58 <crazy> bero: this one I missed myself https://github.com/NVIDIA/egl-wayland/releases
23:42:20 <crazy> I have a FIXME in my own build script for this one
23:42:22 <crazy> :D
23:43:08 <crazy> bero: so not to much will be left to the nvidia spec ( closed part )
00:59:16 <ben79> Hmmm
00:59:24 <ben79> long meeting?
01:01:05 <ben79> #end-meeting
01:01:31 <ben79> #endmeeting
01:01:49 <itchka> yes
01:01:56 <itchka> probably should
01:02:03 <itchka> #endmeeting