15:33:06 <dgilmore> #startmeeting RELENG (2015-04-13)
15:33:06 <zodbot> Meeting started Mon Apr 13 15:33:06 2015 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:33:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:33:14 <dgilmore> #meetingname releng
15:33:14 <zodbot> The meeting name has been set to 'releng'
15:33:14 <dgilmore> #chair dgilmore nirik tyll sharkcz bochecha masta pbrobinson pingou
15:33:14 <zodbot> Current chairs: bochecha dgilmore masta nirik pbrobinson pingou sharkcz tyll
15:33:16 <dgilmore> #topic init process
15:33:30 <nirik> morning
15:33:47 * sharkcz is here
15:34:19 <bochecha> sorry, I'm deep into a satellite 6 beta release, won't really be able to participate today
15:35:29 <dgilmore> #topic #5886 need method for distributing urgent fixes... urgently
15:35:36 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5886
15:36:16 <nirik> I tossed up a straw man
15:36:25 <nirik> for people to pick at.
15:36:37 <dgilmore> I have been meaning to
15:37:27 <dgilmore> some things I did think of
15:37:40 <dgilmore> we need to make atomic trees as part of the process
15:38:09 <tyll> #info make atomic trees part of the process
15:38:35 <dgilmore> we also will need to consider if we need to push out updated cloud/docker/livecds etc
15:38:55 * nirik nods.
15:39:10 <nirik> I think we need to get qa and other working groups involved to detemine that.
15:39:13 <tyll> #info < dgilmore> we also will need to consider if we need to push out updated cloud/docker/livecds etc
15:39:16 <dgilmore> something like shellshock we will need to get the rpms out quickly, but we also need to build everything else
15:39:41 <nirik> so, it's basically a new release
15:39:41 <nirik> ?
15:39:52 <dgilmore> it could be
15:39:54 <tyll> can't we start with just the RPMS and add the other items once we got at least the RPM updates out?
15:39:58 <nirik> thats kind of a second related topic tho... this is just the rpms
15:40:03 <nirik> yeah
15:40:09 <dgilmore> for shellshock we made new cloud images, and lives
15:40:21 <nirik> yeah, but we didn't end up using them did we?
15:40:34 <dgilmore> tyll: well atomic is part of the rpm update process
15:40:43 <dgilmore> so atomic tree will need to go with the rpms
15:40:48 <dgilmore> but the rest could follow
15:41:01 <dgilmore> we ended up not making the lives public
15:41:14 <dgilmore> but we did push the cloud images
15:41:41 <nirik> yeah, atomic will need to be with the rpms...
15:41:46 <nirik> although is it another branch?
15:41:47 <dgilmore> I do not know that we need testing for this
15:41:59 <dgilmore> nirik: it willneed to be teh same branch
15:42:21 <nirik> does it have base and updates? or base and updates and updates-testing? or ?
15:42:29 <dgilmore> otherwise people will not get the update without specificly requesting it
15:42:40 <dgilmore> we have two repos
15:42:56 <dgilmore> base and updates, and a second one that is base and updates and updates-testing
15:43:14 <dgilmore> you have to run a command to switch between them
15:43:58 <dgilmore> we would need to make the updates one have the urgent fixes repo enabled
15:44:06 <nirik> ok.
15:44:18 <dgilmore> well have them both with it
15:44:32 <dgilmore> not sure what config bodhi would need
15:45:11 <nirik> anyhow with that added, where do we want to go from here? talk with qa about it, devel list post for feedback?
15:45:15 <nirik> fesco ?
15:45:30 <dgilmore> probably talk to QA, then FESCo
15:46:09 <nirik> ok. I can bring it up to them next week in their meeting, or just post to their list I guess.
15:47:28 <dgilmore> probably just post to test list
15:48:27 <dgilmore> #info post to test list and engage QA
15:48:45 <dgilmore> #topic #6119 AtomicHost rel-eng integration
15:48:50 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6119
15:49:33 <dgilmore> I implemented a ugly way to make the install media for this
15:50:09 <dgilmore> the pxe to live bit has been postponed as it needs a lot of investigation and work with QA on how to build, test and update
15:50:26 <dgilmore> since the pxe tree needs updated everytime the repo changes
15:52:06 <dgilmore> hopefully going forward with the FESCo policy changes people will engage us much much sooner and it will be easier to get new things in, in a way that we can easily do.
15:53:19 <dgilmore> #topic Secondary Architectures updates
15:53:20 <dgilmore> #topic Secondary Architectures update - ppc
15:54:13 <dgilmore> sharkcz: since pbrobinson is not here, want to give us a update?
15:54:42 <sharkcz> Beta TC2 is out for about a week, we tried RC1 that should include new xorg-x11-server and tigervnc (contains big endian fix), but signing failed on Friday
15:55:03 <nirik> huh.
15:55:07 <sharkcz> there is also new gcc with added 32-bit LE support back, so we will be able to build kernel an dgrub
15:55:11 <dgilmore> I did restart the backend Friday to fix that
15:55:24 <dgilmore> nirik: teh serevr process locked up
15:55:30 <nirik> fun
15:56:11 <sharkcz> haven't heard from pbrobinson today, so I guess new TC or RC will be built tomorrow
15:56:19 <dgilmore> okay
15:56:30 <dgilmore> #topic Secondary Architectures update - s390
15:56:37 <dgilmore> how is s390 coming?
15:56:57 <sharkcz> same situation as ppc, TC2 out, new compose tomorrow
15:57:05 <dgilmore> okay cool.
15:57:11 <dgilmore> testing is okay so far?
15:57:26 <sharkcz> yes, no major issues
15:57:44 <dgilmore> cool
15:57:50 <dgilmore> #topic Secondary Architectures update - arm
15:58:00 * pbrobinson is here, sorry I'm late
15:58:09 <dgilmore> pbrobinson: how is aarch64?
15:58:15 <pbrobinson> ghc issues fixed, we're looking pretty good. Plan to cut RC1 this week
15:58:28 <pbrobinson> no major issues I'm aware of
15:59:03 <dgilmore> awesome
15:59:13 <dgilmore> #topic open floor
15:59:23 <dgilmore> anyone have anything for open floor?
15:59:29 * mstuchli does, if possible
15:59:36 <sharkcz> maybe one thing common to ppc and s390 as FYI - there is a test repo with gcc-go built docker
15:59:38 <dgilmore> mstuchli: sure
15:59:49 <mstuchli> Could we please talk about this ticket: https://fedorahosted.org/rel-eng/ticket/6147 ?
16:00:23 <dgilmore> mstuchli: okay, the guidelines have to be approved by the FPC
16:00:36 <mstuchli> So EPSCO is not enough?
16:00:37 <dgilmore> and put into the official packaging guidelines space
16:00:42 <dgilmore> mstuchli: not at all
16:00:47 <mstuchli> I see
16:01:11 <dgilmore> I do not remeber seeing them come across and i did not vote on them and I am a member of EPSCO
16:01:12 <nirik> well, I am pretty sure they will say that epel can do whatever it wants they don't care...
16:01:23 <dgilmore> I would have voted no to the proposal
16:01:34 <dgilmore> nirik: it effects fedora also
16:01:36 <nirik> dgilmore: then do you have any counter proposal on how to do it?
16:01:39 <dgilmore> so they will not
16:01:51 <mstuchli> For that see the link to the mailing list I posted to the ticked, from that I understood that it passed
16:01:57 <dgilmore> nirik: no, i have not thought about it at all
16:02:15 <nirik> well, we really want to get python3 going... it's been discussed for ages.
16:02:37 <dgilmore> mstuchli: adding packages to the minimal buildroot is quite expensive
16:03:05 <nirik> mstuchli: what are the deps on that macros package?
16:03:09 <dgilmore> mstuchli: likely the macros should be added to redhat-rpm-config
16:03:30 <dgilmore> we do have some epel macros specified somewhere
16:03:42 <nirik> epel-release sadly
16:04:16 <mstuchli> nirik: Deps? Do you meant what the package requires?
16:04:27 <mstuchli> d
16:04:35 <nirik> yeah, I mean if it's just some macros it should need almost nothing?
16:05:06 <nirik> but if dgilmore prefers we put it in redhat-rpm-config/epel-release thats fine with me too. I thought there was some reason we didn't want to do that tho
16:05:48 * mstuchli is sorry, had to do something
16:05:52 <nirik> we twiddle these macros depending on the python3's that are available right?
16:05:56 <mstuchli> nirik: Correct, that's the case
16:06:00 <mstuchli> Yes
16:06:12 <nirik> right, and we didn't want to change epel-release all the time
16:07:01 <dgilmore> perhaps we need a epel-rpm-config package then
16:07:17 <nirik> yeah, thats an option too...
16:07:59 <dgilmore> I am very very strongly against adding random packages to the minimal buildroot and to me the request to add python3-pkgversion-macros is just that
16:08:04 <nirik> mstuchli: and we need this for fedora too so people can reuse specs right?
16:08:17 <mstuchli> nirik: Correct
16:08:25 <dgilmore> it involves some buildsys changes, comps changes, and effects many pieces
16:08:27 <nirik> mstuchli: so yeah, that part should go to FPC...
16:08:40 <dgilmore> and adds an extra thing to install in every single buildroot
16:08:57 <nirik> dgilmore: ok, but an epel-rpm-config would be acceptable (and move the ghc macros from epel-release to it)
16:09:00 <mstuchli> Humm, okay, I'll look into that then
16:09:15 <nirik> mstuchli: let me know if you need any pointers on it. Happy to help
16:09:28 <dgilmore> nirik: yes, though I think the ghc one is required by epel-release
16:09:33 * dgilmore forgets
16:09:48 <nirik> I thought we just put them there because we didn't have a epel-rpm-config. ;(
16:09:48 <dgilmore> but we shouold have a single point of setting macros
16:09:53 <dgilmore> not multiple points
16:10:04 <nirik> I can look at that and making such a package.
16:10:11 <dgilmore> nirik: they were in epel-release originally
16:10:15 <mstuchli> nirik: Okay, thanks a bunch! :)
16:10:25 * nirik adds to his todo
16:11:06 * masta is here
16:11:19 <masta> just in time for open floor
16:11:20 <dgilmore> http://paste.fedoraproject.org/210355/41471142/
16:11:33 <dgilmore> the epel7 buildroots do not list and ghc packages
16:13:23 <nirik> right, it's just got macros in the epel-release package.
16:13:39 <dgilmore> nirik: not in epel7
16:14:06 <nirik> right, there it only has the %epel macro
16:14:08 <dgilmore> I guess in epel7 the macros are in RHEL itself
16:14:25 <nirik> in 6 it has the ghc ones.
16:14:30 <dgilmore> yeah
16:14:51 <dgilmore> so they moved from epel-release to redhat-rpm-config I guess
16:14:52 <nirik> anyhow, a epel-rpm-macros makes sense to me especially if we have to tweak it all the time
16:15:24 <nirik> yes, redhat-rpm-config in rhel7 has ghc macros
16:15:26 <dgilmore> mstuchli: but we can not change anything until FPC signs off
16:15:53 <dgilmore> mstuchli: in fedora the macros would have to go into redhat-rpm-config
16:16:06 * mstuchli nods
16:16:28 <dgilmore> mstuchli: possibly we could ignore it in fedora alltogether and make sure they have ? so when they are undefined tehy do not cause an error
16:16:55 <dgilmore> mstuchli: but either way FPC controls the packaging guidelines and they need to put them in place
16:17:01 <mstuchli> dgilmore: I *think* that would be possible, yes
16:17:42 <dgilmore> mstuchli: does that answer things for you?
16:18:06 <mstuchli> Yes, I'll take it over with bkabrda, I'll see about the FPC thing
16:18:08 <mstuchli> Thanks :)
16:18:18 <dgilmore> great thanks
16:18:49 <dgilmore> sharkcz: did you have something?
16:21:24 <dgilmore> i will take that as a no
16:21:52 <dgilmore> I need to file a ticket with planned changes for f23
16:21:55 <dgilmore> ill wrap up
16:21:59 <dgilmore> #endmeeting