15:32:32 <Xu[m]> #startmeeting
15:32:32 <chwido> Woof! Let's start the meeting. It's Wed Oct 19 15:32:32 2016 UTC. The chair is Xu[m]. Information about me at https://wiki.openmandriva.org/en/Chwido.
15:32:32 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:32:32 <chwido> You should add extra chair(s) just in case, with #chair nick.
15:32:32 <chwido> Have a good meeting, don't bark too much!
15:33:41 <Xu[m]> I literally just realised that the meeting date that klebedeff put on the email was 18 October... confused me for a moment
15:34:17 <Xu[m]> ping bero klebedeff ashledombos
15:36:59 <klebedeff> oops, sorry:)
15:37:30 <Xu[m]> http://matrix.org/_matrix/media/v1/download/matrix.org/QHsDDqUkMmzRUWRhSgfxaHRE - Xu[m]_2016-10-19_15:37:29.txt
15:37:37 <Xu[m]> cool
15:37:40 <Xu[m]> that doesn't work
15:38:15 <Xu[m]> agenda: 1. i586 -> i686, 2. Packages not installing on Lx 3, 3. Transifex/Translations, 4. Bugzilla, 5. Presentation platform?, 6. Misc.
15:38:26 <Xu[m]> #topic i586 -> i686
15:39:15 <Xu[m]> There was discussion on this last week -- the end consensus was move to i686
15:39:36 <Xu[m]> bero/bero|2 is supposed to report on this?
15:39:55 <Xu[m]> If he doesn't show up in a minute we'll skip and come back to it
15:41:59 <Xu[m]> okay
15:41:59 <Xu[m]> Moving on
15:42:06 <Xu[m]> #topic Packages not installing
15:42:16 <klebedeff> Colin just sent a message that he is stuck in traffic but hurrying for the meeting
15:42:30 <Xu[m]> klebedeff: ok
15:42:48 <Xu[m]> ben79_: packages not installing - it really looks like a lot of these packages are from contrib
15:43:07 <Xu[m]> especially when you look at the repoclosure report
15:43:09 <Xu[m]> http://repoclosure.openmandriva.org/
15:43:18 <christann> does anybody use them anymore?
15:43:40 <ben79_> Well, that is to be expected, but does it mean they shouldn't either be fixed or removed.
15:44:07 <Xu[m]> I think we should probably remove dead packages... Because it's becoming a mess
15:44:31 <ben79_> Also in regards to maintaining bugzilla is there a way to get drosbeck to stop with the multitude of bug reports on this?
15:44:39 <Xu[m]> I wonder -- if we could split off our Github org for maintained packages and contrib packages
15:46:14 <ben79_> Xu[m]: What does the repoclosure report tell us? Wht is it reporting?
15:46:26 <Xu[m]> ben79_: it tells us packages that are uninstallable
15:46:49 <Xu[m]> with being able to stop the bug reports, i guess we should rebuild them..?
15:47:05 <Xu[m]> we should probably find some way to do a mass build with the repoclosure report or something
15:47:06 <ben79_> OK, so it tells us just what drosbeck is reporting just not which individual packages.
15:47:37 <Xu[m]> it tells them by repo - so all packages that are uninstallable
15:49:12 <ben79_> OK and if you click on the number it does list the individual packages.
15:49:24 <Xu[m]> right..
15:51:08 <christann> There is a lot of them. How do we determine which are needed and which are not.
15:51:35 <Xu[m]> That's a good question. We inherited a lot of these packages..
15:52:16 <Xu[m]> I think we should purge these packages in cooker
15:52:25 <Xu[m]> but i might also add that we can't remove any from lx3, i think
15:52:32 <Xu[m]> might be better to rebuild in the short term
15:52:49 <Xu[m]> and figure out how to distinguish packages we want/need from packages we should get rid of.
15:55:59 <itchka> Here
15:56:13 <Xu[m]> itchka: o/
15:56:22 <Xu[m]> we're trying to figure out how to handle all these dependency issues in lx3
15:56:35 <Xu[m]> and having a wider discussion on contrib packages and if we should be dropping them from cooker
15:56:50 <Xu[m]> #chair itchka
15:56:50 <chwido> Current chairs: Xu[m] itchka
15:58:47 <itchka> Xu[m]: The dep issues are they the KDE ones you are taliking about. That the libs and apps all need to be updated at the same time
15:59:45 <Xu[m]> no
15:59:51 <Xu[m]> looks like lx3 contrib issues
16:01:04 <itchka> Ah so there are deps from main across to contrib then?
16:01:53 <Xu[m]> more like - lots of bugs like https://issues.openmandriva.org/show_bug.cgi?id=1979
16:06:33 <itchka> Perl stuff that hasn't been updated I guess
16:09:23 <ben79_> In order to keep up with bugzilla I need this guy to stop filing all these bugs. It ain't helping.
16:10:04 <tapwag> IMHO we should be glad of people reporting bugs.
16:10:09 <itchka> I guess we need to review those bugs that have this issues. The problems may be caused by just a few key packages. If they are fixed maybe we fix many more bugs
16:10:43 <itchka> Hi tapwag
16:10:49 <tapwag> itchka, Hello
16:12:02 <tapwag> After all OpenMandriva made a promise to listen to its community.
16:12:36 <itchka> ben79_: Are they all from drosdek?
16:12:53 <ben79_> Yes
16:14:13 <itchka> Ok well at least I can easily search them out.
16:14:47 <ben79_> tapwag: I am glad of people reporting bugs, this guy has pointed out a problem
16:15:18 <ben79_> But he doesn't need to keep filing a seperate bug against evey single package when we already have that information
16:15:36 <ben79_> We do have limited resources
16:17:46 <tapwag> I just a look at the last three bugs he posted and they all have different unsatisfied dependencies.
16:18:09 <Xu[m]> it sounds like the package itself needs a rebuild - that's why it has unsatisfied dependencies
16:18:13 <ben79_> That all being said I assume drosdeck means well we just need to inform him that issue is dealt with a different way
16:18:17 <Xu[m]> some of the packages he's reporting hasn't been rebuilt since 2013 it looks like
16:19:07 <ben79_> tapwag: doesn't matter, they are mostly obscure, not used packages in contrib repo that haven't been rebuilt in a while
16:19:11 <Xu[m]> i need to head off for now - itchka, you have chair. agenda: 1. i586 -> i686, 2. Packages not installing on Lx 3, 3. Transifex/Translations, 4. Bugzilla, 5. Presentation platform?, 6. Misc. We skipped #1 because bero / bero|2 was not responding. we're on 2.
16:19:32 <tapwag> ben79_, Well, what do you suggest then?
16:19:48 <itchka> Xu[m]: Ok thanks
16:19:54 <ben79_> itchka: Have we ever rebuilt broken packages in contrib?
16:20:03 <ben79_> tapwag: ^^^
16:20:09 * bero|2 just got back, was in a Linaro meeting
16:20:43 <ben79_> tapwag: rebuild broken packages in contrib and get rid of some of them altogether.
16:21:52 <ben79_> itchka: tapwag:  Wonder if I could learn enough about ABF in a month to learn how to do somethinglike this myself???
16:22:17 <itchka> ben79_: We had a list of packages that were broken after the last rebuild I did some work on them as crisb also niccos friend did some too be ut he got discouraged because he couldn't handle clang
16:22:21 <tapwag> ben79_, I never really mastered ABF...
16:23:26 <itchka> I must do that abf video I keep meaning to do it but there';s never enough time in my life.
16:23:55 <ben79_> itchka: Then to be proactive about this specific issue I need to take up again the learning and now doing of fixing broken packages.
16:24:33 <ben79_> itchka: And for the moment focus on contrib repo
16:25:17 <itchka> Boy that guy sure has filed a lot of bugs
16:25:21 <ben79_> itchka: And maybe we could ask drosbeck if he like to join in the learning/fixing effort
16:25:56 <itchka> ben79_:  I think that would be a splendid idea
16:25:56 <ben79_> Yes, we need to focus his energy and enthusiasm elsewhere
16:28:59 <itchka> ben79_: I'll revue the problem packages he's mentioned in his bugs and if they are still maintained we can works together and see what can be done to fix them.
16:29:45 <tapwag> Some of the packages are actually quite interesting (miro, nestopia, also some KDE-Apps)
16:31:47 <ben79_> Should someone write a blog post requesting help on fixing broken packages?
16:31:48 <itchka> since bero has returned perhaps we could do the i566-i686 item if that's ok with everyone.
16:32:17 <tapwag> itchka, Do it. I will be out for shopping and back in 15 minutes.
16:33:00 <itchka> ben79_: We can do an action on that if you like. Not sure how much response we'll get but it's worth a go.
16:33:58 <itchka> #action Put up blog post to request help with contrib packaging.
16:34:13 <ben79_> Do we have any written info, How To, Tutorial, anywhere on fixing broken packages?
16:34:43 <ben79_> itchka: My best guess is that most of these packages will be fixed by simply rebuilding them.
16:36:21 <itchka> ben79_: Could be that a variety of things need to be done.
16:37:12 <itchka> If you like we can try and fix a few one evening and you can get an idea of how abf works while we do it.
16:38:29 <itchka> ben79_: Are you happy to move on to the next item?
16:38:43 <ben79_> Yes
16:38:49 <itchka> #item 1
16:39:08 <_TPG> hi
16:39:12 <itchka> #topic i586-i686 report from bero
16:39:29 <itchka> _TPG: Hi :) Good to see you here
16:39:44 <_TPG> :)
16:40:57 <itchka> bero|2: We left this such that you would sound out the other devs about the changing to i686 rather than dropping 32bit \ltogether
16:41:22 <itchka> altogther
16:44:39 <itchka> bero|2: ping
16:48:44 <itchka> bero: ping
16:48:47 * tapwag back
16:49:00 <itchka> but bero has gone...
16:49:53 <itchka> tapwag: We wi do your topic
16:50:02 <tapwag> itchka,
16:50:04 <tapwag> Okay
16:50:07 <itchka> #item 3
16:50:28 <itchka> #topic Transifex/Translations
16:50:44 <itchka> Off you go tapwag
16:51:10 <tapwag> I am facing some problems concerning our l10n process and I am not really happy about the current situation as I simply never really mastered ABF and do not understand what the relationship between ABF and github.com is.
16:52:07 <tapwag> As such I do not know how to bring translations in.
16:52:36 <tapwag> I have a github.com account but do not know if changes made there are integrated into the distribution.
16:53:21 <tapwag> Also there is a lot of old translations on transifex.com
16:54:04 <tapwag> And I would like to ask if it is still that way if Master sources are on ABF because this is what I have been told.
16:54:57 <tapwag> I would also like to announce that I joined the openSUSE l10n team as Cooker once crashed on me and I tried Tumbleweed
16:55:25 <tapwag> which is working fine. I decided to dedicate myself for to upstream at KDE so all distributions will benefit who use KDE.
16:55:55 <tapwag> openSUSE uses a platform called Weblate and it's at l10n.opensuse.org
16:56:48 <itchka> ok tapwag I'm not really qualified to answer this question but I can say that all OpenMandriva software isa on GitHub nothing is in ABF anymore.
16:56:50 <bero|2> had to take the dogs outside, back again
16:57:01 <tapwag> Apparently they are using their own servers. What happened with us what that somebody rushed off to transifex.com and registered an account there. In Prague I wanted to elaborate on the pros and cons of having our own platform
16:57:15 <bero|2> Same here... I'm pretty sure we don't have any repositories on abf anymore
16:57:25 <tapwag> itchka, bero|2 Thank you
16:57:28 <bero|2> but I don't know where translations are being pulled in
16:57:38 <bero|2> (or even if any non-upstream translations are being pulled in)
16:57:48 <tapwag> bero|2, There is a command line client for transifex.com
16:58:39 <bero|2> HisShadow: fedya: ^^^ do you know if this is being used anywhere in abf to pull in translations or do we have to do that manually somewhere?
16:58:56 <tapwag> In Prague I asked Raphael to do a tutorial about this as he used it for the website but I understand if he didn't get round to do it. It was also a fairly quick conversation in between.
16:59:15 <tapwag> In Krakau, sorry
17:00:48 <tapwag> bero|2, What I have done so far was that I edited the strings directly from github.com sources and then git pushed them in.
17:00:58 <itchka> here's the info on the trasiflex client http://docs.transifex.com/client/
17:01:23 <bero|2> that's probably still how it works
17:01:33 <bero|2> but I've never looked at the translation mechanisms
17:02:33 <HisShadow> bero|2: pull what from where?
17:02:34 <tapwag> At least for our own software we should make sure it is properly localized.
17:02:49 <tapwag> Like oma-welcome
17:02:58 <_TPG> bero|2: noooo i've already build these plasma packages
17:03:03 <bero|2> HisShadow: updated translations from transifex
17:03:05 <_TPG> i'm on breeze now
17:03:30 <bero|2> _TPG: stopping my build... the update script just finished the local builds and automatically started them in abf
17:03:51 <_TPG> thanks
17:04:37 <_TPG> i'm fixing breeze now, if it will build you can run your script for next lines of package after breeze
17:05:03 <bero|2> breeze built ok here
17:05:12 <bero|2> chances are I already fixed it
17:05:21 <HisShadow> bero|2: I'm not sure, that translation thing in readme is left over from abf.io
17:06:20 <_TPG> bero|2: breeze now needs appstream :)
17:06:32 <itchka> HisShadow: Can you point me the README
17:08:31 <tapwag> Also just one thing: Shall we stick with our hosted version of transifex.com or should be reconsider having our own instance? I am asking because I felt that somebody just rushed off and we never really made a decision as OMA-community.
17:09:09 <HisShadow> itchka: it's in the rosa-build repo where you created issue
17:09:24 <itchka> HisShadow: Thanks
17:09:35 <bero|2> IMO stick with the hosted one if it's free, the less load we have on our infrastructure the better
17:09:48 <tapwag> For those who are interested, I made a list of some alternatives in the wiki
17:09:49 <tapwag> https://wiki.openmandriva.org/en/L10n
17:10:34 <tapwag> bero|2, I got some warnings that we apparently have outgrown our resources.
17:10:52 <tapwag> Transifex said it would be free for open source projects though
17:11:09 <tapwag> I emailed council-members about this a while ago
17:11:16 <tapwag> But I see your point
17:11:52 <tapwag> Also I would like to present the idea of specific l10n-mailing-lists
17:12:34 <tapwag> KDE for example doesn't have just one particular l10n-mailing-lists but l10n-en, l10n-de, l10n-fr, l10n-es
17:12:43 <tapwag> Shouldn't be too hard to implement
17:13:21 <tapwag> That's all I wanted to bring forward
17:14:01 <bero|2> I think we'll trust you on that one -- I don't think anyone else is currently working on l10n/i18n issues
17:14:04 <bero|2> but I might be wrong
17:14:58 <tapwag> bero|2, Well, transifex.com has quite some activity. Let me check on who many people are signed up with our account.
17:16:11 <tapwag> bero|2, Hah! 89 contributors
17:16:45 <tapwag> So there is definetely interest from community side.
17:17:15 <bero|2> can you see how many have been active?
17:17:21 <bero|2> I don't think we even have that many users
17:17:50 <itchka> tapwag: I think we should definately stick to the hosted version of Transiflex our servers are working hard enough they don't need additional load if we can avoid it.
17:18:11 <ashledombos_> hi
17:21:43 <tapwag> bero|2, Take a look: https://www.transifex.com/openmandriva/openmandriva-linux/dashboard/
17:22:33 <tapwag> As far as I am concerned I do a little bit here and there for all kinds of projects.
17:22:50 <tapwag> The last project I did was adding some material to KDE's krita
17:23:16 <itchka> Nice
17:23:21 <tapwag> KDE German team has about a handfull of German contributors
17:23:43 <_TPG> tapwag: who is taking care of updating these translation on these drakx sources ?
17:24:16 <ben79_> Our resident drakx engineer?
17:24:25 <_TPG> i mean it is good that people are doing translations of drakx stuff, but does anyone regenerated these pot files or updated sources with new translations ?
17:24:34 <itchka> I think that is what tapwag is asking?
17:24:46 <tapwag> _TPG, I mainly posted the file a while ago and translations kept coming in. I know you don't approve of drakx
17:25:22 <itchka> and I don't know the answer
17:25:39 <tapwag> But the problem is that we haven't found a process of "harvesting" the material that has come in. At least I didn't manage to synchronize between github.com and transifex.com
17:26:19 <tapwag> _TPG, In short, no they haven't been regenerated.
17:26:51 <bero|2> We'll also have to put in the newer stuff...
17:27:00 <bero|2> e.g. I don't think we currently have om-welcome in transifex
17:27:01 <_TPG> https://github.com/transifex/transifex/issues/261
17:27:05 <itchka> So should this be part of the package build process?
17:27:06 <bero|2> could use some more translations there...
17:27:13 <_TPG> someone created transifex2github script
17:27:34 <bero|2> I wonder if we could just automate it - make abf pull in new translations when a package is built
17:27:35 <tapwag> bero|2, Correct
17:28:23 <tapwag> _TPG, I haven't heard of this script before but I have been absent a long time
17:28:55 <tapwag> I think what we should do is to have our own software to have the best possible l10n.
17:29:08 <jbj> bero:2: automation is very hard … easiest would be use git merge with files shared between abf <-> transifex
17:29:12 <tapwag> Even if it is something "small" like oma-welcome
17:29:17 <_TPG> there is even ruby script https://github.com/transifex/txgh
17:29:21 <_TPG> HisShadow: ^^
17:29:39 <_TPG> that allows to update github with transifex and viceversa
17:30:38 <tapwag> Well, I can write simple bash-scripts and sometimes succeed at reading them but I don't have any Ruby-knowledge. Sorry.
17:32:18 <HisShadow> _TPG: okay
17:32:55 <tapwag> bero|2, I can certainly add files
17:33:32 <tapwag> Shall I get the .po-files from github.com repositories?
17:34:55 <bero|2> sure, where we have them...
17:35:26 <bero|2> I think om-welcome actually uses a different  translation system
17:35:30 <bero|2> but that can and should be fixed
17:36:27 <tapwag> bero|2, Are we still in touch with the original author?
17:36:59 <itchka> bero|2: Re-wrote it in C++
17:37:56 <bero|2> yes, and I didn't touch the data files that make up the content
17:38:11 <tapwag> I like the idea of having several languages supported but this is a processes not all developers are aware of: i18n (internationalization)
17:38:16 <bero|2> the thing I rewrote essentially was just "display a html file"
17:40:02 <tapwag> bero|2, I can certainly translate it for you into German and I am happy to do this but the application would have to accept different languages. That's what i18n is about
17:40:16 <bero|2> I know
17:40:54 <bero|2> I don't remember off the top of my head, but I think what it actually does is open a browser to display the output of a script in /usr/share/om-welcome/LANGUAGENAME/something
17:40:57 <bero|2> but have to check again
17:41:03 <tapwag> bero|2, Just let me know when you need to have stuff translated. I also started a small business about this
17:41:03 <bero|2> there's certainly better ways to do that
17:41:39 <tapwag> Maybe linking this with locale settings?
17:43:24 <tapwag> Anyway, feel free to hand .po files in that you want to have on transifex.com
17:43:40 <tapwag> In business terms this is called crowdsourcing
17:44:29 <itchka> So bero can I put down an action to take a look at om-welcome and advise whether we change it to use the standard method?
17:44:33 <tapwag> Some companies like codeweavers (the company behind wine) rely on this and do not budget for translations
17:44:49 <bero|2> itchka: sure
17:45:38 <tapwag> bero|2, Feel free to email me with the source .po-file. I will be happy to put it on transifex.com
17:46:06 <tapwag> Maybe with oma-welcome we can then test the synchronization process
17:46:09 <itchka> #action bero to examine oma-welcome software and advise on how to standardise it to use  l10n.
17:46:30 <bero|2> good plan
17:46:59 <bero|2> it's probably also time to split that package into the application (which rarely changes) and the content (which ideally changes all the time)
17:48:02 <tapwag> bero|2, Sounds good
17:48:47 <tapwag> Let's produce free software (as in Freedom)
17:50:01 <tapwag> Anyway, I am fine moving to the next item. Thanks for listening
17:50:41 <itchka> Ok well that's some progress. Who will look at the update of GitHub with new files from Transifex. I guess we would need to check whether the various scripts work and also to decide when they are run and how they should be triggered. Either automatically or on some sort of schedule.
17:52:11 <tapwag> I can certainly add .po files, create repositories etc.
17:52:29 <tapwag> And tell the 89 transifex.com contributors about new stuff
17:53:15 <tapwag> But there needs to be some notification mechanism
17:53:36 <tapwag> as I am not really following what is happening on github.com
18:00:35 <tapwag> Just one more thing. Are we still using OpenProject or has this moved to a different platform?
18:00:53 <tapwag> I keep getting "Bad Gateway" on project.openmandriva.org
18:00:55 <itchka> tapwag: GitHub does have a number of notification mechanism's that may able to be used to indicate there are changes.
18:01:29 <tapwag> itchka, You are right "Following" and "Starred" IIRC
18:02:16 <itchka> tapwag: OpenProject is not working at the moment we are debating what we should use as a replacement.
18:03:09 <_TPG> when that "debate" is going to finish ?
18:03:24 <tapwag> itchka, I never got the idea of it but klebedeff pointed out to me what it's about. I like the idea of project management
18:03:26 <_TPG> as for me this more similiar to silence than a debate
18:03:51 <bero|2> indeed...
18:03:53 <tapwag> _TPG, I am done and fine to move to the next item
18:04:17 <tapwag> Maybe we should OpenProject on the next agenda
18:05:03 <tapwag> Or discuss that in Misc.
18:05:12 <_TPG> tapwag: yes we need to finish that topic soon
18:05:16 <itchka> Lets move on to Item 1 i586-i686
18:05:24 <_TPG> or nothing will be done whatsoever
18:05:55 <itchka> bero|2: What was the result of your survey.
18:06:20 <tapwag> _TPG, I wasn't a power user on this platform but I liked the idea. Hope to get it up and running again.
18:07:03 <tapwag> itchka, Yes, let's move on to the next topic
18:07:06 <bero|2> I didn't get to talk to people yet, too many other things on my plate right now (work, preparing for LPC, some OM stuff, messes with someone breaking into my place, ...
18:07:29 <bero|2> But essentially what we thought in the last meeting was that we can drop i586 for good
18:07:41 <bero|2> but we should switch to i686 instead of dropping 32-bit altogether
18:07:59 <bero|2> reason being that with clang 4.0 the generic 32-bit issues are solved and i686 shouldn't be very problematic
18:08:13 <bero|2> and we'll need a number of libraries there anyway to keep stuff like wine and steam running
18:08:45 <bero|2> and there's actually a few i686 boxes that still run OMV quite well and that aren't overly prehistoric (e.g. Acer Aspire One netbooks, released in 2009)
18:09:37 <bero|2> It may also be time to start phasing out i686 isos by e.g. displaying a big fat warning telling people they should really be using the 64bit version when booting the 32-bit image on a 64-bit capable box
18:10:26 <bero|2> i686+SSE2 seems to be a good baseline for what is still reasonable to support
18:10:43 <bero|2> so no more "got to switch back to 387 and make things slower for people with hardware that isn't prehistoric"
18:11:12 <itchka> That's a good idea how would we acheive that. _TPG could a Calamares module do that?
18:11:41 <bero|2> I'd say we just add another check to the checks it already does to see if e.g. there's enough memory
18:12:11 <bero|2> /proc/cpuinfo can tell if the CPU can run 64bit code
18:12:48 <bero|2> on that note, might also be good to ask people to register their box somewhere if we detect a real 32-bit box, so we know how many are actually still in use
18:12:58 <bero|2> but of course we can't do that without asking the user
18:13:21 <_TPG> hmm, why do we really want to keep ix86 ?
18:13:29 <_TPG> except few libraries
18:13:30 <tapwag> I remember trying to install the 64-bit version of openSUSE on my eeePC with 4 GB Hard drive which prompted me right from the start that installation would be impossible.
18:13:43 * ben79_ gotta go, bbl
18:14:04 <_TPG> world is moving towards ARM and second year we are "debating" over ix86
18:14:53 <tapwag> I must say that I liked the computers bero|2 presented in Krakau
18:15:24 <tapwag> but I must admit that I never got round to really using them as my desktop machine
18:15:40 <tapwag> Even though there are good reasons like silence, no fans etc.
18:16:10 <bero|2> _TPG: I used to think dropping it right away would be the best choice, but then actually found some halfway decent and not too ancient hardware that still needs it - mostly those guys https://en.wikipedia.org/wiki/Acer_Aspire_One (Atoms made until 2009), OLPC , Intel Classmate
18:17:18 <_TPG> bero|2: why we do not have such headliners http://phoronix.com/scan.php?page=news_item&px=Fedora-25-Raspberry-Pi ?
18:17:18 <tapwag> bero|2, There was an editorial in German Linux User Magazine where the editor-in-chief also wanted to ship 64-Bit versions on his cover DVDs but switched back
18:17:18 <bero|2> I fully agree that ARM is more important though
18:18:12 <tapwag> I also agree that ARM is probably the way to go
18:18:15 <bero|2> but with clang 4.0 the x86_32 compiler crashes we've run into should be gone anyway, and with the i586->i686 switch, stuff like compiler_rt not supporting the target properly should be gone
18:18:25 <_TPG> i see with my eyes of future article on phoronix, that "OMG ix86 Still supported by OpenMandriva, what a GREAT SUCCESS" !!!
18:18:26 <bero|2> so i686 builds shouldn't be that much extra work
18:19:07 <bero|2> _TPG: I have a Pi 3 -- let's make it happen
18:19:22 <bero|2> (actually I've started on that too, adding the VC4 driver in mesa etc.)
18:19:50 <bero|2> My goal is to have OMV running on all 96boards soonish
18:19:55 <tapwag> Let me put this from a business plan perspective as I have learnt this during my business courses: Where do we come from? Where we want to be? How we are going to get there?
18:19:55 <_TPG> sure, but please notice that we are wasting times on debates rather than doing things
18:20:40 <_TPG> here is a clear issue with decission making, like we are afraid of taking a step forward
18:21:29 <tapwag> _TPG, Maybe we should rebrand ourselves with "Digital Pioneers".
18:22:15 <_TPG> Debate Pioneers hahaha
18:22:35 <tapwag> _TPG, Fedora distribution says "Always leads - never follows" but in some respect we might be better
18:22:59 <bero|2> In many ways we are the real pioneers...
18:23:05 <bero|2> First distribution to use clang as its main compiler
18:23:11 <_TPG> true
18:23:17 <bero|2> even half a year before Android made the switch
18:23:23 <bero|2> and they had far less potential issues
18:23:25 <tapwag> _TPG, I know exactly what you are talking about being afraid about taking a step forward
18:23:41 <_TPG> if we could only get some noise about that clang switch
18:23:49 <tapwag> bero|2, Might be worth putting in Wikipedia to attract some attention
18:24:41 <_TPG> tapwag: feel free to do it
18:24:57 <itchka> Maybe i686/clang 4.0 could be used to our advantage?
18:25:06 <tapwag> _TPG, I wasn't aware of this
18:25:19 <tapwag> _TPG, Until now.
18:25:37 <tapwag> Do we have any references to support that we were first?
18:25:39 <_TPG> btw found this
18:25:40 <_TPG> http://www.ostechnix.com/openmandriva-lx-installation-guide-with-screenshots/
18:26:30 <_TPG> tapwag: our blog, our announcements these are our references, as there are none who uses clang as base compiler on any distro
18:26:51 <_TPG> [20:24] <itchka> Maybe i686/clang 4.0 could be used to our advantage?
18:26:53 <_TPG> ^^^^
18:27:10 <bero|2> FWIW regarding that Fedora Pi announcement, they're cheating -- they run the Pi3 in 32-bit mode even though it's a 64-bit CPU
18:27:14 <_TPG> maybe we should drop everything except ix86 and call it advantage ? Dude ?
18:27:40 <bero|2> so we may have a chance to force ourselves into those news threads by saying we support it properly actually making use of what the CPU can do
18:28:11 <Xu[m]> wow. i came back to a confrontation.
18:28:15 <_TPG> think this way
18:28:25 <_TPG> there are like 16 builders
18:28:59 <_TPG> we now support 4 architectures, so doing simple math, this means we can build 4 packages at a time
18:29:08 <_TPG> and we have like 15k of packages
18:29:41 <tapwag> Xu[m], Welcome back
18:29:53 <_TPG> so dropping ix86 would give us extra time, resources and everything more to rebuild ARM properly
18:30:52 <itchka> That's a good install/review _TPG
18:31:02 <_TPG> fedya: hi, speaking of builders, ji.jbj.org is not responding, can you please fix it ?
18:31:21 * jbj looks
18:31:31 <tapwag> _TPG, Does everyone on OpenMandriva have a suitable platform? I have a RaspberryPi 3 which I never tried
18:32:18 <_TPG> brb testing gtk+3.22.1 with wayland support enabled on 3.0
18:33:32 <klebedeff> *here
18:33:38 <jbj> _TPG: box is up, docker is running
18:37:52 <tapwag> Just one thing that I came across during my smoking break: I understand that ARM is definetely going to have its place but what about things like speech-recognition. Some people actually claim that we live in the Post-PC Era
18:39:00 <tapwag> I mean when we talk about the next couple of years we should take these things into consideration
18:39:38 <tapwag> And Microsoft, in that respect is ahead of Macintosh and mycroft
18:40:26 <tapwag> I was very impressed when I saw my friend talking to Siri saying "I would fancy some Greek food now." and Siri offered him to guide him to the next restaurant
18:40:55 <tapwag> So what are the perspectives of Tower-PC, keyboard, mouse etc. ?
18:42:10 <bero|2> I think keyboards are here to stay for a long time (though their use will probably go down somewhat). It'll be decades if not centuries before we can actually develop stuff by "talking" to a computer
18:42:16 <itchka> We could talk about that one all night tapwag :)
18:42:47 <bero|2> but stuff like that will definitely reduce keyboard and mouse use over time
18:43:03 <bero|2> but there's not that much we can realistically do about that, except keeping an eye on mycroft
18:43:04 <tapwag> No offense to anyone.
18:43:29 <bero|2> we don't have enough developers to seriously get into something like that
18:44:25 <tapwag> bero|2, I once used a Raspberry Pi as my main desktop computer and actually enjoyed the silence of having no fans running.
18:45:07 <bero|2> and we can do much better than a Pi
18:45:08 <bero|2> https://labs.mediatek.com/site/global/developer_tools/mediatek_android/open_platform/index.gsp
18:45:11 <itchka> I am going to have to to had the chair over to someone else as the family need feeding
18:45:25 <bero|2> that should be around 5 times faster
18:45:37 <bero|2> sadly still missing decent storage
18:45:42 <itchka> #chair bero|2
18:45:43 <chwido> Current chairs: Xu[m] bero|2 itchka
18:45:44 <bero|2> but still doesn't require a fan or even a heatsink
18:45:52 <bero|2> and it's 10 cores
18:47:22 <itchka> Please someone take over the chair. Thanks
18:48:31 <tapwag> I am still a fan of the Commodore 64 which is still holding a world-record for selling most units of computers.
18:49:23 <tapwag> Raspberry Pi is aparently also selling quite well.
18:49:55 <tapwag> But as we all know with MacOS the best thing doesn't have to be a bestseller.
18:50:47 <tapwag> Which is a shame
18:51:13 <tapwag> The classic MacOS is what I am talking about
18:52:00 <bero|2> yes, that was amazing for its time, only Atari and Amiga came close then
18:52:05 <bero|2> and all 3 never really took off
18:52:45 <bero|2> but we don't even have to go back in time to see examples of the worst stuff being the best sellers (windows, ubuntu)
18:55:31 <tapwag> bero|2, They all have some kind of following and "disruption" seems to be the way to go..
18:55:38 <tapwag> Unfortunately
18:56:00 <tapwag> Amiga still has its community
18:57:06 <tapwag> So one question would be do we want to disrupt or gather a loyal following. I think klebedeff might be interested in this.
18:57:49 <tapwag> WhatsApp had about 50 employees and they got billions from facebook
18:58:46 <tapwag> Such a small company and yet so important
19:14:44 <_TPG> i've pushed some GTK+ updates from 3.0
19:15:38 <_TPG> seems like gtk-3.0 update produces few glitches in FF and Plasma
19:16:07 <_TPG> i wonder if this is issue of old Qt5 and old Plasma GTK theme support
19:19:01 <bero|2> Does it look better in cooker?
19:19:09 * bero|2 doesn't use and gcrap
19:21:01 <_TPG> i do not have cooker :(
19:26:55 <bero|2> let me install some grap then...
19:27:20 <_TPG> would be nice to get that FF works with Qt5
19:30:26 <bero|2> Seems to work for the most part
19:30:35 <bero|2> but buttons in file dialogs etc. don't have backgrounds
19:30:44 <bero|2> they look like plain text
19:31:01 <bero|2> but buttons in e.g. about:preferences look like buttons
19:31:08 <bero|2> would be nice to have a native Qt build of FF
19:31:22 <bero|2> but they just removed the code again because it never worked and nobody was fixing it
19:31:35 <bero|2> so I think I'll stay with Qupzilla ;)
19:32:08 <bero|2> I wonder what toolkit if any that new rust based mozilla browser uses
19:32:16 <bero|2> that might be another contender to replace FF
19:32:46 * bero|2 downloads
19:44:40 <_TPG> bero|2: seems like FF 49.0 can be compilled with rust
20:35:49 <ashledombos_> _TPG: bero|2 around?
20:35:55 <bero|2> yes
20:36:00 <ashledombos_> hi
20:37:21 <ashledombos_> bero|2: is it possible to progressively split OpenMandrivaAssociation in github i several smaller organization?
20:37:40 <ashledombos_> this is suggested by github team
20:38:05 <ashledombos_> to avoid over crowding organizations
20:38:36 <ashledombos_> for example we could have all kde/plasma stack in OpenMandrivaKDE
20:39:03 <ashledombos_> and for your pleasure OpenMandrivaGNOME
20:39:24 <_TPG> ashledombos_: i do not see benefits of such splitting
20:39:43 <bero|2> Theoretically yes, we'd just need to update all the projects in ABF at the same time
20:40:16 <bero|2> I don't see benefits in it either unless having thousands of projects in one organization reaally messes up github's code
20:40:27 <_TPG> over crowding ? orly ? we are facing this problem ?
20:40:55 <_TPG> i'd really like to see that over crowding
20:41:23 <ashledombos_> yes
20:41:30 <ashledombos_> browsers struggling to render that much data, or the data taking too long to load and causing unicorns to appear
20:41:53 <ashledombos_> Also error 405
20:41:55 <bero|2> might cause problems for people in countries with horrible connectivity
20:42:08 <ashledombos_> and unable to access list of repos in mobile view
20:42:25 <_TPG> ashledombos_: that's not the way you use github repositories
20:43:06 <_TPG> use native git or https://desktop.github.com/
20:43:11 <_TPG> on other platforms
20:44:51 <ashledombos_> mmmh don't forget that many people will access it with browser
20:45:02 <_TPG> "many" ?
20:45:12 <ashledombos_> especially if there are issues managed by github
20:45:14 <ashledombos_> th
20:45:23 <_TPG> how many ? 100 ? 1k ? of people
20:45:33 <ashledombos_> they will not report issues with desktop or command line
20:45:58 <ashledombos_> this is not really the question, I feel you misunderstand the concern
20:46:07 <_TPG> come on we have 26 registered users, 20% of them uses github
20:46:34 <ashledombos_> so no move of issues in github?
20:47:35 <_TPG> ...
20:47:52 <_TPG> this is our main "issues" site https://github.com/OpenMandrivaAssociation/OpenMandrivaLx
20:48:05 <_TPG> all kind of issues will be registered here
20:48:09 <_TPG> not per project
20:49:35 <_TPG> ashledombos_: same idea as it can be seen here https://github.com/ValveSoftware/steam-for-linux
20:50:08 <_TPG> so everybody fills bugs in one place, and by using some kanban board you are managing bugs, features roadmaps etc
20:50:20 <ashledombos_> https://github.com/ValveSoftware/the_lab_renderer they have issues in other places
20:50:56 <_TPG> and we do not want to have this
20:51:15 <_TPG> one site on github to gather all issues, and to manage them
20:51:32 <_TPG> what is wrong with having things like this way ?
20:51:44 <ashledombos_> the fact is that having almost 20000 repos is far above what github team told me as «good practise limits»
20:52:16 <_TPG> there are project with more repos than we
20:52:47 <_TPG> if you like we can delete 50% of our repos on github because someone says so
20:54:17 <ashledombos_> delete?
20:54:28 <_TPG> flow is simple
20:55:27 <_TPG> users goes to www.openmandriva.org, they see link "Fill bugs, ideas etc" -> they got redirected to https://github.com/OpenMandrivaAssociation/OpenMandrivaLx/issues/new
20:55:45 <ashledombos_> I told about splitting in more repos, and furthermore this could help having a better classification
20:55:56 <_TPG> and its like "hey i know github" and they fill ideas what they need
20:56:21 <_TPG> what are the benefits of such classification ?
20:57:02 <ashledombos_> to have browseable organization
20:57:16 <ashledombos_> in all meanings
20:57:24 <_TPG> through abf you can browse all projects
20:58:31 <_TPG> ABF is such a place to "tag" github projects as a part of something bigger
20:58:58 <_TPG> like ABF should keep infor that x, y, z, foo, baa packages are part of KDE
20:59:06 <ashledombos_> to avoid quirks such as error 405 when you accept invitation
20:59:29 <_TPG> github is simple git service, keep it as it is
21:01:11 <_TPG> i'm using our github repos on daily basis, and never seen any 405 or any unicorn
21:02:11 <ashledombos_> i can send you screenshots, also caf Xu[m] and itchka
21:03:14 <ashledombos_> quoting Alex Sese from github team «If you are planning to have more than 1000 repositories, please try and group them together in separate organisations to help keep the number of repositories within a single organisation under good practise limits.»
21:03:49 <ashledombos_> as it's easy to do this in ABF, I don' see any reason not to do this
21:04:00 <ashledombos_> apart it's long
21:04:11 <ashledombos_> then should be done progressively
21:05:26 <_TPG> please tell them they thould start to use git or abf-c-c rather than browse github
21:05:55 <_TPG> ABF is the place where all "features" should go
21:06:03 <ashledombos_> tell who?
21:07:09 <_TPG> those who are using github just to browse repositories
21:09:19 <ashledombos_> so what while i understand they may not good enough pros such as having a repo display working and following github team advice for also being able to accept invitation in this org without 405, what are the reasons that are in favour of keeping this organization as is?
21:12:35 <_TPG> i have a brilliant idea, those who have unicorn issues or whatever, should set up a git repository on a dedicated server, take care of migration all OMA github repos to dedicated github server, and finally connect ABF there, and shut down our github repost
21:12:38 <_TPG> repos
21:13:40 <_TPG> then nobody will whine, and ofcourse i586 will be supported even all developers will be gone
21:14:20 <ashledombos_> It's indeed a good idea. but need the correct hooks. a little more complex.
21:15:01 <_TPG> great
21:15:21 <ashledombos_> but i guess you were ironic :)
21:15:27 <_TPG> hell no :p
21:16:28 <ashledombos_> anyway i understand you don't really care this part, but i think this may improve situation with almost no counterpart
21:16:40 <ashledombos_> unless i miss an important counterpart
21:16:45 <_TPG> it will not improve anything
21:16:50 <_TPG> it will bring more mess
21:17:10 <ashledombos_> this is not what github guy Alex told me
21:17:30 <_TPG> think about OMA, not github
21:17:31 <ashledombos_> not the mess, but the improve part.
21:17:56 <_TPG> look, our main development environment is ABF
21:18:07 <_TPG> github is just only a backend service
21:18:34 <_TPG> all improvements, ideas, etc should be taken care by ABF modifications
21:18:42 <ashledombos_> not only, if we migrate «issues» there
21:18:46 <ashledombos_> or
21:19:07 <ashledombos_> we put the issue page in «OpenMandrivaSoftware»
21:19:22 <ashledombos_> where we don't have such problems
21:19:29 <_TPG> users want to have one place when they can easily fill a bug or contact with us
21:19:42 <_TPG> they will not browse our github
21:19:45 <_TPG> repos
21:20:19 <_TPG> Dear user, wanna fill bug report or contact us? Click here -> https://github.com/OpenMandrivaAssociation/OpenMandrivaLx/issues/new
21:20:22 <_TPG> and voila
21:20:42 <_TPG> they fill bug there and that's all
21:21:23 <ashledombos_> still error 405
21:21:34 <_TPG> works fine here
21:21:39 <ashledombos_> so for example i can't manage anymore issues
21:21:58 <ashledombos_> i even can access management of OpenMandrivaAssociation
21:22:15 <_TPG> look, github works fine here for me now
21:22:20 <ashledombos_> because error 405
21:22:29 <ashledombos_> you're already manager
21:22:34 <_TPG> i can access all the projects, options whatever
21:22:46 <_TPG> i do not see aby unicorns or 405
21:22:59 <ashledombos_> https://lut.im/hllGBHLDDL/3z1hDJggzIbRj1dR.PNG
21:23:42 <_TPG> maybe github nodes in France have some issues
21:25:11 <_TPG> anyways what happened to rolling release model ?
21:25:16 <_TPG> nobody cares ?
21:25:28 <_TPG> keeping i586 is still more important
21:26:25 <ashledombos_> https://lut.im/gallery#sxEDOh1Ur3/b8BFsn8S3iYqiCSu.png,AsXsfENfAC/8tJjMvALYuvn0sss.png,zidNFnlbe1/HL7XofRaKoBnwKyX.png
21:27:05 <ashledombos_> mmh this is exactly why we insist in moving issues to github in good condition
21:27:26 <_TPG> ashledombos_: are you behind a proxy ?
21:28:49 <ashledombos_> no
21:28:58 <ashledombos_> i tried from several places
21:29:31 <ashledombos_> it takes a long time to load something then 405
21:29:50 <ashledombos_> Alex guy told me «too much repos, reduce it will work»
21:30:00 <ashledombos_> all i can say
21:31:03 <_TPG> doubt that invitation have something related with taking care of invitation
21:31:13 <ashledombos_> i don't know if hie lied, i did not ask this way
21:31:19 <_TPG> i've re-send invitation to you
21:31:36 <_TPG> i'll send you also to OMA Software
21:31:38 <ashledombos_> ok
21:32:27 <_TPG> you are already in OMA Software organization
21:32:33 <_TPG> anyways check your mail
21:32:47 <ashledombos_> oma software i know
21:35:18 <_TPG> bbl
21:35:24 <ashledombos_> nothing appears, I don't see your invitation even in emails only avokhmin
21:37:43 <ashledombos_> bero|2: so to resume, it's not for having benefits, it's for reducing, also if possible suppressing issues.
21:39:26 <ben79_> We don't have many developers but they are @ #openmandriva-cooker. Mainly TPG, bero, itchka, and chrisb.
21:42:10 <ashledombos_> did i muss a discussion about i586? I just remember a discussion days ago but don't see what tpg mentions exactly
21:44:23 <itchka> back
21:44:37 <itchka> Reading back
21:52:39 <ashledombos_> [23:25] <_TPG> anyways what happened to rolling release model ? <- was not there at least two meetings focusing on this and talking about, besides other, Kahinah?
21:55:53 <itchka> ashledombos_: bero proposed that we keep 32bit but move to i686 which is now fully supported by Clang 4.0. TPG did not agree but I have not yet had the chance to reason this through with everyone. As i see it the rolling release proposal if we can get the abf changes done to allow us to implement it has an inbuilt mechanism for a phased removal of 32bit support. If I understood the proposal properly we would
21:55:54 <itchka> still support i586 for a further two years as it goes through to legacy.
21:58:01 <itchka> Obviously this does depend on how often we maker a major release.
21:59:27 <ashledombos_> ok let's do this then :)
21:59:51 <ashledombos_> it seems to be the better solution, and sustainable, right?
22:00:33 <itchka> Alexey is currently looking at the Kahinah implementation for abf once we have this working we can look at some of the other aspects.
22:02:14 <ashledombos_> perfect, thanks to him :)
22:04:43 <ashledombos_> re OpenMandrivaAssociation, I maintain it's not usable as is as a place for putting a github issues page. Or we fix it, or we use OpenMandrivaSoftware or we find another solution…
22:04:54 <itchka> One of the things we need to look at in the rolling release scenario is actually when we make a point release. The model proposal implies that there will be release points but what criteria to apply to determine a release point has not been stated.
22:05:44 <ashledombos_> ideally a release point should be as much as possible usable without internet connection
22:06:19 <ashledombos_> ie not needing important updates for fixing important bugs
22:06:34 <itchka> To be fair Raph you were trying to access it using a  mobile phone.. Are there many people who would want to go throught the pain of filing a bug on a mobile.
22:08:41 <itchka> It's only the mobile interface that's broken desktops work fine. The mobile app is bugged or has inappropriate timeouts.
22:10:39 <itchka> That's a good idea for a release criteria. Zero updates that will be tough with a rolling release.
22:12:54 <ashledombos_> to be fair, this is not something i can consider a good quality acceptance («who nowadays use a mobile/tablet to write a bug or explore github, let's be serious») when it's so easy to have a better solution
22:13:09 <ashledombos_> without counting the error 405 and long loads when bandwith is low
22:13:59 <ashledombos_> it's simply having the issue page in OpenMandrivaSoftware rather than in OpenMandrivaAssociation
22:15:56 <ashledombos_> (and personnaly I do half things in mobile phone, including checking forums, roplying and visiting github, it's also in my most visited sites in my phone)
22:15:59 <itchka> Either way I don't think GitHub is the place for issues anyway it's far too inflexible and basic.
22:17:01 <ashledombos_> me neither, but i thought it was because we could take the advantage of issues assignation to a specific repo
22:18:01 <ashledombos_> in such conditions, I think it's wiser to keep issues separate from github
22:22:09 <itchka> I think a proper analysis of the pros and cons of both methods needs to be created as I don't believe anyone has thought the whole thing through yet irrespective of whether GitHubs mobile app is broken or not.
22:23:10 <itchka> ashledombos_: I must go to bed as I have to up early tomorrow.
22:23:16 <itchka> #endmeeting