16:44:11 <dgilmore> #startmeeting RELENG (2015-03-16)
16:44:11 <zodbot> Meeting started Mon Mar 16 16:44:11 2015 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:44:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:44:20 <dgilmore> #meetingname releng
16:44:20 <zodbot> The meeting name has been set to 'releng'
16:44:20 <dgilmore> #chair dgilmore nirik tyll sharkcz bochecha masta pbrobinson pingou
16:44:20 <zodbot> Current chairs: bochecha dgilmore masta nirik pbrobinson pingou sharkcz tyll
16:44:21 <dgilmore> #topic init process
16:44:33 <dgilmore> who is here?
16:44:45 * sharkcz is here
16:45:13 * nirik is here.
16:45:29 <dgilmore> #topic #5931 [Proposal] Move new branch and unretire requests to pkgdb2
16:45:35 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5931
16:45:41 * masta is here
16:46:07 <dgilmore> need pingu for this
16:46:15 <dgilmore> nirik: have we deployed it yet?
16:46:31 <nirik> no. he was out last week...
16:46:40 <nirik> I can ask him for status tomorrow
16:46:45 <dgilmore> okay
16:46:56 <dgilmore> #info hopefully deployed this week
16:47:07 <dgilmore> #topic #6016 Use fedpkg-minimal in Fedora buildroots
16:47:14 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6016
16:47:20 <dgilmore> #info this is now done
16:47:38 <masta> nice
16:47:48 <masta> how much faster was it?
16:48:14 <dgilmore> masta: about 1 minute on arm and 20 seconda on x86
16:48:33 <masta> cool, might seem small butin a mass build it will be noticed.
16:48:44 <dgilmore> yep
16:48:55 <dgilmore> and makes the srpm buildroot less fragile
16:49:01 <dgilmore> #topic #5963 Orphaned vulnerable packages in EPEL
16:49:07 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5963
16:49:25 <dgilmore> AFAIK this has been done now, though there was some complaints about it
16:49:35 <nirik> yeah, its done
16:50:08 <dgilmore> #info this has now been done
16:50:47 <dgilmore> #topic #6119 AtomicHost rel-eng integration
16:50:53 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6119
16:51:03 <dgilmore> SO this has some pretty major issues
16:51:17 <dgilmore> rpm-ostree-toolbox is a great tool for end users
16:51:26 <dgilmore> but has zero integration into koji
16:51:41 <dgilmore> or any of the releng tooling or processes
16:52:26 <nirik> this needs to be sorted before beta? or ?
16:52:31 <dgilmore> we make the existing images using ImageFactory that same as rpmos-tree-toolbox does
16:52:37 <dgilmore> nirik: I guess
16:53:04 <dgilmore> It should have been sorted for Alpha
16:53:24 <dgilmore> since the feature is supposed to be testable by Alpha
16:53:44 <dgilmore> we currently make the atomic trees in a mockchroot, which is not really okay
16:53:53 <dgilmore> it needs to be a koji task
16:54:04 <dgilmore> so we get public logging and visability
16:54:17 <threebean> so, we just need someone to write that patch?
16:54:30 <dgilmore> threebean: yes
16:55:12 <dgilmore> there is the other piece that is making the atomic install iso and pxe tree
16:55:25 <dgilmore> that really needs to be integrated into pungi
16:56:18 <threebean> I can look at the koji half and report back next week.
16:56:58 <threebean> it's already being accomplished in the releng scripts right now, so it won't hold up Beta if it doesn't work out, correct?  it's just currently being accomplished in an undesirable way?
16:57:02 <dgilmore> there is a reason why we are not using livemedia-creator years after it was written, and it seems that this has gone off and repeated history by walters going off and writing something rather than asking what the requirements are and working with us to come up with an acceptable solution
16:57:15 <dgilmore> threebean: right
16:57:36 <dgilmore> threebean: the main issue is the desire for the install iso and network install tree
16:58:32 <walters> i didn't write livemedia-creator fwiw
16:58:33 <dgilmore> I would rather do it once and right, than hack something in, because if we hack something in the chances are high that we won't fix it
16:58:41 <dgilmore> walters: I am not saying you did
16:58:49 <walters> i'm pretty sure you just did
16:58:57 <dgilmore> walters: I am saying you did the same thing, went off and wrote something we can not use
16:59:08 <dgilmore> walters: not at all
16:59:17 <dgilmore> if you read it as that I am sorry
17:00:03 <dgilmore> I think rpm-ostree-toolbox is a great end user tool
17:00:14 <dgilmore> it just does not fit into what we need in Fedora
17:00:15 <walters> ok let's focus on actionable items here
17:00:26 <walters> do you have a concise link/description to the livemedia-creator issues?
17:00:29 <dgilmore> the image part we have handled already
17:00:55 <dgilmore> walters: there was a few issues with livemedia-creator, biggest being that it could not be run in mock
17:00:57 <walters> (would have been nice to get a ping when the topic is discussed at the start btw)
17:01:05 <dgilmore> walters: that is fixed and we now need koji integration
17:01:37 <dgilmore> walters: we need inteagration into pungi to make the install iso
17:01:52 <walters> ah, we're using docker for the chroot creation currently
17:01:52 <dgilmore> and we need to have integration into koji to make the atomic tree
17:02:30 <dgilmore> walters: we do not currently have anything using docker and without major work its not a suitable means of doing things
17:03:07 <dgilmore> we need to be able to cleaning make the compose environment using the needed pieces
17:04:01 <walters> i think the mock/docker needs a more detailed discussion
17:04:01 <dgilmore> walters: so when we have a new lorax, anaconda, pungi, mash, etc we have to make sure we are using that new version
17:04:22 <dgilmore> walters: it is something that can be looked at down the road, but not today
17:05:05 <walters> this doesn't really feel like a discussion, but more a list of decisions you've already made
17:05:07 <dgilmore> walters: we need to make sure that we can make the deliverable for all possible arches
17:05:25 <walters> (and not put in the ticket)
17:05:49 <dgilmore> walters: perhaps, it is how we do things, we have long term plans to change that. but short term we do not have the ability to change
17:06:13 <dgilmore> walters: I have been nusy and trying to think of the best way to communicate the concerns
17:06:15 <masta> does it need to be a custom task, or can we leverage runroot?
17:06:21 <dgilmore> s/nusy/busy/
17:06:40 <masta> walters: does it need any special root privs?
17:06:50 <walters> everything involving rpm needs root
17:06:56 <dgilmore> masta: we do not have runroot working
17:07:14 <masta> dgilmore: oh my bad, ok then... custom task for now
17:07:15 <walters> (gnome-continuous doesn't, source code all the way to disk images as non-root)
17:07:28 <dgilmore> we need pungi integration to make the install tree
17:07:42 <walters> fixing that is a much more interesting task
17:07:53 <walters> hmm
17:08:10 <dgilmore> walters: how gnome-continuos and Fedora do things are very different, they have different concerns and targets
17:08:17 <walters> isn't it enough that they share lorax?
17:08:52 <dgilmore> walters: we can look at how things are done to see what we can learn, but we have our existing workflows and processes and we need to fit within them
17:09:44 <dgilmore> walters: no.  though we are going to use a majorly different version of pungi in f23 and it will have to have tighter coupling there
17:09:59 <dgilmore> so potentially we can look at something short term for Fedora 22
17:11:38 <dgilmore> walters: we have to use the target os to compose teh target os
17:11:55 <dgilmore> which I guess seems somewhat strange, but that is how we do thing
17:12:02 <walters> did you need me here at the meeting?  why not just summarize all of the decisions beforehand in the ticket?
17:12:12 <dgilmore> we use mash to make the yum repos
17:13:28 <dgilmore> we then use those yum repos to make the install tress, livecds, arm images and atomic repo, we use the install trees and atomic repo to make the cloud images
17:13:41 <walters> i'll try to do that now
17:13:45 <dgilmore> walters: you are the one taht added teh item to the meeting.
17:14:08 <dgilmore> walters: had you come and talked at the start we could have told you the requirements
17:14:23 <dgilmore> rather than showing up and saying here is this thing go and use it
17:14:39 <walters> that's not *at all* what i was saying
17:14:52 <dgilmore> walters: I think that the what you have done is great for end users to make their own trees, images and installers
17:14:58 <walters> i was looking for compromise, discussion, cooperation
17:15:00 <dgilmore> It is not at all wasted effort
17:15:24 <walters> that's why i'm here on irc now, to have a conversation
17:16:16 <dgilmore> walters: I am willing to look at doing something for f22.  f23 is going to have massively changed compose processes
17:16:24 <walters> and i'm willing to change code
17:16:56 <dgilmore> walters: not sure you need to change the rpm-ostree-toolbox code. it seems to be a great end user tool
17:17:40 <dgilmore> walters: https://git.fedorahosted.org/cgit/pungi.git/log/?h=pungi-4-devel is the pungi rewrite we are working on for f23
17:18:18 <dgilmore> we will need to have everything integrated into it
17:18:59 <dgilmore> perhaps for f22 we can run lorax in a mock chroot
17:19:04 <dgilmore> it is not ideal
17:19:13 <nirik> so, really here we need: f22 actions and then look more at f23?
17:19:17 <dgilmore> because it does give us public visability
17:19:23 <dgilmore> nirik: right
17:19:36 <nirik> so what are those? /me is kinda lost here.
17:19:41 <dgilmore> and of the things the only thing we do not currently do is the install media
17:19:56 <dgilmore> at least if i understand it correctly
17:20:08 <walters> and pxetolive
17:20:20 <dgilmore> walters: is that correct? we just need to make the install media?
17:20:41 <walters> pxetolive as well
17:21:13 <dgilmore> walters: the pxe tree is part of the lorax output when making the install media correct?
17:21:21 <walters> that's pxe-to-install
17:21:30 <walters> pxe-to-live is for diskless servers
17:21:46 <dgilmore> okay, and how is that made?
17:21:50 <walters> livemedia-creator
17:22:11 <walters> conceptually anaconda itself is a live system, it's a stripped down desktop that runs one app
17:22:22 <dgilmore> ::sigh:: okay, apparently we can now run that in a chroot
17:22:33 <walters> so livemedia-creator is a slight abstraction of that that drops out the desktop app part and is more configurable
17:22:49 <dgilmore> so in theory we will need to run lorax and livemedia-creator in a mock chroot
17:23:08 <nirik> and that needs a koji plugin to do that? or runroot working?
17:23:12 <walters> it's been working fine inside docker containers, FWIW
17:23:32 <walters> i'm not opposed to using mock either
17:23:33 <dgilmore> nirik: well quickest way is to do it like we are doing pungi
17:23:43 <nirik> oh yeah. gross. ok.
17:23:53 <dgilmore> it is going to make the compose process longer
17:24:06 <dgilmore> walters: we can not use docker today
17:24:21 <nirik> the entire thing needs consolidation and re-writing. I don't think anyone will disagree. ;)
17:24:22 <dgilmore> not without a massive amount of work
17:25:06 <dgilmore> walters: we have no tooling to make anything but a docker base image
17:25:35 <walters> https://github.com/projectatomic/rpm-ostree-toolbox/blob/master/src/py/rpmostreecompose/docker_image.py
17:25:43 <dgilmore> and I guess we could make a base image as part of the compose process that had everything we needed in it
17:25:47 <walters> it's the ~100 lines of trivial code to yum --installroot + docker load
17:25:57 <dgilmore> but it is more work that I am willing to do for f22
17:26:16 <walters> (i don't think anaconda should be involved in docker base images myself, but that's a different discussion)
17:26:42 <walters> but the above is how -toolbox synthesizes correctly up to date images, like mock does
17:26:52 <dgilmore> walters: that is the it was decided internally to make docker base images. we inherited it
17:27:55 <dgilmore> the way it was
17:28:17 <dgilmore> anyway so for f22 we will run lorax and livemedia-creator in a mock chroot
17:28:29 <nirik> there may be some good advantages to replacing mock with docker... but not in f22.
17:28:32 <walters> ok, so not using -toolbox as it is today
17:28:37 <dgilmore> walters: we will need either one or two kickstarts
17:28:42 <dgilmore> walters: no
17:28:49 <walters> i think i could pretty easily extract the raw code to use lorax for the installer
17:29:45 <walters> hmm, what if I made "rpm-ostree-toolbox installer-raw" or so?  That rel-eng could run inside mock?
17:30:27 <dgilmore> walters: I would rather just feed lorax and livemedia-creator kickstarts and getting the output
17:31:13 <walters> #action walters to look at running lorax and livemedia without -toolbox
17:31:32 <dgilmore> walters: do you have kickstarts?
17:31:37 <walters> yep
17:32:08 <walters> https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-atomic-pxetolive.ks
17:32:53 <dgilmore> walters: its the same kickstart for both?
17:33:04 <walters> there's quite a lot that's suboptimal about the above, which circles back to my desire to be writing code and fixing content issues
17:33:26 <walters> a kickstart for the installer?
17:33:41 <walters> it's just lorax, except for https://github.com/projectatomic/rpm-ostree-toolbox/blob/master/src/py/lorax-embed-repo.tmpl
17:34:26 <dgilmore> walters: a kickstart for lorax and one for livemedia-creator
17:34:52 <walters> lorax doesn't take kickstarts (that I'm aware of), it has templates that come with the tool itself
17:35:01 <dgilmore> walters: so we need two kickstarts in spin-kickstarts
17:35:28 <dgilmore> walters: we do not use lorax directly in fedora, pungi takes kickstarts
17:35:51 <walters> so i don't want to take over this whole meeting time, this seems like something where we should be determining high level requirements, allowing each other to work on action items asychronously?
17:36:36 <nirik> and IMHO those should be 'get it working enough now in f22 in existing processes' and also 'make it use a better process potentially in f23+'
17:36:46 <dgilmore> walters: --add-template=ADD_TEMPLATES Additional template to execute
17:36:59 <dgilmore> so we will need a lorax templace in spin-kickstarts
17:37:18 <dgilmore> and we will add it when executing lorax
17:37:55 <dgilmore> walters: we should make a directory for teh lorax template
17:38:27 <dgilmore> walters: for f23 we will need to integrate into pungi
17:40:15 <walters> spin-kickstarts/atomic-installer/lorax-embed-repo.tmpl ?
17:40:16 <dgilmore> #action dgilmore and walters to get things lined up in spin-kickstarts and have the tasks running in mock
17:40:23 <dgilmore> walters: that is fine
17:40:40 <dgilmore> okay lets move on
17:41:08 <dgilmore> #topic #6130 Remove all permissions when packages are retired in a branch
17:41:11 <walters> thanks, pushed
17:41:15 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6130
17:41:46 <nirik> I think we should get pingou's input here. I seem to recall we had it doing that at first and it caused problems.
17:41:52 <walters> great, thanks for the feedback, i'll see what i can do to extract some bits from -toolbox for use in mock.  (FWIW I think -toolbox is not the best code in the world, but it is tested and working, so the key is to keep that aspect while moving forwards)
17:41:53 <dgilmore> yeah
17:42:31 <dgilmore> walters: I think toolbox is a great tool for people to build and deploy thier own atomic repos
17:43:01 <dgilmore> nirik: yeah, I think the request has a bit too much emotion behind it
17:43:17 <dgilmore> and we need some technical opinion
17:43:56 <dgilmore> #info neeed to have some feedback from at least pingu and need to look into it closer to see the technical pros and cons for making such a change.
17:44:08 <dgilmore> #topic Secondary Architectures updates
17:44:09 <dgilmore> #topic Secondary Architectures update - ppc
17:44:19 <dgilmore> sharkcz: any update here?
17:44:32 <sharkcz> yes, a bit
17:45:34 <sharkcz> pbrobinson tried a compose last week, the process worked, but we hadn't enough content in the f22-Alpha tag cloned from primary like anaconda (in the exact NVR), so it failed, we should get this fixed this week
17:46:13 <sharkcz> the last known big endian related bug in gcc was fixed last friday, so should be safe using the llatest gcc
17:46:33 <dgilmore> cool
17:47:14 <dgilmore> #topic Secondary Architectures update - s390
17:47:41 <dgilmore> how is s390 sharkcz?
17:48:13 <sharkcz> I tried a compose last Thursday mainly to see whether the tools work, and they do, we also hadn't the complete f22-Alpha so it was from the actual content
17:48:22 <dgilmore> okay
17:48:31 <dgilmore> how far behind is s390 and ppc?
17:50:06 <sharkcz> haven't measured it today, but should be ~200 builds for s390 (it has updates-testing too since today) and a bit more for ppc
17:50:15 <dgilmore> okay
17:50:20 <sharkcz> we got behind due the gcc
17:50:25 <dgilmore> so maybe Alpha next week?
17:51:18 <sharkcz> yes for ppc, for s390 I'll probably skip it due the known bugs (kernel panic at the end and couple more), or include the latest kernel, will see
17:51:26 <dgilmore> okay
17:51:32 <dgilmore> #topic Secondary Architectures update - arm
17:52:00 <dgilmore> http://armpkgs.fedoraproject.org/compose/22_Alpha_RC1/
17:52:08 <dgilmore> there is a RC1 compose for Alpha
17:52:19 <dgilmore> I asume pwhalen is getting people to test it
17:52:28 <nirik> cool
17:52:46 <dgilmore> though it looks like it may have failed
17:52:48 <pwhalen> dgilmore, no, incomplete
17:53:01 <dgilmore> pwhalen: any idea what the holdup is?
17:53:42 <pwhalen> there are some kernel hang issues pbrobinson was fighting for the compose, I havent talked to him today
17:53:42 <sharkcz> xorg-x11-drv-qxl is needed by xorg-x11-drivers-7.7-12.fc22.aarch64 is in the log
17:53:58 <dgilmore> :( okay
17:53:58 <pwhalen> my understanding was he hacked aroudn that for now
17:54:32 <dgilmore> alright
17:54:44 <dgilmore> hopefully Alpha for aarch64 next week also
17:54:47 <dgilmore> #topic Open Floor
17:54:55 <dgilmore> anyone have anything for open floor
17:55:53 <dgilmore> I guess I have one thing
17:56:26 <dgilmore> rawhide is installable right now, we are using pungi 4.0 development branch in rawhide
17:56:38 <dgilmore> so it is using a very different code base
17:58:48 <dgilmore> anyway
17:58:52 <dgilmore> #endmeeting