| ---Topic for #fedora-meeting is FESCo meeting -- init | ||
| ---Topic for #fedora-meeting set by jds2001 at Fri Jan 23 11:58:14 2009 | ||
| jds2001 | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod | |
|---|---|---|
| j-rod | present | |
| *notting is here | ||
| *sharkcz present | ||
| *jwb is here | ||
| *nirik is here. | ||
| *bpepple is here. | ||
| jds2001 | dgilmore: ping | |
| jds2001 | oh well, let's get started I guess | |
| dgilmore | jds2001: sorry i heard this is for cardinals fans only. ill have to take my exit :) | |
| jds2001 | lol :) | |
| jds2001 | ok, let's get started | |
| ---jds2001 has changed the topic to: FESCo Meeting - agenda at https://fedorahosted.org/fesco/report/9 -- tickets | ||
| jds2001 | .fesco 26 | |
| zodbot | jds2001: #26 (Archer) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/26 | |
| jds2001 | anyone here to represent this? | |
| notting | i don't see tromey | |
| dgilmore | reading the feature page i dont have any questions | |
| jds2001 | OK, does anyone have questions that we should postpone this? | |
| jds2001 | me either | |
| notting | +1 from me | |
| sharkcz | no questions and +1 | |
| jds2001 | +1 here | |
| bpepple | +1 looks straight-forward to me. | |
| dgilmore | +1 | |
| j-rod | looks good to me, +1 | |
| jwb | +1 | |
| jwb | i need to step away for just a minute. be right back | |
| nirik | so this is a gdb fork... it replaces current gdb? or exists alongside it? | |
| jds2001 | I see six +1's, so we've approved the Archer feature | |
| jds2001 | i think it replaces it. | |
| jds2001 | at least from what I see on the page, esp the contingency plan | |
| j-rod | doesn't seem to be a fork, but rather a merger of upstream development branches | |
| nirik | ok... +1 from me as well. | |
| jds2001 | moving right along... | |
| jds2001 | .fesco 27 | |
| zodbot | jds2001: #27 (IBus) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/27 | |
| markmc | https://fedoraproject.org/wiki/Features/IBus | |
| jds2001 | anyone around to represent this one? | |
| notting | it's very much the wrong time of day for them | |
| jds2001 | yeah | |
| bpepple | +1, but i'd like to see them answer Rathann's questions. | |
| dgilmore | the test plan is pretty vague | |
| dgilmore | but otherwise +1 | |
| j-rod | joy. yet another input method. | |
| nirik | I think the answer to the first question is yes, not sure about the second. | |
| notting | +1 | |
| nirik | j-rod: yeah, we are leaving behind a trail of them. ;) | |
| jds2001 | +1 here too | |
| nirik | +1 here... | |
| sharkcz | +1 | |
| notting | j-rod: scim upstream is dead :/ | |
| jwb | 0 | |
| j-rod | similar to the font reorg... can this be the last time we have yet another input method framework? | |
| jds2001 | i see six +1's, so we've approved the IBus feature | |
| bpepple | j-rod: yeah, that would be nice. | |
| j-rod | Too late anyway, but I'm a 0 as well. | |
| jds2001 | it will be in the IRC log :) | |
| jds2001 | .fesco 30 | |
| zodbot | jds2001: #30 (KVM PCI Device Assignment - http://tinyurl.com/cq6w93) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/30 | |
| nirik | this looks nice and cool. +1 here. | |
| dgilmore | +1 i want to use it | |
| jds2001 | +1 here too | |
| sharkcz | +1 | |
| *nirik has a modem card for * that he would love to be able to passthru to a guest. | ||
| j-rod | +1, yes please | |
| notting | ah, was going to ask about graphics cards. :) | |
| bpepple | +1 | |
| jds2001 | i saw markmc join :) | |
| markmc | nirik, yeah, one of the most common requests :) | |
| notting | markmc: is this 'all' PCI, including -E, mini, mini-E, cardbus, etc? | |
| markmc | notting, outta luck for now | |
| markmc | notting, bleh, PCI-X is what works well | |
| markmc | notting, everything is else *shrug* try and see | |
| dgilmore | nirik: i want to move asterisk to its own virtual machine. but need to pass through the tdm400 | |
| notting | +1 | |
| sharkcz | markmc: what are the reasons? | |
| jwb | markmc, then can you rename the feature to PCI-X? | |
| markmc | dgilmore, see "phone line termination cards" :) | |
| notting | back in 2 min... sorry | |
| markmc | sharkcz, jwb, VT-d is all tied up in PCI-X details | |
| markmc | sharkcz, jwb, but you can use e.g. a PCI device behind a conventional bridge | |
| markmc | sharkcz, jwb, just not assign another device behind that bridge to another guest | |
| jwb | but unless you're testing that and know it works... | |
| markmc | (and more horrible details ad nauseum) | |
| sharkcz | markmc: ok | |
| jwb | i just want to make sure the feature is promoting what is actually being tested | |
| markmc | jwb, not in anger yet, but we certainly want to get there | |
| jwb | so we don't get "ZOMG THIS DOESN'T WORK WITH MY PCI-E SOUND CARD" or something ridiculous | |
| markmc | 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. | |
| sharkcz | yea, put there some pointer for required/recommended HW | |
| jwb | markmc, i think you're misunderstanding what i'm asking... | |
| markmc | jwb, one idea is just to expose it as "KVM PCI Network Interface Assignment" to limit it to a specific set of hardware | |
| markmc | jwb, except that would rule out the TDM cards, so .... | |
| jwb | markmc, all i'm asking is that you do this: KVM_PCI-X_Device_Assignment | |
| jwb | for now | |
| wwoods | 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 | |
| markmc | jwb, I understand, but I think not - e.g. the TDM cards aren't PCI-X AFAIK | |
| markmc | wwoods, CONFIG_DMAR is enabled again now AFAIR | |
| markmc | wwoods, said blowing up needs to be just fixed if it still exists | |
| markmc | wwoods, e.g. more black listing | |
| markmc | config-x86_64-generic:CONFIG_DMAR=y | |
| markmc | config-x86_64-generic:CONFIG_DMAR_GFX_WA=y | |
| markmc | config-x86_64-generic:CONFIG_DMAR_FLOPPY_WA=y | |
| dgilmore | markmc: so will it work with my pci tdm400? and can i test that today? | |
| j-rod | the PCI-X part... is that "any PCI or PCI-X card behind a PCI-X bridge" ? | |
| j-rod | s/any/most/ | |
| j-rod | or some | |
| markmc | dgilmore, there's no UI yet or code to unbind the card in the host except, but you could try with qemu-kvm -pcidevice | |
| markmc | j-rod, any PCI-X card, I think | |
| markmc | j-rod, the details are vague, but the plan is to not present any un-assignable cards in the UI | |
| j-rod | markmc: I think I asked that wrong... | |
| wwoods | markmc: right, that was it - is there an obvious way to determine when "my machine is broken" is due to DMAR | |
| wwoods | so we can make sure bug reports get assigned to the right people to update the blacklsits | |
| markmc | wwoods, I think they typically just don't boot, not 100% sure | |
| j-rod | 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? | |
| markmc | wwoods, but I haven't noticed any new reports in quite a while | |
| wwoods | markmc: so is there a magic "nodmar" flag that would disable that support (and thus prove that dmar is the cause of the problem)? | |
| markmc | j-rod, yes, you could assign the tdm card to a guest | |
| j-rod | (trying to understand if the 'VT-d is all tied up in PCI-X details" comment means a PCI-X bridge is required) | |
| markmc | j-rod, but e.g. if you had another tdm card behind the same bridge, you couldn't assign that to another guest | |
| markmc | j-rod, any machine with VT-d will have PCI-X as the root AFAIK | |
| markmc | wwoods, yes, I think there is a flag like that | |
| *markmc looks | ||
| j-rod | markmc: ah, ok, that more or less answers what I'm asking then :) | |
| jwb | perhaps stating that on the page would help | |
| jwb | because not everybody will know wtf VT-d means | |
| markmc | jwb, intel_iommu=off | |
| sharkcz | and where to expect it | |
| j-rod | does the same hold true for AMD? | |
| markmc | jwb, it's similar to "you need VT support for KVM", that's all | |
| markmc | j-rod, don't know the details of AMD IOMMU at all | |
| wwoods | markmc: "intel_iommu=off" is the magic "dmar-b-gon" flag? | |
| markmc | wwoods, looks like it, yeah | |
| wwoods | markmc: any idea when that change went into the rawhide kernel? | |
| wwoods | where should I tell testers to report DMAR-related failures, and what info do they need to include in the report? | |
| wwoods | I assume bz.r.c, rawhide/kernel | |
| markmc | wwoods, before may 2008 AFAICS | |
| markmc | wwoods, bugzilla or fedora-kernel@ | |
| wwoods | markmc: really? I thought we disabled it until just recently | |
| markmc | wwoods, okay, re-enabled on 2009-01-13 | |
| markmc | * Thu May 22 2008 Dave Jones <davej@redhat.com> | |
| markmc | - Disable CONFIG_DMAR. This is terminally broken in the presence of a broken BIOS | |
| markmc | * Tue Jan 13 2009 Kyle McMartin <kyle@redhat.com> | |
| markmc | - Enable CONFIG_DMAR (and GFX_WA and FLOPPY_WA) requested by Gerd. | |
| wwoods | excellent. IIRC We've had some reports of rawhide kernels not booting recently, so I'll direct testers to try intel_iommu=off | |
| markmc | wwoods, great | |
| wwoods | if that fixes their problem, what info is needed to update the blacklist? output of dmidecode? | |
| markmc | wwoods, not sure, TBH | |
| markmc | wwoods, iommu@lists.linux-foundation.org is probably a sensible place to send the details | |
| wwoods | fair 'nuff. I'll just direct everyone to a single bug and if we see problems we'll comment there | |
| wwoods | thanks for the info | |
| jds2001 | alrihgt, I saw seven +1 | |
| jds2001 | so we've approved the KVM PCI Device Assignment feature | |
| jds2001 | .fesco 31 | |
| zodbot | jds2001: #31 (SSSD - https://fedoraproject.org/wiki/Features/SSSD) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/31 | |
| markmc | thanks guys | |
| notting | alas. not system security data daemon? | |
| jds2001 | thanks alot markmc for taking the time to answer all the questions :) | |
| jds2001 | nah | |
| jds2001 | the system security services daemon :) | |
| jds2001 | cool, i was about ready to say sgallagh wasn't around :) | |
| jwb | so this all seems like really cool stuff i'll never sue | |
| jwb | er, use | |
| notting | sgallagh: so, this is intended to replace the current combination of nss_ldap, pam_krb5, pam_ccreds? | |
| nirik | yeah, same here. ;) | |
| jwb | and someone explain how the term "technology preview" got into a Fedora feature page... | |
| jwb | fedora itself is a technology preview... | |
| jds2001 | hehe i was wondering the same thing. | |
| sgallagh | notting: short-term it will be complementary. medium-/long-term, yes. | |
| jds2001 | so all this does is provide caching for offline auth? | |
| jds2001 | or am I missing something totally? | |
| sgallagh | jds2001: It's also an integration point for central HBAC management | |
| notting | sgallagh: is the nss stuff client/server so that we're not sucking $random_lib_of_the_day into process-space? | |
| jwb | HBAC == | |
| jwb | ? | |
| jwb | oh | |
| sgallagh | notting: Yes, it's client-server. | |
| sharkcz | host based access control? | |
| sgallagh | jwb: Host-based access control | |
| dgilmore | i like the idea of SSSD i wish it was more complete | |
| jwb | thanks. | |
| notting | sgallagh: well, that takes all the entertainment out of nss_ldap bugs | |
| sgallagh | SSSD is being developed concurrently with FreeIPA v2 | |
| dgilmore | i think its going to need lots of testing | |
| jwb | sgallagh, what are your chances of getting this testable by Beta? | |
| sgallagh | jwb: I don't have the schedule handy, what's the beta date? | |
| jds2001 | mid-march iirc | |
| jwb | 3-10 | |
| jwb | March 10 | |
| jwb | that's when Beta freeze is | |
| jwb | Feature freeze is a week before | |
| f13 | actually | |
| f13 | Feature freeze is March 3rd | |
| jwb | i said that | |
| f13 | jwb: we were typing at the same time (: | |
| jwb | i win. w00t | |
| sharkcz | the idea is great and should close some gaps | |
| jwb | 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 | |
| f13 | well. | |
| f13 | a feature can always be dropped if it's not ready in time | |
| sgallagh | Sorry, please hold | |
| notting | i'm +1 for the feature - we can drop it/not publicize it if it's not ready | |
| sgallagh | Conversing with my colleagues on that date | |
| f13 | it just needs a good contengency plan | |
| nirik | yeah, +1 here, and if it's not ready we can try again for f12. | |
| sgallagh | f13: Contingency is: don't use it | |
| sharkcz | +1 as notting | |
| jds2001 | +1 if it's that simple. | |
| sgallagh | It's not replacing anything in this release | |
| bpepple | +1 | |
| jds2001 | drop it later if need be. | |
| f13 | 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. | |
| jwb | +1 | |
| f13 | (I'm not actually in FESCo, just lurking) | |
| jds2001 | f13: you're always welcome here :) | |
| sgallagh | f13: Rollback should be limited to removing from nssswitch.conf and pam config | |
| f13 | sgallagh: see, there /is/ a contingency plan! | |
| sgallagh | I put that in the feature page, I thought | |
| f13 | you may have (: | |
| sgallagh | Ah, not enough detail. Sorry | |
| jds2001 | 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. | |
| j-rod | +1, just concerned about testability by beta freeze | |
| *j-rod tardy again | ||
| jds2001 | (same goes for any feature, really) | |
| jds2001 | j-rod: get on the ball! :D | |
| jds2001 | .fesco 32 | |
| zodbot | jds2001: #32 (Instant on Fedora - https://fedoraproject.org/wiki/Features/instant-on-Fedora) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/32 | |
| j-rod | sorry, saw a shiny object... | |
| bpepple | does this actually have someone working on it? | |
| jds2001 | this seemed like more of a wishlist item to me, there's no scope. | |
| f13 | j-rod: looking out the window at your car again? | |
| j-rod | f13: mmmmaaaaaaaayybe | |
| nirik | yeah, without someone doing the work, I don't see that we can approve this... | |
| jwb | poelcat, ping? | |
| jds2001 | he "Don't know the work involved to get a working strip down kernel and X" | |
| *nirik sees no answer to nottings question on this on the talk page | ||
| bpepple | -1, unless it's clear that someone is actually working on this. | |
| poelcat | jwb: pong | |
| notting | -1 from me | |
| jwb | poelcat, quick favor to ask. could you not send features to FESCo that have 0% completion? | |
| nirik | -1 here. | |
| sharkcz | -1 | |
| j-rod | -1 | |
| jds2001 | -1 here, no one's actually working on it. | |
| jwb | -1 | |
| poelcat | jwb: ummm, that is not a requirement of the feature process... I can't that support that | |
| jwb | ok, fair enough | |
| poelcat | it was never the intention of the feature process that something had to be done to propose it | |
| jds2001 | i see 7 -1's, so we've declined the Instant-On Fedora feature, since nobody appears to be working on it. | |
| jwb | yeah, ok | |
| poelcat | we can change the process, but it is not fair to legislate as we go :) | |
| jwb | yep | |
| dgilmore | -1 | |
| jds2001 | onto the FPC report | |
| jds2001 | .fesco 29 | |
| zodbot | jds2001: #29 (Review FPC Report - http://tinyurl.com/bfuuld) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/29 | |
| ---sdziallas_ is now known as sdziallas | ||
| poelcat | 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 | |
| *bpepple doesn't have any objections to the FPC guideline updates. | ||
| nirik | I'm a bit worried about how vuage the 'Non obvious items' thing is... but hopefully people will use common sense. | |
| dgilmore | +1 to explictRequires | |
| jds2001 | yeah, same here. | |
| jds2001 | but +1 since I hope folks will use common sense. | |
| dgilmore | Haskell id like to know what the actual changes were | |
| nirik | I guess it can be revised if it causes problems... no objections here to the other items. | |
| sharkcz | +1, but the explicit requires can have some support directly in rpmbuild | |
| notting | -1 to ExplicitRequires, both because non-obvious seems to be overly specified, and the ExplicitRequires isn't confined to library dependencies | |
| jds2001 | http://fedoraproject.org/w/index.php?title=PackagingDrafts%2FHaskell&diff=72514&oldid=62373 | |
| dgilmore | symlinks +1 | |
| jwb | maybe we should take these one at a time | |
| jds2001 | yeah | |
| jds2001 | so for explicitrequires, I'd like to see a little less guidance on what "non-obvious" means. | |
| jds2001 | rwmjones hit the nail on the head I think there. | |
| dgilmore | dont existing guidelines make "Since <code>%{_docdir}/ghc/libraries</code> is owned by <code>ghc-doc</code> it is recommended to subpackage haddock documentation in a <code>doc</code> subpackage, which can require <code>ghc-doc</code" a must | |
| ---stickster is now known as stickster_food | ||
| notting | for example, i don't think every package that doesn't use autoconf needs comments on why %configure isn't used | |
| *rwmjones did? | ||
| rwmjones | ah ok | |
| *nirik is confused. We are talking about which item? | ||
| jds2001 | explicitrequires | |
| jds2001 | which includes a clause about commenting "non-obvious" items | |
| sharkcz | it is a SHOULD but not MUST | |
| nirik | ok, and the non-obvious part of it? | |
| jds2001 | and enumerates those items. | |
| jds2001 | yeah | |
| nirik | well, some of those... (but not limited to) | |
| notting | 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? | |
| j-rod | 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' | |
| dgilmore | 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 | |
| nirik | I see no problem with that list in particular... | |
| jds2001 | yep | |
| nirik | j-rod: yeah, thats confusing me too... they seem pretty seperate | |
| j-rod | adding a comment about modified tarballs has nothing to do with explicit Requires | |
| sharkcz | dgilmore: I mean the comments are SHOULD | |
| j-rod | so while I think commenting non-obvious things is generally a good idea, this doc isn't the right place for the guidelines | |
| dgilmore | sharkcz: yeah im getting ahead sorry | |
| nirik | j-rod: I agree | |
| jwb | have real life meeting in 1min | |
| j-rod | nirik: although... they're under a 'addition to packaging guidelines' heading in the page | |
| j-rod | so maybe its just the page title that is suckage | |
| nirik | could be. | |
| jds2001 | and I assume this goes into the main guidelines page once approved | |
| jds2001 | rather than a subpage off of it. | |
| j-rod | but then, what notting said: aren't most of these already covered elsewhere? | |
| sharkcz | the comments section should be somewhere under "spec readability" | |
| nirik | some of them are... this expands that I think, to 'you should document weirdness in your spec'... | |
| sharkcz | http://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Legibility | |
| sharkcz | is the place I think | |
| jds2001 | yeah, I was just looking for that :) | |
| nirik | so do we object to it? or just want it split out and integrated in a nice way? | |
| *nirik doesn't have a problem with the guideline, but agrees it shouldn't be in this page at the end. | ||
| jds2001 | I'm not entirely sure that it needs to be enumerated such as it is. | |
| notting | i agree with jds2001 | |
| sharkcz | imo split, put the "comment for non-obvious items" into ^ and make Explicit Requires separate paragraph | |
| sharkcz | I think the list plus the staring sentence is nice legal work :-) | |
| nirik | 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" | |
| notting | and i'd like Explicit requires to be somewhat rephrased/softened. we don't need to be explaining why the kernel requires mkinitrd, etc. | |
| sharkcz | s/staring/starting/ | |
| notting | 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 | |
| sharkcz | mkinitrd is an obvious item | |
| jds2001 | and obvious to whom? | |
| jds2001 | mkinitrd is obvious to everyone here, but joe blow might not know what it does. | |
| notting | if you don't know what the requirements do, perhaps you shouldn't be modifying the spec | |
| jds2001 | agreed :) | |
| notting | 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 ..." | |
| nirik | ok, so where are we? kick back to FPC with comments to rework? | |
| jds2001 | yeah, I think so. | |
| jds2001 | all in favor of kicking back ExplicitRequires to FPC with comments to rework? | |
| jds2001 | +1 here | |
| sharkcz | +1 | |
| jwb | +1 | |
| notting | +1 | |
| nirik | +1 I guess... | |
| bpepple | 0 | |
| jds2001 | I see five +1's, so we've rejected the ExplicitRequires guideline, with comments to rework. | |
| jds2001 | on to Haskell guidelines.... | |
| jwb | 0 | |
| notting | +1, seems fine from the diff | |
| sharkcz | +1 | |
| dgilmore | jds2001: Haskell i had an issue with | |
| nirik | +1 here, does this require changes to existing packages? hopefully not too much churn | |
| dgilmore | dont existing guidelines make "Since <code>%{_docdir}/ghc/libraries</code> is owned by <code>ghc-doc</code> it is recommended to subpackage haddock documentation in a <code>doc</code> subpackage, which can require <code>ghc-doc</code" a must | |
| jds2001 | yeah, I thought that too. | |
| dgilmore | 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 | |
| jds2001 | and splitting docs is alredy part of the guidelines too. | |
| dgilmore | unless im misremebering the guidelines | |
| dgilmore | jds2001: splitting doc subpackages is only for packages with large docs | |
| dgilmore | i guess i misread what i posted | |
| jds2001 | yeah, with large being a judgement call. | |
| dgilmore | if you put docs in %{_docdir}/ghc/libraries your going to have to Requires ghc-doc | |
| dgilmore | but they are recommending you split those docs off | |
| dgilmore | not as clear as it could be but its ok | |
| jds2001 | +1 here too. | |
| jds2001 | i see five +1's, so we've approved the Haskell Guidelines. | |
| jds2001 | symlinks? | |
| dgilmore | symlinks +1 | |
| jds2001 | +1 | |
| jwb | why does symlinks exist | |
| jwb | we need to explain to people how to use symlinks? | |
| jds2001 | i guess it's to make explicit that either way is acceptable? | |
| dgilmore | jwb: most kde packages use symlinks for docs so that khelp works | |
| jwb | and? | |
| sharkcz | was there any issue that this guideline tries to solve? | |
| jwb | sharkcz, yeah that's a better way to phrase my question | |
| sharkcz | jwb: :-) | |
| nirik | perhaps rpmlint could stop yelling about links, but thats not a guideline thing. | |
| dgilmore | i know in the past we say symlinks must be relative | |
| dgilmore | s/say/said/ | |
| nirik | dgilmore: rpmlint says that... but it wasn't a guideline I don't think | |
| dgilmore | nirik: hmm it was always treated as a guideline | |
| jds2001 | yeah, reading the IRC log from FPC | |
| nirik | shouldn't be. Unless i missed where it was added. | |
| jds2001 | seems to be a reaction to https://bugzilla.redhat.com/show_bug.cgi?id=474057 | |
| buggbot | Bug 474057: medium, low, ---, than@redhat.com, ASSIGNED, meinproc4 creates absolute instead of relative symlinks for the common directory | |
| ---stickster_food is now known as stickster | ||
| nirik | 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. | |
| sharkcz | perhaps the connection is that the guideline is "quiet rpmlint" and rpmlint complains about absolute symlinks ... | |
| nirik | 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. | |
| jwb | so we're writing guidelines to contradict rpmlint output | |
| jwb | fix rpmlint instead? | |
| dgilmore | jwb: it will need fixing anyway | |
| nirik | "Run rpmlint on the rpms to examine them for common errors, and fix them (unless rpmlint is wrong, which can happen, too)." | |
| jwb | i have no real objections to the guideline, but it seems superfluous to me | |
| dgilmore | im +1 doesnt hurt to make it clear | |
| dgilmore | need to make sure a bug is filed for rpmlint | |
| jds2001 | still only have two +1's here, anyone else? | |
| *nirik has no problem with it, +1 here | ||
| notting | +1 (although fixing rpmlint never hurts) | |
| sharkcz | +1 | |
| jwb | +1 | |
| jds2001 | alright, I see five +1's, so we've approved the symlink guideline. | |
| j-rod | +1 | |
| jds2001 | er, 7 +1 | |
| jds2001 | :) | |
| j-rod | CRAP. late again... | |
| j-rod | I suck | |
| j-rod | oh well | |
| *jds2001 is just too fast :) | ||
| jds2001 | that's all I had for today..... | |
| ---jds2001 has changed the topic to: FESCo Meeting - open floor | ||
| jds2001 | anybody got anything they want to talk about? | |
| sharkcz | QA guidelines ? | |
| nirik | did we want to talk about the cloning bugs thing? | |
| jds2001 | yeah, Kevin withdrew his complaint, but I think we should talk about it anyhow. | |
| bpepple | nirik: didn't kevin drop that. | |
| sharkcz | jds2001: I agree with your mail | |
| jds2001 | did my reply to the thread make sense? | |
| nirik | bpepple: yeah, he did. | |
| nirik | jds2001: sure. I agree that any big changes in workflow should come thru fesco... | |
| nirik | I guess we can leave it at that | |
| jds2001 | anything else on that topic? (or any other topic)? | |
| *jds2001 will end the meeting in 5 | ||
| jds2001 | 4 | |
| jds2001 | 3 | |
| jds2001 | 2 | |
| j-rod | 7 | |
| bpepple | jds2001: you might want to remind folks at the beginning of the meeting who is responsible for writing the summary. | |
| jds2001 | bpepple: oh right.... | |
| bpepple | just so they don't forget. | |
| jds2001 | jwb: you're on the hook for one more week :) | |
| jwb | yep | |
| jds2001 | nirik: then it goes to you :) | |
| nirik | thanks for running things jds2001... and for writing up the summary jwb. | |
| nirik | jds2001: ok. | |
| jwb | np | |
| jds2001 | np | |
| jds2001 | -- MEETING END -- | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!