From Fedora Project Wiki
| [Tue Jul 28 2009] [10:01:01] * spot looks around for FPC folks | ||
| [Tue Jul 28 2009] [10:01:41] * SmootherFrOgZ is here | ||
| [Tue Jul 28 2009] [10:01:49] * limburgher is here | ||
| [Tue Jul 28 2009] [10:02:06] <spot>abadger1999, tibbs, rdieter, Rathann|lappy: ping | ||
| [Tue Jul 28 2009] [10:02:14] <abadger1999>spot: pong | ||
| [Tue Jul 28 2009] [10:02:15] <Rathann|lappy>here | ||
| [Tue Jul 28 2009] [10:02:16] <rdieter>pong | ||
| [Tue Jul 28 2009] [10:02:20] <tibbs>Yep. | ||
| [Tue Jul 28 2009] [10:02:39] <spot>okay, thats 7 of 9 (and we weren't expecting hans or ralf) | ||
| [Tue Jul 28 2009] [10:02:40] * nirik notes you can use the handy meeting bot plugin: <a href="https://fedoraproject.org/wiki/Zodbot#Meeting_Functions">https://fedoraproject.org/wiki/Zodbot#Meeting_Functions</a> | ||
| [Tue Jul 28 2009] [10:02:40] <abadger1999>Yay, quorum! | ||
| [Tue Jul 28 2009] [10:03:10] <spot>if someone knows how to work the bot, feel free. | ||
| [Tue Jul 28 2009] [10:03:43] <spot>First item on the agenda: Moving the meeting time to Wednesday at 1600 UTC | ||
| [Tue Jul 28 2009] [10:03:58] <spot>Anyone opposed to this? This is your last chance. :) | ||
| [Tue Jul 28 2009] [10:04:03] <limburgher>+1 | ||
| [Tue Jul 28 2009] [10:04:21] <spot>+1 from me | ||
| [Tue Jul 28 2009] [10:04:29] <SmootherFrOgZ>+1 | ||
| [Tue Jul 28 2009] [10:04:29] <Rathann|lappy>+1 | ||
| [Tue Jul 28 2009] [10:04:32] <tibbs>No objection here. | ||
| [Tue Jul 28 2009] [10:04:40] <tibbs>I don't have a preference. | ||
| [Tue Jul 28 2009] [10:05:09] Nickstickster_food is now known as stickster. | ||
| [Tue Jul 28 2009] [10:05:11] <abadger1999>+1 | ||
| [Tue Jul 28 2009] [10:05:33] <spot>hopefully that will get us everyone in future meetings, and more regular quorum | ||
| [Tue Jul 28 2009] [10:05:52] <spot>Next item: Our new member | ||
| [Tue Jul 28 2009] [10:06:18] <spot>As announced several places, I asked Jon Ciesla to fill our open seat and he agreed. | ||
| [Tue Jul 28 2009] [10:06:25] * limburgher <waves> | ||
| [Tue Jul 28 2009] [10:06:43] <spot>Now, lets get down to the fun stuff. | ||
| [Tue Jul 28 2009] [10:06:49] <rdieter>sucker... err, welcome. | ||
| [Tue Jul 28 2009] [10:06:56] <spot>Dos2Unix: <a href="https://fedoraproject.org/wiki/PackagingDrafts/Dos2unix">https://fedoraproject.org/wiki/PackagingDrafts/Dos2unix</a> | ||
| [Tue Jul 28 2009] [10:07:04] <SmootherFrOgZ>we have another open seat btw | ||
| [Tue Jul 28 2009] [10:07:27] <tibbs>We should certainly not be worrying about FC3 compatibility. | ||
| [Tue Jul 28 2009] [10:07:33] <spot>SmootherFrOgZ: well, hans offered his seat up, but i want to see if he can make it at the new time first | ||
| [Tue Jul 28 2009] [10:07:44] <SmootherFrOgZ>spot: ok | ||
| [Tue Jul 28 2009] [10:07:48] <limburgher>FC3 has gone to a nice family with a farm. What about EL-4 for EPEL? Does d2u work there? | ||
| [Tue Jul 28 2009] [10:08:03] <tibbs>That would be EPEL's issue, though. | ||
| [Tue Jul 28 2009] [10:08:19] <limburgher>Does EPEL have it's own guidelines? | ||
| [Tue Jul 28 2009] [10:08:30] <abadger1999>EPEL shares our guidelines. | ||
| [Tue Jul 28 2009] [10:08:43] <spot>No, but last meeting we briefly discussed that there might be merit in making a "EPEL-only" section of the guidelines | ||
| [Tue Jul 28 2009] [10:08:50] <spot>and moving all of the EPEL specific items there | ||
| [Tue Jul 28 2009] [10:08:54] <limburgher>Ergo, might not a small mention of EL-4 be warranted, until RHEL4 EOL? | ||
| [Tue Jul 28 2009] [10:08:55] <SmootherFrOgZ>nod | ||
| [Tue Jul 28 2009] [10:09:03] <abadger1999>nirik: Do you know if EPEL would be interested in having a supplemental Guidelines section? | ||
| [Tue Jul 28 2009] [10:09:05] <limburgher>spot: Good idea. | ||
| [Tue Jul 28 2009] [10:09:37] <nirik>we could... | ||
| [Tue Jul 28 2009] [10:09:44] <SmootherFrOgZ>abadger1999: we haven't got meeting last time to discuss about that clearly | ||
| [Tue Jul 28 2009] [10:10:12] <spot>So, in addition to that draft, this could be the first item in the new Packaging/EPEL page | ||
| [Tue Jul 28 2009] [10:10:28] * nirik doesn't care too much... we should try and keep it as small as possible tho. ;) | ||
| [Tue Jul 28 2009] [10:10:34] <abadger1999>I don't care whether we note differences in the Fedora Guidelines or in a separate page... Just update teh main body to what's in Fedora. | ||
| [Tue Jul 28 2009] [10:10:56] <limburgher>nirik: I agree, I'd ideally like them to diverge only where necessary. | ||
| [Tue Jul 28 2009] [10:11:03] * spot nods in agreement | ||
| [Tue Jul 28 2009] [10:11:08] * limburgher nods | ||
| [Tue Jul 28 2009] [10:11:28] <spot>So, lets vote on this one: Draft + mention on Packaging/EPEL for EL-4 | ||
| [Tue Jul 28 2009] [10:11:44] <SmootherFrOgZ>+1 | ||
| [Tue Jul 28 2009] [10:11:45] <rdieter>+1 | ||
| [Tue Jul 28 2009] [10:11:49] <spot>+1 | ||
| [Tue Jul 28 2009] [10:11:49] <Rathann|lappy>+1 | ||
| [Tue Jul 28 2009] [10:11:59] <tibbs>+1 to the draft. | ||
| [Tue Jul 28 2009] [10:12:01] <limburgher>+1 | ||
| [Tue Jul 28 2009] [10:12:11] <tibbs>I'm not sure we actually know there's an issue with EL-4, though. | ||
| [Tue Jul 28 2009] [10:12:25] <spot>tibbs: i'll word it so that it is mentioned as a potential issue | ||
| [Tue Jul 28 2009] [10:12:42] <abadger1999>+1 | ||
| [Tue Jul 28 2009] [10:12:47] <limburgher>Maybe someone could test, and report back? | ||
| [Tue Jul 28 2009] [10:13:18] <spot>if memory serves, it was a combination of plague and dos2unix, but that was eons ago | ||
| [Tue Jul 28 2009] [10:13:41] <limburgher>Should be moot, then, since it's koji all the way down. | ||
| [Tue Jul 28 2009] [10:13:50] <spot>anyways, the draft passes and i'll try to test it on RHEL-4 | ||
| [Tue Jul 28 2009] [10:14:10] <spot>Next item: AutoProvides and Requires filtering: <a href="https://fedoraproject.org/wiki/PackagingDrafts/AutoProvidesAndRequiresFiltering">https://fedoraproject.org/wiki/PackagingDrafts/AutoProvidesAndRequiresFiltering</a> | ||
| [Tue Jul 28 2009] [10:15:02] Quitsassmann has left this server (Read error: 113 (No route to host)). | ||
| [Tue Jul 28 2009] [10:15:29] <spot>So, for what it is worth, this seems pretty sane to me. | ||
| [Tue Jul 28 2009] [10:15:39] <spot>We have a lot of packages that are doing this in a ton of different ways | ||
| [Tue Jul 28 2009] [10:15:50] <Rathann|lappy>yes, I read it two weeks ago and it seemed fine | ||
| [Tue Jul 28 2009] [10:15:52] <tibbs>It's true that we need to standardize. | ||
| [Tue Jul 28 2009] [10:16:00] <tibbs>However, didn't Panu have issues with this? | ||
| [Tue Jul 28 2009] [10:16:17] <tibbs>I doubt I'll ever be able to find that message, though. | ||
| [Tue Jul 28 2009] [10:16:27] <limburgher>tibbs: That'd certainly be better than the myriad ways it's down now. | ||
| [Tue Jul 28 2009] [10:16:54] * Rathann|lappy sifts through f-p mail | ||
| [Tue Jul 28 2009] [10:17:00] <tibbs>The issue was disabling the dependency generator. | ||
| [Tue Jul 28 2009] [10:17:05] <spot>i believe his comment was that this could break multilib | ||
| [Tue Jul 28 2009] [10:17:24] <spot>"Multilib-safe filtering mechanism needs to be bolted to the internal dependency generator, patches welcome... " | ||
| [Tue Jul 28 2009] [10:17:52] <Rathann|lappy>yup | ||
| [Tue Jul 28 2009] [10:17:58] <rdieter>but that's also true with the status quo, with or without the guideline | ||
| [Tue Jul 28 2009] [10:18:08] <Rathann|lappy>As a generic filtering mechanism this is a no-go, doing this breaks | ||
| [Tue Jul 28 2009] [10:18:08] <Rathann|lappy>multilib as Fedora uses it | ||
| [Tue Jul 28 2009] [10:18:09] <spot>Which is interesting, because i'd expect that people would be seeing serious issues as is. | ||
| [Tue Jul 28 2009] [10:18:21] <limburgher>rdieter: making this a positive step in the right direction, even if incomplete | ||
| [Tue Jul 28 2009] [10:18:26] <tibbs>Well, currently filtering is hard so people don't do it. | ||
| [Tue Jul 28 2009] [10:18:27] <rdieter>agreed | ||
| [Tue Jul 28 2009] [10:18:32] <Rathann|lappy>well, we've been splitting -libs left and right for some time now | ||
| [Tue Jul 28 2009] [10:18:35] <spot>The draft does say "Be careful of using these macros in a multilib situation, as they may interfere with the "coloring" of elf32/64 executables done internally by RPM to support multilib installs." | ||
| [Tue Jul 28 2009] [10:18:59] <tibbs>The base issue is filtering by noarch Perl packages, which this does help. | ||
| [Tue Jul 28 2009] [10:19:07] <Rathann|lappy>so we're moving towards being able to disable elf coloring altogether | ||
| [Tue Jul 28 2009] [10:19:08] <tibbs>But pushing it as a general mechanism is not a good idea. | ||
| [Tue Jul 28 2009] [10:19:22] <Rathann|lappy>which was a stupid idea from the beginning IMHO | ||
| [Tue Jul 28 2009] [10:19:31] <limburgher>Could we give examples of when this is safe? | ||
| [Tue Jul 28 2009] [10:19:32] <Rathann|lappy>(elf coloring that is) | ||
| [Tue Jul 28 2009] [10:19:46] <spot>i don't want to go too far down the road of disabling elf coloring, thats probably a FESCo or upstream RPM topic | ||
| [Tue Jul 28 2009] [10:20:12] <spot>perhaps we could narrow the scope of these macros to noarch packages? | ||
| [Tue Jul 28 2009] [10:20:17] Quitconstanton has left this server ("Lost terminal"). | ||
| [Tue Jul 28 2009] [10:20:18] <spot>there should be no multilib concerns there | ||
| [Tue Jul 28 2009] [10:20:41] <Rathann|lappy>well, it's useful for disabling redundant provides in dlopenable plugins | ||
| [Tue Jul 28 2009] [10:20:43] <limburgher>spot: If there are, we have bigger problems. . . | ||
| [Tue Jul 28 2009] [10:20:51] <tibbs>That would be reasonable if only to clean up the Perl situation. | ||
| [Tue Jul 28 2009] [10:21:22] <limburgher>Maybe disallow use in -lib packages until multilib is fixed? | ||
| [Tue Jul 28 2009] [10:21:31] <Rathann|lappy>hm, how about restricting it to packages that are not multilibbed? | ||
| [Tue Jul 28 2009] [10:21:40] <Rathann|lappy>for now at least | ||
| [Tue Jul 28 2009] [10:21:46] <tibbs>I had an IRC conversation with cweyl about this a month ago. | ||
| [Tue Jul 28 2009] [10:21:52] <spot>i'm fine with that approach as well. | ||
| [Tue Jul 28 2009] [10:22:30] <tibbs>The thing is, he explicitly wants this for arch-specific packages. | ||
| [Tue Jul 28 2009] [10:22:49] <tibbs>And the disabling of coloring was not an issue at all to him. | ||
| [Tue Jul 28 2009] [10:23:02] <limburgher>arch-specific bin or lib? | ||
| [Tue Jul 28 2009] [10:23:10] * rdieter thinks the warning in the draft is sufficient (for now, until something better comes along) | ||
| [Tue Jul 28 2009] [10:23:24] <abadger1999>is the perl situation for noarch perl packages or for compiled extensions? | ||
| [Tue Jul 28 2009] [10:23:39] <tibbs>Actually it's for both. | ||
| [Tue Jul 28 2009] [10:23:54] <spot>yes, but will any of those compiled extensions be multilib? | ||
| [Tue Jul 28 2009] [10:23:59] <tibbs>But I'm not sure that coloring matters at all for arch-specific Perl packages. | ||
| [Tue Jul 28 2009] [10:24:34] Nickmchua is now known as mchua_mtg. | ||
| [Tue Jul 28 2009] [10:25:11] Nickstickster is now known as stickster_afk. | ||
| [Tue Jul 28 2009] [10:25:20] <tibbs>I'm trying to extract that IRC conversation. | ||
| [Tue Jul 28 2009] [10:26:38] <tibbs><a href="http://fpaste.org/paste/20184">http://fpaste.org/paste/20184</a> | ||
| [Tue Jul 28 2009] [10:26:41] <tibbs>I think that's all of it. | ||
| [Tue Jul 28 2009] [10:26:41] <Rathann|lappy>I'd approve it with the caveat that it can't be used for multilib packages | ||
| [Tue Jul 28 2009] [10:26:46] <spot>So, i propose we let the draft by as is, and if it causes problems, we can always amend it to be only noarch or only non-multilib | ||
| [Tue Jul 28 2009] [10:28:25] <spot>Anyone have thoughts on that? | ||
| [Tue Jul 28 2009] [10:28:34] <spot>Or should we just vote on that? | ||
| [Tue Jul 28 2009] [10:28:44] * Rathann|lappy points to what he said earlier | ||
| [Tue Jul 28 2009] [10:29:02] * limburgher agrees with Rathann. | ||
| [Tue Jul 28 2009] [10:29:13] <tibbs>I guess I just don't know how problematic disabling the coloring can be, outside of statements from people who I trust saying it's a really bad idea. | ||
| [Tue Jul 28 2009] [10:29:28] * limburgher thinks a conservative approach might be safer. | ||
| [Tue Jul 28 2009] [10:29:31] Partoshan has left this channel. | ||
| [Tue Jul 28 2009] [10:29:39] <spot>Anyone got a handy definition of what a "multilib package" is? | ||
| [Tue Jul 28 2009] [10:29:43] <Rathann|lappy>tibbs: IIUC if the binaries are not colored they will conflict | ||
| [Tue Jul 28 2009] [10:29:58] <tibbs>spot: I'm not sure anyone really knows. | ||
| [Tue Jul 28 2009] [10:30:16] <Rathann|lappy>spot: in this context, I think a package which contains binaries and is present in the x86_64 in both i586 and x86_64 flavours | ||
| [Tue Jul 28 2009] [10:30:19] <rdieter>one reason why the caveat, at this time, is probably not a good idea | ||
| [Tue Jul 28 2009] [10:30:40] <limburgher>rdieter: i.e it being potentially confusing? | ||
| [Tue Jul 28 2009] [10:30:42] <Rathann|lappy>*present in the x86_64 repo | ||
| [Tue Jul 28 2009] [10:30:45] <rdieter>limburgher: yes | ||
| [Tue Jul 28 2009] [10:30:54] <tibbs>f13 knows, I believe. | ||
| [Tue Jul 28 2009] [10:30:55] <spot>Rathann|lappy: yes, but something has to determine whether it ends up in the repo or not | ||
| [Tue Jul 28 2009] [10:30:56] <f13>hi | ||
| [Tue Jul 28 2009] [10:31:01] <f13>ok, so here is what happens | ||
| [Tue Jul 28 2009] [10:31:03] <abadger1999>We could whitelist instead. | ||
| [Tue Jul 28 2009] [10:31:05] <f13>mash is used to make the repos | ||
| [Tue Jul 28 2009] [10:31:12] NickPikachu_2015 is now known as Pikachu_2014. | ||
| [Tue Jul 28 2009] [10:31:19] <f13>mash knows about which base arches are capable of multilib | ||
| [Tue Jul 28 2009] [10:31:24] <f13>namely, x86_64 and ppc | ||
| [Tue Jul 28 2009] [10:31:42] <f13>when mash goes to make a repo and multilib is turned on, mash will put the entire x86_64 packages set in, plus the entire i386 package set. | ||
| [Tue Jul 28 2009] [10:31:46] <f13>it will then make repodata | ||
| [Tue Jul 28 2009] [10:32:00] <Rathann|lappy>spot: basically all packages with binary libraries which have -devel are multilib'd IIRC | ||
| [Tue Jul 28 2009] [10:32:02] <f13>then it creates a transaction set, and adds into this set various i386 packages based on an algorithm | ||
| [Tue Jul 28 2009] [10:32:14] <f13>this algorithm starts with a few hardcoded packages | ||
| [Tue Jul 28 2009] [10:32:21] <f13>then can add anything that puts a library in the standard path | ||
| [Tue Jul 28 2009] [10:32:26] <f13>and anything with a -devel subpackage | ||
| [Tue Jul 28 2009] [10:32:47] <f13>then a few more things like pam modules, gnome theme libraries, kde things | ||
| [Tue Jul 28 2009] [10:32:59] <f13>It will then depsolve the transaction set to pull in any deps of the things it added | ||
| [Tue Jul 28 2009] [10:33:12] <f13>Anything left that is not in the depsolved transaction set gets purged | ||
| [Tue Jul 28 2009] [10:33:15] <rdieter>yeah, not confusing at all. :) | ||
| [Tue Jul 28 2009] [10:33:17] <spot>So, is it safe to say that a "multilib-capable" package is a architecture specific package that contains libraries in the system path? | ||
| [Tue Jul 28 2009] [10:33:28] <notting>spot: yes. | ||
| [Tue Jul 28 2009] [10:33:34] <f13>spot: or a dep thereof | ||
| [Tue Jul 28 2009] [10:33:58] <spot>f13: yes, but if a dep doesn't have system libraries and it loses coloring, do we care? | ||
| [Tue Jul 28 2009] [10:34:00] <f13>with a few whitelist/blacklist exceptions | ||
| [Tue Jul 28 2009] [10:34:10] <f13>spot: I don't think so. | ||
| [Tue Jul 28 2009] [10:34:13] <notting>those who really care about the guts can read <a href="http://tinyurl.com/nmbygc">http://tinyurl.com/nmbygc</a> | ||
| [Tue Jul 28 2009] [10:34:13] <Rathann|lappy>spot however, the only packages that would cause problems with internal dep gen disabled are the ones which apart from the libs have binaries too | ||
| [Tue Jul 28 2009] [10:34:38] <spot>Rathann|lappy: okay, i see. | ||
| [Tue Jul 28 2009] [10:34:44] <f13><a href="http://git.fedorahosted.org/git/?p=mash;a=blob;f=mash/multilib.py">http://git.fedorahosted.org/git/?p=mash;a=blob;f=mash/multilib.py</a> is the gory details. | ||
| [Tue Jul 28 2009] [10:34:51] <Rathann|lappy>and we've been working on splitting those for a long time | ||
| [Tue Jul 28 2009] [10:35:01] <spot>So, a multilib-capable package is thus defined as "an architecture specific package with system libraries or binaries" | ||
| [Tue Jul 28 2009] [10:35:02] Quitopenpercept has left this server (Remote closed the connection). | ||
| [Tue Jul 28 2009] [10:35:32] <spot>Which simplifies down to "an architecture specific package" | ||
| [Tue Jul 28 2009] [10:36:03] <limburgher>And if someone forgets to noarch something, this would fail gracefully, I suspect. | ||
| [Tue Jul 28 2009] [10:36:03] <spot>well, maybe not. | ||
| [Tue Jul 28 2009] [10:36:10] <tibbs>Isn't it "with system libraries _and_ binaries"? | ||
| [Tue Jul 28 2009] [10:37:07] <f13>tibbs: no, we multilib the -libs packages | ||
| [Tue Jul 28 2009] [10:37:17] <f13>anything that puts a library in a standard path gets tagged as multilib | ||
| [Tue Jul 28 2009] [10:37:22] <abadger1999>f13: But deps may pull in programs? | ||
| [Tue Jul 28 2009] [10:37:31] <Rathann|lappy>f13 unless it doesn't have -libs split | ||
| [Tue Jul 28 2009] [10:37:50] <Rathann|lappy>but as I said we've been splitting those AFAICT | ||
| [Tue Jul 28 2009] [10:37:55] <spot>i suspect we do care about the coloring on deps pulled in that don't have libs | ||
| [Tue Jul 28 2009] [10:38:00] <f13>abadger1999: they may, although a lot of work ahs gone toward splitting out libs so that the base package isn't multilib | ||
| [Tue Jul 28 2009] [10:38:05] <f13>to avoid file level conflicts | ||
| [Tue Jul 28 2009] [10:38:12] <f13>this is where coloring comes in | ||
| [Tue Jul 28 2009] [10:38:25] <f13>when you have two "application" packages that are in a multilib repo | ||
| [Tue Jul 28 2009] [10:38:37] <abadger1999>f13: So any program that gets pulled in should be a packaging bug? | ||
| [Tue Jul 28 2009] [10:38:37] <f13>only the files from the base arch color get laid down | ||
| [Tue Jul 28 2009] [10:38:44] <f13>abadger1999: not necessarily | ||
| [Tue Jul 28 2009] [10:38:56] <f13>abadger1999: it just has to make sure that all the non-colored files don't conflict | ||
| [Tue Jul 28 2009] [10:38:59] <spot>We could word the exception like this: These macros are permitted in use on noarch packages, or packages which do not contain system libraries or binaries in $PATH. | ||
| [Tue Jul 28 2009] [10:39:01] <abadger1999>That's what I'm trying to determine :-) | ||
| [Tue Jul 28 2009] [10:39:11] <f13>things like docs, config files, etc... they all have to match exactly between the archful packages | ||
| [Tue Jul 28 2009] [10:39:12] <spot>That would permit the noarch and arch-specific perl cases. | ||
| [Tue Jul 28 2009] [10:39:36] <spot>It would probably exclude the pigeon example though. | ||
| [Tue Jul 28 2009] [10:39:42] <limburgher>spot: Maybe spell out $PATH, for less experienced packagers? | ||
| [Tue Jul 28 2009] [10:39:44] <Rathann|lappy>spot: s/or binaries/and binaries/ | ||
| [Tue Jul 28 2009] [10:39:56] <spot>Rathann|lappy: i don't think it is an AND | ||
| [Tue Jul 28 2009] [10:39:59] <spot>i think it is an or. | ||
| [Tue Jul 28 2009] [10:40:19] <Rathann|lappy>well if it doesn't have libs then it doesn't get multilibbed | ||
| [Tue Jul 28 2009] [10:40:30] <spot>Rathann|lappy: but it might be pulled in as a dependency | ||
| [Tue Jul 28 2009] [10:40:35] <spot>and if so, we want the binaries colored | ||
| [Tue Jul 28 2009] [10:40:48] <Rathann|lappy>right | ||
| [Tue Jul 28 2009] [10:41:01] <spot>so, a package could have no system libs and binaries in /usr/bin | ||
| [Tue Jul 28 2009] [10:41:06] <Rathann|lappy>it would need some checking | ||
| [Tue Jul 28 2009] [10:41:09] <spot>and we want it to be colored, hence, these macros can't be used | ||
| [Tue Jul 28 2009] [10:41:33] <Rathann|lappy>but sure, better to be extra careful | ||
| [Tue Jul 28 2009] [10:42:11] <spot>limburgher: well, we could say "%{_bindir} or %{_sbindir}" | ||
| [Tue Jul 28 2009] [10:42:25] <spot>i'm not sure we need to define $PATH | ||
| [Tue Jul 28 2009] [10:42:30] <limburgher>spot: Or the lib equivalents. | ||
| [Tue Jul 28 2009] [10:43:05] Nickstickster_afk is now known as stickster. | ||
| [Tue Jul 28 2009] [10:43:21] <spot> These macros are permitted in use on noarch packages, or packages which do not contain system libraries (libraries in %{_libdir}) or binaries in $PATH (/bin, /usr/bin, /sbin, /usr/sbin). | ||
| [Tue Jul 28 2009] [10:43:21] <f13>libexec too? | ||
| [Tue Jul 28 2009] [10:44:10] <spot>f13: for binaries? | ||
| [Tue Jul 28 2009] [10:44:29] <f13>don't a lot of things toss internal binaries there, like plymouth and such? | ||
| [Tue Jul 28 2009] [10:44:34] <Rathann|lappy>libexec can contain binaries, yes, but I'm not sure if there are any multilib packages that put files there | ||
| [Tue Jul 28 2009] [10:44:41] <limburgher>f13: nx, IIRC | ||
| [Tue Jul 28 2009] [10:44:58] <f13>sorry, I'm not helping, I don't even know what's being discussed. | ||
| [Tue Jul 28 2009] [10:45:24] <Rathann|lappy>postfix does, but it's not multilib | ||
| [Tue Jul 28 2009] [10:45:48] <spot>Technically, libexecdir isn't in $PATH | ||
| [Tue Jul 28 2009] [10:45:52] <spot>but it probably should be covered | ||
| [Tue Jul 28 2009] [10:46:01] <Rathann|lappy>yes and yes | ||
| [Tue Jul 28 2009] [10:46:20] <spot>the more i try to work this exception, the more i am inclined to restrict it to noarch until it can be made to work with coloring | ||
| [Tue Jul 28 2009] [10:46:58] <Rathann|lappy>or until colouring goes away, whichever comes sooner :) | ||
| [Tue Jul 28 2009] [10:47:04] <limburgher>spot: That would be the safest and still hit the Perl bits. | ||
| [Tue Jul 28 2009] [10:47:17] <Rathann|lappy>+1 to that | ||
| [Tue Jul 28 2009] [10:47:29] <spot>So, lets vote on this as restricted to noarch packages (it will need a bit of rewording, but i can do it) | ||
| [Tue Jul 28 2009] [10:47:41] <tibbs>+1 | ||
| [Tue Jul 28 2009] [10:47:43] <limburgher>+1 | ||
| [Tue Jul 28 2009] [10:47:48] <Rathann|lappy>+1 | ||
| [Tue Jul 28 2009] [10:47:50] <spot>+1 | ||
| [Tue Jul 28 2009] [10:48:22] <abadger1999>+1 | ||
| [Tue Jul 28 2009] [10:48:29] <rdieter>+1 | ||
| [Tue Jul 28 2009] [10:48:37] <spot>SmootherFrOgZ: want to vote for the record? | ||
| [Tue Jul 28 2009] [10:48:54] <abadger1999>Can we also give cweyl an idea of what needs to be figured out/done to do arched packages too? | ||
| [Tue Jul 28 2009] [10:49:36] <spot>abadger1999: basically, the macros need to retain coloring on items not filtered out | ||
| [Tue Jul 28 2009] [10:50:02] <Rathann|lappy>spot: it's not possible I think or at least not easily done | ||
| [Tue Jul 28 2009] [10:50:09] <SmootherFrOgZ>+! | ||
| [Tue Jul 28 2009] [10:50:15] <tibbs>Unless RPM itself gives us a new mechanism. | ||
| [Tue Jul 28 2009] [10:50:17] <spot>Rathann|lappy: i know it isn't trivial, and probably requires upstream RPM changes | ||
| [Tue Jul 28 2009] [10:50:19] <tibbs>Which would be great. | ||
| [Tue Jul 28 2009] [10:50:21] <SmootherFrOgZ>sorry getting timeout | ||
| [Tue Jul 28 2009] [10:50:43] <tibbs>But it's a matter of working with the rpm devs instead of just working around rpm. | ||
| [Tue Jul 28 2009] [10:50:46] <spot>Panu seemed willing to at least look at patches | ||
| [Tue Jul 28 2009] [10:51:10] <spot>okay, the draft passes with the noarch restriction | ||
| [Tue Jul 28 2009] [10:51:30] <spot>Next item: Explanation of No Bundled Libraries: <a href="https://fedoraproject.org/wiki/No_Bundled_Libraries">https://fedoraproject.org/wiki/No_Bundled_Libraries</a> | ||
| [Tue Jul 28 2009] [10:51:30] <abadger1999>So we wouldn't loosen this to handle arch specific perl modules in any other way? | ||
| [Tue Jul 28 2009] [10:51:38] <spot>abadger1999: nope. | ||
| [Tue Jul 28 2009] [10:51:58] <spot>i know he won't be happy about that, but perhaps it will motivate him to get the coloring working. ;) | ||
| [Tue Jul 28 2009] [10:51:58] <rdieter>I'm ok with it being less strict, but I guess I'm in the minority here | ||
| [Tue Jul 28 2009] [10:52:30] <abadger1999>(and python and ruby and....) | ||
| [Tue Jul 28 2009] [10:52:37] <abadger1999>rdieter: +1 but I don't know how. | ||
| [Tue Jul 28 2009] [10:52:50] <spot>the only other way we could do it is to explicitly permit that perl case, but as abadger1999 points out, it recurses into madness | ||
| [Tue Jul 28 2009] [10:52:59] <tibbs>The only thing you could do is say "don't use it if it breaks something". | ||
| [Tue Jul 28 2009] [10:53:09] <limburgher>A. I think this is great. B. I think it should include info on dir/symlink issues. rdieter, I'm thinkinging about gallery2 here. | ||
| [Tue Jul 28 2009] [10:53:13] <spot>tibbs: yes, but that may not be clear until some poor user hits a multilib case | ||
| [Tue Jul 28 2009] [10:53:16] <abadger1999>spot: Well... not madness... each of those cases is a real reason to filter the dependencies. | ||
| [Tue Jul 28 2009] [10:53:31] <abadger1999>and can cause problems if they aren't filtered. | ||
| [Tue Jul 28 2009] [10:53:58] <spot>well, lets step back to the last item for a moment | ||
| [Tue Jul 28 2009] [10:54:13] <spot>if we could structure an exception for those valid filter cases | ||
| [Tue Jul 28 2009] [10:54:14] <limburgher>re: dir/symlink, the bits in gallery2 as it sits now seem to work, and I've ripped it off^H^H^H^H^H^H^H^used it other places with success. | ||
| [Tue Jul 28 2009] [10:54:17] <spot>what would it say? | ||
| [Tue Jul 28 2009] [10:54:44] <Rathann|lappy>abadger1999: <a href="http://www.redhat.com/archives/fedora-packaging/2009-June/msg00031.html">http://www.redhat.com/archives/fedora-packaging/2009-June/msg00031.html</a> | ||
| [Tue Jul 28 2009] [10:54:49] <spot>arch specific packages with no binaries in $PATH or libexecdir and no system libs in libdir? | ||
| [Tue Jul 28 2009] [10:55:50] * spot notes that packages with a -libs split wouldn't be able to use the macros either | ||
| [Tue Jul 28 2009] [10:56:42] <spot>Does anyone see a problem with also permitting them with "arch specific packages with no binaries in $PATH or libexecdir and no system libs in libdir" ? | ||
| [Tue Jul 28 2009] [10:57:00] <spot>that would cover the remaining perl cases, and some of the python cases. | ||
| [Tue Jul 28 2009] [10:57:38] Partoshan has left this channel. | ||
| [Tue Jul 28 2009] [10:57:46] <tibbs>I see no problems with that; as I understand it there's no interference with any of the cases where coloring is important. | ||
| [Tue Jul 28 2009] [10:57:51] <limburgher>Not off hand. . | ||
| [Tue Jul 28 2009] [10:57:57] <abadger1999>I like that. Do we want to make it clear that subpackages are included? | ||
| [Tue Jul 28 2009] [10:58:19] <Rathann|lappy>well the code that decides if a package should be multilib does look deeper than just libdir | ||
| [Tue Jul 28 2009] [10:58:24] <SmootherFrOgZ>i want | ||
| [Tue Jul 28 2009] [10:58:40] <SmootherFrOgZ>abadger1999: | ||
| [Tue Jul 28 2009] [10:58:49] <Rathann|lappy>abadger1999: yes | ||
| [Tue Jul 28 2009] [10:59:12] <spot>"arch specific packages with no binaries in $PATH or libexecdir and no system libs in libdir. This includes all of the subpackages generated from the spec file." | ||
| [Tue Jul 28 2009] [10:59:54] <spot>abadger1999: does that cover it? | ||
| [Tue Jul 28 2009] [10:59:56] <limburgher>Seems clear. | ||
| [Tue Jul 28 2009] [10:59:56] <abadger1999>Yep. | ||
| [Tue Jul 28 2009] [11:00:05] <abadger1999>+1 | ||
| [Tue Jul 28 2009] [11:00:06] <spot>Okay, lets vote on that additional exception | ||
| [Tue Jul 28 2009] [11:00:10] <tibbs>+1 | ||
| [Tue Jul 28 2009] [11:00:22] <spot>+1 | ||
| [Tue Jul 28 2009] [11:00:22] <limburgher>+1 | ||
| [Tue Jul 28 2009] [11:00:25] <SmootherFrOgZ>+1 | ||
| [Tue Jul 28 2009] [11:00:42] <Rathann|lappy>0, this doesn't cover all the bases IMHO | ||
| [Tue Jul 28 2009] [11:00:43] <spot>Rathann|lappy, rdieter, for the record? :) | ||
| [Tue Jul 28 2009] [11:00:51] <rdieter>+1 | ||
| [Tue Jul 28 2009] [11:01:04] <spot>Rathann|lappy: i think the other bases will require proper coloring support, or disabling coloring | ||
| [Tue Jul 28 2009] [11:01:25] <spot>this is the best we can do for now, until one of those additional conditions is met | ||
| [Tue Jul 28 2009] [11:01:34] <Rathann|lappy>right | ||
| [Tue Jul 28 2009] [11:01:40] <spot>We're now an hour into the meeting. | ||
| [Tue Jul 28 2009] [11:01:48] <spot>we can continue or adjourn to next week | ||
| [Tue Jul 28 2009] [11:01:52] <spot>anyone need to run? | ||
| [Tue Jul 28 2009] [11:01:58] <limburgher>Not urgently | ||
| [Tue Jul 28 2009] [11:01:58] <Rathann|lappy>I do, actually | ||
| [Tue Jul 28 2009] [11:02:02] <tibbs>I'm available. | ||
| [Tue Jul 28 2009] [11:02:04] PartMathStuf__ has left this channel ("Failure: Success!"). | ||
| [Tue Jul 28 2009] [11:02:09] <spot>I can stay | ||
| [Tue Jul 28 2009] [11:02:11] * abadger1999 can stay | ||
| [Tue Jul 28 2009] [11:02:23] <spot>if we retain quorum, lets try to get through a few more | ||
| [Tue Jul 28 2009] [11:02:30] <rdieter>I can stay too | ||
| [Tue Jul 28 2009] [11:02:41] <Rathann|lappy>so sorry guys, see you next week or whenever the next meeting is | ||
| [Tue Jul 28 2009] [11:02:45] <SmootherFrOgZ>i can stay too | ||
| [Tue Jul 28 2009] [11:02:59] <spot>Rathann|lappy: i'll send out an announcement, but it will almost certainly be next week | ||
| [Tue Jul 28 2009] [11:03:21] <spot>okay. Lets try this one again: Explanation of No Bundled Libraries: <a href="https://fedoraproject.org/wiki/No_Bundled_Libraries">https://fedoraproject.org/wiki/No_Bundled_Libraries</a> | ||
| [Tue Jul 28 2009] [11:03:23] QuitRathann|lappy has left this server ("Bye!"). | ||
| [Tue Jul 28 2009] [11:04:00] <tibbs>I don't really know that a justification like this belongs in the guidelines. | ||
| [Tue Jul 28 2009] [11:04:16] <tibbs>I don't disagree with anything that's said there, though. | ||
| [Tue Jul 28 2009] [11:04:33] <spot>We could have it on a separate page, linked from the Review Guidelines, but this information is good and non-obvious to a lot of people. | ||
| [Tue Jul 28 2009] [11:04:45] <spot>So, i'm inclined to just put it in the Packaging/Guidelines | ||
| [Tue Jul 28 2009] [11:05:00] Quitrjune_wrk has left this server (Read error: 104 (Connection reset by peer)). | ||
| [Tue Jul 28 2009] [11:05:06] <spot>(or, as a separate page linked to from both) | ||
| [Tue Jul 28 2009] [11:05:18] <abadger1999><nod> separate page with links. | ||
| [Tue Jul 28 2009] [11:05:27] <limburgher>What about instructions for moving to system libs? | ||
| [Tue Jul 28 2009] [11:05:35] <limburgher>I'm thinking about symlink/dir issues. | ||
| [Tue Jul 28 2009] [11:06:00] <spot>limburgher: can you be more specific? | ||
| [Tue Jul 28 2009] [11:06:00] <rdieter>moving from dir => symlink is the painful one. | ||
| [Tue Jul 28 2009] [11:06:11] <limburgher>spot: The bits in gallery2 that rdieter helped me work up work pretty well. | ||
| [Tue Jul 28 2009] [11:06:25] <limburgher>rdieter: that's what I meant. :) | ||
| [Tue Jul 28 2009] [11:06:34] <spot>they had system lib copies in a separate "local" dir? | ||
| [Tue Jul 28 2009] [11:06:44] <limburgher>Yup. PHP apps do it all the time. | ||
| [Tue Jul 28 2009] [11:06:59] <spot>Perhaps you could work up an addendum to this for that case? | ||
| [Tue Jul 28 2009] [11:07:16] <limburgher>Sure. When do you want it by? | ||
| [Tue Jul 28 2009] [11:07:28] <spot>No rush. I don't think we need to wait for that to approve this. | ||
| [Tue Jul 28 2009] [11:07:49] <limburgher>Agreed. Approve this, and do my addendum later. | ||
| [Tue Jul 28 2009] [11:07:52] <spot>This is correct as is, your addendum would merely flesh out example cases. | ||
| [Tue Jul 28 2009] [11:08:07] <limburgher>Shouldn't take me long, I've been living it for awhile. :) | ||
| [Tue Jul 28 2009] [11:08:14] <spot>limburgher: excellent. | ||
| [Tue Jul 28 2009] [11:08:24] <spot>any other comments before we vote? | ||
| [Tue Jul 28 2009] [11:08:42] <abadger1999>Let's vote | ||
| [Tue Jul 28 2009] [11:09:07] <abadger1999>+1 | ||
| [Tue Jul 28 2009] [11:09:09] <spot>+1 | ||
| [Tue Jul 28 2009] [11:09:09] <limburgher>+1 | ||
| [Tue Jul 28 2009] [11:09:12] <rdieter>+1 | ||
| [Tue Jul 28 2009] [11:09:12] <SmootherFrOgZ>+1 | ||
| [Tue Jul 28 2009] [11:09:47] <tibbs>limburgher: It probably shouldn't be in the guidelines anyway. | ||
| [Tue Jul 28 2009] [11:09:47] <tibbs>We have plenty of tricks and tips pages outside of Packaging:. | ||
| [Tue Jul 28 2009] [11:09:47] <tibbs>Pretty much what PackageMaintainers was set up for. | ||
| [Tue Jul 28 2009] [11:09:53] Quitkital has left this server ("leaving"). | ||
| [Tue Jul 28 2009] [11:09:55] <tibbs>Sorry, I lagged out there. | ||
| [Tue Jul 28 2009] [11:09:59] <spot>tibbs: happens. | ||
| [Tue Jul 28 2009] [11:10:13] <spot>tibbs: want to vote for the record? | ||
| [Tue Jul 28 2009] [11:10:39] <limburgher>tibbs: Right. I don't want to say "do it this way", just "here's a way that works to save you time and profanity" | ||
| [Tue Jul 28 2009] [11:10:59] <spot>Okay, well, i'll assume he will vote on a slight delay. +5, so it passes. | ||
| [Tue Jul 28 2009] [11:11:48] <spot>Next item: Handling of prebuilt binaries: <a href="https://fedoraproject.org/wiki/PackagingDrafts/Removal_of_pre-built_binaries">https://fedoraproject.org/wiki/PackagingDrafts/Removal_of_pre-built_binaries</a> | ||
| [Tue Jul 28 2009] [11:12:09] Quitjosedamiangarrid has left this server ("Leaving."). | ||
| [Tue Jul 28 2009] [11:12:36] <spot>it is notable that there are two separate proposals in there | ||
| [Tue Jul 28 2009] [11:13:29] <spot>For what its worth, i think the secondary proposal is more comprehensive | ||
| [Tue Jul 28 2009] [11:13:33] <rdieter>I don't see much difference offhand. anything significant? | ||
| [Tue Jul 28 2009] [11:13:53] <spot>it covers content binaries, the top one doesn't | ||
| [Tue Jul 28 2009] [11:14:07] <limburgher>Examples given. I the more explicit list. | ||
| [Tue Jul 28 2009] [11:14:09] <spot>specifically, it says you don't need to rebuild .pdf/.png/.ps/.mo | ||
| [Tue Jul 28 2009] [11:14:18] <limburgher>spot: exactly. | ||
| [Tue Jul 28 2009] [11:14:23] <rdieter>ok, better then, yeah | ||
| [Tue Jul 28 2009] [11:14:24] <tibbs>+1 | ||
| [Tue Jul 28 2009] [11:14:42] <spot>tibbs: i'm assuming that is your vote on the previous item? :) | ||
| [Tue Jul 28 2009] [11:15:17] * spot hopes tibbs_ is less lagged. | ||
| [Tue Jul 28 2009] [11:15:25] <tibbs_>I'm coming in through bastion now. | ||
| [Tue Jul 28 2009] [11:15:33] <limburgher>One question. It proposes removing the binaries in %prep. Since we can't verify what they were built from, for legal reasons, isn't a modified tarball safer? | ||
| [Tue Jul 28 2009] [11:15:59] <spot>the only time we have to pull out binaries for legal reasons is when we do not have permission to redistribute them | ||
| [Tue Jul 28 2009] [11:16:05] <spot>or when they violate patents | ||
| [Tue Jul 28 2009] [11:16:11] <tibbs_>I did +1 the previous vote, but I'm not sure if you saw it. | ||
| [Tue Jul 28 2009] [11:16:11] <tibbs_>I don't agree that we should make removal of these files in %prep. | ||
| [Tue Jul 28 2009] [11:16:39] <spot>tibbs_: removing them in %prep ensures that they are not accidentally used in %build | ||
| [Tue Jul 28 2009] [11:16:45] <abadger1999>An issue with the content portion is that fonts currently wants rebuilding from source where the source exists. | ||
| [Tue Jul 28 2009] [11:17:01] <spot>abadger1999: fwiw, we do not treat fonts as content | ||
| [Tue Jul 28 2009] [11:17:08] <tibbs_>I just don't see the point in additional rules about this. | ||
| [Tue Jul 28 2009] [11:17:36] <spot>tibbs_: i think this is a sane clarification of the intent of the existing guidelines | ||
| [Tue Jul 28 2009] [11:17:41] <limburgher>spot: But if they're prebuilt, how do we know we have permission? What if /usr/bin/foo is renamed iexplore.exe? | ||
| [Tue Jul 28 2009] [11:17:45] <tibbs_>I mean, .exe files aren't going to be in the path, and they almost certainly going to be actually runnable anyway. | ||
| [Tue Jul 28 2009] [11:17:52] <tibbs_>So what is the point? | ||
| [Tue Jul 28 2009] [11:17:56] <abadger1999>limburgher: I like to avoid modified tarballs as they make it harder to verify that the tarball corresponds with what was distributed from upstream. | ||
| [Tue Jul 28 2009] [11:18:19] <limburgher>abadger1999: I agree 100%. That's why I yell at upstream when I have to do it. | ||
| [Tue Jul 28 2009] [11:18:34] <spot>limburgher: it is reasonably safe to assume they are under the included license terms from this perspective, unless we have some evidence to the contrary | ||
| [Tue Jul 28 2009] [11:18:58] <limburgher>spot: Putting the onus of avoiding a license violation on upstream, essentially? | ||
| [Tue Jul 28 2009] [11:19:07] <spot>limburgher: pretty much. | ||
| [Tue Jul 28 2009] [11:19:16] <limburgher>spot: i'm thinking of gallery2 again, oddly. :) | ||
| [Tue Jul 28 2009] [11:19:36] <limburgher>spot: Makes me nervous, but you work with Legal moer than I. . . | ||
| [Tue Jul 28 2009] [11:19:42] <limburgher>s/moer/more/ | ||
| [Tue Jul 28 2009] [11:19:58] <spot>well, lemme put it this way | ||
| [Tue Jul 28 2009] [11:20:08] <spot>if i run this past RH Legal, they'll say "nuke them all from orbit to be safe" | ||
| [Tue Jul 28 2009] [11:20:23] <spot>which will cause a LOT of unnecessary tarball rebuilds | ||
| [Tue Jul 28 2009] [11:20:39] <limburgher>Does not RH Legal == necessary? | ||
| [Tue Jul 28 2009] [11:20:49] <spot>but if presented with the specific cases | ||
| [Tue Jul 28 2009] [11:20:51] <limburgher>I know it might be churnful. . . | ||
| [Tue Jul 28 2009] [11:20:57] <rdieter>right, I consider this a bandaid, until upstreams can properly can a cluebat whacking | ||
| [Tue Jul 28 2009] [11:21:02] <spot>in 99% of them, they will say "that's fine, just delete it in %prep" | ||
| [Tue Jul 28 2009] [11:21:29] <spot>and the 1% where they wouldn't are the cases where we clearly don't have permission to redistribute the binary | ||
| [Tue Jul 28 2009] [11:21:42] <spot>or there is a legal factor (e.g. patent) in play | ||
| [Tue Jul 28 2009] [11:21:59] NickDigitalFlux is now known as DigitalFlux-AFK. | ||
| [Tue Jul 28 2009] [11:22:19] <limburgher>So, essentially, %prep says, "they'll fix it in the next release", rebuilt tarball says "AAAHH getitoffmegetitoffme"? | ||
| [Tue Jul 28 2009] [11:22:27] <spot>limburgher: exactly | ||
| [Tue Jul 28 2009] [11:22:33] <limburgher>spot: gotcha | ||
| [Tue Jul 28 2009] [11:22:54] <spot>perhaps some wording could be added to ask the maintainer to notify upstream about removing the binaries from future releases? | ||
| [Tue Jul 28 2009] [11:23:12] <limburgher>spot: That'd do it for me. | ||
| [Tue Jul 28 2009] [11:24:45] <tibbs_>Java folks simply are not going to stop shipping .jars. | ||
| [Tue Jul 28 2009] [11:24:55] Quitkital has left this server ("leaving"). | ||
| [Tue Jul 28 2009] [11:25:12] <limburgher>tibbs_: Tell me about it. | ||
| [Tue Jul 28 2009] [11:25:55] <limburgher>tibbs_: I say, "but I need to build from source" and they look at me like me hair's on fire. Over email. . . | ||
| [Tue Jul 28 2009] [11:26:56] <abadger1999>Updated proposal 2: <a href="https://fedoraproject.org/wiki/PackagingDrafts/Removal_of_pre-built_binaries">https://fedoraproject.org/wiki/PackagingDrafts/Removal_of_pre-built_binaries</a> | ||
| [Tue Jul 28 2009] [11:27:54] <spot>abadger1999: there is one other change that i want to make | ||
| [Tue Jul 28 2009] [11:28:15] <spot>* Some pre-packaged program binaries or program libraries may be under terms which do not permit redistribution, or be affected by legal scenarios such as patents. In such situations, simply deleting these files in %prep is not sufficient, the maintainer will need to make a modified source that does not contain these files. | ||
| [Tue Jul 28 2009] [11:28:19] <spot>Under Exceptions | ||
| [Tue Jul 28 2009] [11:28:37] <limburgher>spot: tips hat | ||
| [Tue Jul 28 2009] [11:29:27] <abadger1999>Added. | ||
| [Tue Jul 28 2009] [11:29:39] <spot>okay, everyone, shall we vote on the revised draft? | ||
| [Tue Jul 28 2009] [11:29:41] <tibbs_>should probably also link to Packaging:SourceURL there as well. | ||
| [Tue Jul 28 2009] [11:30:05] <tibbs_>Specifically, <a href="https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code">https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code</a> | ||
| [Tue Jul 28 2009] [11:30:14] <limburgher>tibbs_ Yes, good catch | ||
| [Tue Jul 28 2009] [11:30:21] <spot>tibbs_: definitely | ||
| [Tue Jul 28 2009] [11:32:01] <spot>okay, lets vote on the revised draft | ||
| [Tue Jul 28 2009] [11:32:03] <spot>+1 from me | ||
| [Tue Jul 28 2009] [11:32:16] <limburgher>+1 | ||
| [Tue Jul 28 2009] [11:32:18] Quitalindebe has left this server (Read error: 110 (Connection timed out)). | ||
| [Tue Jul 28 2009] [11:32:34] <SmootherFrOgZ>i'm fine with this +1 | ||
| [Tue Jul 28 2009] [11:32:44] <rdieter>+1 | ||
| [Tue Jul 28 2009] [11:33:19] <spot>tibbs_, abadger1999? | ||
| [Tue Jul 28 2009] [11:33:28] <abadger1999>+1 | ||
| [Tue Jul 28 2009] [11:34:17] <spot>well, that's +5. I'll assume tibbs is lagged again and will vote sometime in the next 10 minutes. ;) | ||
| [Tue Jul 28 2009] [11:34:19] <tibbs_>I'm still kind of meh on this. | ||
| [Tue Jul 28 2009] [11:34:36] <tibbs_>Not really against it, I just don't see the benefit. | ||
| [Tue Jul 28 2009] [11:35:04] <spot>So, we're now at an hour and a half | ||
| [Tue Jul 28 2009] [11:35:28] <spot>i'm inclined to call it a meeting and pick things up next week | ||
| [Tue Jul 28 2009] [11:35:37] <limburgher>I'm cool either way. | ||
| [Tue Jul 28 2009] [11:35:48] <rdieter>nextweek++ | ||
| [Tue Jul 28 2009] [11:35:56] <SmootherFrOgZ>heh | ||
| [Tue Jul 28 2009] [11:36:00] <tibbs_>So it's 1600Z next Wednesday. | ||
| [Tue Jul 28 2009] [11:36:02] <abadger1999>Either way | ||
| [Tue Jul 28 2009] [11:36:14] <spot>tibbs_: yes | ||
| [Tue Jul 28 2009] [11:36:30] Quitsmooge has left this server ("-ENOCAFFEINE"). | ||
| [Tue Jul 28 2009] [11:37:29] <limburgher>Cool. I assume my draft for the dir/symlink bits should go in PackagingDrafts? | ||
| [Tue Jul 28 2009] [11:37:52] <tibbs_>Don't see why you just wouldn't add it like any other tips page. | ||
| [Tue Jul 28 2009] [11:37:58] <tibbs_>And put it in PackageMaintainers. | ||
| [Tue Jul 28 2009] [11:38:00] <abadger1999>limburgher: Yeah -- and give it | ||
| [Tue Jul 28 2009] [11:38:43] <limburgher>abadger1999: Cool. | ||
| [Tue Jul 28 2009] [11:38:45] <spot>okay, i think we're all done for today. thanks everyone. | ||
| [Tue Jul 28 2009] [11:38:54] <spot>i'll rework that one draft so it is ready for FESCo | ||
| [Tue Jul 28 2009] [11:39:02] <abadger1999>tibbs_: We need to do some wiki organization. | ||
| [Tue Jul 28 2009] [11:39:29] <limburgher>tibbs_: I would, but since it could break other installed packages if someone goofs, I think the extra review might be beneficial. | ||
| [Tue Jul 28 2009] [11:39:45] <tibbs_>I can't disagree about needing to do wiki reorg. | ||
| [Tue Jul 28 2009] [11:39:50] <abadger1999>Have Packaging Guidelines link out to tips pages that tell how maintainers can implement the guidelineswhen upstreamisn't cooperating and stuff. | ||
| [Tue Jul 28 2009] [11:39:54] <SmootherFrOgZ>spot: thanks | ||
| [Tue Jul 28 2009] [11:40:10] <tibbs_>The idea is that any packager should be able to contribute to useful pages like dealing with rpmlint complaints and such without having to go through the committee. | ||
| [Tue Jul 28 2009] [11:40:16] <abadger1999><nod> | ||
| [Tue Jul 28 2009] [11:40:23] <abadger1999>I agree with that. | ||
| [Tue Jul 28 2009] [11:40:32] <limburgher>Makes sense. | ||
| [Tue Jul 28 2009] [11:41:08] <limburgher>I'll write it up either way, and if that's what we do with it, great. As long as the info's out there and people make use of it, I really don't care. | ||
| [Tue Jul 28 2009] [11:59:31] <spot>tibbs_: are you going to open the FESCo ticket or should i? | ||
| [Tue Jul 28 2009] [12:00:18] Quitkital has left this server ("leaving"). | ||
| [Tue Jul 28 2009] [12:00:59] <tibbs_>If you like, please go ahead. I'm having to deal with a work issue at the moment. |