16:29:17 #startmeeting 16:29:17 Meeting started Mon Jan 6 16:29:17 2014 UTC. The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:29:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:29:23 #meetingname releng 16:29:23 The meeting name has been set to 'releng' 16:29:34 #topic whos is here 16:30:01 ping nirik masta dwa tyll_ rdieter 16:30:09 hey. 16:30:32 * dgilmore failed to send out an agenda 16:30:44 morning 16:30:47 I am on my way 16:30:53 I'm here, but not "officially" releng (yet) 16:31:43 I am tyll 16:31:46 danofsatx: welcome :) 16:31:54 tilldroid: :) 16:32:11 * rdieter waves, hola 16:32:21 will wait a couple of minutes for dwa and masta 16:32:21 * sharkcz is here 16:32:25 hola sharkcz 16:32:30 hi Dennis 16:32:43 dgilmore: I'm here 16:32:57 sorry i forgot to ping you sharkcz 16:33:37 np :-) 16:36:28 okay lets get started 16:36:55 #topic tickets 16:37:07 right now we have no tickets in the meeting queue 16:37:41 #info 16:37:51 There are some old Tickets wäre it is unclear what the next action is 16:37:53 #info https://fedorahosted.org/rel-eng/report/10 the report for teh meeing items 16:38:33 if you have anything you want discussed during the meeting add the meeting keyword 16:38:47 tilldroid: okay. which ones? 16:40:06 5418 16:40:32 Imho it should be closed wontfix 16:40:45 tilldroid: thats really not a releng thing as we dont process the scm queue 16:41:10 the processing of the queue is kind off a strange area though 16:41:21 So it can be forwarded to fesco? 16:41:22 ~there is a few people that have been doing it forever 16:41:46 i honestly think we should just close it cantfix 16:41:58 and there is nothing to do 16:42:33 not sure why that ticket did not show up in the meeting report 16:44:26 another old ticket is https://fedorahosted.org/rel-eng/ticket/4084 - it is about multidep breakage 16:44:35 *multiarch 16:44:39 i guess one option is to pull processing the SCM queue into releng 16:44:53 but even then I wouldn't change it 16:45:49 its sat there as without major work to mash we can not do anything 16:46:57 I honestly do not know the best way to deal with it 16:47:58 it boils down to mash would need to know whats multilibbed in relesase repos 16:48:11 then make sure the same things get done in updates 16:48:27 we would never be able to unmultilib something 16:49:19 we would need to add a whole lot of heavyweight wrapping in the process to make sure of things 16:49:35 the process is already heavy and time consuming 16:50:03 there is no clear point where we could break things with history 16:51:36 tyll_: not sure that answers things for you 16:52:20 dgilmore: maybe the bug can then get a more describtive title, because currently it sounds gcc specific, but it is actually some mash problem I do not really understand :-( 16:52:42 this might make it clear that it is nothing that can be done right now 16:52:47 tyll_: yeah. and its not really a huge problem 16:53:21 but it boils down to the way we do multilib in the repos depends on the contents of the repos 16:53:30 the checking is self contained 16:54:22 so if nothing in say the updates repo pulls in a package to be multilibbed but it was multilibbed in the release tree you may hit an issue 16:54:48 I'm of a mind to say wontfix (for now, at releng level at least) 16:55:12 and recommend focus on fixing the packaging bugs that cause the problem(s) 16:55:54 rdieter: it may not be a packaging bug 16:56:18 I thought in this particular case it was, some -devel pkgs with a dep: gcc-gfortran(x86-32) 16:56:26 foo-lib is pulled into being multillibed due to bar requiring it only 16:56:31 foo is updated 16:56:50 * masta looks in 16:56:55 sry I'm late.... 16:56:58 but it doesnt get multilibbed in updates repo as bar wasnt rebuilt 16:57:29 bar is multilibbed due to having a bar-devel sub-package 16:57:38 foo doesnt for some reason 16:57:54 honestly its a pulling at straws senario 16:58:19 rdieter: yeah i think this case was a packaging bug 16:58:43 is there a mash specific bug tracker? 16:58:48 tyll_: any other tickets you would like to discuss? 16:58:57 tyll_: bugzilla 16:58:58 * rdieter doesn't follow that example exactly, but still would argue that until its understood fully to be *not* a packaging bug, the resources/energy required to fix/workaround at releng level simply isn't worth it 16:59:41 https://fedorahosted.org/rel-eng/ticket/3624 16:59:59 This sounds like it can be easily fixed or might already be fixed 17:00:30 there is a script in puppet/ansible that gets run to update the filelists 17:01:47 tyll_: so some issues 17:02:19 there is 3 different machines that could be updating that fullfilelist file 17:02:30 all could be doing it at once 17:02:40 so really it needs some kind of network lock 17:02:48 maybe using nfslock 17:03:08 if the process cant get a lock it needs to wait 17:03:27 as the process making the current file could miss the changes we are updating it for 17:04:40 so its not fixed, it is fixable, the fix needs some thought to ensure processes dont fight each other 17:05:01 tyll_: its the kind of thing id actually like to just pull out of the composedb 17:05:36 ah, ok, I'll update the ticket with this information 17:06:25 http://paste.fedoraproject.org/66190/13890279/ is the current script thats used 17:06:56 we could easily add compression 17:07:54 it could also tie into fedmsg? 17:08:08 (ie, something finished that would cause updates to the flielist) 17:08:19 nirik: yeah 17:08:32 so we could work a few different ways to redo the process 17:10:37 anyway 17:10:56 I could take a look into fedmsg integration, but I do not have access to the system so it is pretty abstract to me what is happening there 17:11:48 tyll_: you probably do, I can work with you later to make sure you do 17:12:43 dgilmore: ok 17:13:06 okay lets move on 17:13:24 #topic s390 status 17:13:37 sharkcz: want to give us a quick status update 17:14:24 I'm doing last steps before releasing, all stuff is in place, running hardlink right now 17:14:36 okay cool 17:14:56 I've rerun last branched with fixed inheritance and fixed key id so all mashed rpms are signed 17:15:10 https://bugzilla.redhat.com/show_bug.cgi?id=1048189 is the update to mash configs 17:15:21 yeah, the key ID thing drove me nuts too before figuring out what it was :( 17:15:55 sorry i failed there 17:16:42 sharkcz: hows updates etc? 17:17:06 mostly done and signed, will mash them soon 17:17:18 cool 17:17:32 okay lets move on. 17:17:39 #topic ppc status 17:17:44 dwa: hows things ? 17:18:08 We released F20 for Power before the break, and have been signing/mashing/pushing updates as normal 17:18:18 this week we're planning on doing some koji maintenance - system updates, etc. 17:18:38 cool 17:18:39 we should also be receiving some new Power systems from IBM soon - they'll support both KVM virt (instead of PowerVM) and PPC64LE 17:18:47 nice 17:18:53 cool 17:19:02 so we will need to come up with a plan to do the ppc64le bootstrap 17:19:09 last I heard we were waiting on loaner agreements etc. to get signed 17:19:32 yeah, once we get hardware we'll be able to actually do stuff. last I heard from IBM the ppc64le ABI was still a little unstable, though 17:20:05 :( 17:20:14 so they were doing more rebuilds from scratch internally 17:20:35 but hopefully they'll find all the bugs and everything will work perfectly the first time for us ;) 17:21:19 that would be nice 17:22:05 okay 17:22:13 that's it from me 17:22:17 #topic arm status 17:22:28 aarch64 has has a few bugs to get fixed low down 17:22:34 but is slowly getting there 17:22:51 going to look at enabling rawhide this week 17:23:02 32 bit updates slowly are gtting out 17:23:26 with f18 eol next week softfp will be dead 17:23:27 dgilmore: what low down things in aarch64? 17:24:20 dgilmore: stuff related to using the foundation? 17:24:49 masta: some bugs in elfutils i believe 17:25:33 okay 17:25:38 #topic open floor 17:25:46 anyone have anything they want to discuss 17:26:12 I did the updates push last two weeks, somebody else turn 17:26:45 we should probably setup a fedocal for this 17:26:45 dwa: want to? 17:26:56 masta: yeah thats on the list to do 17:27:29 I think dwa was last week, but pto... so I covered 17:27:30 yeah, happy to 17:27:46 and agree, a calendar somewhere would be excellent :) 17:27:59 masta: thanks for that, btw 17:28:18 okay dwa for updates this week 17:28:41 I would like to propose to somehow organise the trac items so that task-like items can be better separated from other items that only need to be done eventually such as tooling changes 17:29:07 tyll_: okay, i can make you an admin to make catagories etc 17:29:13 im going to fossdem and devconf at the end of the month 17:29:36 as devconf im giving a talk on future things for releng and how people can help to deliver them 17:30:21 dgilmore: I am planning to go to fosdem as well 17:31:03 tyll_: excellent will be good to meet you finally 17:31:48 =) 17:33:41 over the christmas break i worked on changing my blog 17:33:54 im planning on writting more often about whats going on in releng 17:34:12 and try spark interest in people to get involved 17:34:21 anything else? 17:34:29 if not we just have gon over an hour 17:34:35 ill wrap up 17:35:27 #endmeeting