14:59:49 <spot> #startmeeting Fedora Packaging Committee 14:59:49 <zodbot> Meeting started Wed Nov 30 14:59:49 2011 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:59:54 <spot> #meetingname fpc 14:59:54 <zodbot> The meeting name has been set to 'fpc' 14:59:54 <tibbs|h> Morning. 14:59:57 <spot> #topic Roll Call 15:01:34 <tibbs|h> I apppear to be lagging. 15:02:07 <spot> tibbs|h: not sure about that 15:02:33 <tibbs|h> My connection is going up and down. Good job, xfinity. 15:02:51 <spot> but but, pc world says they have the fastest internets.... :P 15:03:13 <tibbs|h> It's fast in short bursts. 15:03:17 <spot> hehe 15:03:27 <spot> okay, so i see tibbs and me... 15:03:33 <tibbs|h> Yeah, exciting meeting. 15:03:48 <spot> ping abadger1999, racor, limburgher, SmootherFrOgZ, Rathann, 15:04:07 * jsmith lurks, just because he's here 15:04:16 * limburgher here 15:04:21 <Rathann> I'm sort of here 15:04:43 <Rathann> from a mobile phone at work 15:04:43 * limburgher is distracted but trying ever to hard to focus 15:04:47 <tibbs|h> Given Panu's condmnation of %pretrans this morning, I'm wondering if we don't need to discourage its use in the guidelines. 15:04:50 <limburgher> s/to/so/ 15:05:11 <spot> tibbs|h: i haven't seen that yet, but i'm a bit behind on email at the moment 15:05:14 <limburgher> tibbs|h: I thought we did already, but maybe I'm remembering it elsewhere 15:05:24 <tibbs|h> We 15:05:29 <tibbs|h> said you have to use lua. 15:05:31 <Rathann> very busy, please ping me if you need my vote to break a tie 15:06:02 <tibbs|h> Too bad, too; I thought it was a clever solution to the problem. 15:06:48 <spot> well, i'll give it a few more minutes. 15:06:55 * racor was on the phone ... 15:07:24 <spot> okay, we have a very light agenda 15:07:39 <spot> so lets see if our 4.5 people will work. :) 15:08:02 <spot> #topic Fix confusing upgrade path examples - https://fedorahosted.org/fpc/ticket/121 - http://fedoraproject.org/wiki/User:Ferdnyc/PackagingEditTest 15:08:21 <spot> I'm the one who wrote the original examples, and I think this is a fantastic cleanup. 15:08:52 <tibbs|h> Yeah, those examples always were a bit cumbersome (no offense intended, of course). 15:09:03 <spot> none taken. they've confused me too. :) 15:09:07 <limburgher> Wow. 15:09:24 <limburgher> You know that bit in Wizard of Oz where she walk out of the house and it's all in color? 15:09:33 <limburgher> s/walk/walks/ 15:09:45 <spot> hehe 15:10:09 <spot> so, I'm +1 on this change 15:10:34 <tibbs|h> While we're in here, maybe we could think about why all the good stuff about what version/release to use is in the "Naming" guidelines. 15:11:14 <limburgher> Where would you rather see it? Not saying it shouldn't move, just curious. 15:11:31 <tibbs|h> In the "Naming and Versioning Guidelines" or whatever. 15:11:35 <tibbs|h> I.e. rename the page. 15:12:00 <spot> well, we can rename the page i suppose 15:12:01 <tibbs|h> But, yes, +1 on this cleanup. 15:12:06 <limburgher> Logical. 15:12:09 <spot> thats one of the older pages in the guidelines 15:12:22 <spot> i did add a helper link off the main page that goes right to this section 15:12:39 <tibbs|h> It's just that "why are the examples so confusing" and "why do I look in the naming guidelines for what to put in the version" are two of the more common questions I've had to answer. 15:13:00 <racor> Could somebody summarize this - I don't get it. 15:13:58 <tibbs|h> He's just fixing up the formatting on http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages 15:14:30 <tibbs|h> Although there is still a small bit of broken formatting in the draft. 15:15:28 <spot> tibbs|h: where? 15:15:30 <tibbs|h> Two tables are missing borders. 15:15:38 <tibbs|h> Though I don't know nearly enough wiki formatting to fix it. 15:16:05 <tibbs|h> The first table is missing the bottom border and the third is missing the top border. 15:16:18 <tibbs|h> Erm, no, that goes away when I resize the font. WTF? 15:16:26 <spot> yeah, i dont see that 15:16:30 <racor> Must be a language barrier: ... alsa-lib-0.9.2-0.6.rc1 (upgrade to 0.9.2rc2) ??? 15:16:55 <spot> racor: no, alsa-lib-0.9.2-0.6.rc1 -> alsa-lib-0.9.2-0.7.rc2 15:17:10 <spot> racor: if you read the table from top to bottom, it shows the upgrade progression 15:17:37 <tibbs|h> I mean, he didn't add any text. 15:17:54 <spot> tibbs|h: yeah, that's all my "awesome" original text, it is just formatted in a cleaner fashion 15:17:57 <racor> spot: yes, that's what I presumed, reading "alsa-lib-0.9.2-0.6.rc1 (upgrade to 0.9.2rc2)" standalone, at least to me is confusing 15:18:12 <spot> racor: i don't think it says that 15:18:37 <spot> wait, are you looking at the old page or the proposed new one? 15:19:35 <racor> spot: both - side-by-side - The citations are from the ... 15:19:51 <racor> <crap/> now I get it ... I mixed up old/new ... 15:20:25 <tibbs|h> Yes, he added the "this is after upgrading". 15:20:30 <tibbs|h> Which does make more sense. 15:20:50 * abadger1999 awake now 15:21:08 <spot> So, i see +2 on this cleanup proposal 15:21:17 <limburgher> +1 15:21:47 <racor> +1 15:22:33 <abadger1999> +1 15:23:11 <spot> #action Improved examples approved (+1:5, 0:0, -1:0) 15:24:30 <spot> tibbs|h: do you want to propose that we rename NamingGuidelines to NamingAndVersioningGuidelines ? 15:25:04 <tibbs|h> It's not a big deal; that name does seem a bit cumbersome. 15:25:17 <tibbs|h> But maybe add it to the title or something. 15:25:24 <spot> We could also split out VersioningGuidelines, but that would be more work. 15:25:44 <spot> i'll just add it to the title for now 15:25:55 <abadger1999> mediawiki norm seems to be long names (and with spaces) 15:26:10 <tibbs|h> Redirects... Redirects everywhere. 15:26:22 * abadger1999 agrees with adding versioning to name 15:26:29 <spot> it is now titled "Package Naming and Versioning Guidelines" 15:27:20 <tibbs|h> BTW, are you keeping that version block up to date? 15:27:31 <spot> tibbs|h: no. it should be dropkicked out a back door. 15:28:00 <spot> that style dates to a time when i thought it might end up as packaged docs 15:28:16 <spot> i'm not sure what value there is in it when it is a wiki document 15:28:24 <spot> and the history/versioning is embedded in the format 15:28:43 <spot> the only page that i've kept current is the licensing page 15:31:05 <spot> so... 15:31:11 <spot> 121 was the only ticket i had on today's agenda 15:31:24 <spot> i am going to send out the whenisgood today, i promise. 15:31:32 <tibbs|h> Oh, cool. 15:31:36 <abadger1999> thanks :-) 15:31:44 <abadger1999> usr move? 15:31:56 <spot> abadger1999: did that ticket get updated info? 15:31:58 <tibbs|h> Yeah, Panu dashed our plans for the usrmove thing. 15:32:14 <tibbs|h> "I STRONGLY recommend against using %pretrans in filesystem" 15:32:17 <haraldh> yes, we tried hard 15:32:21 <haraldh> but yum failed 15:32:29 <abadger1999> well -- just the idea of moving the script into %pretrans 15:32:58 <spot> so, is there no way that we'll be able to handle yum upgrades here? 15:32:59 <abadger1999> I think he's okay with just the warning that is proposed. 15:33:05 <tibbs|h> Yeah, seems there's no real way to do it without requiring a manual script run. 15:33:18 <haraldh> current plan: use http://fpaste.org/oxUu/ 15:33:24 <haraldh> from dracut 15:33:32 <haraldh> or rescue environment 15:33:44 <haraldh> dracut would be a simple kernel command line option 15:34:10 <spot> haraldh: is there any way we can be clever about this? 15:34:14 <haraldh> I would provide new F15 and F16 packages with the update script 15:34:32 <spot> haraldh: e.g. have dracut check to see if the filesystem is converted, and if not, run the script? 15:35:00 <haraldh> nah, you _have_ to upgrade to F17 afterwards 15:35:11 <haraldh> no "automatic" conversion 15:35:16 <spot> haraldh: no, hear me out 15:35:26 <haraldh> the script has to run _before_ the upgrade 15:35:29 <haraldh> to F17 15:35:32 <spot> ah yes. 15:35:48 <spot> maybe we can do some sort of nasty hack in yum 15:36:00 <haraldh> hmm, we could 15:36:21 <spot> i just think that having no method to handle this case is a recipe for a lot of flames 15:36:27 <haraldh> _but_ doing the upgrade in a live system is a mess 15:36:28 <spot> and if we can avoid that, it would be ideal 15:36:47 <haraldh> so, doing it from within the initramfs is a lot cleaner and failsafe 15:37:26 <spot> haraldh: maybe yum could check to see if the system is converted if it is trying to update a f16 package to an f17 one, and if it isn't, bail out and tell the user to run the script 15:37:27 <haraldh> just reboot once with that kernel command line option.. then you can "yum update" to F17 like you want 15:37:39 <haraldh> spot, that would be cool.. 15:38:06 <spot> that might even be able to be done in a plugin 15:38:17 <haraldh> but we have the "filesystem" guard in all conflicting packages anyway 15:38:50 <haraldh> the "critical" package list is actually very small 15:38:50 <spot> i still think that this problem needs a solution before we can go forward on this feature 15:39:03 <haraldh> solution is there 15:39:25 <haraldh> the filesystem rpm still has the lua check 15:39:37 <haraldh> and fails to install on an unconverted system 15:39:48 <spot> yes, but thats the problem 15:39:53 <haraldh> and all critical packages will have "Conflicts: filesystem < 3" 15:40:06 <tibbs|h> The lua check doesn't work. 15:40:10 <haraldh> it does 15:40:15 <tibbs|h> pretrans can't abort the transaction. 15:40:25 <haraldh> tibbs|h, correct.. but %pre can 15:40:30 <haraldh> and it does 15:40:37 <tibbs|h> Ah, OK. 15:41:16 <spot> okay.... so filesystem's %pre checks with lua to see if the filesystem is converted, and if not, it aborts the transaction and tells you to run the script? 15:41:23 <haraldh> yep 15:41:31 <tibbs|h> That seems to be a new thing since we last talked about this. 15:41:41 <tibbs|h> Perhaps that's the best we can get. 15:41:45 <haraldh> it's already in the FESCO ticket 15:41:55 <haraldh> 2 weeks ago 15:42:12 <spot> why wouldn't we just run the script in %pre then? 15:42:25 <haraldh> same problem as in %pretrans 15:42:32 <haraldh> yum does some optimizations 15:42:40 <spot> ok 15:42:46 <haraldh> so, if the filesystem layout changes in between, we are hosed 15:42:50 <spot> what installs the script? 15:42:56 <spot> or will the user have to download it manually? 15:42:57 <haraldh> I would say dracut 15:43:06 <haraldh> it will be in the dracut package 15:43:11 <haraldh> F15 and F16 update 15:43:13 <abadger1999> haraldh: looks like needconvert() in the script can bailout early if some of the directories are already links but not all. 15:43:16 <spot> okay. 15:43:35 <haraldh> abadger1999, correct... because then, it needs convert 15:43:56 <haraldh> abadger1999, it bails out early, if it needs convert 15:44:29 <spot> so, it seems like that explains how yum upgrades will be handled (the user will be prompted to manually convert the filesystem via the script, then afterwards, yum upgrade will succeed) 15:44:39 <haraldh> correct 15:44:52 <spot> I hope that message is very very clear. :) 15:45:08 <haraldh> s/convert the filesystem via the script/reboot with a special kernel command line option/ 15:45:22 <haraldh> so, the script is run from within the initramfs 15:45:36 <haraldh> this spares us nasty ld-linux-2.so tricks 15:45:40 <spot> haraldh: okay. 15:45:48 <abadger1999> haraldh: ah got it -- || not && 15:46:46 <spot> haraldh: and you have tested this specific scenario (try to yum upgrade, get failure message, reboot with custom option, then yum upgrade successfully) ? 15:47:03 <haraldh> yes 15:47:21 <haraldh> https://fedorahosted.org/fesco/ticket/690#comment:12 15:47:24 <spot> okay, then it seems like the criteria has been met. 15:47:34 <spot> does anyone present (FPC) think it hasnt? 15:47:45 <limburgher> spot: and if not, a great scream will be heard from my house in a few months. :) 15:47:53 <haraldh> hehe 15:48:13 <spot> limburgher: i think it will be worse than that time we accidentally blew up alderaan. 15:48:19 <haraldh> in all out interest this will be tested very well 15:48:21 <limburgher> As long as the message is out there well enough, it should be OK. We can post this to the LiveUpgrade sig. 15:48:34 <limburgher> spot: Damn Fedora Orbital Laser. 15:48:47 <tibbs|h> Will we need to do any guidelines work for this besides saying "don't put stuff here; put it there instead"? 15:48:56 <spot> tibbs|h: not that i can see 15:49:43 <spot> so, i propose we lift the hold on this item 15:49:52 <haraldh> to whom do I have to talk about the mass conversion of the packages? 15:49:58 <spot> haraldh: fesco 15:50:00 <haraldh> ok 15:50:15 <spot> assuming you're not doing anything besides simply changing the paths 15:50:23 <haraldh> yep 15:50:26 <haraldh> nothing else 15:50:59 <limburgher> I assume this includes making sure rpm macros Do The Right Thing? 15:51:03 * abadger1999 still reading through the upgrade script 15:51:08 <spot> limburgher: well, i thought about that 15:51:18 <limburgher> If ever there was an argument for proper macro use in your spec, this is it. :) 15:51:19 <spot> limburgher: and i don't think we need to change the rpm macros at this time 15:51:19 <abadger1999> haraldh: Do you care about the case where a mount has spaces in its name? 15:51:24 <haraldh> limburgher, I rebuild everything in mock first 15:51:31 <limburgher> spot: because of the symlinks? 15:51:35 <spot> limburgher: yeah. 15:51:36 <abadger1999> Like /my\ old\ system/usr 15:51:49 <haraldh> abadger1999, did you find a line without quotes? 15:51:52 <spot> limburgher: and if we decide to rollback for some reason, i'd rather not have macro confusion 15:52:09 <limburgher> spot: Good point. And if it doesn't work. . .we'll find out. :) 15:52:10 <abadger1999> haraldh: I'm just looking at ismounted() and I'm not sure it handles that 15:52:21 <spot> limburgher: if/when we decide to drop the symlinks, we can revisit the macros 15:52:23 <haraldh> abadger1999, ah, right 15:52:31 <haraldh> abadger1999, thx for the pointer 15:52:39 <abadger1999> no problem 15:52:53 <haraldh> in dracut it is /sysroot 15:53:02 <haraldh> just wanted to be nice in the script 15:53:10 <limburgher> spot: <nods> 15:53:44 <haraldh> spot, limburgher: which macro exactly? 15:54:09 <haraldh> they are all fine with /usr 15:54:21 <haraldh> a lot of cruft will be removed from the specfiles 15:54:32 <haraldh> doing dirty symlink tricks in /lib* 15:54:40 <haraldh> and such 15:54:42 <spot> haraldh: well, there are quite a few macros that specify pathing 15:54:46 <limburgher> haraldh: Exactly. 15:54:59 <spot> e.g. %{__mv} 15:55:03 <limburgher> %{_bindir} for example. 15:55:05 <haraldh> ah, right 15:55:14 <haraldh> %{_bindir} is /usr/bin 15:55:29 <spot> yeah, i'm not thinking of the normal toplevel dirs 15:55:30 <haraldh> but %{__mv} yes 15:55:41 <tibbs|h> Compat symlinks should save us here. 15:55:44 <limburgher> mv is a perfect example. 15:55:48 <spot> tibbs|h: they will 15:55:52 <limburgher> tibbs|h: Right. 15:56:00 <spot> it would only be an issue if the symlinks ever disappeared 15:56:01 <haraldh> anyway.. the compat symlinks will not go away as long as "#!/bin/sh" is used :) 15:56:03 <tibbs|h> And fixing that now just invites pain if we have to un-fix it later. 15:56:07 <spot> and that would require a FHS change 15:56:15 <spot> so i think we're fine to leave it as is 15:56:22 <haraldh> and ld-linux-2.so is hardcoded with "/lib/" 15:56:24 <spot> changing it now would also cause heartburn in EPEL 15:56:46 <haraldh> no chance we will remove these symlinks in the next years 15:57:23 <spot> so, i'm +1 on lifting the hold here 15:57:41 <tibbs|h> Yes, I think we're done here. 15:57:43 <abadger1999> +1 15:57:44 <tibbs|h> +1 15:58:16 <limburgher> +1 15:58:56 <spot> racor, Rathann, we need one more +1 16:00:42 <racor> -1 16:00:56 <spot> racor: okay. 16:01:18 <spot> Rathann, rdieter (if you're around), we still need your votes 16:01:25 <tibbs|h> So what of the requirements we put to them last week have they not met? 16:03:47 <limburgher> FWIW, this makes me nervous and I'm still +1 because I think it's being done carefully. 16:04:39 <tibbs|h> This isn't something we can stop anyway. We can only make sure the packaging guidelines part is done correctly. 16:04:46 <tibbs|h> And it appears that we've done that and more. 16:06:07 <abadger1999> tibbs|h: well... we might be able to stop it anyway... but there's probably a greater chance of that if we were unanimously against it rather than just a few -1 votes. 16:06:17 <abadger1999> which we are not at this time. 16:06:21 <tibbs|h> Well, just one unexplained -1 votes. 16:06:26 <abadger1999> Exactly 16:06:40 <tibbs|h> Not that I expected that we'd get any sort of explanation. 16:06:53 <tibbs|h> But I have short ribs to get in to braise, so.... 16:07:11 <spot> geppetto: we're voting to lift the hold on the /usrmove item 16:07:12 <abadger1999> haraldh: If the script encounters a / directory that's already a link; it should probably warn the user that they may have to convert that one manually. 16:07:31 <geppetto> spot: ok … not #121 then? 16:07:36 <spot> no, 121 was approved 16:07:42 <geppetto> I thought the hold was just on the packaging changes? 16:08:01 <geppetto> Well, policy/documentation of packaging changes 16:08:13 <geppetto> Can we actually stop it? 16:08:20 <haraldh> abadger1999, yes 16:08:26 <spot> geppetto: the criteria for the hold was that the script be reviewed, the yum update scenario be understood, and that it be tested 16:08:43 <spot> geppetto: this vote is to state that the criteria has been met and the hold should be lifted 16:09:21 <spot> geppetto: vote count is at +1:4, 0:0, -1:1 16:09:38 <geppetto> So … my understanding is that unless someone finally fixes rpm to allow dir. => symlink moves … there's not going to be a yum upgrade path, and doesn't require running magical scripts and hoping 16:10:37 <racor> OK, to avoid further misunderstandings: I consider /usrmove to be a crime against Linux and Unix. I cannot arrange it with my conscience to support it. 16:10:49 <limburgher> geppetto: As it sits, with the script, there is a yum upgrade path. 16:11:14 <spot> geppetto: basically, yes. yum upgrade will try to run, hit the %pre in filesystem, which checks for conversion, then when it finds it hasn't been done, bails out and tells the user to reboot with a custom command line option. 16:11:23 <geppetto> limburgher: Running something else is not a yum upgrade path, IMNSHO 16:11:23 <spot> then dracut does the conversion, and boots up 16:11:39 <spot> then the user reruns yum 16:12:01 <limburgher> racor: I agree, though not so strongly, but I feel that important that the thing I disagree with is at least done well. 16:12:02 <geppetto> The words "Epic." and "Fail." come to mind. 16:12:24 <spot> geppetto: okay... so how do we make yum handle this? 16:12:42 <limburgher> geppetto: They seem determined, and I think this is the best that's possible with the tools as they are now. 16:12:52 <geppetto> With the info. we have now … must convert all users, must use external script … we can't. 16:13:31 <geppetto> Plus rpm's inability to move from dirs. to symlinks. 16:14:09 <tibbs|h> I wonder why that problem seems unfixable. 16:14:24 <abadger1999> haraldh: okay, I'm done reading through the script -- those were the only two things I saw that could be changed. 16:14:29 <geppetto> I think it's just in a piece of rpm nobody wants to look at (and esp. change). 16:14:35 <haraldh> abadger1999, thank you 16:15:29 <spot> geppetto: so, your point is that rpm would need to support moving from dirs to symlinks before you would consider this hold criteria met? 16:16:44 <geppetto> No, there are a few ways around it: 1) Don't require all users move, so new installs have symlinks and old users have dir. plus a file symlinks I guess. 2) Find some way to stick the conversion in the packages. 3) Fix rpm. … 4) ?? 16:16:59 <geppetto> #1 is directly against what notting wanted, though 16:17:09 <spot> i don't think anyone has come up with a way to do #2 safely 16:17:33 <spot> the safest way is to do it in dracut, it seems 16:17:50 <geppetto> Yeh, I guess the problem is just that the dirs. are so core to everything … as I thought people had done dir. => symlink moves with magic scriptlets before. 16:18:01 * spot wonders if it is possible to offer some sort of command to reboot into the migration mode. 16:18:10 <geppetto> I don't see how that helps. 16:18:28 <spot> well, it makes it less likely to fail if it is "sudo f17-migrate" 16:18:49 <geppetto> From the yum POV if you can't just run "yum upgrade" … then it doesn't really matter if you have to run preupgrade instead. 16:19:08 <geppetto> You've already failed all expectations etc. 16:19:12 <spot> geppetto: i definitely see that, but i also don't see how it is possible to just run yum upgrade 16:19:19 <haraldh> geppetto, what's the thing? you have to reboot anyway.. 16:19:22 <spot> so if that isn't possible, this is the next best thing 16:19:57 <limburgher> geppetto: See gallery2 16:19:57 * geppetto shrug … fine, +1 then … I'll try not to care. 16:20:02 <abadger1999> spot: grub (not sure about grub2) has some sort of boot once setting so it is possible.... not sure if it's desirable though 16:20:42 <spot> abadger1999: if for no other reason than to make it very simple and less likely to fail when the user doesn't remember what the magic option is when the system reboots 16:20:52 <geppetto> someone better put "Do _not_ use 'yum upgrade'" in the release notes 16:20:56 <geppetto> And the announcement. 16:21:10 <racor> geppetto: == epic fail 16:21:23 <haraldh> geppetto, it's not officially supported anyway, isn't it? 16:21:28 <spot> geppetto: well, if it says "don't use yum upgrade before you have converted the filesystem via this method: ...", isn't that the same thing? 16:21:42 <abadger1999> haraldh: So in the yum upgrade case -- what's the exact steps to make things work? 1) Update to new enough dracut 2) ? 16:21:55 <rdieter> here now finally (reading backlog) 16:21:57 <haraldh> 2) recreate the initramfs 16:22:06 <haraldh> 3) reboot with kernel command line option 16:22:10 <geppetto> haraldh: There's a difference between every previous release, where we didn't test it as much but it worked … and F17-F19 where we know it'll fail completely. 16:22:12 <haraldh> 4) yum upgrade 16:22:46 <haraldh> geppetto, after some manual steps it works, also 16:22:58 <haraldh> without anaconda or preupgrade 16:23:00 <limburgher> geppetto: But the idea is that if the user does A then B then C and then yum upgrade, it will. 16:23:10 <geppetto> spot: I'd rather not … just tell people to use preupgrade because we know it doesn't work. 16:23:26 <haraldh> preupgrade is recommended of course 16:23:37 <haraldh> or running upgrade from the DVD 16:23:41 <haraldh> or USB stick 16:23:51 <racor> haraldh: These days SUSE and Ubuntur encourage on-the-fly upgrade, only the "bleed edge" distro Fedora fails to support it. 16:24:09 <kay> suse works on the same issue already :) 16:24:11 <haraldh> racor, wait until Debian switched to /usr 16:24:14 <geppetto> limburgher: When what you have to do ammounts to just running preupgrade anyway, but with much more chance of it going wrong … it seems like a bad idea to pretend that it can work. 16:24:16 <limburgher> Plus I've been live yum upgrading since FC2, why stop now? :) 16:24:20 <kay> they need to kill the mindless / vs. /usr split too 16:24:21 <haraldh> suse works on the /usr switch also 16:24:21 <abadger1999> haraldh: k. And does the yum upgrade needs to run in the special boot? Or can you reboot into the normal system before yum upgrade? 16:24:29 <kay> they wait for us, they say :) 16:24:32 <limburgher> geppetto: But it won't take as long as preupgrade. 16:24:35 <haraldh> abadger1999, normal system 16:24:46 <geppetto> limburgher: If we just tell everyone "we know we've broken yum upgrades, don't use them" … we have a much better chance of all the users coming through it. 16:24:47 <abadger1999> col. 16:25:32 <haraldh> limburgher, if you reboot with that option, you can yum upgrade to F17 also 16:25:43 <haraldh> so, what is the thing here? 16:25:46 <racor> haraldh: Before Debian switches to /usr, Fedora will be dead and Ubuntu be overrun by Mint. 16:25:49 * spot notes that we are at +1:4, 0:0, -1:1 on lifting the hold 16:25:58 <geppetto> spot: I said +1 above 16:25:59 <rdieter> spot: count me +1 16:26:04 <spot> okay. 16:26:22 <spot> #action Hold lifted. (+1:6, 0:0, -1:1) 16:26:39 <spot> haraldh: please try to document this clearly and thoroughly. 16:26:52 <haraldh> spot, of course 16:27:05 <spot> okay, i think we're done for today. 16:27:09 <spot> thanks everyone 16:27:13 <haraldh> thanks 16:27:13 <spot> #endmeeting