15:59:12 <spot> #startmeeting Fedora Packaging Committee
15:59:12 <zodbot> Meeting started Wed Mar 23 15:59:12 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:59:18 <spot> #meetingname fpc
15:59:18 <zodbot> The meeting name has been set to 'fpc'
15:59:24 <spot> #topic Roll Call
16:00:25 <spot> no one?
16:00:27 <spot> wow. :)
16:00:49 * abadger1999 here
16:01:32 <spot> tibbs|h, rdieter_work, SmootherFrOgZ, limburgher: ping?
16:01:51 <spot> this might be a quick meeting.
16:01:55 <rdieter_work> hola
16:02:34 <spot> geppetto: ping?
16:02:43 <geppetto> here
16:03:33 <tibbs|h> Here now.
16:03:45 <tibbs|h> Talkative in-laws.
16:06:01 <spot> okay, thats 5 (6 if racor is actually here)
16:06:49 <spot> #topic SystemD - https://fedorahosted.org/fpc/ticket/31
16:06:52 <spot> err..
16:06:56 <spot> #topic Systemd - https://fedorahosted.org/fpc/ticket/31
16:07:17 <spot> We split this into two parts
16:07:27 <spot> new packages with systemd service files
16:07:36 <spot> and upgrading from packages with sysv initscripts
16:07:52 <spot> I spent some time testing the first half
16:08:08 <spot> https://fedoraproject.org/wiki/User:Spot/Testing_systemd#Environment
16:08:33 <spot> in the process of testing, i discovered that the scriptlets were wrong
16:08:43 <spot> and that daemon-reload does not do what I thought it does
16:08:53 <spot> (or at least, it does not act that way currently)
16:09:09 <Rathann> I'm half-here
16:09:10 <spot> thankfully, the fix was pretty straightforward
16:09:16 <spot> and I have already updated the draft
16:10:05 <spot> are there any questions about my testing there?
16:11:02 <racor> sorry, was distracted, I am here
16:11:16 <tibbs|h> The "This is ugly" part...
16:11:28 <abadger1999> Need to test reboots too.
16:11:35 <tibbs|h> I'm not sure if that comment indicates that there's a problem.
16:11:37 <abadger1999> and also allowed to autostart.
16:11:39 <spot> tibbs|h: the ugly part is that systemd reports the removed service as "error  inactive dead"
16:11:58 <tibbs|h> Oh, the comment is for the preceeding line, not the following one.
16:12:02 <spot> tibbs|h: and it doesn't get garbage collected on a daemon-restart
16:12:09 <spot> but it's gone.
16:12:09 <abadger1999> and also upgrade from systemd using package version 1 to systemd using package version 2
16:12:12 <tibbs|h> Right, I what you're saying.
16:12:40 <spot> abadger1999: okay, i can test those things pretty simply by just incrementing release and rebuilding.
16:12:41 * Rathann has to get off the bus
16:12:45 <Rathann> bbiab
16:12:45 * limburgher is here, finally.
16:12:47 <abadger1999> spot: Well
16:12:50 <abadger1999> spot: Actually not
16:13:02 <abadger1999> spot: You also need to check that on upgrade, the new code is running.
16:13:13 <limburgher> sorry i'm late, work is nuts today.
16:13:22 <abadger1999> spot: after updating the package but before doing a reboot.
16:13:28 <spot> abadger1999: would it be sufficient to change something in the service info text?
16:13:37 <spot> that way we'd see that the new service file was in use.
16:14:17 <abadger1999> spot: Not sure -- with the test supervisor package I had, I changed the version that the server reported when I connected to it with a command line tool.
16:14:45 <abadger1999> spot: Is the service info text something that ser2net itself reports in the same way?
16:14:57 <spot> not really, this code is pretty simple
16:15:00 <abadger1999> spot: If it's just what systemd reports, then it's not sufficient.
16:15:05 <abadger1999> k
16:15:31 <spot> okay. well, it looks like i'm going to need more time to test those cases.
16:15:37 <spot> i don't want to waste meeting time on it
16:15:49 <spot> so i will send an email to the list with the results later today
16:16:03 <tibbs|h> Honestly I have to say that there is simply no way we are going to be able to approve anything without having to revise it later.
16:16:35 <spot> tibbs|h: okay, so are you saying we should approve it as is and revise if testing shows a need?
16:17:40 <abadger1999> spot: Hmm.. what's the difference between systemd enable and systemd load ?
16:18:07 <tibbs|h> spot: Well, not necessarily.
16:18:16 <abadger1999> My testing showed that systemd enable was pretty close to an equivalent of chkconfig --add
16:18:54 <spot> abadger1999: "Enabling simply hooks the unit into various suggested places (for example, so that the unit is automatically started on boot or when a particular kind of hardware is plugged in)."
16:19:11 <spot> load just tells systemd "hey, you have a new .service file."
16:19:50 <spot> enable will have it autostart on a reboot
16:19:55 <abadger1999> The man page says that systemctl load is pretty much useless.
16:19:59 <abadger1999> What's it doing here?
16:20:16 <spot> abadger1999: well, lennart thinks it is useless, but that doesn't mean it is.
16:20:49 <abadger1999> enable will have it autostart on reboot if the unit file specifies that it is Wanted-by the target that we are running in.
16:21:00 <abadger1999> Otherwise it won't
16:21:05 <spot> hm. okay.
16:21:14 <spot> so maybe enable is always the right command there
16:21:26 <spot> this all gives me migraines
16:21:34 <tibbs|h> You are not the only one.
16:21:36 <abadger1999> We're starting to get into a mess of twisty corridors but...
16:21:37 <spot> i have yet to be convinced that this is somehow a better implementation.
16:21:53 <tibbs|h> up arrow enter.
16:22:02 <spot> i will test with enable as opposed to load.
16:22:09 <abadger1999> enable would be the right command iff we are making the unit files contain the information about which levels we want them to autostart in.
16:22:19 <abadger1999> Which would be like the way we handle sysv init scripts.
16:22:42 <abadger1999> But I think that the lennart/guidelines philosophy for systemd has been that information is carried in the spec files instead.
16:22:43 <geppetto> abadger1999: If the infromation wouldn't live there, where would it live?
16:22:52 <geppetto> blah
16:23:17 <spot> well, if you think that is a distribution level decision
16:23:23 <abadger1999> ie: we run enable in the spec file if we want it to "autostart" (but the unit file has to specify the proper target).
16:23:25 <spot> and you are assuming that upstream is providing the .service
16:23:45 <abadger1999> and that the upstream .service specifies the targets that we're actually using.
16:23:48 <spot> then the spec file could conceivably be the "right" place to make that distinction
16:24:27 <abadger1999> <nod>  It could be.  but there's a fair few assumptions in there and it's a change of philosophy that people have to wrap their heads around.
16:24:59 <spot> to handle it in the service files, we'd have to unset WantedBy=
16:25:06 * Rathann is back
16:25:25 <abadger1999> Right.
16:25:28 <spot> and that just seems somehow more hackish that documenting "if not on by default, use load. if on by default, use enable."
16:25:55 <spot> s/that documenting/than documenting/
16:26:32 <abadger1999> So what does load accomplish here?
16:26:49 <spot> load tells systemd about the service, but does not make the symlinks
16:26:58 <spot> you still need to enable it or start it
16:27:14 <abadger1999> What happens if we don't do load?
16:27:30 <spot> systemd doesn't know about it
16:27:33 <spot> so a start will fail
16:27:39 <spot> an enable will succeed though
16:28:06 <abadger1999> okay, so it's probably needed for the non-autostart %post and is not needed for autostart post
16:28:27 <spot> abadger1999: yep. with the clarification on enable, i agree.
16:28:28 <abadger1999> What about the note i nthe man page that: "Note that systemd garbage collects loaded units that are not active or referenced by an active unit. This means that units loaded this way will usually not stay loaded for long."
16:29:06 <spot> abadger1999: dunno. worst case, you're back in the "start doesn't work, enable will succeed" case.
16:29:07 <abadger1999> Doesn't that mean that running load in the package %post will make systemctl start work right after package install but not after the next garbage collection?
16:29:12 <abadger1999> k
16:30:07 * spot wonders if i can force it to garbage collect
16:31:09 <abadger1999> why was daemon-reload not the right thing to use?
16:31:18 <abadger1999> documentation implies that it is.
16:31:24 <geppetto> abadger1999: So, wait … if I stop a unit … then systemd might GC it, so I can't start it?
16:32:15 <spot> also related, i propose that we replace this sentence: "Most systemd services must be disabled by default, especially if they listen on the network." with "Services can either be enabled or disabled by default. To determine which case your specific service falls into, please refer to FESCo's policy here (url)."
16:32:30 <abadger1999> +1 to that change
16:32:49 <geppetto> sure, +1
16:32:55 <abadger1999> geppetto: I don't know -- needs testing to find out.
16:33:13 <spot> after daemon-reload, systemctl didn't know about the new service
16:33:28 <spot> which makes sense, i suppose, given how enable works
16:33:43 <spot> but i expected that users might be baffled at that behavior like i was
16:34:25 <spot> aha, daemon-reload does a GC
16:34:35 <spot> [spot@f15 ~]$ systemctl -a |grep ser2net
16:34:35 <spot> ser2net.service           loaded inactive dead          Proxy that allows tcp co
16:34:35 <spot> [spot@f15 ~]$ sudo systemctl daemon-reload
16:34:35 <spot> [spot@f15 ~]$ systemctl -a |grep ser2net
16:34:35 <spot> [spot@f15 ~]$
16:34:48 <abadger1999> Guh
16:34:54 <spot> awesome, huh? :)
16:35:00 <abadger1999> spot: I think ask lennart if this is a bug in systemd
16:35:16 <spot> abadger1999: earliest that will happen is next week
16:35:24 <spot> but i suspect it is intended behavior
16:35:30 <spot> because we have not enabled the service
16:35:39 <abadger1999> *sigh*
16:35:49 <abadger1999> Can we revert back to SysVinit?
16:36:00 <spot> abadger1999: we can ask fesco to consider it.
16:36:04 <abadger1999> heh
16:36:29 <spot> although, at this point, i don't see them doing that.
16:37:09 <spot> i'll talk to lennart and we'll revisit this next week
16:37:17 <abadger1999> Alright... what we really need to ask lennart is -- what systemctl commands need to run in %post to make "systemctl start "work after a package is installed.
16:37:25 * spot nods
16:37:40 <abadger1999> taking into account that the "systemctl start" may be done after GC has run.
16:39:11 <abadger1999> What do you think about me pinging adamw after the meeting to see about qa running these types of tests too?
16:39:22 <tibbs|cell> my home internet is broken.
16:39:24 <geppetto> That seems like a good idea
16:39:26 <spot> abadger1999: sure
16:39:39 <spot> just make it clear that we still haven't figured out the correct scriptlets yet
16:39:57 <abadger1999> Cool.  Designing the test matrix and running the tests is the part of this work that makes my head spin.. maybe having someone used to that stuff will help there.
16:40:00 <abadger1999> <nod>
16:40:32 <abadger1999> I think the goal will be -- we provide test packages with scriptlets, the tester makes sure that all the permutations of installing/upgrading those packages works.
16:40:49 <geppetto> I suspect that they probably want to just install a service in a package, and then run a whole bunch of systemctl commands and make sure it does sane things
16:40:50 <spot> you know...
16:40:50 <abadger1999> We're good when all the permutations come out with desired behaviour.
16:41:04 * spot is uncovering new wrinkles.
16:41:10 <spot> i'm just going to test a ton more and report back.
16:41:19 <spot> this is clearly not ready yet.
16:41:20 <abadger1999> k
16:41:31 <tibbs|h> Finally.
16:41:32 <spot> does someone have the URL for FESCo's onboot policy?
16:41:50 <abadger1999> Go on and I'll find it.
16:42:55 <spot> #topic CMake - https://fedorahosted.org/fpc/ticket/48
16:43:09 <spot> rdieter_work: you said in that ticket you were going to look into it, but it doesn't look like that happened
16:43:56 <rdieter_work> yeah, my fail... (fell of my plate all over the floor) I can do that soonish
16:44:39 <spot> mmkay.
16:44:46 <spot> #topic Java - https://fedorahosted.org/fpc/ticket/70
16:46:11 <spot> looking at the helpful diff, it all seems fine to me.
16:46:21 <tibbs|h> I read through this when it was submitted; It has the benefit of removing some cruft as well as making the guidelines match what's currently actually needed.
16:47:06 <tibbs|h> The macroization of the jpackage_script thing makes sense to me as the kind of thing we'd want to hide behind macros.
16:47:26 * spot nods
16:48:10 <tibbs|h> That said, I haven't actually tested it since I don't package any java stuff.
16:48:21 <abadger1999> I don't have much java experience but it looks fine to me
16:48:31 <spot> the fedora-java folks converted my one java package to use the new maven3 bits
16:48:36 <spot> and it made it work considerably better
16:48:43 <spot> so I'm solidly +1 here
16:49:01 <limburgher> My java-fu is weak but it looks sane.
16:49:20 <tibbs|h> I do wish in general they'd separate the "change this because it's outdated info" stuff from the "we're adding new convenience macros" thing.
16:49:36 <tibbs|h> But I'm stil +1 on this draft.
16:49:52 <Rathann> same here, +1
16:49:54 <rdieter_work> +1
16:49:57 <geppetto> dito. +1
16:50:20 <spot> thats +5, racor, abadger1999, rdieter_work, want to vote for the record?
16:50:29 <abadger1999> +1
16:50:30 <limburgher> +1
16:50:34 <spot> err.
16:50:41 <spot> rdieter_work did vote. :)
16:50:49 <limburgher> can'
16:50:52 <spot> systemd has eaten what little remains of my brain.
16:50:52 <limburgher> 't be too careful
16:51:01 <rdieter_work> nom nom
16:51:20 <racor> Pardon, I was reading the proposal
16:51:31 <limburgher> could have been a confused string theorist.
16:51:39 * rbergeron throws a hotdog at systemd because we need the remainders of spot's brain
16:52:02 <spot> rbergeron: somehow i doubt that systemd worships the hot dog.
16:52:31 <spot> #action Approved (+1:7, 0:0, -1:0)
16:53:11 <racor> I noticed maven-3 only exists in Fedora > 14. to me this would mean the "old maven" guideline should stay with some remarks added
16:53:14 <limburgher> i heard systemd only eats lasagne and orphans.
16:54:21 <spot> racor: that is an interesting point
16:54:46 <tibbs|h> Unfortunately I have no F13 left.
16:55:12 <racor> apart of this, this proposal sounds good -> +1
16:55:38 <tibbs|h> I guess we can just keep an old copy around for the few weeks until F13 no longer accepts new packages.
16:56:10 * spot wonders if f14 has maven3
16:56:43 <spot> looks like it does
16:57:37 <spot> actually...
16:57:38 <spot> no. it doesn't.
16:57:39 <abadger1999> spot: Re: fesco policy url: It's still, needs to be moved: https://fedoraproject.org/wiki/User:Kevin/DefaultServices
16:57:39 * geppetto can't see maven or maven3 outside of f15
16:57:40 <tibbs|h> I'd say it would have been a bit kinder if they had told us what releases are actually supported by the new draft.
16:57:48 <spot> when i write this up, i'll rework it to talk about maven2 vs maven3
16:57:55 <spot> and note to revisit it when f-14 dies
16:59:12 <spot> okay, lets try to get one more item in
16:59:21 <spot> #topic MinGW-64 https://fedorahosted.org/fpc/ticket/71
16:59:37 <spot> https://fedoraproject.org/wiki/PackagingDrafts/MinGWCrossCompiler
16:59:57 <tibbs|h> racor had significant objections to what they were doing before.
17:01:04 <spot> tibbs|h: i don't recall what those objections were though
17:01:42 <racor> I don't know what tibb|h is referring to, but ...
17:02:00 <racor> i had 2 issues with recent developments:
17:02:20 <tibbs|h> There was a review with some strenuous objections.
17:02:45 <racor> 1) the target name mingw-w64 ... this doesn't harmonize well with autoconf
17:03:14 <racor> 2) the request to rename the "mingw32-xxx" packages into "cross-xxx"
17:03:39 <tibbs|h> The latter is not in the new draft.
17:03:45 <tibbs|h> They're using just "mingw" now.
17:03:49 <spot> so, #2 isn't in this draft, so it should be a non-issue
17:04:04 <spot> as to #1, can you propose an alternative that autoconf likes?
17:05:04 <racor> spot: It's a problem we can't solve - Only upstream can do so.
17:05:30 <spot> Also, in this draft they say "Cross compiled packages" several times, i think this should be changed to "Cross compiled MinGW packages"
17:05:35 <racor> i mean upstream mingw(32)
17:05:50 <tibbs|h> I guess I don't understand the aims of their project.
17:06:26 <spot> racor: while this may be valid, i don't think this necessarily is a problem with the draft
17:06:27 <tibbs|h> I thought it was just "build things for windows" but now there's talk of apple's OS.
17:07:03 <SmootherFrOgZ> hey, sorry just back from dayjob meeting. will scroll up to be in sync
17:07:50 <racor> tibbs|h: they talked about MacOS in their cross-xxx renamer proposal
17:08:02 <abadger1999> cross- is mentioned here: https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework#Porting_guide
17:08:10 <abadger1999> and the guidelines draft links to that
17:08:37 <spot> sneaky.
17:08:56 <spot> i think the attempt here is to write guidelines for all cross compilers
17:09:04 <spot> and i'm not sure this is a good fit for that
17:09:12 <tibbs|h> I doubt it is.
17:09:41 <spot> well, it says it is "Packaging Guidelines for cross compiler framework"
17:09:56 <spot> when the old guidelines said "Packaging Guidelines for MinGW Windows cross-compiler"
17:10:16 <racor> tibbs|h: so do i. It's not even close to it
17:10:30 <spot> i think that if someone came across it as is with the new wording, they'd think it was for all Cross compilers
17:10:47 <tibbs|h> Yes.
17:10:54 <spot> it seems reasonably sane if narrowly limited to the mingw environments, but thats as far as i'm comfortable with it
17:11:03 <Rathann> hm, what does mingw have to do with MacOSX?
17:11:07 <tibbs|h> Plus, I doubt the MacOS stuff will ever be licensed properly.
17:11:11 <spot> i really don't like the secondary document which should be in the packaging guidelines
17:12:24 <racor> Rathann: They believe their framework to be general enough and pulled out MacOS as potential future extension.
17:12:36 <limburgher> Yeah, at least the title has to change, it's Win32-centric.  If they want to go general, they need to do that, and haven't
17:12:50 <limburgher> Like, how would I adapt this to Hurd or Plan9?
17:12:53 <tibbs|h> Well, they proposed "cross-".
17:12:58 <spot> so, i could reword it to match the older document and be very narrowly specific to MinGW only
17:13:09 <spot> and drop the section pointing to the "porting guide"
17:13:16 <racor> limburgher: or the bsds (no joke I do have bsd cross toolchains)
17:13:40 <limburgher> racor: I wasn't joking either.  Minix, for that matter.
17:13:44 <spot> although, my gut tells me we're going to hear screaming if we approve that.
17:13:45 <tibbs|h> But the question is whether their framework can be extended that far.
17:14:15 <tibbs|h> One problem is that they have "grand designs" which it doesn't appear they've talked about outside of their group.
17:14:18 <geppetto> Is it realistic to expect that anything other than win32 is going to get into Fedora?
17:14:31 <tibbs|h> win64, probably.
17:14:32 <spot> geppetto: well, win64 seems likely.
17:14:40 <racor> spot: I already yelled during he "cross-xxx" renamer reviews.
17:14:44 <geppetto> yeh … but minix or bsds?
17:14:53 <tibbs|h> OSX, probably not as long as the licensing stuff doesn't change.
17:15:04 <tibbs|h> BSD, I don't see why not, though I'm not sure I see the point.
17:15:32 <limburgher> If it's truly general, there should be a path to that.  There's not much point, but someone may want to.
17:15:48 <spot> well, we're almost out of time for today
17:15:51 <tibbs|h> I think they were originally going tof rhtat.
17:15:55 <tibbs|h> for that.
17:15:56 <limburgher> Plus, then we're prepared for $_COOL_NEW_OS_ALL_THE_KIDS_ARE_USING down the road.
17:16:25 <spot> i'm going to make a new draft that isn't "all cross compilers ever" and just enables win64.
17:16:29 <tibbs|h> Honestly, I'd be happy to see some kind of general cross-toolchain errorf.
17:16:38 <limburgher> spot: +1
17:16:42 <tibbs|h> effort. Man, I can't type today.
17:16:47 <tibbs|h> spot: +1.
17:16:51 <limburgher> tibbs|h: Agreed.
17:16:58 <Rathann> yep, one step at a time
17:16:59 <racor> hardly possible
17:16:59 <spot> then, if there is interest in a grand unified cross compiler draft, we can revisit it separately.
17:17:08 <tibbs|h> Sure, it's possible to have an effort.
17:17:13 <tibbs|h> You know, people talk about things.
17:17:21 <tibbs|h> Unless you're saying that people will never talk about things.
17:17:38 <spot> okay. i'm opening the floor briefly.
17:17:42 <spot> #topic Open Floor
17:17:52 <tibbs|h> I think the octave questions we had have all been answered.
17:17:58 <spot> tibbs|h: oh?
17:18:12 <tibbs|h> Though upstream seems to want to use libexec, and the maintainer doesn't really want to patch in a change.
17:18:21 <racor> As often around this time, I regret having to leave now.
17:18:21 <tibbs|h> So something of an impasse there.
17:18:34 <tibbs|h> spot: Yes, he posted answers to everything we had asked in the ticket.
17:19:07 <spot> well, i can't blame him for not wanting to carry that patch
17:19:21 <spot> my instinct is to +1 this (with the XXX line removed)
17:19:34 <tibbs|h> Right, that's just how I patched in the questions.
17:19:46 <tibbs|h> But, do we care about the libexec misusage?
17:19:56 <tibbs|h> I suspect that racor would were he still around.
17:20:02 <spot> we care, we asked upstream to fix it, they aren't willing.
17:20:32 <spot> either we require the maintainer to fork the behavior forever and ever, or we note that octave is retar^Wspecial
17:20:33 <tibbs|h> Well, sure, but in the past we've then had it patched.
17:20:47 <tibbs|h> I recall that we didn't allow, say, mono to be special.
17:20:58 <spot> well, actually, we did let mono do some rather odd things
17:21:08 <spot> just not the most obscene items
17:21:39 <abadger1999> How does debian deal with this?
17:21:45 <abadger1999> they don't use libexec so...
17:21:47 <tibbs|h> They patch octave.
17:22:04 <abadger1999> otoh, they don't have the /usr/lib /usr/lib64 split
17:22:22 <tibbs|h> Correct, though since multilib isn't an issue, that's not really an issue either.
17:22:33 <spot> well, if debian is patching octave, then we'd be in good company here.
17:22:36 <tibbs|h> It just gets patched differently depending on which arch it's building on.
17:22:37 <abadger1999> it could be as simple as %{configure} --libexecdir=%{_libdir}
17:23:02 <tibbs|h> http://octave.1599824.n4.nabble.com/libexec-for-packages-td3334700.html
17:23:32 <tibbs|h> The proposed patch is there.
17:23:47 <spot> doesn't look like upstream replied at all
17:24:04 <tibbs|h> No, they don't seem to care about the issue.
17:24:47 <spot> okay, so since we do care about this, and debian cares, how about we just have him patch it? the patchset doesn't look horrible.
17:25:13 <tibbs|h> A possibly better archive is at https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-March/023344.html
17:25:25 <tibbs|h> I think he's leaving it up to us as to what he should do.
17:25:52 <tibbs|h> But obviously carrying around another patch is undesirable in genera.
17:26:04 <tibbs|h> I don't know how to look at debian patches to make sure that's what they're doing.
17:26:08 <rdieter_work> in a perfect world, I'd prefer to hear *some* sort of feedback from upstream, before deciding anything.
17:26:15 <spot> i doubt that debian is doing it like that
17:26:29 <spot> but they might be, who knows?
17:26:38 <spot> they're not trying to account for arch conflicts
17:26:42 <spot> so they might be using libdir
17:27:26 <spot> okay, well, we'll talk about this next week
17:27:29 <spot> we're out of time
17:27:31 <spot> thanks everyone
17:27:37 <spot> #endmeeting