16:12:57 <itchka> #startmeeting
16:12:57 <chwido> Woof! Let's start the meeting. It's Wed Dec 19 16:12:57 2018 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:12:57 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:12:57 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:12:57 <chwido> Have a good meeting, don't bark too much!
16:13:05 <itchka> #item 1
16:13:22 <itchka> #topic Report: ABF cooker dnf; How can we fix outages
16:13:41 <itchka> bero?
16:14:08 <bero> Let's start with abf and what we're already doing to fix outages...
16:14:37 <bero> The reason for the abf breakage last week was the box not coming back up after a power outage (with nobody around to fix it)
16:15:06 <bero> There's a broken HDD in the box, so it was stuck in the BIOS saying "Disk failure, press F1 to continue"
16:16:16 <bero> I've ordered a PCI card that can essentially fake a screen and input devices over the net, so once that thing arrives, we can remote control the bios
16:16:41 <bero> but of course there's still problems if I'm traveling and a part of the hardware we're actually using breaks down
16:16:58 <HisShadow_> bero: just jam F1
16:17:17 <bero> So for now I've set up an hourly sync from abf to c64 (not even in the same location, so a nuclear bomb hitting one location won't destroy the other box)
16:17:28 <bero> c64 isn't on the fastest connection in the world, but better than nothing
16:17:54 <bero> we can make it take over if this happens again and switch back to the faster connection when the other box is back up
16:18:37 <bero> fdrt: I still need to figure out how to start the spare abf when we need it though -- for now I'm rsync-ing everything that's in /var/lib/openmandriva to c64, is that enough or do we need to sync anything else?
16:19:10 <HisShadow_> bero: hmm, what about starting another abf with postgres master-master replication?
16:19:25 <HisShadow_> and an nginx to balance the load between 2
16:20:09 <crazy> HisShadow_: do you know how file-store webUI is working ?
16:20:34 <itchka> Would that generate lots of extra traffic?
16:20:46 <crazy> HisShadow_: we need fix some things there and in nginx configs
16:20:50 <bero> HisShadow_: That would be great, I'm a bit concerned they may disturb each other with file stores being out of sync or something, do you know if there's some functionality to make sure they remain in sync?
16:21:23 <bero> also do you know if abf's locking is good enough to handle 2 instances trying to write to the db at the same time?
16:21:35 <bero> I'm not familiar with the code base at all...
16:21:44 <HisShadow_> crazy: by webUI you mean the actual interface or nginx behind it?
16:22:32 <crazy> HisShadow_: both .. I figured what sucks @nginx but since the WebUI can set HEADERS and CACHE and what not too I need to know what it does
16:22:33 <HisShadow_> bero: we keep same filestore, just 2 abfs, need to think about it though
16:22:47 <crazy> HisShadow_: file-sore downloads working by luck
16:23:08 <crazy> HisShadow_: can be corrupted at any time ( silent corrupted )
16:23:48 <crazy> HisShadow_: that bc the way nginx handling some stuff from upstream server
16:24:52 <bero> HisShadow_: same file-store wouldn't fix the problem with the box (or the connection to the location) going down and nobody being there to fix it -- we need file-store duplicated as well
16:27:19 <HisShadow_> crazy: Cache-Control: max-age=0, private, must-revalidate this is the only header I get when trying to upload as far as I can see, others are standard
16:27:58 <crazy> HisShadow_: not only problem being the defaults
16:28:22 <crazy> [16:25:26] <crazy> fdrt: basically Transfer-Encoding: chunked and proxy_buffering on and !X-Accel-Buffering off ( in front/back end ) @upstream proxyed servers is somewhat bad situation
16:28:25 <crazy> @ HisShadow_
16:28:30 <crazy> see docs about
16:28:43 <crazy> that is such crap how nginx handle that
16:29:19 <ashledombos[m]> hi
16:29:32 <crazy> HisShadow_: also even wrong HTTP 1.0 by default ..
16:29:43 <itchka> ashledombos[m]: Hi
16:30:09 <bero> HisShadow_: problem is also at download time (can't resume downloads or even detect a download failed because file size isn't sent etc.) -- while it tends to work, this has caused a few random build failures before (incomplete download of a source package)
16:30:31 <bero> no big deal because just trying again will fix it, but it would still be good to fix (and probably isn't all that complicated)
16:30:33 <bero> hi ashledombos[m]
16:31:55 <crazy> but ingoring that this configurations does this : client request file , nginx hides the HEADERS the clinet need to know and trust upstream proxy , now if server decides to stop in the middle of the download , clinet thinks 'yay I'm done all fine' while the file is corrupted
16:33:09 <crazy> HisShadow_: try to download .. use wget -d on some file ... use wget -c -d some_file , stop the download , re-try etc
16:33:27 <crazy> you'll notice quick what is wrong
16:33:29 <crazy> :)
16:34:40 <crazy> I know X-Accel-Buffering can be manipulated from WebUI's code too however I have zero clue about abf and or file-store UI code
16:35:34 <crazy> there are some solution this can be fixed but for that one need to understand the bing picture on how that all is working together .. which I do not 100% understand now :D
16:37:19 <HisShadow_> okay, I need to look into it myself
16:37:29 <HisShadow_> I haven't done anything with fstore really
16:37:48 <crazy> Content-Length header sent by the client and replace it with chunked
16:37:48 <crazy> > encoding - /incorrect chunked encoding/, that will make the client believe
16:37:48 <crazy> > it has the full entity, even though it has only a part of this.
16:37:48 <crazy> 
16:37:48 <crazy> Yes, this is a known problem. Upstream module expects backend to
16:37:49 <crazy> behave properly, and if it misbehaves (or, more importantly,
16:37:50 <crazy> connection is broken for some reason) bad things may happen.
16:38:02 <crazy> is what @devels tells
16:38:33 <crazy> HisShadow_: ok thx
16:51:34 <itchka> Ok so where do we go with the abf "mirror"
16:52:29 <itchka> keeping two filestores in sync seems a difficult task to me.
16:53:32 <bero> itchka: currently  keeping them in sync by rsync-ing everything over once an hour, so at worst we'll lose 1 hour of changes
16:54:35 <itchka> bero: But how will the database deal with the lack of concurrency?
16:58:43 <bero> I don't know how the db works in detail -- but I'd hope that a missing file that is shown in the db would be fixable by just storing it again
17:02:08 <HisShadow_> yeah, if the file is missing on the disk by in the db you can just place it in the correct spot
17:04:57 <itchka> I obviously don't know how this all works I would have thouight that once one file has been stored by the container the container data is destroyed. but no matter I'll take your word for it :)
17:05:28 <HisShadow_> hm? what containers are you talking about?
17:06:17 <itchka> The container that builds the file to be stored. I assume that the repos are also mapped to the files store.
17:06:50 <itchka> or are you just talking about the sources?
17:10:51 <itchka> but no matter we need to move on.
17:11:24 <itchka> We will revisit this.
17:11:51 <itchka> Lets move on to the release discussion.
17:11:56 <itchka> #item 2
17:12:21 <itchka> #topic Lx4 Release Plan. Where are we.
17:12:55 <itchka> I've divided this topic up into headings so we can deal with specific issues.
17:13:54 <itchka> The first is the amount of time we should spend testing the alpha bearing in mind that some fairly major changes will be made as soon at it's released.
17:15:32 <itchka> My personal feeling about this is that testing should be restricted to boot, installation and graphics/ hardware issues. Any comments?
17:16:56 <ben79> Or make the fairly major changes and release that as the Alpha
17:18:03 <ben79> That would make much more sense to me
17:18:27 <rugyada> itchka: +1
17:18:43 <rugyada> ben79: that could be alpha2
17:19:28 <ben79> What are the fairly major changes we are talking about??
17:20:40 <itchka> Pretyy much the entirity of KDE and and it's supporting Qt libraries and the the entire libre-office suite.
17:21:18 <ben79> That's all? What could go wrong?
17:21:54 <itchka> :)
17:22:17 <ben79> So, yeah OK, we are it seems talking about releasing what we have now as Alpha 1 and then the real package list would go in Alpha 2
17:22:46 <ben79> So I get it and that seems OK
17:23:53 <itchka> If it's reasonably good after the updates we could even call it beta...
17:24:29 <ben79> With us package freezes don't really seem to mean much we usually keep changing things for ever
17:25:21 <ben79> well not forever but until final release
17:26:36 <itchka> This time all the changes are pretty near ready so if we get all fundamental stuff like booting, install and graphics hardware sorted we will have time to concentrate on the applications.
17:26:59 <rugyada> https://wiki.openmandriva.org/en/OpenMandriva_Release_QA#Checklist
17:27:32 <rugyada> guess these guidelines are ok for 1st alpha
17:27:54 <rugyada> (or alpha in general)
17:29:29 <rugyada> ‎[18:15] ‎<‎itchka‎> [...] boot, installation and graphics/ hardware issues
17:29:58 <itchka> Yes they look pretty good.
17:30:46 <itchka> I think the only thing it doesn't mention is booting in VB.
17:31:11 <rugyada> itchka: if anything is missed I can add it
17:32:13 <rugyada> aside, see also : https://wiki.openmandriva.org/en/Software_release_life_cycle#Alpha
17:32:50 <ben79> https://wiki.openmandriva.org/en is mega slow here
17:32:58 <rugyada> yep
17:33:10 <rugyada> we already aware ben79 :/
17:33:25 <rugyada> hope is to fix it asap
17:33:44 <rugyada> sorry for the inconvenience :)
17:34:12 <ben79> Oh, it isn't much of an inconvenience actually
17:35:00 <ben79> Anyway so we are talking about releasing what we have right now as Alpha One, meaning ISO 2348 or another new ISO?
17:36:09 <rugyada> bero's say requested here
17:36:15 <itchka> bero ?
17:36:30 <ben79> So the original question was how long to test it? A week should be plenty enough for that list.
17:37:00 <bero> sorry, had to take the dogs outside, reading back
17:37:15 <ben79> So it may depend more on when the new stuff is ready for Alpha Two
17:37:47 <rugyada> ben79:  basically 2348 is very similar to 2342 which we were testing during the latest times
17:38:03 <ben79> yes I don't see much difference yet
17:38:16 <rugyada> someone reporting some delay in boot
17:38:28 <rugyada> in hw, not in vb afaics
17:38:45 <bero> I agree with what has already been said...
17:38:48 <rugyada> for me a bit of delay in live mode
17:38:54 <bero> Let's not give too much time to alpha1...
17:39:00 <ben79> As far as that checklist I'm almost done,
17:39:02 <rugyada> but once installed no more.
17:39:07 <bero> Plenty of changes already ready to go and they really make things better
17:39:08 <itchka> ben79: Once we release the alpha I assume the repos will split so the updates could then go into cooker and it's possible to to test them without unfreezing 4.0 until things at least have been reviewed.
17:39:54 <bero> I'd rather make the split a bit later so we don't have to literally push hundreds of packages around immediately
17:41:14 <ben79> So we're talking release of ISO 2348 as alpha one and in 3-7 days we'd release an alpha two with a lot of new packages?
17:42:16 <ben79> #action #share
17:43:49 <itchka> I don't feel that releasing an alpha and then dumping hundreds of packages into is such a good idea we could end up with real problems when people only get half the updates 'cus they started pulling them too early.
17:46:01 <itchka> Better to give some days to debug the basic issues on the current iso's and then when the fundamentals are ok push the updates and release the alpha. I was assuming we would split when the alpha was released.
17:47:01 <itchka> Let's try and keep it smooth and trouble free for those who may help us test the pre-releases.
17:47:57 <rugyada> if we don't release we wont have any feedback..
17:48:18 <ben79> I don't understand what is different about what you are saying. We release a Alpha One and test basic functions and then add a bunch of packages in a new ISO right?
17:48:52 <ben79> The new ISO being Alpha 2 which will look more like final release
17:50:38 <rugyada> from my side I push to release what we have now as alpha1
17:50:47 <itchka> I would just call it the Alpha we can informally test teh current cooker isos unless you feel we should have a label to encourage users to test.
17:51:34 <rugyada> we need wider testing
17:52:10 <rugyada> not just you me 2/3 others..
17:54:20 <itchka> If we do that because the repos won't be split we will be in the situation where loads of packages will be dumped into alpha1 along with the all the potential problems that can cause.
17:55:58 <ben79> Oh, we really need to release something for users to test, and as soon as possible,
17:56:40 <rugyada> ‎[18:43] ‎<‎itchka‎>‎ I don't feel that releasing an alpha and then dumping hundreds of packages into is such a good idea
17:56:41 <rugyada> 1) alpha is alpha (development release, not final release)
17:56:42 <rugyada> 2) alpha2 testing and release will replace alpha1
17:57:25 <rugyada> tester dont have to update alpha1, rather to re-install and test alpha2
17:57:41 <rugyada> so goes for beta etc
17:57:44 <rugyada> imho.
17:58:19 <ben79> I don't recall us splitting repos this early in the past, I was expecting repos split to happen around beta one
17:58:26 <rugyada> never
17:58:57 <rugyada> I assumed repos splitted once cooker to become relesa
17:59:10 <rugyada> final release*
17:59:23 <ben79> and adding packages to alpha 1 isn't any different that adding a long list of packages to Lx 3
17:59:47 <itchka> Perhaps that's why we always get in such a mess with testing times getting shorted and shorter as we approach the final.
18:00:24 <rugyada> itchka:  no, it's bc we did not follow release cycle
18:00:47 <rugyada> as in public release a/b/rc ect
18:00:59 <ben79> I think we get in trouble in the past because we never actually do a package freeze, we keep adding new stuff until final release, and I fully expect that to happen with Lx 4
18:01:16 <rugyada> ben79:  yes
18:01:40 <ben79> How many times do we see "Foo X.X just got released and gee whiz we really should get that in" ?
18:01:46 <rugyada> ben79: yes, right. and no, that's wont have to happen :)
18:02:02 <ben79> I don't like it but I don't exxpect it to change either
18:02:54 <itchka> rugyada: No because we can't because all the time the repos are not split a freeze in cooker is unattainable;  we know that it just doesn't happen and we end up chasing our tails.
18:04:10 <ben79> We will keep adding new stuff after repos are split, we always do
18:04:22 <rugyada> itchka: I dont understand what you are saying..
18:05:05 <rugyada> and tbh I think bero would be more proper person to discuss it with you.
18:05:50 <ben79> I think I understand what itchka is saying I just don't believe we will do it
18:05:51 <rugyada> bero:  help :)
18:06:12 <bero> IMO we should split at beta or rc time
18:06:29 <bero> and start being careful with updates as soon as the post-alpha set of things is in
18:06:40 <itchka> What I am saying is that if there is to be any control at all about what updates are applied during the release process we will have to split the repos so that QA can moderate the flow of new packages into the distro and so that our efforts at testing are not continuously negated.
18:07:17 <bero> Agreed in general, but we don't have the manpower to give real testing to the hundreds of packages that are about to roll in...
18:07:29 <bero> and IMO someone installing something marked "alpha" knows that it may get broken
18:07:36 <bero> so we don't need too rigid QA until we reach beta
18:08:00 <bero> also, I'm already running all the stuff that needs to be pushed after the alpha release
18:08:09 <bero> I know even the in-between system works fairly well
18:09:07 <itchka> How long will it take to push it all now bero?
18:09:43 <bero> I was pretty surprised that e.g. falkon simply kept working with qt 5.12 + qtwebengine 5.11
18:09:44 <bero> hard to tell given we don't know if abf will have hickups or so
18:09:46 <bero> but it shouldn't take too long
18:09:54 <rugyada> just consider that we do have an alpha1 ready to go...
18:09:58 <bero> Probably we can have alpha2 after the weekend or so
18:10:45 <bero> of course we could consider just delaying the alpha and not officially releasing what we have right now
18:11:03 <itchka> I think we may as well wait until the stuff is built
18:11:03 <bero> but I think we should go ahead with the plan of releasing the current isos and then following up quickly
18:11:12 <bero> 2 releases ==> 2x the attention
18:11:22 <rugyada> bero: +1
18:11:38 <rugyada> that's all.
18:11:56 <bero> and we need some testing of the core system regardless of what's running on top
18:12:19 <bero> IMO we should push out this alpha ASAP if only to show the world that we're still alive
18:12:26 <bero> all our stuff got rejected for FOSDEM...
18:12:42 <bero> Probably because we're already being considered dead for not having had an interesting release for > 2 years
18:13:11 <itchka> No doubt
18:13:25 <rugyada> someone just missing some points far from him..
18:13:41 <rugyada> yet very important too..
18:13:53 <itchka> bero: Can you do the updates like a mass build so that you can release them all at onece?
18:13:58 <itchka> once
18:14:52 <bero> not without a lot of extra load (building stuff manually in containers because all the packages depend on each other)
18:15:20 <bero> and there's not much of a point in doing so because I know the in-between system keeps working (at least mostly)
18:16:34 <itchka> could you jet them into cooker_testing repo?
18:16:59 <itchka> Just a thought
18:17:47 <bero> There is no cooker_testing repo...
18:18:14 <bero> We could create one, but then moving stuff from there to regular cooker would probably be as painful as moving them from cooker to a branched 4.0
18:18:25 <bero> but probably in the longer run that's where we want to go
18:18:40 <bero> (so people can use cooker as a rolling release without all the trouble)
18:18:46 <ben79> http://abf-downloads.openmandriva.org/cooker/repository/x86_64/main/testing/
18:18:55 <ben79> It is there already
18:19:04 <ben79> but it probably should not be there
18:19:24 <ben79> all the repos have a testing for that matter
18:19:55 <rugyada> "Alpha software can be unstable and could cause crashes or data loss. Alpha software may not contain all of the features that are planned for the final version."
18:19:56 <ben79> all the Cooker repos have a testing for that matter
18:20:46 <bero> let me throw something at cooker_testing to see if it actually works... We've never used it before and there's a good chance nothing is set up for it
18:20:58 <ben79> And who put those packages in Cooker main/testing anyway?
18:21:12 <rugyada> cooker is by definition a testing environment
18:21:19 <itchka> perl-mail-sender?
18:21:41 <rugyada> so we want to have a /testing repo for a testing environment :P
18:21:49 <rugyada> funny
18:22:27 <itchka> rugyada:  It's more like a holding area to allow all packages to be built before releasing.
18:22:50 <rugyada> uhmm
18:24:10 * rugyada wonders who will test the testing packages in testing repo for cooker testing environment
18:24:49 <bero> I've thrown boost and qt at cooker/testing so we can see if it works at all...
18:24:52 <ben79> when we don't have enough time or people to test packages for Lx 3...
18:25:10 <bero> can't hurt to know if it's even an option
18:25:35 <itchka> Ok lets see how we go.
18:25:40 <rugyada> bero: sure, but we all know how it will end :)
18:26:13 <itchka> I have to lead some Carol singing tonight and will have to go soon are you all right to take ove the chair bero?
18:26:26 <bero> sure
18:27:35 <bero> http://file-store.openmandriva.org/api/v1/file_stores/c97d9b93fab6584e36c41377fc1d729b2d4cd21b.log?show=true
18:27:36 <itchka> Ok Thanks. There's one thing I'd like to suggest before I go and that is release issue handling.
18:27:50 <bero> looks like a builder is broken, let's see if it's caused by cooker/testing or something else
18:28:37 <ben79> release issue handling
18:28:50 <itchka> I would like to suggest that we experiment using git hub for the bug reporting side of the release process. It will have the advantage of keeping all the release bugs in one place. What do you think?
18:29:03 <rugyada> well, so now that we finally made itchka happy with his testing repo can we agree on releasing alpha1 asap?
18:29:46 <ben79> not until we exhaust all possible reasons not to release...
18:29:59 <rugyada> ben79:  +1000000000
18:30:23 <rugyada> let's give him yet another chance
18:30:37 <itchka> bero: Is that an unexpanded macro?
18:30:38 <rugyada> what's next ?
18:31:03 <ben79> I'm fine with using github for bugs for Lx 4, but if we do it guarantee's that we will switch to it
18:31:23 <bero> rugyada: +1000, we should release a few weeks ago ;)
18:31:31 <itchka> rugyada: I'm simply trying to reduce the waste of testing time as well as the frustation that causes.
18:31:48 <bero> itchka: no, it's a random recurring builder failure
18:32:27 <AngryPenguin> hi
18:32:51 <itchka> Release and be dammned; I have to go.
18:32:53 <itchka> :)
18:33:00 <AngryPenguin> someone currently at cooker?
18:33:01 <rugyada> bye itchka
18:33:07 <itchka> #chair  bero
18:33:07 <chwido> Current chairs: bero itchka
18:33:13 <itchka> bye
18:33:13 <rugyada> good singing
18:33:15 <bero> bye itchka
18:33:20 <ben79> bye itchka
18:33:21 <bero> AngryPenguin: sure
18:33:35 <bero> So I guess:
18:33:36 <ben79> When Lx 3.0 was being developed QA completely lost control of what was happening so I understand that part, I'm just not sure how to avoid it again
18:33:43 <bero> #action Release 4.0 alpha as soon as possible
18:33:46 <AngryPenguin> bero: can you test it? https://abf.openmandriva.org/build_lists/347026
18:33:49 <bero> #share 4.0 alpha release imminent
18:34:11 <rugyada> @all developers:
18:34:13 <rugyada> we'll need your valued inputs for alpha1 release announcement
18:34:14 <rugyada> as usual, but more than usual I'd say bc this is the 1st alpha of a new main release
18:34:16 <rugyada> we know that a lot of changes happened since Lx3 so it's good to summarize them for the followers
18:34:17 <rugyada> and more important to reveal to newcomers.
18:35:03 <rugyada> that's from my PR side
18:35:13 <bero> AngryPenguin: looks like it works
18:35:35 <ben79> So exactly what are we going to release as alpha one? The current ISO 2348?
18:35:36 <AngryPenguin> bero: do u want it in cooker? :)
18:35:51 <rugyada> ben79: I think so
18:36:12 <bero> AngryPenguin: sure, looks really good...
18:36:34 <bero> rugyada: Agreed re PR... Do you have a link to the wiki page or whatever it was where we're collecting inputs?
18:36:45 <ben79> Well it boots, installs, and works on my desktop so it has to work everywhere else right?
18:37:10 <rugyada> bero:  the 4.0 wiki pages
18:37:11 <bero> I think 2348 and 2349...
18:37:11 <rugyada> https://wiki.openmandriva.org/en/4.0/Alpha/Release_Notes
18:37:23 <AngryPenguin> bero: then in free time import it https://github.com/OpenMandrivaAssociation/stacer
18:37:25 <AngryPenguin> thanks :)
18:37:32 <bero> unless there's reasons to keep that znver1 surprise feature secret for a bit longer
18:38:55 <rugyada> bero: https://wiki.openmandriva.org/en/4.0
18:40:42 <rugyada> bero: https://forum.openmandriva.org/t/update-wiki-page-for-4-0-release/2265
18:40:56 <rugyada> bero: https://forum.openmandriva.org/t/omlx-4-0-roadmap/2273
18:41:25 <rugyada> all the links I think may be useful
18:42:01 <rugyada> ben79:  did I forget anything?
18:42:55 <ben79> Don't think so, we just need a blog announcement  and to send to all the magazines at the appropriate time.
18:43:07 <bero> #share everyone please add release notes etc. to https://wiki.openmandriva.org/en/4.0/Alpha/Release_Notes https://wiki.openmandriva.org/en/4.0 https://forum.openmandriva.org/t/update-wiki-page-for-4-0-release/2265 https://forum.openmandriva.org/t/omlx-4-0-roadmap/2273
18:43:10 <rugyada> right
18:43:54 <AngryPenguin> anyway, before release we should fix steam package
18:45:19 <bero> AngryPenguin: 1.0.0.59 is currently building
18:45:50 <ben79> before release we should fix everything
18:46:01 <AngryPenguin> bero: nah, you see UILDSTDERR: xz: bootstraplinux_ubuntu12_32.tar: Cannot allocate memory
18:46:19 <ben79> i'm still waiting for system-config-printing or a replacement
18:46:28 <AngryPenguin> bero: im able to build it but with this change https://github.com/AngryPenguinPL/steam/commit/0b7ee
18:46:30 <bero> AngryPenguin: it built successfully here, let's see how it holds up in abf
18:46:44 <rugyada> bero:  ben79 I can start a new pad to share announcement draft for us
18:46:55 <ben79> OK,
18:46:57 <bero> rugyada: please do
18:47:14 <rugyada> ok
18:47:51 <bero> AngryPenguin: stacer added
18:47:53 <ben79> rugyada: just start it here: https://www.openmandriva.org/ecrire/?exec=rubrique_edit&id_rubrique=10&bonjour=oui
18:48:05 <AngryPenguin> bero: thanks
18:48:38 <rugyada> ben79:  I'd rather prefer to share a pad
18:48:41 <bero> AngryPenguin: It does error out on xz -- probably if it's in a real 32bit environment, it can't allocate sufficient memory
18:48:50 <rugyada> if you are not strongly against
18:48:50 <bero> they should really get rid of that ridiculous 32bit requirement
18:48:51 <ben79> OK, whatever
18:48:54 <bero> either way should be fixable
18:49:12 <AngryPenguin> bero: so maybe test this: https://abf.openmandriva.org/build_lists/338868
18:49:13 <AngryPenguin> ?
18:50:18 <bero> AngryPenguin: currently testing another possible fix (it's definitely nicer not to bundle brokenbuntu libraries that don't have the same fixes as their system counterparts), but let's go for it if the other fix doesn't work
18:50:39 <bero> AngryPenguin: I've just changed "xz -9ef" to "xz", reducing compression level and therefore memory requirements
18:51:48 * rugyada hopes soon we'll killall 32bit once forever
18:52:59 <bero> Me too, but sadly there's still too many people who require stuff like wine and steam
18:54:03 <rugyada> well this will be something to be discussed later
18:54:44 <rugyada> offtopic here however need of dedicate discussion :)
18:55:52 <bero> AngryPenguin: https://abf.openmandriva.org/build_lists/347039
18:56:36 <AngryPenguin> bero: nice :)
18:57:02 <bero> I guess we're done with the ABF cooker topic (and actually well into release plan)... shall we move on?
18:57:19 <ben79> yes, please
18:58:03 <bero> #topic Lx4 Release Plan. Where are we.
18:58:11 <bero> I think we pretty much got that covered already...
18:58:36 <bero> Does anyone want to add anything to the topic?
18:58:46 <rugyada> nothing
19:01:40 <bero> Guess that takes us to
19:01:47 <bero> #topic Alpha testing. To what extent?
19:02:03 <rugyada> I think covered it too
19:02:05 <ben79> I think we covered that also
19:02:10 <rugyada> lol
19:02:23 <bero> yes, for the most part...
19:03:10 <rugyada> bero: unless you have something in particular
19:03:12 <bero> One thing that we haven't covered yet is non-x86
19:03:27 <bero> We have a couple of aarch64 builds that we should think about testing
19:03:40 <bero> Including one for Raspberry Pi, so that hardware is widely available
19:03:54 <bero> but not sure how widespread arm boxes are in QA...
19:04:07 <ben79> none here
19:04:16 <rugyada> no clue
19:04:37 <bero> we need some testing there and some help fixing problems
19:05:01 <bero> so maybe that's another thing to just add to the release notes to get some external testers to look at it
19:05:11 <rugyada> right
19:05:12 <ben79> we probably need to solicit testers with such hardware
19:05:20 <rugyada> was about to say
19:05:55 <rugyada> and in release announcement too we can add that we have ready to test such builds
19:06:34 <rugyada> wdyt?
19:06:56 <bero> yes, makes sense
19:07:04 <bero> #share we need testers on non-x86
19:07:10 <rugyada> more buzz :)
19:07:16 <bero> #action talk about non-x86 builds in release announcement
19:07:27 <ben79> I think we need to hope we get more support from users on that than we do with x86 32-bit testing
19:07:50 <bero> true
19:07:55 <bero> but I'm not too optimistic
19:08:15 <bero> mostly people with arm hardware are people who know what they're doing, and people who know what they're doing usually already have a distro they like
19:08:42 <bero> and given we get 0 hype from the press, there will be very little incentive for people to try it out
19:08:52 <rugyada> which doesn't mean they may like OM 4 more btw :D
19:09:13 <rugyada> not like*
19:09:16 <rugyada> lol
19:09:29 <bero> true -- unfortunately "If it isn't debian, it sucks" is too prevalent
19:09:49 <rugyada> well we'll try and see
19:10:55 <rugyada> if nobody interested then no point in wasting time on it/them
19:11:20 <rugyada> we'll share just among us :)
19:11:33 <rugyada> for ppl who need it.
19:11:54 <bero> #topic Release Notes Update
19:11:59 <bero> I guess we pretty much got that covered too?
19:12:06 <rugyada> yep
19:12:18 <bero> #topic Alpha issue handling
19:12:31 <rugyada> a further eye won't hurt anyway
19:12:35 <bero> So I presume this is where we decide what bug tracking system to use...
19:12:38 <Son_Goku> wait what
19:12:41 <Son_Goku> we have release notes?
19:12:57 <bero> Son_Goku: [19:43:07] <bero> #share everyone please add release notes etc. to https://wiki.openmandriva.org/en/4.0/Alpha/Release_Notes https://wiki.openmandriva.org/en/4.0 https://forum.openmandriva.org/t/update-wiki-page-for-4-0-release/2265 https://forum.openmandriva.org/t/omlx-4-0-roadmap/2273
19:13:08 <bero> Son_Goku: will go over them when the meeting is over...
19:13:12 <Son_Goku> ok
19:16:02 <rugyada> please note: also the errata needs review
19:20:53 <rugyada> aside: I'm keeping up to date the Overview wiki section for 4.0
19:21:13 <rugyada> updated some screenshot today
19:21:34 <rugyada> just tell me if you want anything else
19:22:10 <rugyada> more*, not else
19:22:31 <rugyada> screenshots to add
19:23:32 <rugyada> if you want to highlight anything in particular etc.
19:26:19 <ben79> Ummm...
19:26:26 <ben79> moving
19:26:30 <ben79> on
19:27:53 <rugyada> ben79:  sure, I'm done with this topic
19:27:55 <bero> #topic Updates before beta release
19:28:13 <bero> so I guess we got that covered too...
19:28:44 <rugyada> +
19:28:54 <bero> lots of updates to come so we don't need to release a ton of updates along with the release
19:29:06 <bero> but nothing too risky
19:29:44 <bero> #topic Beta Release timing
19:30:26 <bero> We should probably get some feedback on the alpha before fixing the date for real...
19:30:34 <crazy> back
19:30:42 <rugyada> bero: agreed
19:30:48 <bero> We don't really know if people will find serious bugs
19:30:48 <rugyada> hi crazy
19:31:04 <bero> but let's aim at getting it out quickly
19:31:47 <crazy> itchka: bero guys now *really* why would you want to use $Mhub , errm gitbug .. damn .. github as bug tracker ?
19:31:58 <crazy> :D
19:32:43 <crazy> if you really do not like the BTS you got and want something github like .. get titea fire container with it and use as own github for the repos even
19:32:53 <crazy> *gitea
19:34:54 <crazy> bug tracker , repos should be anyway somewhere selfhosted .. and use external stuff as mirror .. now say github go down or wipes your data ( reason does not matter ) , what do you do ? ..
19:35:41 <crazy> Oh github is down we cannot push anything .. Oh wait github to be up to report bugs ? ..
19:36:02 <bero> THat is a problem...
19:36:04 <crazy> always bad idea doing that .. but is probably just my personal opinion
19:36:44 <crazy> bero: the other way around is easy .. if your server go down use the mirror ..
19:36:45 <bero> The only good reason I can see is the integration with the rest of the infrastructure
19:36:54 <ashledombos[m]> ideally we could use gitlab
19:37:05 <crazy> ashledombos[m]: NO please NOT gitlab
19:37:19 <ashledombos[m]> same features as github
19:37:23 <ashledombos[m]> gitea is not bad also
19:37:27 <crazy> I tested it .. you *reallly* do NOT want to maintain his mess
19:38:08 <crazy> gitea is fine .. is go , small and has almost all github features even the private repos afaik
19:38:27 <ashledombos[m]> well i generally here https://framagit.org/public/projects it doesn't seem unmaintainable
19:38:34 <HisShadow_> we did use gitlab
19:38:41 <HisShadow_> for abf and stuff
19:38:52 <bero> I have checkouts of all our repositories that are synced daily, just in case
19:38:59 <bero> I don't trust any cloud providers
19:39:18 <crazy> ashledombos[m]: you'll cry on updates with that CE version and is resources hungry as hell
19:39:23 <bero> but can't hurt to use them if we have backup solutions and copies
19:39:41 <crazy> bero: you do it with git hooks
19:40:02 <crazy> push to your-git -> pushes to mirrors too
19:40:25 <crazy> or you set it in github as mirror and it synces self ( with some webhooks I think )
19:41:07 <ashledombos[m]> we can migrate to launchpad, bero trusts MS
19:41:27 <ashledombos[m]> (Mark Shuttlething)
19:41:28 <crazy> sure .. we all love MS :)
19:41:45 <bero> It's really telling that even his name is MS
19:42:23 <bero> we used launchpad in linaro for a while, always sucked
19:42:29 <Son_Goku> why not use pagure and mirror to things?
19:42:44 <bero> so badly that even the brokenbuntuites in linaro decided to move off it ;)
19:42:53 <bero> Son_Goku: pagure is an option
19:42:56 <Son_Goku> I actually wanted to bring up this idea for another reason, too
19:43:17 <Son_Goku> there's some interest in Fedora about repoSpanning Dist-Git systems across distros for sharing packaging
19:43:19 <HisShadow_> or was it just self-hosted git repos...I don't remember anymore, 3 years have passed
19:43:30 <Son_Goku> and while the idea was brought up for spanning between Fedora and Mageia
19:43:41 <Son_Goku> there's no reason it couldn't be extended to OpenMandriva too
19:44:09 <Son_Goku> and Pagure is an order of magnitude lighter than GitLab and other Git hosting systems
19:44:25 <Son_Goku> it supports automatic push mirroring, and the upcoming release will also support pull mirroring
19:44:38 <bero> Not sure if sharing packaging can really work given there's all sorts of differences, but can't hurt to try
19:44:47 <bero> I'd guess at least for some packages it would work
19:45:46 <Son_Goku> it's handy for comparing and patch sharing
19:46:18 <bero> true
19:46:23 <ashledombos[m]> https://docs.gitea.io/en-us/comparison/ pagure is unfortunately not in comparison
19:46:27 <Son_Goku> https://twitter.com/mattdm/status/1072519912957140992
19:46:31 <Son_Goku> bero ^
19:46:38 <Son_Goku> this was the Twitter conversation that led to this
19:47:14 <ashledombos[m]> is pagure self hostable?
19:47:16 <Son_Goku> yes
19:47:23 <Son_Goku> it's actually stupid simple to run
19:47:37 <Son_Goku> it's currently packaged for Fedora, Mageia Cauldron, and openSUSE Tumbleweed
19:48:28 <Son_Goku> it's written in Python, so it's easy to hack on too
19:48:36 <Son_Goku> https://pagure.io/pagure
19:53:48 <Son_Goku> my plan is that Mageia will also use Pagure soon as a Git frontend
19:53:59 <ashledombos[m]> Trying to find pagure features
19:54:02 <Son_Goku> it's actively maintained and developed, and the developers are very friendly
19:55:05 <Son_Goku> the documentation is here: https://docs.pagure.org/pagure/
19:55:19 <ashledombos[m]> bero: what would be the blocker for it?
19:55:24 <Son_Goku> but as far as a feature list goes, I dunno
19:58:24 <bero> ashledombos[m]: I don't see any blockers, except maybe manpower to set up and maintain another thing
19:59:01 <ashledombos[m]> yes sure but now there is Son_Goku to maintain it ^^
19:59:35 <bero> Son_Goku: how well does it interact with bug trackers, to come back to the reason why some people want to switch to github bug trackers?
20:01:38 <Son_Goku> what do you mean?
20:01:46 <Son_Goku> it has its own lightweight issue tracker similar to github
20:03:26 <bero> Son_Goku: does it support things like automatically seeing that a commit closes a bug etc.?
20:03:31 <Son_Goku> yes
20:03:56 <Son_Goku> it also can emit MQTT, STOMP, or FedMsg notifications for other services to consume
20:04:05 <Son_Goku> so if you wanted a bz to close based on a commit, it can
20:08:18 <bero> Looks like a good option to me...
20:08:26 <bero> But would be good to hear from TPG and a few others
20:08:34 <bero> so maybe we should take this up again next time?
20:14:53 <bero> I'll take that as yes...
20:15:08 <bero> #action Take a look at pagure when more interested people are around
20:15:10 <bero> #topic AIB
20:15:18 <bero> ben779: ben79: Do you have AIBs?
20:15:52 <ben79> ¡Ay, caramba!
20:16:08 <ben79> Request for packaging MultiBootUSB package for Openmandriva
20:16:08 <ben79> https://issues.openmandriva.org/show_bug.cgi?id=2395
20:16:08 <ben79> Bug in php under apache
20:16:08 <ben79> https://issues.openmandriva.org/show_bug.cgi?id=2383
20:16:08 <ben79> system-config-printer crashes on startup
20:16:09 <ben79> https://issues.openmandriva.org/show_bug.cgi?id=2382
20:16:11 <ben79> And this against dnfdragora reported in forum:
20:16:13 <ben79> https://forum.openmandriva.org/t/omlx-4-0-pre-alpha-iso-plasma-development-builds/2128/164
20:17:01 <bero> 2395 is fixed... I think AngryPenguin built it
20:18:29 <bero> I know that php works in cooker...
20:18:35 <bero> so 2383 is probably fixed too
20:19:13 <bero> system-config-printer seems to be missing some python modules (or maybe it's more python2 code that runs in /usr/bin/python==python3)
20:19:25 <bero> Is there any reason to use it over e.g. falkon http://localhost:631?
20:20:43 <bero> dnfdragora works here... I remember fixing the error mentioned in the forum post, probably a dnf upgrade or dnf distro-sync should fix that one...
20:26:51 <bero> anything else?
20:30:38 <bero> apparently not...
20:30:41 <bero> #topic AOB
20:30:44 <bero> Doe we have AOB?
20:34:22 <bero> doesn't look like it...
20:34:35 <bero> So good luck with the alpha to all of us!
20:34:37 <bero> #endmeeting