16:09:54 <itchka> #startmeeting
16:09:54 <chwido> Woof! Let's start the meeting. It's Wed Nov  8 16:09:54 2017 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:09:54 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:09:54 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:09:54 <chwido> Have a good meeting, don't bark too much!
16:10:59 <itchka> Here's a basic agenda
16:11:02 <itchka> 1. Release: Will we ever get this right
16:11:04 <itchka> 2. https://forum.openmandriva.org/t/new-updates-gcc-7-2-will-set-me-out-of-business/1441. Rebuild of contrib? Discussion
16:11:05 <itchka> 3. Reports:-
16:11:07 <itchka> rpm
16:11:08 <itchka> 3.    AIB (Any Interesting Bugs)
16:11:10 <itchka> 4.   AOB
16:11:14 <itchka> #item 1
16:11:27 <itchka> #topic Release: Will we ever get this right
16:12:36 <itchka> I have to say that we are struggling. As fast as we fix things something else gets broken.
16:13:38 * bero wonders how things get broken on what is essentially a dead branch
16:13:49 <itchka> I have been in converstaion about the 5.2.0 version of Virtual Box and their felling is that we woould be better off releasing 5.2.2 when it comes.
16:13:59 <ben79> Is the "kernel oops" in VBox something that happens when trying to boot ISO in to 'Live' or 'Install' or both?
16:14:07 <bero> so when can we expect 5.2.2?
16:14:19 <Son_Goku> no one knows
16:14:33 <Son_Goku> there's a lot hinging on the upstream reviews of the vbox guest additions
16:14:34 <ben79> We could update to 5.1.30 in VBox
16:14:47 <Son_Goku> as Fedora is moving to merge cleaned up versions of those modules into the kernel
16:14:57 <itchka> bero: Because certain individuals keep pushing updates to fix things like wayaland which nobody uses
16:15:34 <bero> Fixing stuff that's primarily interesting for the future is what cooker is for...
16:15:38 <ben79> Well basically it's new packages if we stop upgrading things we can stop breaking things
16:16:26 <itchka> The only reason we built the later vbox was to try and fix a kernel oops when booting the iso.
16:17:20 <itchka> It's not been pushed yet so we can dump it if we want to. We can dump the later kernel too since that has not been pushed either.
16:17:41 <ben79> VBox 5.2 isn't in OMLx 3.03 currently anyway
16:19:08 <ben79> So the VBox issue as I understand is the "kernel opps" but I'm not sure I've ever seen it.
16:22:14 <itchka> You could reproduce it by video recording the session. That's how crazy did it. It happens for me every time.
16:22:38 <christann> vbox guest additions will not run on the latest version of Windows 10 (at least it doesn't here).
16:22:49 <ben79> Yes but are you talking about booting the ISO or booting an installed system?
16:23:21 <itchka> ben79: Iam talking about the booting the ISO in VB.
16:23:41 <ben79> OK
16:24:58 <itchka> The last thing we want is some reviewer not be able to review it because he can't get further than the start up screen.
16:25:55 <itchka> It's somethimg to do with plymouth get rid of plymouth and everything works.
16:30:58 <itchka> I suggest we disable plymouth on the iso and go with that. At least then most things work although there are still issues in the troubleshooting menu with xauth.
16:31:29 <bero> Someone at ELC-E said there's some work happening on a kernel based splash screen system that should kill plymouth at some point
16:31:33 <bero> hope that'll be ready soon
16:32:16 <itchka> Yes SUSE are doing it. It's already available as a kernel patch apparently.
16:32:51 <itchka> Perhaps we should thow all caustion to the winds and pilot it.
16:33:17 <ben79> For now lets just disable plymouth for VBox
16:33:42 <Son_Goku> itchka: I wouldn't suggest it
16:33:52 <Son_Goku> but that said, Fedora doesn't enable plymouth for live media
16:34:01 <Son_Goku> only on the installed system
16:34:05 <Son_Goku> so that might work
16:34:46 <bero> why would it work on the installed system if it doesn't work on live?
16:35:56 <bero> where is that suse patch? Would be nice to have a look at it (even though I'm a bit skeptical of throwing it at 3.x -- but it may be something to look at for cooker at least)
16:36:08 <Son_Goku> SUSE does not have the patch applied anywhere
16:36:14 <Son_Goku> it's only an RFC patch series in the kernel ML
16:39:28 <itchka> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1521693.html
16:42:45 <itchka> Plymouth has never really worked properly for us and now that booting is getting faster and faster it's becoming less and less relevent.
16:43:38 <Son_Goku> bbl, going to lunch
16:43:48 <ben79> I don't have a problem with getting rid of Plymouth
16:43:55 <itchka> We can disable it in grub on the iso so the filesystem image will be untouched and thus it will be enabled when installed.
16:44:29 <ben79> I don't mind 'text' mode booting
16:46:25 <itchka> Well as far as I'm concerned it's either disable it on the iso or delay another week or maybe more whicle we track down the issue.
16:47:35 <ben79> Disable on the ISO, maybe forever
16:49:44 <bero> The problem is that reviews will rip us apart
16:50:07 <bero> "They claim to be user friendly but they confuse the user with lots of unintelligible text messages at bootup. Go Ubuntu!"
16:53:22 <itchka> If that's situation then we need to put some resouces in to fix it. I have doe everything I can and I'm out of ideas solutions. The VB guys say we need to connect to the vm via a serial port and get the full kernel trace to be able to get to the bottom of it.
16:54:18 <itchka> I'm happy to try this but it will take time.
16:54:47 <bero> That patch set looks really reasonable...
16:54:52 <bero> https://lkml.org/lkml/2017/10/25/359 <--- see the comments there
16:55:07 <bero> I think I'll add that to the cooker kernel, then we can see whether or not we want to backport it
16:57:53 <itchka> Ok bero that would be good. In the link I posted it mentions some mods to allow animations and pictures,
16:58:29 <bero> yes, that's the subsequent patches e.g. here https://lkml.org/lkml/2017/10/25/356
17:04:38 <itchka> Am I still connected?
17:04:49 <ben79> nope
17:05:02 <ben79> oh, wait, I mean yep
17:06:33 <bero> maybe ;)
17:11:06 <itchka> Oh good
17:11:30 <itchka> My connection has be behaving starngely all day.
17:12:06 <ben79> Um, given difficulties with VBox 5.2 should we consider upgrading to VBox 5.1.30 for Lx 3?
17:12:11 <itchka> My touch typing is not getting any better
17:13:37 <itchka> ben79: It's easy enough to do; though we would need to rebuild the kernel.
17:14:24 <itchka> bust since we would so that anyway for the splash patch if it works it wouldn't be too bigger deal.
17:14:40 <ben79> FWIW: as far as including vbox-guest-additions to kernel it isn't working anyway users still have to install the package
17:15:14 <itchka> As far I'm concerned 5.2.0 is a dud and we shoudln't run with it.
17:15:59 <itchka> It got badly broken while being created and wasonly fixed at the last minute.
17:16:11 <ben79> I'm thinking we upgrade to 5.1.30 and work on fixing the kernel/boot issue
17:16:31 <ben79> Even VBox devs reccommened that we skip VBox 5.2
17:16:35 <itchka> Thet have had staff turnover and lost expertise.
17:16:55 <itchka> I'll go with that.
17:17:58 <itchka> I'll build 5.1.30 locally and see how ot works.
17:18:42 <ben79> I would think we should build it regular way to testing repo so more can test
17:19:35 <ben79> and so you have more time for the real problem
17:20:52 <itchka> I just do it as a check to make sure what I push to the repos is working it's building now.
17:23:04 <itchka> One patch failed
17:39:23 <itchka> Ok well it looks like it's going to be a few days before we can decide what to do. So plan of action. Dump new kernel and vb 5.2.0; build vb 5.1.30 rebuild kernel with new modules and test. Rebuild kernel again when bero has patched. OK ?
17:42:51 <itchka> ben79: BTW there's a new nvidia-current. I'll try and update the others too but they are more problematic at the moment.
17:43:22 <itchka> It works ok here but it needs more testing.
17:43:29 <ben79> OK, I guess I'll post on the forum
17:43:48 <itchka> Please if you would
17:44:52 <itchka> Ok I thing we can close the release subject fro the time being.
17:46:04 <itchka> bero: Let me know when you have something for us to test.
17:46:37 <bero> kernel is currently building with the bootsplash patches rebased and enabled
17:46:53 <bero> Not yet sure it'll finish compiling given my rebase might not be 100% complete
17:47:00 <itchka> Wow you are fast!
17:47:01 <bero> we'll also need to figure out how to create a bootsplash image
17:47:45 <itchka> Are there any clues like is it a sttaight bitmap?
17:48:26 <itchka> maybe the plymouth splashes would work; they are doing pretty much the same thing.
17:48:59 <bero> No, it's something very different
17:50:14 <bero> it's semi-documented in one of the patches
17:50:46 <bero> https://patchwork.kernel.org/patch/10026619/
17:51:25 <bero> I've pinged the guy who wrote the patches about the tool that creates a bootsplash file, but no reply yet (not much of a surprise given I just sent it 10 minutes ago)
17:56:21 * ben79 Here's forum post: https://forum.openmandriva.org/t/call-for-testing-for-nvidia-current-384-98-1/1500
17:56:43 <itchka> Good man
17:57:15 <itchka> bero: We can test with a blank screen so it won't hold us up.
17:59:45 <ben79> should we go ahead and remove VBox 5.2 and kernel 4.13.11-2 packages from main-testing?
18:01:04 <itchka> ben79: Already done.
18:02:02 <itchka> I just need to do a little patch fix on 5.1.30 and we can build that.
18:06:13 <ben79> Uh, Oh, we may have a problem,or this takes longer than I realize, VBox and kernel packages are still in main-testing repo though removed from Kahinah
18:16:35 <itchka> Well if they don't get removed soon we will have to ask bero to nuke at least the virtualbox one.
18:17:06 <itchka> Anyways lets move on.
18:20:47 <ben79> Rebuild contrib?
18:20:53 <itchka> I'm not too keen on a long discussion on rpm this week. There's a lot at stake with this and I think it would be better to discuss and mull things over
18:21:08 <itchka> after the release.
18:21:18 <ben79> Is it possible to rebuild contrib?
18:21:20 <itchka> Yes lets look at contrib
18:22:00 <itchka> #item 2
18:22:04 <ben79> I had to actually ask users to stop reporting broken packeges in contrib
18:22:16 <ben79> There are so , so , many
18:22:22 <itchka> #topic  https://forum.openmandriva.org/t/new-updates-gcc-7-2-will-set-me-out-of-business/1441. Rebuild of contrib? Discussion
18:23:42 <itchka> ben79: Inevitably there will be many many broken packages more so now that gcc has been updated.
18:26:04 <itchka> When things are quieter we could try a mass build just to see how bad the problem is.  There will be a lot of stuff in contrib which is no longer mainatined but qually there is going to be some good stuff which it would be nice to have working.
18:26:22 <ben79> This goes back long before latest gcc to beginning of Lx 3
18:28:12 <itchka> Lets have some suggestions as to how the community might be engaged in this task .
18:28:29 <ben79> there's a ton of , especially edu and science/math, packges in Lx that never have worked, they go back to really Mandriva through 2014
18:29:08 <ben79> inchka: that is exactly what we need
18:31:55 <ben79> and if ABF was really automatic (it isn't) then that might work
18:32:46 <ben79> but maybe there is a way to simplify or otherwise create a way for community members to get involved?
18:36:16 <itchka> One of the big issues I have found in fixing things in contrib is that it is not a single task like saying fix that package and everything is fine. It just doesn't work like that.
18:38:10 <itchka> What normally happens is that you end up chaseing up a dependency tasks that may be a chain of eight ot nine packages before you reach the top.
18:40:16 <ben79> Which sounds like a ton of work
18:40:39 <itchka> Unless you know what the top level of the chain is you can waste an inordinate amount of time trying to build stuff. As you can imaging each depdndency package may have a dependency chain of it's own which means the issue blooms into a huge task very quickly.
18:41:53 <itchka> What is needed is a way to target the packages that have the most deps and get those sorted out.
18:42:15 <itchka> bero: Are there tools for this kind of thing?
18:42:34 <ben79> Well there is this guy in Romania
18:42:46 <Pharaoh_Atem> back
18:42:48 <ben79> but I guess that ship has sailed
18:44:56 <itchka> Yes, symbianflo shame about the clash of egos we really missed out there. He did sort out ROSA'S contrib so there is a source of patches.
18:52:37 <itchka> Pharaoh_Atem: If we wanted to find the topmost dependencies in the contrib repo how would me go about it?
18:52:42 <ben79> well, then that is something to work with but I think the problem is going to be getting people with enough knowledge and developed skills to employ the patches
18:53:40 <Pharaoh_Atem> itchka: what do you mean by that?
18:53:52 <itchka> ben79: The only thing we can do is train then
18:53:57 <Pharaoh_Atem> do you mean reverse dependencies (what depends on this thing) or forward dependencies (what does this thing depend on)?
18:54:47 <ben79> How well has that worked with ABF? The people frurtherest along with that Mandian and Adelson profess to not really understand how thing work there
18:54:48 <itchka> I mean reverse dependencies like work from the bottom up until you reach the real key ones.
18:55:43 <itchka> Pharaoh_Atem:  ^^
18:56:05 <Pharaoh_Atem> so there are two ways
18:56:11 <Pharaoh_Atem> you could do a full repograph
18:56:34 <Pharaoh_Atem> or you can do a whatrequires query for each package that you care about
18:57:11 <itchka> How would I do a full repograph?
18:58:03 <itchka> That would anable us to target work to get the maximum amount of packages fixed for the minimum amount of labour.
18:58:15 <Pharaoh_Atem> if you have a working yum and yum-utils package, there's a repograph program included
18:58:55 <itchka> would that work with our repo data?
18:59:21 <Pharaoh_Atem> I'd be surprised if it didn't
18:59:33 <Pharaoh_Atem> also, dnf has a repograph thing as well
18:59:53 <Pharaoh_Atem> but I didn't get that far to package the repograph plugin
18:59:58 <Pharaoh_Atem> I could, though
19:00:14 <Pharaoh_Atem> since that doesn't really require the rpmdb to work (though I may have a preliminary libsolv patch to fix that)
19:01:35 <Pharaoh_Atem> it doesn't look like yum-utils is packaged in OpenMandriva
19:01:45 <Pharaoh_Atem> and yum is broken dependency-wise in OpenMandriva, too
19:01:54 <itchka> Pharaoh_Atem: it would be useful to have if you could do it.
19:02:14 <Pharaoh_Atem> I'll give it a go
19:02:23 <Pharaoh_Atem> but contrib needs to have up-to-date rpm-md repodata
19:02:27 <Pharaoh_Atem> otherwise it won't work
19:02:51 <itchka> I'll ask fedya to run createrepo_c on it.
19:06:43 <itchka> ben79: There we have a start :) We will at least be able to find out the magnitude of the task and how perhaps we can optimise it.
19:07:11 <ben79> OK, that'll be a good thing then
19:07:55 <ben79> It would be a good start also just to know how many broken packges there are vs. total packages
19:08:46 <itchka> It will need several months of determined effort to be able to get people doing something with it.
19:09:57 <ben79> I suppose it is worth a try
19:11:17 <ben79> So a couple of things to put on some to do list would be :
19:11:30 <ben79> 1. Flow chart for package management
19:11:33 <ben79> and
19:11:39 <itchka> Well it is something that the community can get behind and maybe get some training in packaging. If we could just have half a dozen who were bel to do that it would make an enormous difference.
19:12:02 <ben79> 2. An up to date "How To" for package management
19:12:13 <ben79> To my knowledge we have neither
19:12:50 <ben79> But we do have a need to create package maintainers to reduse load on our developers
19:12:56 <ben79> A MAJOR need
19:13:22 <ben79> reduse is either reduce or a Freudian slip
19:14:26 <Pharaoh_Atem> well, I've been sharing this around to Fedora and Mageia packagers: https://rpm-packaging-guide.github.io/
19:14:28 <ben79> That does tie in to this effort doesn't it?
19:14:49 <Pharaoh_Atem> hopefully it'll become more useful for OpenMandriva ones once we get the DNF stack and similar tooling in place
19:15:52 <ben79> We, OpenMandriva, need something maybe either more basic or more inclusive like what the relationship is between Github and ABF to users (me included) this is currently a mystery
19:15:57 <itchka> Thanks Pharaoh_Atem
19:16:06 <ben79> as we publicize nothing about what contributors do
19:18:07 <Pharaoh_Atem> there is no relationship :)
19:18:15 <Pharaoh_Atem> GitHub is just a git hosting source, like any other
19:23:37 <ben79> OK, what is a git and it is different form what? Just curious.
19:24:09 <ben79> Are there other sites that host gits?
19:24:27 <itchka> I have been meaning to do a series of video talks about abf and packaging to get people started.
19:24:55 <ben79> I just googled git, so maybe don't explain here
19:25:56 <itchka> There are herds of them :)
19:27:12 <itchka> git is after all is said and done female goat!!
19:27:24 <ben79> itchka: What do you mean, herds of what?
19:28:22 <itchka> female goats! The humour is perhaps a bit too English.
19:28:48 <Pharaoh_Atem> git is a version control system
19:29:12 <Pharaoh_Atem> https://git-scm.com/
19:29:35 <Pharaoh_Atem> ABF, like Koji and many other build systems, rely on an external source control / version control system
19:30:14 <Pharaoh_Atem> ABF, at one point, was configured to manage the Git repositories itself, but it now relies on GitHub instead
19:31:06 <ben79> OK, thanks, that's a start for me at least
19:31:27 <ben79> So scm=software configuration management
19:35:19 <itchka> ben79: It would be time well spent getting a feel for git. It was written by Linux Torvalds to help in the management of the kernel source tree. It's a great piece of sofware.
19:36:06 <itchka> It even has a Gui....
19:36:47 <ben79> So, before we move on, simply speaking one would start learning (relearning in my case) rpm packaging locally, and git then github then ABF (which only Russians really understand)
19:36:47 <itchka> In fact two (as well as number of third party ones)
19:37:44 <ben79> (I *think* I was kidding about ony Russians understanding ABF, or so I hope)
19:38:07 <itchka> You can learn both rpm packaging and git locally and you can get the data you need using abf tools.
19:38:53 <bero> ben79: you're actually right, I only understand ABF as a user, and I think it's pretty much the same for TPG
19:40:01 <ben79> I already know, though haven't done it in a long time, that simply building .rpm's locally isn't all that difficult, difficult comes in when your bullspit has to work with other peoples stuff
19:40:33 <ben79> let's table this for now, so meeting doesn't last for ever
19:40:51 <itchka> Ok
19:41:07 <itchka> bero: How's the kernel build?
19:42:25 <itchka> I've fixed up virtualbox-5.1.30 and that builds now, so I'll push it ot 3.0
19:49:43 <ben799> I'm trying to get ISO 1549 to not boot in
19:49:52 <ben799> vbox and can't do it
19:50:11 <ben799> it works even on my notebook with video capture enabled
19:50:29 <ben799> trying now with video apture and booting from a DVD
19:51:29 <ben799> damn, I'm normally really good at breaking things
19:52:40 <ben799> Dadgummit it works no matter what I do!!!
19:52:52 <itchka> Try increasing the resolution or screen size in the video capture part. But hang I have just thought video capture is not working in 5.2.0 so probably it's having no effect. You need to be on the older version.
19:53:09 <ben799> So that might eliminate time as a factor in why it won't boot for Colin
19:54:06 <ben799> is it hardware?
19:55:04 <ben799> I am on the older version and I have checked and video capture does work
19:55:22 <itchka> It has never worked for me irrespective of VB version crazy triggered the fault by slowing VB down it won'ty work for you becasue you can't slow VB 5.2.0 down in that way because video capture is boken and it's not creating a file.
19:55:37 <ben799> currently res is 1366x768 which is maximum screen size for this computer
19:56:32 <itchka> Maybe he did  something else as well. I can send you his video if you like.
19:56:41 <ben799> Im not using 5.2 I'm using VBox 5.1.26 video capture is working
19:56:58 <ben799> OK
19:58:26 <itchka> ben79: It's here http://ftp.frugalware.org/pub/other/people/crazy/OOPS-in-splash.mkv
20:00:29 <ben79> Can't tell anything from that it starts with grub2 screen I need to see if something in settings or config is different
20:01:34 <ben79> I do know that our kernels do occaisionally don't boot but I just reboot and usually it then works
20:03:29 <ben79> and when I see that happen it is the same error as in the video from crazy
20:04:36 <itchka> Yes it used to be like that for me but now it happens all the time.
20:07:28 <itchka> Anyway Ben there's nothing more we can do with that one except to connect to the box via a serial terminal and get a proper log.
20:07:39 <ben79> OK, onward
20:08:18 <itchka> any bugs that are important?
20:09:34 <ben79> https://issues.openmandriva.org/show_bug.cgi?id=2154
20:09:56 <ben79> this one has been around for a while without resolutions
20:11:30 <ben79> otherwise most of the important recent bugs don't have bug reports,
20:11:58 <ben79> they are development bugs we just talked about
20:12:04 <itchka> Have you searched aroun to see if the problem has been reported elsewhere?
20:12:19 <ben79> then there are as many Blackcrack bugs as any developer could wish for...
20:12:31 <ben79> me, no
20:12:47 <itchka> Ok I'll take a look
20:17:58 <itchka> I like to suggest that we pick up the rpm thing again after we have done the release. There's just too much other stuff to think about at the moment.
20:20:40 <ben79> I just checked and the issues in bug 2154 are still valid
20:26:01 <itchka> Ok
20:26:49 <itchka> It's getting late and I need to eat. If everyone is happy I'll close the meeting now.
20:27:37 <ben79> close it
20:27:50 <itchka> #endmeeting