15:39:04 <itchka> #startmeeting
15:39:04 <chwido> Woof! Let's start the meeting. It's Wed May  9 15:39:04 2018 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
15:39:04 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:39:04 <chwido> You should add extra chair(s) just in case, with #chair nick.
15:39:04 <chwido> Have a good meeting, don't bark too much!
15:39:39 <itchka> Here's the Agenda
15:39:43 <itchka> Topics
15:39:44 <itchka> 1. Report: ABF cooker dnf
15:39:46 <itchka> 2. Lx4 Release Plan. Initial discussions
15:39:47 <itchka> 2. AIB
15:39:49 <itchka> 3: AOB
15:39:52 <itchka> #item 1
15:40:05 <itchka> #topic  Report: ABF cooker dnf
15:40:23 <itchka> Where are we at bero?
15:41:37 <bero> still trying to get to a point where we can start the mass build without expecting just about every package to fail
15:41:55 <bero> I'd like to have at least qt building properly before starting the mass build because a lot depends on it
15:42:20 <bero> but because of various interdependencies that already requires sorting out a lot of seemingly unrelated stuff
15:42:33 <bero> Qt uses cups (for printer support)
15:42:36 <itchka> Have you landed the extra cmake stuff that you mentioned yet?
15:42:47 <bero> cups uses php (for its web frontend)
15:42:57 <bero> php uses mariadb (for database connectivity)
15:43:04 <bero> mariadb uses Java (for JDBC)
15:43:05 <bero> ...
15:43:19 <itchka> Oh dear I see what you mean!!!
15:43:21 <bero> Java was a big problem because of i686 brokenness
15:43:24 <bero> but that's sorted out now
15:43:33 <bero> so starting to make good progress
15:43:56 <itchka> Does php have to use mariadb?
15:43:59 <bero> yes
15:44:20 <bero> without it most people trying to actually use it will scream
15:44:41 <bero> but that is actually building again
15:44:52 <itchka> What I mean is that is it possible to use and alternative db?
15:44:58 <bero> I don't know what extra cmake stuff you're talking about... Probably something I forgot about
15:45:40 <bero> It can use any db out there, but we need to build it with support for all of them to cover what people want to run with it
15:46:00 <bero> it doesn't have one interface that would allow to just exchange dbs and expect everything to work
15:46:27 <bero> if you have php code written for mariadb you need php built with mariadb support, if you have php code written for posgres you need php built with postgres support etc.
15:46:54 <bero> since not everything people may want to use is db independent and not everything uses the same one, there's no way around building php with support for all of them
15:47:33 <bero> but that's not a problem anymore anyway, given the java mess is fixed now
15:49:15 <itchka> Just curious as I'm using postgres with Lx3 for akonadi and it seems more stable and using the maintenance tools now only takes a few minutes rather than half-an-hour or so.
15:50:19 <bero> we should probably default to using it for akonadi then...
15:50:55 <itchka> I think it would be an improvment.
15:51:44 <itchka> Assuming I'm ever able to complete the dependencies for the python based pgadmin4.
15:52:17 <bero> should be a bit easier after the mass build because all the bits with python 3.4 dependencies will be gone
15:52:38 <itchka> I seem to be going around in bootstrap circles with that on.
15:53:15 <itchka> It's the testing packages that seem to be most of the problem.
15:53:40 <bero> Nothing wrong with disabling testing for bootstrapping
15:53:48 <bero> sometimes there's no way around that
15:54:18 <itchka> I'll bear that in mind :)
15:55:56 <itchka> bero: How long for Qt then any idea?
15:56:08 <bero> hopefully not much longer
15:56:38 <bero> php is already in the tree, but needs a rebuild because of the %-in-post-script issue
15:56:46 <bero> and of course something broke the build again already
15:56:52 <bero> so fixing that again
15:57:00 <bero> currently x86_64 and aarch64 are looking ok
15:57:08 <bero> but i686 and armv7hl still have lots of failures
15:57:45 <bero> mostly because they were in pretty bad shape before the move already
15:58:07 <bero> just didn't show up that frequently because stuff that has been around forever never needed to rebuilt on those arches
16:00:03 <itchka> I guess I'll look at those with your directional nudges I have made some progress.
16:01:21 <itchka> It would just be nice to be able to have the packages to build an LxQt iso so I can test out the isobuilder tool with dnf.
16:02:00 <itchka> I guess we will plod on.
16:02:21 <itchka> Let's move on
16:02:27 <itchka> #item 2
16:02:53 <itchka> #topic Lx4 Release Plan. Initial discussions
16:05:39 <bero> LxQt iso certainly requires building qt first
16:05:57 <bero> and that's what I've been trying to do for the last couple of weeks
16:07:15 <itchka> with Java fixed I guess you must be getting close :)
16:09:02 <bero> certainly closer
16:09:56 <bero> Still a lot of problems with packages still requiring devel(something) dependencies
16:10:04 <bero> but that's just a matter of rebuilding stuff
16:11:35 <itchka> Maybe we should have a please fix this kind of noticeboard.. It seems quite hard to get a coherent idea of the most key packages that need fixing.
16:12:35 <bero> we'll definitely need that for the mass build again
16:12:54 <bero> I expect we'll have hundreds, or more likely thousands of packages failing with some trivial error
16:13:34 <bero> definitely need them listed in some place so not everyone fixes the same thing at the same time
16:14:37 <itchka> I ssem to chase down dependencies and then get sidetracked of into another fork because one key package requires an obscure dep which takes you down another seemingly endless route of dependencies and I end up forgetting which package I was working on in the first place !:)
16:16:09 <bero> same here...
16:16:22 <bero> that's how we got from lxqt to java
16:17:39 <itchka> I'm told that dnf can create a dependency map..maybe we should try that?
16:21:09 <bero> at some point definitely
16:21:25 <bero> right now the basic dependencies are pretty much sorted out
16:21:38 <bero> bigger problem is that some stuff didn't build on one particular architecture or so
16:22:57 <itchka> So if people want to help then they should direct their efforts towards the  ARM7 and i686 arches.
16:23:13 <ben79> Wonder if there is a way to create a board or page on Github for "Packages Broken" and maybe even list them by or a way to search for "some trivial error" so some dumb ass user like me could focus on a specific "trivial error"
16:24:06 <bero> ben79: that's exactly what we need to do for the mass build
16:24:13 <itchka> Oh Ben I wish :)
16:24:28 <ben79> OK, but that wouldn't help now?
16:25:15 <bero> itchka: yes, for the most part it's those 2 causing problems with e.g. php building successfully on everything but armv7hl because armv7hl doesn't have the current version of apr-util (which in turn is caused by the current version of apr having failed to build on armv7hl before)
16:25:29 <ben79> 'nuther question, when the packages break that is on ABF?
16:26:08 <bero> ben79: Right now getting the list of broken packages is more challenging than fixing them
16:26:14 <ben79> so if there isn't such a list we need to learn to look for broken packages no ABF?
16:26:28 <ben79> no ABF >> on ABF
16:26:58 <bero> essentially what happens right now is we build something like qt, see that it's failing because of e.g. cups, then see that that, in turn, is failing because of php etc.
16:27:03 <itchka> ben79: Basically it works like this.. You try to build a package
16:27:14 <bero> with any of those it's faster to just fix what's broken than to even complain about it being broken
16:27:31 <ben79> OK
16:27:44 <itchka> It can can in one of two ways either because of a missing or out of date dependency.
16:27:48 <itchka> OR
16:27:48 <bero> the mass build will change that because all of a sudden there will be 1000s of known bad things instead of 1 package getting in the way of 1 target
16:28:11 <itchka> It's just plain broken and will not build.
16:29:10 <ben79> so the trivial errors tend to be simply things that need to be changed in the .spec file or other file?
16:29:21 <itchka> Believe it when I say that the package thgat just won't build because of som error is a lot easier to fix than one with a missing dependency!!!
16:30:52 <ben79> packages that won't build usually tell us if there is a syntax error, of other error, or if there is a missing dependency as I recall
16:31:02 <ben79> in build.log
16:32:11 <bero> right
16:32:51 <ben79> OK, back to #topic Lx4 Release Plan
16:32:56 <itchka> Basically yes..you need to study the build log as the actual source of the error is not always obvious. using the search term in your browser using the term error: (note he the colon)  can be quite helpful.
16:33:17 <itchka> Lx4 is going to be a bit of the landmark release; I feel we need to try and promote it as we go along. One idea I had was that we could perhaps use is to publish some kind of benchmarking data as develoipment progresses
16:33:58 <ben79> Yes, it would be good if we could get something about it in our blog soon for instance
16:34:40 <ben79> and then have weekly blog posts, which I think _TPG is kind of doing in Facebook?
16:35:05 <bero> agreed... We need to promote it more
16:35:28 <ben79> I'm not a social media person so would like to see publicity in more traditional modes like in our blog and forum
16:35:37 <AngryPenguin> also rememer, to send info to websites like softpedia/linux or phoronix
16:35:52 <itchka> There will also be a need for some new artworks. I would particularly like to see an animated bootsplash since we have the in kernel bootsplash generator in our kernels so some ideas for that would be useful.
16:36:02 <bero> In addition to just being better and having all the new core bits, it's also going to be the first release that works properly on aarch64 and armv7hl...
16:36:34 <bero> I'd also prefer more traditional publicity -- Sucker-berg is a world class a**hole, I like boycotting Fakebook
16:36:42 <ben79> AngryPenguin: Yes by all means, we do miss our public relations person Kate Lebedeff... maybe I need to learn how to do that
16:36:55 <itchka> That's a big thing bero...We need to publish that in the right arena.#
16:37:12 <bero> And with some luck we'll even have RISC-V working as well
16:37:32 <bero> but no guarantees on that one yet, pretty much depends on when the hardware will ship
16:37:50 <ben79> itchka: you know who to talk to for artwork but there is a new player on that front as well jimmyc
16:38:47 <bero> That's good, it's certainly better to have more than 1 person for something... I just hope their ideas are somewhat compatible
16:39:05 <itchka> Thanks ben79 I'll bear that in mind.
16:39:11 <ben79> Don't like facebook but me "Mississippi/Louisiana country folk" family is stuck on it...
16:39:56 <ben79> so far nothing jimmyc has been used so we will see...
16:40:33 <itchka> He did some fun stuff with the bee though :)
16:40:38 <ben79> Officially as far as I know the Artwork Team is rugyada
16:40:47 <itchka> Yes
16:41:09 <ben79> But I would like to see Lx 4 artwork be more "different" form our previous releases
16:42:29 <ben79> As far as traditional publicity I *think* it is simply a matter of sending e-mails to correct places and they either publish or not at their discreation
16:42:36 <itchka> Well let's sse if we can get some discussion going.
16:43:07 <ben79> So I could do that if I had a list, I'm not interested in doing social media, someone else needs to do so
16:43:27 <ben79> itchka: discussion about Lx 4 artwork?
16:43:32 <itchka> yES
16:43:38 <ben79> Agreed
16:43:48 <ben79> aGREED
16:44:01 <ben79> :)
16:45:41 <itchka> I wonder whether we could take advantage of Plasma's task based interface to provide some pre-configured task based desktops.
16:47:47 <ben79> not sure what that means or what it would entail
16:50:43 <itchka> Phone call.
16:54:52 <itchka> Back
16:55:36 <itchka> I'll see if I can outline a couple of ideas and put them on the forums.
16:56:16 <ben79> OK, might be interesting...
16:56:28 <itchka> We need to move on as I have to go and do other stuff soon.
16:56:35 <itchka> #item 3
16:56:45 <itchka> #topic AIB
16:57:08 <itchka> ben79: Do you have any pressing bugs for us?
16:57:12 <ben79> To reiterate this is focused on bugs against Lx 3 not Cooker at this time. This first bug has been time consuming for me so far.
16:57:12 <ben79> Crash on openMandriva 3.03 >>> https://bugs.kde.org/show_bug.cgi?id=393348 >>> https://forum.openmandriva.org/t/kde-crash/1770
16:57:12 <ben79> The KDE.org bug # 393348 has had some progress, fdrt built a 'plasma-workspace-debuginfo' package and some others to go with it. The problem currently is that when the user tries to create a backtrace on most recent '/usr/bin/plasmashell' crash all he's getting is:
16:57:12 <ben79> (gdb) bt
16:57:12 <ben79> #0 0x00007f0bbf584e87 in ?? ()
16:57:13 <ben79> Backtrace stopped: Cannot access memory at address 0x7ffd4c04e480
16:57:16 <ben79> and I don't know what's next. Don't know why he isn't getting a bt. Or if there is something wrong with his computer.
16:58:27 <ben79> The other 2 bugs are unfortunately hold overs from last time we did AIB which has been a few weeks. (The good news there is that currently not a lot of bugs are being filed against Lx 3.)
16:58:27 <ben79> cannot install python-tables due to dependency issues >>> https://issues.openmandriva.org/show_bug.cgi?id=2337
16:58:27 <ben79> blender produces a segmentation fault (core dumped) when started >>> https://issues.openmandriva.org/show_bug.cgi?id=2341
16:59:22 <ben79> someone mentioned something about the python-tables and a certain version of python or something but I forgot what was said
16:59:39 <itchka> 2337 shouldn't be too hard to fix.
16:59:57 <ben79> Excellent
17:00:26 <itchka> Should just be rebuilds
17:00:42 <ben79> 2341 *may* be just a missing or out of date dependency
17:01:28 <ben79> The big question I would like answered is why that user can't get a backtrace? in the first one mentioned
17:01:43 <ben79> Something wrong with his computer?
17:02:52 <ben79> and plasma-workspace is package that provides plasmashell but is plasma-workspace-deguginfo the only debug package needed for plasmashell crash backtrace?
17:03:26 <itchka> Clearly not sicnce there is no symbol shown for the call.
17:05:14 <itchka> First thing is that this seems to be a gui bug. It would be worth knowing what graphics hardware is in use and which drivers are being used.
17:07:34 <ben79> I think nvidia and nouveau driver
17:08:43 <itchka> The KDE bug report mentions Intel . Are you able to reproduce this Ben?
17:09:52 <ben79> no
17:09:57 <ben79> 60.790] (II) modeset(0): [DRI2]   DRI driver: nouveau
17:09:57 <ben79> [    60.790] (II) modeset(0): [DRI2]   VDPAU driver: nouveau
17:12:19 <itchka> Perhaps he should try the nVidia proprietry drivers?
17:12:59 <ben79> If you look in the forum thread he has provided xsession and Xorg.0.log logs
17:13:03 <itchka> nouveau can't do multi-threading too well..maybe it's that.
17:15:08 <ben79> OK, what I think is that his issue is to complicated for a middle man and he needs to come here himself,
17:15:56 <itchka> ben79: I have nVidia I'll see if I can reproduce here. I seem to recall switching to the proprientry drivers becaus eof crashes.
17:16:06 <ben79> fdrt and itchka have shown a willingness to help on this issue and maybe if TPG is around he would also
17:17:06 <ben79> I spent the better part of an afternoon trying to get plasmashell to crash  and didn't get there so let me know if you can how you crash it
17:17:55 <ben79> it is actually the menu panel that appears to be crashing
17:19:09 <itchka> Ok Ben I'll give it a go.
17:19:24 <itchka> Need to move on as I have to go.
17:19:33 <itchka> #item 4
17:19:42 <itchka> #topic AOB
17:20:30 <itchka> I'll leave the meeting open until half-past the hour and then if there is nothing I 'll close it.
17:26:56 <AngryPenguin> As for the two bugs with the blender and python-tables, I tried to rebuild the packages a month ago but without success.
17:27:39 <itchka> They woulkd not rebuild or did not run?
17:28:13 <AngryPenguin> build error
17:28:58 <bero> probably dependency issues?
17:29:02 <itchka> Can you point me to the build lists?
17:29:16 <AngryPenguin> blender first with dependencies and after fix dep, then
17:29:20 <AngryPenguin> blender/imbuf/intern/dds/Common.h:38:26: error: 'fmax' was not declared in this scope
17:29:21 <AngryPenguin> DEBUG util.py:265:   #define clamp(x,a,b) min(fmax((x), (a)), (b))
17:29:52 <AngryPenguin> https://abf.openmandriva.org/build_lists/165273
17:30:20 <bero> That's probably a missing include
17:30:36 <AngryPenguin> or better this
17:30:37 <bero> #include <cmath>
17:30:41 <AngryPenguin> https://abf.openmandriva.org/build_lists/164285
17:30:56 <bero> or #include <math.h> if it's C code (rather than C++)
17:31:58 <AngryPenguin> it would be a good idea to upgrade the blender
17:32:04 <bero> /builddir/build/BUILD/blender-2.76b/source/blender/imbuf/intern/dds/DirectDrawSurface.cpp:1105:7: error: 'max' was not declared in this scope
17:32:07 <AngryPenguin> but new version needed new python
17:32:07 <bero> same sort of issue
17:32:19 <bero> either #include something that defines max or define it...
17:32:30 <bero> #define max(x,y) ((x) > (y) ? (x) : (y))
17:33:23 <itchka> You Ok to fix this AngryPenguin?
17:34:34 <AngryPenguin> I can try
17:34:51 <itchka> Ok Thanks :)
17:35:13 <itchka> I have to go so closing the meeting
17:35:21 <itchka> #endmeeting