17:00:54 <geppetto> #startmeeting fpc
17:00:54 <zodbot> Meeting started Thu Mar 12 17:00:54 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:56 <geppetto> #meetingname fpc
17:00:56 <zodbot> The meeting name has been set to 'fpc'
17:00:56 <geppetto> #topic Roll Call
17:01:02 <geppetto> Ok, let's try this again
17:01:10 <geppetto> tomspur: tibbs: mbooth you still here?
17:01:16 <tomspur> yes
17:01:21 <geppetto> #chair tomspur
17:01:21 <zodbot> Current chairs: geppetto tomspur
17:01:30 <mbooth> Hi
17:01:37 <geppetto> #chair mbooth
17:01:37 <zodbot> Current chairs: geppetto mbooth tomspur
17:02:02 <geppetto> hopefully at least one more person will turn up too, then we can have quorum
17:02:17 <geppetto> SmootherFrOgZ: ping?
17:02:49 * tomspur thought most people here are from US, so picking your time zone as a reference made sense the last time
17:02:59 * SmootherFrOgZ here
17:03:03 <geppetto> #chair SmootherFrOgZ
17:03:03 <zodbot> Current chairs: SmootherFrOgZ geppetto mbooth tomspur
17:03:28 <geppetto> tomspur: Yeh, we had been doing it anyway for the 2 or 3 DST changes before you made the change.
17:03:39 <geppetto> tibbs: ping
17:04:32 <mbooth> Maybe tibbs|w
17:04:42 <tibbs|w> Yeah, sorry.
17:04:53 <tibbs|w> Shopping for UPS units....
17:04:59 <geppetto> #chair tibbs
17:04:59 <zodbot> Current chairs: SmootherFrOgZ geppetto mbooth tibbs tomspur
17:05:19 <geppetto> Ok, 5 it is
17:05:30 <geppetto> #topic Schedule
17:05:32 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-March/010497.html
17:05:47 <geppetto> #topic #503 	Changes/LegacyJDKsInFedora
17:05:47 <geppetto> .fpc 503
17:05:47 <geppetto> https://fedorahosted.org/fpc/ticket/503
17:06:45 <geppetto> I thought this was just about naming, when I moved it to the meeting
17:06:54 <geppetto> but as tibbs says, we don't have a proposal
17:07:23 <geppetto> Do we want to discuss it … or just throw it back with a "please come up with a draft policy, for naming" ?
17:07:23 <tibbs|w> I should have set it to needinfo, I think.
17:07:29 <geppetto> maybe
17:07:41 <tibbs|w> I don't want to risk doing something they don't want us to do.
17:07:55 <tibbs|w> And I certainly don't understand what's going on enough to propose anything.
17:07:58 <SmootherFrOgZ> yup, a draft would be great
17:08:19 <mbooth> Yeah, there doesn;t seem much here "for us"
17:08:39 <tibbs|w> The jvm package naming is kind of nuts already.
17:08:48 <geppetto> #action Someone needs to make a draft of what you'd like us to vote on, like recommended package naming.
17:08:57 <geppetto> #topic #508 	New GID for openstack-neutron
17:09:02 <geppetto> https://fedorahosted.org/fpc/ticket/508
17:10:16 <geppetto> This argument would apply to anything, right?
17:10:31 <tibbs|w> Did we give them the existing GIDs?
17:10:39 <tibbs|w> I don't recall that at all.
17:10:44 <geppetto> Please give ma a static UID/GID because then someone only needs to set it up in LDAP once?
17:11:29 <geppetto> I'm not shocked if openstack has a bunch of static UID/GIDs … but I'd guess that at least some of them really are required due to shared storage
17:11:57 <tibbs|w> I'm afraid I don't understand the argument.
17:12:07 <tibbs|w> How does having a static GID help at all with LDAP?
17:12:25 <tibbs|w> You put the GID in LDAP, then you install packages and they use the GID you put in LDAP.
17:12:34 <tibbs|w> That doesn't require a static GID at all.
17:12:51 <geppetto> it does if the install happens when you aren't connected to LDAP
17:13:32 <geppetto> (not arguing this is a good reason)
17:15:01 <tibbs|w> Do we really still not have a mechanism for fixing GIDs at system install time?
17:15:08 <tibbs|w> (UIDs too).
17:15:16 <tibbs|w> I thought systemd was supposed to have something relating to that.
17:15:42 <tibbs|w> Ah, yeah, there was a ticket that stayed in needinfo forever and I finally closed it.
17:16:14 <tibbs|w> Anyway, I think if someone could come up with that, this whole "I need static for reasons" would probably go away.
17:16:35 <geppetto> maybe
17:17:28 <geppetto> I'm happy to just -1 tickets like this though, as they come up
17:17:52 <geppetto> Or tell them to speak to systemd guys, and/or anaconda or something … if they want a better fix.
17:19:54 <geppetto> Anyone else want to comment, or vote or whatever?
17:20:02 <tomspur> I'd expect a better argument than "help users to setup" -> asking for more info why they really need one?
17:20:15 <tibbs|w> Generally -1 to this, especially with no real reason.
17:20:48 <racor> I am at -1, as well. They need to come up with some better reasoning.
17:21:45 <mbooth> Hmm
17:21:57 <geppetto> #action If you setup LDAP before package install then it'll just work with "dynamic" GIDs.
17:22:12 <mbooth> Other openstack packages also do not specify group
17:22:12 <mbooth> http://pkgs.fedoraproject.org/cgit/openstack-trove.git/tree/openstack-trove.spec#n276
17:22:28 <mbooth> I agree there needs to be better reasoning
17:23:09 <geppetto> #action If you still think you need a static GID, you need to give a better reason than just "it might be easier". Eg. shared storage.
17:23:18 <geppetto> #topic #509 	Further bootstrapping guideline changes
17:23:22 <geppetto> https://fedorahosted.org/fpc/ticket/509
17:23:45 <tibbs|w> I don't really get what the problem is here.
17:23:49 <geppetto> So … what did we miss last time tibbs? And what do you want us to do or vote on?
17:24:15 <tibbs|w> I was just trying to make sure that whatever vondruch was still concerned about didn't get lost.
17:24:19 <tomspur> Don't you need both lines, when really bootstrapping?
17:24:21 <tibbs|w> Personally I'm OK with the way it is now.
17:24:36 <tibbs|w> But I'm OK with the "proposal" I put there as well.
17:24:50 <tomspur> If one uses bootstrapping, but cannot pass --with-bootstrap, one must put the second line also to the spec file
17:25:03 <tomspur> And then remove it again, once built
17:25:06 <geppetto> The proposal confuses me … doesn't that mean you have to alter the specfile to boot without bootstrap?
17:25:19 <tibbs|w> You always have to alter the spec file.
17:25:21 <geppetto> What tomspur said
17:25:36 <tibbs|w> The --with thing is nice but... not really useful.
17:25:50 <tibbs|w> In the context of something that goes through koji, at least.
17:26:57 <tomspur> I think the line "Set this to 0 after we've bootstrapped." is confusing
17:27:31 <tomspur> When you set it to 0 and use --with-bootstrap, it will not bootstrap...
17:27:46 <tomspur> Or am I wrong?
17:28:02 <mbooth> tomspur: I guess that's the point of the proposal, to fix that
17:28:11 <geppetto> Yeh, maybe that's the bug
17:28:43 <geppetto> What we want is _with_bootstrap to affect bootstrap … and if it's not set then bootstrap to have  default
17:28:57 <geppetto> That default being 1 when the package is first built, and 0 afterwards
17:30:27 <geppetto> I would rather keep the --with/--without functionality … but just givening up (tibbs proposal) isn't the end of the world.
17:31:10 <tibbs|w> What's the best way to make this make sense and keep the --with stuff?
17:31:14 <mizdebsk> fwiw, --with bootstrap is useful in some cases, for example when user wants to bootstrap official fedora srpm, which is built without bootstrapping
17:31:30 <mizdebsk> i use this regularly
17:31:49 <tibbs|w> But you still have to edit something at some point.
17:32:07 <tibbs|w> Because koji and --with are incompatible.
17:32:10 <tomspur> %{?_with_bootstrap: %global bootstrap 1}%{!?_with_bootstrap:  %global bootstrap $manually_changed_bootstrap_default}
17:32:20 <mizdebsk> user can just do: mock --with bootstrap <srpm>
17:32:23 <tomspur> Doesn't look to nice...
17:32:24 <geppetto> From what I can see the recommended way is to use %bcond_with bootstrap … and %if %{with bootstrap}
17:32:48 <tibbs|w> I never properly understood  %bcond_*.
17:33:05 <racor> geppetto: +1
17:33:14 <mizdebsk> geppetto: +1 that's what i use, bcond
17:33:50 <geppetto> tibbs: I think that's one of the problems … few people do :(
17:34:32 <tibbs|w> I'm open to anything that works.  I only put something in the ticket so that there would be something to discuss.
17:34:38 <geppetto> racor: You want to propose a policy change for next week to use bcond?
17:37:20 <geppetto> #action Seems that people do use --with/--without for bootstrapping … so we can't just get rid of it. A new policy to vote on that has a changable default and reacts to --with--without would be nice. Maybe bcond?
17:37:20 <racor> geppetto: I can try, but I am not sure I'll be able to find a free time slot.
17:37:26 * geppetto nods
17:37:31 <geppetto> I've left it open to anyone
17:37:40 <geppetto> Hopefully someone will come up with something :)
17:38:15 <geppetto> Ok, moving on to older tickets/packages.
17:38:16 <geppetto> #topic #126     bundling exception for scintilla
17:38:23 <geppetto> https://fedorahosted.org/fpc/ticket/126
17:38:47 <tibbs|w> I tried to do the necessary research.
17:38:52 * geppetto nods
17:38:56 <tibbs|w> But all that did was show how much of a mess this is.
17:39:34 <geppetto> yeh
17:40:04 <tibbs|w> I didn't try to track down what's modified and what isn't.  That would be something for the particular maintainers, I think.
17:40:05 <geppetto> so … scintilla is the most up to date bundle, right?
17:40:27 <tibbs|w> Well, we don't actually have a standalone scintilla package.
17:40:31 <tibbs|w> For extra fun, of course.
17:40:59 * geppetto nods
17:41:14 <tibbs|w> But monkeystudio bundling qscintilla bundling scintilla....
17:42:17 <tibbs|w> Anyway, I don't know what to do besides contact package maintainers.
17:42:20 <geppetto> I'm not even sure what are options are here
17:42:23 <tibbs|w> Or file bugzilla tickets.
17:42:43 <tibbs|w> I don't see, really, much chance of anything unbundling anything except maybe monkeystudio.
17:42:46 <geppetto> I guess we tell everyone to join the ticket, and they can help unbundle this mess?
17:43:00 <geppetto> cool
17:43:19 <mbooth> So what is the way ahead? Someone packages the "real" scintilla first?
17:43:33 <mbooth> Only then can unbundling begin in earnest
17:44:16 <geppetto> Well, maybe the very first step is that geany/etc. need to add "bundling(scintilla) = whatever"
17:44:33 <geppetto> Then we can see what, if anything, actually needs to bundle
17:45:41 <geppetto> Any other ideas?
17:45:50 <tibbs|w> I'm out.
17:45:59 * SmootherFrOgZ has none
17:47:49 <geppetto> #action Given the scope of the bundling here, we need input from the other package maintainers. At the very least they should have bundled() provides, better would be to help unbundle this giant mess.
17:48:09 <geppetto> #topic #248     python-feedgenerator - a standalone version of a bundled library
17:48:14 <geppetto> https://fedorahosted.org/fpc/ticket/248
17:48:47 <geppetto> tibbs: what's the interesting thing?
17:49:49 <tibbs|w> Just the fact that it's the bundling thing in reverse.
17:50:12 <tibbs|w> Someone wants to extract a piece of one package and package it separately so that they can make use of it.
17:50:26 <tibbs|w> But then, after two years I doubt anyone cares.
17:50:40 <tibbs|w> It was just an old still-open ticket.
17:50:51 <SmootherFrOgZ> really interesting however, as said in the ticket, I'm not sure upstream would follow that
17:50:58 <mbooth> I see no satisfactory answer to spot's question "I guess what isn't clear to me is why the django package can't generate a python-feedgenerator subpackage that the rest of django can pull in as a dependency, but is independently installable."
17:51:01 <geppetto> I'm like 99% sure we've had the same problem with some random Java thing too
17:51:21 <tibbs|w> Ye, spot's thing seemed to make the most sense.
17:51:33 <geppetto> Yeh
17:51:57 <tibbs|w> Even if upstream doesn't commit to any kind of API, it's still sort of packager courtesy.
17:52:07 <geppetto> It's basically the same old "upstream doesn't want to do software engineering, so would prefer we allow bundling/static-libs/copy-libs/whatever"
17:52:14 <tibbs|w> "Hey, could you spit this file out into a subpackage so I can use it?"  "Sure, here you go."
17:52:26 * geppetto nods
17:53:08 * tomspur has the impression, that the python-feedgenerator fork is more or less dead
17:53:22 <geppetto> bonus
17:53:23 <tibbs|w> Honestly I'd just close it with "what spot said in #8 makes sense to us; if you still want this and that doesn't work, reopen."
17:53:40 <geppetto> I'm happy to do that
17:53:51 <mbooth> I'd vote for that
17:54:07 <SmootherFrOgZ> +1
17:54:20 <tomspur> This is the diff: http://paste.fedoraproject.org/197240/61821551/
17:54:21 <geppetto> #action what spot said in comment #8 makes sense to us; if you still want this and that doesn't work, reopen.
17:54:59 <tomspur> Yet maybe at last a little django dependency on django-utils works
17:55:16 <geppetto> #topic #303     Consider reverting decision to ban %{?_isa} in BuildRequires
17:55:17 <geppetto> https://fedorahosted.org/fpc/ticket/303
17:57:15 <tibbs|w> Another ancient one.
17:57:34 <tibbs|w> But there's good stuff from Panu in there.
17:58:49 <mizdebsk> i would like to state that koschei (continuous integration system for fedora) relies on lack of isa in BR
17:59:00 <mizdebsk> this is basic design assumption and reverting this would rend koschei unusable
17:59:12 <tibbs|w> But if it's wrong, it's wrong.
17:59:19 <tibbs|w> Not that I know one way or the other.
18:00:25 <geppetto> Technically it's wrong, but Panu exagerates the problem
18:00:44 <geppetto> If you don't use _isa … then very few packages have problems
18:01:13 <geppetto> However the ones that do tend to complain a lot, because nothing just works for them and they are often the most complex (Eg. kernel)
18:01:35 <geppetto> And people are trained that yum-builddep foo … does just work.
18:02:21 <racor> geppetto: Most important: People are treating *.src.rpms as arch independent. Having _isa in BR:'s would void this.
18:03:18 <geppetto> racor: Right, but as Panu says technically they just aren't arch independent … but it's often hard to tell for most packages if they don't use _isa
18:04:05 <geppetto> I _think_ the latest python rpm now provides the APIs that yum-builddep needs so that #2 can be fixed
18:04:24 <geppetto> In that yum-builddep can extract the .spec out of an .src.rpm (but I'm not 100% sure of that).
18:04:53 <geppetto> However fixing #1 is much more of a pain, IIRC … and yum-utils will be dead-ish for F22
18:05:04 <racor> geppetto: Yes, I know. ATM srpms carry an arch in some rpm internals, but besides this, they actually are arch-independent
18:05:43 <geppetto> One option is to leave this until F22 and dnf is king … and see how much that cares.
18:06:16 <mbooth> geppetto: Does the dnf equivilent of these tools do "the right thing"?
18:06:19 <geppetto> But then I think a bunch of people will be unhappy if koschei stopped working, as mizdebsk says
18:06:39 <geppetto> mbooth: IIRC yum-builddep equivalent doesn't exist yet
18:07:20 <mizdebsk> there is dnf builddep
18:07:43 <mizdebsk> mock and koji can use it
18:07:48 <geppetto> mizdebsk: Ahh … do you know if it cares?
18:08:38 <mizdebsk> i think it has the same limitations as yum-builddep, so it won't work with arched srpms
18:10:46 <geppetto> yeh, just had a look at the source … and it uses .src.rpm headers
18:11:26 <geppetto> so … there's that
18:12:06 <mbooth> So ... this is a bug in "builddep" command then, right? It should do, as pmatilai says "a bit more work behind the scenes"
18:12:22 <geppetto> I'll add an action item that whoever cares about this needs to speak to the tool people that currently rely on arch independent src headers and help them fix the problem
18:12:40 <geppetto> After we have no more tool problems, then no problem changing the policy
18:13:10 <geppetto> mbooth: Kind of … but for a _long_ time there wasn't a reasonable way that the tools could work better
18:13:14 <mizdebsk> mbooth: in some cases builddep must run from yum metadata, so it doesn't have srpm content to extract and parse the spec from
18:13:16 <geppetto> And I'm not 100% sure there is now
18:13:31 <mizdebsk> the same for koschei - it has only yum metadata
18:13:39 * geppetto nods
18:14:10 <mbooth> I see
18:15:00 <geppetto> #action We have no problem changing this _if the tools work_. yum-builddep doesn't, the dnf builddep rewrite also doesn't work. koschei which is a new Fedora tool also relies on not having to download/extract .src.rpm files.
18:15:59 <geppetto> #action So if you want to change policy here someone will have to speak to and work with all the tool authors to make sure the tools still work, if they do then changing policy should be trivial.
18:16:18 <geppetto> #topic #497     Clean up BuildRequires section; don't try to define the minimal build en
18:16:23 <geppetto> https://fedorahosted.org/fpc/ticket/497
18:17:07 <tibbs|w> Oh, crap.  I pretty much forgot about this.
18:17:09 <geppetto> tibbs: Did the tweaked version go out?
18:17:13 * geppetto nods … no problem
18:17:16 <tibbs|w> Still on me, and no, I didn't touch it.
18:17:19 <tibbs|w> Next week....
18:17:27 <geppetto> Yeh
18:17:27 <tibbs|w> Still super low priority anyway.
18:17:37 * geppetto nods
18:17:38 <geppetto> #topic Open Floor
18:17:45 <tibbs|w> Is that.... everything?
18:17:48 <geppetto> Yeh
18:17:54 <geppetto> 506 was defered to next week
18:18:01 <geppetto> so that's all the tickets :)
18:18:04 <mbooth> #510 was opened today if you want to take a look
18:18:06 <tibbs|w> We have only 21 open tickets.
18:18:28 <tibbs|w> And I think I'll get rid of a couple more old needinfo ones.
18:18:50 <geppetto> mbooth: You want to ?
18:18:59 <mbooth> Sure
18:19:12 <geppetto> #topic #510 	Bundling exception for takari-archiver
18:19:28 <geppetto> https://fedorahosted.org/fpc/ticket/510
18:19:57 <mbooth> I already added my thoughts -- I figured it would be easy to close it quickly
18:21:07 <geppetto> 300 line file … and mostly isSet() calls?
18:21:11 <geppetto> blah … I guess I'm +1
18:21:24 <racor> mbooth: my java-foo is ~0. But does the modified version rpm-wise conflict with the original version?
18:21:38 <geppetto> racor: they changed formatting, it says
18:22:05 <tibbs|w> I don't particularly have an issue with this.
18:22:08 <geppetto> But they probably don't ship the file anyway … just bundle the bytecodes in whatever
18:22:20 <racor> geppetto: My concern is on rpm-provides/requires.
18:22:22 <geppetto> fyi, here is the file: https://github.com/takari/takari-archiver/blob/master/src/main/java/io/tesla/proviso/archive/FileMode.java
18:22:30 <mizdebsk> there will be no rpm conflict
18:22:31 <mbooth> racor: There are no conflicts, no
18:22:38 <tibbs|w> +1; this is... barely even code, really.
18:22:57 <SmootherFrOgZ> +1 from me
18:23:00 <geppetto> +1
18:23:08 <tomspur> +1 for to small to care
18:23:10 <racor> +1. They could have renamed the file and nobody would have noticed ;)
18:23:14 <tibbs|w> I mean, it doesn't actually do any computing, really.
18:23:19 <geppetto> yeh
18:23:26 <mbooth> +1 from me obviously
18:23:58 <geppetto> #action Bundling exception for FileMode in takari-archiver (+1:5, 0:0, -1:0)
18:24:03 <geppetto> #topic Open Floor
18:24:13 <geppetto> Ok, anything else?
18:24:21 <tibbs|w> We're very nearly there, folks.
18:24:26 <geppetto> :)
18:24:29 <mbooth> No more from me :-)
18:24:59 <tibbs|w> And by "there", I mean actually done with all of the old stuff.
18:25:29 <mbooth> tibbs|w: You've really done a lot bring that backlog down :-)
18:25:29 <geppetto> Ok … do we want to stay on UTC 17 for next week, or move to UTC 16 (following US DST)?
18:26:31 <geppetto> Anyone? :-o
18:26:34 <mbooth> geppetto: Feel free to stay on US DST for me
18:26:52 <tibbs|w> I have no preference.
18:26:56 <mbooth> My calendar reminds me at the correct time
18:27:05 <geppetto> SmootherFrOgZ: You have any problem with it?
18:27:08 * tomspur would follow one random time zone
18:27:09 <SmootherFrOgZ> nope
18:27:13 <tomspur> I don't care which one :)
18:27:28 <tibbs|w> I don't eat lunch anyway, so it makes no difference to me.
18:27:28 <geppetto> Ok, I'll see you at 16 UTC next week then :)
18:27:29 <SmootherFrOgZ> fine by me
18:28:29 <geppetto> Ok, cool thanks for coming everyone. See you next week when we might have less than 10 tickets total on our Schedule :)
18:28:30 <racor> geppetto: 16 UTC is fine, I just missed the US already has switch to DST, today ;)
18:29:12 <geppetto> racor: You couldn't tell by how much grumpier everyone over here was this week ;)
18:29:48 <racor> geppetto: EU is following in couple of weeks ;)
18:29:57 <dgilmore> geppetto: a sugestion
18:30:32 <dgilmore> geppetto: saw the earlier %{?_isa} bit
18:31:14 <dgilmore> I think a viable option is to have to use isa if you have architecture specifc BuildRequires
18:31:24 <dgilmore> i.e. %ifarch foo
18:31:30 <dgilmore> BuildRequire bar
18:32:04 <dgilmore> then people would get a visable clue they should rebuild the srpm
18:32:41 <racor> dgilmore: This basically is the same problem - We banned %ifarch BR ... for similar reasons.
18:32:54 <dgilmore> racor: you can not ban ifarch BR
18:32:54 <geppetto> racor: yeh, but people still use it
18:33:05 <dgilmore> racor: it is needed
18:33:17 <tibbs|w> So does that similarly break the same tools?
18:33:19 <dgilmore> libseccomp for instance does not build or support all arches
18:33:27 <tibbs|w> Because then those tools are... already broken.
18:33:48 <geppetto> tibbs: yeh
18:34:15 <geppetto> tibbs: This is mostly what Panu meant when he said .src.rpm headers aren't arch. independent.
18:34:27 <mizdebsk> dgilmore: if BR is wrapped in ifnarch <some-secondary-arch> then all BR for primary arch would have isa and it would break builddep for developers working on primary
18:34:49 <dgilmore> mizdebsk: no it doesnt
18:35:14 <dgilmore> mizdebsk: how do you figure?
18:35:17 <geppetto> dgilmore: He means with your proposal that using ifarch means you should add _ias to BR
18:35:26 <geppetto> _isa, even
18:35:37 <mizdebsk> yes, builddep working from metadata would stop working in this case
18:35:42 <dgilmore> geppetto: he is saying it breaks builddep
18:35:45 <dgilmore> it doesnt
18:35:46 <tibbs|w> Can someone articulate well the criteria for deciding whether this kind of thing is really needed?
18:35:53 <dgilmore> it means you know you need to rebuild the srpm
18:36:23 <geppetto> dgilmore: it makes the repometadata useless
18:36:42 <racor> Another problem has not been discussed today: arch-dependent BRs will break, when the packages they BR change arch.
18:36:44 <dgilmore> tibbs|w: it all comes down that you really shoudl always rebuild a srpm on the target arch to ensure your BuildRequires are correct
18:36:55 <dgilmore> tibbs|w: koji does this as part of its build process
18:37:19 <mizdebsk> assume srpm was built on arm koji builder, on x86_64 builddep would report that dependency with arm isa is not available and fail
18:37:32 <dgilmore> it comes down to if you have no ifarch BuildRequires the Requires of the srpm will be the same on all arches
18:37:55 <mizdebsk> not with current state where isa in BR is not allowed
18:38:09 <dgilmore> if you have a ifarch in your BuildRequires the Requires a srpm has will vary depending on the arch it is built on
18:38:16 <geppetto> dgilmore: the problem is a lot of people want to do things like "install an environment where I can build FOO" without having FOO.src.rpm at all
18:38:33 <racor> dgilmore: Will you provide everybody an arm7vl, a sparc, ppc and want Fedora to ship SRPMS repositories for each of them?
18:38:44 <dgilmore> geppetto: technically thats not possible
18:39:06 <dgilmore> racor: you are being silly.
18:39:20 <geppetto> dgilmore: that doesn't stop people wanting it  … and apparently koschei desires it
18:39:25 <dgilmore> srpms are binary rpms specific to the arch the srpm was built on
18:39:31 <racor> dgilmore: No, this is a direct consequence of your reasoning.
18:40:01 <tibbs|w> So where do the source packages we ship as part of each release come from?
18:40:11 <racor> Packagers will not be able to arch-independent srpms and Fedora will have to ship arched' srpms
18:40:15 <mizdebsk> except you can install srpm on any arch
18:40:30 <dgilmore> geppetto: if we require people add the isa when and only when the package has architecture specific BuildRequires  that is a big flag this needs special handling
18:40:45 <dgilmore> but allows the rest to do carry on
18:41:08 <dgilmore> tibbs|w: the srpm is froma  random arch of koji's chosing
18:41:22 <tibbs|w> Does that strike anyone as kind of problematic?
18:41:36 <dgilmore> tibbs|w: its not
18:41:52 <geppetto> dgilmore: right, but as mizdebsk says … there will be cases there that giant flag breaks things that will work otherwise.
18:41:58 <tibbs|w> I guess they all have the source; it's just the dependencies that differ.
18:42:01 <dgilmore> but you really do need to rebuild the srpm on the target arch to ensure BuildRequires are right
18:42:39 <geppetto> dgilmore: How feasible would it be to have Arch'd repodata?
18:42:41 <dgilmore> geppetto: what is worse, get a big fat warning flag upfront? or get a build that blows up for something missing?
18:43:05 <mizdebsk> dgilmore: strictly speaking you are correct, but in common case deps from different arch will be good enough for most cases
18:43:08 <tibbs|w> Or worse, I guess, a build that silently succeeds but without some functionality.
18:43:13 <dgilmore> geppetto: they may or may not work otherwise
18:43:40 <dgilmore> mizdebsk: and in most cases there is no need for the isa as tehre is no arch specifc BuildRequires
18:44:00 <tibbs|w> Basically, I don't have a problem allowing this as long as it's strictly limited to the cases where it's necessary, and those cases are articulated clearly.
18:44:23 <dgilmore> mizdebsk: my proposal is torequire the use of isa only when there is a BuildRequires wrapped in a %ifarch, and forbid it otherwise
18:44:42 <mizdebsk> dgilmore: what about %ifnarch?
18:44:51 <dgilmore> mizdebsk: same thing
18:45:15 <mizdebsk> i can agree about ifarch, but isa in ifnarch would break stuff
18:45:18 <dgilmore> by saying %ifarch I mean architecture specific build Requires
18:45:28 <dgilmore> mizdebsk: how?
18:45:38 <tibbs|w> I can see how ifnarch is a different animal.
18:46:02 <tibbs|w> But then ifarch with multiple arches has the same issues, so not really.
18:46:09 <mizdebsk> you could wrap all BR in %ifnarch <some-arch-nonexistent-in-fedora>
18:46:13 <dgilmore> %ifnarch i386 armv7hl ppc s390
18:46:17 <mizdebsk> and make all BR arch-dependant this way
18:46:32 <dgilmore> BuildRequire: 64bit-super-foo
18:46:59 <dgilmore> mizdebsk: that would be silly
18:47:32 <dgilmore> mizdebsk: but the guidelines could say only if the architecture is a fedora primary or secondary arch
18:47:52 <geppetto> dgilmore: Yeh, but I think the worry that ifnarch has a lot more false positives than ifarch might be valid.
18:48:20 <mizdebsk> from what i know, in practice ifnarch/ifnarch are most useful for secondary arches
18:48:21 <geppetto> But without real numbers I'd be inclined to just hope it isn't too many in either case.
18:48:48 <dgilmore> geppetto: most ifnarch i know of are s390 or s390x
18:48:50 <mizdebsk> adding them with isa would affect BRs for fedora primary, which don't have these arches
18:48:57 <tibbs|w> Would we want to see numbers?
18:49:11 <dgilmore> mizdebsk: there is some for primary also
18:49:31 <mizdebsk> sure, but that's very low number of cases
18:49:47 <tibbs|w> grub, the efi stuff, syslinux, things like that.
18:49:49 <geppetto> tibbs: I'd rather not … but if mizdebsk wants to convince us that triggering on inarch is bad, I'd want to see some concrete examples of why
18:50:23 <mizdebsk> i can give you an example
18:51:05 <mizdebsk> there's package that has missing test dependency on s390, hence BR on that test dep is wrapped in %ifnarch and %check skipped
18:51:05 <dgilmore> I think triggering on ifarch ifnarch in the BuildRequires is the right thing to do
18:51:21 <dgilmore> there is ifarch ifnarch in other places and they are uneffected
18:51:46 <mizdebsk> srpm in fedora primary is never built on s390, so srpm in primary will always have this dep
18:51:56 <geppetto> mizdebsk: yeh, you are missing the buildrequire part of dgilmore's proposal
18:52:06 <mizdebsk> but with dgilmore proposal it will be arched
18:52:24 <geppetto> mizdebsk: ifarch/ifnarch being in the specfile doesn't affect anything, _unless_ they affect what the BuildRequires are.
18:52:40 <geppetto> mizdebsk: So not running random test or something is fine
18:52:53 <mizdebsk> you are missing the point
18:53:14 <geppetto> Oh, test dep.
18:53:16 <geppetto> Meh.
18:53:24 <dgilmore> mizdebsk: so your prosal would be to only add isa if the BuildRequires ifarch ifnarch is a primary arch?
18:53:31 <mizdebsk> with dgilmore proposal, BR will become arch-specific (will have _isa) and will be unusable with builddep and koschei
18:53:55 <mizdebsk> dgilmore: yes, that would be ok
18:53:58 <dgilmore> mizdebsk: koschei is broken if it doesnt rebuild the srpms for every arch
18:54:26 <mizdebsk> it can't with current resources... 4G disk storage :(
18:55:07 * geppetto wonders if the change in dgilmore's and my pocket could solve mizdebsk's storage problem.
18:55:15 <dgilmore> mizdebsk: it should be able to detect the isa and rebuild in that case
18:55:16 * geppetto facepalms
18:55:40 <dgilmore> mizdebsk: there is not that many effected
18:55:50 <geppetto> dgilmore: From what I can gather they are only storing repodata, and not .src.rpm at all
18:56:05 <mizdebsk> problem of builddep stays (but i admit it's rare to use builddep with metadata, mock uses it on srpm)
18:56:13 <dgilmore> geppetto: the repodata would have the isa info in it
18:56:20 <geppetto> indeed
18:56:23 <dgilmore> the SRPM requires would have it
18:56:32 <dgilmore> fetch the srpm and do what needs done
18:56:56 <dgilmore> I do not know of any huge packages that have ifarch BR's
18:57:04 <geppetto> kernel
18:57:15 <mizdebsk> eclipse?
18:57:27 <dgilmore> I was also under the impression koschei had a big cheque book to get what hardware it needs
18:58:20 <mizdebsk> kind of, but i made it work fine with just metadata
18:58:32 <mizdebsk> if i have to download full srpm, so be it
18:58:47 <dgilmore> mizdebsk: only in the case that there is a isa
19:00:22 <tibbs|w> Maybe someone who really understands this could submit a draft.  Or perhaps we could get competing drafts.
19:00:46 <tibbs|w> I also wanted to point out that I slipped up and didn't bump https://fedorahosted.org/fpc/ticket/325
19:00:49 <tibbs|w> back to meeting status.
19:01:20 <geppetto> tibbs: yeh, I'll put dgilmore's plan with/without mizdebsk change into the ticket
19:01:32 <dgilmore> tibbs|w: I do not have a strong opinion. I see the value in adding it when there is architecure specific BuildRequires. its a up front indicator that somethng may need doing
19:01:34 <geppetto> tibbs: Bump it now and we'll get to it next week, it's fine :)
19:03:01 <dgilmore> there really is no point in having isa when the is no Architecure specific BuildRequires
19:03:19 <dgilmore> geppetto: if there is any questions I am happy to answer them
19:03:31 * geppetto nods … you are CC'd on the ticket?
19:04:04 <dgilmore> I do not think so
19:04:13 <geppetto> might want to do that then
19:04:28 <tibbs|w> geppetto: I already bumped it.  And I guess we're way over time anyway.
19:04:30 <mizdebsk> dgilmore: with your proposal, if there is arch-specific BR, but srpm was built on arch that has this BR disabled then there would be no isa in any BR and no indication srpm needs to be rebuilt
19:04:36 <geppetto> dgilmore: #303
19:04:42 <geppetto> dgilmore: https://fedorahosted.org/fpc/ticket/303
19:05:15 <geppetto> #info Lots more talking about ticket 303, arched build requires and using _isa in buildrequires
19:05:20 <dgilmore> geppetto: adding myself
19:05:25 <geppetto> cool
19:05:53 <geppetto> I'm going to close in a few unless someone really needs to talk more about something :)
19:06:16 <tibbs|w> Nope.
19:06:31 <tibbs|w> Down to 18 tickets, though.
19:06:40 <mizdebsk> i'll add myself to #303 as well - i'm open for discussion
19:07:11 <tibbs|w> geppetto: One day we're going to have to figure out to do with 142 and 339, though.
19:07:40 <tibbs|w> Actually I don't understand why 142 is still open.  I guess I'll close it again and incur the wrath of another of our agitators.
19:09:26 <geppetto> One day :-o
19:09:35 <geppetto> #endmeeting