[05:30] <babyface_> anybody know why is there no new built precise desktop iso on Sep 10?
[07:45] <cjwatson> plars: the issue psivaa reported was "report.html is very long", and it became shorter :-P
[07:45] <cjwatson> plars: I do still intend to check it manually
[07:46] <cjwatson> babyface_: unclear; probably not worth investigating now, we'll just see if today's works
[07:47] <babyface_> cjwatson, yes, let's see if today's works
[09:08] <sil2100> Hello!
[09:09] <sil2100> I would like to propose an FFE for a feature that somehow completely got missed in all the FF-haste we had...
[09:09] <sil2100> https://bugs.launchpad.net/ubuntu/+source/indicator-appmenu/+bug/1048992 <-
[09:09] <ubot2> Launchpad bug 1048992 in indicator-appmenu "[FFE] Support for webapps in the indicator-appmenu package" [Undecided,New]
[09:10] <sil2100> The features even landed in trunk before FF it seems, but there was no official new release since that time, so it missed FF
[09:25] <psivaa> cjwatson, reported a bug on d-i for quantal server install failures, bug 1049011
[09:25] <ubot2> Launchpad bug 1049011 in debian-installer "Quantal server installation fails on a vm at partman-md stage, " [Undecided,New] https://launchpad.net/bugs/1049011
[09:27] <cjwatson> psivaa: Yeah, I'm in the middle of fixing it.  It's not in partman-md, it just looks like it
[09:29] <psivaa> cjwatson, ohh ok, hope you'd change the title accordingly then?
[09:29] <cjwatson> I already did
[09:30] <psivaa> cjwatson, just saw thanks :)
[09:31] <Laney> psivaa: it's rls-q-incoming not q-rls-incoming, btw
[09:32]  * cjwatson will fix
[09:35] <psivaa> Laney, ohh ok, sorry about that
[09:35] <cjwatson> I'll respin in an hour or two once those fixes are published
[09:35] <cjwatson> And retest
[09:39] <psivaa> ok, hope our automated tests could verify that too
[10:29] <knome> has ubiquity thrown "unrecoverable error"s for other, or is it just xubuntu?
[10:31] <xnox> knome: duplicate. try images from 2012-09-11 should be ok.
[10:32] <knome> xnox, which bug number should i use?
[10:32] <knome> i mean, for reporting on ISO tracker
[10:32] <knome> and do you know if the problem is xubuntu-specific or all flavors
[10:33] <xnox> we know that ubiquity-gtk is borked, and we fixed it, so all images that used ubiquity-gtk were borked between friday and yesterday.
[10:33] <knome> ok
[10:33] <knome> huh :)
[10:34] <knome> so, did you have a bug number for that? :)
[10:37] <xnox> bug 1048211
[10:37] <ubot2> Launchpad bug 1048211 in udisks2 "udisks2-inhibit crashes if udisks2 is not running" [Critical,Fix released] https://launchpad.net/bugs/1048211
[10:38] <knome> thanks
[10:40] <xnox> knome: it shouldn't be there on the 20120911 image... which one were you testing?
[10:41] <knome> 10 i suppos
[10:41] <knome> i zsynced
[10:41] <knome> how do i check the image date?
[10:41] <knome> i think i just got the 10
[10:43] <knome> that must be it, because i was reporting to 10 too, that's why i couldn't send the report
[10:45] <knome> cjwatson, https://code.launchpad.net/~ochosi/ubiquity/quantal-proposed/+merge/123041 should be correct now.
[10:46] <xnox> knome: well there is 9/11 image available http://cdimage.ubuntu.com/xubuntu/daily-live/20120911/
[10:46] <knome> xnox, probably wasn't when i zsynced
[10:46] <knome> xnox, that was a while ago
[10:46] <xnox> fair enough. just wanted to check in case the fix regressed.
[10:47]  * xnox is trying 9/11 now.
[10:47] <knome> yeah
[11:30] <psivaa> cjwatson, I reported Bug 1049062 on update-manager-core for obsolete config files, affecting our daily tests
[11:30] <ubot2> Launchpad bug 1049062 in update-manager "Obsolete config files for update-manager-core are left after precise2quantal server upgrades" [Undecided,New] https://launchpad.net/bugs/1049062
[11:36] <cjwatson> psivaa: possibly the least interesting of the jenkins tests :)
[11:37] <psivaa> cjwatson, that could be true, but seeing the failure every day made me raise the bug,
[11:37] <cjwatson> Oh, sure
[11:37] <cjwatson> It just has no end-user impact
[11:37] <cjwatson> The only reason to worry about fixing it is to make the tests go green
[11:38] <cjwatson> It's a valid bug certainly, but not OMG-now priority
[11:39] <psivaa> i agree, may be we should think of what to do with the tests
[11:40] <cjwatson> Meh, not really worth arguing about it either - I'll have a look
[11:45] <cjwatson> Well, I take it back, while obsolete conffiles themselves are unimportant, in this case they pointed to some functionality being lost on upgrade
[11:46] <psivaa> ohh ok, green balls mean less investigation time for us :), and thanks for looking at it cjwatson
[11:53] <cjwatson> fixed now
[11:53]  * cjwatson tests the server respin
[13:12] <plars> cjwatson: right, I hadn't checked the file yet when I sent that, and later saw it was just a few packages.  Realistically, what do you see as the best way to handle things from report.html? Should a bug be filed for each package, or is there a preferred approach to dealing with problems found there?
[13:13] <cjwatson> plars: It requires analysis
[13:13] <cjwatson> plars: Filing a bug for each package will certainly be massive overkill
[13:14] <plars> cjwatson: I suspected as much
[13:14] <cjwatson> plars: I would recommend talking to the +1 maintenance team du jour: https://wiki.ubuntu.com/PlusOneMaintenanceTeam
[13:14] <cjwatson> (search for schedule)
[13:14] <cjwatson> well, "Schedule (12.10)"
[13:15] <cjwatson> plars: Or this channel
[13:15] <cjwatson> Because sometimes it'll be an image build issue that we know about
[13:15] <cjwatson> I don't think right now there's a terribly sensible way to handle this in terms of bugs
[13:15] <plars> cjwatson: ok, skaet had mentioned that too, but since you seemed to be handling with psivaa I wanted to ping you to find out if you preferred to be made aware of things there too
[13:15] <cjwatson> In this case it related to something I was doing to image builds
[13:16] <plars> cjwatson: understandable, just want some path to resolution for it
[13:16] <cjwatson> You can't particularly know that in advance and I'm certainly not going to watch bugs on all packages to find out :-)
[13:16] <cjwatson> So why not just make your standard process be to ask here; that will generally be good enough
[14:15] <psivaa> cjwatson, any idea when we would be getting the precise server images with d-i updated with new kernel verison?
[14:16] <cjwatson> I thought I saw mail that that had been copied into precise-updates today
[14:17] <cjwatson> So should be tomorrow
[14:18] <psivaa> ahh ok, thanks very much
[14:33] <mterry> skaet, so that remote-login feature.  It was to be disabled-by-default because we thought that's what the security team requested.  Turns out that was not true.  Mind if I turn it on by default today?
[14:34] <skaet> mterry, can they comment to that effect in the bug?  (and what's the bug number again please ;) )
[14:35] <mterry> skaet, bug 1040221
[14:35] <ubot2> Launchpad bug 1040221 in unity-greeter "FFe request: Provide remote login options" [Medium,Fix released] https://launchpad.net/bugs/1040221
[14:52] <skaet> mterry,  seeing jdstrands comment now.   thanks.   ok by me, as long as we revisit if issues emerge.
[14:52] <mterry> skaet, awesome
[15:18] <cjwatson> OK, the server images should actually work again now
[15:18] <skaet> :)
[15:21] <Daviey> woot
[15:21] <Daviey> thnaks cjwatson
[16:00] <cjwatson> Has anyone had a chance to think about bug 1046890 as yet?
[16:00] <ubot2> Launchpad bug 1046890 in grub2 "[FFe] grub2 2.00" [Undecided,Confirmed] https://launchpad.net/bugs/1046890
[16:11] <stgraber> cjwatson: looking
[16:11] <skaet> cjwatson,  to back it out if we see too many regressions?
[16:11] <skaet> also,  is it all ready to land now?
[16:11] <cjwatson> Difficult, but I suppose we could use a horrible version like 2.00+really1.99-blah
[16:12] <cjwatson> There are no libraries with shlibdeps or anything
[16:12] <cjwatson> Not quite.  I want to debug the dmraid problem that Robert Collins reported; I want to make sure I have changes to a couple of related packages prepared; and I want to issue some kind of call for testing from the PPA.
[16:12] <cjwatson> But I wanted to make sure I wasn't just completely on a hiding to nothing before putting further work into the FFe.
[16:13] <skaet> getting a  cleaner version would certainly be a good thing.   Question is timing enough to react if there are issues encountered.
[16:13] <cjwatson> balloons: ^- Speaking of which, I could do with community testing of the above
[16:14] <cjwatson> My feeling is that the devil we know is not actually particularly good in this case, given all the arcane gettext-related crashes :-/
[16:14] <cjwatson> (in 1.99)
[16:16] <stgraber> cjwatson: will you have it ready before beta2 freeze (next Thursday)?
[16:17] <cjwatson> Yes, I think actually by the end of this week.
[16:19] <skaet> cjwatson, stgraber - ok by me as long as we have a fallback to revert to before beta 2 freeze, if there are more "surprises" than anticipated.
[16:21] <stgraber> cjwatson: commented and approved
[16:23] <cjwatson> Thanks; I'm going to post a CFT to ubuntu-devel now, with a caveat about dmraid
[16:23] <skaet> thanks stgraber.
[16:24] <balloons> cjwatson, hmm
[16:26] <balloons> ok, so pretty straightforward..  I see your ppa
[16:28] <ochosi> hey folks, i'm aware you might be super-busy at the moment, but i quickly wanted to ask whether any of you could take a quick peek at my merge-request for ubiquity (it's really just a one-liner and only affects launching xfce's window-manager)..?
[16:29] <ochosi> would be nice if xubuntu's installer wouldn't look corrupted anymore in beta2
[16:30] <ochosi> (here's the link: https://code.launchpad.net/~ochosi/ubiquity/quantal-proposed/+merge/123041)
[16:31] <cjwatson> balloons: How does http://paste.ubuntu.com/1198987/ look?
[16:31] <stgraber> ochosi: #ubuntu-installer is usually a better place for these
[16:31] <stgraber> ochosi: anyway, looking at it now
[16:31] <stgraber> ochosi: oh, looks trivial enough. Can you add a debian/changelog entry too?
[16:31] <ochosi> stgraber: oh, thanks. i wasn't aware of that. will go there next time!
[16:32] <ochosi> stgraber: ah ok, didn't know i should. in what form? shall i push another commit to the branch or attach the changelog-entry?
[16:32] <cjwatson> balloons: Oh, I'll expand the "please mail me" paragraph a little to ask for version and platform too
[16:33] <balloons> cjwatson, so do you feel given the nature of changes it would be best to target some specific folks, instead of an overall call?
[16:33] <balloons> or are you comfortable enough with the changes we can push it out to everyone, with the warning supplied
[16:33] <stgraber> ochosi: another commit is easier for the merge
[16:34] <ochosi> stgraber: ok, will quickly do that now
[16:34] <stgraber> thanks
[16:34] <ochosi> well thanks for looking at it so promptly!
[16:35] <cjwatson> balloons: It's more that since it's a change that could in principle affect a large number of people (at least on non-ARM platforms) I don't want to bias the reporting in advance
[16:35] <cjwatson> There isn't a particular set I'm looking for feedback from, although perhaps I should say something that this isn't for the faint of heart?
[16:36] <cjwatson> I mean, pre-release boot loader packages in general rather than this update in particular
[16:36] <balloons> yes.. that's what I mean.. we could target the message towards that audience
[16:37] <cjwatson> So I think that audience certainly includes ubuntu-devel, but maybe not (say) all of Planet Ubuntu
[16:37] <balloons> I could specifically ask several folks who are more than capable of doing this well and giving feedback
[16:37] <cjwatson> Absolutely, that would be great if you have ideas; that's why I asked you :-)
[16:37] <balloons> rather than a full on testing event on the tracker
[16:37] <balloons> I think that's what we're looking for here
[16:38] <balloons> although, before you actually release, we should broadcast the change.. when it hits quantal, we'll get the full on testing from everyone.. heh ;-)
[16:38] <ochosi> stgraber: do i have to re-do the merge-request or is it enough that i just pushed the changelog?
[16:38] <stgraber> ochosi: just pushing is enough to have it update
[16:39] <ochosi> stgraber: ok, so far that's done. if i made a mistake or you need anything else from me just let me know (sry, i'm a bit new to these merge-requests)
[16:39] <cjwatson> balloons: http://paste.ubuntu.com/1199006/
[16:39] <cjwatson> balloons: Oh, yeah, I certainly want testing *before* pushing to quantal
[16:40] <balloons> right... so I'll specifically ask some folks to test this round, and I'll pass your instructions to them.
[16:41] <balloons> it will be more intimate.. if you feel that's enough then we'll push to quantal, and of course, it will get more testing when it lands :-)
[16:41] <balloons> on the next reboot for everyone
[16:41] <stgraber> ochosi: merged
[16:41] <balloons> we could also go for a round II of publicized testing after the initial feedback from folks
[16:41] <cjwatson> OK, https://lists.ubuntu.com/archives/ubuntu-devel/2012-September/035887.html
[16:41] <ochosi> stgraber: thanks a lot!! that's one less thing for me to worry about now :)
[16:44] <cjwatson> Also, folks here may be interested: I have secured permission to release my Python rewrite (in progress) of the cdimage tools
[16:45] <balloons> cjwatson, ok, I'll pass along your note.. after some initial feedback, let me know if you want to open up a full campaign and we'll do so
[16:45] <cjwatson> So once that's complete, which I'll try to do ASAP, we'll no longer have a separate deployment branch of cdimage, just a small separate branch somewhere with stuff like passwords and e-mail addresses that's genuinely private
[16:45] <stgraber> cjwatson: yay!
[16:45] <Laney> hoorah
[16:45] <stgraber> so people will be able to run the same magic as we are :)
[16:45]  * Laney updates grub in celebration
[16:45] <cjwatson> I plan to move it to be hosted properly on LP in the process so that people will be less confused about how to commit
[16:46]  * xnox ponders to upgrade to grub2 and then migrate to UEFI and possibly ditch initramfs luks....
[16:46]  * xnox books a couple of hours on the weekend
[16:47] <cjwatson> I have *not* tested the LUKS stuff in any way at all :-)
[16:47] <TheLordOfTime> if I created a debdiff which was accepted into precise-proposed for SRU verification testing, and I was affected by the bug, am I allowed to self-verify that the built package in -proposed works?
[16:47] <TheLordOfTime> (for a given bug)
[16:47] <cjwatson> It would be nice to know that it at least works no worse than previously
[16:48] <xnox> cjwatson: ok. i will prepare recovery boot first, cause it's my working machine with luks+lvm
[16:48] <stgraber> I'll probably be upgrading to the grub from the PPA to see if it works better than 1.99 here (UEFI with the video mode not being handled properly)
[16:50] <xnox> I was waiting out for 2.00 to try UEFI on my supposedly-UEFI-compliant laptop
[16:50]  * xnox heard all sorts of claims about these Latvian laptops....
[16:54] <cjwatson> GRUB 2.00 worked with DM-RAID in my test VM, so I think it may be specific to Robert's striped DM-RAID setup
[17:21] <dobey> hi all. can i a get a release teamer to look at a couple FFe bugs? bug #1048669 and bug #1047606 thanks
[17:21] <ubot2> Launchpad bug 1048669 in ubuntuone-control-panel/trunk "[FFe] Drop ubuntuone-installer package from archive" [High,Fix committed] https://launchpad.net/bugs/1048669
[17:21] <ubot2> Launchpad bug 1047606 in ubuntu "[needs-packaging] [FFe] ubuntuone-client-data" [Wishlist,New] https://launchpad.net/bugs/1047606
[18:16] <fginther> infinity, greetings. can you tell me why eog and evince were unapproved from oneiric-proposed? I've been working with cnd on the libgeis renaming work.
[18:18] <infinity> fginther: Hrm.  Was a while ago, and I discussed it with cnd at the time.  Let me see if I can resurrect them and see why.
[18:18] <fginther> infinity, thank you
[18:19] <infinity> fginther: Or, wait... Do you mean "why did I reject uploads a week or two ago" or "why are the current uploads in the unapproved queue"?
[18:19] <fginther> infinity, "why are the current uploads in the unapproved queue"
[18:19] <infinity> fginther: Because that's where uploads to stable releases go.
[18:20] <infinity> fginther: They look fine, I'll review and accept in a second.
[18:20] <stgraber> unapproved here means "waiting for review", not "rejected"
[18:20] <fginther> infinity, my apologies, I thought they wen to the "new" queue
[18:20] <stgraber> new is only for new sources or binaries (that don't exist in the target archive)
[18:20] <infinity> fginther: Nah, nothing in stable releases should be "new", generally, you're just in the strange position of having been uploading stuff to stable releases that wasn't there before. :P
[18:21] <fginther> infinity, Ah, that explains it. Thank you.
[18:21] <TheLordOfTime> if I created a debdiff which was accepted into precise-proposed for SRU verification testing, and I was affected by the bug, am I allowed to self-verify that the built package in -proposed works? (for LP Bug 1014044)
[18:21] <ubot2> Launchpad bug 1014044 in php5 "PHP5-FPM not reporting errors to web server (nginx)" [Medium,Fix committed] https://launchpad.net/bugs/1014044
[18:22] <infinity> TheLordOfTime: Yeah, if you've verified the actual binaries from the archive DTRT (rather than, say, your own test build), it's perfectly reasonable for you to do the verification.
[18:23] <TheLordOfTime> infinity:  only systems running my test builds were mission-critical-fix-needed servers
[18:23] <TheLordOfTime> i tested on my local create-then-destroy VM(s) which i use for testing stuff, as well as this laptop specifically
[18:23] <TheLordOfTime> (the testing from precise, that is)
[18:24] <infinity> Yeahp, that works for me.  The patch was entirely confined to the FPM SAPI, if I recall from when I reviewed it, so that's a pretty small set of people who would even know how to test it effectively.
[18:24] <TheLordOfTime> yep
[18:24] <TheLordOfTime> well...
[18:24] <infinity> And it's wildly unlikely to magically break anything else.
[18:24] <TheLordOfTime> the nginx team tries to push to get FPM used instead of cgi or what not
[18:25] <TheLordOfTime> so i tend to use that
[18:25] <infinity> Yeah, I'm sure it's seeing more use lately.  That said, a bug like this is sort of proof positive of the smallish user base.
[18:25] <infinity> It never would have made a release version in apache2filter, for instance.
[18:26] <TheLordOfTime> mhm
[18:26] <TheLordOfTime> fixed that bug, marked it verification-done
[18:26] <TheLordOfTime> and i think the segfault bug that the SRU included a fix for was also verification-done'd
[18:26] <infinity> Anyhow, short story, I'm happy with you self-verifying.  Doubly-so, if you're testing in a production environment where you can spot regressions under load.
[18:26] <infinity> Beats someone like me doing a testbed install and muddling around.
[18:26] <TheLordOfTime> well, when the people running their sites say "PHP is fubaring, what're the error logs saying?"
[18:27] <TheLordOfTime> I can't say "um... there are no logs..."
[18:27] <TheLordOfTime> so i say i'm working on it :P
[18:27] <TheLordOfTime> took a damn long time for me to notice that bug though
[18:27] <TheLordOfTime> normally i see those kinds of bugs crazily quickly
[18:27] <TheLordOfTime> ... in retrospect, i should have tagged that as a regression, because it was introduced in Precise (a regression between Oneiric and Precise)
[18:29] <TheLordOfTime> infinity:  the real issue with the SRU was two-fold: (1) it fixed two bugs, and (2) the second bug (segfault) was a lot harder to test, and explosivity factor of that was unknown.
[18:29] <TheLordOfTime> so...
[18:29] <TheLordOfTime> (that's my interpretation of potential issues, of course)
[18:31] <TheLordOfTime> infinity:  also, when you happen to see any emails from my @ubuntu.com address, feel free to ignore, when i sent that, you weren't online :P
[18:32] <infinity> TheLordOfTime: ;)
[18:34] <xnox> fginther: "unapproved" == "not approved yet / to be approved"
[18:34] <balloons> cjwatson, I noticed today's daily still has
[18:36] <balloons> "installing something over here, but this is so long it does not fit" string :-) Was this intended to be replaced
[18:36] <balloons> ?
[18:37] <fginther> xnox, thanks. infinity straighten me out
[18:39] <xnox> balloons: my fault, fixed in trunk.
[18:39] <xnox> balloons: pending next deployment.
[18:39] <balloons> xnox, ok.. I guess no bug report needed then eh?
[18:40] <xnox> balloons: I thought that string is not visible, I changed it to much longer one to test layout !English  which sometimes is very long.
[18:40] <xnox> balloons: yeah no need ;)
[18:40] <balloons> also xnox, while I have you.. It's interesting that the installer doesn't go to the partition screen or confirm the disk to install to, if there's only one disk
[18:40] <xnox> balloons: I have one more fix for the top crasher, need to test a bit more and will upload a release.
[18:41] <xnox> balloons: see bug reports, this is intended behaviour. Or do you have concerns?
[18:41] <xnox> The button does say "Install Now" vs "Continue" =)
[18:41]  * xnox filed a bug report to update test cases.
[18:42]  * balloons is updating them now :-)
[18:43] <xnox> =))))
[18:43] <balloons> I only see a continue, and not "install now" when selecting it
[18:43] <balloons> not concerns persay, just confirming intended behavoir
[18:43] <balloons> and of course, the tests need to reflect it
[18:44] <xnox> Hmm... if clicking that bottom right leads to starting installation, it should say "install now" and not "continue"
[18:44] <xnox> that is a bug =)
[18:44] <balloons> in this case, it's an "erase quantal and reinstall"
[18:44] <balloons> it says continue
[18:45] <xnox> with one disk that should say "Install Now"
[18:45] <xnox> =(
[18:45] <balloons> right.. one disk
[18:46] <balloons> ok, dentist is calling.. ugh.. I'll bbl and file a bug for it
[18:46] <xnox> ok.
[18:46] <balloons> thanks xnox !
[18:46] <knome> balloons, bug for the dentist? o.O
[18:46] <balloons> knome, ohh yes!
[18:46] <balloons> lol
[18:47] <balloons> knome, btw, a tangent.. did you see your logo made it onto a cupcake?
[18:47] <knome> i didn't!
[18:47] <balloons> https://plus.google.com/104307250302998042813/posts/aMB1wGb4G8P
[18:47] <balloons> :-)
[18:48] <knome> cool
[18:48] <knome> we probably should have lunch/dinner together some day on uds
[18:49] <balloons> knome.. you bet
[18:49]  * knome just made sure all his stuff will fit into the backpack along with the laptop, so no luggage \o/
[18:49] <knome> anyway, we shouldn't populate this channel with this chat... :)
[19:10]  * tumbleweed would love to nack all these unity FFes until it actually runs in my VM
[19:10] <tumbleweed> I hope somebody is looking at that stuff
[19:22] <skaet> tumbleweed, have started looking at some of them
[19:23]  * tumbleweed is getting worried. People in the Loco have started upgrading and nobody has had anything good to say, yet
[19:23] <Laney> someone lost their window manager mid-upgrade at the global jam
[19:23] <Laney> that was un-fun
[19:24]  * tumbleweed is busy helping someone with a broken nvidia
[19:29] <stgraber> Laney: yeah, I had a few people getting similar problems... I may even be willing to spend some time next cycle to split the upgrade process into "download the stuff" and "install the stuff", where the first part would be done from the regular user session and the second part would be done from a minimal user session where there's not much that can crash
[19:30]  * infinity recalls having this conversation not long ago...
[19:30] <stgraber> because really, who actually manages to work during a dist-upgrade anyway? (with half the desktop randomly blowing up)
[19:30] <stgraber> infinity: around two weeks ago I believe ;)
[19:30] <Laney> it also took about 3 hours
[19:30] <infinity> Three hours for an OS upgrade isn't world-ending.
[19:30] <infinity> Crazy breakage is less pleasant.
[19:31] <dobey> skaet: you're looking at FFes now? are any ubuntuone ones on your list?
[19:32] <Laney> I'd say having a release upgrade put you out of action for that long is pretty bad
[19:32] <infinity> Laney: Really?  Have you ever upgraded, well, any other desktop OS?
[19:33] <Laney> well, not recently enough to be able to assert timings with any authority
[19:33] <tumbleweed> still, the release upgrade could totally be done from a daemon that doesn't die if X does
[19:33] <Laney> but I don't remember it taking that long.
[19:33] <Laney> (OSX would have been the last one I did)
[19:33] <infinity> OSX has a lot less software in the "core system" that they actually upgrade.
[19:34] <infinity> So does Windows, for that matter, but any time they've offered an upgrade path, it's always been a nightmare, and a day-long process.
[19:34] <dobey> Windows OS upgrades are fun. 6 hours of reboots!
[19:34] <Laney> I don't think our bar should be to be as bad as Windows upgrades :-)
[19:34] <infinity> Not that I'm saying we can't improve, we absolutely can, but I don't think we're doing particularly poorly either, when it comes to timing.
[19:35] <infinity> We could definitely improve the "it all goes to poop, halp!" experience, though. :P
[19:35] <tumbleweed> yeah, that's the low hanging fruit
[19:35] <Laney> also, conffile prompts mid-upgrade
[19:39] <infinity> Laney: Ones due to bad packaging, or legit ones, but you want them clustered at the beginning or end?
[19:39] <Laney> the latter
[19:39] <infinity> Laney: The former are definitely bugs.  The latter, I agree we should be able to do better somehow.
[19:39] <Laney> bugs should just be fixed
[19:39] <Laney> but if we do the latter then the former is a bit less annoying
[19:41] <skaet> infinity,  could you take a look at https://bugs.launchpad.net/ubuntu/+source/ubuntuone-installer/+bug/1048669 and https://bugs.launchpad.net/ubuntu/+bug/1047606 ?  If they can land in the next day or so,  I think they should be ok - but wanted to make sure the archive aspects are all considered properly.
[19:41] <ubot2> Launchpad bug 1048669 in ubuntuone-control-panel/trunk "[FFe] Drop ubuntuone-installer package from archive" [High,Fix committed]
[19:44] <infinity> skaet: Looking.
[19:47] <infinity> dobey: I'm a bit confused about why we still need an ubuntuone-installer.desktop, if we're dropping the installer in favour of just, like, installing the client.
[19:49] <dobey> infinity: because we can't rename the file, as it will break the default list for unity launcher; and will thus break for people on upgrade as well
[19:51] <infinity> dobey: Oh, does it double for launching the client as well?
[19:51] <dobey> infinity: it just launches the control panel directly now, yes.
[19:51] <infinity> dobey: Fair enough.  A bit messy that it has a silly name, but not world-ending.
[19:51] <dobey> infinity: before, it launched the installer, which if control panel was already installed, would just run it
[19:51] <dobey> infinity: yeah, i wish we could migrate the default apps stuff easily
[19:52] <infinity> dobey: Both those FFe bugs look fine to me, is the -data thing a new source package, or just a new binary built from some other U1 source?
[19:52] <dobey> infinity: new source package
[19:52] <infinity> dobey: Upload away, then, so we can give it a once-over in the queue.
[19:53] <dobey> great, thanks
[19:53] <infinity> dobey: And do make sure it has sane Breaks/Replaces for u1installer.
[19:53] <infinity> dobey: Or maybe even a Conflicts, given that we want installer to go the heck away.
[19:53] <dobey> yep. already have breaks/replaces of ubuntuone-installer in ubuntuone-control-panel in our daily builds even :)
[19:54] <infinity> dobey: Yeah, but this -data bug implies that it'll ship the installer.desktop, so it'll need a Replaces as well (or, like I said, maybe just a hard Conflict to force removal)
[19:56] <dobey> infinity: ah. i need to update the description for that, sorry. it was going to, then i realised there is no point for it, and just put that file in ubuntuone-control-panel instead
[19:56] <infinity> Check.
[19:58] <dobey> was going to and even built a package, and lintian complained about .desktop without the binary in the same package, and i was like "oh, duh, why did i do that?" :)
[20:10] <skaet> thanks infinity
[20:13] <infinity> Right, okay, I'm really going to lunch now. :P
[22:09] <stgraber> cjwatson: I just upgraded using your PPA and the first dist-upgrade failed: http://paste.ubuntu.com/1199608/
[22:09] <stgraber> cjwatson: not sure if that /video.lst is something wrong in the new grub2 or something else
[22:12] <stgraber> cjwatson: calling apt-get install --reinstall on the linux-image package succeeds, so I guess it may have been some weirdness when having both a kernel and the new upgrade installing at the same time
[22:17]  * stgraber reboots to see if the new shiny grub at last boots that system :)
[22:20] <stgraber> cjwatson: ok, so all good except that problem during the upgrade. System boots fine and I'm not getting the video mode error anymore (instead getting the aubergine screen from grub for a second)
[23:16] <cjwatson> stgraber: Thanks - possibly an ordering issue then.  Could you mail that to me so that I have a record of the problems all in one place?
[23:16] <cjwatson> It's probably ordering between grub-install and grub-mkconfig.
[23:53] <stgraber> cjwatson: sure, will do once I have something better than my phone to send that :)