17:02:18 #startmeeting FESCo meeting 20091211 17:02:18 Meeting started Fri Dec 11 17:02:18 2009 UTC. The chair is jds2001. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:18 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:29 #meetingname fesco 17:02:29 The meeting name has been set to 'fesco' 17:02:33 #chair dgilmore dwmw2 notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:02:33 Current chairs: Kevin_Kofler dgilmore dwmw2 j-rod jds2001 nirik notting sharkcz skvidal 17:02:42 * nirik is here. 17:02:46 * sharkcz is here 17:02:50 jds2001: I'm in the middle of making sure out mail will work for the phx move 17:02:58 jds2001: so I'm "here" but not very responsive 17:03:03 np 17:03:11 hello hello 17:03:18 the mail getting through is more important :D 17:03:26 Present. 17:03:26 sorry, was grabbing lunch 17:03:36 np 17:03:36 Hello 17:03:52 * jds2001 got a little busy with $DAYJOB and missed noon on the dot :) 17:04:08 anyhow.... 17:04:24 #topic provenpackager request - rakesh pandit 17:04:24 * j-rod tardy 17:04:39 j-rod: i was too, dont feel lonesome :) 17:04:51 +1 17:05:00 .fesco 284 17:05:01 jds2001: #284 (request for provenpackager - Rakesh Pandit (rakesh)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/284 17:05:03 oops 17:05:20 +1 here. ;) rakesh does good work. 17:05:59 +1. no objections 17:06:06 +1 no objections 17:06:09 +1; feedback was positive on the list 17:06:14 +1 17:06:40 #agreed rakesh provenpackager membership is approved. 17:06:54 #topic provenpackager request - sdz 17:07:03 .fesco 267 17:07:04 jds2001: #267 (Proven packager request - Sebastian Dziallas) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/267 17:07:13 +1, makes sense, doing good work 17:07:18 +1 17:07:23 I failed here....forgot to put it on the agenda after sending it to the list :( 17:07:26 +1 17:07:27 +1, no brainer. 17:07:29 +! 17:07:31 +1 17:07:47 #agreed sdz provenpackager membership is approved 17:07:59 +1 here too 17:08:00 #topic man pages guidelines 17:08:01 For the record, +1 to both the provenpackager requests from me too. 17:08:03 .fesco 291 17:08:04 jds2001: #291 (Man pages Packaging Guideline) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/291 17:08:22 * jds2001 is not sure what she's after 17:08:30 ivana: ping 17:08:32 spot, abadger1999 and I talked about this 17:08:50 Something like Debian's "all binaries need manpages" rule, but only for stuff in /bin and /sbin, not /usr/bin, /usr/sbin and the like. 17:08:55 * abadger1999 can help here 17:09:05 (Debian requires it even for GUI programs in /usr/bin, that's quite silly.) 17:09:12 I think it's nice to have man pages, but I think requiring them is a bit much. 17:09:30 -1 if we are going to mandate man pages it should be for everything 17:09:47 especially if upstream doesnt provide them 17:09:58 Well, -1 to dgilmore's proposal for sure! ;-) 17:10:02 we should *encourage* the practice, but far be it from us to dictate it. 17:10:19 Just for /bin and /sbin stuff is more realistic. 17:10:23 jds2001: i fully agree we should encourage it. 17:10:25 Those are commands designed to be used on the command line. 17:10:27 so, what should we do to encourage it? 17:10:33 make it a 'should' item in the packaging guidelines? 17:10:42 i personally run --help much much more than man 17:10:44 Maybe a better formulation would be that command-line tools need manpages? 17:10:46 Kevin_Kofler: That's what she wants. FPC decided that requiring that would need to either be a FESCo mandated policy ("Allprograms in /usr/bin should have a man page") or a tips and tricks item. 17:10:46 have a resource for people writing them? 17:10:47 notting: +1 17:10:49 Just like GUI tools need menu entries. 17:11:25 GUI programs generally have their own way to provide documentation. 17:11:34 a desktop file is much easier than a man page to whip up 17:11:41 (e.g. yelp, khelpcenter etc.) 17:11:50 notting: making it a should item would help 17:11:56 Though KDE upstream recently started shipping manpages for everything, contributed by the Debian folks. 17:12:01 Those manpages are quite useless though. 17:12:08 many man pages are. 17:12:17 Kevin_Kofler: thats what you get when you force the issue 17:12:27 They usually just repeat the options common to all KDE apps (handled by Qt or kdelibs) and add a one-line description of the application. 17:12:39 especially the 'this is the man page for foo, see 'info foo' for content' which many of the gnu utils have. 17:12:49 Yeah, that's really silly too. 17:13:04 people spit out crap to satisfy some requirement 17:13:12 I would be ok adding a SHOULD or a tips on it, but I am -1 for making it a requirement. 17:13:17 dgilmore: Indeed. 17:13:38 nirik: i'm +1 on that 17:13:50 a SHOULD item is +1 for me 17:14:05 Could we specify the exact formulation of the SHOULD item? 17:14:10 +1 to nirik's proposal (or what it notting's? :) ) to add it as a SHOULD guideline 17:14:24 from the ticket: "The binaries and scripts which are in /bin and /sbin directories should have man page which describes their behaviour." 17:14:33 Kevin_Kofler: executables should have a man page 17:14:40 Here's the summary of why FPC rejected it: https://www.redhat.com/archives/fedora-packaging/2009-December/msg00004.html 17:15:01 I'd write something like "Executables designed to be used from the command line SHOULD have a man page which describes their behavior." 17:15:13 -1 for making a man page a hard req, fine with a SHOULD 17:15:18 * j-rod going mobile... back in a few moments... 17:15:39 We can add something like "(usually the ones located in /bin or /sbin)" if you think it's useful. 17:15:47 I don't think basing this on location only is that great. 17:15:56 There are command-line tools in /usr/bin too. 17:15:57 or add "If your package does not, work with upstream to add man pages" 17:16:10 nirik: That too. 17:16:37 nirik: + coordinate with other distros 17:16:52 In any case, I'm +1 to the idea to a SHOULD (though I think we'd better flesh out the exact text ASAP), 0 to a MUST for /bin and /sbin, -1 to a global MUST. 17:17:33 gui apps can have command line flags. i think a simple. "executable files should have man pages" is enough 17:17:57 Even if the man page says "This application has no command-line options."? :-/ 17:18:00 i'm +1 to the combination of Kevin_Kofler and nirik's writeup there 17:18:11 dgilmore, would it not be reasonable to say here's what you should have as well? 17:18:20 Kevin_Kofler: if that is the man page its a waste of time and effort to do it 17:18:33 Maybe we should be specific on what a manpage should contain. 17:18:57 Otherwise we get tons of "No options. Consult Help / Index for usage help." "manpages". 17:19:02 rjune: i dont understand what your trying to say? 17:19:09 * nirik notes you can't legislate common sense, and getting too detailed tries to do that 17:19:13 dgilmore, what Kevin_Kofler just said. 17:19:25 There's already a fairly established convention of what should be in a man page. it's more than *just* command line options 17:19:46 i dont think we need to codify that 17:20:05 SHOULD: your package should contain man pages for command line binaries/scripts. If it doesn't work with upstream to add them. 17:20:32 nirik: i think command line needs removing from there 17:20:46 Please add a comma after "doesn't" to make this sentence LR(1). ;-) 17:21:04 Otherwise, when you read it, you first misparse it and then have to reread it. 17:21:05 SHOULD: your package should contain man pages for binaries/scripts. If it doesn't work with upstream to add them where they make sense. 17:21:14 SHOULD: your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense. 17:21:18 +1 17:21:26 +1 17:21:29 nirik: +1 for the last proposal 17:21:37 +1 17:22:08 +1 17:22:29 #agreed add to packaging guidelines SHOULD: your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense. 17:22:48 #topic better hostname feature 17:22:55 .fesco 278 17:22:56 jds2001: #278 (Better Hostname - https://fedoraproject.org/wiki/Features/BetterHostname) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/278 17:23:00 * j-rod_ back... 17:23:26 * jds2001 failed a bit and hasnt had the time to read what i should have on this feature as i recall from the last meeting 17:23:28 * nirik is confused where we are with this. 17:23:34 didn't we pass it? 17:24:10 Last Time, on FESCo... i believe we left this unpassed waiting for responses to questions on the discussion page 17:24:18 * j-rod_ vaguely recalls discussing already 17:24:28 * nirik nods. At least 2 times. 17:24:47 there were two comments added since then 17:24:47 * dgilmore still does not see what good it does for us 17:24:57 * jds2001 sees current comments on the discussion page and no answers :( 17:25:14 well current as of 11/20 :( 17:26:34 simo's question is probably the most important unanswered question. 17:26:56 defer yet again? 17:27:21 yeah :( 17:27:32 we can vote and defer, if we can't come to an agreement? 17:27:38 maybe add some more questions to the page too ? 17:27:47 vote and defer? 17:27:52 vote *to* defer? 17:27:54 there wasn't exactly much to answer there, I think 17:28:15 jds2001: misplaced comment 17:28:18 vote, and defer if... 17:28:22 anyway, both david and I are busy with other things atm, so it doesn't hurt to defer it 17:28:59 mclasen: simo asked a "what's the point?" question like dgilmore did here, and went on to ask about security implications. 17:29:24 And to this date, his question got no answer. 17:29:48 see above 17:30:11 ok 17:30:34 #agreed the better hostname feature is deferred as there are unanswered questions on the talk page 17:30:45 #topic color management 17:30:49 .fesco 292 17:30:50 jds2001: #292 (Color Management - https://fedoraproject.org/wiki/Features/ColorManagement) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/292 17:31:29 the spelling of this feature needs correcting 17:31:36 its Colour 17:31:39 ha. 17:31:52 dgilmore: i think not :D 17:31:58 +1 dgilmore 17:32:05 dgilmore: hughsie's a brit. if he wants to spell it without a 'u', i have to take him at his word 17:32:25 notting: hes a pom, they get everything wrong ;) 17:32:53 shall we move on to the actual feature, rather than the spelling of it? :) 17:33:04 * mclasen notes that all the u's got moved over to udisks, upower, etc 17:33:11 having worked in environments where colour was critical to be correct I understand the importance of this feature. +! from me 17:33:16 * nirik is +1 here, it seems something that was lacking before and would be nice to tout. 17:33:23 mclasen: hey now, that's a different flamewar 17:33:34 * notting is +1 to gnome-color-manager 17:33:39 +1 17:33:40 +1 17:33:50 +1 17:34:07 #agreed gnome-COLOR-manager feature is approved 17:34:08 :) 17:34:08 +1 to this, nice new feature. 17:34:16 Now we just need a KDE version. ;-) 17:34:29 convince someone to write one :) 17:34:35 Kevin_Kofler: get coding 17:34:57 #topic Moblin 2.2 17:35:04 .fesco 293 17:35:05 jds2001: #293 (Moblin 2.2 - https://fedoraproject.org/wiki/Features/Moblin-2.2) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/293 17:35:14 auto-desktop-env-refresh +1 17:35:34 +1 17:35:49 +1 17:35:55 +1 17:35:55 +1 17:35:58 +1 17:36:01 #agreed Moblin 2.2 feature is accepted 17:36:09 #topic SSSD by default 17:36:12 * notting is mildly curious what 'moblin app install' does, but that's not a fesco issue 17:36:12 .fesco 294 17:36:15 jds2001: #294 (SSSD by default - https://fedoraproject.org/wiki/Features/SSSDByDefault) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/294 17:36:27 * sgallagh is present to represent the SSSD team 17:36:34 notting: pbrobinson would be happy to answer, im sure :) 17:36:49 i'm in favor of fedora providing ssds to everyone by default. oh wait. 17:37:03 notting: I guess app-install is yet another package manager GUI. 17:37:23 notting: That would be nice, but unfortunately your dyslexia is showing :( 17:37:52 darn! I wanted a free ssd! 17:38:03 :) 17:38:22 at any rate, +1 to SSSD by default. 17:38:32 +1 to sssd as long as it doesnt break other auth methods its long overdue 17:38:37 sgallagh: really dumb question. it allows for offline use, but only if that user has logged in over the network already? 17:38:45 notting: Well, yes 17:39:01 sgallagh: (i.e., it caches credentials, not directory information) 17:39:01 * jds2001 doesnt see how it could work any other way :D 17:39:26 so this is only really by default if you choose network login at firstboot time. 17:39:27 sgallagh: so it wont suck down all users auths. but will cache auth credentials of user who logged in while online 17:39:33 * notting is +1 17:39:34 jds2001: Well, with the right ACLs, we could theoretically mirror the LDAP server locally, but that's ridiculous 17:39:45 dgilmore: Exactly correct 17:39:46 nirik: 'default' refers to it being installed by default, I guess ? 17:40:08 nirik: By default I really meant "Available on all installations" 17:40:28 * nirik is +1. 17:40:30 sgallagh: what does the service do, if anything, if you don't check that button in authoconfig? 17:40:33 Are our live spins expected to ship this? How much space does it take? 17:40:34 mclasen: yeah. 17:40:47 * nirik assumes it would be added to base/core/something? 17:40:56 notting: It wastes about a megabyte of disk space, but nothing else 17:41:07 I think we can spare 1 MB. 17:41:17 +1 17:41:20 +1 to this feature. 17:41:57 sgallagh: quick question. does this conflict with nscd? 17:42:10 * dgilmore breifly looked into it a few months back 17:42:14 +1, nice new shiny 17:42:26 dgilmore: It should not conflict, though with NSCD turned on, it may interfere with configured SSSD timeouts. 17:42:40 So you may not get the exact set of cache updates you expect. 17:42:44 sgallagh: thats what i thought 17:42:56 #agreed SSSD feature is accpeted 17:43:06 sgallagh: but the config gui could disable nscd when sssd is enabled 17:43:50 dgilmore: Well, better would be to leave nscd running and just reconfigure nscd not to function for users and groups 17:44:03 That way it could remain running for other maps, if they are in use 17:44:07 sgallagh: :) that would work also 17:44:14 #topic mono strong name key 17:44:19 .fesco 295 17:44:23 jds2001: #295 (Provide system mono strong name key) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/295 17:44:26 dgilmore: I will open an RFE against authconfig 17:44:46 this just looks like another package to me that mono packages would need to BR 17:44:46 so did debian just generate one randomly? do other distros use their own? 17:44:48 sgallagh: thanks. it was a thought that i just had 17:44:59 dgilmore: It's a good one 17:45:47 fwiw, i just did this in rawhide about a week or so ago 17:45:55 its an obvious win, so i just did it. 17:46:06 mono-devel has the key file 17:46:14 spot: works for me 17:46:17 WFM 17:46:22 spot: cool. There was some question about us using a different one that other distros, but not sure how many people would try and copy binaries around anyhow. 17:46:27 The strong name key is a public/private key pair. For some stupid reason, Mono upstream thinks strong cryptography is useful/needed there. :-/ 17:46:34 wait, if spot just did this, why are we discussing it? 17:46:48 notting: not removed from the schedule 17:46:51 It's quite pointless, so Debian just ships the private key they're using, and I guess we're doing so now too. 17:46:53 a ticket was opened? :) 17:47:02 approved/done closed/ move on nothing to see 17:47:04 So IMHO we can close this ticket. 17:47:08 thee's really nothing for us to do here :) 17:47:09 yep 17:47:24 I think it might be worth getting this added to the Mono packaging guidelines though (but that needs to go through FPC). 17:47:26 it's more FPC stuff to fix Mono guidelines, I think 17:47:35 #agreed this has already been done in rawhide. 17:47:37 notting forgiveness is easier to get afterfact 17:47:44 right, but then the binarys won't run on the other distro with the different key? or am I misunderstanding that? 17:47:53 #agreed no action from fesco is required. 17:47:54 I guess someone can just report a bug on that if it's a big deal. ;) 17:48:07 #topic open floor 17:48:16 #info go vote in the fesco elections :) 17:48:29 I have a question about whether an enhamcement might be worthy of a feature page. 17:48:42 jds2001: did you see the conversation in #fedora-devel earlier 17:48:43 sure, what is it? 17:48:51 dgilmore: no.. 17:48:55 * jds2001 goes to look 17:49:10 jds2001: mailing lists. fixed date for moving them. Jan 9th and 10th 17:49:17 Assuming Lougher's patches get accepted I want to get lzma support into squashfs and livecd-creator. 17:49:25 It's not a lot of work. 17:49:34 dgilmore: awesome. 17:49:47 dgilmore: you want me to send out notifications? 17:49:48 dgilmore: excellent. I am still willing to help out with that... let me know if I can do anything on it. 17:49:50 so its just something we need to note 17:49:51 brunowolff: Smaller live images = we can ship more stuff on a CD = great thing = IMHO deserves a feature page. 17:49:57 I wasn't sure if the change to more compact live images would be considered a feature? 17:49:59 jds2001: please do 17:50:08 brunowolff: hm.... is it something the user (or even the spin creator) would notice? 17:50:15 nirik: we should do the renaming of the lists.fp.o ones now that need it 17:50:19 notting: We can put more stuff onto the KDE spin. :-) 17:50:20 nirik: will do 17:50:20 #info Fedora mailing lists will be moved to Fedora Infrastructure on 1/9 and 1/10 17:50:21 dgilmore: sure. 17:50:26 As the games spin maintainer, I'll notice. 17:51:00 Supposedly they'll be a significant size reduction (maybe 20%), but I'll no more in week or two. 17:51:23 I didn't want to right up a feature page if there was no chance of it being announced as a feature. 17:51:37 I am doing the work anyway, so that I can fit more games into the games spin. 17:51:39 IMHO it's worth advertising as a feature. 17:51:47 * nirik isn't sure it's a full on feature... but it should surely be a release note. 17:51:49 brunowolff: it would be a feature. we can either ship smaller livecds or more packages on them 17:51:53 Kevin_Kofler: yeah, but that would be the feature people would notice (KDE: now with more KDE) 17:52:22 It sounds like there is some chance that it would be accepted as a feature, so I'll do the feature page and you 17:52:24 Summary: "Better compression technology (LZMA) allows us to ship more software on our live images." 17:52:32 guys can vote on it later. 17:52:49 brunowolff: sure, get it in and propose it 17:53:04 I will be doing some stuff now to get a jump on things. I'll probably know in a week if the key patches get accepted 17:53:13 upstream. So far it seems likely though. 17:53:17 poelcat would be your guy on the process itself. But I'm sure you know that :) 17:53:28 I think we should just ship the patches. 17:53:45 It's sad to have to wait forever for upstream to accept useful enhancements. :-( 17:53:49 Kevin_Kofler: we try to avoid that. 17:53:55 squashfs-lzma has been there for ages. 17:54:07 and i dont think we'll wait "forever" 17:54:17 We've been missing out on it all this time, and were forced to remove useful apps from our live images (I know the GNOME one also lost some apps over time) to make room. 17:54:21 brunowolff seemed to think it was imminent. 17:54:25 Squashfs-tools already has what's needed there. I have contacted Kyle about that and have permission to 17:54:41 anyhow 17:54:43 start working on that in devel (with some scratch builds for review first). 17:55:35 cool, anything else? 17:55:40 Lougher has posted patches for review on lkml and an updated set this week. 17:56:01 No one seems to be objecting in general, though there wasn't lots of feedback. 17:56:17 I got what I needed. Thanks. 17:57:25 * jds2001 ends the meeting in 30 17:57:58 #endmeeting