16:01:13 <spot> #startmeeting Fedora Packaging Committee
16:01:13 <zodbot> Meeting started Wed Mar  9 16:01:13 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:18 <spot> #meetingname fpc
16:01:18 <zodbot> The meeting name has been set to 'fpc'
16:01:26 <spot> it has been one of those days, i apologize for the late start
16:01:31 <spot> #topic roll call
16:02:24 <tibbs|h> ...
16:02:45 <abadger1999> Hey
16:03:04 <geppetto> here
16:03:16 <limburgher> Here
16:04:15 * spot is here
16:04:37 <geppetto> spot: pretty sure you don't need to roll call yourself ;)
16:05:46 <spot> racor: are you here?
16:05:59 <spot> ping: rdieter_work
16:06:12 <rdieter_work> hola
16:06:39 <spot> okay, this meeting will be fun, thanks in advance for everyone's patience.
16:06:42 <spot> #topic Systemd
16:07:03 <spot> Please bear with me, as I'm going to try to take baby steps here.
16:07:04 <racor> here, was getting a coffee ;)
16:07:07 <tibbs|h> Is the draft currently up to date?
16:07:22 <spot> tibbs|h: hold up a sec, we're not talking the draft right now
16:07:32 <spot> we need to decide something that will affect how we draft
16:07:49 <spot> I sent an email to the packaging list yesterday
16:08:00 <spot> describing three scenarios of "users"
16:08:09 <tibbs|h> Ah, yes.
16:08:15 <limburgher> <nods>
16:08:18 <spot> 1) Users who do a fresh install. They will get an experience with systemd where fewer services start on boot than used to start on boot in Fedora 14.
16:08:24 <spot> 2) Users have customized their runlevel settings, and then upgrade.
16:08:30 <spot> 3) Users who have not customized their runlevel settings, and then upgrade.
16:08:35 <tibbs|h> http://lists.fedoraproject.org/pipermail/packaging/2011-March/007679.html
16:09:05 <spot> Now, if we work the scriptlets to focus on #2, we'll have an adverse affect on #3.
16:09:10 <spot> And vice-versa, to be fair.
16:09:57 <tibbs|h> Personally I think it reasonable to say that updates should handle the common case (no customization) and make the release notes indicate loudly what folks who have customized need to do.
16:10:09 <spot> I proposed a compromise where we focus on #3, but make it possible for users in #2 to do a manual revert from a copy of their old settings
16:10:37 <geppetto> Given that this is Fedora, I'm not sure that it's worth spending time trying to fix #2 … it's a one time-ish thing, and people can fix it
16:10:48 <tibbs|h> How would you record the pre-upgrade state?
16:11:15 <spot> tibbs|h: a tool would be written to record it, a "/bin/sysv2systemd"
16:11:22 <tibbs|h> OK.
16:11:28 <spot> tibbs|h: lennart has expressed some willingness to do that
16:11:56 <tibbs|h> If we can break as much of the "migration" (recording of state, whatever) out of the actual guidelines, I think we can actually move forward.
16:12:44 <limburgher> That would satisfy me.
16:12:59 <abadger1999> geppetto: Note:  it is one-timeish with emphasis on the ish.
16:13:03 <abadger1999> one time per package.
16:13:09 <geppetto> abadger1999: yeh, I know
16:13:17 <tibbs|h> Is there any possible that we can get the regular systemd guidelines approved and worry about the migration case separately?
16:13:19 <geppetto> abadger1999: But I'm hoping that most of the stuff will be done by F16
16:13:26 <abadger1999> But unless we can get people to switch to unit files all in one go.... :-(
16:14:05 <spot> abadger1999: the idea of asking FESCo to make each package without a unit file (that needs one) a beta blocker does have some appeal
16:14:10 <geppetto> abadger1999: Well I'm hoping that "almost everything" will be done in a couple of releases
16:14:28 <abadger1999> Do we want to either ban switching, discourage switching, or asking FESCo to ban switching from sysv to unit files within a release?
16:14:29 <geppetto> spot: For F15?
16:14:30 <spot> but that would be a bit outside of our scope.
16:14:33 <spot> geppetto: yeah
16:14:44 * abadger1999 is not sure
16:14:44 <geppetto> wow … callous :) … I don't mind that though :)
16:15:22 <abadger1999> tibbs|h: No.
16:15:34 <abadger1999> tibbs|h: But we can decide that we don't care about the migration case entirely.
16:15:43 <spot> abadger1999: it seems like we have agreement to focus on #3, with the compromise of recording the state with a tool to help users in #2 manually migrate customized settings
16:15:46 <tibbs|h> Not sure I got my point across.
16:15:47 <abadger1999> <nod>
16:15:50 <geppetto> abadger1999: I would assume we'd want a bunch of proofs, like apache-httpd, mysql, postgres, etc. … but I don't mind spot's idea of everything either :)
16:16:10 <tibbs|h> If we approve the guidelines and leave the migration case to a separate document, new services can go in now.
16:16:18 <abadger1999> ah.
16:16:25 * abadger1999 looks at the latest scriptlets.
16:16:36 <tibbs|h> But that's a different discussion, I think
16:17:08 <tibbs|h> Anyway, if the migration isn't completely automatic then I'd think migration within a release would already be discouraged by existing policy.
16:17:09 <abadger1999> tibbs|h: Yes, that would be possible.
16:17:17 <tibbs|h> But that's fesco policy, not ours.
16:17:35 <abadger1999> %post, %preun, and %postun don't have anything for migration
16:17:47 <abadger1999> %triggerun and %posttriggerun are only migration.
16:18:00 <spot> abadger1999: yep, so perhaps we can get the base guidelines down and work on the migration piece separately
16:19:01 <abadger1999> As long as someone is willing to volunteer for the huge matrix of testing that seems reasonable.
16:19:14 * abadger1999 looks at the whole guidelines to see where we are.
16:19:21 <geppetto> I liked lennart's macro/script idea, instead of pasting the giant scriptlets into each package … but I'm happy to +1 the current draft, just to get it done
16:19:24 <spot> abadger1999: i'll volunteer.
16:19:37 <spot> geppetto: i'd rather worry about that as a secondary effort
16:19:42 * geppetto nods
16:19:44 <abadger1999> spot: Okay, one thing -- the naming section
16:20:02 <abadger1999> geppetto: We had that idea already :-)
16:20:14 <abadger1999> The %triggerun is the biggest section.
16:20:24 <spot> abadger1999: what about the naming section?
16:20:30 <abadger1999> although -- not as big if we go without migration.
16:21:04 <abadger1999> spot: lennart wants apache but you mentioned we need to avoid using the name apache?
16:21:14 <abadger1999> And currently, there's "apache-httpd.service"
16:21:27 <abadger1999> which I don't know if it satisfies hatever legal requirements exist.
16:21:55 <spot> well, there are no legal requirements, but apache.service isn't valid, and the Apache project has yelled at us in the past for that sort of thing
16:22:07 <geppetto> I think that apache-httpd should be fine
16:22:10 <spot> there are lots of "Apache Foo" and "Apache Bar"
16:22:17 <spot> and there are also lots of httpd implementations
16:22:26 <spot> so "apache-httpd" is the most correct solution
16:23:04 * spot basically still feels the naming is correct, and i dont think lennart cares too much as long as there are working service files. :)
16:23:29 <tibbs|h> So we care about length of names?  Because systemctl output is often not useful.
16:23:35 <tibbs|h> fedora-s...t-hack.service, for example.
16:23:43 <abadger1999> spot: Okay. Cool.
16:24:04 <spot> i think if that is a prevalent issue, we should be encouraging bugs on systemctl
16:24:12 <abadger1999> he does care because he wants everyone to use the same unit files.
16:24:13 <spot> rather than mandating length of names
16:24:24 <abadger1999> but I think/hope apache-httpd should satisfy everyone :-)
16:24:26 <tibbs|h> Sure, that's reasonable.
16:24:27 <spot> abadger1999: yes, but i doubt he'd find flaws in the logic there.
16:24:36 <abadger1999> <nod>
16:24:50 <spot> his hope is that upstreams will provide these .service files
16:25:03 <spot> and i doubt strongly that apache upstream would ship httpd.service or apache.service. :)
16:25:13 <geppetto> abadger1999: I doubt that's going to be possible, because some distro. somewhere is going to want to support apache-httpd-1.3 etc. or something
16:25:30 <geppetto> abadger1999: But apache-httpd seems the most likely "common"  choice, IMO
16:25:41 <abadger1999> geppetto: yep.  Lennart's goal, not mine.
16:25:45 * geppetto nods
16:25:46 <spot> i think we might be able to vote on the draft if we put in the updated scriptlets and then work separately on the migration
16:25:59 <abadger1999> Testing first, vote after.
16:26:08 <spot> abadger1999: okay, i'm fine with that.
16:26:23 <spot> but we're not going to test right now.
16:26:26 <tibbs|h> So rip out the trigger bit and replace it with a link to a migration document?
16:26:31 <abadger1999> I'm going to merge the first option from https://fedoraproject.org/wiki/User:Toshio/Systemd_scriptlet_options
16:26:36 <spot> abadger1999: can you send a quick email out when you have made the merge?
16:27:08 <abadger1999> to the page and also pull out the %trigger stuff to a migration section or leave it on the other page.
16:27:09 <geppetto> abadger1999: merge the first option without the triggers, right?
16:27:14 * geppetto nods
16:27:15 <abadger1999> geppetto: Correct.
16:28:06 <spot> okay, when you see abadger1999's email, please test it if you have the cycles
16:28:17 <spot> lets move on
16:28:19 <abadger1999> I have a page of test recipes and ideas too
16:28:26 <abadger1999> https://fedoraproject.org/wiki/User:Toshio/Testing_systemd
16:28:27 <spot> abadger1999: send it in the email. :)
16:28:45 <spot> abadger1999: probably makes sense to send it to packaging@ and cc lennart
16:28:45 <abadger1999> The tester would have to update teh packages there to use the new scriptlets though.
16:28:47 <abadger1999> <nod>
16:28:59 <spot> i have a package that needs updating
16:29:06 <spot> so i can pretty easily test it
16:29:46 <spot> #topic Octave - https://fedorahosted.org/fpc/ticket/61
16:29:55 <abadger1999> Oh -- are we okay to go ahead even if the tool doesn't get writen?
16:30:05 <spot> abadger1999: i'll get lennart to write the tool
16:30:08 <abadger1999> or never mind -- that's going to be a separate vote.
16:30:34 <abadger1999> new packages-only for now.
16:30:46 * abadger1999 reads ctave changes for this week
16:30:48 <spot> tibbs|h: iirc, you were going to talk to orionp ?
16:31:37 <tibbs|h> I updated the draft with three questions but I've been so buried for the past couple of weeks.
16:31:58 <tibbs|h> He was going to ask upstream about whether stuff needed to live in libexec but I'm not sure if he's heard back yet.
16:31:58 <spot> does anyone else have a bit of time to talk to orionp about things?
16:32:06 <spot> ah, okay
16:32:42 <spot> i'll poke him today and let him know we're waiting on him
16:32:53 <tibbs|h> There's a thread at https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-March/023344.html
16:33:19 <tibbs|h> Not much useful discussion, though.
16:33:35 <tibbs|h> That's really the only real question we have open, I think.
16:33:37 <spot> if it works, he may be able to just make the change.
16:33:48 <spot> i'll see if he is willing to make an "executive decision". :)
16:33:51 <tibbs|h> I added three things to the draft, prefixed with XXX.
16:34:07 <spot> we also need clarity on the "unset TERM" section
16:34:23 <tibbs|h> Ah, right.
16:35:24 <tibbs|h> Honestly I don't think that needs to be mentioned at all.  The macros will take care of it either way, and packagers shouldn't need to care.
16:35:33 * abadger1999 notes that libexec is likely optional since debian doesn't have libexec
16:35:48 <abadger1999> Just don't know if it fits our definition of libexec or not.
16:35:56 <tibbs|h> Hmm, can you tell where debian puts the package files?
16:36:06 <tibbs|h> I don't even know how to look at the contents of a debian package.
16:36:07 <Rathann> sorry guys
16:36:28 <Rathann> today was the first day at a new job
16:36:31 <abadger1999> Maybe.... Tradition would have it in /usr/lib/octave/ somewhere but I don't know where to confirm
16:36:44 <spot> Rathann: congrats
16:36:48 <limburgher> Rathann: congrats!
16:36:52 * abadger1999 sees what packages.debian.org has but doesn't think it has file lists
16:37:07 <abadger1999> Rathann: Don't worry about little ole' us then :-)
16:37:11 <spot> abadger1999: i think it does, i knew how to do that once upon a time.
16:37:19 <Rathann> thanks guys
16:37:26 <spot> lets move on, i'll talk to orionp
16:37:39 <spot> #topic Emacs changes - https://fedorahosted.org/fpc/ticket/68
16:37:43 <abadger1999> You are correct
16:38:03 <spot> i note with some irony that i literally just yesterday brought one of my packages into compliance with the old guidelines
16:38:04 <abadger1999> tibbs|h: http://www.debian.org/distrib/packages
16:38:13 <spot> and these new guidelines make that work unnecessary. :)
16:38:34 <spot> so, i am pleased at the change, but frustrated at the timing.
16:38:46 <spot> https://fedoraproject.org/wiki/PackagingDrafts/Emacs
16:39:39 <tibbs|h> With the split of the two cases this is much more readable.
16:39:43 * spot nods
16:40:00 <spot> i'm actually quite happy with this draft, especially with the sectioning
16:40:25 <tibbs|h> I do have to wonder why we make byte compilation mandatory, though.
16:40:37 <limburgher> I could follow this.
16:40:39 <Rathann> s/Case/actual short description/ in the headings would be my suggestion
16:40:46 <tibbs|h> Rathann: +1.
16:41:05 * laxathom here (sorry for the late)
16:41:17 <tibbs|h> But the actual byte compilation is super simple, so it shouldn't be a big deal.
16:41:19 <geppetto> tibbs|h: wouldn't it be a lot slower otherwise?
16:41:38 <tibbs|h> Well, it's slower.
16:41:58 <geppetto> tibbs|h: But, like python, if you run as a normal user you can't save any byte compilation … right?
16:42:01 <tibbs|h> But whether that actually makes much difference is something I'd personally leave to the packager.
16:42:09 * abadger1999 edits for Rathann's points
16:42:13 <spot> or perhaps: "Case I: Package only provides functionality for (X)Emacs" and "Case II: Package also provides auxiliary (X)Emacs files"
16:42:59 <spot> tibbs|h: byte compilation caught a missing dep in the xemacs side for me. :)
16:43:01 <Rathann> sounds good
16:43:28 <tibbs|h> But if you're not subpackaging, deps on other emacs packages would be problematic.
16:43:43 <tibbs|h> But, sure, byte compilation does give at least a bit more actual testing.
16:43:59 <tibbs|h> Anyway, I'm not objecting to it.
16:44:07 <Rathann> how does one find out which of the two emacsen is supported by the add-on?
16:44:19 <tibbs|h> You just have to talk to upstream.
16:44:26 <Rathann> and what to do if it works for both?
16:44:29 <tibbs|h> Or test it out.
16:44:29 <spot> Rathann: in the few cases i've come across, i've either asked or looked at the code and it told me
16:44:54 <spot> Rathann: just byte compile the same file for both and put the result in the right dir.
16:45:04 * spot did it yesterday, it really was pretty simple
16:45:14 <Rathann> ah, so I need to create subpackages for both emacs flavours in that case
16:45:15 <tibbs|h> Right, but do the guidelines actually say that?
16:45:15 <Rathann> ok
16:45:20 <spot> tibbs|h: they do
16:46:07 <geppetto> yeh … in their template for both they might want to do an example byte compile for both … and mv commands, or something … but that's minor, and I'm happy to +1 without
16:46:28 <spot> So, with the improved titles, I'm +1
16:46:34 <geppetto> I think I could work out how to do one without :)
16:46:37 <geppetto> +1
16:46:57 <rdieter_work> +1
16:47:31 <tibbs|h> For the case 2 stuff, is it obvious to everyone that the various numbered things are not mutually exclusive?
16:47:55 <tibbs|h> I.e. that you do both for a .el file that supports both emacses?
16:48:29 <tibbs|h> I just want to make sure that packagers are not confused by that.
16:48:47 * abadger1999 switches to an unordered list
16:49:13 <tibbs|h> Anyway, I'm +1 on this.
16:49:26 * spot sees +4 on the draft
16:49:45 <Rathann> tibbs|h: it's a bit inconsistent with Case I in that respect
16:49:52 * SmootherFrOgZ doesn't have all comment but according to spot's cases +1
16:50:03 <limburgher> +1
16:50:03 <abadger1999> +1
16:50:10 <Rathann> +1
16:50:14 <abadger1999> tibbs|h: https://fedoraproject.org/wiki/PackagingDrafts/Emacs#Manual_byte_compilation
16:50:19 <abadger1999> Updated
16:51:00 <tibbs|h> It is a requirement that all Elsip files are byte compiled and packaged, unless there is a good reason not to, in which case this should be documented with a comment in the spec file.
16:51:01 <tibbs|h> Hmm.
16:51:06 <tibbs|h> He snuck that in.
16:51:19 <abadger1999> actually... I only updated Case1... hmmm
16:51:22 <racor> sorry, I was distracted and couldn't follow ... don't count my vote
16:51:23 <tibbs|h> I just noticed, and I disagree with that.
16:51:44 <abadger1999> tibbs|h: Agreed.
16:52:00 <spot> okay, lets back up.
16:52:01 <abadger1999> If that's intended to be a "not doc" clause
16:52:26 * abadger1999 could read it both ways thouhg
16:52:30 <tibbs|h> My understanding is that he's saying if a tarball includes a .el file, you have to either package it or justify why you're not packaging it.
16:52:33 <Rathann> It'd also be nice to say why we're doing byte-compilation
16:52:44 <tibbs|h> And I don't think we do that for anything else.
16:52:49 <Rathann> i.e. for performance reasons
16:52:52 <spot> tibbs|h: well, the implication is certainly there.
16:53:03 <tibbs|h> Is there a requirement that if upstream ships something, you have to package it?
16:53:15 <Rathann> tibbs|h: I believe there isn't
16:53:17 <limburgher> I don't think so, per the discussion on devel
16:53:23 <tibbs|h> And I believe there shouldn't be any rule like that.
16:53:37 <abadger1999> reading that section in context, it doesn't read like that to me but -- can we clarify it so that it's obvious to others that we don't mean that?
16:54:18 <tibbs|h> emacs fans trying to get all of the mode files to be made available is OK, trying to force that with guidelines isn't really OK in my book.
16:54:34 <tibbs|h> So, how to clarify that?
16:54:42 <Rathann> I read that as "all .el files that you're packaging must be byte-compiled unless there's a good reason not to"
16:54:58 <tibbs|h> That rule I could agree with.
16:55:03 <tibbs|h> But that's not actually what's written.
16:55:03 <spot> well, if we drop "and packaged"
16:55:08 <spot> then that maps up well
16:55:16 <limburgher> tibbs|h: ditto
16:55:45 <spot> perhaps: "It is a requirement that all packaged Elisp files are byte compiled, unless there is a good reason not to,..."
16:56:01 <tibbs|h> +1
16:56:06 <Rathann> +1
16:56:07 <racor> I am sorry and regret, but this meeting doesn't work out for me, I've got to leave.
16:56:33 * spot is just going to make that change
16:57:09 <spot> okay.
16:57:13 <spot> lets vote one last time
16:57:16 <spot> +1
16:57:34 <limburgher> +1
16:57:52 <SmootherFrOgZ> +1
16:57:55 <tibbs|h> +1, though I think a colon is missing:
16:58:04 <tibbs|h> "The following macros are provided to help with this "
16:58:26 <geppetto> +1
16:58:30 <Rathann> +1
16:58:32 <tibbs|h> Fix'd.
16:59:02 <spot> okay, i see +6 here, abadger1999, rdieter_work, wanna vote again?
16:59:04 <Rathann> meh, I think I'll have to fix one of my packages to conform :)
16:59:38 <abadger1999> +1
17:00:02 <rdieter_work> +1
17:00:26 <spot> #action approved with minor changes, already committed: (+1:8, 0:0, -1:0)
17:00:46 <tibbs|h> Wow, we actually had the whole committee here at one time.
17:00:57 <spot> tibbs|h: i can't remember the last time that happened. :)
17:01:16 <spot> Okay, i have one last business item before i open the floor
17:01:22 <spot> #topic Next week's meeting
17:01:32 <spot> Daylight savings time is happening this weekend
17:01:38 <limburgher> Crap.
17:01:42 <spot> so, please remember: we will STILL meet at 1600 UTC
17:02:15 <spot> but that may be different for you depending on where you live. figure it out. :)
17:02:17 <tibbs|h> Actually, DST is happening _for the US only_ this week, right?
17:02:26 <spot> tibbs|h: i think so.
17:02:51 <spot> #topic Open Floor
17:03:05 <tibbs|h> Doesn't matter, anyway, my desktop clock just stays in UTC.
17:03:15 <spot> Oh, btw, lennart is writing the sysv2systemd tool for us now.
17:03:24 <limburgher> Cool.
17:03:45 <spot> if there are no topics in the next, oh, three minutes, i'll close it out.
17:03:49 <tibbs|h> So, basically, that tool can encapsulate as much migration stuff as anyone wants, right?
17:03:53 <abadger1999> I'll be at pycon next week
17:04:01 <spot> abadger1999: have fun!
17:04:16 <abadger1999> wireless is usually good during the hackfest time but if I'm not present, that's why :-)
17:04:23 <spot> tibbs|h: i believe he is only implementing "--save" and "--restore", but hey, FOSS. :)
17:05:00 <tibbs|h> Well, sure, but the point is that if we just call the tool at the appropriate time, further work on migration stuff can happen completely without us caring.
17:05:13 <spot> yep yep.
17:05:33 <tibbs|h> Great.
17:06:07 <tibbs|h> I just have to carve out enough time to get back to my pending package reviews.
17:06:21 <tibbs|h> Fortunately next week is spring break.
17:07:14 <tibbs|h> spot: BTW, I've forgotten the procedure.
17:07:24 <spot> i'm sorry for what?
17:07:30 <tibbs|h> What do I need to do about the guideline change of mine that was approved last week?
17:07:43 <abadger1999> Alright, heading to the airport.
17:07:46 <spot> oh, commit the change, then toss some announcement text in the ticket
17:07:54 <abadger1999> Later all!
17:07:57 <tibbs|h> OK, I'll do that now.
17:07:59 <spot> i'll probably do an announcement today
17:08:02 <Rathann> safe flight, abadger1999 :)
17:08:06 <abadger1999> thanks
17:08:08 <tibbs|h> abadger1999: God tur!
17:08:15 <spot> and with that, i think we're done.
17:08:18 <spot> thanks everyone
17:08:21 <limburgher> thanks!
17:08:21 <spot> #endmeeting