[02:35] <ScottK> infinity: Thanks.
[07:50] <sladen> skaet et al; am I okay to upload  bug #1048600  -docs okayed it 3 days ago
[07:50] <ubot2> Launchpad bug 1048600 in ayatana-design "[FFe] Restore "Ubuntu Medium" weights in Ubuntu's binary .deb" [Critical,Fix committed] https://launchpad.net/bugs/1048600
[08:24] <psivaa> cjwatson, installer media-info still says Alpha, is that intended?
[08:31] <xnox> psivaa: beta1 image or dailies?
[08:31] <xnox> please check both.
[08:31] <xnox> (the two are build with different parameters)
[08:31] <psivaa> xnox, i noticed on daily quantal, did not check the official beta 1 thogh
[08:32] <xnox> psivaa: dailies have interesting things like "Install RELEASE" =)
[08:42] <Laney> bah
[08:42] <Laney> sladen: breaking qt disturbs me
[08:42] <popey> Laney, medium font enabling?
[08:43] <Laney> that linked bug
[08:43] <Laney> bug 744812
[08:43] <ubot2> Launchpad bug 744812 in fontconfig "FontConfig/Qt stack choke on Ubuntu Medium font meta-data (No medium in Inkscape and too bold in Qt apps)" [Undecided,Confirmed] https://launchpad.net/bugs/744812
[08:45] <psivaa> xnox, i dont know if i am missing something but http://cdimage.ubuntu.com/releases/12.10/beta-1/ does not have any amd64 or i386 images?
[08:45] <Laney> psivaa: releases.ubuntu.com
[08:45] <xnox> psivaa: yes, there are on releases.
[08:45] <psivaa> Laney, xnox thanks :)
[08:47] <sladen> Laney: Unity-2D was the primary Qt app that was broken; but most apps have trouble with advanced fonts with more than 4 weights.  (Though this isn't the fault of the fonts).
[08:47] <Laney> so we can expect more trouble? :-)
[08:48] <sladen> if trouble == ill-designed font selection dialogues?
[08:49] <Laney> probably a subset
[08:49] <Laney> or ∈
[08:58] <tumbleweed> Laney: surely 0ad and 0ad-data go together?
[08:58] <Laney> yes?
[08:59] <tumbleweed> you asked for a separate request
[08:59] <Laney> then the sponsor won't miss the request to sync the other one
[09:05] <tumbleweed> anyway, I'm inclined to accept it. Just having a brief look
[09:05] <Laney> yeah, do
[09:05] <tumbleweed> not reviewing 0ad-data diffs, though :)
[09:06] <Laney> I didn't expect that to need a separate review
[09:06] <Laney> just its own little buglet
[09:06] <tumbleweed> agreed
[09:25] <tumbleweed> can an archive-admin unblacklist sensors-applet? bug 1049343
[09:25] <ubot2> Launchpad bug 1049343 in ubuntu "FFe: Sync sensors-applet 3.0.0-0.2 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1049343
[09:31] <iulian> Ugh, huge diffs, my favourites.
[09:32] <didrocks> sladen: available to make the upload of the ubuntu font or should I do it?
[09:45] <cjwatson> psivaa: Yes, it's intended for dailies except when we're actually preparing beta candidates.  (We forgot to flip it for beta-1 though.)
[09:47] <psivaa> cjwatson, ok, was just in the process of double checking for the official beta 1
[09:48] <cjwatson> It's part of the process docs for preparing a beta - we just screwed up.
[09:48] <cjwatson> Not desperately important though :-)
[09:50] <psivaa> yea true, may be will become ok for beta 2
[10:26] <psivaa> cjwatson, just wondering if you need any further information for bug 1051388 before i go onto destroy the vm
[10:26] <ubot2> Launchpad bug 1051388 in ubiquity "CRITICAL **: unable to create directory '/root/.cache/dconf': Permission denied. dconf will not work properly. message on amd64 vm installation" [Undecided,New] https://launchpad.net/bugs/1051388
[10:28] <cjwatson> psivaa: in general we don't spend much effort on fixing messages that only appear in terminal output and that have no practical effect
[10:29] <cjwatson> psivaa: we don't need anything else but it's low-priority
[10:30] <psivaa> cjwatson, agree i saw a similar bug, just reported not to miss anything ::
[10:30] <psivaa> :)
[10:32] <xnox> psivaa: it's a bug in dconf.... and critical is a bit misleading since it doesn't crash nor burst into flames.
[10:34] <psivaa> xnox, yes it was a little alarming at the time of that installation coz my hardware is not that powerful and the installation seemed very slow, and at times seemed hung.
[10:35] <xnox> psivaa: the reason why your installation hang is unknown, but it's interesting that it was a networkless install and in the end of the syslog there are messages of "not being able to resolve host ubuntu"
[10:35] <psivaa> yep that was going to be my next question, it correctly detected during the inital stage that there is no network
[10:37] <psivaa> xnox, i.e.  when it laid the checked conditions for available memory, power source and network connection.
[11:31] <henrix> infinity: regarding bugs #1047350 and #1046423 do you have any idea why the linux-headers packages just vanished?
[11:31] <ubot2> Launchpad bug 1047350 in linux-lts-backport-natty "linux-lts-backport-natty: 2.6.38-16.67~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1047350
[11:31] <ubot2> Launchpad bug 1046423 in linux-lts-backport-oneiric "linux-lts-backport-oneiric: 3.0.0-26.42~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1046423
[11:31] <henrix> infinity: is there any way to recover them, or the solution is to just go ahead with a respin?
[13:35] <dobey> hey all, can i get someone to poke at https://bugs.launchpad.net/ubuntu/+source/ubuntuone-installer/+bug/1048669 ?
[13:35] <ubot2> Launchpad bug 1048669 in ubuntuone-control-panel "[FFe] Drop ubuntuone-installer package from archive" [High,Fix released]
[13:57] <Laney> dobey: weren't you looking at that with infinity?
[13:58] <dobey> Laney: i was discussing the other bug, which was about adding ubuntuone-client-data (which likely won't happen at this point, as some unexpected things have come up on our side)
[13:59] <Laney> oh, well that's why I skipped over it, sorry
[13:59] <dobey> Laney: i am not sure this bug actually needs an FFe; and ubuntuone-client and ubuntuone-control-panel no longer recommends/depends on ubuntuone-installer (so it's off the image now anyway)
[13:59] <dobey> so ubuntuone-installer can be pulled from the archive without any issues now, afaik
[13:59] <Laney> all that's left is executing the removal?
[14:00] <dobey> as far as i understand, yep. i guess an archive admin has to do that
[14:01] <Laney> I don't know what people expect FFe for
[14:01] <Laney> someone else tell me :P
[14:02] <Laney> dobey: btw, have you noticed the "headline" amount of available space being wrong in the u1 control panel?
[14:02] <dobey> yeah i'm not sure this needs an FFe. i guess we might have needed one for adding ubuntuone-client-data to some deps, but i think that would be separate still as well.
[14:02] <Laney> here it says that I'm using 100% of 5GiB but I should have 205 ("Account information" gets it right)
[14:02] <dobey> Laney: i have not
[14:03] <Laney> k
[14:03] <dobey> Laney: does https://one.ubuntu.com/account/ say the right thing for you?
[14:04] <dobey> hrmm, so mine says the wrong thing in both places it seems
[14:04] <Laney> no
[14:04] <Laney> but it knows about the extra subscription
[14:05] <Laney> just not included in "Your storage"
[14:05] <Laney> (well, it's in the list but not the total)
[14:05] <dobey> Laney: i think that is a server issue
[14:05] <dobey> right
[14:05] <Laney> ok
[14:05] <Laney> shall I file a bug somewhere?
[14:05] <dobey> i'm poking someone about it right now
[14:06] <Laney> awesome
[14:12] <dobey> Laney: are you an archive admin too?
[14:12] <Laney> no
[14:12] <Laney> t yet ;-)
[14:12] <dobey> ah ok
[14:12] <dobey> heh
[14:12] <Laney> just subscribe the archive admins
[14:13] <Laney> and set it Confirmed I think
[14:32] <dobey> Laney: should i drop the [FFe] bit?
[14:33] <Laney> if you like, but I doubt it will concern the processing AA :P
[14:34] <dobey> ok, confirmed and subscribed ubuntu-archive
[14:34] <dobey> thanks laney
[14:34] <Laney> kein problem
[15:02] <doko> looking at websockify in NEW #1048679, looks ok, but needs the FFe. anyone care for a review?
[15:03] <Laney> bounce it back to the uploader and ask for him to file it
[15:03] <Laney> same with anerd afaics
[15:04] <doko> Laney, well, the request for the FFe is in the bug report. why bounce it back?
[15:05] <Laney> which bug report?
[15:05] <Daviey>  < doko> looking at websockify in NEW #1048679 ...
[15:05] <Laney> I don't see that on the release team's list
[15:06] <Daviey> They haven't e subscribed by the seems of it
[15:06] <doko> subscribed
[15:06] <Daviey> In anyway, this isn't really a Feature at all
[15:06] <Daviey> A current main project was broken into 2
[15:06] <Daviey> (Upstream)
[15:07] <Daviey> Hmm, that was my understanding.. anyway
[15:09] <Daviey> Laney: are yoiu taking it?
[15:09] <Laney> nah, you do it
[15:10] <Laney> I'm being DoSed by Unity :P
[15:10] <Daviey> My shoulders became all angled earlier, it seemed. :)
[15:10] <Laney> how 'bout that
[15:10] <iulian> That shouldn't require an FFe in my opinion but on the other hand it still remains a new package that has to go through the NEW queue and be processed by archive admins.
[15:10]  * iulian shrugs.
[15:11] <ScottK> New packages need FFe, specifically because AA's aren't generally supposed to have to deal with New in this part of the cycle.
[15:11] <doko> iulian, did you read the report?
[15:11] <iulian> doko: Nop.
[15:12] <iulian> ScottK: Indeed.
[15:12] <iulian> doko: Well Daviey said that so I commented on what he said.
[15:13] <Daviey> Hmm, Ok.  I expected to NEW it myself TBH.
[15:14] <Daviey> thanks.
[15:15] <doko> anerd rejected from NEW, because it doesn't clean the binaries, included in the source instead
[15:16] <Laney> ask him for the paperwork too when you mail please
[15:16] <Laney> who wants to take a Unity FFe?
[15:17] <Laney> bug #713423 bug #876017 bug #1046461
[15:17] <ubot2> Launchpad bug 713423 in unity "[FFe/UIFe] Unity launcher gets cluttered when having multiple partitions and/or external volumes attached" [Medium,Confirmed] https://launchpad.net/bugs/713423
[15:17] <ubot2> Launchpad bug 876017 in unity "[FFE][UIFE] Window management - We should be able to close windows in spread mode" [Medium,Fix committed] https://launchpad.net/bugs/876017
[15:17] <ubot2> Launchpad bug 1046461 in shotwell "[UIFe] [FFe] UOA integration needs to support multiple accounts" [Undecided,New] https://launchpad.net/bugs/1046461
[15:17] <Laney> take your pick
[15:17]  * Laney glances at iulian and Daviey
[15:17] <Daviey> Laney: assign me one
[15:18] <stgraber> bug 876017 is waiting for a screenshot last I checked
[15:18] <ubot2> Launchpad bug 876017 in unity "[FFE][UIFE] Window management - We should be able to close windows in spread mode" [Medium,Fix committed] https://launchpad.net/bugs/876017
[15:19] <Laney> true, it is
[15:19]  * Laney is Incompleting tuff so that people don't keep looking at it
[15:20] <highvoltage> sounds tuff.
[15:20] <Laney> well... jbicha: did you mean that to be a blocker or was it for your info?
[15:25] <jbicha> Laney: stgraber: no, that's not a blocker
[15:25] <Laney> cool
[15:25] <jbicha> it is nice for UIFE's to come with a screenshot so we can see what changed though :)
[15:25]  * Laney has been asking for a lot of nice things on release team bugs :P
[15:26] <Laney> stgraber: want to take one of the first two?
[15:31] <stgraber> Laney: I'll take 876017
[15:31] <Laney> ok
[15:31] <Laney> thanks
[15:32] <Laney> these are the ones that popey said were important for his team and weren't blocked on receiving some information / resolved already
[15:35] <iulian> Laney: I'll take the third one.
[15:35] <Laney> I assigned it to Daviey, but I'm sure he won't mind you stealing it :-)
[15:36] <iulian> Oh did you?
[15:36] <stgraber> popey: when you have a sec, I commented in bug 876017 asking for a few details. I'd also appreciate (but won't block on) having a screenshot before/after the change. Thanks
[15:36] <iulian> Daviey can take it then. :)
[15:36] <ubot2> Launchpad bug 876017 in unity "[FFE][UIFE] Window management - We should be able to close windows in spread mode" [Medium,Fix committed] https://launchpad.net/bugs/876017
[15:36] <Laney> heh
[15:38] <iulian> If he's really busy with something else, then I shall take it.
[15:39] <Daviey> i can't do it for the next hour and 20
[15:46] <iulian> Daviey: You don't mind if I steal it from you, do you?
[16:02] <iulian> jbicha: Have you tried that modified patch (06_uoa.patch)?
[16:02] <jbicha> iulian: no, I guess I could though
[16:06] <iulian> jbicha: That'd be nice.
[16:07] <popey> stgraber, thanks
[16:14] <Laney> phew
[16:14] <Laney> I feel like we got something of a handle on the release team's queue
[16:20] <iulian> We are in need of solutions, Laney... solutions!
[16:21] <Laney> so there's a group of four UIF exceptions that don't seem particularly pressing
[16:22] <Laney> bug #1049239 bug #1049236 bug #1049235 bug #1049231
[16:22] <ubot2> Launchpad bug 1049239 in unity-greeter "[UIFe] Add drop shadow under greeter menu bar" [Undecided,New] https://launchpad.net/bugs/1049239
[16:22] <ubot2> Launchpad bug 1049236 in unity-greeter "[UIFe] The indicator bar at the top of the Unity greeter should be exactly the same height as the indicator bar in the desktop after the user is logged in (24px)" [Undecided,New] https://launchpad.net/bugs/1049236
[16:22] <ubot2> Launchpad bug 1049235 in unity-greeter "[UIFe] The greeter's session change indicator should only be displayed if more than one session is installed" [Undecided,New] https://launchpad.net/bugs/1049235
[16:22] <ubot2> Launchpad bug 1049231 in unity-greeter "[UIFe] The gap between the user name and password entry is too large in the greeter" [Undecided,New] https://launchpad.net/bugs/1049231
[16:22] <Laney> opinions?
[16:23] <stgraber> they don't seem particularly pressing though mterry is poking quite regularly about them, especially the last one
[16:23] <Laney> that might be transitive poking
[16:28] <jbicha> iulian: shotwell fails to build now http://paste.ubuntu.com/1211325/
[16:29] <mterry> stgraber, :)  sorry, not particularly Important for quantal, just small change I hoped to squeeze in
[16:29] <iulian> jbicha: Gah. Could you please attach that to the bug report?
[16:31] <mterry> (design thinks they are important though)
[16:31] <Laney> qrfvta guvaxf n ybg bs guvatf :C
[16:31]  * iulian nods.
[16:38] <stgraber> ;)
[16:55] <mterry> snark aside, it does look better with the changes.  I didn't mean to be obnoxious, just wanted an answer one way or the other before we got too far past UIF
[16:57] <Laney> yeah it's just that we have a large number of changes
[16:58] <Laney> exceptions to review I mean
[16:59] <mterry> Laney, fair enough.  I have no objection if these are low on your list
[17:05] <infinity> mterry: Will you accept a verbal rubber-stamp?
[17:06] <mterry> infinity, I guess?  If that means I can push to quantal
[17:06] <infinity> mterry: I'm not sure I "get" the user/pass gap one, but the rest all look/seem like obviously correct consistency fixes to me, not "UI changes".
[17:06] <mterry> infinity, the gap one is just that I moved the user name down 12 pixels
[17:06] <Laney> You might want to make jbicha aware if it impacts his screenshots
[17:07] <infinity> jbicha: ^
[17:07] <mterry> Laney, jbicha was aware of them originally.  reminding is always good
[17:07] <infinity> Oh, wait.  He alwready signed off.
[17:07] <infinity> already, too.
[17:07] <Laney> oh, good
[17:08] <mterry> infinity, maybe I have a strict definition of UI change, but it would look different in screenshots (like no ubuntu session logo)
[17:08] <infinity> mterry: In the name of lightweight and lazy, feel free to quote me from IRC, with this uniquely identified password that NO ONE COULD REPRODUCE EVER: "platypus", and upload away.
[17:09] <Laney> UIF doesn't have the bug fix/no bug fix distinction as I understand it (because the point is to allow people to make documentation and other visual stuff based off what we're shipping)
[17:09] <infinity> mterry: No, your strict definition of UI change for the sake of the docs team is perfectly reasonable.  For the sake of FFe, though, none of those things are features, IMO, they're bugfixes.
[17:09] <Laney> hunter2 is a better password
[17:09] <mterry> infinity, heh, OK.  Thanks.  Sorry if I was a pain  :)
[17:10] <infinity> mterry: Nope, all good.  It's only a pain if we keep talking about it. ;)
[17:10]  * Laney is happy that 4 things get to go away from the list :-)
[17:10] <Laney> (and that Ubuntu gets better, of course!)
[17:38] <TheLordOfTime> anyone know if Debian's iceweasel package is related to Ubuntu's firefox package at all?
[17:38] <infinity> We forked the packaging eons ago.  If they relate at all now (other than sharing some patches back and forth), it's likely coincidental.
[17:39] <infinity> chrisccoulson would know better, though.  Maybe he's been working more closely with Debian than our previous mozilla maintainers have.
[17:40] <TheLordOfTime> well i ask because of a request in launchpad to tie a debian bug for iceweasel to a bug in ffox that has an upstream fix and a Wishlist/Triaged on Ubuntu
[17:40] <TheLordOfTime> i'm not even certain the two are related
[17:40] <TheLordOfTime> join #launchpad if you want :P
[17:40] <TheLordOfTime> that's where this discussion is happening
[17:41] <infinity> Getting it fixed in iceweasel won't get it fixed in Ubuntu, if that's the question.  We don't merge from iceweasel.  But if Mike fixes it in Debian with a backported patch, I'm sure you could point Chris at it to fix it.
[17:41] <infinity> That said, we pull new upstream versions as they're released, so if it's fixed upstream, we'll get it soon.
[17:42] <TheLordOfTime> infinity, mind hopping into #launchpad for me and explaining that?
[17:42] <infinity> I suppose?
[18:10] <plars> skaet: I was looking a bit further and found more discussion of minimum system requirements here: https://help.ubuntu.com/12.04/serverguide/preparing-to-install.html which answers my question about the disk space for server
[18:11] <plars> skaet: in the past, it seems that 1G was sufficient for all tasks selected, however right now it's barely sufficient for the base system (to get that working, you even need to manually partition and *not* use swap, because you need the entire gig for install)
[18:11] <Daviey> iulian: I assume you took it?
[18:11] <plars> Daviey: ^ also
[18:12] <plars> anyone happen to know if 1G was really sufficient for all tasks in 12.04? (/me is doubtful of this)
[18:13] <iulian> Daviey: Yup.
[18:13] <iulian> I'll take care of it.
[18:13] <stgraber> plars: for 32bit, yes, for 64bit, mostly
[18:13] <plars> stgraber: for 64bit, 1G is barely enough if you use all of it for install, and select no tasks in quantal
[18:49] <plars> skaet, Daviey: Any feedback on the 1G minimum for Ubuntu server?
[18:53] <skaet> plars,  I'm not sure if this is expected or not,  so defering to Daviey to weigh in if it should be a bug or not.   At any rate,  the serverguide/preparing-to-install.html should probably get updated to reflect current reality.
[20:36] <skaet> infinity,  https://bugs.launchpad.net/ubuntu-cdimage/+bug/950477 - any update?
[20:36] <ubot2> Launchpad bug 950477 in ubuntu-cdimage "md5sums are not accurate for daily arm images" [Critical,Incomplete]
[20:37] <skaet> do we still have this problem?
[20:44] <cjwatson> Only Lubuntu seems to still have daily-preinstalled.
[20:44] <cjwatson> cjwatson@nusakan:~/cdimage/www/full/lubuntu/daily-preinstalled/20120917$ md5sum -c MD5SUMS
[20:44] <cjwatson> quantal-preinstalled-desktop-armhf+ac100.bootimg: OK
[20:45] <cjwatson> quantal-preinstalled-desktop-armhf+ac100.tar.gz: OK
[20:45] <cjwatson> I think I got this with the Python rewrite if nothing else.  It substantially rearranged the handling of checksums in general.
[20:45] <cjwatson> I'll close it after the TB meeting finishes.
[20:47] <infinity> ScottK: All the KDEish stuff in precise-proposed seems to be v-done and well-aged, should we do a massive release today to clean up the pending SRU page?
[20:47] <infinity> ScottK: (I'd JFDI, since it's my day, but not sure if you were waiting on something specific before doing the update)
[20:47] <ScottK> infinity: There are a couple that aren't quite aged yet.
[20:48] <ScottK> libksane and kdenetwork.
[20:48] <infinity> ScottK: Oh, I didn't see the new kdenetwork upload.
[20:48] <cjwatson> I possibly ought to ensure that all pre-existing files have correct checksums.
[20:48] <infinity> ScottK: (I was happy to let libksane slide)
[20:48] <ScottK> infinity: If you could look at kdenetwork and see if it's OK, then I'd be good with pushing them all.
[20:49] <Laney> what's happening with the (precise) image build failures that are coming in?
[20:49] <ScottK> libksane and kdenetwork are just breaks/replaces so I don't think aging them is important.
[20:49] <Laney> is this some known failure mode? E: Failed getting release file http://archive.ubuntu.com/ubuntu/dists/precise/Release
[20:49] <Laney> at debootstrap
[20:49] <infinity> cjwatson: If you're going to sum them to check, then there's not much point in the caching/reusing thing at all, and we may as well just run the sums on the whole directory every time.
[20:50] <infinity> Laney: Could be some firewall rules got tightened.
[20:52] <cjwatson> infinity: As far as I know the new code doesn't sum them to check.
[20:52] <cjwatson> infinity: "all pre-existing files have correct checksums" - I meant me manually checking things like precise release
[20:52] <infinity> cjwatson: Oh, right.
[20:52] <infinity> cjwatson: I think I did all of precise post-release, haven't checked point-releases though.
[20:53] <cjwatson> I think I just managed to avoid some stupid corner case that was too painful to debug in shell.
[20:53] <infinity> (I may have done everything in www/ when I did the precise checks, but I don't recall for sure now)
[20:53] <cjwatson> I rewrote that entire section of code from scratch in a more Pythonic kind of style, and it has a load of unit tests
[20:54] <cjwatson> It still has a slightly nasty bit incorporating s/// expressions
[20:54] <infinity> ScottK: The diff for kdenetwork seems perfectly reasonable, but doing an upgrade test to make sure it actually does what people expect would be nice.
[20:54] <cjwatson> Which *cough* calls out to sed, but you didn't see that code
[20:54] <infinity> ScottK: And I'm not sure what "friendly" package manager kubuntu uses, but if it's update-manager, a conflict won't actually let you upgrade at all, it'll just put the package on hold.
[20:55] <infinity> ScottK: (Until you use something more violent, like apt-get dist-upgrade)
[20:56] <infinity> cjwatson: Yay for forking instead of doing it in Python.  That's what, well, all of my Python looks like. :P
[20:56] <cjwatson> infinity: I couldn't think of a way to do that little bit natively without unreasonable pain
[20:58] <ScottK> infinity: This'll only come up on release upgrades, so I think that's fine.
[20:59] <infinity> ScottK: It won't come up on post-release upgrades that were left in a sad state?
[20:59] <ScottK> I suppose.
[20:59] <infinity> ScottK: ie: I already upgraded from 10.04 to 12.04, and that old package is still installed, and now I upgrade to the SRU.  What happens?
[20:59] <ScottK> You need to dist-upgrade
[20:59] <infinity> ScottK: Or was it just completely broken anyway, due to the file overlap?  Which, I suppose it would be.
[20:59] <ScottK> Muon (the KDE thing) will tell you that.
[20:59] <infinity> Alright.
[21:00] <ScottK> Then it's clickety click.
[21:00] <infinity> ScottK: Then someone just doing a quickie lts->lts test to verify would be nice, I guess.  I'll concede the "already upgraded, now SRU" thing probably isn't a concern, cause they were already broken.
[21:01] <ScottK> Actually it's more complicated.  The package only existed in Maverick, so it's sequential upgrades that are the problem.
[21:01] <ScottK> LTS to LTS is fine.
[21:02] <infinity> ScottK: Oh, that's a bit irksome to test.
[21:02] <ScottK> Yes.
[21:02] <ScottK> Which is why I didn't do it.
[21:12] <skaet> infinity - we likely to get the fix for: https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/859552?
[21:12] <ubot2> Launchpad bug 859552 in live-build "[FFe] Wubi should use ext4 disk images" [Undecided,Triaged]
[21:13] <infinity> skaet: That's up to ev and the strange win32 build of e2fsprogs that wubi uses.
[21:13] <infinity> ev: ^
[21:38] <scott-work> is there a reason the ubuntu studio images are building (and failing) for precise? am i asking an exceedingly silly question?
[21:39] <stgraber> scott-work: looks like something's wrong with the build machines.
[21:39] <stgraber> scott-work: Laney poked IS about it already
[21:39] <scott-work> stgraber: thank you :)
[22:06] <xnox> infinity: skaet: well I have a work item to learn/automate wubi building + e2fsprogs is kind of my thing nowadays.... maybe I should look into that.
[22:07] <skaet> thanks xnox
[22:07] <infinity> xnox: If you can sort out how to get wubi using a current and built-from-source-reproducibly version of e2fsprogs, that would be swell.
[22:08] <stgraber> oh yeah, fixing that one would be neat. Last cycle I managed to get wubi to work with ext4 but sadly there was no source matching the .exe I found somewhere on the internet, so not something we really wanted to ship (or actually, would be allowed to ship)
[22:08] <xnox> infinity: i used to have plenty of 'experience' (read vodoo magic & pixie dust) to make random builds for mingw platform, that is "reproducible" builds for Windows ;-)
[22:09] <xnox> infinity: would lp.net allow uploads for a mingw-w64 arch? =)))))
[22:09] <infinity> xnox: Yeah, we might want to revisit if we think mingw would pass an MIR, and you could just add e2fsprogs-win32 to the i386 build.
[22:09] <stgraber> actually, thinking about it, why do we even need e2fsprogs in wubi?
[22:09] <xnox> or do I have to hack up arch all packages?
[22:10] <stgraber> IIRC it's for e2fsresize, but we can easily do that on first boot, can't we?
[22:10] <infinity> stgraber: e2resize, I think.
[22:10] <xnox> don't we have all the pre-install magic for arm?
[22:10] <infinity> stgraber: Doing it on first boot is doable (see jasper), but it has to be done from the initrd, which makes things more fragile.
[22:10] <xnox> "all figured out" (tm)
[22:11] <infinity> stgraber: Cause you then have to regen the initramfs after.
[22:11] <stgraber> infinity: well, I'm pretty sure I prefer to debug something going wrong in the initramfs than in a windows version of e2resize...
[22:11] <infinity> stgraber: I was going to examine live-resizing at one point to try to avoid that, but I suspect it's safer to do on an unmounted filesystem, no matter what people say.
[22:12] <stgraber> infinity: yeah, I've been doing online resize a few times and it usually works fine, though I don't remember ever doing it on the root partition with a lot of files open...
[22:12] <stgraber> infinity: I guess doing it from a very early upstart job, blocking the rest of the boot on it should be safe and definitely easier to debug
[22:13] <infinity> stgraber: Well, doing it from the initrd isn't hard to debug.
[22:13] <infinity> stgraber: It's just the fiddly part about removing the magic and regenerating the initrd after you've successfully booted once.
[22:13] <infinity> stgraber: Which isn't all that tough, either.
[22:13] <infinity> stgraber: So, we COULD do all of that.  Pretty big post-FF feature, though.
[22:13] <infinity> (From a QA/testing perspective)
[22:14]  * xnox always did online resizes (no downtime) even with drdb & hearbeat, lvm + raid..... without a hitch. Maybe I just got lucky all ~30 odd times ?!
[22:15] <stgraber> infinity: can't we use a trick like checking for the number of mounts on the partition and call e2resize if == 0? that should avoid the whole re-generating a new initramfs part of the process
[22:15] <xnox> increase, as online shrinking is not supported.
[22:15] <infinity> stgraber: Ew.  No, I'd rather the logic just wasn't in there.
[22:18] <mcasadevall> /join #TDRevolution
[22:18] <mcasadevall> bah
[22:39] <ogra_> stgraber, infinity, just regenerate the initrd from the running initrd, not that hard ...
[22:40] <ogra_> a few bind mounts and a chroot call