--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, kick_, jds2001, j-rod
Hi everybody; who's around?
* nirik is here.
* rwmjones here
rwmjonesdan'll be around in a minute
* notting is here
bpeppleok, let's get started...
--- bpepple has changed the topic to: FESCo-Meeting -- MinGW - all
rwmjonesready when you are
bpeppleAlright, where do we want to start on this?
packaging guidelines have gone to the packaging committee, right?
rwmjonesFPC approved the guidelines but wanted mingw to be changed to mingw32 throughout (eg. package names etc)
I have done that change to the guidelines
and I'm rebuilding the packages themselves
dwmw2_PDXew, hg.
rwmjonesalmost through rebuilding the packages with the new names, at which point I'll upload them to a repo for people to try out
jwbok, i have two questions
1) does anyone think the Board's suggestion of a separate repo is a huge deal and is a show stopper?
dwmw2_PDXwe're not expecting users in general to interact with hg, are we? That's just a detail for you folks internally?
* jds2001 here sorry
dwmw2_PDXno, the separate repo is a fine plan
rwmjonesdwmw2_PDX, no no, Hg is just our development repo until we get packages into cvs
dwmw2_PDXok, cool.
nirikI don't understand the seperate repo, but I don't think its a blocker if others are happy with it.
rwmjoneswell, hang about, the separate repo is extra burden for no real benefit
dwmw2_PDXis it really much extra burden?
* nirik nods at rwmjones
rwmjoneshave a look at the list of files (before renaming): http://www.annexia.org/tmp/mingw/00-files.txt
that's an x86-64 build, but it takes 211MB
most packages are noarch
dwmw2_PDXI like putting the compilers themselves (the .arch packages) into Fedora properly
and the Win32 binarys/dlls into the separate repo
nottingrwmjones: i asked this a few weeks ago... have we verified that the packages build correctly no matter which fedora arch the noarch build gets shuffled off to?
spoleebadwmw2_PDX, for clarification that was the board mandate in a nutshull
dwmw2_PDXthe win32 environment is completely separate from, and independent of, the Fedora environment.
rwmjonesnotting, I've only got i386 & x86-64, and I'm building for both right now, so I can tell you later
No5251, however they really ought to, otherwise there's a problem in the cross-compiler itself
jwbspoleeba, we have been told it was not a mandate from the board
spoleeba, by other board members.
spoleebajwb, the seperate repo?
rwmjonesdwmw2_PDX, it's not really separate because we need them for further package builds
* nirik is confused by the board minutes.
jwbspoleeba, correct
spoleebajwb, they havent told me that
jwbspoleeba, we were told it was a suggestion
bpepplespoleeba: correct, spot said it was only a suggestion.
nottingrwmjones: also, are you intending to support x86_64-pc-mingw64 (i.e., win64)?
spoleebabpepple, i asked for clarification....on the board list...i got crickets
bpepple, the minutes have the mandate
nirikhttp://fedoraproject.org/wiki/Board/Meetings/2008-07-15 "Leave technical details and implementation to FESCo" and "Board supports such an effort as long as it is self contained and separated from the main package respository "
jds2001it has been made clear that there is no mandate.
spotas the person who suggested it, it is simply a suggestion.
jds2001the details are up to FESCo.
rwmjonesnotting, if we could do it, but our advice has been that the upstream mingw64 project (which is separate from mingw) isn't very functional ... HOWEVER I've not tried it
dwmw2_PDXrwmjones: so you want all these identical noarch packages to be available in all current versions of Fedora, on all architectures?
(and likewise, by extension, we'd do that kind of thing for other cross-targets?)
rwmjonesdwmw2_PDX, not sure I understand the question ... they are noarch packages because they have no (build) architecture
however they do have a specific host/target architecture, which is i686-pc-mingw32
spoleebaspot, the minutes as worded..are stronger than a suggestion
rwmjonesas you might gather, rpm doesn't really understand x-compilation
spotspoleeba: yes, but as the person who made the suggestion and was present at the meeting, the minutes do not do it justice.
dwmw2_PDXif you want to put them in the "Fedora" repository, you end up putting them in about 6 repositories right now. F8/i386 F8/ppc F8/x86_64 F9/i386 F9/ppc F9/x86_64
spoleebaspot, did you ack the minutes?
spoti intended it as a suggestion, FESCo is the responsible party for working out the details
rwmjonesdwmw2_PDX, ok .. I thought that noarch packages would be shared
dwmw2_PDXall identical packages, because they have no arch dependency or even Fedora-version dependency
spoleebaspot, did you reply back to my board-list post asking for clarification?
jwbdwmw2_PDX, if they are identical, then hardlinks will suffice..
spotspoleeba: i replied to the FESCo trac ticket
dwmw2_PDXwell, they can be -- but it seems to make more sense to have their own repo.
you could even install the .repo file when you install the toolchain package.
jds2001spoleeba: none of that makes a difference right now. Take the bickering elsewhere. Spot has made himself abundantly clear.
rwmjonesdwmw2_PDX, so what's the benefit to doing that?
dwmw2_PDXand it lets you have a 'mingw32 development repo' where you update all your win32 libraries, decoupled from the Fedora version
nirikdwmw2_PDX: they would need to have repos for all the releases they support right?
spoleebaspot, i dont like being set up a spokesman for what i take to be the board's consensus opinion on the matter..then told after the fact by another board member that the minutes are wrong and my own personal efforts at getting clarification from other board members go unanswered
dwmw2_PDXnirik: no, that's the point.
they're the _same_ for all the releases.
jwbdwmw2_PDX, erm... no?
nirikdwmw2_PDX: so, this saves space? why not do something like this for all fedora noarch packages?
spotspoleeba: i dont think you were set up to be anything. if anything, you volunteered. apologies if i stopped reading your email after the 3rd page.
spoleebajds2001, are you saying that spot's opinion should be taken for the board's concensus?
rwmjonesdwmw2_PDX, ok so I misunderstood you ... the noarch packages are only the same within a Fedora release
dwmw2_PDX, we aim to follow 'native' package versions in each release
dwmw2_PDXrwmjones: so F8 builds different win32 binaries to F9?
rwmjonesdwmw2_PDX, and have indeed written a tool to do this
dwmw2_PDX, well, they'd be different versions, assuming the native F8 & F9 packages were different
dwmw2_PDXah, I see.
nottingrwmjones: given the package guideline about stripping, that implies you can't build native and mingw in the same package
rwmjonessorry for the confusion there
dwmw2_PDXmea culpa. I think I did know that before.
jds2001spoleeba: should I take yours as the Board's consensus? Not trying to be argumenative here, and I'd suggest we really just drop this until later.
rwmjonesnotting, it would seem so ... if you set __strip for one, it might not work for the other
dwmw2_PDXit also matches what we'll want to do with cross-building for Fedora.
jwbdwmw2_PDX, yes
i've said that a lot :)
dwmw2_PDXso let's not think about this as a one-off for mingw32 -- let's think about what we want to do in the general case
* jwb sighs
jwbdo you not read the lists?
nirikrwmjones: I have some questions as well... 1) does this build/work on ppc? whats the target there? ppc windows(does it even exist?), 2) what .exe's are in the fedora packages? could there be a guideline to limit those/eliminate them?
dwmw2_PDXdo we want our F9/i386 repo to include F9-version packages for _all_ architectures, including windows?
or do we want the various targets to each be in their own repo?
rwmjonesnirik, (1) I don't know, but it certainly ought to (very big bug if not)  (2) there are some .exe's ... let me find you a link to explain that
nottingrwmjones: is your plan to do day-by-day tracking of your dependent packages, week-by-week, or occasional-and-one-final-build-before-freeze?
jds2001ppc windows doesnt exist :)
spoleebajds2001, i think you should read the minutes
jwbjds2001, it did at one point
spoleebajds2001, and if there are questions you should aks for clarification in fab
dwmw2_PDXin all cases (including x86_64), it would target Win32/i386.
jds2001jwb: i thought that was Alpha
dwmw2_PDXjds2001: there was ppc too.
ppcle, iirc.
jwbthere was a ppc laptop at some point that ran windows i thought
it sucked
rwmjonesthe target in this case would always be win32 on i686, at least until upstream get somewhere with win64
nirikrwmjones: and on x86_64 also win32?
rwmjonesnirik, https://fedorahosted.org/fesco/ticket/7#comment:12
rwmjonesnirik, yes absolutely
nirik, the host compiler shouldn't make any difference, since it's a cross-compiler
dwmw2_PDXI think it makes sense for all the _output_ of cross-toolchains to be in separate repositories per _target_ architecture, rather than all bundled in with the Fedora repo.
jwbdwmw2_PDX, that does make some sense
which is why i'm not opposed to a separate repo
nirikrwmjones: right. I think we need some kind of guideline about that... but I don't know how to word it. Ban all non native exes from being in the fedora  packages? that would affect the debug case you have... how can we say 'no end user exe's' ?
dwmw2_PDXI don't think the separate repo should be problematic in any way.
rwmjonesdwmw2_PDX, I'd still be wondering what the purpose of this is .. the space requirements are not that big, like one big openoffice binary
nirik, yes that needs to be said
nirik, but wording has also escaped me
dwmw2_PDXrwmjones: a clean separation. A repository which stands alone and can be used one its own.
spoleebanirik, can you draw a line on how an exe is to be used?
nirikspoleeba: yeah, but that gets into murky intent... ;(
rwmjonesnirik, "libraries and development tools" is a key phrase in the mission
spoleebanirik, that's pretty precedent setting...we make no effort now with submission to guage intent
nirikspoleeba: right, which is why I don't like it/don't think it would ever fly.
spoleebanirik, if i thought we could defend that sort of policy and say this exe is good and that one is not...id have suggested it
* dgilmore shows up
dwmw2_PDXif it's in a separate repository, do we still really need to ban executables?
rwmjonesnirik, actually https://fedorahosted.org/fesco/ticket/7#comment:13 is the comment i meant
nirikso perhaps we could say no exes ? sorry for debugging, but someone could compile their own?
rwmjonesnirik, no that's a really bad idea - see the comment above
nirikrwmjones: yeah, read down. ;)
rwmjonesit'll cause developers to have to rebuild the RPMs
nirikdwmw2_PDX: ok, so then you could have anything in that seperate repo? firefox.exe ?
dwmw2_PDXdo we have any specific reason to forbid that?
jwbhell yes
rwmjonesthere's just no point building it
spoleebadwmw2_PDX, 'need'? we'd feel less pressure to restrict the payloads in any way
rwmjonesit's not of any use to Fedora developers
and Windows users can get it from mozilla.org
not that they would know what to do with an rpm anyway
nirikdwmw2_PDX: I would guess the support burden? re-building all these apps and supporting them running on windows?
dwmw2_PDXof course there's plenty of stuff that doesn't make sense to include
the question is whether we actually need to _ban_ them
spoleebanirik, support burden would work itself out..without policy restrictions
jwbyou could phrase it as "FESCo approved binaries"
rwmjonesbut virsh.exe is necessary for fedora developers ... they need to give it to the windows users as a debug tool
nirikdwmw2_PDX: so what is your argument for seperate repo again? space savings? seperation of a functional area of packages?
spoleebanirik, but to construct a ban of any sort...presupposes the value of the executable
dwmw2_PDXnirik: a clean separation of a functional area of packages. This repository stands alone -- it doesn't depend on anything else in Fedora (except maybe a toolchain), and nothing in Fedora really depends on it.
dgilmorerwmjones: but virsh.exe will be you building and distributing via libvirt.org
dwmw2_PDXif I want to be running F9, but working on the rawhide mingw stuff, I can just point my _mingw_ yum repo at rawhide and all is well
nirikdwmw2_PDX: so what makes this different than any other package grouping? less dependencies on the rest of the collection?
dgilmorerwmjones: everything needed to build that on fedora though should be ok for fedora inclusion
rwmjonesdgilmore, but it's stupid for us (loyal Fedora developers) to have to rebuild these packages.  That defeats the point and need for them being in Fedora in the first place for us (as libvirt devs)
dwmw2_PDXnirik: Think about where we're going with this, ideally, in the long run.  We will be building _every_ package in Fedora, for _every_ architecture supported by Fedora. And then some more.
this is jsut the start
dgilmorerwmjones: your not getting me
rwmjonesdwmw2_PDX, we will not be building every package in Fedora for mingw ... for a start it's completely impossible to do that
dwmw2_PDXI don't think we want _all_ that explosion of packages in the core repo. I think we want a separate repo for each target
rwmjonesthe amount of work is astronomical
it's taken us weeks to build just 20 packages, because they have to be individually ported by hand
nirikdwmw2_PDX: so would this replace secondary arches is what you are saying?
dwmw2_PDXrwmjones: when we do cross-builds for other linux architectures, we're likely to build at lot more than you do for mingw32
dgilmorerwmjones: the tools and DLL's to build what your going to ship is ok for inclusion in fedora
dwmw2_PDXnirik: no, that's a separate thing
nottingnirik: i don't know that it will, but i don't necessarily think this is the right way for someone to do, say, an arm port
dgilmorerwmjones: but final products that windows end users will use have no place in fedora
rwmjonesdgilmore, but we'll still end up rebuilding libvirt RPM
dgilmorerwmjones: when i asked you the other week you clearly said that the product you give to windows users will not be built in fedora
nirikright, it's same arch, different os tools in fedora. The question is can it be just the fedora packages needed to do the development (as the mingw people clearly want) or is it all packages for that os eventually?
rwmjonesdgilmore, that argument can apply to the whole of mingw though
jds2001dgilmore: I think that we're on the same page, sorry to have been silent in this discussion - I am in a $DAYJOB meeting at the same time :)
dgilmorerwmjones: any .exe really has no place in fedora.
rwmjonesdgilmore, I meant that we won't be giving them RPMs, because obviously they'll be no use ... also we will build some end-user applications (specifically virt-manager)
nirikif it's just the development tools, I think a seperate repo isn't needed. If it's going to be everything in the world, it probibly should be.
dwmw2_PDXdgilmore: you could make the same argument about .DLL. And I'd still disagree.
spoleebanirik, i really have to apologize for making such heavy use of the 2ndary arch comparison meme
dgilmorerwmjones: yes.  im happy to have the tools to do taht in fedora
jds2001rwmjones: this is different than what I understood then.
spoleebanirik, its colored everyone's thinking too much
jds2001I'm happy to have tools to rebuild virt-manager, but not the virt-manager binary itself.
nirikspoleeba: perhaps. It does add confusion... oh well, such is life. ;)
dgilmorerwmjones: but building of .exe files for windows users consumption is up to you to build and distribute on your
rwmjoneslet's step back here ... we want to help fedora developers build without needing Windows ... if they have to rebuild the whole toolchain to get virsh.exe, then we haven't done that
we've put some stupid barrier in the way because of some tiny executable
jds2001is virsh.exe not part of virt-manager proper?
* jds2001 may be misinformed here.
rwmjonesjds2001, no it's part of libvirt
nirikwhy would they need to rebuild the toolchain? don't we provide the toolchain for them to do this?
dwmw2_PDXcan't you just rename it to virsh.dll and it'll run anyway? :)
dgilmorerwmjones: when i asked you previously if you intended to build end user windows apps in fedora  you said that no you did not.  just the supporting infrastucture
rwmjonesdgilmore, virsh.exe is a debug tool, it's not an application
virsh = libvirt shell
rwmjonesit's 255K
dgilmorerwmjones: yes and thats for you to build on your own
rwmjones: i dont care how big or small it is
nirikrwmjones: so why does that need to be in a fedora package? how would a windows user install it from rpm?
spoleebahow do we distinguish an application exe from a tool exe?
rwmjonesbut we're failing because let's take gnutls ... CERTTOOL.EXE is a debug tool, small, etc.  Now the Fedora developer wants to ship this, he's got to rebuild the gnutls RPM which was already built in Fedora.
* jds2001 thinks that if I as a Fedora user can make usefulness of it, then it belongs in Fedora.
rwmjonesso we've failed him
jds2001if I can't execute it, it doesn't.
dwmw2_PDXspoleeba: better question: why would we, FESCo, _want_ to distinguish between them rather than leaving it to the folks working on mingw32 to do what they feel is appropriate?
rwmjonesyou can execute it fine under wine
nirikeither: a) we ban all .exe files b) seperate repo, and we don't care about exe files...
rwmjonesall of these programs run from the command line if you have wine installed
dwmw2_PDXseparate repo, and don't care about exe files, really.
rwmjonesyou don't even need to type 'wine ...', the kernel finds the right interpreter for them
dgilmorerwmjones: building libjpeg dlls  thats an ok use. cross compilers,  thats ok.  building something intended for end user consumtion thats not fedora.  thats where you are on your own to build and distribute.
dwmw2_PDXfor mostly separate reasons, but still.
spoleebadwmw2_PDX, i can think of many reasons as to why fesco would want to try...but ive gone way past my comfort level in making suggestions :->
rwmjonesare we helping fedora developers here or not?
jwbdgilmore, you mean like the livecd creator tool that lmacken worked on?
* nirik is still wondering how someone on win32 would deal with a rpm download?
nirikjwb: is that available as an rpm in fedora?
rwmjonesnirik, there is no issue there ... no one is talking about building Fedora RPMs for the sole purpose of giving them to Windows users
dgilmorejwb: i say thats something that should not be built in koji as a rpm.  but can be built on the developers workstation.
dwmw2_PDXWhat's the actual question being put to FESCo? Whether, and how, we allow this project to move forward?
dgilmorejwb: but the tools and dll's needed to build it are ok
spoleebanirik, well... if you had a fedora run data server...exporting a filesystem via samba....
jwbnirik, it was an illustration on how windows only binaries _could_ be beneficial for Fedora.  not everything is black and white
dwmw2_PDXI propose that we don't make any hard restrictions about what files are shipped, but recommend that they don't ship end-user binaries. And put the _target_ (noarch) stuff in a separate repository, and the actual toolchain into Fedora.
rwmjonesjwb, the full NSIS binary is only available as a windows binary running under wine ... although with a lot of effort on monday I ported most of Debian's work on building a native NSIS
jwbi'm +1 to dwmw2_PDX's proposal
sort of
rwmjonesI'm ok with dwmw2_PDX's proposal, but have no vote so ...
spoleebajwb, im pretty confident there are more tools out there like the livecd creator that we could brand as Fedora but would run on windows, we just havent thought of them yet
jds2001+1 to dwmw2_PDX
bpepple+1 to dwmw2_PDX proposal.
j-rod+1 here too
jwbdwmw2_PDX, can we assume you're a +1 to your own proposal?
spoleebadwmw2_PDX, how tight of a definition are you applying to toolchain?
dgilmoredwmw2_PDX: to implement that cleanly we would need to add new tags/targets to koji, a new series of cvs branches. new bodhi update streams. new branches on the mirrors.  an update to fedora-release to have the new repo(is it enabled or disabled by default)
* notting is wary of the effect that 'take this subset of koji built packages and put them somewhere else' is going to have on the releng tools
dgilmoredwmw2_PDX: i.e. alot of work by people not involved in this discussion
dwmw2_PDXspoleeba: yeah. I haven't been drinking yet
jwbdgilmore, why a new series of cvs branches?
dwmw2_PDXspoleeba: I was thinking "the packages which aren't noarch" when I said toolchain
spoleebadwmw2_PDX, you might need to be okay with the toolchain including a few dlls and exes
dgilmore-1 to dwmw2_PDX's propposal.  it has alot of variables that need looking at before we can say yeah or nope to it
dwmw2_PDXspoleeba: like my i686-linux-gnu-gcc package already does, you mean ?
dgilmorejwb: because maintaining lists of this goes here and that goes there leads to fail
jwbum, no
spoleebadwmw2_PDX, maybe..ive given up trying to understand what I mean
spoleebadwmw2_PDX, your proposal is an implied limit of some kind as to what goes into the main repository
dwmw2_PDX, just be sure YOU know what you mean to limit :->
dwmw2_PDXdgilmore: we don't need a fedora-release update. The toolchain package itself could contain the repo file.
spoleebadwmw2_PDX, so you dont have to come back and argue over it..after the fact
* rwmjones still wonders, why a separate repo for a few hundred MB?
jwbdwmw2_PDX, except we have guidelines against that
dgilmoredwmw2_PDX: we dont allow other packages to ship repo definitions
rwmjoneswhy not a separate repo for perl packages?
dwmw2_PDXdo we?
jwbrwmjones, it's not a minGW specific thing
rwmjones, think of it this way: today MinGW. tomorrow: cross-toolchains for ppc, sparc, arm, mips, etc
rwmjonesjwb, those are secondary architectures, nothing like mingw at all
jwbrwmjones, few hundred MiB today, few GiB tomorrow
dgilmoredwmw2_PDX: we banned it because someone got there package in shipped a .repo file and then updated the package elsewhere
jwbrwmjones, horsepoo.  they are not
dwmw2_PDXspoleeba: I don't mean it as a limit -- I mean it as a clean separation. And it's "stuff which doesn't run on the host, but is packaged as noarch because it's just fodder for a cross-compiler"
spoleebajwb, my understanding..talking to others..is that the arm stuff is even more complicated..since its a family of targets
dwmw2_PDX, just trying to make sure you are clear
rwmjonesjwb, you're talking about embedded sparc systems or something?
dwmw2_PDXdgilmore: that kind of behaviour is bad. Fixing the wording of the guidelines to say "no repo files pointing at things other than official fedora repos" would be reasonable though, right?
jwbrwmjones, you can build cross toolchains _just like_ MinGW is that target different architectures
rwmjones, sure "embedded" if you want to call it that
nottingrwmjones: i don't really buy that argument. they're all cross-compilers. mingw is cross-arch+host, the others are just cross-arch
rwmjonesjwb, you mean Windows on sparc?
dgilmorerwmjones: there are non-fedora embededed use cases for mips, arm, ppc
dwmw2_PDXrwmjones: no, Linux on sparc,i386,arm,ppc,etc.
jwbrwmjones, no i mean cross compiling.  has nothing to do with windows or target arch
rwmjonesjwb, this is not just a matter of recompiling .. each package is patched and ported individually ... seriously hard work
dwmw2_PDXall with their _own_ set of hundreds of .noarch. packages, for each of the packages in Fedora.
rwmjonesjwb, for example I spent 3 days porting gcalctool (and still haven't finished)
jwbrwmjones, i do it all day long.  it's what i'm paid to do.  i know that
spoleebagcalctool..isnt that an end user app?
rwmjonesdwmw2_PDX, this is a misconception (as far as mingw is concerned anyway) ... there's just no way you could do that
gcalctool was ported because I wanted to blog about how to do ti
jwbrwmjones, you are NOT getting it
dwmw2_PDXrwmjones: it's just harder for Windows.
rwmjonesnothing to do with fedora
dwmw2_PDXrwmjones: but the principle is the same
jwbrwmjones, everything you are proposing for MinGW is applicable to _any_ cross compiling toolchain
dwmw2_PDXrwmjones: we do not want to set a precedent for how we handle cross-compiler output/libraries based on the limitations of Windows
jwbas dwmw2_PDX says, the principle is the same
rwmjonesdwmw2_PDX, no, it really is totally different .. you have to port POSIX code to work against the Win32 native API for a start
dwmw2_PDXwe want to get it right for _all_ cross-toolchain stuff.
jwbrwmjones, no, it's not different
dwmw2_PDXrwmjones: that's an implementation detail which isn't particularly relevant here
rwmjonesit's not a recompile
dgilmorerwmjones: your not getting the point we are trying to make
dwmw2_PDXit's "How do we package and ship" this stuff
not "how much does the developers brain hurt when they work on it"
dgilmorerwmjones: we want to setup a framework for any combination of cross compiling
rwmjonesbut what are these other platforms ... ok, there's some embedded platforms (the arm guys).  What else?
dwmw2_PDXdgilmore: will you change your -1 if we modify the proposal to be dependent on rel-eng feedback? If rel-eng run away screaming we'll revisit it?
dgilmorerwmjones: the possibilities are endless
dwmw2_PDXI don't _think_ it should actually be that hard to do, but let's ask for a coherent response from someone who actually knows?
dgilmoredwmw2_PDX: it needs infrastructure input as well as releng
dwmw2_PDXI think that's what I meant
rwmjoneswhat does that even mean?  mingw targets a specific platform with its own completely different API
jwbrwmjones, damnit man.  listen.  this has nothing to do with mingw
dwmw2_PDXrwmjones: these other platforms are Fedora on _all_ CPU architecutres
for example, on my shinybook I want to build for i386 Fedora
jwbmingw is a subset, an example, of cross compling
jwbFESCo needs to get it right for cross compiling as a whole
jds2001jwb: +1
bpeppleok, I think the vote for dwmw2_PDX proposal was five '+1', and two '-1'.  I think dwmw2_PDX suggestion to get rel-eng & infrastructure teams feedback on the feasibility of it makes sense.
* nirik999 lost network there for a bit. ;(
spoleebadwmw2_PDX, i poked infrastructure a bit... i was told koji isnt a problem
* nirik999 wishes he knew what the proposal was. oh well.
dwmw2_PDXin practice that was going to be the case anyway -- if we decide something and the folks who have to implement it say "fuck off", then that's a fairly effective veto :)
jds2001if they run the other way, we can revisit.
spoleebadwmw2_PDX, im not sure if rel_eng would have a problem
dgilmorespoleeba: i want you to stay out of this from now on please.
dwmw2_PDXbut I'm happy with adding that wording to the proposal :)
jds200118:37 < dwmw2_PDX> I propose that we don't make any hard restrictions about what files are shipped, but recommend that they don't ship end-user binaries. And put the _target_ (noarch) stuff in a separate repository, and the actual toolchain into Fedora.
18:37 < dwmw2_PDX> I propose that we don't make any hard restrictions about what files are shipped, but recommend that they don't ship end-user binaries. And put the _target_ (noarch) stuff in a separate repository, and the actual toolchain into Fedora.
18:37 < dwmw2_PDX> I propose that we don't make any hard restrictions about what files are shipped, but recommend that they don't ship end-user binaries. And put the _target_ (noarch) stuff in a separate repository, and the actual toolchain into Fedora.
dgilmorejds2001: we get it
spoleebadgilmore, i was just informing dwmw2_PDX as to what ive been told
jds2001sorry, there's the proposal three times nirik999 :)
dgilmore: sorry, stupid terminal.
nirik999ok, sounds sane... except how can you tell the target stuff from the toolchain?
dgilmoreadd to that that we need to check with releng and infrastructure.  and ill give it a +1
nirik999: different tags/targets in koji different cvs branches
dwmw2_PDXProposal #2: Let them apply common sense on .exe files, and please don't ship end-user binaries. Ask infrastructure team to report on our plan to put the target (noarch) stuff into a separate repository. Unless that's prohibitively hard, that's what we want.
dwmw2_PDXnirik: toolchain is the .arch.rpm packages, of which there are probably only one or two (binutils and gcc).
dgilmoredwmw2_PDX: thet target noarch stuff really needs to be kept in its own playhouse
rwmjonesso can we get infrastructure to do something to https://fedorahosted.org/fedora-infrastructure/ticket/807 and https://fedorahosted.org/fedora-infrastructure/ticket/689
dwmw2_PDXnirik: the rest is the rest. The .noarch packages.
dgilmore: 'own playhouse' != 'separate repository' ?
nirik999ok, I will +1 that...
* jds2001 read 'own playhouse
jds2001== separate repo
dgilmoredwmw2_PDX: own playhouse == seperate repo, cvs branches, build targets, bodhi stream,
nottingwell, if they're its own koji build target, that makes some of the releng side easier (i.e., don't need to deal with mash/pungi bits to pull it out of the release trees)
dwmw2_PDXwell, I only really care about the separate repo part; for the rest you're probably right but I'm happy with whatever's easiest with our infrastructure
dgilmorenotting: that would lead to madness if its not kept completely seperate
nirik999so would the mingw32-release package be in fedora? or only in the sperate repo
dwmw2_PDXseparate like secondary arches? How much can we re-use the stuff that builds for secondary arches? Or don't we want to go there?
rwmjonesis that end of mingw topic?  I kind of need to go soon ...
rwmjonesnirik, we'd very much like it to be available immediately for developers
dwmw2_PDXnirik: I think we should relax the no-new-repo-files guideline to say 'no new repo files except for official Fedora repos'
nirikdwmw2_PDX: yeah, or fesco approved or something, thats fine.
that was kind of the point in it in the first place anyway, right?
dgilmorenirik: its contents would need to be in fedora-release to comply with our guidelines
jwbrwmjones, we realize it's a bit unfair to MinGW to try and make generic cross compiling decisions.  but you're blazing a path here, and you've done a damn good job so far :)
rwmjonesif the repo goes in fedora-release then there's no way we could "sabotage" it, or any concerns like that
dwmw2_PDXdgilmore: I am proposing that we fix the guidelines.
nirikdgilmore: ok, that should be fine too to me... whatever we can work out.
dwmw2_PDXrwmjones: I don't think we need to worry about sabotage. We know where you live.
rwmjonesdwmw2_PDX, indeed you do
dgilmoredwmw2_PDX: id rather see it in fedora-release and disabled
dwmw2_PDXdgilmore: ok, I suppose.
is there any way for a separate package to _enable_ it?
rwmjonesbut why disabled?
nottingdwmw2_PDX: not sanely, no
nirikin any case shall we move on for the last 2 minutes of our meeting slot? ;)
rwmjonesthat just hinders us for no reason
dgilmorerwmjones: because most fedora users wont care for it
dwmw2_PDXrwmjones: because we don't want 'yum update' to go fetch all the headers for _all_ cross-architectures every time.
again, thinking of the precedent we're setting for the general case.
jds2001dgilmore: most fedora users dont care for my icelandic-fonts, either :)
rwmjonesany windows developers wanting to give up windows, or any fedora devs asked to build windows programs (a frequent request) will be
bpepplenirik: actually our time slot has been changed to 2 hours, since we were constantly going over our time. ;)
dgilmorerwmjones: its easy to enable a repo
dwmw2_PDXdgilmore: it's a good point though; I would prefer to find some way that installing the mingw32-compiler package would automatically enable the ming32-target repo.
rwmjonesdgilmore, it's an extra step ... another thing to explain ... it means that 'yum search' won't show this wonderful new capability etc
dwmw2_PDXeither shipping the repo file with that package and relaxing our guidelines, or some way to make it _enabled_
nirikdwmw2_PDX: propose some guidelines change to the packaging folks?
dgilmoredwmw2_PDX: you could do some sed magic in %post i guess
rwmjonesthis is a valuable way to enable fedora developers to stay on fedora
dwmw2_PDXdgilmore: that might work, but how does it work with fedora-release upgrades?
as long as it works sanely, that could be done.
dgilmoredwmw2_PDX: they are marked as config files
though there has been instances where we have forced new configs in
dwmw2_PDXI think the sed thing in %post is a good start.
dwmw2_PDXwe can argue about the 'no repos' guideline later.
nirikI think it might be easier to get the guideline changed and have a mingw32-release, then it can be pulled in/installed however you like.
rwmjonesnirik, there is already a mingw32-filesystem package
which does the base stuff
dwmw2_PDXsince that way we don't have to modify fedora-release.
what are the disadvantages of just fixing the guideline?
rwmjonesmight be timely to look at: http://fedoraproject.org/wiki/PackagingDrafts/MinGW
dgilmoredwmw2_PDX: more people asking for exceptions
dwmw2_PDXdgilmore: depends how we phrase it.
dwmw2_PDXno exceptions, just a guideline of "no repository files except pointing to official Fedora repositories"
jwbmove on?
dwmw2_PDXdo we want to make that guideline change a proposal and vote on it?
or wait for the infra team to respond before we settle that detail?
bpeppledwmw2_PDX: how about we wait for the infra team to respond.
jwbshouldn't we wait to see if we have to destroy the proposal that is causing the new proposal to surface?
bpeppleok, if there's nothing else lets move on to a couple of feature items.
--- bpepple has changed the topic to: FESCO-Meeting - FEATURES - all
rwmjonesok I have to leave now, but if anyone has any questions please don't hesitate to mail rjones/redhat_dot_com
bpepplerwmjones: thanks for all your work on this.
alright, poelcat wanted us to look at a couple of features that haven't had any response.
poelcatbpepple: i'm told an update is "coming"
bpeppleah, so let's hold off then.
poelcatthat is all I know
bpepplepoelcat: is the haskell feature also being updated?
well no response
bpeppleok, so this is our policy for dropping features: https://fedoraproject.org/wiki/Features/Policy/Dropping
jwbsounds like a candidate for the latter
wwoodsloupgaroublond: ping - isn't haskell yours?
jwb.fas Yaakov
zodbotjwb: ynemoy 'Yaakov Meir Nemoy' <loupgaroublond@gmail.com>
jwbseems so
bpepplejwb: yeah, based on the feature page, this looks like a feature we should drop based on the information available.
* nirik nods.
bpeppledoes anyone disagree with that?
* bpepple listens to the crickets.
jwbit's bumped
bpeppleok, the next features we need to determine if they are in a testable state.
nirikajax: ?
ajaxgetting there.
ajaxi have the mailing list set up now, which is fortunate
and i have a working parser, it's just not in the server quite yet.
it'll probably miss the beta compose though
jwbsounds like not testable
ajaxthat's a fair assessment, yeah
* jwb sheds a tear
dgilmoreajax: so F11 now
ajaxwell, or just unannounced in f10
i mean, i'm still going to do it, it just might not be something to advertise
dgilmoreajax: ok, so we punt and yell about it for F11
dgilmoreit just might happen to be there and working before hand
bpeppleok, the next feature is: https://fedoraproject.org/wiki/Features/KernelModesetting
jwbthis one seems testable
nirikjust the intel part is fail, right?
dgilmoreajax: is this you also?
ajaxwell, my team, but sure.
nottingcertainly appears testable
jwbis intel still fail?
ajaxintel kms is known to be quite broken, and is shipping disabled for the beta
and will probably continue to be in final, but might be stable enough for users to turn on by hand by then
dgilmorehow would i go about testing ati?
jwbso, really, it's only on for ATI.  and only for x86 at that
ajaxif you see a shiny splash, yay, it works.
if you see something else, it's broken.
i get the bar going across the screen
ajaxr300 through r600 only
j-rodworks on one of my boxes, ship it!
ajaxexcuse me: through r500
jwbdgilmore, the bar?
ajaxjwb: he means the text progress bar
jwbif you mean the cylon looking thing, i think you need to update plymouth
bpepplealright, so this feature is testable, though with a caveat in regard to intel.  anything else in regard to this feature? or should we move on?
dgilmore ATI Technologies Inc Mobilitiy Radeon HD 3600 Series
ajaxdgilmore: is an r600.  too new, sorry.
dgilmorethats in my desktop
ajaxworking on it though.
dgilmorenot sure its actuallya  mobility card
ajax: :)
ajaxbpepple: if "testable" is the metric, i think we're done here.
bpeppleajax: agreed.
jwbi will note that krh fixed r400 yesterday
bpeppleOk, the next feature is: https://fedoraproject.org/wiki/Features/Sugar
jwbso there is progress even
bpeppleI know there has been some progress on this, but I'm not sure it's testable yet.
dgilmorejeremy: ping
jeremydgilmore: pong
dgilmorejeremy: suagr feature
it should be testable right
bpeppleis it in a testable state for the beta?
wwoodsIt's testable. You can install sugar-desktop at installtime, it starts like a normal desktop session
dgilmoreyou can yum install and log into sugar
wwoodsthere are no packaged activities, AFAIK
so you can't actually *do* anything
but the framework is there
dwmw2_PDXthe page says an initial set of activities is packaged
dgilmorewwoods: there is journal and a bunch in review i think
dwmw2_PDXbut waiting for pyxpcom -- is there progress on that?
dgilmoredwmw2_PDX: last i poked at that it was blocking on caillon working out if we could even ship it
jeremythere are packaged activities now
they'll be in rawhide as soon as we unfreeze
jeremywhich, since they're not on any of the media other than everything, means they're essentially "in the beta" :-)
bpepplejeremy: works for me.
jeremypyxpcom will be in the post-security-update xulrunner build according to what caillon told me this afternoon
(and then all the bits for browse will get packaged up pretty quickly)
bpeppleok, anything else in regard to Sugar? Otherwise let's move on.
dgilmorejeremy: :)
bpeppleFeature: https://fedoraproject.org/wiki/Features/LXDE
dgilmorejeremy: so its likely to land in time for F-10?
wwoodsout of curiosity, does sugar have its own way of installing new activities? or should testers fire up a terminal (or other session) to do so?
dgilmorewwoods: you can install via journal and browse
jeremydgilmore: yep, it will
nirikfor lxde, sadly 2 packages are still in review... so I think it needs to go to 11 (ha ha).
dgilmorethough it puts them ins ~/Activities
jeremywwoods: you can install them through the journal.  but the Fedora Way (tm) will be via 'yum install'.  just as the Fedora Way (tm) of installing perl modules isn't perl -MCPAN
dgilmoreso not testable
bpepplenirik: do we know what's holding up those 2 reviews?
nirikunless those packages aren't critical for testing, but I think they are.
wwoods(for the record, I've been slowly attempting to test features: https://fedoraproject.org/wiki/QA/TestResults/Fedora10Features/Beta)
nirikbpepple: I glanced at them and there was a lot of discussion about what should be a subpackage, etc.
wwoodsnone of the LXDE packages are even built, AFAICT
nirikwwoods: some are, but thats because they were already in... like openbox is the windowmanager.
nottingwell, if they try and add the comps group now, they'll be breaking the string freeze
nirikyeah, so I think this should move back to next release... if they get it sooner great, we can trumpet it in 11
bpepplenirik: +1
bpeppleanyone disagree with pushing LXDE, otherwise we can move on.
ok, I had a question whether this was testable or not: https://fedoraproject.org/wiki/Features/GStreamer_dependencies_in_RPM
Did the packagekit piece get written yet?
nirikwell, it could be tested via yum too, right?
wwoodsthe PK bits are built but not in Beta
so they are technically testable right now
nottingany reason not?
bpepplewwoods: cool.  that's what I was wondering.  thanks.
notting(in beta)
wwoodsnotting: already late, don't want to risk futher destabilization, will be available at day-0
bpeppleok, is there anything else in features folks want to discuss, otherwise we can start to wrap up for today.
sticksterbpepple: I have one issue -- meeting time.
bpepplestickster: floors yours.
jwbstickster, what about it?
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
sticksterThe point of using #fedora-meeting is that it's centrally located and well-attended.
dgilmorebpepple: election
sticksterPeople know to go there, and can log other meetings.
* jwb waits...
sticksterSpeaking as a Fedora mgr type -- Originally Docs moved out to another room during a week when things were running late here (as they do)
dgilmorestickster: you would like fesco to change its meeting time?
sticksterWould it be troublesome for FESCo to shift an hour earlier, and do a two-hour meeting?
* dwmw2_PDX has only just got used to this one. Almost. At least I get the day right now
dwmw2_PDXan hour earlier I could handle. Two hours less so.
jwbhour earlier is probably fine
with me anyway
dwmw2_PDXwhen I'm at home, an hour earlier would actually be good
sticksterJust consider it. That's all
dgilmorean hour earlier should work for me
bpepplestickster: I think Kick & j-rod weren't about to attend earlier.
* stickster &
dwmw2_PDXwe went through this before, didn't we?
is there any reason things should have changed?
dgilmoreperhaps we should move to #fedora-meeting2
j-rodI'm fine with Wednesdays an hour earlier, my big issue is Tues/Thurs being no good
nottingwell, i can't really speak for Kick and j-rod in their absence. take it to e-mail?
bpeppledgilmore: I'm fine with moving to #fedora-meeting2, though I though quaid told me the doc team was moving there.
* j-rod just wandered back, sorry...
dgilmorebpepple: it sounds like they would prefer to be here
dwmw2_PDXnotting: yeah, let's ask
dgilmorebpepple: im willing to accomodate them on that
bpepplehow about we discuss this on the mailing list, and see if we can work on a solution?
stickster+1, no need to spin wheels here, just wanted to put it in for consideration.
quaidhere's the problem, there is no critical mass in meeting-1
(not using -2 etc. yet)
there are ~100 ppl here, and ~9 there
until we can get everyone here to also lurk there, it makes the secondary mtg room nonviable
I'm happy for Docs to move
but we need that room to be useful, at least as many lurkers as there are in #fedora-docs :D
bpeppleMaybe if we move to meeting-2, that will get more folks to hang out there.
quaidsure, gravity draw rule
it worked for this channel
dwmw2_PDXam I missing the point? Why do we need lurkers?
the channels are logged, right?
dgilmorequaid: i think im in meeting 2 never knew 1 existed
quaiddwmw2_PDX: that is the point of a common meeting channel
jwbdwmw2_PDX, no?
quaiddwmw2_PDX: one can watch as many meetings without lurking in multiple sub-channels
dgilmore: hmm
dgilmore: we set something on the meeting channel wiki page
bpeppleanyway, let's discuss this on the mailing list and work out a solution.
* quaid back to his meeting on #fedora-docs
dgilmorebpepple: election
dgilmorewe should get cracking on it
One question is whether we should have our election at the same time as the board, since with the release delay we've got a small window to run it before the holidays.
dgilmorebpepple: im +1 for that
bpeppleI'm +1 for that also.
dgilmorebpepple: i think it could help turn out if both are at once
abadger1999That was always my hope.  Now that G has written election software that can handle that I'm all for it :-)
jwbhow do you handle people that are running for both, but will drop from one if they are elected to the other?
bpeppleThe only downside if for the folks that one to be on the board or FESCo but not both.
* bpepple see jwb beat him to it.
nottinghave them state their preference?
bpepplenotting: that's what G and I discussed last night.
jwbcan you be a bit more verbose on that?
dgilmorebpepple: i would say they pick what they really want and run for it
jwbsorry, no
dgilmoreFESCo or the board should not been seen as consolation prizes
dgilmoreif you run for both you shuld be prepared to do both
bpeppledgilmore: I tend to think the same thing.
jwbthat's a fairly silly statement, considering we've never held the elections at the same time before
so there was always a choice
jwbyou could run for the Board, and if that didn't work, you could still run for FESCo to try and make an impact
jwbit's not a consolation prize
dgilmorethat was a side effect of the old elections app
jwbthat doesn't make it any less valid
dgilmorewhere we could only run one election at a time
dgilmorejwb: you can still have an effect without being on FESCo or the board
dgilmoreI know at leats oncein the past we wanted to run them at the same time but couldnt
jwbthis is sort of a waste of time to discuss.  people that want to do one or the other will just run for both and drop whichever they like least if they are elected to both
dgilmoreI propose that we say yes we want to have the FESCo election at teh same time as the fedora board election
jds2001sorry i stepped away for quite some time for a meeting :/
dgilmorejwb: there is nothing we can do to stop people declining a position if they are elected.  and we can accept that
dwmw2_PDX: whats your objection?
dwmw2_PDXthe same as jwb's
jwbdgilmore, you need at least 9 people in FESCo to make it a valid body.  if you only have 9 candidates to start with, and one drops, you have to figure something out
dwmw2_PDXit's not about being a consolation prize
nottingdgilmore: +1
dgilmorejwb: well this election of for 4 people
* bpepple notes we've got a hard stop in 3 minutes, so we might need to take this to the mailing list, since we don't need to decide this today.
dgilmorejwb: the next is for 5
jds2001jwb: we have procedures for that, though.
nirik+1 on proposal
dwmw2_PDXit's about wanting to help out and/or be involved -- and I don't think people will want to do _both_ (even if we want them to)
dgilmoreif 4 people nominate then we dont have elections they are all accepted
bpepplealright, I see five '+1' and one '-1', and one '0'.
dwmw2_PDXI suppose if people drop out within days of the election we can just pick the next person on the list, who just missed out.
so it doens't have to be _so_ much of an issue for it.
j-rod0 here too
dwmw2_PDXI can revise to 0 too.
jds2001our procedure actually calls for that, dwmw2_PDX
dgilmoredwmw2_PDX: its happened like that in the past
dwmw2_PDXok then
I'm ambivalent then
jwbjds2001, our procedure does not account for having exactly the number needed, and then having one drop
but whatever
bpeppleok, so that give use five '+1', and three '0'.  we've decided to hold the election at the same time as the board.
dwmw2_PDXjwb: if we have more candidates than positions, it's OK
jwbdwmw2_PDX, right
bpeppleok, we're out of time, so we have to call an end to the meeting.
dgilmorejwb: if we have the exact number there is no election.
bpepple-- MARK -- Meeting End

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!