16:21:38 <itchka> #startmeeting
16:21:38 <chwido> Woof! Let's start the meeting. It's Wed Feb 13 16:21:38 2019 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:21:38 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:21:38 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:21:38 <chwido> Have a good meeting, don't bark too much!
16:21:56 <crazy> ben79: do a quick test .. dnf install xen as example
16:22:07 <crazy> or dnf install zypper etc
16:22:29 <itchka> Are we talking of the main repo here?
16:22:34 <crazy> you can take a list of packages from dnf itself ..
16:22:52 <crazy> itchka: enable cooker main only ... fire dnf list available
16:23:00 <crazy> and test these packages
16:23:19 <crazy> yes I talk about main or whatever dnf list in there
16:24:03 <ben79> Gasp! Drop packages!
16:25:15 <ben79> My knee jerk reaction to packages in main that won't install is that they aren't used so drop 'em or move to the home of packages that don't work and make a bigger mess of contrib
16:25:16 <crazy> itchka: very easy to test .. install clean VM with cooker main only enabled , update , create a list from what dnf lists and testing one by one is installable first
16:25:26 <itchka> I think preferably fix them.
16:26:55 <ben79> Fix stuff like xen and zypper??? No don't waste our time on that git rid of 'em
16:27:16 <itchka> So crazy have you tried this? Do you have any idea how many packages are suffering from rpm5ness
16:27:16 <crazy> itchka: obviously no one touched these in ages .. nor mass rebuild fixed these meaning that : 1) no once cares 2) some are just staled packages ( wipe away ) or 3) someone may care but no-one notice these are broke .. is why we need a test run on that
16:27:30 <ben79> some packages probably should be fixed but surely not all
16:28:05 <crazy> itchka: not a clue .. I wanted to start thencooker hit qt5 mess and I delayed the test for 'once cooker is done with all these'
16:28:24 <crazy> I tested some random ones is why I know some are broken
16:29:20 <crazy> and while and install test is != these are working is better than noting ..
16:29:43 <crazy> offering such packages in final would make you look very bad
16:29:57 <crazy> *us look
16:30:05 <crazy> damn I can't type at all today
16:32:37 <itchka> Well in the past we have always fixed all the packages in main so it's not that some packages have not been maintained. I'm not sure that bero has finished java yet so there's goung to be loads of broken stuff there.
16:33:18 <crazy> itchka: anyway my TODO for this week for OM is this ( assuming no other weird stuff comes in here or customer breaking remote boxes or the like :P) : calamares / kpmcore bump fixup teaks , iso script sync with most changes , grub CLI option , and this install test
16:34:22 <itchka> I'd like to see the iso script changes please. Just to keep up to date.
16:34:57 <itchka> grub CLI option? I thought we could do that from the spplash screen..
16:35:10 * bero is back
16:35:13 <crazy> itchka: no changes just sync up .. not sure what left .. eg: we changed theme we need fix grub files and stuff like this
16:35:51 <itchka> crazy: Ok I get.
16:36:00 <itchka> Hi bero
16:36:01 <crazy> itchka: no you cannot boot CLI in OM only you edit grub by yourself .. is set to graphical target
16:36:34 <bero> some of the stuff currently in main needs to move to contrib...
16:36:36 <crazy> itchka: so we got a grub menu to 'boot cli'
16:36:40 <bero> and we need to resume the contrib mass build too
16:36:59 <itchka> Did we stop it?
16:37:04 <bero> but OTOH it may be good to have a beta2 with the KDE updates in ASAP so we see if they broke anything
16:37:17 <crazy> bero: I think the other way around :P ..
16:37:38 <bero> itchka: I stopped it to free up builders for the qt mass build, that was more important
16:37:48 <itchka> He he
16:38:00 <itchka> Ok
16:38:20 <crazy> bero: some stuff from contrib need go into main , whole contribut need die hard and moved to archive/ .. broken crap in main moved to that archive and then if peoples fix something from archive they can ask for putting in main
16:39:29 <crazy> don't offer contrinb/* in  Lx4 with 70-80% broken packages or packages with sec bugs and what not
16:39:51 <bero> I think we need to keep contrib (though probably renamed to unsupported or something) for stuff we don't want to really support, but that isn't totally useless like most of the "doesn't even build anymore" bits
16:40:32 <crazy> first round of wipe out in contrib/* need be qt4* , kde4* and everything else want qt4 .. unless someone want to maintain and backport all CVE's from qt5*
16:41:15 <crazy> ( I guess no-one want do something like this but who knows )
16:42:07 <crazy> bero: yes not rm -rf .. just call it archive-we-do-no-care-about-it-may-eat-your-CAT
16:42:15 <itchka> crazy: That's half the fun of contrib it's not doing any harm to anyone and it's got all this interesting and obscure stuff in it. I don't understand the obsession with destroying it if bits don't work the so what. T's contrib and there are no guarantees.
16:43:16 <crazy> itchka: as long you as Distributor offer such a repo which has 80% broken shit in it .. who is gonna look bad ?
16:43:32 <itchka> It's a different story with the repos we ship that are e4nabled by default.
16:43:34 <crazy> it should not exists .. nor be supported in any way
16:43:54 <crazy> by default or not default offered packages has to work
16:44:07 <bero> IMO it can be useful to have even qt4 stuff that doesn't have a proper replacement floating around despite the CVEs
16:44:08 <itchka> It only looks bad if you don't tell people
16:44:15 <crazy> I found stuff not touched since 2008!
16:44:27 <bero> No harm in installing e.g. a game that has 5000 remote root exploits on a box that isn't connected to anything
16:44:57 <bero> Of course we need to make sure stuff that is really useless these days is removed/archived at some point
16:45:32 <bero> but I don't see anything wrong with a "we know this is broken and may eat you, but if you absolutely need it go ahead" type repository
16:46:42 <crazy> bero: itchka you guys have to decide @the end however I am not talking from developer perspective about that but as foojoe user .. comming to OM , enabling contrib while a app I want is there then find out 9 of 10 apps I have trying to install are broken , won't even install and if they install they do not work
16:47:19 <bero> agreed about that -- stuff that's there should at least install and start up
16:47:39 <crazy> I will probaly just this 'what kind of crappy devels these are ' and move on without to even open any bug report
16:47:47 <ashledombos[m]> what is the meaning of having a contrib repo while there is no company vs contrib nowadayx?
16:47:55 <bero> but realistically we won't have the time to make sure it does before the release
16:48:13 <bero> ashledombos[m]: main == we care about those packages and if you find a bug, we'll fix it or at least pass it on upstream
16:48:33 <ashledombos[m]> ok
16:48:38 <crazy> bero: I know we do not have is why don't offer it
16:48:43 <bero> ashledombos[m]: contrib == we don't care about this stuff, we know some of it is broken, but it may be useful for some, so here's a package. Install it as you please, but if it breaks you get to keep both pieces
16:49:14 <bero> crazy: as long as it's not enabled by default and people have to go through some hoops explaining what it is, I don't think it'll make us look bad
16:49:53 <crazy> bero: I would more prefer different usage of 'contrib' as a pure 'files repo on github or somewhere' and then we mentor the peoples there helping out to write prober specs files which then we can put in main
16:50:04 <itchka> Actually ashledombos[m] has a point maybe we should market it as the "The fixit challenge" repo.
16:50:07 <ben79> Based on what bero is saying changing the name from contrib to unsupported would be appropriate and honest
16:50:23 <AngryPenguin> hi
16:51:15 <bero> crazy: the problem with that is that we'll end up having to support too many packages that may be relevant to 0.0000001% of users
16:51:25 <crazy> in that way we can have true contributors may even step into developend sometimes ... the opposite is right now .. peoples walks away with big head ace
16:51:27 <bero> but I agree with moving a lot of the "good contrib" stuff to main
16:52:06 <AngryPenguin> maybe we should: for lx4 leave contrib in the state it is. Inform users that many packages are broken. Then, for LX5, start removing the contrib. Transfer good packages to main, remove bad ones.
16:52:57 <crazy> bero: then we can enable a main-extra which contrary to contrib we support .. whatever ..but that contrib in his form should not exists
16:53:11 <itchka> crazy: I see it too as a training ground. This is something I have wanted to do for some time but did not have the necessary experience. I think I could probably make a start on a project like that now though.
16:54:42 <ben79> We see over, and over, and over, user tries to install package form contrib and either it won't install or won't work then user response is automatically it is OpenMandriva repo OM devs should fix it. That is what we need to change, that expectation.
16:55:23 <ben79> To me renaming it what it really is 'unsupported' is simplest and easiest way to do that.
16:55:24 <bero> right -- the idea for contrib must essentially be "if you break it, fix it -- we might help you if someone has enough time, but don't expect us to"
16:57:47 <ben79> The word contrib obviously does not convey to users that concept
16:58:17 <AngryPenguin> "contrib - unsupported packages"
16:59:08 <ben79> AngryPenguin: no that is just defining it again, we've been doing that, I'm blue in the face from telling users that
16:59:42 <ben79> we need to change the actual name of the repo to a more accurate descriptive title
17:00:06 <bero> are there any reasons whatsoever not to change the name?
17:00:07 <ben79> Make it immediate and obvious
17:00:40 <bero> Worst possibility I can see is that some old config tools may have a contrib hardcoded somewhere, but chances are those don't work with dnf anyway
17:00:46 <bero> so now would be a good time to rename it...
17:02:32 <bero> Any objections to renaming?
17:02:39 <bero> And rename to what? "unsupported"?
17:02:45 <bero> "fix-it-yourself"?
17:03:08 <AngryPenguin> "crap" :D
17:03:14 <itchka> No objections; FixMe
17:03:18 <bero> "apple-like" ;)
17:03:19 <ben79> "feel-free-to-provide-your-own-patches"
17:03:32 <HisShadow> "garbagedump"
17:03:45 <ben79> I prefer unsupported as that makes it clear what we are trying to make clear
17:03:58 <christann> I agree with Ben.
17:04:02 <itchka> Archeological Playground
17:05:02 <ben79> well at one time archive was also suggested
17:05:33 <crazy> HisShadow: I like it :P +1 :D
17:05:37 <ben79> I would suggest something simple that kind of fits our current naming and either archive or unsupported would do that
17:05:47 <bero> I'd prefer unsupported over archive because there's also stuff in there that's not ancient...
17:06:06 <ben79> HisShadow: good one
17:06:29 <crazy> bero: from me +1 to rename
17:06:33 <ben79> I also believe unsupported does a better job
17:06:42 <HisShadow> "broken-watercloset"
17:06:43 <ben79> of making clear
17:06:45 <bero> e.g. we can put some stuff there that has some potential but is not ready to be supported
17:06:58 <bero> fancy-new-app ;)
17:07:13 <ben79> yes there are a number of reasons to have an unsupported repo
17:07:32 <itchka> HisShadow: That's only one step from BrokenShit :)
17:12:14 <crazy> bero: while working on kpm/cala stuff to test some things .. I would like to drop reiserfs deps from kpmcore at all .. no point in offering auch an broken FS these days .. here I disabled even in-kernel support for it
17:12:59 <bero> yes... We should probably split the kernel package for stuff like that
17:13:05 <bero> unsupported-modules subpackage or so
17:13:59 <HisShadow> I still have a couple harddrives with reiserfs 3 lying around somewhere
17:14:27 <HisShadow> yeah, but I haven't seen reiserfs anywhere since forever
17:15:14 <crazy> bero: good idea
17:15:23 <bero> yes -- that's why I think it's useful to have the module built somewhere, but not wasting space (and making us support it) in a normal install
17:15:39 <ben79> So I'm not hearing any objection to changing name of contrib repo to unsupported
17:15:47 <ben79> To get back on topic
17:15:54 <crazy> HisShadow: really is full of bugs and not maintained .. kernel poeples just pushes compile / general API in-kernel changes to it ..
17:15:54 <rugyada> re contrib repo imo: "unsupported" is the most proper name, it's clear the name and the meaning, understandable by anyone
17:15:54 <bero> also some stuff that is vital to some users, but useless to 99.9% (infiniband drivers, anyone?) should probably be split from the main kernel package
17:17:25 <crazy> bero: yes I am fine with that
17:17:31 <itchka> Pretty boring name though
17:17:54 <crazy> [18:03:57] <HisShadow> "garbagedump" <- combine boot ?:P
17:18:08 <crazy> unsupported-garbagedump
17:18:10 <crazy> :D
17:18:12 * crazy hides
17:18:14 <bero> g_unsupported ;)
17:18:24 <ben79> itchka: boring name like main, non-free, ect
17:18:28 <bero> where g stands for either garbagedump or the thing I'm thinking of ;)
17:18:40 <ben79> they should be
17:19:22 <ben79> no you start doing stuff like that and then the meaning becomes less clear, boring names have a purpose
17:22:35 <rugyada> pretty name: what your fantasy suggests and you like to call it among us, official name: yes some simple formal serious boring name. please remember that you are talkint to the whole world out there not to your neighbours
17:23:08 <ben79> people for whom English is 4th or 5th language
17:23:17 <rugyada> talking*
17:25:46 <ben79> do we need a vote?
17:25:57 <itchka> Exactly right ruru[m] and a word like unsupported will likely acheive it's demise rather than make additional packages available to distro users but as you wish.
17:26:19 <bero> unsupported -- clear and boring, and for those who want an exciting name, it's an acronym for Useless Non-working Shit Used by People Possessing Obvious Retardation Trying to Enrage Developers, or something
17:26:37 <crazy> rofl
17:26:43 <rugyada> lol
17:27:29 <HisShadow> haha
17:29:10 <itchka> In that case the name should be UNSUPPORTED.
17:29:35 <ben79> itchka: no we won't see the demise of  an unsupported repo, if one thinks about it that is way to convenient for a distro for it to go away,
17:30:36 <ben79> will we see a lot of the packages in the unsupported repo go away, don't know but we should, IMO anything not touched for 10 years should go to the trash bin automatically
17:32:11 <ben79> or to an archive
17:33:48 <ben79> "#action developers to change the name of contrib repository to unsupported"
17:34:07 <ben79> "#share developers to change the name of contrib repository to unsupported ASAP"
17:34:15 <ben79> "#action developers to change the name of contrib repository to unsupported ASAP"
17:34:51 <ben79> there remove the quotes and we did it
17:35:59 <itchka> So we are not going to vote on this?
17:36:01 <bero> HisShadow: if we just rename the repository on abf, will that automatically rename the directories, or do we have to do something in the filesystem manually?
17:36:38 <HisShadow> let me check
17:36:50 <ben79> If we are then lets vote and move on, these meetings could go faster
17:37:06 <bero> I think it's pretty much unanimous, but why not make it official...
17:37:08 <bero> +1 from me
17:37:20 <ben79> +1
17:37:23 <rugyada> +1
17:37:32 <itchka> -1 from me
17:37:49 * ben779 +1
17:38:23 <bero> actually looks like abf doesn't have a rename option
17:38:26 <bero> itchka: why?
17:38:55 <HisShadow> bero: yeah, it doesn't, name attribute is read only. Would need to rename it in fs and rename manually in the database
17:39:44 <crazy> +1 for me
17:41:20 <itchka> I feel it will be the beginning of the end of that repo. It will end up as an excuse to ignore it completely if not now then in the not too distant future.
17:43:28 <itchka> #share developers to change the name of contrib repository to unsupported ASAP
17:43:35 <ashledombos[m]> +1
17:43:45 <itchka> #action developers to change the name of contrib repository to unsupported ASAP
17:44:18 <itchka> Ok let's do soem of the agenda.
17:44:23 <itchka> #item 1
17:44:42 <itchka> #topic Cooker and ABF report.
17:44:49 <itchka> bero ?
17:51:48 <bero> So, overall things are looking good again
17:52:28 <bero> the updates we wanted to pull in are done, and we have a workaround for the nouveau driver bug that broke things for nouveau users after the qt 5.12.1 update
17:52:45 <bero> no known serious problems, but we obviously need a lot more testing
17:53:12 <bero> abf is holding up well right now too
17:53:30 <itchka> bero: Is the nouveau thing still the lack of multi-threading support?
17:53:50 <bero> itchka: yes
17:54:19 <itchka> Doesn't look like that will ever be fixed....
17:55:14 <bero> The correct fix is to boycott Nazividia ;)
18:01:49 <itchka> So what else needs to be done in cooker before we can split it off?
18:02:28 <itchka> crazy has mentioned a number of broken packages that need fixing
18:03:35 <ben79> Fix all of these: https://issues.openmandriva.org/show_bug.cgi?id=2421  >>> dnf update shows Traceback: RuntimeError: TransactionItem not found for key:
18:03:42 <itchka> Should we run repoclosure to get some idea of what deps still need fixing?
18:05:12 <itchka> ben79: I have see similar with some cups packages and with cdrdao
18:06:12 <ben79> there are a lot of them, they have incorrect package names
18:06:32 <ben79> like 2015 or 3000 instead of 4000
18:06:40 <ben79> AFAIK
18:08:58 <itchka> Ok I'll generate a list of those and see if we can't rebuild them all.
18:10:05 <itchka> So we need to give that priority?
18:10:17 <ben79> just be sure to put whatever in that bug report
18:11:35 <ben79> priority? not for me to say, from user perspective it looks very bad but it is just an error message like urpmi had so many of the packages will still work AFAIK
18:12:49 <itchka> I've seen it loads of time and to me it gave the impression that the packages had not been installed.
18:13:20 <ben79> then there is another catagory of packages that need to be removed or fixed, those that still depend on rpm5 , or so I have heard
18:14:35 <ben79> well users see that and they will think all sorts of bad thoughts so perhaps it should be priority,
18:15:09 <ben79> especially since we are switching package managers if we start out dnf with a lot of errors like this it will be bad, bad
18:15:24 <itchka> Can someone suggest how we might detect these apart from physically trying to install everything that dnf says is available?
18:16:38 <ben79> anyway to automate such rote testing
18:18:24 * ben79 
18:18:33 <ben79> me/ what?
18:20:09 * ben79 What happened?
18:20:31 <itchka> Nothing as far as I know...
18:20:52 <ben79> It's like someone farted and everyone left but you and me
18:21:13 <crazy> no :) I got an phone call
18:21:23 <ben79> which is OK, I always enjoy these talks anyway
18:21:37 <ben79> even learn stuff...
18:21:40 <crazy> itchka: I don' think that is possible .. maybe from the location the rpm exists but not sure
18:23:51 <itchka> Well if it's and rpm5 issue the reasons must be fairly specific maybe we can extract infro from the mass build logs.
18:24:48 <bero> probably ls |grep -v 4000 will show the right list
18:25:47 <bero> it's packages that failed the mass build
18:27:38 <itchka> bero: It's unlikely to be all of them if there's a key dependency failure it could affect loads of packages that don't have rpm5 issues.
18:28:49 <itchka> We should create a dependency graph then we can pick out the important targets.
18:36:03 <itchka> Are we agreed that these have to be fixed before we split off 4.0?
18:36:33 <bero> fixed or moved to contrib/unsupported for the packages that are useless
18:41:07 <itchka> A plan of concerted action then bero can you generate the list and post it on the cooker ml?
18:48:51 <bero> sure, assuming we have a sane way to detect broken packages
18:49:20 <itchka> I guess what you suggested is as goo a way as any.
18:49:31 <itchka> goo=good
18:49:45 <bero> probably rpm -qp something on the server should work as well
18:49:50 <bero> will have to experiment a bit
18:50:04 <bero> btw, did anyone create the ml yet?
18:50:22 <bero> ashledombos[m]: I think you were looking into that?
18:55:46 <fdrt> hi
18:58:25 <itchka> hi fdrt
18:58:50 <AngryPenguin> bero: can we still add some new package to cooker?
19:07:17 <itchka> has everyone died and gone to heaven?
19:08:06 <itchka> bero: I guess if there's no ml just post it on the cooker forum.
19:09:22 <itchka> Don't think we are going to get through the agenda at this rate.
19:09:35 <itchka> Lets move on
19:09:44 <itchka> #item 2
19:10:35 <itchka> #topic Lx4 beta Release issues/progress
19:11:54 <itchka> I've install the beta on my new laptop and with the short use that it's had it seems to be working pretty good apart from acpi but then this is a very new machine.
19:12:21 <ben79> This is the biggest release by OpenMandriva in 2019 or 2018, that's progress
19:12:40 <itchka> An upgrade to beta on my main box exposed the nouveau bug which has now been fixed.
19:12:58 <itchka> ben79: :)
19:15:20 <itchka> I have but one comment. I find a full screen launcher so much more pleasant to use that the thing we ship as the default is it possible that calamares could allow us to have a choice at install as which is the default/
19:15:26 <itchka> ?
19:16:35 <ben79> you already have that choice don't you?
19:17:05 <christann> I agree with making the full screen launcher default. There are a few choices, but the setting is not easy to find imho.
19:17:40 <bero> AngryPenguin: IMO yes, new packages are far less likely to break stuff than modifications to existing packages
19:17:57 <itchka> Yes but I always have to fiddle about on the desktop to select it. I was just wondering whether it could be set up at install.
19:18:18 <ben79> Uh, that's
19:18:19 <bero> matter of taste... personally I hate full screen launchers, but agree it would be good to have the option available easily
19:19:18 <ben79> it is available and easy already, so right clicking on an icon and selecting something is a major operation for people
19:19:20 <ben79> ?
19:20:08 <ashledombos[m]> Bero yes
19:20:18 <ashledombos[m]> I'm working on it
19:20:39 <ashledombos[m]> But i wanted to tie it with lindev.ch
19:20:56 <ashledombos[m]> But maybe i'll do it later
19:21:01 <itchka> It's not that straightforward ben79 for a start both icons are the same so you can be sure that you have selected the right one. If you put the both on the task bar you then have to guess which one to delete.
19:21:05 <ashledombos[m]> I mean tying it
19:21:19 <rugyada> right click on menu icon > Alternatives > Application Dashboard ?
19:21:34 <ben79> No itchka what rugyada says
19:22:19 <itchka> Well that kinda proves the point doesn't it how the hell do people even know it's available.
19:24:22 <ben79> no it doesn't using a mouse and right click is intuitive on any OS
19:24:43 <ben79> virtually everyone knows that
19:25:08 <ben79> maybe, probably, ever these settings should be in systemsettings
19:25:49 <itchka> I know that Ben but on a menu selector; it's pretty esoteric ?
19:25:55 <ben79> but what you are asking for leads to people wanting to customize their desktop with the installer, not a good way for us to go IMO
19:26:06 <ben79> no, it is everywhere
19:26:54 <itchka> What is everywhere?
19:27:24 <crazy> itchka: what full screen launcher ?
19:28:15 <crazy> itchka: if you mean that weird install mode that was side effect of missing real windows manager  .. but yes I can make calamres start full screen
19:28:16 <ben79> talking about setting which application launcher to use with the installer
19:28:18 <itchka> Not sure how to answer that crazy I'm not sure it has a name.
19:28:49 <rugyada> also to read some KDE docs may help
19:28:57 <rugyada> https://userbase.kde.org/Plasma_application_launchers
19:29:01 <itchka> Application Dashboard it would seem.
19:29:34 <rugyada> the way to change is always the same since ages
19:29:48 <ben79> FWIW: I could care less which one we make default as I consider it so easy to change it does not matter
19:29:54 <crazy> itchka: not calamares thing .. packaging thing hm ?:) we force these by patching
19:30:33 <rugyada> crazy:  it would mean distro own settings,
19:30:42 <crazy> itchka: and with rsync mode not so easy way of doing that since you cannot allow user to install/remove packages with an gui
19:31:21 <rugyada> and given it's user preference and easy to do.. who cares? :D
19:31:44 <crazy> rugyada: yes is patched in .. I wanted to fix all these once I can remove the weird 2008 menus bc is a bit complicated .. we patch 2 packages then do some other things in 3 others which is mad to start with
19:31:47 <itchka> As far as I'm aware it's widget within plasma.
19:31:52 <rugyada> I prefer the small current one
19:32:19 <rugyada> crazy:  not really patched I think, it's distro customization
19:32:22 <crazy> rugyada: so once I start clening up the one _I_ have to touch the rest anyway
19:32:38 <crazy> rugyada: we patch kicker default
19:32:41 <crazy> trust me
19:32:51 <crazy> default plasma is Kickoff
19:32:58 <rugyada> as for favorites etc yes, ok
19:33:06 <itchka> I know you do rugyada which is why it would be nice to have the choice at install.
19:33:08 <crazy> favs are broken too
19:33:24 <rugyada> setting one menu instead of another is just distro's choice
19:33:41 <rugyada> itchka:  plasma is plasma
19:33:45 <crazy> itchka: no way sry , at least not like all is put together right  now
19:34:04 <rugyada> user can custom its own prefered look
19:34:44 <rugyada> crazy:  they are 2 different issues
19:35:01 <itchka> Forget I asked.
19:35:01 <rugyada> or better: one is an issue and the other one is not..
19:35:04 <crazy> 2 ?:) is see a lot more but tell me
19:35:21 <rugyada> crazy:  ok, I know
19:35:37 <crazy> itchka: it does not means we cannot do that but right now I cannot see how
19:36:11 <crazy> itchka: I can force something from _calamares_ but as soon you update distro packages is gone
19:36:26 <itchka> No worries there are more important fish to fry.
19:37:33 <crazy> itchka: what we need do is this : un-fuck mandriva mess , fix profile , fix icons , fix menus .. once done split all the launcher maybe other things in own packages then situation looks different
19:37:43 <crazy> itchka: then we can play some other games :)
19:38:49 <crazy> itchka: then you can click I want foo in a GUI and installer remove all but foo or set foo default or something .. but as long we use the profile and force stuff like now any update will kill it off
19:39:34 <crazy> itchka: anyway I may have other idea just not sure I have time to implement for Lx4
19:41:20 <itchka> Ok crazy maybe well dicuss it in a quiet moment let's get the reall broken stuff out of the way first.
19:41:22 <itchka> Apart from the previously discussed dnf issues/broken packages are ther any other major bugs. I haven't had much time to do any testing except just using the box. So far everthing looks pretty solid to me.
19:41:42 <ben79> well there are bug reports so yes
19:42:02 <itchka> Ok lets move onto thiose then
19:42:08 <itchka> #item 3
19:42:22 <itchka> #topic AIB
19:42:34 <itchka> Off you go ben79
19:43:28 <ben79> Everyone is or should be familiar with how to list bugs by Product, like "Cooker" and "Lx3" currently
19:43:47 <ben79> https://issues.openmandriva.org/buglist.cgi?bug_status=__open__&list_id=40444&order=Importance&product=OpenMandriva%20Lx%203&query_format=specific
19:44:39 <ben79> One thing we need is for develpers to go through the list of open Lx 3 bugs above and tell us by marking them which are RESOLVED/COOKER
19:44:52 <ben79> and which are RESOLVED/CANTFIX
19:45:10 <ben79> the list is not that long I think 68 currently
19:45:52 <itchka> Some of them are packaging requests
19:46:42 <ben79> that does not matter package requests can be marked either way, either we package them for Cooker or we aren't going to package them right?
19:48:30 <itchka> Ok  wel I know I have fixed some of those in Lx3
19:48:56 <ben79> Anything that is fixed needs to be marked as fixed please.
19:49:30 <ben79> Anyway to get either list simply go to https://issues.openmandriva.org/ and select >Search>Leave status as Open> and select the Product
19:50:07 <itchka> Ok is that it ben79
19:50:57 <ben79> We do have a problem with bugs not getting marked as FIXED sometimes,
19:52:30 <ben79> As long as fix everything possible and tell user when we cant fix something then yes, that is all.
19:53:05 <itchka> Looks like some stuff I fix in Lx3 is broken again in cooker. Prolly all thos packages in main that haven't been rebuilt.
19:53:53 <itchka> This is the most confusing error message ever
19:53:54 <ben79> In that case we should have a new bug report filed against Cooker right? I'm asking not tellling.
19:53:56 <itchka> Problem: conflicting requests
19:53:58 <itchka> - nothing provides libhunspell-1.3.so.0()(64bit) needed by bluegriffon-1.7.2-2.x86_64
19:54:43 <ben79> in Cooker of Lx 3?
19:54:50 <ben79> in Cooker or Lx 3?
19:54:51 <itchka> How can it be a conflict if nothing is providing it?
19:54:57 <itchka> Cooker
19:55:37 <itchka> ben79: Yes or just switch the product to cooker
19:56:03 <itchka> With a comment maybe to say you've done that.
19:58:19 <ben79> definitely with a comment
19:59:23 <ben79> I'm kind of thinking it would be better to file a new report though
20:00:38 <ben79> Or maybe not, not sure
20:00:48 <itchka> People can just append stuff to the old one like "retested in cooker gave this error"
20:03:44 <ben79> That is a good idea, I don't have answers on this
20:04:43 <itchka> It keeps the work to the minimum..if it doesn't work we can always start creating new bugs.
20:06:24 <ben79> yes, I don't think this is a big issue anyway, normally user will file a bug report against a stable version and a QA or dev will add to report "also in Cooker" if warranted.
20:07:23 <ben79> this has been done in the past as I recall
20:08:46 <ben79> The main thing is  can we get devs to go through the now much shorter Lx 3 list and mark any bugs as RESOLVED/COOKER or CANTFIX or INVALID as warranted?
20:09:13 <itchka> Ok ben79: I'll do a bit on this tonight on ones I know I have a chance of fixing as it will probably mean fixing and rebuilding packages in cooker which never built on the mass build.
20:09:30 <ben79> That gives users a sense of some resolution to their issue.
20:09:57 <ben79> OK , thanks
20:11:41 <itchka> Ok lets move on
20:11:48 <itchka> #item 4
20:11:51 <itchka> AOB
20:12:01 <itchka> #opic AOB
20:12:05 <itchka> #Topic AOB
20:12:16 <itchka> Too tired
20:12:44 <itchka> Just a quick report on mirrormanager2
20:13:55 <itchka> It's working but some of the setup script are fedora specific I'm trying to port them but with python I'm flying virtually blind.
20:15:05 <ben79> What do we need to do to get this deployed in OM Lx 4.0, we need to get this done
20:15:21 <itchka> fdrt: The docker stuff is fixed up now and you should be able to deploy it over nginx. I have had it running with locally within docker.
20:16:23 <itchka> Well if I have any energy left tonight I'll run the modified scripts and see whether they work.
20:16:29 * ben79 easy for me to say...
20:17:03 <ben79> I'm running on tomorrows energy today
20:17:14 <itchka> Then it's a question of liasing with fdrt and possibly Son_Goku to get the final setup done.
20:17:22 <Son_Goku> hmm?
20:18:11 <Son_Goku> itchka, talk to adrianr in #fedora-apps
20:18:18 <Son_Goku> he's the maintainer of mm2 and can help you
20:18:29 <Son_Goku> he'd be happy to help and glad to hear of a non-Fedora deployment
20:18:38 <itchka> Son_Goku: I already have ;) he's been quite helpful.
20:20:19 <ben79> Any way thanks to itchka for all your work on this, at a such a difficult time, what with moving and all, much appreciated.
20:20:40 <Son_Goku> itchka, I'm a bit strapped for cycles, but I can try to help
20:20:54 <Son_Goku> but I'm glad Adrian is being helpful :)
20:23:09 <itchka> Son_Goku: It's mainly the python stuff the best I can do is look at what Fedora and Centos have in the files and replicate it with openmandriva repo names substituted but  I have not much idea of what the code I am changing is actually doing.
20:24:15 <itchka> There are series of scripts which generate the inititial data and it's these I'm having to hack.
20:24:43 <Son_Goku> bero, fdrt, myself, and adrianr would definitely be able to help
20:24:56 <Son_Goku> I just don't know how the initial data stuff works
20:25:29 <itchka> You are as much in the dark as I am then :)
20:30:16 <ben79> In relation to an earlier question in this meeting. Isn't having a working mirror manager one of the things we are supposed to have for RC release?
20:30:36 <itchka> I'll plod on I just hope I didn't make the wrong decision choosing mirrormanager2
20:30:50 <itchka> ben79: Yes
20:32:03 <ben79> OK, just curious.
20:33:14 <itchka> Any other AOB...Otherwise it's time for tea.
20:35:22 <itchka> I'll give it five minutes.
20:39:26 <itchka> Ok ending the meeting.
20:39:31 <itchka> #end meeting
20:39:36 <itchka> #endmeeting