15:00:34 <haraldh> #startmeeting Fedora Base Design Working Group (2014-11-14)
15:00:34 <zodbot> Meeting started Fri Nov 14 15:00:34 2014 UTC.  The chair is haraldh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:40 <haraldh> #meetingname  Fedora Base Design Working Group
15:00:40 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:01:11 <haraldh> #chair dgilmore masta vpavlin
15:01:11 <zodbot> Current chairs: dgilmore haraldh masta vpavlin
15:01:21 <vpavlin> Hi
15:01:25 <haraldh> hey
15:02:10 <haraldh> dgilmore, masta : ping?
15:02:17 <nphilipp> hi
15:02:49 <haraldh> so, lets get started nevertheless
15:02:53 <haraldh> #topic Status buildrequires cleanup work (davids & nils!)
15:02:59 <haraldh> dazo, nphilipp ?
15:03:16 * masta is here
15:04:29 <haraldh> dazo, nphilipp: anything to report?
15:05:13 <nphilipp> haraldh: yes, sorry was touching base with dazo
15:05:48 <nphilipp> I'll try to summarize even though dazo did most of the work since last time -- he's preparing for a hackathon on the weekend
15:06:42 <nphilipp> On the resources side, we meanwhile have a beefy machine borrowed from Karsten Hopp on which we can do the rebuilds.
15:07:46 <nphilipp> It doesn't have too much disk space, but enough RAM to do mock rebuilds on tmpfs (which is what Benedikt did originally to speed things up). Results need to be stored elsewhere anyway.
15:09:14 <nphilipp> We've put together an initial DB scheme for storing the results of individual rebuild tests
15:10:05 <nphilipp> dazo has rolled this into a small XMLRPC server to which worker machines can submit the results
15:11:55 <nphilipp> There are some issues with timestamps and timezones with the ORM vs. the python datetime stuff (there always are) but I have dealt with that before, so is solvable
15:12:55 <nphilipp> let me scroll back to see what else he did :)
15:13:48 <nphilipp> haraldh: no, that's it for now
15:13:54 <haraldh> ok
15:14:09 <haraldh> eager to see more results :)
15:14:13 <nphilipp> heh
15:14:16 <nphilipp> we too, we too
15:14:20 <haraldh> ok, next topic
15:14:33 <haraldh> #topic Update on factory-reset work
15:14:53 <haraldh> ffesti, any solutions for us on the rpm side?
15:15:14 <haraldh> also for vpavlin and sgallagh_afk ' s request for multiple config subpackages
15:15:25 <ffesti> not news yet. I 've been on sick leaf the last two weeaks, basiaclly
15:15:38 <ffesti> and the rpm team just suffered some severe losses
15:15:45 <haraldh> that's bad to hear
15:15:54 <haraldh> gute besserung
15:16:23 <haraldh> ok, then .. next topic
15:16:33 <haraldh> #topic generic network install images
15:16:47 <haraldh> this was discussed on the mailing list
15:17:19 <haraldh> dgilmore, it has been solved from your side
15:17:21 <haraldh> hasn't it?
15:17:51 <haraldh> ah, no that were the docker images
15:18:27 <haraldh> jreznik, can you elaborate?
15:18:39 <haraldh> "One more topic - generic network install images, there was a question
15:18:39 <haraldh> raised, if Base WG would like to take care of it. I'll provide more details
15:18:39 <haraldh> in the meeting."
15:20:17 <haraldh> ... ok, seems to be afk
15:20:23 <haraldh> maybe later or next week
15:20:38 <haraldh> #topic Go software
15:20:54 <haraldh> seems to be solvable by "Provides: bundled(go) = 1.0.0"
15:21:07 <haraldh> #topic Docker update
15:21:11 <haraldh> vpavlin, ?
15:22:08 * jreznik is here, sorry for being late, I thought we start at 5 pm
15:22:17 <haraldh> 15:00 UTC
15:22:21 <vpavlin> I think we need dgilmore:) He fixed base image builds (great!) but we still don't have a way to push it to Docker Hub officially
15:22:45 <vpavlin> I like mattdm's the idea to solve rawhide case
15:22:54 <jreznik> haraldh: ah, you're right, utc and it's winter...
15:23:31 <vpavlin> And yes - pushing would require either manual steps or some temporary automation script which would take care of those manual steps...
15:24:07 <vpavlin> But that's something relengs need to solve - I am more than happy to help, but I need them to figure out the way how to do that
15:24:51 <haraldh> ok
15:25:34 <vpavlin> Not sure if you saw the Docker pull request for /run...
15:25:39 <haraldh> yes
15:25:43 <vpavlin> Still under heavy discussion...
15:26:01 <haraldh> "heavy" is a little bit exaggerated :-)
15:26:23 <vpavlin> Well..heavy in comparison with other PRs...;)
15:26:46 <haraldh> I thought the last question was only "/var/tmp"
15:26:57 <haraldh> but yeah, let's see
15:27:11 <vpavlin> True..
15:27:19 <haraldh> so, then lets revisit jreznik's topic
15:27:32 <haraldh> #topic generic network install images
15:27:37 <jreznik> #link https://www.redhat.com/archives/anaconda-devel-list/2014-November/msg00004.html
15:27:38 <haraldh> jreznik, your turn
15:28:27 <jreznik> it's still not yet resolved but there's a possibility of having "generic network install image" for f22 if we decide not to have productized network install
15:28:52 <jreznik> and mattdm mentioned, it could be interesting for base wg to own it (in case we would go this route)
15:29:51 <masta> cool
15:30:02 <haraldh> so, it's basically the anaconda installer + some minimal infrastructure to mount a network repo or get all the packages from the network
15:30:09 <haraldh> ?
15:31:20 <jreznik> yep
15:31:22 <haraldh> What exactly do you want the BaseWG to own there?
15:31:26 <masta> that was my understanding
15:31:41 <haraldh> I mean, 99% of the packages are base packages
15:31:47 <haraldh> + anaconda
15:32:00 <vpavlin> haraldh: The "product"?
15:32:07 <jreznik> haraldh: that's a good question, maybe it could be used in some way to say it's our base product?
15:32:22 <haraldh> So, we have to decide on release cycles? :)
15:32:35 <jreznik> could be an easy way to get minimal installation to users etc.
15:32:43 <jreznik> (actually it already is)
15:33:10 <mattdm> haraldh: helping test, helping define what exact functionality it has
15:33:12 <jreznik> haraldh: now, take it as heads up as I saw it on ml and base was mentioned
15:33:30 <haraldh> I think the installer defines the functionality mostly
15:34:00 <haraldh> so, it's more an installer image than a minimal system
15:34:18 <haraldh> or base product
15:34:29 <mattdm> things like the defaults in cases where a product isn't specifically selected
15:35:11 <mattdm> but the main thing is that with no one "owning" it, no one told releng that it was even wanted
15:35:41 <haraldh> ok
15:36:07 <mattdm> I don't think it's _necessarily_ a lot of extra work, but possibly some checklist items at release time
15:36:46 <haraldh> Yes, I think we can manage that
15:37:12 <haraldh> Let me put that on the table, when everybody is present (msekleta, pknirsch)
15:37:28 <mattdm> haraldh: awesome thanks
15:37:46 <haraldh> thanks jreznik, mattdm
15:38:21 <jreznik> thanks haraldh
15:38:27 <haraldh> #topic Open Floor
15:38:33 <haraldh> anything else?
15:38:44 <vpavlin> go packages?
15:39:07 <haraldh> scroll up :)
15:39:13 <haraldh> <haraldh> seems to be solvable by "Provides: bundled(go) = 1.0.0"
15:39:16 <haraldh> ffesti, true?
15:39:23 <vpavlin> aha...missed that..sorry
15:39:27 <jreznik> vpavlin: go packages, go!
15:39:57 <vpavlin> jreznik: ;)
15:40:49 <ffesti> haraldh, I am not into the spoecifics of go packaging
15:41:13 <ffesti> what are you trying to do?
15:41:31 <ffesti> (updates and obsoletes work on package names only)
15:41:59 <vpavlin> We need to have an infomration about the version of go used for the build
15:42:05 <ffesti> (just case that this was the question)
15:42:34 <haraldh> ffesti, "go" links everything statically
15:43:02 <ffesti> It should be possible to write a autogenerator that would create the necessary provides automatically
15:43:04 <vpavlin> there are go-lang packages and packages that are written in go-lang..and we need to be sure that packages written in go-lang are build from the latest possible version, but we have no way to figure that out
15:43:06 <haraldh> so, the package has to have a version of go somewhere stored, which was used to build the stufff
15:43:34 <haraldh> but as I understood, the bundled() tag should solve problems?
15:44:08 <ffesti> well, depends what you mean by "solve problems" means
15:44:25 <ffesti> you still need to rebuild the packages
15:45:00 <ffesti> a more secure way would be having a golang meta package that the packages Require with the exact version
15:45:25 <ffesti> so when you update it you know all the old (==vunerable) packages are gone
15:45:43 <ffesti> otoh I am not sure if you really want to enfore this that way
15:45:54 <ffesti> but it's probably worth a thought
15:46:07 <haraldh> an empty golang meta package?
15:46:11 <ffesti> yup
15:46:14 <haraldh> might make sense, yes
15:46:53 <ffesti> the alternative youd be to issue a meta package that does Conflicts: bundled(go) < 1.2.4
15:47:00 <haraldh> but then, as long as a package still requires the old golang, you would not get the updates :)
15:47:11 <haraldh> for _allll_ go packages then
15:47:14 <ffesti> to render broken packages illegal
15:47:42 <haraldh> but yeah, same for libs
15:48:13 <ffesti> that has the benefit of not enforcing the very exact golang version for all packages
15:48:27 <ffesti> while still being able to declare some as outdated and no longer save
15:48:43 <haraldh> I like the "Conflicts"
15:49:04 <ffesti> one needs to thing this through in more detail
15:49:28 <haraldh> Well, you are _the_ expert :)
15:49:29 <ffesti> as it clearly misuses the dependency system and may lead to very non intuitive results
15:50:35 <haraldh> on a side note, I don't like how we .. or rpm handles the whole security update
15:50:51 <haraldh> people might use "--skip-broken"
15:51:18 <haraldh> and because of their custom package, which requires the old buggy lib, the lib will not get updated
15:51:29 <ffesti> a) this is not rpm but yum/dnf
15:51:36 <haraldh> where the lib should get updated, but the custom package should fail
15:51:51 <ffesti> b) we can barly force people to install some packages
15:52:15 <ffesti> but I agree that the UI could be more clear
15:52:54 <haraldh> so yum/dnf should have a feature, where it just removes packages, which hinder a security update
15:53:07 <haraldh> or put them aside, ignore the conflict
15:53:09 <haraldh> whatever
15:53:13 <ffesti> but it is clearly the user's decision what is more important: The software to keep running or the vunerability to be closed
15:54:15 <haraldh> yeah, but nowadays, I cannot make the decision to automatically choose the " vunerability to be closed" option
15:54:33 <ffesti> I am not the one to tell our customers that fixing that bug was more important that his business
15:55:33 <ffesti> I thinik doing this automatically is much too dangerous
15:55:42 <haraldh> ofc, I can just rpm --force every signed package from RH
15:55:52 <haraldh> with my own custom script
15:56:25 <ffesti> sure, have fun
15:56:42 <haraldh> but then again, we don't have mechanisms in place, which prevent broken deps in our own releases
15:56:56 <haraldh> no tested checkpoints
15:57:05 <haraldh> at least not for Fedora
15:57:16 <ffesti> *cough* *cough*
15:57:25 <haraldh> bless you
15:58:10 <haraldh> and even worse, we allow newer packages in older releases
15:58:30 <haraldh> so updating becomes a pain every release, if you are late in the game
15:58:46 <ffesti> I am really not the person to complain to about this
15:59:01 <haraldh> no? you should
15:59:56 <ffesti> may be I missed that part of my job descripton
16:00:00 <haraldh> if you tried updating f19 to f20, with f19 having newer version-release than the f20 one, but deps on f19 packages
16:00:39 <haraldh> so, you are still running RHEL-4? :)
16:00:58 <rdieter> at least autoqa checks upgrade paths pretty well these days, and automatically disables autokarma in case of problems
16:01:19 <ffesti> There are days I wish I did
16:01:20 <haraldh> rdieter, good to hear
16:02:15 <haraldh> ok, then... let's call it a meeting..
16:02:22 <haraldh> thanks @all and have a nice weekend!
16:02:23 <rdieter> doesn't help folks who cherry pick stuff from updates-testing, then try to fedup
16:02:48 <haraldh> rdieter, that's part of the contract with "*-testing" :)
16:02:55 <rdieter> <nod>
16:02:55 * vpavlin needs to go - anything else?
16:03:12 <haraldh> #endmeeting