15:01:07 <pknirsch> #startmeeting Fedora Base Design Working Group (2013-12-13)
15:01:07 <zodbot> Meeting started Fri Dec 13 15:01:07 2013 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:15 <pknirsch> #meetingname  Fedora Base Design Working Group
15:01:15 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:01:32 <pknirsch> hello and welcome everyone!
15:01:35 <jwb> hello
15:01:52 <notting> hello
15:02:03 <pknirsch> #chair jwb notting jreznik
15:02:03 <zodbot> Current chairs: jreznik jwb notting pknirsch
15:02:51 <haraldh> <-
15:03:01 <pknirsch> #chair haraldh
15:03:01 <zodbot> Current chairs: haraldh jreznik jwb notting pknirsch
15:03:20 <pknirsch> Let's get started then.
15:04:05 <pknirsch> I just wanted to follow up on the things we've discussed last week
15:04:25 <pknirsch> #topic  Buildreq cleanup initiative
15:05:08 <pknirsch> So it took me a bit longer to put together that ugly hack of a python script, but i've posted it yesterday and started doing several queries with it
15:05:43 <pknirsch> also we've had a few good responses and suggestions already which could potentially make things a bit easier
15:06:17 <pknirsch> then main one was from Vit about trying to strip down BRs from packages and see a) whether they still build and b) produce the same results as with the BRs
15:07:34 <sghosh> sorry I am late
15:07:42 <pknirsch> Bruno wolf suggested to use rpmdiff for b) and thats certainly a good starting point
15:07:45 <pknirsch> heya sghosh :)
15:07:51 <pknirsch> #chair sghosh
15:07:51 <zodbot> Current chairs: haraldh jreznik jwb notting pknirsch sghosh
15:08:32 <pknirsch> for a) i'm still unsure as i'd love to do that automatically as well, but i'm pretty certain we don't have any tool that does that
15:08:49 <pknirsch> so that would need some work, but i'll definitely look into that
15:09:28 <pknirsch> secondly, having a visualization of the BR, even for a subset of packages has proven to be really helpful (karsten hopp used that several times).
15:10:03 <pknirsch> I've tested some python code we wrote quite a while ago, but that seems to barf at modern rpms right now, so need to look into that, too
15:10:26 <notting> visual, as in with dot or something?
15:10:32 <pknirsch> jep
15:10:39 <pknirsch> works for smaller sets of packages
15:11:04 <pknirsch> but for larger ones the dot2pdf file makes evnice segfault :)
15:11:15 <notting> yeah. at this point, i don't think we can request a new 5 story office just to display the dep graph
15:11:28 <pknirsch> and dot itself i stopped after about 1h of trying to render it
15:11:32 <pknirsch> hehe, right
15:12:09 <pknirsch> what i might be able to pull do though is generate some more statistics that could prove helpful:
15:12:23 <pknirsch> how many packages BR something else
15:13:01 <pknirsch> which would make it a hotspot to look at, resp. for singular BRs we could see if those could be dropped or modified
15:13:46 <pknirsch> maybe i can even somehow export it into jgraph, but that didn't look too straight forward so far
15:14:45 <haraldh> What we probably need is a solution to the problem of BR of BR, which just add features, which are not needed by Base
15:14:47 <pknirsch> also as a second followup to the cleanup of docs, jreznik talked with Jan of the rpm/yum team about it and he has some ideas of how that can be achieved. mattdm might have used some of those ideas in the cloud images already
15:14:59 <pknirsch> true
15:15:09 <pknirsch> or remove dead BRs
15:15:20 <jwb> pknirsch, installation of docs or building of docs?
15:15:24 <pknirsch> something Florian in the office here mentioned today
15:15:30 <jwb> because building of docs is the larger problem imo
15:15:56 <haraldh> or e.g. if systemd has a GUI, which needs gnome-devel, we would have a problem
15:15:57 <pknirsch> jwb: i think it's mainly installation, but ye, building docs is the bigger issues
15:16:56 <jreznik> I can check it in more details with him
15:17:20 <jreznik> we just had a quick talk and I'll try to note it/email it to the list
15:17:28 <haraldh> or, we solve the problem by building "subpackages" with the same source tarball, be it GUI, or docs
15:17:30 <jreznik> just it was a bit more busy week than I thought :)
15:18:05 <Viking-Ice> I thinks split into subpackages would be the way to go for docs stuff
15:18:29 <jwb> Viking-Ice, as i said last week, subpackages do not help the BR issues
15:18:44 <jwb> they need to either be removed or moved into separate SRPMs
15:19:09 <haraldh> jwb, only if we think of one sourcetarball <-> one src.rpm
15:19:11 <haraldh> yes
15:19:40 <jwb> haraldh, hrm?
15:19:48 <Viking-Ice> I guess that would mean moved into separate SRPMs then
15:19:53 <haraldh> separate  srpms
15:19:54 <haraldh> yes
15:20:00 <jwb> haraldh, ah, ok.
15:20:01 <sghosh> haraldh: how would you differnetiate the src.rpm?
15:20:19 <haraldh> sghosh, ?
15:20:31 <sghosh> naming the src.rpm
15:20:39 <jwb> separate SRPMs does help, but at the cost of double maintenance unless we figure out something clever
15:20:46 <pknirsch> <component>.src.rpm and <component>-doc.src.rpm?
15:20:52 <Viking-Ice> right
15:20:58 <jwb> i'd advocate for prebuilt docs, or pointing online where feasible
15:21:17 <jwb> and then using the above SRPM thing as a fallback
15:21:28 <haraldh> with rpm macros we could also do different builds with one src.rpm
15:22:18 <haraldh> but they would have to be predefined and used globally, and carefully chosen
15:22:57 <pknirsch> that would mean modifying how packages are generally built though, haraldh
15:23:03 <haraldh> yes
15:23:04 <jwb> if they result in docs always being built when the main package is built, it doesn't help anyway
15:23:15 <pknirsch> which is quite a bit trickier than just doing 2 srpms
15:23:23 <haraldh> true
15:24:08 <haraldh> but in the looooong run, one might want to question our current src.rpm strategy anyway ... or the rpm src.rpm syntax
15:24:30 <pknirsch> but yea, the first few BR chains i saw seemed to indicate that certain doc specific package get pulled in all the time which then end up needing a whole stack of packages around, well everything :)
15:24:58 <jwb> fwiw, i'm going to discuss outright removal of kernel-docs today
15:25:02 <jwb> in teh kernel meeting
15:26:08 <haraldh> regarding "pre-built" docs. I think most of the "rebuilding" is the consequence of applying a patch, which changes documentation.
15:26:54 <pknirsch> hm
15:26:58 <jwb> i wonder how often that happens
15:27:37 <pknirsch> i would hope (which dies last) that even doc changes would go upstream as well
15:27:41 <haraldh> well, at least gtk-doc triggers on source code changes
15:28:09 <jwb> haraldh, oh, you mean when docs are generated from code comments?  e.g. javadoc, etc
15:28:23 * pknirsch has seen lots of doxygen use
15:28:27 <jwb> yeah
15:28:28 <haraldh> pknirsch, that would mean, we don't apply any patches in src.rpms :)
15:28:33 <pknirsch> which has a rats ass of deps :)
15:28:48 <jwb> haraldh, or just don't call 'make docs'
15:28:53 <pknirsch> haraldh: heh, ye, i can dream, right? ;P
15:29:06 <haraldh> seems like we all want arch linux :)
15:29:18 <haraldh> build from upstream with no patches :)
15:29:21 <jwb> most of those cases seem to have a separate make target for the docs part.  if they don't, patching out the docs build from the makefiles (or whatever) is doable....
15:29:34 * pknirsch nods
15:30:39 <haraldh> or do the hammer method with : find docs -type f -exec touch '{}' \;
15:31:22 <pknirsch> it's something i can try to check as well with some scripts and bash magic in the coming weeks
15:31:29 <pknirsch> see how many packages actually have a make doc
15:31:36 <pknirsch> install them and use them
15:31:39 <pknirsch> mark them as %doc
15:31:40 <pknirsch> etc
15:33:43 <pknirsch> just to give us a good indicator of really how much docs we have and how they are built and packaged
15:34:06 <pknirsch> and how much of this bloody BR mess we could tackle with that alreay
15:34:08 <pknirsch> already
15:34:33 <haraldh> is gcj still built?
15:34:42 <haraldh> I read, that it's not part of RHEL-7
15:35:11 <pknirsch> for RHEL-7 it's out, and iirc the tools team either has or wants to get rid of it in Fedora as well
15:35:12 <pknirsch> lemme check
15:35:45 <jwb> i thought it was mostly used on ppc
15:35:46 <sghosh> does gcj even qualify for the base?
15:36:49 <pknirsch> it's part of the gcc build, which is part in turn of the self hosting requirement of base
15:36:58 <pknirsch> (which we agreed upon iirc)
15:37:39 <sghosh> ah - ok
15:38:35 <pknirsch> sec
15:38:37 <haraldh> gcc-java
15:39:08 <pknirsch> hrmpf
15:39:09 <pknirsch> so ye
15:39:14 <jreznik2> but we can get rid of it
15:39:15 <pknirsch> f20 still contains libgcj & freinds
15:41:51 <haraldh> so, what is the doc solution? try to not rebuild the doc, if not possible, factor out in a separate src.rpm?
15:42:11 <haraldh> or reuse the same spec file and to macro magic?
15:42:16 <haraldh> or reuse the same spec file and use macro magic?
15:43:14 <pknirsch> the only problem with a 2nd doc src.rpm i see is that the maintainer would have to maintain 2 instead of 1 packages
15:43:23 <notting> simplest is to package the docs prebuilt
15:43:31 <pknirsch> right
15:43:42 <haraldh> add a docs tarball if necessary?
15:44:39 <pknirsch> and add that as a SourceX: foo-docs.tar
15:44:39 <haraldh> can yum/dnf do installs with "--excludedocs" ?
15:44:55 <jwb> haraldh, where the tarball is pre-built docs?
15:45:03 <haraldh> jwb, yep
15:45:10 <jwb> yeah, that's not bad
15:45:30 <pknirsch> mhm
15:45:39 <haraldh> would also solve many problems we had on multiarch
15:45:48 <sghosh> what if the build systems automated the docs spec file if tagged to do it? (for the second src.rpm case)
15:45:51 <haraldh> where docs differed
15:45:52 <pknirsch> hm, don't think yum can do --excludedocs actually, which it should be able to
15:45:59 <haraldh> so lib.i686 could not be installed with lib.x86_64
15:46:45 <jwb> pknirsch, i think you have to specify tsflags or something in yum.conf
15:46:47 <pknirsch> sghosh: ye, thats what i've been pondering about, too. having maintainers take care of 2 packages instead of one only for the separation of docs sounds a bit extreme
15:46:56 <pknirsch> jwb: ah right
15:47:09 * pknirsch hasn't seen anything about it in the yum manpage at least
15:47:56 <pknirsch> sghosh: so if we could somehow script that to make it so that the maintainer would only have to work with 1 specfile but could kick off either a doc or non-doc build that would be good, too imho
15:48:03 * haraldh wonders, if a prebuild docs isn't the same as a prebuild binary package.
15:48:12 <pknirsch> hm
15:48:14 <jwb> haraldh, in terms of the FPC?  possibly
15:48:15 <sghosh> pknirsch: I have other use cases for automated spec file munging as well
15:48:34 <pknirsch> haraldh: hm, ue
15:48:56 <pknirsch> sghosh: yea. stacks/envs come to my mind at least
15:49:48 <sghosh> :)
15:50:30 <haraldh> so we need a meta-src.rpm, which produces several src.rpms :)
15:50:47 <haraldh> so the maintainer only has to care about the meta-src.rpm
15:51:10 <jreznik2> and metacomplexity
15:51:22 <haraldh> or the resulting rpm carries the "rpm defines" which were used for the src.rpm
15:51:30 <haraldh> to build the rpm
15:52:12 <pknirsch> hehhe
15:52:26 <jwb> brb
15:52:47 <pknirsch> i'm not sure adding complexity to how we build and maintain packages is going to be attractive to developers :P
15:53:04 <pknirsch> (just as a sidenote)
15:53:43 <sghosh> it should be transparent to developers
15:53:55 <notting> this seems an awfully complicated paradigm shift just for "reduce buildreqs¨
15:54:07 * pknirsch nods to notting
15:54:11 <haraldh> right
15:54:19 <pknirsch> i think we should separate the two things
15:54:24 <sghosh> true - if that's the only thing to solve. sorry if I took you off track
15:54:57 <pknirsch> and it's certainly worthwhile to look at the doc problem as well in detail
15:55:11 <pknirsch> someone willing to kick off a discussion in Fedora about that and drive it?
15:55:12 <haraldh> but I can see the benefit for stacks
15:55:21 <haraldh> and only maintaining _one_ spec file
15:55:25 <pknirsch> yep
15:55:41 <pknirsch> anything else is maintenance madeness
15:56:00 <haraldh> on the other hand a spec file with a lot of %if is horrible also
15:56:25 <Viking-Ice> yeah no %if please ;)
15:56:27 <haraldh> of course nothing beats the kernel.spec :)
15:56:31 <pknirsch> well, there are lots of ponys in the world. can't have all of them :P
15:56:42 <jwb> haraldh, glibc/gcc is a rival of kernel.spec
15:56:58 <pknirsch> just wanted to say, glibc is "pretty" as well :)
15:57:02 <sghosh> 3 horse race - who needs ponys
15:57:03 <Viking-Ice> I was planning on cleaning up the specs and bring them 21 century for base ;)
15:57:13 <pknirsch> Viking-Ice++!
15:57:18 <Viking-Ice> <slurp> horses ;)
15:57:25 <pknirsch> big ponies!
15:58:58 <jwb> i need to head out now unfortunately.  i'll review minutes later this afternoon
15:59:03 <pknirsch> no
15:59:05 <pknirsch> np
15:59:08 <pknirsch> sorry!
15:59:17 * notting has an 11am as well
15:59:24 * pknirsch mumbles o is too close to p
15:59:28 <pknirsch> alright
16:00:16 <pknirsch> the lets call it for today, we got enough things we can already look at. and holidays are close as well. For anyone already on PTO or on PTO next Friday i wish you Happy Holidays!
16:00:37 <haraldh> Still, I like the idea of foo-variant-a.spec: %include foo.spec; %define variant-a 1
16:00:46 <pknirsch> I'll still be here next Friday and send out a brief agenda with Gluehwein on it :)
16:01:09 <haraldh> :)
16:02:04 <pknirsch> mhm haraldh, i think there are many ways on how we can experiment with how especially the doc stuff (or any other munged specfile build) can be achieved without putting more burden on developers/maintainers
16:02:09 <sghosh> haraldh: also thing about when to apply the spec files - build stage, packaging stage - economies of scale can be achieved there
16:03:13 <sghosh> s/thing/think
16:03:44 * pknirsch nods
16:03:49 <sghosh> looking forward to the virtual Gluehwein
16:03:53 <pknirsch> :)
16:04:11 <Viking-Ice> Gluehwein puff mead instead any day
16:04:29 <Viking-Ice> or Brennivín and shark
16:04:50 <pknirsch> hehe Viking-Ice, feel free to bring some virtual ones for next weeks meeting then!
16:05:11 <Viking-Ice> lol
16:05:24 <haraldh> mmm... shark.. lovely :)
16:05:46 <haraldh> *shudder*
16:05:46 <pknirsch> probably fermented! :/
16:05:56 * masta looks in
16:05:57 * pknirsch flees in horror
16:06:09 <masta> sry I'm late
16:06:13 <pknirsch> np masta :)
16:07:01 <pknirsch> alright, lets call the official part then for today. Thanks everyone for the great discussion today and have a great weekend!
16:07:12 <Viking-Ice> pknirsch, probably absolutely unless you want to kill yourself ( you cant eat fresh shark it will kill you )  haraldh yeah we just need to keep Václav and Lukas from it so there is something left for us ;)
16:07:23 <haraldh> :-)
16:07:27 <pknirsch> #endmeeting