14:30:17 <_TPG> #startmeeting
14:30:17 <chwido> Meeting started Tue Dec 17 14:30:17 2013 UTC.  The chair is _TPG. Information about MeetBot at https://wiki.openmandriva.org/om/en/MeetBot.
14:30:17 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:30:29 <n3npq_> otherwise have hero decide and let me know what was decided.
14:30:42 <_TPG> #topic 2014.0 Specifications
14:31:16 <_TPG> arisel, ashledombos benatto bero crisb fedya|2 itchka n3npq_ pcpa Pulfer Solbu Wayne_Sallee Xu|Mobile
14:31:42 <_TPG> Hello, TC meeting srated few seconds ago
14:32:08 <_TPG> we are 2 days after the feature freeze deadline
14:32:11 <pcpa> pong
14:32:37 <_TPG> i'd like to finish and fix specifications list for 2014.0 release
14:32:42 <ashledombos> quack
14:32:45 <_TPG> #link https://wiki.openmandriva.org/en/2014.0/Specifications
14:32:52 <itchka> Sounds good to me
14:33:06 <_TPG> looks like few ideas were added since last meeting
14:33:17 <_TPG> anyways let's continue
14:33:48 <itchka> What's the next item?
14:33:53 <_TPG> last topic was ISO build
14:34:17 <itchka> rescue system?
14:34:35 <_TPG> 4. Provide original Rescue System
14:34:37 <_TPG> 5. Support for locallly built isos with a chroot the allows updating rather than reloading
14:34:43 <_TPG> 6. Add by default all repositories (for 64bit add 32bit main repos)
14:35:29 <itchka> _TPG: My last tests with omcc seemed to indicate that this alredy works
14:35:51 <itchka> Item ^ I mean
14:35:54 <itchka> 6
14:36:18 <_TPG> itchka, by default after installation you have configured all repos ?
14:36:33 <_TPG> even 32bit on 64bit machine ?
14:37:22 <itchka> Ah I see you mean pre-installed. I'm talking about using the add buttom in repo setup
14:37:36 <_TPG> ...
14:37:39 <_TPG> :D
14:39:09 <itchka> If you use the add button it first installs the update repos and then on the second go it adds 32 and 64nit repos on a 64bit machine.
14:40:02 <_TPG> anyways repos are nor pre-installed
14:40:17 <Xu|Mobile> Sorry, I'm idling. Got a train to catch and a hope that the snowstorm won't impede travel
14:40:27 <itchka> No
14:40:29 * Xu|Mobile will respond if explicitly pinged. Probably.
14:42:25 <itchka> Anyone for offering the original rescue system on the DVD or is it too cloesly tied into the old installer?
14:43:11 <_TPG> anyone interested on this meeting ?
14:43:17 <_TPG> arisel, ashledombos benatto bero crisb fedya|2 itchka n3npq_ pcpa Pulfer Solbu Wayne_Sallee Xu|Mobile
14:44:10 <_TPG> if not then i'll remove from specs all not discussed specifications
14:44:24 <_TPG> we can not discusse them forever
14:44:36 <Wayne_Sallee> I'm here because I opened the chat software to go to mate-dev
14:44:52 <itchka> _TPG: before you do there is one that I would like to air.
14:45:09 <pcpa> right now I have mostly interest in the #java option, and maybe make it "unofficial"
14:45:09 <Wayne_Sallee> I didn't realize that mate was built in cooker.
14:46:44 <Wayne_Sallee> I have several channels set to automatically open when the software starts. :-)
14:47:53 <itchka> It's been suggested that a memebr of the TC approach the Virtual Box admins with a view to building OpenMandriva rpms this could give use some good advertising as well as always having up to date pakages availble to users.
14:48:37 <crisb> sorry i'm here now
14:51:29 <_TPG> anyone wants to discuss ISO Build topics ?
14:51:42 <_TPG> if no then i'll NO GO them
14:53:31 <itchka> Sad; locally built isos could save alot of QA time lets hope it get included in the iso tool cleanup; not to drop too bigger hint.
14:55:00 <pcpa> unless you have less than 1Mb download, or a really fast computer, building isos in abf, and downloading them is a lot faster in my experience with oem/conectiva
14:55:48 <pcpa> fast computer I mean, ide disks are too slow, just need a local repo mirror
14:56:20 <itchka> That depends how it's done. It.s slow the first time but if youonly update the local chroot it's much faster subsequently
14:56:51 <itchka> Especially when ABF is heavily loaded...
14:56:58 <pcpa> that is how I did it, still would take like 4 hours in my pc to generate an iso, and 10 min in abf
14:57:48 <pcpa> the problem is i/o, if you can do all the i/o in ssd then it would be better locally I agree
14:58:45 <itchka> Well I have an 8 core server and a 240Gig ssd so it would ceratinly be faster for me!
14:58:48 <pcpa> but I think the issue is being able to do it, so I am going off topic :-)
14:59:27 <itchka> I hope provision can be made anyways.
14:59:45 <crisb> it's already possible now isnt it?
15:00:33 <n3npq_> pcpa: there are 3 dual 4 core blades here. one runs 2011.0 occasionally used by mdawkins, the other runs Marathon (because last OS I installed), the 3rd is my devel box running C6 … avail for the asking
15:00:53 <pcpa> this is an example, easy to use for local generation or abf generation: https://abf.rosalinux.ru/oem/build_kde4_desktop - generates a live installer...
15:01:16 <_TPG> 4. Provide original Rescue System
15:01:20 <itchka> No not really because verytime you build you have to download every rpm for the distro each time you build an iso. Thats just impractical when you have only a 1MB connection
15:01:30 <_TPG> is there anyone who whould like to take a lead in topic Provide original Rescue System
15:01:49 <n3npq_> I can/will set up an rdist mirror to minimize dl time. I can also do a mirror (w 10Gbps backbone access) @pmman if asked
15:02:25 <fedya|2> i'm here
15:02:42 <_TPG> ok i need to switch to my mobile
15:02:46 <_TPG> brb
15:03:53 <itchka> The original rescue system was really useful as far as I know it was sel-contained and would only require an extra entry in the grub2 menu
15:04:00 <itchka> sel=self
15:05:04 <itchka> The only downside is that it used grub rather than grub2 so some work would have to be done.
15:05:36 <itchka> uefi would also be an issue.
15:06:39 <itchka> It could be turned into a quick and easy tool to aid development of uefi which we still don'y have working.
15:06:57 <itchka> Is that enough to chew on?
15:15:41 <itchka> No takers ah well;  next time maybe.
15:16:46 <pcpa> we need some specialized positions, e.g. installer is not something trivial, but once one gets it going things flow, just that needs a lot of time to work on it
15:17:18 <ashledombos> _TPG, itchka : you need my participation? sorry as these latest days i was focusing on administrative and infra, i did not take time for dev side
15:20:28 <itchka> ashledombus: No worries; I guess you need to be informed but you can read the log for that.
15:22:39 <itchka> pcpa: I understand; it's not a problem but if these ideas don't get aired then they perhaps don't get borne in mind when the installer is written
15:24:06 <itchka> pcpa: and having thought it through a bit it's alot more work than I initially had in mind when I suggested the idea.
15:24:11 <ashledombos> _TPG: itchka but how are things moving? is there lack of participation? do you feel over-charged or not enough helped?
15:29:21 <bero> back, sorry, currently extremely busy and on the road a lot
15:30:19 <bero> TBH I think all the ISO build bits should go into the rewrite, not much of a point in providing band-aid for stuff that is going away anyway
15:30:27 <itchka> ashledombus: We rumble on...
15:30:51 <bero> But given the iso build bits will likely actually be done for 2014, there's a good chance we can get the rescue bits etc. in because they'll be supported in the new system
15:31:28 <itchka> bero: I salute you!!
15:34:02 <itchka> _TPG: Are you there?
15:35:27 <_TPG> Yes i'm here
15:36:23 <itchka> I think we can continue with Build System
15:37:31 <itchka> I would like to withdraw items 2 and 3 since we are making some progress on those anyway.
15:39:46 <_TPG> ok
15:39:51 <_TPG> so let's continue
15:40:05 <itchka> :)
15:42:46 <_TPG> 4. Provide original Rescue System
15:42:48 <_TPG> NO GO
15:42:52 <_TPG> ?
15:43:41 <itchka> see beros contribution I think it's a go but it wouldn't be the original rescue system
15:44:00 <itchka> TBH I think all the ISO build bits should go into the rewrite, not much of a point in providing band-aid for stuff that is going away anyway
15:44:32 <itchka> this was from bero perhaps you missed it because your connection kept dropping
15:44:51 <_TPG> itchka: Colin i saw these
15:45:16 <_TPG> but we need a decision and someone who will be resposnible for this
15:45:32 <itchka> bero: ping
15:45:54 <bero> _TPG: I think we can just remove the point because it'll just go along with the build tool rewrite
15:46:00 <bero> _TPG: But feel free to list me
15:46:10 <_TPG> ok :)
15:46:41 <_TPG> second point
15:46:42 <_TPG> 5. Support for locallly built isos with a chroot the allows updating rather than reloading
15:46:43 <itchka> It will serve as a useful reminder:)
15:46:59 <bero> Goes along with the build tool rewrite as well
15:47:15 <_TPG> bero: so you again then ?
15:47:19 <bero> So IMO no in terms of fixing the current scripts, but yes as a feature for the new ones
15:47:36 <_TPG> so next one
15:47:38 <_TPG> 6. Add by default all repositories (for 64bit add 32bit main repos)
15:48:10 <bero> Should definitely do that... Right now having to use a setup tool before running urpmi --auto-update is weird
15:49:38 <pcpa> personally I do not like that, it only benefits non free software usage
15:50:31 <bero> pcpa: I think the idea is just to have urpmi working out of the box (both 64 and 32bit main and contrib enabled)?
15:50:57 <bero> Not all that sure whether or not we should include non-free by default
15:50:58 <pcpa> I understood enabling 32 bit on 64 bit, otherwise, urpmi enabled is required
15:52:26 <_TPG> yes idea is to have a working urpmi out of box
15:53:05 <_TPG> imagine a luser who just installed omv
15:53:29 <pcpa> for updates this is a must
15:53:40 <_TPG> how he is able t install something when he was living all the past time in wndows world?
15:55:49 <itchka> If you have the OM update too installed does it not prompt you to install the update repos. So if the repos are preinstalled you will get automatic updates as soon as the user logs in which will alert /him/her to the update system
15:56:02 <itchka> s/too/tool
15:56:50 <itchka> This seems very "new user" friendly.
15:58:04 <_TPG> bero: ?
15:58:36 <bero> That's the idea -- repos preinstalled so people get automatic update notifications right away...
15:58:38 <itchka> The only problem I can see with this is if $MIRRORS is not properly maintained which then results in a the user getting a really bad impression.
15:59:07 <_TPG> bero: YES
15:59:16 <_TPG> sorry capslock
15:59:58 <bero> also goes with new build scripts
16:00:11 <_TPG> ok
16:00:14 <bero> We actually had something for this in ks.template, but never figured out why it didn't make it to the actual isos
16:00:27 <_TPG> yes i remeber that
16:00:50 <_TPG> it was something related to media.cfg being rewritten
16:01:40 <_TPG> so moving to next topic
16:01:44 <_TPG> #topic Mirrors
16:02:02 <_TPG> there were no ideas related to mirrors system
16:02:27 <_TPG> let's skip it then
16:02:46 <_TPG> #topic Build System
16:02:54 <_TPG> 1. Institute automated interface for Bugzilla to release updates by voting
16:03:04 <_TPG> 2. Better support to allow the finding and grouping of "Publish to QA" Packages
16:03:13 <_TPG> 3.  Use ABF's maintainers db with OMV bugzilla to auto assign bugs to maintainers
16:03:19 <_TPG> 4.  Add aarch64 support to ABF
16:03:26 <_TPG> 5.  Merge main and contrib. Good enough to start if adding contrib repositories to build and test of packages in main.
16:04:12 <_TPG> itchka: no.1 qa bot does this ?
16:04:39 <itchka> _TPG: I'll withdraw 1 and 2 they are being actioned by QA specifically Robert who ahs written a nice tool and n3npq and myself who are discussing testing
16:04:58 <itchka> Please go on to item3
16:05:18 <_TPG> itchka: so let's assign 1 and 2 to QA team
16:05:26 <_TPG> just to keep a track for this
16:05:50 <itchka> Ye I'm happy with that
16:05:58 <_TPG> good then
16:06:02 <_TPG> 3rd
16:06:37 <_TPG> simply bugs should be auto-assigned to person from abf's maintainers db
16:07:50 <_TPG> any opinions on this ?
16:08:14 <itchka> _TPG: You'll have to help me here. Won't this mean that we will be assigning bugs to ROSA maintainers and if our code is different in some way will this not have the potential to breal things
16:08:34 <_TPG> itchka: no
16:08:58 <_TPG> itchka: all repository have own maintainers db
16:09:48 <_TPG> so if someone assign bug to cooker then e-mail will be send to a maintainer definied in abf's cooker maintainers db
16:10:13 <bero> We just need to fix the maintainer db then
16:10:19 <bero> It doesn't reflect reality at all
16:11:14 <_TPG> bero: true
16:11:38 <_TPG> bero: 99% of packages are owned by vsharshov@gmail.com
16:11:51 <itchka> Ok thanks for the explanation. Is this db up to date. I'd hate start hassling people from a  Qa standpoint to get important  things fixed if I'm talking to someone who is no longer a contrubuter. I'd be mighty unpopular pretty quickly
16:12:17 <bero> And we should auto-add a Cc to a mailing list because no maintainer can be expected to be around all the time
16:12:31 <_TPG> itchka: like bero said this db needs to be cleaned up
16:12:35 <bero> itchka: The db isn't even close to reality
16:12:38 <itchka> ah missed all this while typing
16:13:03 <_TPG> well i own packages which i'm maintaining
16:13:27 <itchka> This is a big issue
16:13:48 <bero> I own maybe 1 or 2 packages, but in reality am maintaining 200+
16:13:48 <_TPG> itchka: this is lazyness
16:14:58 <itchka> _TPG: How do we sort it out I don't mind helping if there is anything productive I can do
16:15:34 <bero> IMO throw away all but the last 10 builds and whoever did most of those owns the package initially -- that should come a lot closer to reality
16:16:04 <_TPG> imho this is Q&A task for 2015
16:16:14 <itchka> For me it's very difficult I don't like asking people to fix bugs but if we don't keep the list under control it will just escape and we'll nver catch up.
16:17:20 <itchka> _TPG: I agree but what do we do in the meantime. I suppose look up the last person who built the package
16:17:25 <_TPG> bero: seems good idea
16:19:08 <_TPG> itchka: are you fine to assign this task to Q&A ?
16:19:23 <itchka> _TPG: This is an ongoing task put it down to QA and I'll make a start on it: I would also suggest that it is a permanent item on the cooker agenda because there are going to be lots of issues of that I am sure.
16:20:28 <_TPG> ok
16:20:34 <pcpa> I imported 5+ packages last week, they all are automatically assigned to warpc. a good start would be to assign to whoever imported it...
16:21:08 <_TPG> pcpa: can you fill a bug on abf ?
16:21:18 <_TPG> so next topic ?
16:22:03 <_TPG> #topic Add aarch64 support to ABF
16:22:06 <itchka> bero: Could I have some assurance from the dev team that they will address at least some of the current bugs 2013. it would really be very helpful:)
16:22:22 <_TPG> fedya|2: ping
16:22:27 <fedya|2> _TPG: pong
16:22:37 <fedya|2> _TPG: in progress
16:22:47 <fedya|2> _TPG: https://docs.google.com/spreadsheet/ccc?key=0AnBVe7J_2qGZdHhGei1jLXdqbDliOGRfRV81eTZVbWc#gid=0 status page
16:22:56 <_TPG> will it be ready for 2014.0 release
16:23:12 <bero> _TPG: Addition to ABF is happening, but I doubt we should provide packages for 2014.0, given the CPUs don't even exist yet
16:23:44 <bero> itchka: We will, but given our lack of manpower, we can't pay as much attention to backporting fixes to 2013 as you'd probably like us to
16:23:49 <fedya|2> _TPG: if bero could give me an access to aarch64 board, it possible to release aarch64 as development release
16:24:10 <bero> There is no such thing as an aarch64 board yet
16:24:29 <bero> Even ARM itself is testing stuff in the emulator
16:24:49 <_TPG> hmm interesting
16:25:19 <_TPG> i'm for removing this from specifications list
16:25:22 <itchka> bero: Thanks. I'll publish a prioritised list on cooker ml.
16:25:27 <fedya|2> _TPG:  I do everything that depends on me
16:25:41 <_TPG> fedya|2: i know :)
16:26:09 <fedya|2> _TPG: I strongly advise against removing from Features of 2014
16:26:30 <_TPG> fedya|2: but as bero said there is no board to even run this
16:26:58 <pcpa> _TPG: made a request to @abf-support (afaik the best place to request abf features or report bugs/problems)
16:26:58 <fedya|2> _TPG: it's really COOL feature, that helps us to go far ahead from Mageia
16:27:13 <bero> I'll do what I can, but realistically I don't expect us to have access to the hardware before May
16:27:35 <_TPG> fedya|2: you convinced me :p
16:27:46 <bero> We'll still beat Mageia if we have it ready for 2015.0 probably
16:27:59 <fedya|2> _TPG: well mageia does not have an ARM port
16:28:02 <_TPG> so let's keep this
16:28:07 <_TPG> and move to next topic
16:28:13 <bero> Maybe we should leave it there with a couple of question marks
16:28:31 <bero> shouldn't include it in the release unless we have access to a board by then
16:28:34 <bero> But if we do...
16:28:38 <fedya|2> - arm port
16:28:38 <fedya|2> - arm build cluster
16:28:38 <fedya|2> - arm pkgsubmit.mageia section
16:28:49 <pcpa> fedya|2: they have unnoficial armv5 port, but that probably is dead now, was from mandriva anyway, armv5 and mips o32 port
16:29:08 <fedya|2> pcpa: yes i know about armv5 port based on mandriva 2009-2010
16:29:30 <fedya|2> pcpa: in fact it's dead
16:29:34 <_TPG> bero: i think we can decide on further TC meeting whether we want to go publish this aarch64 as a feature
16:30:07 <_TPG> 5. Merge main and contrib. Good enough to start if adding contrib repositories to build and test of packages in main
16:30:18 <_TPG> i'm for -1 for this
16:30:26 <_TPG> at least for 2014.0
16:30:45 <fedya|2> -1
16:31:10 <itchka> I'm neutral I can't judge this
16:31:12 <bero> -1
16:31:21 <pcpa> do not make it an official statement, just have information somewhere o people know we are working on this
16:31:25 <bero> I think it's a really bad idea to do this ever
16:31:55 <_TPG> so NO GO
16:31:56 <itchka> Contrib is very broken still isn't it?
16:32:02 <_TPG> itchka: badly
16:32:11 <_TPG> due to lack of manpower
16:32:31 <itchka> NO GO then
16:32:39 <bero> itchka: Depends on what part of it, but overall yes, and we need the freedom to keep it that way. We need to focus on packages that are actually relevant before we can fix issues with stuff nobody cares about
16:32:39 <_TPG> moving to next topic
16:32:52 <_TPG> #topic End user orientation
16:33:00 <_TPG> 1. Provide a simple "HOWTO" explaining in easy way how submit bugs and provide useable information
16:33:09 <_TPG> 2.  Add on KDE desktop activators to OMV site, google services (maps, translate etc.)
16:33:19 <_TPG> 3.  Add to the release notes a list of major features that are not yet provided (eg for 2013: UEFI, installation of grub2 on root partition, ...)
16:33:27 <_TPG> 4.  Provide a welcome screen (like mint-welcome or mageia-welcome)
16:33:34 <_TPG> 5.  Provide some desktop settings on that welcome screen (e.g. "Make it act more like Windows"/"Make it act more like OSX" for people converting from those
16:33:41 <_TPG> 6.  Talk to VirtualBox admins about building rpms for OpenMandriva they are building Mandriva ones at the moment. This would get our name seen.
16:34:03 <_TPG> 1. never found enything on omv related site
16:34:19 <_TPG> well we can use old mdv articles and convert them
16:35:07 <bero> task to pass on to workshop?
16:36:08 <_TPG> there is a page  "First Time User"
16:36:12 <_TPG> but it is empty
16:36:15 <_TPG> yes workshop task
16:36:34 <itchka> I think workshop with QA input
16:36:56 <_TPG> good point
16:37:02 <_TPG> so next is @
16:37:03 <_TPG> 2
16:37:20 <_TPG> our desktop is quite empty
16:37:50 <itchka> doesn't this sort of tie in with 5
16:38:31 * bero thinks we shouldn't help the privacy violators at Google by integrating their stuff into the default desktop... Making it available, of course.
16:39:20 <bero> just not install by default
16:39:57 <itchka> Thats where 5 comes in just add Googly type desktop
16:41:23 <_TPG> itchka: seems yes
16:44:28 <bero> yes, makes sense if we can get 5 done on time
16:44:43 <_TPG> so merging with 5
16:45:27 <_TPG> next is 4
16:45:45 <_TPG> i think this is for workshop and Q&A
16:46:12 <itchka> I agree I'm already woking on this with Robert
16:46:46 <_TPG> :)
16:46:52 <_TPG> next is 5
16:46:57 <itchka> we will also add a workaround section
16:47:10 <_TPG> who will take responsibility for 5
16:48:27 <itchka> _TPG: What is 5 now
16:48:48 <bero> I'd like to do it, but I'm not sure we should be doing it for 2014.0 (given it'll probably need a rewrite for KDE5 afterwards)
16:49:31 <_TPG> let's postpone this to 2015
16:49:56 <crisb> i think so too
16:50:49 <itchka> agrres
16:51:58 <itchka> _TPG: Did we cover welcome screen?
16:52:05 <_TPG> itchka: no
16:52:09 <_TPG> i just missed this
16:52:36 <_TPG> 4.  Provide a welcome screen (like mint-welcome or mageia-welcome)
16:52:47 <itchka> thatls ok then I'm not going barmy!!
16:52:50 <_TPG> never have seen these
16:53:13 <_TPG> so i do not know is this a desireable feature and worth to fight for
16:54:05 <itchka> If I recall Mandriva versions basically opened with Mandriva home which was the entry website.
16:54:42 <itchka> I think this is infra or workshop
16:55:07 <itchka> entry website=landing page
16:56:02 <bero> true
16:56:37 <itchka> It's simple and effective
16:56:57 <_TPG> ok
16:57:04 <_TPG> so moving to next ?
16:57:24 <itchka> yes
16:57:25 <_TPG> 6. Talk to VirtualBox admins about building rpms for OpenMandriva they are building Mandriva ones at the moment. This would get our name seen.
16:57:34 <_TPG> who will talk to them ?
16:57:54 <itchka> A member of TC would carry most weight
16:58:34 <itchka> Probably needs to be a German speaker to get the best result
17:00:50 <bero> which leaves arisel and me
17:01:20 <itchka> ariel: ping
17:01:25 <itchka> arisel:pin
17:01:34 <itchka> grrr
17:01:39 <itchka> arisel:ping
17:02:47 <arisel> ...
17:03:24 <itchka> arisel: would you be prepared to Talk to VirtualBox admins about building rpms for OpenMandriva they are building Mandriva ones at the moment. This would get our name seen
17:04:01 <arisel> itchka: sure, can try :)
17:04:22 <itchka> arisel: Thank you :)
17:04:29 <_TPG> good
17:04:41 <_TPG> !bite arisel
17:04:42 * chwido thinks about biting arisel but decides to not to.
17:05:30 <_TPG> moving to next topic
17:05:32 <_TPG> #topic Server
17:05:40 <_TPG> 1.Switch from MySQL to MariaDB
17:05:50 <_TPG> 2.Add Galera support
17:05:55 <_TPG> 3.Better SOGo integration
17:05:58 <itchka> I support this MariaDB is open source
17:06:23 * bero too
17:06:25 <_TPG> -1 for all from my side unless someone will be assigned and do this for 100%
17:06:41 <bero> MySQL is Open Source too, but MariaDB is where the community is headed
17:07:04 <bero> Feel free to assign me, I have to do it on my server anyway
17:08:21 <_TPG> bero: on all three of them ?
17:08:59 <bero> yes, I have to get it up on my server anyway, promised it to a hosting customer
17:10:30 <_TPG> bero: thanks then
17:10:55 <itchka> bero: soGo looks good. Thanks bero
17:11:15 <_TPG> moving to next not discussed specs
17:11:30 <_TPG> #topic Kernel and hardware support
17:11:40 <_TPG> 3. Add support for SQUASHFS_MULTI_DECOMPRESSOR (http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/01675.html)
17:13:20 <_TPG> this should be in kernel 3.14 or 3.15
17:13:36 <_TPG> but it would be worth to try with older kernels
17:15:13 <itchka> so if I understand this it's a parallell decompressor for squashfs. Might it affect responsivness on some machines with lowish resources?
17:15:29 <_TPG> itchka: no it only works on multicore
17:16:29 <itchka> _TPG: would we need two diffeent kernels then one for multi-proc and one for uni
17:16:37 <_TPG> itchka: no
17:16:51 <itchka> ok seems good then
17:17:22 <_TPG> patch checks for MAX_DECOMPRESSOR
17:17:30 <_TPG> and multiplies it by 2
17:17:44 <itchka> I guess we should talk to nicco then?
17:17:52 <_TPG> so if you have one cpu then it looks like this MAX_DECOMPRESSOR = 1*2
17:18:19 <_TPG> itchka: seems so
17:18:20 <itchka> That's neat
17:18:47 <_TPG> bero: are you fine with this feature ?
17:19:16 <bero> yes, looks good
17:20:01 <_TPG> so let's assign this to nicco
17:20:35 <itchka> who will contact him?
17:20:36 <_TPG> moving to next topic
17:20:40 <_TPG> #topic ARM
17:20:47 <_TPG> 1. Recompile all packages from repositories supported by OMV.
17:20:53 <_TPG> 2.  Provide a working KDE environment.
17:21:02 <_TPG> 3.  Create working Image.
17:21:07 <_TPG> these were ON HOLD
17:22:32 <itchka> with the abf is working at the moment a mass build seems a bit ambitious!!
17:22:41 <itchka> the way abf
17:23:33 <_TPG> so if #1 can not be reached then #2 and #3 also
17:24:07 <_TPG> anyways are we going to provide a working armv7 image for 2014.0 ?
17:24:14 <_TPG> fedya|2: ping :)
17:25:51 <bero> we really should
17:25:55 <pcpa> _TPG: received a response for the package ownership change... https://abf.io/projects/mass_import
17:26:04 <bero> and aside from abf issues I think we can
17:26:38 <pcpa> need to check later if it works, contrary to following the default links
17:26:56 <_TPG> pcpa: good news !
17:27:27 <pcpa> _TPG: ah, nvm, I will reply, the problem is that I have been assigning to openmandriva, not to myself, and openmandriva assignment defaults to warps
17:27:29 <pcpa> warpc
17:27:43 <itchka> That's at least two mass rebulds how long does that take bero
17:28:12 <_TPG> anyways do we have a fullu rebuilded main for armv7 ?
17:28:17 <_TPG> does it even works ?
17:29:14 <bero> itchka: currently can take forever, I've had to cancel the gcc 4.8 related mass build after 3 weeks and it was still nowhere near done... But it used to be a lot faster, I tend to think this is just a temporary abf malfunction
17:29:24 <bero> _TPG: We don't currently have a full rebuild, but what is there works
17:30:02 <_TPG> does our armv7 supports arm-cortex-a9 ?
17:31:02 <bero> yes, Cortex-A9 is a v7
17:31:21 <bero> so is Cortex-A7, Cortex-A8, Cortex-A15 and Krait/Snapdragon
17:31:27 <itchka> bero: I think we need to seriously look at abf scheduling I know ROSA were also running a mass build if too many are started at the same time you could wait months. This needs talking about with the abf maintainers
17:31:44 <bero> itchka: true
17:32:44 <itchka> bero: unless of course we can add extra resources when we need to
17:36:15 <_TPG> so GO for all three
17:36:23 <_TPG> who should i assign there ?
17:39:18 <itchka> The question here is really how many users are going to install this.  From a practical point of view if only a few dozen individuals are going to use it at this time then we would be better putting our effort into the main part of OMA.
17:42:19 <itchka> _TPG: Can we leave people to think about this and get on with the rest of the meeting.
17:42:35 <_TPG> itchka: so ON HOLD
17:42:50 <_TPG> last one
17:42:55 <_TPG> from specs list
17:42:59 <_TPG> #topic Java
17:42:59 <bero> _TPG: I think assign fedya|2 to all...
17:43:10 <_TPG> 1.Obsolete java-1.6.0-openjdk and recreate java stack based on Fedora java stack.
17:43:17 <_TPG> 2.Do the above without obsoleting java-1.6.0-openjdk, 1.6.0 is vital for Android developers until at least Android 4.5 is out
17:43:49 <_TPG> bero: ok, done
17:44:01 <_TPG> pcpa: it's time for you java stuff :)
17:44:03 <pcpa> I found a major other show stopper, the fedora packages relies on rpm4 features that cannot be added to rpm5
17:44:58 <bero> I wonder if we should just "steal" some other distro's work then...
17:45:01 <pcpa> jbj suggested me to extract dependencies info from rpm -qp --provides and --requires of fedora packages...
17:45:15 <bero> Wasn't n3npq_ saying he can add the needed bits and pieces?
17:45:36 <pcpa> I considered to write from scratch, but then would be a NOGO for 2014
17:45:45 <bero> Hmm, I don't like that idea too much, it's asking for trouble when updating anything
17:45:58 <pcpa> I mean, write a new stack from scratch
17:46:11 <bero> IMO that wouldn't be NOGO...
17:46:27 <bero> The point of NOGOing stuff for 2014 is to make sure we don't break things...
17:46:38 <bero> Given this is already broken, a rewrite shouldn't hurt
17:46:49 <bero> and could actually be a lot less braindamaged than jpackage
17:47:27 <pcpa> jpackage is dead, since 2009 afaik
17:48:13 <itchka> we have to have working java for libreoffice functionality
17:48:42 <itchka> ?
17:49:20 <pcpa> I want a lot less than that, but was (and still am) aiming on having eclipse working
17:51:33 <_TPG> let's keep only stuff that needed for LO and other java move to wastebin ?
17:51:55 <pcpa> I mean, I want one specific package working, the jmol plugin, but because of that, I have fixed the java plugin so so many times already in the past, but now it is not only the plugin that is broken
17:51:57 <_TPG> excuse me but who uses dozens of java modules ?
17:52:01 <_TPG> seems like perl
17:52:20 <_TPG> we have almost all packages from cpan, but what the purpose ?
17:52:35 <bero> Most of them are needed by some obscure application in contrib
17:52:42 <itchka> pcpa: is the work hard or just tedious
17:52:54 * _TPG long time ago had and idea to import all R-cran
17:53:49 <pcpa> if I do what I started, we could have jboss working and other buzz stuff
17:54:24 <bero> IMO the 2 things we really need working are libreoffice and browser applets
17:54:27 <pcpa> _TPG: I had it pretty much done, well, like 5Gb of packages done at some point
17:54:32 <bero> tomcat, jboss and friends are a plus
17:54:32 <pcpa> most should still work
17:55:19 <_TPG> what is the benefit of having working jboss then ?
17:56:12 <pcpa> better than not having i working :-)
17:56:36 <itchka> good answer :)
17:56:54 <pcpa> but if importing java pacakges from fedora, this would come for free, just that I barely started creating the environment to make synching as easy as possible
17:57:46 <pcpa> texlive in this respect is a lot easier, I just create specs from texlive metadata, java at first would be easier to "steal" fedora work, and in the future write our own schema to update from upstream, and not fedora packages
17:58:23 <itchka> but if fedora won't work with rpm5 ?
17:59:06 <_TPG> honestly i mean what is a real benefit to support jboss and other java related software ?
17:59:19 <_TPG> i doubt that end luser will ever use this
18:00:00 <itchka> Hmm not so sure the perl editor debugger in eclipse is an amazing tool
18:00:31 <pcpa> the problem are scripts, and find-requires/provides, so I need to extract information from rpms
18:01:05 <pcpa> I could kind of get fedora packages working with %define _use_internal_dependency_generator 0 and defining __find_requires and __find_provides and providing some scripts
18:01:21 <pcpa> but jbj says _use_internal_dependency_generator should not be used
18:02:17 <itchka> so thew alternative is a complete rewrite using extracted information from the fedora rpms?
18:02:45 <pcpa> I mean, disabled, and disabling it right now without providing __find_requires and __find_requires scripts does not work, so, "_use_internal_dependency_generator 0" is not really an option...
18:07:23 <pcpa> itchka: I think I did not reply correctly :-), the easiest approach right now, and what I would experiment with is to have a script that reads a fedora spec, comments the Group line, add a .omv-release to release, and extract mvn(...) and osi(...) provides/requires from actual fedora packages and adds to the spec
18:07:38 <pcpa> may not be easy to understand if first time getting the idea :-)
18:08:08 <itchka> I am losing focus here: As I understand it currently we have enough working java to support libreoffice and webapplets but we have none of the flashier stuff; Currently we can't use the fedora packages because they are not complient with our structure. The only way we can use the fedora stuff is to use it to help rewrite the whole thing. That work cannot be done until the 2015 release.
18:08:22 <itchka> Thank you pcpa
18:08:56 <_TPG> so java stuff got NO GO for 2014 ?
18:09:41 <itchka> I would say monitor progress and defer 'til nearer the time of release.
18:10:37 <itchka> given pcpa's recent explanantion
18:10:52 <pcpa> _TPG: I prefer to not make it official for now, and we cannot simply say in a press release that we did copy all fedora java packages...
18:11:21 <_TPG> s/copy/share
18:11:23 <pcpa> writing a java stack from scratch is really NOGO, but unofficially having it working, as a copy of fedora is doable
18:12:34 <_TPG> pcpa: is this ok for you ON HOLD - first update cooker then if nothing is broken backport to 2014.0
18:13:17 <pcpa> In one or two weeks I should be able to get a better prevision of what can be done, I did work all weekend just to get some base bits in place, e.g. lilypond, docbook-dtds, etc
18:14:29 <itchka> pcpa: Then ON_HOLD is ok for you?
18:14:44 <pcpa> itchka: yes, good enough for now
18:14:58 <_TPG> pcpa: we can check after alpha release
18:15:11 <_TPG> so agreed
18:15:20 <itchka> good
18:15:26 <_TPG> looks like we finished Specs list
18:15:33 <itchka> yes
18:16:02 <itchka> _TPG could we do Jeffs item please as I haven't got much longer
18:16:13 <_TPG> i thought it will take more time and energy to walk through the list
18:16:28 <_TPG> #topic rpm4.org
18:16:30 <_TPG> oops
18:16:35 <_TPG> #topic rpm5.org
18:16:41 <_TPG> n3npq_: ping
18:18:14 <itchka> _TPG is this the topic that j recently asked you to add?
18:22:43 <_TPG> let's wait a little bit more
18:23:12 <itchka> n3npq_:ping
18:34:09 <itchka> _TPG: What elso do we have on the agenda?
18:34:26 <_TPG> itchka: that's all
18:34:37 <_TPG> if no response in 5 mins i'll close this meeting
18:35:35 <itchka> _TPG: Its good we managed to finish the 2014-specification
18:36:21 <itchka> What is the rpm5.org thing about can someone fill me in with any background while we wait?
18:39:12 <_TPG> ok time to end
18:39:16 <_TPG> #endmeeting