16:28:56 <itchka> #startmeeting
16:28:56 <chwido> Woof! Let's start the meeting. It's Wed Nov  9 16:28:56 2016 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:28:56 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:28:56 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:28:56 <chwido> Have a good meeting, don't bark too much!
16:29:06 <itchka> #item 2
16:29:40 <itchka> #topic Kahinah preparation for the rolling release model.
16:30:37 <itchka> As you all hopefully know by now we have to change the way we do the QA process if we are to adompt a rolling release model.
16:31:56 <itchka> avokhmin and myself have done some work on it in terms of defining whaty needs to be done and you can see how far we have got here. https://github.com/OpenMandrivaSoftware/rosa-build/issues/13#issuecomment-256779214
16:33:10 <itchka> Unfortunately avokhmin is in Japan at the moment and is only really available at weekends.
16:36:51 <itchka> I communicated with him yesterday evening on skype and he said that we had done a partial revue and he thought there were problems. He said he will try and complete a review over the next couple of days. I would be grateful if others could study this problem perhaps using my flowchart as a guide to the functionality required from Kahinah and ABF
16:38:51 <itchka> We also have the problem that Persona kahinahs authentication system is to be shut down on the 30th November and at that point it will cease to function unless something is done. Xu(m) can you comment on this please?
16:40:59 <Xu[m]> I can see if I can replace Persona with oauth2 to github. Alternatively, I can temporarily set up an alternative Persona server until there's a replacement
16:41:39 <Pharaoh_Atem> replacing it with OpenID Connect is probably the ideal case
16:42:06 <Xu[m]> yeah, that'd be the ideal case
16:42:34 <Pharaoh_Atem> that's also what Bodhi uses, too
16:42:41 <itchka> Is that harder than oauth2?
16:42:49 <Pharaoh_Atem> no
16:42:58 <Pharaoh_Atem> OpenID Connect is the successor to OpenID and OAuth2
16:43:11 <Xu[m]> but yeah. assume kahinah won't go down. i'll probably update kahinah sometime this week or next and you shouldn't notice any difference
16:43:16 <Xu[m]> or you will, not sure how that's going to look yet
16:43:17 <Xu[m]> lol
16:43:18 <Pharaoh_Atem> it layers authz bits onto authn stuff
16:43:38 <Pharaoh_Atem> oauth2 is purely authn
16:43:54 <itchka> Thanks Xu[m] that makes me feel a whole lot better ;)
16:46:49 <itchka> Also regards Kahinah we are a bit behind on testing so if anyone has a spare half-hour or so to test a package or two each day we could soon clear the list.
16:49:44 <christann> How can we approve groups of packages such as yesterday's update to plasma 5.8.3
16:50:07 <Pharaoh_Atem> are packages built in siderepos (like Koji does)?
16:50:22 <Pharaoh_Atem> if they are, then you could just push them in as a group and regenerate the metadata
16:50:38 <itchka> We can't yet. If enough people say yes then Xu[m] can run a script to release them all.
16:52:17 <itchka> christann: If you are happy mail me your yes, I'll check with Ben and if he says yes too then I'll put in a request for the group to be released.
16:52:37 * bero is back
16:52:57 <christann> Sounds good.
16:53:36 <itchka> Hi bero.. we are on item 2 at the moment.
16:54:23 <bero> yes, already read the log
16:55:56 <itchka> Ok
16:56:46 <itchka> bero: Are you ok to do item 1 we are more or less finished with item 2
16:56:50 <Xu[m]> I think item 2 is more or less done right now
16:56:59 <bero> sure, but I don't think we have anything new to add to 1
16:57:07 <bero> essentially same as last 2 weeks
16:57:20 <bero> and again probably nobody with a different view around
16:57:48 <itchka> #item 1
16:57:58 <itchka> #topic i686
16:58:13 <itchka> Ok just for the record
16:58:18 <bero> So from where I stand, someone needs to flip the i586 switch in abf to i686
16:58:34 <itchka> Are the other devs in agreement?
16:58:57 <bero> and symlink directories around to make sure we keep pulling in i586 packages in i686 until everything is rebuilt
16:59:14 <bero> Some (most notably TPG) think we should just can i?86 altogether
16:59:28 <bero> but I haven't seen anyone making the point that we should keep i586 around
17:00:34 <itchka> I think the point TPG was maybe trying to make is that we don't really have a plan for phasing it out.
17:01:30 <itchka> This is why I thought it may have been helpful to view it in context with the rolling release model.
17:01:52 <bero> Right...
17:02:39 <bero> One way to start phasing it out IMO is adding a warning screen to the installer -- if someone is trying to use the i686 iso on an x86_64 machine, he should be told that he'd be better off with the x86_64 iso
17:02:53 <bero> and then we can check again a bit later how many people still use i686
17:03:35 <bero> but one more problem that needs to be solved before we can really phase it out is the compat libraries we'll need even if/when we drop it as a fully supported architecture
17:03:45 <bero> Without compat libraries, no wine and no steam
17:04:13 <bero> and currently abf has no concept of "Build all packages on x86_64, aarch64 and armv7hl, and build this particular list of packages on i686 too"
17:04:33 <bero> so IMO that's something we need to sort out before we can even seriously think about dropping i?86
17:06:08 <itchka> Yes I very much agree and I think we must put that item on the agenda for discussion and general study. I wonder how other distros are solving it.
17:07:00 <Pharaoh_Atem> well, Fedora has downgraded i686 as a secondary arch
17:07:11 <Pharaoh_Atem> meaning that now releases and composes are on a best-effort basis
17:07:32 <bero> that makes sense, we should do that too
17:07:44 <bero> (they still provide it, just reduced level of support)
17:07:57 <Pharaoh_Atem> it's sort of treated as a first-class architecture in terms of packages for multiarch on x86_64, though
17:08:41 <Pharaoh_Atem> I think the idea is that within the next few releases, support for i686 can gracefully degrade (like 32-bit PowerPC did)
17:09:03 <bero> sounds like what we should do
17:09:37 <itchka> what would do about wine have that gracefully degrade too?
17:09:37 <bero> as part of that, it would be ok to just "ExcludeArch: %{ix86}" in some packages that aren't compat libraries and that are causing pain
17:10:02 <bero> no, we need to keep taking care of the 32bit packages we need in the 64bit world as well
17:10:18 <bero> but if let's say libreoffice fails to compile, we could just add "ExcludeArch: %{ix86}"
17:10:22 <bero> no compat libraries with that...
17:10:25 <Pharaoh_Atem> yeah
17:10:31 <Pharaoh_Atem> pretty much the same approach going on in Fedora
17:10:55 <itchka> That's a pretty mainline package to ditch!
17:11:15 <Pharaoh_Atem> libreoffice isn't likely to break anytime soon
17:11:29 <Pharaoh_Atem> especially since 32-bit x86 is huge deal for them
17:11:49 <Pharaoh_Atem> but if other applications break... *shrugs*
17:12:00 <Pharaoh_Atem> best-effort fixing, and if not easily fixed, excludearch it is
17:12:14 <bero> that was just one example of a package that might cause problems and that won't be needed in a "care mostly about 64bit compat" world
17:13:31 <itchka> Do we still need a working install of i686 to build the compat packages or can we cross compile?
17:14:06 <Pharaoh_Atem> mock builds of i686 should work on x86_64
17:14:14 <Pharaoh_Atem> as long as you're okay with 64-bit hosts for everything
17:15:29 <itchka> So we could just build the compat packages.
17:16:21 <Pharaoh_Atem> as we continue to degrade it, we can do Fedora-style multiarch repos to reduce the number of repos
17:16:41 <Pharaoh_Atem> that is, a single repo with dual-arch, only including compat libs in the x86_64 repo
17:16:57 <Pharaoh_Atem> it also makes it less likely for people to use 32-bit apps on 64-bit systems
17:16:57 <itchka> I see
17:17:25 <Pharaoh_Atem> ABF supports this configuration, so it can be done
17:21:24 <proyvind> if you're going to build 32 bit x86 packages for backwards compatibility in x86_64 environments, you can push it way further than i686
17:21:45 <proyvind> ie. sse2 is nice..
17:24:27 <itchka> Ok, So bero are you saying that our next release will still have a 32bit component and it will be i686?
17:25:32 <proyvind> make it pentium4 or something
17:26:19 <proyvind> first generation x86_64 and pentium4 both has sse2, no?
17:26:36 <Pharaoh_Atem> yes
17:26:52 <Pharaoh_Atem> but the corresponding Athlon XP didn't have it
17:26:59 <proyvind> well
17:27:37 <proyvind> if you're dropping release compatible with 32 bit athlon xp anyways,  how does it matter? ;)
17:27:57 <Pharaoh_Atem> we didn't say that
17:28:18 <Pharaoh_Atem> i686 would be downgraded to best-effort for release composes and stuff
17:28:38 <proyvind> not sure what you mean
17:29:28 <Pharaoh_Atem> it means we're still making images and stuff
17:29:39 <Pharaoh_Atem> but it's not considered blocker if they fail
17:29:44 <proyvind> then why bother moving to i686?
17:29:46 <proyvind> for cmov?
17:30:14 <Pharaoh_Atem> a few things
17:30:15 <proyvind> i586 compatibility for 32 bit releases is a stronger selling point..
17:30:18 <Pharaoh_Atem> not really
17:30:29 <proyvind> really.
17:30:54 <Pharaoh_Atem> when even the most conservative of distributions moved up to i686, there's literally no reason not to
17:31:03 <proyvind> for what gain?
17:31:28 <Pharaoh_Atem> compiler optimizations, enable certain applications and libraries to build, etc.
17:31:28 <proyvind> what you achieve is less than you loose by dropping backwards compatibility
17:31:54 <itchka> Guys we have already debated this and we don't need to do it again please lets not waste everyones time.
17:32:15 <bero> proyvind: i686+sse2 is the idea
17:32:56 <proyvind> bero: so why not pick ie. pentium4 to get i686+mmx+sse+sse2 etc..? :)
17:33:05 <Pharaoh_Atem> Athlon XP+, Athlon 64, Pentium 4, etc. will be the base
17:33:10 <bero> there's also issues with upstream projects dropping i586 (compiler-rt and friends)
17:33:28 <bero> proyvind: yes, pentium4 is essentially what we're talking about with i686+sse2 -- sse2 implies mmx+sse
17:33:30 <Pharaoh_Atem> the only compiler still supporting i586 is gcc
17:33:38 <Pharaoh_Atem> no one else does
17:33:53 <bero> clang sort-of does
17:34:07 <bero> but doesn't care much about i586-only bug reports
17:34:31 <Pharaoh_Atem> llvm only has i586 stuff as a side-effect of i686
17:34:46 <Pharaoh_Atem> and they want to drop i586 anyway, as Apple cares not a whit for it
17:38:57 <bero> and neither does google (2nd largest contributor these days)
17:43:17 <Pharaoh_Atem> llvm also makes it increasingly annoying to build without i686 features, too
17:51:03 <itchka> Ok well we need to move this forward. We are not going to be on i686 forever either so I think we do need to work up a plan for deprecation which will include provision of compat libs to support wine and steam (and possibly others)
17:52:18 <itchka> #action Create new agenda item "i686 deprecation planning" This will be a standing item on the agenda until a plan is finalised.
17:52:33 <Pharaoh_Atem> I think we can first start with downgrading it to a secondary architecture, making releases best-effort
17:53:02 <Pharaoh_Atem> provide information in releases and materials about how to determine whether a user can install 64-bit on older systems
17:53:27 <Pharaoh_Atem> and migrate to a unified multiarch repo for x86_64, so that we don't depend on i686 repo existence for multiarch compat
17:55:47 <Pharaoh_Atem> that will allow us to accelerate a de-emphasis on 32-bit x86 and get rid of it entirely much more quickly
17:56:01 <itchka> Those are good points and the informational one should probably be highest on teh list
17:57:58 <Pharaoh_Atem> maybe making a simple tool to help people identify if their computer is compatible with x86_64 OpenMandriva would be good too
17:59:07 <itchka> Yes indeed I can across a 64bit laptop the other day that would not accept an x86_64 install
17:59:29 <itchka> So it's not straightforward
18:00:02 <Pharaoh_Atem> it could also be used to help in surveying the matrix of users that have x86_64 build compatible systems
18:01:16 <itchka> Pharaoh_Atem: Are you voluteering to write such a tool :)
18:01:25 <Pharaoh_Atem> mmmm
18:01:41 <Pharaoh_Atem> let's not put words in my mouth :)
18:02:03 <itchka> With you skills it would just be a few minutes :)
18:02:41 <itchka> Seriously though how would one go about this?
18:02:48 <Pharaoh_Atem> I'm not exactly sure
18:03:03 <Pharaoh_Atem> not sure what the criteria that should be checked to identify compatibility
18:03:47 <itchka> Just have an iso with two kernels and a bit of clever lua scripted grub stuff?
18:04:03 <Pharaoh_Atem> maybe
18:04:36 <Pharaoh_Atem> I don't have any particularly good answers here
18:04:43 <itchka> anyone?
18:05:08 <proyvind> I have dual arch support in my drakx branch
18:07:14 <proyvind> https://github.com/DrakXtools/drakx/blob/master/images/grub_data/grub.cfg
18:07:53 <itchka> Would a Linux version of cpuid do it? You'd only need to boot and i686 kernel to checkout the processor.
18:08:48 <Pharaoh_Atem> that would probably be sufficient
18:09:05 <Pharaoh_Atem> that also gives you the ability to identify the boot process too
18:09:10 <proyvind> uhm
18:09:31 <proyvind> there's a cpuid grub2 module
18:09:39 <proyvind> look at the grub.cfg example above
18:11:08 <itchka> Ah yes cpuid -l
18:14:45 <itchka> That's pretty much the solution then; once booted we could open a web browser and in some way ask the user to record the result.
18:19:03 <itchka> Ok I think we are done with i686 so we will move onto the final item when I have attended to a call of nature.
18:27:21 <itchka> Ok let's move on
18:27:28 <itchka> #item 3
18:28:07 <itchka> #topic  Update on fixing bugs for the new spin
18:33:32 <itchka> Ok ben79 sent a mail to the cooker list to say there has been some progress on bug fixes. I have now fixed the issues with efibootmgr (bero thanks for your input) which would have broken a new spin for UEFI. There is still a problem with grub not writing to it's environment block file /etc/grubenv so the default boot choice is not remembered. I haven't managed to fix this yet but then I haven't looked for the
18:33:33 <itchka> problem I have only determined what is not happening
18:33:48 <itchka> bero do you have anything to report bugwise?
18:34:10 <bero> not really - I was at LPC busy with completely other things
18:37:25 <itchka> Ok no worries. I'm fairly sure the bugs that are stopping a new spin will be fixed pretty soon. I would suggest we make the new spin as soon as kahinah has it's new authentication system which will avoid any problems with publishing fixes for any issues with the QA test iso.
18:39:58 <itchka> Moving on
18:40:02 <itchka> #item 4
18:40:32 <itchka> #topic AOB (Any other business)
18:41:32 <itchka> Short items only please meeting will end at 20:00 CET
18:50:18 <itchka> Meeting will end in 10 minutes
19:03:34 <Pharaoh_Atem> nothing from me
19:03:44 <Pharaoh_Atem> bero, anything?
19:03:56 <bero> I don't have anything right now
19:04:15 <itchka> Oh I'll do the shares and end the meeting
19:14:00 <itchka> #share Item 1:  Topic: Arch i686: The adoption of arch i686 will move forward. A new item will be added to the agenda to discuss and implement a plan for deprecation of this architecture so that it can be phased out in an orderly fashion. i686 releases will now be made on a best effort basis. Seriously problematic packages will be excluded from builds this will reduce the load on our developers. A plan for
19:14:01 <itchka> deprecation will be created which will include the creation of a tool to determine whether a machine is suitable for a 64bit installation. The need for legacy libs to support wine and steam (and possibly others) has been recognised and thus the plan will cover the production and distribution of compat libs from a single repository once i686 is fully deprecated.
19:21:09 <itchka> #share Item 2: Topic: Kahinah:  Developers were invited to review the current progress of the design of the new Kahinah functionality requirements. avokhmin will review current offerings. The isssue of the suspension of the Persona authentication service on the 30th November was raise Xu(m) stated that he would address this issue in the coming week and that we should have an alternative authentication system
19:21:10 <itchka> before the 30/11. christann raised the question of the release of KDE Plasma updates from Kahinah ..it was explained that this was currently managed by a hand crafted script. Votes by email were requested once three positive votes were received the packages will be released as a group.
19:24:46 <itchka> #share Item 3: Topic: Bug Fixes for new spin. Some progress has been made but there is still more to do. It is hoped that the worst bugs will be fixed by end of next week this will hopefully be ready after Kahinahs authentication update.
19:25:16 <itchka> #shate Item 4: Topic: AOB: There was no AOB
19:25:21 <itchka> #endmeeting