15:01:06 <_TPG> #startmeeting
15:01:06 <chwido> Meeting started Tue Jul 15 15:01:06 2014 UTC.  The chair is _TPG. Information about MeetBot at https://wiki.openmandriva.org/om/en/MeetBot.
15:01:06 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:57 <_TPG> andrepm: arisel avokhmin benatto bero|3 fedya franciscopk galmeida gmoro itchka itchka_ jkerr82508 klebedeff luca___ marja mdawkins nicco__ pcpa proyvind Pulfer Xu_R
15:02:05 <_TPG> anyone for a TC meeting ?
15:02:13 <avokhmin> +
15:02:59 <mdawkins> here
15:04:16 <Xu_R> here
15:05:48 <benatto> here
15:06:36 <_TPG> let's go
15:07:32 <_TPG> #agenda http://pastie.org/9393727
15:07:44 <_TPG> #topic 2014.1 release - what needs to be done ?
15:08:03 <_TPG> is there anything that needs to be done for 2014.1 ?
15:08:53 <Xu_R> It was noted in yesterday's meeting notes: https://chwido.openmandriva.org/meetings/openmandriva-cooker/2014-07-14/openmandriva-cooker.2014-07-14-15.17.html
15:10:07 <Xu_R> I'd take the opportunity to investigate all those; but other than that, we should be good to go
15:11:16 <_TPG> speaking of KDE boot
15:11:53 <_TPG> if we disable all those fancy effects then KDE boots very fast
15:13:17 <_TPG> Xu_R: this above list is mostly based on "hunch", like baloo may cause slowdowns
15:13:34 <_TPG> well new kernel *MAY* also cause slowdowns
15:13:35 <Xu_R> _TPG, well, those "hunches" are what users see
15:13:51 <Xu_R> so we'll investigate them regardless
15:14:14 <_TPG> baloo is disabled on livemode same as nepomuk
15:15:00 <_TPG> Xu_R: if you are going to investigate them, would it be good to have those so called issues registered somewhere to track progress of them ?
15:15:24 <Pulfer> Baloo is quite fast thing, BTW
15:15:26 <Xu_R> I'm keeping track of them. itchka also has his list (which is linked from above)
15:15:45 <Pulfer> Seems to be much lighter than Nepomuk at least
15:15:51 <_TPG> Pulfer: +1
15:16:23 <Xu_R> Okay, well it's something that we could keep in mind. If it's not the problem, then we don't need to worry about it
15:16:36 <_TPG> Xu_R: no i mean either register them as bugs on issues.openmandriva.org or requests on project.openmandriva.org to have a clear view of the situation
15:16:50 <_TPG> since we are open here right ?
15:17:10 <Pulfer> BTW, I'm updating KDE 4.13.2 -> 4.13.3 in openmandriva/master now. It should take 3-4 days to complete the work (slower than usually because of mass rebuilds)
15:17:21 <Xu_R> _TPG, it's being kept track of. I'm putting it in project.openmandriva.org in QA when I get the time to (probably later today)
15:17:32 <Xu_R> There are a lot of mass rebuilds going on...
15:17:35 <_TPG> Xu_R: great
15:18:07 <_TPG> Pulfer: maybe we should update 2014.0 too ?
15:18:15 <_TPG> if it is not too late
15:18:28 <_TPG> but yes these mass rebuilds are killing ABF
15:18:33 <Pulfer> _TPG: What KDE version 2014.0 has now?
15:18:45 <_TPG> Pulfer: 4.13.3
15:18:50 <_TPG> Pulfer: 4.13.2
15:19:04 <Pulfer> I suggest to backport 4.13.3 then when it's ready
15:19:39 <itchka> Sorry I'm late guys I have alot on at the moment.
15:19:40 <_TPG> sure
15:21:13 <_TPG> Xu_R: so what are we going to do with that list ?
15:21:59 <Xu_R> _TPG, from that list I'd investigate why KDE starts so slow and why Firefox is having issues. Those are really the two major things I got from it.
15:22:21 <mdawkins> brb - ping me when we talk about ISO building please
15:22:26 <_TPG> Xu_R: when we should expect some results ?
15:22:28 <_TPG> mdawkins: k
15:23:25 <Xu_R> _TPG, we're all aiming to figure out these problems by the end of this week
15:23:41 <Xu_R> Additionally, nicco__ is going to try to aim for kernel 3.15 by the end of this week if we can
15:25:06 <bero|3> back
15:25:18 <_TPG> #action QA team will give status report on KDE and FF slowness at end of this week
15:25:33 <bero|3> In case people haven't noticed, KDE 5.0 has been released - currently building it in cooker (without obsoleting 4)
15:26:28 <_TPG> #action update KDE to 4.13.3 version before release
15:28:12 <_TPG> speaking 2014.0
15:28:29 <itchka> Sorry called away again. bbs
15:28:30 <_TPG> i'd disable by default wpa_supplicant and network_service
15:28:58 <_TPG> as these two takes in parallel like 5-7 seconds on boot time
15:29:18 <bero|3> Does plasma-nm work these days if wpa_supplicant isn't running?
15:29:50 <bero|3> last time I checked it didn't, but that was probably around 2 years ago
15:30:08 <_TPG> nope
15:30:20 <_TPG> ondly drakx-net is using wpa_supplicant
15:31:10 <_TPG> and we have quite old version of it
15:31:14 <bero|3> Then I'm all for disabling it
15:33:55 <_TPG> cool
15:34:24 <_TPG> anyone got some objections  to disable network.service and wpa-supplicant.service ?
15:35:20 <Xu_R> I thought NetworkManager uses wpa supplicant? But not as a service, I think
15:35:26 <Xu_R> so then I have no objections
15:36:54 <_TPG> i have both services disabled here and NM works fine
15:37:11 <_TPG> not to mention that my system i close to 10s boot
15:37:24 <_TPG> unless i disable systemd-fsck-root.service :D
15:37:49 <_TPG> #action disable wpa_supplicant and network services
15:38:59 <_TPG> moving to next topic
15:39:06 <_TPG> #topic ISO building for 2014.1
15:39:35 <_TPG> i gave a little love from my site to livecd-tools and iso-build-tools
15:40:01 <_TPG> most important is that i've killed that grey box flickering on boot :)
15:41:24 <nicco__> it would be possible putting two different kernel flavours per iso (for ex. desktop & laptop)?
15:41:56 <nicco__> this question was poned to ROSA into the rosalab forum by a customer
15:43:04 <OnlyHuman> chwido: bark wanna-go-walkies
15:43:05 * chwido barks at wanna-go-walkies while having an interested look at a place somewhere below the belly button.
15:43:06 <nicco__> he asked for desktop&laptop for 64bit, desktop&desktop-pae + laptop&laptop-pae on 32bit
15:44:40 <bero|3> nicco__: In theory yes, but the problem is that the current live installer doesn't know anything about packages -- it just syncs whatever is on the live image to the harddisk, so selecting one would mean some modifications we can't realistically expect for 2014.1
15:44:43 <nicco__> having in the iso also a laptop kernel for who's complaining omv uses too much cpu and battery
15:46:18 <nicco__> In the past, I have seen many live distros that are equipped with different kernels
15:47:37 <_TPG> mdawkins: ping
15:49:54 <mdawkins> here
15:50:13 <_TPG> anyone for disabling that extra services druing boot/install ?
15:50:21 <mdawkins> +1
15:50:23 <_TPG> we have cups/samba/sshd ?
15:50:36 <Xu_R> can't cups load on demand?
15:50:55 <Xu_R> or samba?
15:51:00 <_TPG> Xu_R: it is stared by xinetd too
15:51:14 <Xu_R> _TPG, okay, then have it load on demand then
15:51:17 <mdawkins> well samba needs to be worked on a bit
15:51:21 <bero|3> Xu_R: cups can load on demand, but demand loading currently prevents http://localhost:631 from working for setting up the first printer in the system. Not sure if anyone but me relies on that
15:51:25 <mdawkins> it has a bunch of libs bundled into it
15:51:45 <bero|3> samba is probably similar, in general could launch on demand, but would likely lose its functionality as master browser
15:52:07 <_TPG> latest iso boots in 17 secs :>
15:52:11 <Xu_R> bero|3, systemd should be able to monitor localhost:631, right? if a call comes to 631, systemd should be able to hold it
15:52:19 <mdawkins> bero|3: is samba even used like that anymore?
15:52:24 <Xu_R> launch cups in the background, and then send the call on its way
15:52:42 <_TPG> Xu_R: xinetd service does this
15:53:27 <Xu_R> _TPG, doesn't systemd do something similar too?
15:53:40 <_TPG> Xu_R: iirc no
15:53:55 <Xu_R> okay. have xinetd handle it. I'm all for disabling cups on bootup
15:54:15 <_TPG> wpa_supplicant takes like 5 secs on bootig
15:54:25 <_TPG> 7 secs is for ModemManager
15:54:40 <Xu_R> oh wait
15:54:41 <Xu_R> _TPG
15:54:42 <Xu_R> http://0pointer.de/blog/projects/inetd.html
15:54:57 <Xu_R> ^ systemd has inetd capabilities too, so we should probably use those
15:55:54 <_TPG> Xu_R: well we can add few *.scokets
15:55:57 <_TPG> sockets
15:56:06 <_TPG> for cups and sshd
15:56:14 <Xu_R> sounds good
15:56:45 <_TPG> #action add systemd sockets for cups and sshd
15:57:06 <_TPG> #action disable user ask for enabling extra services on draklive
15:57:14 <bero> We still need to make sure they can be turned off easily - some people may not want to have sshd starting for security reasons
15:57:40 <_TPG> same goes for cups
15:58:04 <_TPG> if i start pinging some ports then i can start service based on systemd socks
15:58:50 <Xu_R> Well, we could make sure systemd listens on only
15:58:58 <Xu_R> that way nobody outside the computer can ping to start cups at least
15:59:07 <Xu_R> sshd... disable by default maybe?
16:00:55 <_TPG> yea i'd keep only cups
16:01:05 <mdawkins> so are isobuilds working again?
16:01:40 <_TPG> mdawkins: for 2014.0 and 2013.0 were working fine
16:02:11 <_TPG> mdawkins: i've also found solution for cooker but livecd-tools can't compile because of py3
16:02:21 <mdawkins> ok
16:02:33 <mdawkins> b/c one of the bits we really need to work on still is the pkg list
16:02:48 <mdawkins> the ISOs still in my mind are pure bloat
16:03:10 <Xu_R> ^ agreed
16:03:30 <_TPG> if we remove LO then ISO will be lighter
16:03:45 <mdawkins> _TPG: there's more that we could do
16:03:45 <Xu_R> Ehh, but that's something we can't do >__>
16:03:53 <mdawkins> LO for the DE should prolly stay
16:04:00 <_TPG> LO is huge
16:04:04 <bero> and useless for a typical desktop user
16:04:09 <mdawkins> but if we split up the LO libs properly then we could prolly install only parts of LO
16:04:10 <_TPG> :>
16:04:42 <bero> we already can omit some parts
16:06:13 <_TPG> on latest iso there are 2163 installed unique rpm packages
16:08:20 <mdawkins> yeah, i'd bet that 1200 is more realistic
16:08:35 <_TPG> biggest ones are libreoffice-common and gutenprint-foomatic
16:08:52 <_TPG> strange is that rosa-icons is bigger than firefox
16:09:10 <Xu_R> how big is libreoffice-common?
16:09:32 <Xu_R> If we're not using rosa-icons then we shouldn't include it
16:09:34 <_TPG> 225060760
16:09:45 <_TPG> Xu_R: we are sing rosa-icons
16:09:46 <bero> I don't think getting below 1700 is realistic, probably xorg by itself is more than 100 packages
16:09:55 <_TPG> unless we switch to default ones
16:10:37 <Xu_R> I think we just need to sift through all the packages one by one... Maybe on a spreadsheet where we can mark ones we maybe don't need?
16:11:05 <mdawkins> yes
16:11:09 <Xu_R> Cause a working gnome environment, probably including libreoffice, is approx 1200 packages (I've been building gnome)
16:11:22 <mdawkins> it would be prudent to start with the different iso build levels
16:12:18 <_TPG> let's remove LO and everything will be fine and switch to calligra
16:12:43 <Xu_R> -1
16:13:22 <bero> I think that's a good option for the future, but it's not quite there yet
16:13:50 <bero> especially if you have to open M$ office files sent by clueless coworkers
16:14:06 <_TPG> so we stick with what we have
16:15:33 <mdawkins> calligra is the old koffice?
16:15:57 <bero> on a similar note I hope by 2015.0 we can replace Firefox with qupzilla in KDE and LXQt, should get rid of a slew of gpackages - but not quite there just yet too
16:16:06 <bero> mdawkins: yes
16:18:05 <Pulfer> Calligra is like LO 0.1alpha, nothing close to MSO/LO
16:18:20 <mdawkins> well my honest suggestion is just leaving LO-writer and calc
16:18:30 <Pulfer> I don't think anyone really uses Calligra for production
16:19:31 <Xu_R> mdawkins, also impress for powerpoints
16:20:19 <mdawkins> Xu_R: how often compared to a doc or xls file do you get pp files?
16:20:46 <Xu_R> mdawkins, Actually, pretty often. It's kinda annoying because stuff like that should come in a pdf, but noooooo
16:20:48 <nicco__> yes, the very most of people use writer, calc and impress
16:20:51 <bero> I tend to get more pp files than doc or xls
16:21:01 <mdawkins> hmm ok
16:21:05 <_TPG> i use all of them
16:21:06 <mdawkins> the impress too
16:21:33 <Xu_R> Let's look at Microsoft Office for Home and Student. That just has Word, Excel, and Powerpoint. I think we can just have Writer, Calc, and Impress.
16:21:34 <_TPG> are we going to use stock KDE icons or go with rosa-icons ?
16:21:38 <bero> we even get slides for presentations at Linux conferences submitted as pptx :/
16:21:42 <_TPG> this can save 100MiB
16:21:46 <mdawkins> but cereal folks, math and draw and whatever else that comes pkged with LO is kinda extra
16:22:02 <nicco__> many students use impress for presentations, is very used
16:22:32 <bero> I don't think we should switch icon sets in a minor update - but for 2015...
16:22:35 <nicco__> KDE icons are really ugly!
16:22:39 <Pulfer> Rosa icons are the best icons, IMHO
16:22:45 <_TPG> Pulfer: +1
16:23:07 <_TPG> anyways found 20MiB to save
16:23:12 <_TPG> do we really need python-zope-interface ?
16:23:13 <nicco__> yes, true, rosa icons are cute
16:23:21 <_TPG> this pulls python-devel
16:23:27 <Pulfer> MIB Ossigeno icons are second best, IMHO
16:23:44 <Pulfer> And KDE default icons are just OK but nothing really good
16:23:48 <nicco__> how is the size of MIB ossigeno rpm?
16:23:59 <Pulfer> Let me check
16:24:53 <Pulfer> mib-ossigeno-icons-4.3.0-69.4-rosa2012.1.noarch  33 312 973
16:25:03 <bero> IMO we don't need zope... what pulls it in?
16:26:47 <nicco__> [18:20] <_TPG> 225060760 > are rosa icons 225 Mb?
16:27:25 <nicco__> if so, decisely too much for the isos
16:27:51 <_TPG> nicco__: no it's size of libreoffice-common
16:28:05 <_TPG> bero: it is pulled from iso-pkg-lists
16:28:25 <Pulfer> rosa-icons-1.1.3-5-rosa2014.1.noarch.rpm    12 157 333
16:28:38 <Pulfer> Latest icons are quite small in size
16:30:12 <_TPG> we have rosa-icons-1.0.33
16:30:20 <_TPG> maybe it would be good to update tem
16:30:21 <_TPG> them
16:33:02 <mdawkins> python-zope-interface prolly pulls in py-devel b/c of a pkgconfig file or an egg
16:33:12 <mdawkins> it's prolly very obvious
16:33:52 <_TPG> but it is not needed on ISO
16:34:08 <Xu_R> -devel packages should not be on an ISO
16:34:12 <mdawkins> well almost no devel pkg should be on the iso
16:34:15 <mdawkins> +1
16:34:25 <mdawkins> not even gcc
16:34:35 <mdawkins> we should be pre-pkging kernel modules
16:34:38 <Pulfer> gcc may be needed for dkms stuff
16:34:47 <mdawkins> Pulfer: pre-pkg
16:34:55 <mdawkins> it works out better
16:35:03 <mdawkins> it's just hard to track
16:35:05 <_TPG> is see only python-devel as a devel package on ISO
16:35:07 <Pulfer> Yes
16:35:18 <mdawkins> b/c anytime you upgrade the kernel all the dkms have to be rebuilt
16:35:21 <_TPG> and no gcc
16:35:36 <mdawkins> and if a newer dkms pkg is release then it has to be built too
16:36:03 <_TPG> #actions remove python-devel and related to it python packages from iso
16:36:12 <_TPG> #action remove python-devel and related to it python packages from iso
16:36:30 <_TPG> #action update rosa-icons to new version
16:36:38 <nicco__> but not in all installations there are dkms
16:37:06 <_TPG> do we have anything more on ISO topic ?
16:37:07 <nicco__> in many installation, with all free drivers, there are none dkms
16:39:11 <Pulfer> What happens if someone uses pre-pkg nvidia blob and then installs new kernel from non-official repository?
16:39:22 <Pulfer> If there's no dkms
16:39:34 <nicco__> right!
16:39:41 <_TPG> Pulfer: on live mode this is useless
16:39:56 <Pulfer> I mean mostly Nicco's repositories with lots of kernel versions
16:39:59 <Pulfer> _TPG: Surely
16:40:36 <mdawkins> could we ditch dkms ?
16:40:46 <itchka> back
16:40:49 <_TPG> no
16:40:58 <_TPG> dkms is not on iso too
16:45:19 <bero|3> The way we handled external kernel modules in Ark was that we forced every module to be included in the kernel package (e.g. we ripped the modules out of virtualbox and built them inside the kernel package) to make sure they're always up to date
16:45:54 <bero|3> That may be the best way forward for us too, given our typical user won't quite get what it means if VirtualBox doesn't start up anymore because something called dkms spewed some error message at bootup
16:47:57 <_TPG> let's move to next topic
16:48:02 <_TPG> #topic QA - list of bugs that needs to be fixed
16:48:09 <itchka> Regarding this iso topic do not forget the people who don't have internet access. They can't get any packages except from the DVD.
16:48:44 <_TPG> itchka: and they wont
16:48:56 <_TPG> itchka: because all what is on ISO is copied to hdd
16:49:40 <_TPG> ok let's move throug some bugs
16:49:42 <_TPG> https://docs.google.com/spreadsheets/d/1yYwANCMo5Ekk8IfQW4wgWBIvxNO7K01gclbFupa2H_c/edit#gid=0
16:50:27 <itchka> _TPG: Exactly if you take it off the list they don't get it. If they get their DVD from a magazine and they have no internet what do they do then.
16:51:00 <_TPG> itchka: we do not have DVD iso
16:51:12 <_TPG> with all packages from main
16:51:22 <_TPG> anyways let's go with bugs
16:51:34 <_TPG> https://issues.openmandriva.org/show_bug.cgi?id=384 doesnt sound like a blocker for 2014.1
16:51:43 <_TPG> dunno why this one in on this list
16:52:08 <itchka> 846 is very relevent given preceding discussions
16:52:12 <Pulfer> Bug #1 - OMV is getting more and more experimental, it reminds Mandriva/Rosa 2011 times already...
16:53:51 <_TPG> itchka: relevant how ? sorry i do not see how this is realted to ISO or some rpm packages ?
16:54:05 <bero|3> Pulfer: That's expected when the next release is almost a year away and we need to get the stuff that will be ready by release time tested...
16:54:45 <Pulfer> bero|3: I really hope you know what you are doing then
16:55:06 <itchka> _TPG: I mean the discussions about disabling wpa-supplicat and rely in on nm. It make draknet irrellevent yet removing it has not been mentioned.
16:56:08 <_TPG> itchka: draknet is irrelevent for 2 years or 3
16:56:38 <Pulfer> BTW, does OpenMandriva use knetworkmanager or plasma-nm in ISOs?
16:56:45 <itchka> _TPG: That may be but some people still try to use it.
16:56:47 <_TPG> Pulfer: plasma-nm
16:56:51 <Pulfer> Good then
16:57:15 <_TPG> itchka: and those people file bugs because they try to use not maintained since 2010 software
16:57:20 <_TPG> is that good option ?
16:57:32 <_TPG> not maintained software
16:57:48 <Pulfer> In Rosa I had to use bleeding edge plasma-nm (git snapshot from early July) to match latest NM and libnm-qt
16:57:53 <itchka> That bug was filed against 2014 _TPG
16:58:10 <bero|3> Pulfer: We're currently on
16:58:18 <_TPG> why bug 834 is critical ?
16:58:32 <Pulfer> bero|3: It's ok for older NM and libnm-qt
16:58:33 <itchka> If you put software on a cd it's not unreasonable for people to expect it to work!
16:58:47 <symbianflo> afternoon
16:58:55 <Pulfer> symbianflo: Hi
16:59:07 <_TPG> itchka: so let's remove drak-net and everybody will be happy
16:59:11 <symbianflo> Pulfer: Hi
16:59:33 <_TPG> or someone needs to spend some of his precious time to fix that crappy stuff
16:59:35 <itchka> _TPG: It's critical because it wastes a users time and gives us a bad reputation for non-working software.
16:59:54 <bero|3> IMO removing it is by far the best option
17:00:24 <bero|3> If people use it because they have a problem with plasma-nm, we should fix plasma-nm instead, that's what people will still use a few years from now
17:00:35 <_TPG> itchka: have you confirmed that 834 bug ?
17:00:38 <itchka> bero|2: Exactly
17:02:08 <_TPG> itchka: bugreporter from that bug says that mageia packages can mount exfat... what if i tell you there is no difference between our and mageia fuse-exfat packages ?
17:02:32 <bero|3> There may be a difference in one of their dependencies
17:02:46 <bero|3> e.g. util-linux or fuse
17:02:48 <itchka> _TPG: I have not but to my knowledge this bug has been reported twice by two different individuals. I can confirm it if you like but the point is if draknet is unmaintained and we want people to use nm it simple shouldn't be there.
17:03:35 <_TPG> itchka: ok sho who will fix that drak-net buggy software ?
17:03:53 <_TPG> bero|3: fuse looks same on both distros
17:04:09 <_TPG> bero|3: well there are few differences in util-linux
17:04:28 <_TPG> bero|3: iirc you fixed some sis driver ?
17:04:29 <_TPG> https://issues.openmandriva.org/show_bug.cgi?id=815
17:04:38 <itchka> _TPG: I'll ask crisb he knows drakx pretty well.
17:05:11 <_TPG> itchka: sure, please ask him for fixing other drakx bugs :)
17:05:17 <bero|3> _TPG: That may or may not be fixed... I synced the patches we're applying to the sis driver with rosa because theirs is reported to work -- but I don't have any sis hardware to test
17:05:48 <_TPG> bero|3: would not hurt anybody if we port them for 2014.0
17:06:07 <_TPG> well there is a chance it will work somehow
17:06:15 <bero|3> Probably not, worst case we'd replace one driver that doesn't work with another that doesn't work either
17:06:20 <itchka> bero|3: I will contact the user and see if he will do some testing.
17:08:30 <_TPG> bero|3: but we still won't loose anything
17:08:46 <bero|3> at least not unless the driver from 2014.0 happens to work for someone
17:08:58 <bero|3> always a bit hard to know
17:09:02 <itchka> 844 relates to nm
17:09:11 <bero|3> we get people screaming "it's broken!" but we never get people screaming "it works" ;)
17:10:32 <itchka> Alas that tends to be the way of things...
17:10:32 <_TPG> :D
17:11:17 <bero|3> bug #1234 "it just works, break it so my support business can make some profit"
17:11:35 <itchka> :)
17:12:17 <_TPG> itchka: 844 is fine
17:12:40 <_TPG> on windows you also have by default eth connection
17:12:47 <bero|3> which btw. is the reason why most hardware shops still preload Windoze -- one of them actually admitted that they force people on windoze because that way they'll also buy some anti-virus software, M$ office etc. from them
17:13:11 <itchka> So what do you do if you want a static ip
17:13:40 <itchka> Use draknet :)
17:13:41 <bero|3> yes, it's good that it comes up by default, but it should be editable...
17:13:56 <bero|3> vi /etc/sysconfig/network-scripts/ifcfg-eth0 ;)
17:14:53 <itchka> I wonder how many users can use vi :)
17:15:39 <bero|3> kwrite /etc/sysconfig/network-scripts/ifcfg-eth0
17:16:02 <bero|3> or worse, lowriter /etc/sysconfig/network-scripts/ifcfg-eth0 (and then save it in odt or doc format for fun)
17:16:39 * _TPG uses vi
17:16:57 * bero|3 too
17:16:59 <itchka> cmon guys think of the you kids coming along who have never used anything remotely relating to a UNIX os. itchka uses vim
17:18:50 <nicco__> mcedit /etc/sysconfig/network-scripts/ifcfg-eth0 :)
17:19:35 <bero|3> heretic! ;)
17:19:49 <_TPG> mcedit is cool
17:19:51 <itchka> _TPG: Can I remind you of 785. Actually the best is kate-session-manager for all those file you are continually messing with.
17:20:18 <bero|3> I'll give mcedit that it's not as awful as mc ;)
17:20:52 <symbianflo> mcedit is the best...
17:21:35 <symbianflo> bero|3: your mc might be awful ...not mine ...
17:21:38 <symbianflo> :D
17:21:44 <itchka> I'll admit that the mc editor is crap but to give this incredibly useful program it's due you can set it up to use vi or any other editor you care to name.
17:22:36 <_TPG> itchka: Coling will you ask Crisb to take a look at drakx bugs ?
17:22:48 <symbianflo> itchka:i forgive you because you don't really know what potential have mc if you would have a real mc...
17:23:46 <itchka> _TPG: Sure
17:24:25 <itchka> symbinaflo: Then point me to this supertuned program. :)
17:24:29 <_TPG> #action ask Crisb to take a look on drakx bugs
17:24:45 <_TPG> #topic Announcement and GA date
17:25:06 <_TPG> are we still fine with end of July to release 2014.1 ?
17:25:14 <symbianflo> Install it from mrb
17:26:07 <bero|3> _TPG: IMO yes, I don't see any major bugs that weren't at least as bad in 2014.0
17:26:25 <itchka> _TPG: The i586 repo needs fixing first there are programs which I cannot install because of unsatisfied dependencies.
17:26:31 <itchka> wine
17:26:46 <itchka> is one example
17:27:12 <itchka> ekiga (although it's probably contrib)
17:27:38 <nicco__> few mins ago, Luca said me that is high the risk there will be no interests because all people is on the seaside
17:28:23 <nicco__> it's exactly the same thing I thought and I've already said you yesterday
17:30:34 <_TPG> nicco__: when we do this on august then people also be on a seaside
17:31:06 <_TPG> we are releasing bugfix ISO
17:31:23 <_TPG> not a new release with super features
17:32:06 <itchka> _TPG: That's true but if that's the case why don't we spend a little more time fixing bugs and send out best quality.
17:33:35 <nicco__> mine and Luca's thoughts are that this release time is generally the worst to release something
17:34:14 <itchka> nicco__: So when is the right time?
17:34:41 <nicco__> the release will pass as unobserved, in my opinion from 21 to 27 August
17:35:46 <nicco__> the most of people, at least in Italy, they will finish their vacation from 15-20 August
17:35:48 <itchka> nicco__: Do you mean 21 July to 27 August?
17:36:32 <nicco__> yes, is when people, the very most of them, come back from their vacations
17:38:11 <nicco__> none, at least happens in Italy, think of install any OS in early/mid August
17:38:47 <nicco__> perhaps, outside Italy may be different...
17:39:39 <itchka> In uk school holidays finish around 3rd September
17:40:24 <itchka> and start in late June early July
17:41:04 <itchka> _TPG: Poland?
17:41:19 <_TPG> vacations end with august
17:42:21 <_TPG> bero|3: what is your opinion ?
17:43:39 <bero|3> I'm unsure about this one...
17:43:54 <bero|3> It's true that a lot of people are on vacation and won't see the announcement, at least not right away
17:44:20 <bero|3> but OTOH it's not a big release and people installing it will have a better experience than people installing 2014.0
17:44:35 <bero|3> so from that perspective, we should release it ASAP so people can install something better
17:44:46 <itchka> We need to keep peoples interest in the winter months. If we released 1st September it would catch people for the autumn when it's cooler and the seaside is not so attractive.
17:44:50 <bero|3> Both points are valid, but I'm not sure which one is more important
17:45:16 <bero|3> In the winter months we need people to pay attention to the alpha/beta releases of 2015.0...
17:46:34 <itchka> I agree but winter doesn't really start until November.
17:46:47 <_TPG> itchka: winter is for us to work on next release
17:47:16 <_TPG> bero is fully right here
17:47:23 <_TPG> and we should release asap
17:47:39 <_TPG> because we will never focus on cooker and 2015.0
17:47:55 <itchka> _TPG: Yes I understand that, I'm saying that people would have a couple of months use from 2014.1 before the new release cycle.
17:47:57 <bero|3> That part is true...
17:48:09 <bero|3> We have an ambitious project going on and we can't keep our focus diverted from it
17:48:26 <_TPG> +1
17:48:52 <itchka> On a personal note I might say that even distro workers need a summer holiday:)
17:49:16 <itchka> Or at least a period when things are less intense.:)
17:49:18 <_TPG> see that's why we should release in July, so some of us can go on vacation
17:50:45 <bero|3> Indeed. I'm planning to visit my sister's family in the next 3 weeks, I'll be around, but probably not 24x7
17:50:46 <itchka> That's why I'm advocating a relaxed approach with release on Sept 1st. Not everybody goes on vacation at the same time.
17:51:00 <nicco__> +1
17:51:57 <_TPG> i'm +1 for end of july
17:52:27 <bero|3> I'm leaning towards end of July as well, we really need time to focus on 2015.0
17:53:44 <bero|3> We can't fix Pulfer's bug #1 if we lose another 2 months
17:53:59 <_TPG> that's true
17:54:04 <Xu_R> +1 for end of july
17:54:37 <itchka> That gives 2 weeks to update KDE and 1 week test and bugfix.
17:55:54 <Xu_R> why 2 weeks to update KDE?
17:56:10 <Xu_R> I want all updates done by the end of this week so that we can test and bugfix
17:57:00 <itchka> I meant KDE and any other stuff that needs fixing. As well as sorting out the i586 repo.
17:57:27 <Xu_R> Can we get that done within the next week and a half? That'd be nice.
17:57:49 <_TPG> we need to ask Pulfer
17:58:28 <nicco__> if for 31 july or 04 August for the GA would not change much...
17:58:28 <itchka> TPG: Plymouth?
17:58:52 <bero|3> abf seems to have some issues with i586 right now, most of my builds (at least in cooker) fail because i586 tries to download packages that aren't there anymore
18:00:01 <itchka> bero|3: How are we going to fix this i586 repo?
18:00:27 <bero|3> Not much we can do, aside from waiting
18:00:36 <itchka> SF says we have 3 different EVRD's in it.
18:01:07 <itchka> bero|3: How does waiting help?
18:01:11 <bero|3> (and rebuilding the couple of packages that were built on x86_64 only because of the i586 chroot breakage)
18:01:41 <bero|3> itchka: it always does -- abf is constantly broken while something is being published and gets back to normal once the publishing is done
18:02:05 <symbianflo> bero|3: a couple ? are you sure? ...
18:02:12 <bero|3> itchka: 3 different EVRDs are nothing to worry about because urpmi only picks the most current one. We can clean it out, but it shouldn't break things
18:02:34 <bero|3> symbianflo: Maybe a few more, but not that many
18:02:49 <symbianflo> bero|3:  urpmi faild to pick  it as you said in 10 cases out of 28
18:03:06 <bero|3> At some point we need to make sure a build fails globally if it fails on any arch
18:03:13 <bero|3> just to maintain consistency
18:03:17 <symbianflo> yeah sure i'm overreacting :D
18:04:16 <itchka> bero|3: How do we find the packages that need to be rebuilt. I'm happy to take on the task of doing it if it helps>
18:04:36 <_TPG> how to set fuzz in spec file ?
18:04:39 <symbianflo> itchka:repoclosure
18:04:40 <_TPG> any define ?
18:04:52 <bero|3> itchka: essentially, ls the x86_64 repository and the i586 repository and see where there's any differences
18:05:07 <bero|3> repoclosure will find the most important ones too
18:06:15 <itchka> bero|3: Ok I'll look into it and report back if I have any difficulties.
18:06:47 <_TPG> found that
18:10:36 <_TPG> #agreed 2014.1 will be released at end of july
18:11:05 <bero|3> Chwido says woof - I think it means he agrees
18:11:05 <chwido> bero|3: Error: "says" is not a valid command.
18:11:37 <symbianflo> bad choice ...
18:15:00 <_TPG> hehe
18:15:21 <_TPG> ok do we wan't to continue with some cooker stuff ?
18:15:46 <bero|3> Unless someone has something else on 2014.1 before?
18:15:57 * bero|3 doesn't have anything else on 2014.1
18:21:40 <bero|3> _TPG: I presume the silence means neither does anyone else
18:21:52 <_TPG> ok that's cook
18:21:54 <_TPG> cool
18:22:00 <_TPG> let's move to 2015.0 stuff
18:23:44 * Xu_R has nothing on 2014.1 either
18:24:15 <bero> so kde5 is almost done, but obviously we'll have to restore customizations etc.
18:24:38 <_TPG> or make new ones
18:25:13 <bero> true
18:25:42 <bero> esp. with icons, themes etc. we need to look at the new defaults before changing them
18:25:56 <Xu_R> KDE5 is much slower than I thought it'd be right now... I dunno, how do you guys see performance?
18:27:06 <_TPG> #topic By default build package optimized for its size https://project.openmandriva.org/work_packages/67
18:27:12 <_TPG> iirc we use -Oz with cooker
18:27:20 <_TPG> so this can me barked as done ?
18:27:29 <_TPG> s/barked/marked
18:27:35 <bero> not finished building it, so I haven't seen it running
18:27:57 <bero> _TPG: yes, done
18:30:53 <symbianflo> bero|3:  can I push my mc in oma?
18:32:17 <_TPG> ok marked as done
18:32:28 <_TPG> #topic Make python 3.x main, start deprecating 2.x https://project.openmandriva.org/work_packages/55
18:32:36 <_TPG> where are we with this task ?
18:35:15 <bero> symbianflo: sure
18:35:52 <bero> _TPG: basics are done, but quite a few extra modules need to be adaptedd
18:36:49 <symbianflo> ok
18:42:46 <_TPG> bero: can you update progress on that page ?
18:46:02 <symbianflo> OMA2014.1 and Tanning  Lotions Will be out on July ... :-D
18:48:22 <_TPG> # topic GNOME 3.12/3.14/3.16 https://project.openmandriva.org/work_packages/98
18:48:24 <_TPG> #topic GNOME 3.12/3.14/3.16 https://project.openmandriva.org/work_packages/98
18:48:34 <bero> _TPG: sure
18:48:34 <_TPG> Xu_R: i saw you are working on this
18:48:54 <_TPG> Xu_R: can you update status ?
18:48:54 <Xu_R> _TPG, yes. A minimal GNOME already works :D
18:49:16 <_TPG> that sounds cool
18:49:30 <Xu_R> I'll be updating it to 3.14 when it comes out, and probably 3.16 for 2015.0
18:50:49 <Xu_R> I'll probably merge it into main after 3.14 comes out
18:51:02 <_TPG> Xu_R: any chances to get it on 2014.1 ?
18:51:13 <Xu_R> _TPG, no. Missing too many components still. :/
18:51:48 <Xu_R> I can release an unofficial 2014.1 version later maybe, but for now no.
18:55:16 <_TPG> Xu_R: well sounds good :)
18:57:07 <_TPG> Xu_R: please add kyndek to kahiniah
18:57:52 <_TPG> #topic Update to perl 5.20.x or 5.2x https://project.openmandriva.org/work_packages/56
18:58:24 <_TPG> bero: i assume we need to wait for mas rebuild finish, and some python fixes to get that perl update ?
18:58:45 <bero> mass rebuild yes, python is unrelated...
18:58:59 <bero> but we need a volunteer to actually do it
18:59:54 <bero> and some input from the Rosa guys on how to do it without breaking abf until urpmi is rebuilt
19:01:44 <_TPG> bero: well yes i didn't forgot about to talk to Denis about his experience with perl/urpmi updates
19:06:46 <_TPG> i think these were all major ideas for 2015.0 yet to be discussed
19:07:58 <bero|3> There's also a new LXQt coming out, this time with optional Qt5 support
19:08:17 <bero|3> I'd say we should build it with Qt5 support, by the time 2015.0 is released, probably Qt4 won't be all that relevant anymore
19:11:45 <_TPG> +1
19:11:56 <Xu_R> +1
19:11:58 <_TPG> LXQT is gaining some more attention
19:20:09 <_TPG> ok do we have anything more to talk about ?
19:22:09 <bero|3> At some point we'll have to talk about how and if we want to handle tablets, phones etc.
19:22:28 <bero|3> But it probably makes more sense to talk about that when we've seen the stuff rosa wants to give us
19:22:29 <_TPG> bero|3: well yes
19:22:45 <bero|3> Can't decide whether or not that's useful at all if we haven't seen it
19:24:53 <_TPG> yeah
19:25:11 <_TPG> bero|3: what about that intel az210a ?
19:25:32 <_TPG> i was asking you few times :>
19:25:59 <bero|3> And I can only repeat the same answer over and over again ;)
19:26:17 <bero|3> It's an easy target because we already have a solid x86 build and support for Intel graphics chips
19:26:29 <bero|3> but I have no idea whether or not those things have DRM in the bootloader or crap like that
19:26:45 <bero|3> if they do --> useless because we can't boot them
19:27:16 <_TPG> bero|3: that's why i was asking to whether to buy one, because i saw auction with quite cheap model
19:27:41 <_TPG> looks like someone else already bought that phone for less than 50 euros
19:27:58 <_TPG> i could but that and send it to you
19:28:15 <_TPG> but you did not replied to me :<
19:28:28 <bero|3> because essentially I don't know
19:28:32 <bero|3> I don't know anything more than you do
19:29:26 <_TPG> ok :D
19:29:39 <_TPG> btw orange sandiego is same as XOLO 900
19:31:24 <_TPG> anyways i'll try to find one and buy it
19:42:16 <_TPG> silence means i'll end TC meeting in 5 mins'
19:45:24 <bero|3> I don't think we have anything else
19:45:31 <bero|3> Except maybe quick update on the mass build
19:45:57 <bero|3> https://abf.io/platforms/cooker/mass_builds/451
19:46:11 <bero|3> So far 12437 pending, 1606 errors, 6631 succeeded
19:46:31 <bero|3> Of the errors, many are abf i586 build root setup issues, and a few are armv7hl specific
19:46:41 <bero|3> so overall this is already looking much better than the first build
19:48:00 <_TPG> sounds nice
19:48:23 <bero|3> but it's taking forever
19:49:28 <bero|3> of course, once the mass build is done and we aren't too busy getting 2014.1 out the door, everyone please focus on fixing those build failures
19:54:14 <_TPG> #endmeeting