15:14:08 <itchka> #startmeeting
15:14:08 <chwido> Woof! Let's start the meeting. It's Wed May 16 15:14:08 2018 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
15:14:08 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:14:08 <chwido> You should add extra chair(s) just in case, with #chair nick.
15:14:08 <chwido> Have a good meeting, don't bark too much!
15:14:53 <christann> Hi all
15:15:04 <itchka> Hi
15:15:14 <itchka> heres' the agenda
15:15:18 <itchka> 1. Report: ABF cooker dnf
15:15:19 <itchka> 2. Lx4 Release Plan. Initial discussions
15:15:21 <itchka> 2. AIB
15:15:22 <itchka> 3: AOB
15:15:24 <itchka> #item 1
15:15:39 <itchka> #topic   Report: ABF cooker dnf
15:15:55 <itchka> Over to you bero and Pharaoh_Atem
15:16:19 <bero> Lots of progress, but still not in the best shape...
15:16:36 <bero> The amount of dependencies we have in order to build a pretty basic system these days is scary
15:16:46 <itchka> QT5?
15:17:31 <bero> yes -- qt5 wants gtk3 for the theme support, gtk3 wants gtkwebkit, which wants vala and (among other things) librsvg, which wants rust and cargo, which have always been a pain to bootstrap, etc.
15:18:06 <bero> the good news is that we now have support for just about all the languages from java to rust sorted out
15:18:26 <bero> so now libraries should be getting a lot easier
15:19:28 <bero> would be nice to get rid of all the gcrap and its insane dependency chains though ;)
15:19:40 <itchka> rust and cargo...yuk I did some work on that last year it was very broken for clang.
15:20:03 <bero> the big problem with those things is that they essentially require themselves
15:20:08 <bero> rust is written in rust
15:20:17 <bero> so bootstrapping it is hard
15:20:41 <bero> and it was in bad shape before (current version only in the x86_64 tree, outdated version in i686 and aarch64, nothing at all in armv7hl)
15:20:57 <bero> all the things that were broken even before the dnf move are coming back to bite us now
15:21:17 <bero> everything is updated and built for every platform now
15:21:24 <bero> I sure hope it'll stay that way ;)
15:21:33 <itchka> If I remember correctly they always build with the previous version the trouble if that doesn't build you are kinda stuck!
15:22:16 <bero> exactly
15:24:07 <itchka> Anything we should target.
15:25:48 <itchka> I note that with you help angrypenguin got blender to build.
15:25:51 <bero> I'm still targeting getting qt to build, on top of that all the UI stuff should be buildable again, so we can get ready for the mass build...
15:28:21 <bero> I think we're getting really close to that
15:29:02 <itchka> Qt4 still seems to be required for some packages and that ppears to be very broken.
15:29:25 <bero> not that bad, it should build with -std=gnu++98 added to the compiler flags
15:29:56 <bero> I'd hope we can get rid of it sooner rather than later though, everything still using it should really move to qt5
15:30:08 <bero> preferably before qt6 is out ;)
15:32:19 <itchka> Sorry I've not been very active on cooker this week..spring puts me outside for garden maintenence and lawn mowing!
15:35:20 <itchka> Pharaoh_Atem:  any comments ?
15:38:54 <itchka> bero: I guess we just plod on. Do you think getting a release out this year is realistic?
15:39:06 <bero> Certainly
15:39:10 <bero> if not, we should just give up
15:39:49 <itchka> That's cheered me up :)
15:40:18 <crazy> itchka: what packages still want Qt4 ..
15:42:32 <itchka> crazy: Can't recall now it was down a long string of deps that started with postgres I think. You know how these things go you end up hundreds of mile from where you stsrted.
15:43:53 <crazy> Blackcrack: what kind of weird feature request is that https://github.com/calamares/calamares/issues/952 ?
15:44:06 <crazy> itchka: QT4 stuff should just die ..
15:45:32 <bero> $ dnf repoquery --whatrequires lib64qtcore4
15:45:36 <bero> gives quite a list...
15:46:18 <crazy> bero: can you post that list somewho ?
15:46:46 <bero> but most of what it shows is either compat cruft (akonadi-kde4, baloo-kde4, breeze-kde4, ...) or optional bits that have qt5 equivalents anyway (fcitx-qt4)
15:46:53 <crazy> bero: you are better to use a qt5/kf5 branch when available than broken Qt4 ones
15:47:24 <crazy> bero: what for you need akonadi-kde4 and freinds ?
15:47:30 <bero> crazy: Agreed
15:47:47 <bero> itchka: https://pastebin.com/2FXYmbXC
15:47:54 <bero> crazy: Nothing -- that's why I was calling it compat cruft
15:49:26 <crazy> bero: then maybe first kill all kde4 and revdepends ones .. not much should be left then .. and the rest should have qt5 equivalents
15:49:34 <bero> While the list is large, I don't see anything I'm concerned about...
15:49:42 <bero> mostly KDE4 compat cruft libraries
15:49:47 <crazy> yepp
15:50:21 <bero> Some stuff that might be worth looking at (not sure what some of that is actually):
15:50:27 <bero> avogadro (I think this has a qt5 branch)
15:50:50 <itchka> does kwallet have a Qt5 equivalent?
15:50:56 <bero> bluedevil (probably its successor is already in a different package)
15:51:04 <bero> cagibi (what is this?)
15:51:08 <bero> dssi (what is this?)
15:51:18 <bero> grive (what is this?)
15:51:25 <bero> jovie (what is this?)
15:51:28 <bero> juffed (what is this?)
15:51:46 <bero> kfilereplace
15:51:59 <bero> kfingermanager (but does anyone really use finger anymore?)
15:52:15 <bero> klinkstatus
15:52:19 <bero> klook
15:52:24 <bero> kommander
15:52:34 <bero> kopete (has a qt5 branch)
15:52:39 <bero> kover
15:52:41 <bero> kppp
15:52:48 <bero> kremotecontrol
15:52:51 <bero> ksaneplugin
15:52:54 <bero> kscd
15:53:00 <crazy> bero: https://github.com/openchemistry/avogadrolibs <-- this replaces old avogadro1
15:53:34 <bero> qastools (what is this?)
15:53:34 <crazy> bero: all k<apps> are not yet in kde apps release are gone upstream
15:53:40 <bero> qlipper (what is this?)
15:53:57 <crazy> bero: some may still have some branch in extragear/*
15:54:06 <bero> rosa-launcher (probably there's better bits in plasma anyway)
15:54:15 <bero> rosa-media-player (probably smplayer is better anyway)
15:54:28 <bero> sphere-client-rosa (what is this?)
15:54:34 <bero> touchfreeze
15:54:37 <bero> unetbootin
15:54:43 <bero> vtk-test-suite
15:54:43 <crazy> bero: grive -> kio-gdrive
15:54:46 <bero> zart
15:54:59 <bero> that list is much smaller already...
15:55:36 <bero> I think I'm not overlooking anything when I'm saying everything else in the list either has a qt5 port already or is obsolete
15:56:25 <crazy> jovie is old kde4 text-to-speech won't work anyway with plasma5
15:56:47 <bero> good candidate for removing then...
15:56:56 <crazy> bluedevil is now bluedevil5
15:57:14 <bero> probably time to kill it and rename bluedevil5 back to bluedevil
15:57:17 <crazy> kfile* should be all in kf5 now etc
15:57:58 <bero> kscd can probably be replaced with smplayer as well, AFAIK it can play audio CDs
15:59:14 <crazy> bero: yes
16:00:33 <crazy> that ksaneplugin is probably now libksane
16:00:49 <bero> I'd guess so too
16:01:43 <bero> qastools has a newer version that has moved to qt5, so one more thing off the list
16:02:09 <crazy> bero: https://github.com/pvanek/qlipper/blob/master/CMakeLists.txt#L58 <-- this has qt5 version
16:04:59 <crazy> cagibi gone but there is zerofonf-ioslave
16:05:04 <crazy> *conf
16:06:25 <crazy> bero: kommander -> krusader I guess
16:07:26 <bero> probably
16:08:34 <crazy> bero: http://xwmw.org/qastools/ <-- Qt5 since 0.20.0
16:08:43 <bero> dssi doesn't exist with qt5 yet, but hasn't seen an update since 2011, probably it's obsolete anyway
16:09:12 <bero> crazy: I've already pushed the qastools 0.21.0 update while we were looking at the list ;)
16:09:43 <crazy> :D
16:11:27 <crazy> no idea about these rose-* stuff but rest should have an replacement or gone bc never plasma has these in core libs/kf5
16:11:33 <crazy> *rosa*
16:12:20 <bero> agreed, and rosa is still actively maintained, so they should have updates for remaining bits and pieces too
16:15:54 <crazy> bero: there is just one the devels kind refuses to port .. unetbootin .. see https://github.com/unetbootin/unetbootin/issues/53 ( I've didn't yet dropped it but is here *nobuild* ) .. I planned to replace with this sometimes : http://multibootusb.org/page_features/
16:19:17 <bero> certainly looks like a possible replacement
16:19:21 <bero> I presume that is on qt5?
16:46:41 <itchka> Hmm it uses syslinux
16:48:38 <itchka> Last release 2014
16:48:55 <ben79> we're getting rid of systemd anyway right?
16:49:47 <itchka> Dunno where you got that from ben79..
16:50:33 <itchka> Anyways time to move on.
16:50:55 <ben79> just common sense
16:52:52 <bero> Would be fun to get rid of systemd, but that would require either writing something equivalent and compatible or patching all sorts of things to get by without it
16:57:00 <itchka> #item 2
16:57:28 <itchka> #topic  Lx4 Release Plan. Initial discussions
16:58:25 <bero> We should try to get it out as quickly as possible...
16:59:06 <bero> I'd say we can prepare to go into soft feature freeze once the rebuild is complete and KDE has been brought up to date
16:59:17 <itchka> What is a realistic timescale to have cooker working?
17:00:15 <bero> Let's not talk about timescales yet -- we need to see how the mass build goes
17:00:31 <bero> I could imagine thousands of packages needing adjustments with a new BuildRequires: somewhere or so
17:01:01 <bero> Before we know how that goes, I think it makes more sense to decide what we want to do before the release instead of trying to fit a timeline
17:01:12 <itchka> Ok lets talk about the ARM releases
17:01:32 <itchka> Do we have a helpful way to package these?
17:02:08 <bero> This is currently still a little tricky because every device needs a different kernel, uses a different bootloader etc.
17:03:00 <bero> So probably we can deliver a generic rootfs tarball that people need to integrate with their board and the corresponding kernel manually
17:03:18 <bero> And we can provide special images for boards we care about and want to support
17:03:49 <bero> The higher-end aarch64 server boxes actually use UEFI, so we can essentially use the same iso builders we use for x86_64 there
17:04:00 <bero> but sadly that hardware is still quite rare
17:04:30 <itchka> Why don't we make a thing of the Macchiato?
17:05:51 <itchka> In fact perhaps target the UEFI boards.
17:06:21 <bero> That's definitely one of the boards I'd like to support, given I have 4 of them
17:06:44 <bero> it would also make sense to target the Raspberry Pi given how many of them are out there
17:06:50 <itchka> UEFI could handle selecting the right kernel for booting.
17:06:52 <bero> and the Dragonboard 820c simply because it's good
17:07:02 <ben79> Caffè macchiato?
17:07:38 <bero> ben79: http://macchiatobin.net/product/macchiatobin-double-shot/
17:07:48 <itchka> I honestly think that would make more sense than having a vagues tarball.
17:08:36 <bero> This one may be interesting to support as well given it is rather cheap for the power https://shop.t-firefly.com/goods.php?id=45
17:09:11 <bero> We probably need to release that tarball as well, given there's just too many boards out there
17:10:31 <itchka> I like that firefly :)
17:12:15 <itchka> All that power and only 2 amp draw...
17:13:28 <ben79> so these various boards what do people actually do with them? Servers? Build their own desktop or laptop?
17:15:16 <ben79> or platform for dedicated computer like those we have on printing presses where it needs to function like a touchscreen desktop but function is limited to controlling and monitoring various systems on a printing press?
17:16:04 <ben79> I'm sure these type of computers are common in manufactoring of all kinds
17:16:07 <ben79> now a days
17:18:41 <ben79> OR will some day desktops and laptops be built with ARM or aarch64 arch?
17:23:11 <itchka> ben79: The ARM stuff will really score in the server world first. Performance versus power consumption gives it an edge in the datacentre where cooling is a big overhead for the x86 architecture.
17:23:41 <bero> ben79: Good question... Most people right now use them for special purposes (e.g. home automation seems to be a common use case), some use them in servers, and they're certainly powerful enough to make decent desktops and laptops these days
17:23:53 <bero> but not many people have been building such devices
17:24:29 <bero> I've actually been trying to change that, I can quickly turn a macchiatobin into a nice desktop box...
17:24:48 <ben79> OK, lower power comsumption plus less heat for given level of performance, that matters
17:25:04 <bero> one problem is usually graphics, most ARM boards have an embedded Mali GPU that doesn't come with open drivers
17:25:25 <bero> but some boards actually have decent GPUs (Adreno or Vivante) or no GPU and a PCI slot
17:26:50 <ben79> I guess I'm wondering why we don't see major manufactors building desktops and laptops with the new arch's yet?
17:27:45 <bero> Comes down to one thing: Microsoft
17:27:58 <ben79> I can see that for servers they may be better right now, and speciality applications like home automation
17:28:05 <bero> Manufacturers are convinced that nobody will buy a computer that doesn't have Windows 10 x86 on it
17:28:23 <bero> And Microsoft pays them to maintain that view
17:28:24 <ben79> OK
17:32:14 <ben79> OK, I got the gist of how they are used currently and that they probably will be employed more widely in the future
17:34:06 <itchka> bero: Have you seen a firefly in the flesh? On the web page the board doesn't look much bigger than a hard drive but there's no cluse whether it's a laptop drive a a full size one.
17:34:51 <ben79> the suprise would be if they aren't more widely used in the future, but I have my question answered.
17:41:08 <bero> itchka: I have one here (just didn't get to put anything useful on it yet). It's about the size of a 3.5" desktop harddisk
17:41:48 <itchka> So it would go in the pi-top themn?
17:42:05 <Pharaoh_Atem> modern systems are building aarch64
17:42:22 <ben79> Ahhh... The difference ARM vs. x86 seems basically RISC vs. CISC
17:42:34 <Pharaoh_Atem> though most SBCs are funky, the Fedora and SUSE guys developed uboot to UEFI, so most of the pain is resolved from an integration point of view
17:42:36 <bero> itchka: should fit better than the OpenQ820, but I don't think it'll fit in the normal board slot
17:42:45 <bero> itchka: and of course the Mali GPU is highly problematic
17:43:18 <ben79> so is aarch64 basically 64 bit ARM?
17:43:25 <itchka> bero: It has Mali blast it!
17:43:25 <bero> ben79: yes
17:44:22 <bero> mali will probably become usable at some point
17:44:23 <bero> https://rosenzweig.io/blog/a-moving-mesa-midgard-cube.html
17:44:26 <bero> but right now it isn't there
17:46:53 * ben79 Interesting history: https://en.wikipedia.org/wiki/Acorn_Archimedes
17:47:13 <bero> yes, that was a really nice computer for its time
17:48:09 <bero> the next CPU architecture that I think will become interesting is https://en.wikipedia.org/wiki/RISC-V
17:48:48 <bero> first board is available in prototypes now https://www.crowdsupply.com/sifive/hifive-unleashed
17:49:07 <bero> Probably it won't be ready in time for the 4.0 release
17:49:15 <bero> but I hope with 5.0 we can support RISC-V as well
17:51:17 <ben79> Well heck fire, if we're going to support ARM and aarch64 in LX 4 then we will be wanting a server installer or server installer option on regular ISO's won't we?
17:51:31 <bero> certainly would be nice to have
17:52:02 <ben79> I know, easy for me to say or dream, but I'm not a coder
17:53:40 <itchka> We have a text installer ben79 _TPG poimted to it in the forums. I have already done some work on it.
17:54:03 <ben79> actually a server installer or option would be for x86 stuff anyway right? ARM and aarch64 will need to be generic tar ball and support for a few specific boards
17:54:29 <ben79> where is text installer?
17:54:44 <ben79> we can't even build Lx 3 ISO's at the moment
17:54:45 <bero> mostly, yes -- but we can do whatever we want for the boards we decide to support
17:56:18 <itchka> bero: Surely UEFI would allow us to select a kernel to boot dependant on hardware...
17:56:51 <bero> yes -- the problem is primarily with boards that don't support UEFI (and that don't necessarily use uboot either)
17:57:04 <Pharaoh_Atem> bero: are there that many boards that don't support either?
17:57:19 <Pharaoh_Atem> I don't know of any today that don't at least do uboot
17:58:01 <ben79> anyway I'm not finding a test installer yet
17:58:05 <bero> Pharaoh_Atem: Quite a few boards use a custom bootloader -- e.g. most Qualcomm based boards use a bootloader that is based on LK
18:02:12 <crazy> bero: sry phone and stuff here .. yes multibootusb is pyqt5
18:03:13 <Pharaoh_Atem> bero: as in the Linux kernel?
18:03:22 <Pharaoh_Atem> or on something actually called LK?
18:03:33 <crazy> bero: and kind does same just different .. you can install more distros into one USB stick or just one or just a iso image and uninstall without to wipe the whole USB stick
18:03:58 <bero> Pharaoh_Atem: No, LK as in https://github.com/littlekernel/lk
18:05:07 <bero> crazy: some boot loaders are funny though -- there's bootloaders that only boot a kernel at a specific byte offset of an SD card etc.
18:05:48 <bero> and of course there's boards that strictly enforce Android-style partitioning
18:06:17 <crazy> bero: well yes
18:06:42 <itchka> Android partitioning is the most nonsensical thing I have ever seen!
18:08:07 <crazy> well is Google folks logic
18:08:36 <crazy> bero: OT .. you guys are using dracut too right ?
18:09:17 <bero> yes
18:09:31 <crazy> bero: may I PM you ?:)
18:09:36 <bero> sure
18:09:57 * bero is always surprised google works at all given how bad a lot of their code is
18:10:55 <ben79> So for ARM and aarch64 on Lx 4 are we a maybe or a definitely going to be able to support?
18:11:32 <ben79> Or undecided
18:14:17 <bero> I'd say aarch64 definitely...
18:14:40 <bero> 32-bit ARM, probably, if anyone still cares at the time
18:14:47 <bero> the architecture is disappearing already
18:15:13 <ben79> OK,
18:16:39 <itchka> Ok time is slipping away. Lets move on
18:16:49 <itchka> #item 3
18:16:59 <itchka> #topic AIB
18:17:16 <itchka> Ok ben79 do you have any bugs for us?
18:17:26 <ben79> New bug:
18:17:26 <ben79> new gfortran is breaking lots of libraries >>> https://issues.openmandriva.org/show_bug.cgi?id=2243
18:17:40 <ben79> Leftover from last week but not Resolved:
18:17:40 <ben79> cannot install python-tables due to dependency issues >>> https://issues.openmandriva.org/show_bug.cgi?id=2337
18:17:40 <ben79> blender produces a segmentation fault (core dumped) when started >>> https://issues.openmandriva.org/show_bug.cgi?id=2341
18:18:52 <itchka> Hmm I thought angrypenguin managed to build the new blender does it still not work?
18:19:50 <ben79> I don't know, it is not my bug, all I know is no activity in bug report
18:21:12 <itchka> Hmm lets check it out. I have to confess I've been out of the loop this last week with family and garden demanding my time.
18:21:29 <ben79> One of the things that is needed is for developers to get directly involved with bug reports and not using me as a middle man, it just does not work well
18:21:58 <itchka> I'm just updating at the moment but then I'll pull it.
18:22:38 * ben79 And OT but also I need for users on forum with more difficult issues to come here and talk directly with developers and not use me as middle man for same reasons
18:23:01 * ben79 just part of my own learning process
18:24:12 <bero> I don't have any 3.x boxes to check with
18:24:18 <bero> running cooker everywhere
18:25:26 <bero> and of course so busy getting stuff ready to at least pass the mass build that I have little time to check even if bugs are resolved in cooker
18:26:32 <ben79> about blender the only package is in main-release not blender in updates or testing so any new package isn't available yet to test
18:27:16 <itchka> Ok angrypenguin must have built in his own repo. I'll check it out
18:28:43 <ben79> Well anyway there is still a need for developer support at issues.openmandriva.org for Lx 3, but I recognize that the focus is mostly (almost exclusively) on Lx4/Cooker
18:28:53 <ben79> here
18:29:32 <ben79> and it is likely I don't anywhere near all that TPG or crisb do regarding bugs
18:30:02 <ben79> only see what is actually published in bug reports
18:30:53 <ben79> >>> and it is likely I don't <see> anywhere near all that TPG or crisb do regarding bugs
18:32:00 <ben79> Oh, didn't mean to leave out itchka regarding Lx 3 bugs, itchka does a lot
18:33:44 <itchka> It's a difficult time at the moment with cooker needing all this work. Perhaps we should have a moratorium on updating 3.0 except if there are security issues  or updates that actually fix filed bugs.
18:33:54 <ben79> anyway the above is this weeks AIB, would be nice if 2337 and 2341 would get resolved soonish if possible
18:34:48 <itchka> I have had Blackcrack complaing about lack of support for php and own cloud. What can I do if he doesn't provide any logs...
18:35:44 <crazy> itchka: some php modules still need an rebuild ( if he talks about the old bug(s) about php )
18:36:02 <itchka> Ok ben79: I'll try for blender tonight.
18:36:35 <crazy> some stuff pulled in by webmin ( if I remember correctly ) and some other ones I think from contrib
18:36:35 <itchka> crazy: If that's all that's needed I'll bump and rebuild them.
18:36:39 <ben79> itchka: my opinion is that if users don't provide logs or other request information we can't solve their bugs, we can mark them NEEDINFO and leave them or close them after a month or 2, again my opinion
18:37:20 <itchka> I agree.. I left the ball in his court.
18:37:22 <crazy> itchka: yes they seem to be last rebuild against very old php .. so PHP API does not match and some weird errors popping up
18:38:02 <itchka> Ok I'll give it a try.
18:38:15 <ben79> itchka: about blender AngryPen may have a package in personal repo
18:38:41 <ben79> itchka: issue may be resolved and no one knows...
18:39:21 <itchka> His changes should show up in his branch of git.
18:39:48 <itchka> Ok lets move on as I am getting hungry!.
18:39:55 <ben79> Yeah
18:40:04 <itchka> #item 4
18:40:15 <itchka> #topic AOB
18:41:05 <itchka> I'll leave this open until 45 mins past the hour and if no topics I'll close the meeting.
18:41:07 <ben79> I have a question, can we get ISO builder to work again so we can build Lx 3 ISO's, our testers miss the weekly ISO builds HisShadow was providing
18:42:53 <ben79> Oh, another question, in OM Lx 3 my desktop runs measurably hotter (sensors) by 5-20 degrees C than it does in openSUSE or Manjaro, any guidence on trouble shooting that would be appreciated
18:43:58 <itchka> ben79:That may be possible I have made the necessary changes to omdv-build-iso for it to build with dnf though I haven't tested it yet. If fedyas scripts update the dnf metadata on 3.0 then it should be possible to build iso's again. I will look at it over the next few days.
18:44:11 <ben79> On my notebooks the issue is not so clear it is more of a maybe they run hotter so hardware may be part of the issue.
18:44:52 <ben79> OK, recently bero did a test build and also in recent build logs for weekly builds it is trying to use Cooker repos
18:45:01 <itchka> I am away on holiday next week so I am unable to chair the meeting. I hope someone will pick up the job abd chair it.
18:46:35 <itchka> ben79: Hmm that is interesting as it should use the repos according to the commandline switches. I'll have a look at the logs.
18:47:26 <ben79> to chair meeting, what does I need to know, do I need any authorization?
18:47:39 <ben79> say for instance if bero does not want to
18:48:44 <itchka> I don't think so Ben I think #startmeeting should be enough
18:49:01 <ben79> OK
18:49:48 <itchka> I'll tray and follow on my phone but I will be on a canal boat so could be in the middle of nowehere with no reception.
18:50:05 <ben79> OK, https://wiki.openmandriva.org/en/Chwido
18:50:48 <ben79> Wait I need a password to do that it looks like:
18:50:52 <ben79> First identify to the bot:
18:50:52 <ben79> chat in private with Chwido and send
18:50:52 <ben79> identify <username> <password>
18:51:24 <itchka> Well lets end this meeting and we can test it,
18:51:48 <ben79> OK
18:51:55 <itchka> #chair ben79
18:51:55 <chwido> Current chairs: ben79 itchka
18:52:16 <ben79> #endmeeting