From Wiki [en] OpenMandriva
Jump to: navigation, search

TC meeting

Time & Place

Place: #openmandriva-cooker @ Date/Time: Tuesday 2013-06-18, 14:30 UTC

Time zone Local time UTC offset
CET Tuesday 2013-06-18, 15:30 UTC+1
MST Tuesday 2013-06-18, 07:30 UTC-7
MSK Tuesday 2013-06-18, 18:30 UTC+4
VLAT Wednesday 2013-06-19, 01:30 UTC+11


1. Release status
3. AOB




[16:35:35] <bero> Anyone here for the TC meeting?
[16:36:05] <Pulfer> bero: I'm here
[16:36:11] <mdawkins> here
[16:36:13] <OnlyHuman> Top Cat meeting? :P
[16:36:23] <mdawkins> but only for about 20mins
[16:36:38] <bero> Argh, now that Chwido read the word "Cat" he's going to chase us all around ;)
[16:36:38] <Pulfer> OnlyHuman: Tech Committee :-P
[16:36:53] <bero> Ok, let's get going quickly then ;)
[16:36:56] <bero> So...
[16:37:00] <bero> 1. Status of the release
[16:37:06] <OnlyHuman> Pulfer: same thing :D
[16:37:19] <bero> The mass build went fairly well, 625 failures (but that's still 625 too many)
[16:37:41] <bero> Some of them are just because a dependency wasn't rebuilt yet, so as soon as the build results have been published I'm going to launch a mass build of all failed packages
[16:37:52] <mdawkins> ok
[16:38:28] <bero> Some others are very simple to fix (e.g. "BuildRequires: gtk+2.0-devel" needing to be changed to "BuildRequires: pkgconfig(gtk+-x11-2.0)") because Provides from other packages were cleaned out
[16:38:40] <bero> Some will be tricky (esp. perl segfaulting during build)
[16:39:40] <bero> Looks like TPG was right about libpng 1.6, it doesn't mess up much (So far I've seen it causing problems only with packages that have an explicit dep on pkgconfig(libpng15) where it should be pkgconfig(libpng))
[16:39:49] <bero> So as far as I'm concerned it can stay in
[16:40:17] <bero> arisel already fixed up some install failures
[16:40:28] <bero> So the next release should be good
[16:40:37] <bero> Does anyone have anything they want to add to this?
[16:41:12] <mdawkins> mirrors?
[16:41:22] <mdawkins> and urpmi set up
[16:41:41] <bero> Good point, we need to get mirrors right and provide some URL that autoselects them, like the old
[16:41:48] <bero> I presume that's a task to pass on to the infra team?
[16:41:55] <fedya> I want to mirror armv7l (softfloat) repo to official mirros
[16:42:09] <mdawkins> fedya: is the repo structure like the rest?
[16:42:19] <mdawkins> fedya: that's all i've been asking for
[16:42:33] <fedya> mdawkins: our main repo
[16:42:46] <bero> fedya: Do you think armv7hl is ready to be mirrored too?
[16:42:53] <fedya> mdawkins: you can rsync it to good structure
[16:43:12] <mdawkins> fedya: no, you have to do the stucture like the rest
[16:43:35] <mdawkins>
[16:43:38] <fedya> bero: nope, armv7hl not ready, i will prepare our repo rpms for few next days
[16:43:45] <mdawkins> then armv7hl
[16:44:01] <fedya> mdawkins: well, u can give me an example what i must to do?
[16:44:13] <mdawkins> then {main,contrib,non-free}
[16:44:18] <fedya> mdawkins: i must rename /home/fdkit/repo/main to /home/fdkit/cooker/armv7hl/main ?
[16:44:19] <mdawkins> then release
[16:44:36] <fedya> mdawkins: contrib-non-free is empty now
[16:44:38] <mdawkins> we need the same repo directory structure for all
[16:44:49] <mdawkins> no mater the arch
[16:44:59] <bero> fedya: That's ok, let's just create an empty directory structure for them so scripts can assume they'll find things the way they expect
[16:45:35] <mdawkins> the problem runs into, if we have say a 15GB dir on the principal mirror
[16:45:39] <fedya> mdawkins: Well, i understood you. i will create /home/fdkit/repo/cooker/armv7l/contrib,main,non-free
[16:45:55] <mdawkins> and then the structure changes, rsync sees it as new files
[16:46:04] <mdawkins> it doesn't move files locally
[16:46:21] <mdawkins> so 15GB x 20 mirrors taxes the principal mirror
[16:46:32] <mdawkins> fedya: and then release
[16:46:35] <mdawkins> ie
[16:46:40] <fedya> mdawkins: okay
[16:46:46] <mdawkins>
[16:47:00] <mdawkins> oops
[16:47:10] <mdawkins>
[16:49:53] <bero> Anything else?
[16:50:31] <fedya> bero: util-linux + uclibc fixed?
[16:51:46] <bero> fedya: I've started looking into it, but don't have a fix yet. So far, I know that some uClibc libraries (libcrypt etc.) are not recognized as such and therefore trigger dependencies on when it should be uClibc( (but uClibc correctly provides the latter)
[16:54:47] <bero> If anyone has some spare time, could use some ;)
[16:54:52] <bero> Anything else?
[16:55:46] <bero> ok, apparently not.
[16:55:50] <bero> 2. FREEZE
[16:56:29] <bero> After the build failures have been fixed, let's consider main deep-frozen
[16:57:18] <Pulfer> bero: I'd prefer to push KDE 4.10.5 update when it's released
[16:58:00] <Pulfer> But other than that, it's really time for Main deep freeze  indeed
[16:58:14] <bero> No more updates (unless they fix a major bug or security bug, or take a package from beta or rc to final), no more cleanups that might break other packages, ... - without talking about it and getting consensus in the channel
[16:58:48] <bero> I think we can allow KDE 4.10.5 and libreoffice 4.1, both projects have good track records of not releasing totally broken bits
[16:58:58] <bero> Also wine 1.6 because that's just a move from -rc to final
[16:59:25] <Pulfer> 4.10.5 will pass ROSA's QA so if anything is broken, we'll know about it soon
[16:59:44] <bero> Do you have the exact date for the 4.10.5 release plan?
[16:59:55] <Pulfer> bero: Early July
[17:00:06] <bero> Shouldn't be a problem
[17:00:23] <Pulfer> Yep
[17:00:46] <Pulfer> July 02 according to 4.10 Release Schedule
[17:01:14] <bero> Definitely no more soname updates that require a large scale rebuild unless there's EXTREMELY good reasons
[17:01:50] <Pulfer> Surely
[17:02:13] <Pulfer> As well as perl updates or something like that
[17:02:37] <bero> right
[17:03:47] <Pulfer> bero: BTW, some offtopic. Have you pushed gcc 4.8 to that personal repo already? I ask this because I have a user waiting for an answer
[17:05:10] <fedya> bero: hmm i got strange error
[17:05:26] <fedya> bero:
[17:05:54] <fedya> bero: looks culpit it is ruby-1.9.3-gnueabi.patch
[17:06:26] <bero> Pulfer: No, I didn't get to giving it some needed updating yet, currently rather busy w/ the day job (It's Linaro release week). Should have it soon though
[17:07:00] <Pulfer> bero: Ah, I see. Thanx for letting me know
[17:07:32] <bero> fedya: Looks like an armv7hl-linux-hf vs. armv7hl-linux mismatch
[17:07:53] <bero> fedya: The tcltk files seem to be in the former location while the spec expects the latter
[17:08:04] <fedya> bero: yeah i see it
[17:08:24] <fedya> bero: but location should be  armv7hl-linux-hf
[17:10:02] <fedya> bero: what do you think?
[17:13:44] <fedya> bero: i can remove "hf" from gneuabi
[17:16:58] <bero> Not sure what they expect, let's check where other distros place it for compatibility...
[17:17:24] <bero> IMO "hl" and "hf" are rather redundant, the "h" in hl already says it's hf
[17:17:31] <bero> But if that's where everyone puts it...
[17:18:24] <fedya> bero: yeah for example gentoo uses armv7a-hardfloat-linux-gnueabi
[17:22:42] <bero> Ok, I take it that means nothing else on freeze ;)
[17:22:46] <bero> So
[17:22:53] <bero> 3. AOB
[17:22:56] <bero> Do we have anything?
[17:25:32] <bero> Apparently not -- so back to work ;)
[17:28:08] <bero> Mass build still has about 8000 packages to be published
[17:28:08] <Pulfer> Yep :-)
[17:28:17] <Pulfer> Should take few days
[17:28:27] <Pulfer> Publishing seems to be the slowest part
[17:28:48] <bero> I wonder if we can speed it up somehow...
[17:29:07] <Pulfer> Perhaps ABF devs can