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