15:05:44 <spot> #startmeeting Fedora Packaging Committee
15:05:44 <zodbot> Meeting started Wed May 11 15:05:44 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:05:48 <spot> #meetingname fpc
15:05:48 <zodbot> The meeting name has been set to 'fpc'
15:05:53 <spot> #topic Roll Call
15:06:04 * abadger1999 here
15:06:07 * SmootherFrOgZ here
15:06:32 <tibbs> Howdy.
15:06:52 * racor here
15:06:56 <abadger1999> limburgher will be back in 5 minutes
15:07:20 <spot> okay, so thats 6...
15:07:29 <spot> rdieter?
15:07:39 <abadger1999> geppetto: you here for the meeting?
15:09:35 <spot> okay, well, we have quorum
15:09:39 <spot> so lets get started
15:09:50 <spot> #topic Systemd amendment
15:10:27 <spot> In the ticket that will not die (#31), it was proposed that we add an alert note to state that "Packages must be strictly forbidden from migrating to systemd within updates to a Fedora release. The migration is only allowed between Fedora releases."
15:11:16 <spot> This is because otherwise, you might have situations where services enabled at installation might be disabled upon update (or vice versa).
15:11:22 <geppetto> abadger1999: yeh, sorry … doing something for rel-eng
15:11:23 <abadger1999> <nod>
15:11:31 <spot> So, this makes sense to me to add.
15:11:34 <tibbs> I agree.
15:11:45 <tibbs> I'd even go so far as to say that it should be done before branching.
15:11:48 <geppetto> yeh, +1
15:12:01 <spot> So, +1 to this amendment
15:12:23 <abadger1999> spot: I'm fine with that -- I think we should also ping fesco to see about making porting a feature so that we can apply FES/etc resources to getting it done in one release.
15:12:25 <abadger1999> +1
15:12:29 <tibbs> +1
15:12:39 * abadger1999 opens a fesco ticket
15:13:16 * spot notes that we are at +4 on this item, racor, SmootherFrOgZ, limburgher (if back) ?
15:13:40 <limburgher> +1
15:13:42 <racor> +1
15:13:42 <limburgher> And I'm back.
15:13:46 <SmootherFrOgZ> +1 from me
15:14:05 <spot> #action Alert note amendment approved (+1:7, 0:0, -1:0)
15:14:36 <spot> #topic Improve wording of /srv section - https://fedorahosted.org/fpc/ticket/82
15:15:14 <spot> The wording of the /srv guideline may be a bit inflammatory and could stand to be improved.
15:15:26 <spot> Toshio proposed new wording in ticket 82
15:15:31 <spot> and it sounds good to me.
15:15:48 <tibbs> +1
15:15:51 <spot> +1
15:15:58 <SmootherFrOgZ> +1
15:16:00 <abadger1999> +1
15:16:02 <limburgher> +1
15:16:21 <racor> +1
15:17:06 <geppetto> +1
15:17:29 <spot> #action Improved /srv wording approved (+1:7, 0:0, -1:0)
15:18:07 <spot> As a tangent, since the FHS process has groaned back to life again, i plan on trying to have /libexec added
15:18:33 <spot> since this is a very very very old outstanding FPC item
15:18:49 <spot> (to give you an idea of the date, it was originally opened by Axel Thimm)
15:18:59 <SmootherFrOgZ> wow
15:19:11 <spot> moving on. :)
15:19:21 <spot> #topic MinGW Tweak - https://fedorahosted.org/fpc/ticket/83
15:19:28 <geppetto> spot: ever the optimist
15:19:48 <spot> Tibbs has generated a draft for the "old" mingw guidelines - https://fedoraproject.org/wiki/User:Tibbs/MinGW_Old
15:19:50 <tibbs> So we sort of got into an odd spot with the mix of old and new guidelines.
15:20:17 <tibbs> Some folks take the old guideline to mandate the srpm name as something different than the new guidelines.
15:20:34 <tibbs> Hence adding new packages makes for a somewhat nasty transition.
15:20:43 <kalev> Hi guys, epienbro isn't around today, but can I try to clarify the intent here?
15:21:04 <kalev> The new guidelines essentially codify how to package up libraries using the mingw-w64 toolchain
15:21:06 <pjones> this tweak looks pretty reasonable to me.  we should force them to build a 64-bit targetting mingw while we're at it ;)
15:21:19 <kalev> that new toolchain, however, isn't yet in Fedora and we aren't sure how long it might take.
15:21:22 <spot> kalev: we already approved the new guidelines
15:21:33 <kalev> yes, and that's the problem.
15:21:35 <kalev> ktietz: are you here?
15:21:36 <spot> kalev: this is simply to address an issue in the "old" guidelines
15:21:37 <tibbs> I'm not sure there's any intent; the new guidelines specify a source package name; the old guidelines don't really but some people think it does.
15:21:51 <kalev> let me explain please.
15:22:00 <kalev> ktietz is the person who knows a lot more than me about the issues surrounding the mingw-w64 toolchain
15:22:03 <tibbs> So the tweak just says "yes, you can use mingw-foo for srpms even when using the old guidelines".
15:22:06 <ktietz> kalev: yes, the issue is that we wait still on reaction of RH legal department here
15:22:13 <tibbs> The w64 stuff has nothing at all to do with this.
15:22:24 <tibbs> And there's no legal issue involved at all.
15:22:37 <kalev> It has all to do about this issue
15:22:39 <spot> kalev & ktietz: please hold off on this, i think you're talking about something unrelated
15:22:54 <spot> we will let you have a chance to talk about your issue during our open floor time
15:23:05 <tibbs> The bottom line is that people are submitting SCM requests for mingw32-foo, and that's dumb.
15:23:19 <spot> tibbs: yes, agreed.
15:23:40 <tibbs> Because then they need a rename request to support the new stuff going forward, and another package review.
15:23:53 <tibbs> You can save all the pain by just calling the srpm mingw-foo on all releases.
15:24:07 <tibbs> It appears that people believe that violates the old guidelines.
15:24:28 <tibbs> So I propose simply modifying the old guidelines to allow use of the new naming for the srpm.
15:25:01 <spot> +1 to the proposed improvements to the "old" guidelines
15:25:04 <abadger1999> +1
15:25:06 <limburgher> +1
15:25:16 <tibbs> +1
15:25:18 <SmootherFrOgZ> +1
15:25:34 <geppetto> +1
15:25:50 <tibbs> As a bonus, this gets the example spec into the actual guideline page instead of as a link in someone else's SCM.
15:26:42 <spot> racor, i'll give you another minute or two to vote (i assume you are still reading the draft)
15:27:43 <racor> -1
15:27:45 <tibbs> I did apply this to an existing package and verified that identical content was generated.
15:28:02 <spot> racor: any rationale for your -1 vote?
15:28:19 <racor> the "old" and the "new" toolchains are entirely different beasts
15:28:37 <racor> "new" replaces "old"
15:28:39 <tibbs> What does that have to do with spm naming in the old guidelines?
15:28:52 <racor> tibbs: they are differentl packages
15:29:08 <spot> racor: yes, but this is a tweak to minimize bureaucracy and process in moving the same sources from the old chain to the new one?
15:29:16 <racor> "old" exists for "fedora < 16", "new" for newer
15:29:45 <tibbs> So you're saying that you think the additional bureaucracy is warranted?
15:29:49 <racor> spot: I don't consider this bureaucracy - They simily are different packages.
15:30:12 <spot> okay, fair enough. your dissent is noted. :)
15:30:19 <tibbs> Well, it's a valid point.
15:30:38 <tibbs> I approached it from the standpoint of trying to eliminate the extra review and such.
15:30:53 <tibbs> I don't think we ever considered the issue before.
15:31:06 <spot> #action Proposed improvements to "old" guidelines approved (+1:6, 0:0, -1:1)
15:31:38 <tibbs> Anyway, I guess packagers are welcome to force themselves to go through the extra review if they want.
15:31:47 <spot> #topic GIO scriptlets may be broken w/multilib - https://fedorahosted.org/fpc/ticket/81
15:32:08 <racor> tibbs: renamers require re-review at any case.
15:32:13 <spot> abadger1999: i think this ticket is yours, do you know if there is an actual issue here?
15:32:29 <abadger1999> I haven't had time to find a gnome person.
15:32:37 <abadger1999> halfline: Are you around by chance?
15:33:20 <abadger1999> spot: I'll touch base with a gnome person this week and update the ticket.
15:33:23 <tibbs> I read somewhere that you shouldn't generally use $1 -eq 1 but intead compare for bigger than 0.
15:33:31 <spot> fair enough, we'll revisit it next week
15:33:49 <tibbs> I can't remember where I read that but it might be useful to look over our scriptlets with that in mind.
15:33:52 <abadger1999> that is in the scriptletsnippets page but I don't think it helps with this particular issue.
15:34:14 <tibbs> It doesn't?
15:34:34 <tibbs> It appears that $1 is "2" instead of "1" and that breaks things.
15:34:47 <tibbs> Am I misunderstanding the problem.
15:34:49 <tibbs> ?
15:35:08 <geppetto> I just pinged mclasen
15:35:12 <abadger1999> actually... reading the comments it seems it would.
15:35:15 <mclasen> hi
15:35:33 <geppetto> mclasen: Hey, we needed a gnome person for advise on: https://fedorahosted.org/fpc/ticket/81
15:35:34 <abadger1999> mclasen: hey.  Do you know if GIO modules can be in a package that's multilib'd ?
15:36:01 <mclasen> I don't see why not
15:36:37 <abadger1999> okay.  Thanks.
15:36:54 <abadger1999> tibbs: Okay here's what I think is happening
15:37:04 <abadger1999> The %post is only supposed to fire on a new install
15:37:19 <abadger1999> upgrades are supposed to fire the %postun instead
15:37:21 <mclasen> I think we forgot to add a %posttrans, maybe ?
15:37:42 * mclasen has actually added %posttrans in most of the packages with gio modules, anyway...
15:38:03 <abadger1999> The problem is that neither the %post or %postun are fired if you're installing a multilib version of a package for the first time.
15:38:44 <abadger1999> Changing the %post conditional to -ge 1 is making it so that it fires on upgrades as well as installs.
15:38:59 <abadger1999> Which fixes the bug but doesn't do what the original scriptlet was attempting
15:39:33 <mclasen> the only thing that is important to me is that you run gio-querymodules whenever the set of installed modules changes
15:39:37 <abadger1999> mclasen: Can you tell us what the %posttrans looks like?
15:40:13 <abadger1999> mclasen: Right.  That's currently not being done when dealing with multilib packages containing a gio module
15:40:14 <mclasen> let me see if I can find an example
15:40:28 * mclasen won't comment on multilib...
15:41:08 <abadger1999> It's the environment we were given :-)
15:41:22 * spot blames notting
15:41:46 * mclasen thinks environments are changeable
15:41:50 <mclasen> anyway, it seems I was wrong
15:42:02 <mclasen> all the examples I can find just have a straight %post/%postun without and ifs
15:42:08 <mclasen> s/and/any/
15:42:34 <spot> abadger1999: okay, so do you want to propose the hackish fix (Changing the %post conditional to -ge 1) or would you like more time to try to come up with something else?
15:42:36 <abadger1999> Okay -- so the easiest solution is to get rid of the conditional and just deal with gio-querymodules-%{__isa_bits} %{_libdir}/gio/modules being run twice.
15:43:27 <mclasen> running it twice should be entirely harmless
15:43:34 <spot> abadger1999: that operation isn't terribly memory/cpu intensive, iirc.
15:43:47 <spot> so i dont think it really impacts things to run it more often than necessary
15:44:06 <abadger1999> Okay, let's do that.
15:44:26 <spot> I'm +1 to dropping the conditional on the %post item
15:44:34 <abadger1999> Proposal: Change GIO scriptlets to not conditionalize %post invokation to work around multilib issue.
15:44:37 <tibbs> It doesn't take ages to run, does it?
15:44:38 <abadger1999> +1
15:44:51 <geppetto> +1
15:45:02 <racor> +1
15:45:05 <spot> tibbs: i do not believe so
15:45:06 <limburgher> +1
15:45:12 <tibbs> +1
15:45:20 <limburgher> tibbs: If it does, we'll find out. ;)
15:46:09 <spot> SmootherFrOgZ: would you like to vote here?
15:47:01 <spot> #action Change GIO scriptlets to not conditionalize %post invokation to work around multilib issue is approved (+1:6, 0:0, -1:0)
15:47:27 <spot> #topic %find_lang handling revisited - https://fedorahosted.org/fpc/ticket/79
15:47:47 <tibbs> I haven't had the chance to play with this more.
15:47:55 <spot> okay, we'll table it for next week
15:48:13 <tibbs> We can probably drop it; I'll try to determine that.
15:48:25 <spot> tibbs: okay, if you decide to drop it, please close the ticket
15:48:30 <tibbs> Sure.
15:48:57 <spot> tibbs: ticket #76 (new filtering mechanisms) is also waiting on you (or someone) to draft a proposal
15:49:20 <tibbs> Right.  I've just had no luck syncing up with the RPM folks.
15:49:31 <tibbs> And the past few weeks have been very bad for me.
15:49:37 <spot> geppetto: is this something you could help out with?
15:49:51 <tibbs> Fortunately my in-laws leave today so I get some time back going forward, and the semester is ending.
15:50:12 <abadger1999> <nod>
15:50:53 <spot> so that leaves only ticket #80
15:51:02 <geppetto> spot: Not much … I mean, I can ping florian/Panu as much as anyone, I guess :)
15:51:04 <spot> #topic Handling sysv initscripts in a subpackage - https://fedorahosted.org/fpc/ticket/80
15:51:38 <spot> This item is the last contentious point of the systemd battles. :)
15:52:19 <geppetto> I thought we'd discussed just saying "no, don't ship both" ?
15:52:26 <spot> yes, we did discuss this
15:52:34 <SmootherFrOgZ> +1 from me (sorry, got distracted by an issue at dayjob)
15:52:47 <spot> but i think we might want to ask FESCo to make that call as opposed to FPC
15:52:53 <abadger1999> What's the proposal exactly?
15:53:30 <spot> Well, lemme propose this: We ask FESCo if they wish to continue to support packaging both sysv initscripts and systemd unit files.
15:53:46 <tibbs> Is there a use case for having both?
15:53:49 <spot> and we move forward based on that guidance
15:53:51 <abadger1999> I think we should be more specific.
15:54:03 <spot> tibbs: hypothetically, a spin using upstart as opposed to systemd
15:54:08 <geppetto> spot: Why do you think FESCo needs to decide?
15:54:16 <tibbs> spot: I don't think that's a valid case, though.
15:54:21 <tibbs> Unless we're going to _mandate_ them.
15:54:25 <geppetto> spot: Yeh, to go with the spin using dietlibc?:)
15:54:26 <spot> geppetto: because it goes beyond documenting acceptable use cases
15:54:41 <spot> we would be saying "you cannot package sysvinit scripts"
15:54:53 <abadger1999> are we asking "Can one service have both a sysvinit script and a systemd unit file; perhaps in separate subpackages?"  Are we asking "Can a service that provides both a sysv init script and a systemd unit file ship them in the same binary package?"
15:54:53 <spot> (if systemd unit files are present)
15:55:23 <tibbs> abadger1999: Your second question is certainly entirely within our purview.
15:55:25 <spot> abadger1999: the problem is that putting the sysv initscript in a subpackage adds quite a bit of complexity.
15:55:28 <geppetto> spot: But I think that's fair … we've banned .la files or .egg-info at various times, for similar reasons
15:55:41 <abadger1999> tibbs: <nod>
15:55:51 <SmootherFrOgZ> abadger1999, yep, second question
15:56:16 <abadger1999> spot: Has someone on the FPC (or outside the FPC) asked that we ban system v init scripts?
15:56:30 <spot> abadger1999: notting suggested it, and I'm not honestly opposed to it
15:56:58 <spot> i think if a package has a systemd unit file, there really isn't too much of a valid use case for including the systemv initscript (either in the main package or in a subpackage)
15:57:01 <geppetto> abadger1999: I think that having the packagers choose _either_ systemd files or sysv files is the best option
15:57:14 <abadger1999> I'm somewhat opposed to it... it's contrary to how we treat every other non-default init system.
15:57:40 <tibbs> I'm confused as to what people are for and against at this point.
15:57:43 <spot> abadger1999: whats the use case for packaging the sysv initscripts when unit files are present?
15:57:54 <abadger1999> spot: use with a non-default init system.
15:58:02 <tibbs> But, again, that won't work.
15:58:03 <abadger1999> upstart, sysVinit, etc.
15:58:26 <tibbs> If one core package doesn't ship sysvinit files, how does that spin work?
15:58:28 <abadger1999> tibbs: It won't work in the general case.  But it could work for a specific use-case.
15:58:31 <geppetto> So … I'm firmly in the "non-default init systems should not be in the distro."
15:59:05 <tibbs> And if the answer is that "they can add their own package with the sysvinit files", then why can't they just do that for everything, and keep their stuff out of the main distro?
15:59:09 <abadger1999> geppetto: That would be a question to pass to FESCo if we want.... probably with a strawman poll of what we think.
15:59:26 <geppetto> abadger1999: I guess … but do you seriously think that's viable?
15:59:47 <abadger1999> geppetto: ensc was doing that.
16:00:01 <tibbs> Sort of.
16:00:07 <spot> abadger1999: ensc does a lot of things that no human should sanely do.
16:00:10 <tibbs> He was maintaining his own OS.
16:00:24 <abadger1999> spot: Yeah, like dietlibc :-)
16:00:31 <tibbs> And for the packages where he could, he added weird stuff so that he didn't have to maintain it separately.
16:00:44 <abadger1999> <nod>
16:01:08 <spot> So, maybe we're spending time trying to document a case that no one cares about...
16:01:14 <tibbs> But here's the question: why do we care if people want to package sysvinit stuff?
16:01:15 <spot> except for ensc. :)
16:01:26 <abadger1999> tibbs: Right.
16:01:37 <tibbs> So, a question:
16:01:57 <tibbs> If someone wants to stick sysvinit stuff in a subpackage, does the main package have to change in any way?
16:02:08 <tibbs> That trigger thing has to go in?
16:02:20 <spot> tibbs: not as far as I know, the triggerpostun applies to the subpackage
16:02:44 <spot> the problem is that if the subpackage gets installed on a systemd enabled system...
16:02:58 <spot> then the chkconfig call gets handed to systemctl
16:03:09 <tibbs> Which means that someone who wants their own sysvinit-based distro can easily just package up a bunch of sysvinit scripts and not bother Fedora.
16:03:20 <tibbs> Which means that we don't lose anything at all by just banning them.
16:03:26 <abadger1999> eh...
16:03:47 <abadger1999> Why should we ban them?
16:04:03 <tibbs> Because they're completely unnecessary in Fedora.
16:04:12 <tibbs> And because if someone happens to install both, they get breakage.
16:04:32 <abadger1999> They don't get breakage of systemd, correct?
16:04:32 <tibbs> I mean, we could add Conflicts: systemd to them or something.
16:04:47 <abadger1999> Just of the sysvinit stuff?
16:04:50 <tibbs> spot just said they did.
16:05:04 <tibbs> "[11:02] <spot> the problem is that if the subpackage gets installed on a systemd enabled system..."
16:05:18 <spot> abadger1999: the chkconfig --add call will be interpreted by systemctl on a systemd enabled install
16:05:26 <tibbs> Maybe I'm misunderstanding.
16:05:40 <spot> chkconfig on a systemd env is just a wrapper for systemctl
16:05:41 <tibbs> Or maybe we could get the new chkconfig tweaked with a --no-handoff option or something.
16:05:54 <abadger1999> spot: Right... which breaks usage of chkconfig for the sysv style init system... but leaves systemd still working correctly?
16:06:25 <spot> abadger1999: i don't know what it will do, in the documented apache-httpd case, it might result in two services
16:06:57 <spot> at best, it would result in two configuration "files" for a single service with systemd ignoring the sysv initscript
16:06:58 <michich> tibbs, the option exists and it's called --no-redirect
16:07:10 <tibbs> Hey, awesome.
16:07:21 <tibbs> Maybe... we could use it?
16:07:51 <abadger1999> mchua: http://git.fedorahosted.org/git/?p=chkconfig.git;a=commitdiff;h=318825db1aafca9a2bdb64c48eb54537f2e5e01e;hp=74485322b128f1c6418e86b646b36ee2407a675d
16:07:57 <abadger1999> oh sorry.
16:08:06 <abadger1999> Didn't see that you had just said the same thing.
16:08:06 <spot> that would resolve that concern.
16:08:45 <spot> wait, nm
16:08:50 <spot> it doesn't work on a --add call
16:09:07 <spot> "This option is only valid when on, off, or no command (to check enablement) is passed to a service."
16:09:25 <michich> maybe --add works even without it? I have not tried.
16:10:06 <spot> michich: i'm pretty sure --add is a passthrough to systemctl
16:10:27 <michich> no, there is no equivalent to --add in systemd
16:10:51 <michich> I have now tried chkconfig --add NetworkManager on F15 and it creates the SysV symlinks as expected
16:10:59 <abadger1999> Scanning the code, it doesn't look like add ever tries to send to systemd
16:11:05 <spot> okay, then i suppose it is a non-issue.
16:12:08 <tibbs> So, where are we at?
16:12:50 <spot> Proposal: Add https://fedoraproject.org/wiki/User:Toshio/Systemd_scriptlet_options#Subpackage_with_sysv_initscripts to https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_spec_file_scriptlets
16:12:50 <tibbs> If the sysvinit subpackages don't hurt anything besides adding some random clutter, what's issues remain?
16:13:55 <abadger1999> So this would be my position: 1) If sysv init scripts can coexist with systemd unit files and not cause issues for systemd then they should be allowed to be packaged.  2) If improperly packaging (incl. scriptlets) for the sysv init scripts can cause issues for systemd then we should document how to properly package them.
16:14:00 <geppetto> spot: I think that, at least, we should have some wording that suggests packagers don't need to ship both
16:14:21 <spot> geppetto: we already have that
16:14:28 <spot> "Packages may also provide a SysV initscript file, but are not required to do so. This format is considered legacy, but Fedora still contains init mechanisms such as upstart which do not support the systemd unit file format. If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins. The guidelines for SysV initscripts can be found here: Packaging:SysVInitScript"
16:14:47 <geppetto> ok, fair enough
16:15:10 <spot> my proposal is to just add a section about the scriptlet necessary for the subpackage handling in the mixed case universe
16:15:41 <abadger1999> +1 from me.
16:15:49 <tibbs> I can get behind either that or banning them entirely.
16:15:55 <tibbs> So +1 for me.
16:16:01 <spot> +1
16:16:19 <SmootherFrOgZ> +1
16:17:01 <limburgher> +1
16:17:11 <geppetto> +1
16:17:51 <spot> #action Adding a section to describe the scriptlet necessary for sysv subpackage handling in sysvinit-specific guidelines is approved (+1:6, 0:0, -1:0)
16:18:13 <spot> okay, thats the last ticket on the agenda
16:18:17 <spot> #topic Open Floor
16:18:42 <tibbs> Nothing from me.
16:19:00 <spot> kalev: if you'd like to bring up your mingw concern, now would be the appropriate time
16:19:15 <kalev> yes.
16:19:33 <kalev> The issue with the new MinGW guidelines is that they were meant for the new toolchain, but the new toolchain is not yet ready (legal issues, like ktietz said).
16:19:47 <kalev> The "old" toolchain is only for building for 32 bit target, and a large part of the "new" guidelines is about how to build packages for both 32 bit and 64 bit targets at the same time.
16:20:08 <kalev> At the moment the "new" guidelines are incompatible with the "old" toolchain.
16:20:33 <kalev> so the "new" guidelines cannot be used at this point, at least not without modification, because the "new" toolchain isn't yet in and we have no idea how long it might take.
16:20:56 <kalev> What I am proposing is to edit the official pages so that the new guidelines wouldn't be so promiment and to show everyone that, for now, they should be be using the "old" guidelines instead.
16:21:19 <kalev> for what it's worth, I am fine with allowing the source packages to be also named mingw- in the "old" guidelines; that will certainly ease future transition to the "new" mingw-w64 toolchain + the "new" guidelines, whenever that might happen.
16:21:42 <spot> kalev: is there any chance the new mingw toolchain will make it in Fedora 16?
16:22:00 <kalev> But right now the "new" guidelines are only causing confusion; they cannot be used, yet the official pages say that they should be used.
16:22:05 <tibbs> I'm a bit confused as to why those guidelines were pushed when they're not useful.
16:22:10 <kalev> spot: I have no idea. ktietz?
16:22:40 <spot> we can reword the notices, but my impression was that they were valid for rawhide (hence, F16). If that isn't true, we should amend the notices.
16:23:05 <kalev> yep, the notices aren't true.
16:23:28 <kalev> the new guidelines are certainly a good starting point for importing the "new" toolchain, but this hasn't happened yet and I have no information when that can happen.
16:23:39 <kalev> I suppose epiebro thought the legal stuff would clear up earlier.
16:23:50 <spot> kalev: fwiw, i am unware of this "legal stuff"
16:23:55 <spot> which is never a good sign. :P
16:24:25 <tibbs> What I don't get is why the guidelines don't work as is.
16:24:36 <tibbs> I mean, I know there were some renames and such that needed to go through.
16:24:45 <spot> kalev: if someone could be nice enough to fill me in on the details offline... i'd appreciate it.
16:24:57 <tibbs> If the 64-bit portion doesn't yet work, why not just note that?
16:25:09 <tibbs> But the 32-bit portion should work the same as it ever did.
16:25:46 <tibbs> What am I missing?
16:26:00 <kalev> the 32 bit portion had a lot of changes too, which are largely pointless if we don't have the new toolchain in.
16:26:31 <kalev> for example, packages are named different: mingw32-w32api vs mingw32-headers, mingw32-runtime vs mingw32-crt
16:26:59 <kalev> introducing a lot of new macros which aren't needed at all for the old toolchain, and which needs the new mingw-filesystem package
16:27:21 <tibbs> I thought we had the new mingw-filesystem package now.
16:27:26 <racor> kalev:  ... facts which will break quite some amount of 3rd party works.
16:28:26 <kalev> tibbs: yep, my point is, we certainly _can_ make the new mingw-filesystem work with the old toolchain, but it will be a lot of unnecessary work with all the packages
16:28:52 <tibbs> Nothing requires changing existing packages, though.
16:29:14 <tibbs> Unless someone really didn't think this through at all and made things somehow mutually exclusive.
16:29:32 <racor> tibbs: 3rd party packages do
16:29:44 <tibbs> do what, exactly?
16:30:16 <racor> tibbs: require current mingw32-* packages and depend on them otherwise
16:30:29 <tibbs> They can adapt, can't they?
16:31:15 <tibbs> I'm really annoyed that someone pushed these guidelines all the way through the process without any of this coming to light at all.
16:31:15 <racor> tibbs: Sure, but ... avoid such changes avoids work.
16:31:25 <kalev> it's hard to make a good decision here without knowing if the new mingw-w64 toolchain is allowed to get in Fedora.
16:31:44 <kalev> tibbs: I agree
16:31:48 <tibbs> Well, the whole decision shouldn't have happened until that was known.
16:31:53 * spot nods
16:32:09 <tibbs> So what do we do now?
16:32:09 <racor> kalev: I consider both issues (guidelines vs. legal) to be independent
16:32:26 <tibbs> They're most certainly not independent.
16:32:35 <spot> tibbs: i propose that we make it clear that the new guidelines are pending on the new mingw-w64 toolchain being added to Fedora
16:32:50 <tibbs> We can't pass a guideline that says "use this" when the thing you're supposed to use can't actually be in the distro.
16:32:55 <kalev> What I was thinking when all the discussion was happening earlier is that spot knows about the legal issues and the new guidelines are only being approved because spot thinks there's a fair chance we can actually use them.
16:33:09 <spot> kalev: i don't know about the legal issues. :)
16:33:12 <tibbs> This is the first most of us have heard of any legal issues.
16:33:19 <racor> kalev: I don't see this. You can change  package names/macros without taking into account 64bit.
16:33:56 <kalev> well, these two issues are certainly interwined.
16:34:49 <kalev> spot: would you have time to come to the #fedora-mingw channel later and discuss the issues with the mingw-w64 toolchain?
16:34:55 <spot> kalev: sure.
16:35:09 <kalev> I have no idea what's going on with RH legal, but apparently ktietz has been talking to someone
16:35:15 <racor> what you are doing to me boils down to replacing one cross toolchain with another one, rsp. one set of packages with another one. As 64bit would be new, it doesn't matter when/if it will/will not be introduced
16:35:40 <abadger1999> Proposal: Move the old guidelines (w/ tibbs's tweaks) back to Packaging:MingW ; change the admonitions to say that the new guidelines have been approved but are not yet in effect ; have the mingw SIG open a new ticket when the new packages are in and they want the situation reversed.
16:36:04 <spot> abadger1999: you beat me to typing up the same thing with different wording. :)
16:36:07 <spot> +1
16:36:11 <kalev> sounds good to me
16:36:20 <abadger1999> +1
16:36:45 <racor> I regret, I've got to quit now.
16:37:44 <spot> there is +2 for that proposal. tibbs, geppetto, SmootherFrOgZ, limburgher ?
16:37:51 <geppetto> +1
16:37:57 <geppetto> although I'm pretty confused :)
16:38:31 <gholms> Bad time to pop in and ask a question?
16:38:41 <abadger1999> gholms: Almost a good time :-)
16:38:59 <abadger1999> gholms: Trying to wrap up a vote.
16:39:05 * gholms wants
16:39:07 <gholms> *waits
16:39:09 <SmootherFrOgZ> +1  spot
16:39:19 <spot> tibbs, limburgher ?
16:40:19 <limburgher> sorry, akf, one sec.
16:40:20 <limburgher> alk
16:40:24 <limburgher> afk dammit!
16:41:21 <limburgher> +1
16:41:34 <spot> #action Move the old mingw guidelines (w/ tibbs's tweaks) back to Packaging:MingW ; change the admonitions to say that the new guidelines have been approved but are not yet in effect ; have the mingw SIG open a new ticket when the new packages are in and they want the situation reversed :: APPROVED (+1:5, 0:0, -1:0)
16:41:45 <spot> okay. :)
16:41:48 <spot> gholms: go ahead
16:42:05 <kalev> spot: perfect, thanks guys.
16:42:37 <gholms> How does one decide whether it is appropriate to have a module for an alternate python stack in a package that is distinct from the main one?
16:43:16 <spot> abadger1999: i think this has your name on it.
16:43:20 <gholms> I was under the impression that having them in the same package was usually better, but abadger1999 raised some good points to the contrary in bug 702677.
16:44:01 <abadger1999> gholms: So my postion is that it's better to be in separate packages but in the specific case of python2 + python3 in Fedora, having subpackages is the general rule.
16:44:13 <abadger1999> gholms: Where I have reservations about tat specific case :-(
16:44:47 <spot> fwiw, my opinion is that if the core maintainer is fine with maintaining support for alternate stacks in that package, they can do so, but are not required to.
16:45:19 <tibbs> Sorry, I got called away.
16:45:30 <tibbs> In-laws need to get to the airport.
16:46:10 <abadger1999> after my ongoing experience with pyhton-docutils, I wish that I'd pressed harder to keep the modules in separate packages.
16:46:51 <gholms> That makes sense to me.
16:47:23 <spot> okay. if there are no other open issues, i'm going to close out the meeting.
16:47:36 <gholms> What I hope to get out of you folks is a little more guidance in that part of the wiki, I guess.
16:48:03 <gholms> It isn't clear to me that that doesn't apply to python2 vs. python26.
16:48:16 <gholms> ...and I suspect that I can't edit it myself.  :)
16:48:23 <spot> abadger1999: since you understand the problem space, perhaps you could draft a guidance change with pros/cons ?
16:48:46 <abadger1999> python26 isn't in Fedora at all -- just epel... so that's probably why it's not in the guidelines
16:48:58 <abadger1999> I'll look into adding something small to call attention to that detail.
16:49:06 <gholms> Many thanks
16:49:29 <abadger1999> np
16:49:46 <spot> Okay, and with that, I think we're done for today.
16:49:49 <spot> Thanks everyone.
16:49:51 <spot> #endmeeting