Jan 23 10:00:02 FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod Jan 23 10:00:05 present Jan 23 10:00:10 * notting is here Jan 23 10:00:13 * sharkcz present Jan 23 10:00:20 * jwb is here Jan 23 10:00:34 * nirik is here. Jan 23 10:00:49 * bpepple is here. Jan 23 10:01:09 dgilmore: ping Jan 23 10:01:14 <-- KageSenshi has quit ("この世に必然なんてない・・・あるのは必然だけ") Jan 23 10:02:03 oh well, let's get started I guess Jan 23 10:02:04 jds2001: sorry i heard this is for cardinals fans only. ill have to take my exit :) Jan 23 10:02:09 lol :) Jan 23 10:02:29 ok, let's get started Jan 23 10:02:45 --- jds2001 has changed the topic to: FESCo Meeting - agenda at https://fedorahosted.org/fesco/report/9 -- tickets Jan 23 10:02:51 .fesco 26 Jan 23 10:02:53 jds2001: #26 (Archer) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/26 Jan 23 10:03:22 anyone here to represent this? Jan 23 10:03:33 i don't see tromey Jan 23 10:03:35 --> J5 (n=quintice@c-66-31-41-146.hsd1.ma.comcast.net) has joined #fedora-meeting Jan 23 10:04:27 --> J5_ (n=quintice@nat/redhat/x-e4f05336f8bfd1ec) has joined #fedora-meeting Jan 23 10:04:51 reading the feature page i dont have any questions Jan 23 10:04:55 OK, does anyone have questions that we should postpone this? Jan 23 10:04:58 me either Jan 23 10:05:03 +1 from me Jan 23 10:05:11 no questions and +1 Jan 23 10:05:12 +1 here Jan 23 10:05:16 +1 looks straight-forward to me. Jan 23 10:05:19 +1 Jan 23 10:05:21 looks good to me, +1 Jan 23 10:05:41 +1 Jan 23 10:05:48 i need to step away for just a minute. be right back Jan 23 10:05:49 so this is a gdb fork... it replaces current gdb? or exists alongside it? Jan 23 10:05:50 I see six +1's, so we've approved the Archer feature Jan 23 10:06:03 i think it replaces it. Jan 23 10:06:26 at least from what I see on the page, esp the contingency plan Jan 23 10:06:30 doesn't seem to be a fork, but rather a merger of upstream development branches Jan 23 10:06:51 ok... +1 from me as well. Jan 23 10:07:14 moving right along... Jan 23 10:07:17 .fesco 27 Jan 23 10:07:19 jds2001: #27 (IBus) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/27 Jan 23 10:07:25 https://fedoraproject.org/wiki/Features/IBus Jan 23 10:08:08 anyone around to represent this one? Jan 23 10:08:33 it's very much the wrong time of day for them Jan 23 10:08:38 yeah Jan 23 10:09:01 +1, but i'd like to see them answer Rathann's questions. Jan 23 10:09:32 the test plan is pretty vague Jan 23 10:09:43 but otherwise +1 Jan 23 10:09:49 joy. yet another input method. Jan 23 10:09:51 I think the answer to the first question is yes, not sure about the second. Jan 23 10:10:17 +1 Jan 23 10:10:21 j-rod: yeah, we are leaving behind a trail of them. ;) Jan 23 10:10:35 +1 here too Jan 23 10:10:36 +1 here... Jan 23 10:10:39 +1 Jan 23 10:10:53 j-rod: scim upstream is dead :/ Jan 23 10:11:01 0 Jan 23 10:11:03 similar to the font reorg... can this be the last time we have yet another input method framework? Jan 23 10:11:07 i see six +1's, so we've approved the IBus feature Jan 23 10:11:19 j-rod: yeah, that would be nice. Jan 23 10:11:23 Too late anyway, but I'm a 0 as well. Jan 23 10:11:36 it will be in the IRC log :) Jan 23 10:11:43 .fesco 30 Jan 23 10:11:48 jds2001: #30 (KVM PCI Device Assignment - http://tinyurl.com/cq6w93) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/30 Jan 23 10:11:55 <-- mcepl (n=mcepl@49-117-207-85.strcechy.adsl-llu.static.bluetone.cz) has left #fedora-meeting Jan 23 10:11:58 this looks nice and cool. +1 here. Jan 23 10:12:10 +1 i want to use it Jan 23 10:12:13 +1 here too Jan 23 10:12:17 +1 Jan 23 10:12:33 * nirik has a modem card for * that he would love to be able to passthru to a guest. Jan 23 10:12:39 +1, yes please Jan 23 10:12:51 ah, was going to ask about graphics cards. :) Jan 23 10:13:08 +1 Jan 23 10:13:13 i saw markmc join :) Jan 23 10:13:21 nirik, yeah, one of the most common requests :) Jan 23 10:13:23 markmc: is this 'all' PCI, including -E, mini, mini-E, cardbus, etc? Jan 23 10:13:26 notting, outta luck for now Jan 23 10:13:59 notting, bleh, PCI-X is what works well Jan 23 10:14:11 notting, everything is else *shrug* try and see Jan 23 10:14:35 nirik: i want to move asterisk to its own virtual machine. but need to pass through the tdm400 Jan 23 10:15:05 +1 Jan 23 10:15:06 markmc: what are the reasons? Jan 23 10:15:15 markmc, then can you rename the feature to PCI-X? Jan 23 10:15:22 dgilmore, see "phone line termination cards" :) Jan 23 10:15:33 back in 2 min... sorry Jan 23 10:15:50 sharkcz, jwb, VT-d is all tied up in PCI-X details Jan 23 10:16:07 sharkcz, jwb, but you can use e.g. a PCI device behind a conventional bridge Jan 23 10:16:21 sharkcz, jwb, just not assign another device behind that bridge to another guest Jan 23 10:16:24 but unless you're testing that and know it works... Jan 23 10:16:31 (and more horrible details ad nauseum) Jan 23 10:16:33 markmc: ok Jan 23 10:16:45 i just want to make sure the feature is promoting what is actually being tested Jan 23 10:17:10 so we don't get "ZOMG THIS DOESN'T WORK WITH MY PCI-E SOUND CARD" or something ridiculous Jan 23 10:17:11 jwb, not in anger yet, but we certainly want to get there Jan 23 10:17:36 jwb, if it hasn't had enough testing or is plane broken, we'll be taking it out of the UI and release notes etc. Jan 23 10:17:40 yea, put there some pointer for required/recommended HW Jan 23 10:17:53 markmc, i think you're misunderstanding what i'm asking... Jan 23 10:18:03 jwb, one idea is just to expose it as "KVM PCI Network Interface Assignment" to limit it to a specific set of hardware Jan 23 10:18:12 jwb, except that would rule out the TDM cards, so .... Jan 23 10:18:19 markmc, all i'm asking is that you do this: KVM_PCI-X_Device_Assignment Jan 23 10:18:21 for now Jan 23 10:18:24 IIRC it requires some kernel bits which, last time we turned them on, they kind of blew up a lot of machines with faulty BIOSes Jan 23 10:18:42 jwb, I understand, but I think not - e.g. the TDM cards aren't PCI-X AFAIK Jan 23 10:19:03 wwoods, CONFIG_DMAR is enabled again now AFAIR Jan 23 10:19:31 wwoods, said blowing up needs to be just fixed if it still exists Jan 23 10:19:37 wwoods, e.g. more black listing Jan 23 10:19:58 config-x86_64-generic:CONFIG_DMAR=y Jan 23 10:19:58 config-x86_64-generic:CONFIG_DMAR_GFX_WA=y Jan 23 10:19:58 config-x86_64-generic:CONFIG_DMAR_FLOPPY_WA=y Jan 23 10:20:22 markmc: so will it work with my pci tdm400? and can i test that today? Jan 23 10:20:31 <-- J5 has quit (Connection timed out) Jan 23 10:20:33 the PCI-X part... is that "any PCI or PCI-X card behind a PCI-X bridge" ? Jan 23 10:20:48 s/any/most/ Jan 23 10:20:57 --> J5 (n=quintice@nat/redhat/x-36c93bcba8fa1f31) has joined #fedora-meeting Jan 23 10:20:58 or some Jan 23 10:21:16 dgilmore, there's no UI yet or code to unbind the card in the host except, but you could try with qemu-kvm -pcidevice Jan 23 10:22:01 j-rod, any PCI-X card, I think Jan 23 10:22:27 j-rod, the details are vague, but the plan is to not present any un-assignable cards in the UI Jan 23 10:22:30 markmc: I think I asked that wrong... Jan 23 10:22:34 markmc: right, that was it - is there an obvious way to determine when "my machine is broken" is due to DMAR Jan 23 10:22:52 so we can make sure bug reports get assigned to the right people to update the blacklsits Jan 23 10:23:09 wwoods, I think they typically just don't boot, not 100% sure Jan 23 10:23:16 markmc: what I'm meaning to ask is whether most any device sitting behind a pci-x bridge should be able to be passed through, or can one also pass a tdm card through if its sitting in a plain pci slot? Jan 23 10:23:22 wwoods, but I haven't noticed any new reports in quite a while Jan 23 10:23:43 markmc: so is there a magic "nodmar" flag that would disable that support (and thus prove that dmar is the cause of the problem)? Jan 23 10:23:51 j-rod, yes, you could assign the tdm card to a guest Jan 23 10:23:57 (trying to understand if the 'VT-d is all tied up in PCI-X details" comment means a PCI-X bridge is required) Jan 23 10:24:07 j-rod, but e.g. if you had another tdm card behind the same bridge, you couldn't assign that to another guest Jan 23 10:24:35 j-rod, any machine with VT-d will have PCI-X as the root AFAIK Jan 23 10:25:01 wwoods, yes, I think there is a flag like that Jan 23 10:25:03 * markmc looks Jan 23 10:25:20 markmc: ah, ok, that more or less answers what I'm asking then :) Jan 23 10:25:33 perhaps stating that on the page would help Jan 23 10:25:45 because not everybody will know wtf VT-d means Jan 23 10:26:07 jwb, intel_iommu=off Jan 23 10:26:08 and where to expect it Jan 23 10:26:11 does the same hold true for AMD? Jan 23 10:26:40 jwb, it's similar to "you need VT support for KVM", that's all Jan 23 10:26:53 j-rod, don't know the details of AMD IOMMU at all Jan 23 10:27:07 --> sdziallas_ (n=sebastia@p57A2D5F6.dip.t-dialin.net) has joined #fedora-meeting Jan 23 10:27:17 markmc: "intel_iommu=off" is the magic "dmar-b-gon" flag? Jan 23 10:27:26 wwoods, looks like it, yeah Jan 23 10:28:13 markmc: any idea when that change went into the rawhide kernel? Jan 23 10:28:19 <-- neverho0d has quit (Read error: 110 (Connection timed out)) Jan 23 10:28:44 where should I tell testers to report DMAR-related failures, and what info do they need to include in the report? Jan 23 10:28:53 I assume bz.r.c, rawhide/kernel Jan 23 10:29:26 wwoods, before may 2008 AFAICS Jan 23 10:29:37 wwoods, bugzilla or fedora-kernel@ Jan 23 10:30:04 markmc: really? I thought we disabled it until just recently Jan 23 10:30:30 wwoods, okay, re-enabled on 2009-01-13 Jan 23 10:31:06 <-- nicubunu (n=nicubunu@mail.apsro.com) has left #fedora-meeting ("Fading into sunset") Jan 23 10:31:08 * Thu May 22 2008 Dave Jones Jan 23 10:31:08 - Disable CONFIG_DMAR. This is terminally broken in the presence of a broken BIOS Jan 23 10:31:20 * Tue Jan 13 2009 Kyle McMartin Jan 23 10:31:20 - Enable CONFIG_DMAR (and GFX_WA and FLOPPY_WA) requested by Gerd. Jan 23 10:31:38 excellent. IIRC We've had some reports of rawhide kernels not booting recently, so I'll direct testers to try intel_iommu=off Jan 23 10:32:02 wwoods, great Jan 23 10:32:03 if that fixes their problem, what info is needed to update the blacklist? output of dmidecode? Jan 23 10:32:36 wwoods, not sure, TBH Jan 23 10:33:08 wwoods, iommu@lists.linux-foundation.org is probably a sensible place to send the details Jan 23 10:33:22 fair 'nuff. I'll just direct everyone to a single bug and if we see problems we'll comment there Jan 23 10:33:28 thanks for the info Jan 23 10:33:42 alrihgt, I saw seven +1 Jan 23 10:34:01 so we've approved the KVM PCI Device Assignment feature Jan 23 10:34:25 .fesco 31 Jan 23 10:34:27 jds2001: #31 (SSSD - https://fedoraproject.org/wiki/Features/SSSD) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/31 Jan 23 10:34:40 thanks guys Jan 23 10:34:48 alas. not system security data daemon? Jan 23 10:34:56 thanks alot markmc for taking the time to answer all the questions :) Jan 23 10:35:13 nah Jan 23 10:35:21 the system security services daemon :) Jan 23 10:36:23 --> sgallagh (n=sgallagh@nat/redhat/x-251ed8779e64b561) has joined #fedora-meeting Jan 23 10:36:47 cool, i was about ready to say sgallagh wasn't around :) Jan 23 10:36:50 so this all seems like really cool stuff i'll never sue Jan 23 10:36:52 er, use Jan 23 10:36:55 sgallagh: so, this is intended to replace the current combination of nss_ldap, pam_krb5, pam_ccreds? Jan 23 10:36:58 yeah, same here. ;) Jan 23 10:37:13 --> neverho0d (n=psv@vpn-pool-78-139-211-156.tomtel.ru) has joined #fedora-meeting Jan 23 10:37:22 and someone explain how the term "technology preview" got into a Fedora feature page... Jan 23 10:37:37 fedora itself is a technology preview... Jan 23 10:37:44 hehe i was wondering the same thing. Jan 23 10:37:48 notting: short-term it will be complementary. medium-/long-term, yes. Jan 23 10:38:08 so all this does is provide caching for offline auth? Jan 23 10:38:19 or am I missing something totally? Jan 23 10:38:22 --> mclasen (n=mclasen@nat/redhat/x-2500ddef70b93aa3) has joined #fedora-meeting Jan 23 10:38:35 jds2001: It's also an integration point for central HBAC management Jan 23 10:38:50 sgallagh: is the nss stuff client/server so that we're not sucking $random_lib_of_the_day into process-space? Jan 23 10:39:08 HBAC == Jan 23 10:39:08 <-- sdziallas has quit (Read error: 110 (Connection timed out)) Jan 23 10:39:09 ? Jan 23 10:39:15 oh Jan 23 10:39:23 notting: Yes, it's client-server. Jan 23 10:39:25 host based access control? Jan 23 10:39:29 jwb: Host-based access control Jan 23 10:39:32 i like the idea of SSSD i wish it was more complete Jan 23 10:39:33 thanks. Jan 23 10:39:41 sgallagh: well, that takes all the entertainment out of nss_ldap bugs Jan 23 10:39:44 SSSD is being developed concurrently with FreeIPA v2 Jan 23 10:39:50 i think its going to need lots of testing Jan 23 10:39:52 sgallagh, what are your chances of getting this testable by Beta? Jan 23 10:40:08 jwb: I don't have the schedule handy, what's the beta date? Jan 23 10:40:18 mid-march iirc Jan 23 10:40:24 3-10 Jan 23 10:40:28 March 10 Jan 23 10:40:29 <-- hanthana has quit ("Leaving") Jan 23 10:40:37 that's when Beta freeze is Jan 23 10:40:43 Feature freeze is a week before Jan 23 10:40:45 actually Jan 23 10:40:49 Feature freeze is March 3rd Jan 23 10:40:53 i said that Jan 23 10:41:03 jwb: we were typing at the same time (: Jan 23 10:41:21 i win. w00t Jan 23 10:41:53 the idea is great and should close some gaps Jan 23 10:42:36 i think it sounds really cool. i'm just wondering if we should defer until we get a better feel for it being complete in time Jan 23 10:42:45 well. Jan 23 10:42:53 a feature can always be dropped if it's not ready in time Jan 23 10:42:57 Sorry, please hold Jan 23 10:43:05 i'm +1 for the feature - we can drop it/not publicize it if it's not ready Jan 23 10:43:08 Conversing with my colleagues on that date Jan 23 10:43:17 it just needs a good contengency plan Jan 23 10:43:24 yeah, +1 here, and if it's not ready we can try again for f12. Jan 23 10:43:26 f13: Contingency is: don't use it Jan 23 10:43:36 +1 as notting Jan 23 10:43:40 +1 if it's that simple. Jan 23 10:43:47 It's not replacing anything in this release Jan 23 10:43:49 +1 Jan 23 10:43:53 drop it later if need be. Jan 23 10:43:54 sgallagh: sure, I haven't looked at the scope yet to see if there would be any changes that would have to be rolled back. Jan 23 10:44:02 +1 Jan 23 10:44:06 (I'm not actually in FESCo, just lurking) Jan 23 10:44:22 f13: you're always welcome here :) Jan 23 10:44:25 f13: Rollback should be limited to removing from nssswitch.conf and pam config Jan 23 10:44:36 <-- lfoppiano has quit (Read error: 110 (Connection timed out)) Jan 23 10:44:40 sgallagh: see, there /is/ a contingency plan! Jan 23 10:44:48 I put that in the feature page, I thought Jan 23 10:44:55 you may have (: Jan 23 10:45:14 Ah, not enough detail. Sorry Jan 23 10:45:48 i see six +1's, so we've approved the SSSD feature, with the understanding that if it's not testable by beta, we'll drop it. Jan 23 10:46:00 +1, just concerned about testability by beta freeze Jan 23 10:46:03 * j-rod tardy again Jan 23 10:46:04 (same goes for any feature, really) Jan 23 10:46:16 j-rod: get on the ball! :D Jan 23 10:46:44 .fesco 32 Jan 23 10:46:46 jds2001: #32 (Instant on Fedora - https://fedoraproject.org/wiki/Features/instant-on-Fedora) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/32 Jan 23 10:46:52 sorry, saw a shiny object... Jan 23 10:47:00 does this actually have someone working on it? Jan 23 10:47:05 this seemed like more of a wishlist item to me, there's no scope. Jan 23 10:47:09 j-rod: looking out the window at your car again? Jan 23 10:47:22 f13: mmmmaaaaaaaayybe Jan 23 10:47:25 yeah, without someone doing the work, I don't see that we can approve this... Jan 23 10:47:26 poelcat, ping? Jan 23 10:47:39 he "Don't know the work involved to get a working strip down kernel and X" Jan 23 10:47:43 * nirik sees no answer to nottings question on this on the talk page Jan 23 10:48:04 -1, unless it's clear that someone is actually working on this. Jan 23 10:48:05 jwb: pong Jan 23 10:48:07 --> gregdek (n=gdk@nat/redhat/x-9251228cbf446c8c) has joined #fedora-meeting Jan 23 10:48:11 -1 from me Jan 23 10:48:24 poelcat, quick favor to ask. could you not send features to FESCo that have 0% completion? Jan 23 10:48:26 -1 here. Jan 23 10:48:35 -1 Jan 23 10:48:36 -1 Jan 23 10:48:38 -1 here, no one's actually working on it. Jan 23 10:48:42 -1 Jan 23 10:48:58 jwb: ummm, that is not a requirement of the feature process... I can't that support that Jan 23 10:49:15 ok, fair enough Jan 23 10:49:16 it was never the intention of the feature process that something had to be done to propose it Jan 23 10:49:24 yeah, ok Jan 23 10:49:25 i see 7 -1's, so we've declined the Instant-On Fedora feature, since nobody appears to be working on it. Jan 23 10:49:34 we can change the process, but it is not fair to legislate as we go :) Jan 23 10:49:44 yep Jan 23 10:49:48 -1 Jan 23 10:50:16 onto the FPC report Jan 23 10:50:19 .fesco 29 Jan 23 10:50:22 jds2001: #29 (Review FPC Report - http://tinyurl.com/bfuuld) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/29 Jan 23 10:50:22 --- sdziallas_ is now known as sdziallas Jan 23 10:50:23 if there is no one to actually work on, that makes a little more sense, but just saying 0% done, therefore not accepted doesn't make sense to me Jan 23 10:51:01 * bpepple doesn't have any objections to the FPC guideline updates. Jan 23 10:51:27 I'm a bit worried about how vuage the 'Non obvious items' thing is... but hopefully people will use common sense. Jan 23 10:51:35 +1 to explictRequires Jan 23 10:51:36 yeah, same here. Jan 23 10:52:11 but +1 since I hope folks will use common sense. Jan 23 10:52:15 Haskell id like to know what the actual changes were Jan 23 10:52:18 I guess it can be revised if it causes problems... no objections here to the other items. Jan 23 10:52:28 +1, but the explicit requires can have some support directly in rpmbuild Jan 23 10:52:39 -1 to ExplicitRequires, both because non-obvious seems to be overly specified, and the ExplicitRequires isn't confined to library dependencies Jan 23 10:52:56 http://fedoraproject.org/w/index.php?title=PackagingDrafts%2FHaskell&diff=72514&oldid=62373 Jan 23 10:53:08 symlinks +1 Jan 23 10:53:53 maybe we should take these one at a time Jan 23 10:54:05 yeah Jan 23 10:54:29 so for explicitrequires, I'd like to see a little less guidance on what "non-obvious" means. Jan 23 10:54:30 <-- J5_ has quit ("Ex-Chat") Jan 23 10:54:46 rwmjones hit the nail on the head I think there. Jan 23 10:55:04 dont existing guidelines make "Since %{_docdir}/ghc/libraries is owned by ghc-doc it is recommended to subpackage haddock documentation in a doc subpackage, which can require ghc-doc for example, i don't think every package that doesn't use autoconf needs comments on why %configure isn't used Jan 23 10:55:27 * rwmjones did? Jan 23 10:55:36 ah ok Jan 23 10:55:40 * nirik is confused. We are talking about which item? Jan 23 10:55:47 explicitrequires Jan 23 10:55:59 which includes a clause about commenting "non-obvious" items Jan 23 10:56:02 it is a SHOULD but not MUST Jan 23 10:56:03 ok, and the non-obvious part of it? Jan 23 10:56:09 and enumerates those items. Jan 23 10:56:10 yeah Jan 23 10:56:20 well, some of those... (but not limited to) Jan 23 10:56:52 the ones that seem like they should remain enumerated are modified tarballs and license/legal changes. but aren't those covered elsewhere in the guidelines? Jan 23 10:57:17 something adding a note about commenting non-obvious stuff that is completely unrelated to Requires: seems, uh, out of place, on a page titled 'explicitRequires' Jan 23 10:57:17 sharkcz: if you put files in the filesystem not provided by the filesystem package and you dont own the path. you need to Requires the package that does own the path Jan 23 10:57:19 I see no problem with that list in particular... Jan 23 10:57:25 yep Jan 23 10:57:40 j-rod: yeah, thats confusing me too... they seem pretty seperate Jan 23 10:57:42 adding a comment about modified tarballs has nothing to do with explicit Requires Jan 23 10:57:48 <-- abadger1999 has quit (Read error: 60 (Operation timed out)) Jan 23 10:58:03 dgilmore: I mean the comments are SHOULD Jan 23 10:58:19 so while I think commenting non-obvious things is generally a good idea, this doc isn't the right place for the guidelines Jan 23 10:58:28 sharkcz: yeah im getting ahead sorry Jan 23 10:58:51 j-rod: I agree Jan 23 10:58:55 --> biertie (n=bert@19.159-136-217.adsl-dyn.isp.belgacom.be) has joined #fedora-meeting Jan 23 10:59:13 have real life meeting in 1min Jan 23 10:59:41 nirik: although... they're under a 'addition to packaging guidelines' heading in the page Jan 23 10:59:49 so maybe its just the page title that is suckage Jan 23 10:59:56 could be. Jan 23 11:00:09 <-- markmc (n=markmc@83-70-64-220-dynamic.b-ras1.srl.dublin.eircom.net) has left #fedora-meeting ("Leaving") Jan 23 11:00:22 and I assume this goes into the main guidelines page once approved Jan 23 11:00:33 rather than a subpage off of it. Jan 23 11:00:41 but then, what notting said: aren't most of these already covered elsewhere? Jan 23 11:00:59 the comments section should be somewhere under "spec readability" Jan 23 11:02:36 some of them are... this expands that I think, to 'you should document weirdness in your spec'... Jan 23 11:02:53 http://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Legibility Jan 23 11:03:26 is the place I think Jan 23 11:03:45 yeah, I was just looking for that :) Jan 23 11:04:33 so do we object to it? or just want it split out and integrated in a nice way? Jan 23 11:05:32 * nirik doesn't have a problem with the guideline, but agrees it shouldn't be in this page at the end. Jan 23 11:05:34 I'm not entirely sure that it needs to be enumerated such as it is. Jan 23 11:05:47 i agree with jds2001 Jan 23 11:05:48 imo split, put the "comment for non-obvious items" into ^ and make Explicit Requires separate paragraph Jan 23 11:07:11 I think the list plus the staring sentence is nice legal work :-) Jan 23 11:07:19 yeah, you can never list everything... perhaps it should have just more explaination? ie "In order for other people reading your spec to understand it, please comment anything that you do that is non obvious or changes from standard/defaults" Jan 23 11:07:37 and i'd like Explicit requires to be somewhat rephrased/softened. we don't need to be explaining why the kernel requires mkinitrd, etc. Jan 23 11:08:16 s/staring/starting/ Jan 23 11:09:55 for example, rephrase it as "Packages should only contain explicit Requires on other packages that are necessary the packages to function. Library dependencies should be added automatically by RPM's build process." or something along those lines Jan 23 11:09:55 mkinitrd is an obvious item Jan 23 11:10:33 and obvious to whom? Jan 23 11:10:50 mkinitrd is obvious to everyone here, but joe blow might not know what it does. Jan 23 11:11:15 if you don't know what the requirements do, perhaps you shouldn't be modifying the spec Jan 23 11:11:29 agreed :) Jan 23 11:12:00 i just find it odd that a guideline that started because a package had explict "Requires: libfoo libbar" now starts off with "Packages must not contain Explicit Requires: within the spec file, except ..." Jan 23 11:12:52 --> stmille (n=steve@204-16-153-141-static.ipnetworksinc.net) has joined #fedora-meeting Jan 23 11:13:47 ok, so where are we? kick back to FPC with comments to rework? Jan 23 11:14:03 yeah, I think so. Jan 23 11:14:07 --> abadger1999 (n=abadger1@nat/redhat/x-8f64f9c0a0b4d61c) has joined #fedora-meeting Jan 23 11:14:52 all in favor of kicking back ExplicitRequires to FPC with comments to rework? Jan 23 11:14:59 +1 here Jan 23 11:15:01 +1 Jan 23 11:15:03 +1 Jan 23 11:15:05 +1 Jan 23 11:15:17 +1 I guess... Jan 23 11:15:29 0 Jan 23 11:16:00 I see five +1's, so we've rejected the ExplicitRequires guideline, with comments to rework. Jan 23 11:16:26 on to Haskell guidelines.... Jan 23 11:16:48 0 Jan 23 11:17:45 +1, seems fine from the diff Jan 23 11:17:47 +1 Jan 23 11:18:33 jds2001: Haskell i had an issue with Jan 23 11:18:34 +1 here, does this require changes to existing packages? hopefully not too much churn Jan 23 11:18:43 dont existing guidelines make "Since %{_docdir}/ghc/libraries is owned by ghc-doc it is recommended to subpackage haddock documentation in a doc subpackage, which can require ghc-doc yeah, I thought that too. Jan 23 11:18:59 if you put files in the filesystem not provided by the filesystem package and you dont own the path. you need to Requires the package that does own the path Jan 23 11:19:42 and splitting docs is alredy part of the guidelines too. Jan 23 11:19:43 unless im misremebering the guidelines Jan 23 11:20:44 jds2001: splitting doc subpackages is only for packages with large docs Jan 23 11:21:04 i guess i misread what i posted Jan 23 11:21:10 yeah, with large being a judgement call. Jan 23 11:21:42 if you put docs in %{_docdir}/ghc/libraries your going to have to Requires ghc-doc Jan 23 11:21:55 but they are recommending you split those docs off Jan 23 11:22:37 not as clear as it could be but its ok Jan 23 11:22:52 +1 here too. Jan 23 11:23:18 i see five +1's, so we've approved the Haskell Guidelines. Jan 23 11:23:25 symlinks? Jan 23 11:23:36 symlinks +1 Jan 23 11:23:50 +1 Jan 23 11:24:08 why does symlinks exist Jan 23 11:24:16 we need to explain to people how to use symlinks? Jan 23 11:24:41 i guess it's to make explicit that either way is acceptable? Jan 23 11:24:43 jwb: most kde packages use symlinks for docs so that khelp works Jan 23 11:24:55 and? Jan 23 11:25:26 was there any issue that this guideline tries to solve? Jan 23 11:25:38 sharkcz, yeah that's a better way to phrase my question Jan 23 11:25:56 jwb: :-) Jan 23 11:26:01 perhaps rpmlint could stop yelling about links, but thats not a guideline thing. Jan 23 11:26:15 i know in the past we say symlinks must be relative Jan 23 11:26:25 s/say/said/ Jan 23 11:26:52 dgilmore: rpmlint says that... but it wasn't a guideline I don't think Jan 23 11:27:14 nirik: hmm it was always treated as a guideline Jan 23 11:27:26 yeah, reading the IRC log from FPC Jan 23 11:27:30 shouldn't be. Unless i missed where it was added. Jan 23 11:27:32 seems to be a reaction to https://bugzilla.redhat.com/show_bug.cgi?id=474057 Jan 23 11:27:33 Bug 474057: medium, low, ---, than@redhat.com, ASSIGNED, meinproc4 creates absolute instead of relative symlinks for the common directory Jan 23 11:28:14 <-- No5251 has quit (Read error: 113 (No route to host)) Jan 23 11:28:26 --- stickster_food is now known as stickster Jan 23 11:28:43 --> spot_ (i=spot@beer.tclug.org) has joined #fedora-meeting Jan 23 11:29:08 that could be closed->Notabug I think... but if there is a consistency issue, it would be nice for say all the kde packages to do the same thing with links. Jan 23 11:30:23 perhaps the connection is that the guideline is "quiet rpmlint" and rpmlint complains about absolute symlinks ... Jan 23 11:31:25 I think many people misread that... the guidelines say that rpmlint must be run and the results pasted in the review. Nothing about if they should be all dealt with. Sometimes rpmlint is wrong. Jan 23 11:31:39 so we're writing guidelines to contradict rpmlint output Jan 23 11:31:46 fix rpmlint instead? Jan 23 11:32:00 jwb: it will need fixing anyway Jan 23 11:32:05 "Run rpmlint on the rpms to examine them for common errors, and fix them (unless rpmlint is wrong, which can happen, too)." Jan 23 11:32:19 i have no real objections to the guideline, but it seems superfluous to me Jan 23 11:32:42 im +1 doesnt hurt to make it clear Jan 23 11:32:53 need to make sure a bug is filed for rpmlint Jan 23 11:33:12 still only have two +1's here, anyone else? Jan 23 11:33:13 * nirik has no problem with it, +1 here Jan 23 11:33:22 +1 (although fixing rpmlint never hurts) Jan 23 11:33:34 +1 Jan 23 11:33:58 +1 Jan 23 11:33:59 alright, I see five +1's, so we've approved the symlink guideline. Jan 23 11:34:00 +1 Jan 23 11:34:05 er, 7 +1 Jan 23 11:34:09 :) Jan 23 11:34:11 CRAP. late again... Jan 23 11:34:13 I suck Jan 23 11:34:15 oh well Jan 23 11:34:27 * jds2001 is just too fast :) Jan 23 11:34:50 that's all I had for today..... Jan 23 11:34:58 --- jds2001 has changed the topic to: FESCo Meeting - open floor Jan 23 11:35:10 <-- EvilBob has quit (Remote closed the connection) Jan 23 11:35:29 anybody got anything they want to talk about? Jan 23 11:35:45 QA guidelines ? Jan 23 11:35:47 did we want to talk about the cloning bugs thing? Jan 23 11:36:11 yeah, Kevin withdrew his complaint, but I think we should talk about it anyhow. Jan 23 11:36:13 nirik: didn't kevin drop that. Jan 23 11:36:16 jds2001: I agree with your mail Jan 23 11:36:21 did my reply to the thread make sense? Jan 23 11:36:44 bpepple: yeah, he did. Jan 23 11:37:00 jds2001: sure. I agree that any big changes in workflow should come thru fesco... Jan 23 11:37:06 I guess we can leave it at that Jan 23 11:37:45 --> EvilBob (n=EvilBob@fedora/bobjensen) has joined #Fedora-Meeting Jan 23 11:38:29 anything else on that topic? (or any other topic)? Jan 23 11:39:29 * jds2001 will end the meeting in 5 Jan 23 11:39:31 4 Jan 23 11:39:33 3 Jan 23 11:39:36 2 Jan 23 11:39:36 7 Jan 23 11:39:38 jds2001: you might want to remind folks at the beginning of the meeting who is responsible for writing the summary. Jan 23 11:39:49 bpepple: oh right.... Jan 23 11:40:02 just so they don't forget. Jan 23 11:40:05 jwb: you're on the hook for one more week :) Jan 23 11:40:12 <-- biertie has quit (Remote closed the connection) Jan 23 11:40:13 yep Jan 23 11:40:46 nirik: then it goes to you :) Jan 23 11:40:51 thanks for running things jds2001... and for writing up the summary jwb. Jan 23 11:40:55 jds2001: ok. Jan 23 11:41:00 np Jan 23 11:41:04 np Jan 23 11:41:25 -- MEETING END -- Jan 23 11:41:52 --- knurd is now known as knurd_afk Jan 23 11:42:20 <-- notting (n=notting@redhat/notting) has left #fedora-meeting ("Ex-Chat") Jan 23 11:46:10 --- EvilBob has changed the topic to: This channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Fedora_meeting_channel for meeting schedule