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