[02:19] <rsalveti> tjaalton: are you also going to update the weston package for quantal before ff?
[02:19] <rsalveti> saw you updated it already at the git debian tree
[03:32] <pitti> Good morning
[03:46] <infinity> pitti: Hey, you're a big fan of testsuites, right?
[03:46] <pitti> indeed I am!
[03:46] <infinity> pitti: And possibly glib?
[03:46] <pitti> yes, some weeks ago I worked on that to make all of them succeed -- sometimes
[03:46] <infinity> pitti: I'm trying to decide if the failing glib test on armel is an actual bug, or just the test not allowing enough slack.
[03:46] <infinity>       /* elapsed_msec should be 4000 msec +/- change for overhead/inaccuracy */
[03:46] <infinity>       g_assert_cmpint (elapsed_msec, >=, 3950);
[03:47] <infinity>       g_assert_cmpint (elapsed_msec,  <, 6000);
[03:47] <infinity> ^-- armel is asserting with elapsed_msec = 7365
[03:47] <pitti> I suppose the latter, but I haven't looked at any ubuntu stuff for the last two weeks; I can put it onto my TODO
[03:47] <pitti> it succeeded on my panda board, but it's a race condition
[03:48] <pitti> if it's urgent to get it built, a retry is fine
[03:48] <infinity> pitti: Sure.  I was going to "fix" it by just letting the test be sloppier, but I don't want to be covering an actual bug, and I don't particularly know the code.
[03:48]  * pitti has a quick look
[03:48] <infinity> pitti: Initially, I thought it was just a timeout deal, but reading the test makes it seem like they really are expecting a vaguely specificl ballpark value.
[03:50] <infinity> pitti: It's also a 2.5h build up to that point, so "retry until it sticks" seems like a suboptimal solution, if the test really does vary enough to sometimes get it right.
[03:53] <pitti> infinity: I read the test now; I agree, bumping it to 8000 or so sounds fine
[03:54] <infinity> pitti: Alright, will do.  Unless you want TILM on it (or have the power to commit it to Debian, which might be nice).
[03:54] <pitti> for 240 d-bus calls, and sleeping 100 msec 40 times, 8000 or even 10000 sounds appropriate
[03:54] <pitti> infinity: yes, I do have; we try to stay in sync with Debian
[03:54] <pitti> infinity: I can also commit the last patch revert there, and we can sync again
[03:54] <infinity> pitti: Okay, then I'll let you fix it in experimental and keep my hands off.
[03:55] <pitti> I'll also report it upstream, should be no problem to bump the timeout there
[03:55] <infinity> Cheers.
[03:55] <pitti> thanks for pointing out
[04:12] <pitti> infinity: debian exp svn now has the patch for this, and Laney's recent quantal-proposed upload as well; I'm running through Debian's test failures and see what else to change, then do the uploads
[04:16] <tjaalton> rsalveti: yes, but it needs a newer mesa which has to be finished first
[04:20] <rsalveti> tjaalton: oh, ok
[04:22] <tjaalton> rsalveti: before FF for sure
[04:22] <rsalveti> great, thanks
[04:31] <infinity> pitti, Laney: Danke.
[04:31] <infinity> pitti: Here's hoping 8s is enough for most cases.
[07:04] <dholbach> good morning
[07:11] <pitti> hey dholbach, wie gehts?
[07:11]  * pitti mehs at the numerous LP timeouts in bugs
[07:12] <dholbach> pitti, ganz ok, und dir?
[07:12] <pitti> dholbach: very well, thanks! I enjoyed my holidays a lot
[07:24] <infinity> pitti: Meh, of course there appear to be other test failures too. :/
[07:25] <pitti> infinity: yeah, I saw; I'll deal with this one, it also affects the Debian experimental buildds
[07:25] <pitti> meh, what happened to LP that it keeps timing out for just about any operation on a bug?
[07:26] <infinity> pitti: I suspect there's still some ongoing sketchiness with the combination of DC move and service migrations over the weekend.
[07:26] <pitti> oh right, that
[07:26] <infinity> pitti: Oh, except that you're talking bug management, that's been broken for longer.
[07:27] <infinity> Though, perhaps more broken today than previously.
[07:27] <pitti> MPs as well
[07:28] <infinity> There's just sadness all over right now, but it might be worth popping your head into #lanchpad-ops (internally) and see if your specific issues are known.
[07:28] <infinity> Spelled correctly, of course.
[07:40] <pitti> infinity: glib upload, take three
[07:41] <wgrant> LP is having some trouble from the DC move and kernel bugs and such atm, we're working on it
[08:13] <Laney> Oh, good work!
[08:56] <Daviey> @pilot in
[09:03]  * dholbach hugs Daviey
[09:05] <Daviey> dholbach: Hey!
[09:05] <Daviey> dholbach: I have expired from ~ubuntu-sponsors, would you mind re-adding me please?
[09:06] <dholbach> done
[09:06] <Daviey> ta!
[10:41]  * cjwatson resurrects merges.u.c post-DC-move
[10:51] <Daviey> infinity / slangasek: Hey, you've both added thoughts to bug 809221.  I'm reluctant to sponsor it, until you are both satisfied.. can you comment please? ta
[11:15] <pitti> seb128: are you fine with teh change proposed in bug 1033932?
[11:16] <pitti> seb128: I think these old crashes are fairly irrelevant (would sort out the "crashes during logout" case)
[11:17] <pitti> and ev ^
[11:17]  * pitti lunch, bbl
[11:17] <seb128> pitti, just back from lunch, looking
[11:17] <seb128> pitti, enjoy your lunch ;-)
[11:18] <seb128> pitti, that works for me!
[11:18] <Sweetsha1k> \o\ /o/ \o/ installing mysql-server from a StarBasic macro works.
[11:19] <seb128> Sweetsha1k, nice!
[11:20] <ev> pitti: if we're going to show multiple reports in a single dialog, why discard these at all? We could just do what Matthew suggests and send them all at the same time.
[11:21] <seb128> ev, because there is still no reason to greet users at login with whoopsie dialogs which turn out to be shutdown issues from the previous session
[11:23] <ev> seb128: it's not whoopsie, it's apport. Whoopsie is the daemon that shovels ready to be uploaded crash reports to daisy.ubuntu.com. As Matthew says in the report, it's about sending them the next time we have a report that deserves explanation.
[11:23] <ev> so it wouldn't necessarily be at login
[11:23] <ev> it would be the next time an application crashed
[11:23] <ev> they'd be bundled together and sent
[11:24] <seb128> I guess that would work yes
[11:25] <ev> excellent
[11:43] <xnox> kees: Asked a review on the lvm2 merge proposal. It looks to me as if the wrong init script (clvm instead of lvm2) was dropped some time in the past. Unless that was intended?  https://code.launchpad.net/~dmitrij.ledkov/ubuntu/quantal/lvm2/merge95/+merge/119696
[11:51] <ev> mpt: remind me what the multiple reports dialog looks like when there's an error processing a report? I vaguely recall the report body being replaced with a one-line message, but I'm struggling to remember what that is
[11:52] <mpt> ev, "If no details are available (for example, the crash file is unreadable), below the process name should appear the paragraph “No details were recorded for this error.”"
[11:52] <ev> ah yes, thanks
[11:53] <ev> ah, I was looking in the wrong section for that
[12:19] <pitti> re
[12:19] <pitti> ev: that sounds a bit strange, though; "gedit crashed, and btw, these other 5 crashed last time"?
[12:52] <ev> pitti: I'm not sure what the UI would look like. That's more mpt's domain than my own.
[12:58] <pitti> mpt: I don't understand "reporting crashes from the previous session the next time we have a report that deserves explanation"
[12:59] <pitti> mpt: that sounds like "gedit crashed, and btw, these other 5 crashed last time"
[12:59] <pitti> mpt: and isn't going to make things any easier
[12:59] <pitti> mpt: or do you mean showing the 5 old ones after a new crash happens in the current session, but in a separate window?
[13:03] <shadeslayer> cjwatson: mm .. if you're around could you ping me ;)
[13:05] <cjwatson> shadeslayer: just say what you want
[13:05] <shadeslayer> cjwatson: a couple of questions concerning live build, that is all
[13:05] <shadeslayer> for starters, do you populate the preseed folder manually?
[13:06] <shadeslayer> ( by putting the .seed files in config/preseed )
[13:07] <cjwatson> By "manually", do you mean in the livecd-rootfs scripts?  We don't do anything *actually* manually
[13:07] <cjwatson> But you can look at livecd-rootfs for yourself, and see that we don't
[13:08] <shadeslayer> well .. I did, and there was nothing about preseeds
[13:08] <cjwatson> Our debian-cd installation puts preseed files in /preseed/ on the ISO9660 filesystem
[13:09] <shadeslayer> alright, that qualifies as manually since it's *not* done by livecd-rootfs
[13:09] <shadeslayer> how do you generate the .seed files?
[13:09] <cjwatson> They're hand-written
[13:09] <shadeslayer> that's what I thought as wel :P
[13:09] <shadeslayer> *well
[13:10] <shadeslayer> for some reason my iso only has a isolinux and squashfs folder, and does not boot
[13:10] <shadeslayer> ( KVM says error code 0003, and there seems to be no indication of how to fix this issue on the net )
[13:10] <cjwatson> isohybrid: binary-hybrid.iso: boot loader does not have an isolinux.bin hybrid signature. Note that isolinux-debug.bin does not support hybrid booting
[13:10] <shadeslayer> right
[13:10] <cjwatson> You're seeing the same thing that our Chinese edition amd64 images keep complaining about
[13:11] <shadeslayer> ouch
[13:11] <cjwatson> I haven't had time to figure out what's going on there
[13:11] <shadeslayer> if you can give me pointers, I can give it a try
[13:11] <cjwatson> Not without doing equivalent work to investigate the whole thing from scratch :)
[13:11] <cjwatson> You'll have to dig into live-build
[13:11] <shadeslayer> ( Note that I'm building the ISO in a quantal chroot, just like you advised, and I still get that )
[13:12] <cjwatson> Yeah, this is evidently a bug in quantal's live-build, but I don't know what it is, sorry
[13:12] <shadeslayer> I was looking at lb_binary_syslinux and nothing obvious jumped at me :P
[13:12] <shadeslayer> alright
[13:12] <shadeslayer> how come the official images don't see this ? :P
[13:12] <cjwatson> Because they don't use ISO generation in live-build
[13:12] <cjwatson> They only have live-build spit out a squashfs and then deal with ISO9660 assembly separately
[13:13] <shadeslayer> ah ok
[13:13] <shadeslayer> oh, what's the ubuntu symlink for?
[13:13] <shadeslayer> it's /ubuntu linked to ./
[13:13] <cjwatson> Occasionally apt clients and the like want to access the archive via an /ubuntu base path
[13:14] <cjwatson> It just saves having to bother tracking down weird bugs
[13:14] <shadeslayer> heh :P
[13:14] <cjwatson> Oh, and I think some bits of software use it as a cue that this is a CD with a package pool on it
[13:14] <shadeslayer> oh .. that's interesting ..
[13:15] <cjwatson> It's one of those things that may or may not actually be needed any more, but it isn't a good use of time to remove it and see what breaks because it doesn't cause any problems
[13:15] <shadeslayer> is /install supposed to be generated by lb as well?
[13:15] <shadeslayer> ofcourse
[13:15] <cjwatson> /install is basically entirely informational so who cares
[13:16] <cjwatson> Well, there's mt86plus I guess
[13:16] <cjwatson> Our debian-cd installation puts that in place
[13:16] <shadeslayer> alright, /boot as well I presume?
[13:16] <cjwatson> live-build does memtest a bit differently, see lb_binary_memtest
[13:16] <shadeslayer> ( a bit confused as to why there's a grub config file there tbh )
[13:16] <shadeslayer> will do
[13:16] <cjwatson> EFI
[13:16] <shadeslayer> won't work :P
[13:17] <shadeslayer> afaik EFI only detects /efi/boot/
[13:17] <cjwatson> why not?  (don't confuse Mac support with EFI in general)
[13:17] <shadeslayer> oh
[13:17] <shadeslayer> ok
[13:17] <cjwatson> and this is only part of the EFI support, it's not all of it
[13:17] <shadeslayer> right
[13:17] <cjwatson> You may note that there is an /efi/boot/ directory too
[13:17] <shadeslayer> I was under the assumption that all EFI implementations look for /efi/boot
[13:17] <shadeslayer> yus
[13:17] <cjwatson> They do
[13:18] <cjwatson> But the image we put there gets its configuration from /boot/grub/
[13:18] <cjwatson> This makes it easier to put configuration in place at the CD-build level without having to rebuild the EFI image
[13:19] <shadeslayer> ah ok
[13:19] <shadeslayer> and what about /pics ?
[13:20] <cjwatson> Please grep the debian-cd source rather than asking about each one ...
[13:20] <cjwatson> lp:~ubuntu-cdimage/debian-cd/ubuntu
[13:21] <cjwatson> I don't want to explain every file on the image serially over IRC :)
[13:21] <shadeslayer> actually, that' was the last one, but sure ;)
[13:21] <cjwatson> Anyway none of this relates to your boot failure
[13:21] <shadeslayer> ofcourse
[13:21] <shadeslayer> I'm just curious as to what these are
[13:22] <cjwatson> May not even be used, I don't remember
[13:25]  * shadeslayer will take a look
[13:25] <shadeslayer> did you see my ping about the fedora live CD not booting?
[13:26] <shadeslayer> to be precise, it boots, but X doesn't start
[13:26] <shadeslayer> nor can I get to a tty
[13:26] <cjwatson> I don't care about that :-)
[13:26] <cjwatson> I'm certainly not going to debug Fedora kernel/userspace
[13:27] <cjwatson> I was only interested in the boot menu level
[13:27] <shadeslayer> haha :D
[13:27] <shadeslayer> ah yes, that does show up
[13:27] <cjwatson> I'll need to sit and stare at hexdumps of partition tables and the like to figure out why my test image doesn't do the same
[13:28] <shadeslayer> sounds like fun :P
[13:28] <cjwatson> I expect it to be a big bag of no fun, but that's booting for you
[13:31] <mpt> pitti, I mean adding secondary text to the normal "The application Text Editor has closed unexpectedly" alert, something like "If you send an error report, previous problems will be reported too."
[13:31] <pitti> mpt: how do you show the details of the other reports then?
[13:32] <pitti> should they pop up after the current one?
[13:32] <mpt> pitti, in the details pane, same as for the "Multiple applications have closed unexpectedly" one.
[13:32] <pitti> ah, I haven't seen that design yet
[13:33] <mpt> pitti, it was just an idea thrown into the bug report, I haven't sketched it or anything
[13:34] <pitti> mpt: anyway, this doesn't sound SRUable to me -- it's a major UI change/addition
[13:36] <ev> pitti: the expanded details UI for multiple applications closing is the same as before, only the multiple reports are separated by an hseparator in the treeview
[13:36] <pitti> mpt: for precise, my gut feeling is that we should SRU a fix as you suggested in bug 1033932 without showing the old ones
[13:36] <mpt> pitti, suits me.
[13:43] <shadeslayer> cjwatson: thanks once again :)
[14:05] <cjwatson> stgraber: It just occurred to me that I promised at UDS to turn biosdevname on by default in the installer for 12.10, and haven't yet done so
[14:05] <cjwatson> stgraber: So I think I'm going to make that change today, unless you scream ...
[14:06] <slangasek> Daviey: well, I was commenting on the general principle there but haven't read the code; not sure infinity saw my response so I guess it's up to him to comment now.  BTW, if you do sponsor it please note that mountall is now in sync in Debian, so unlike in the past the package now /should/ have a ubuntuX version number :)
[14:06] <stgraber> cjwatson: I'm not exactly sure that all the bits have been updated to deal with biosdevname, but I guess better do it now and have the rest of the cycle to fix these than have to do it at the last minute because of external pressure...
[14:07] <Daviey> cjwatson: i'd be interested in feedback from pushing biosdevname on by default.
[14:07] <cjwatson> Exactly.  I know we've fixed a number of such bugs
[14:08] <Daviey> slangasek: hah, well.. maybe i should just leave it on infinity.
[14:08] <slangasek> fine by me :)
[14:20] <smoser> cjwatson, i was looking at bug 1035279, and that lead me to https://code.launchpad.net/~utlemming/ubuntu/quantal/grub2/param-recordfail-timeout/+merge/107243
[14:20] <smoser> i'd like to call utlemmings change there a fix for bug 872244 and subsequently mark that bug as fix-released.
[14:20] <smoser> the end goal is to get the GRUB_RECORDFAIL_TIMEOUT setting back to precise.
[14:21] <smoser> but i can open a new bug if you'd like.
[14:21] <cjwatson> smoser: While I don't think I have time to handle the SRU, if you want to do the obvious backport of that patch then I'm totally fine with that
[14:22] <smoser> cjwatson, i'm not asking you to do the SRU. we'll handle that. just that you'd be ok with it. and also with marking bug 872244 as "fix-released" based on that change.
[14:22] <cjwatson> I mean, of the patch that I actually landed in quantal, which isn't quite the same as Ben's original
[14:22] <cjwatson> Well, it's kind of a sucky fix because it requires configuration to DTRT, but there's no way to avoid *that* without conflicting with a design requirement
[14:23] <cjwatson> So it's probably the best you can do
[14:23] <slangasek> pitti: hi, welcome back :)
[14:24] <smoser> cjwatson, great. thanks.
[14:24] <caribou> cjwatson: I'm working with smoser on this : I'll use the commit from http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/grub2/quantal
[14:24] <caribou> cjwatson: I think this is the one you're talking about (as opposed to Ben's original)
[14:25] <slangasek> pitti: I've reopened bug #734376 that you closed a while ago, because this is still showing up in the crashdb - it seems additional filtering is needed to make this not be a nuisance for users.  could you offer a pointer on where to start looking?
[14:25] <cjwatson> caribou: Yes
[14:25] <caribou> cjwatson: ok, fine
[14:25] <cjwatson> caribou: It was just a bit simpler really - no point in adding a new patch to the stack for this
[14:36] <smoser> caribou, cjwatson ok. i'm not going to touch 872244 as bug 669481 was the bug that was actually already used. we'll just use that.
[14:36] <cjwatson> OK
[14:36] <smoser> (i had missed that it was there)
[14:37] <silverarrow> how are 12.10 comming along?
[14:44] <pitti> slangasek: hello; thanks!
[14:45] <pitti> slangasek: ah, that'd be an apport bug then; adjusting
[14:47] <SpamapS> silverarrow: http://status.ubuntu.com/ubuntu-quantal/ ... looks like we're a bit behind schedule. But that always happens right before freezes (big pushes for big features will land rapidly)
[14:47] <pitti> slangasek: followed up
[14:47] <silverarrow> I see
[14:47] <silverarrow> I was wondering about installing the test version for ppc
[14:51] <ev> pitti, mpt: hi
[14:52] <ev> so the discussion is whether or not we should implement the multiple error reports in a single dialog: https://wiki.ubuntu.com/ErrorTracker#When_there_are_multiple_simultaneous_errors
[14:53] <ev> pitti: apologies for paraphrasing, and please do correct. Martin mentioned that he believes that two crashes happening in close proximity is rare when you factor out crashes at logout. He also suggested that the design offers no way to selectively report problems
[14:53] <ev> that is, to find a report you don't want to send and remove it from the list of ones that you do
[14:54] <mpt> pitti, so the motivation is to bring sanity to situations like <http://imgur.com/zR6II>. But I have no data on how often that happens.
[14:55] <pitti> (sorry for lagging; talking to multiple people and having a G+ meeting in 5 mins)
[14:55] <ev> I think that two crashes happening in close proximity is something we should optimize against no matter what the frequency, as always having one dialog increases our chances of "yes" responses.
[14:55] <ev> The frequency of the dialogs was something raised by seb128. I don't know how much of an effect factoring out logout crashes will have, but I'd like to do everything we can to bring it down to a single dialog.
[14:55] <ev> And indeed, if we do this then we don't have to discard heuristically determined logout crashes
[14:57] <pitti> I don't think we need to optimize for "two apps crash at the same time"
[14:57] <pitti> that seems like a small corner case to me, and really not worth making the UI a lot harder to use IMHO
[14:58] <pitti> it's just about the initial batch of "these programs crashed during logout of your previous session"
[14:58] <mpt> pitti, what do you mean by "making the UI a lot harder to use", specifically?
[14:58] <pitti> which is already covered by bug 1033932
[14:58] <mpt> Just choosing which reports to send and which not to?
[14:58] <pitti> i. e. not show them at all
[14:59] <ev> (alpols, ellen shut down her laptop while upgrading - tending to that quickly)
[14:59] <pitti> mpt: the details for one crash are already long enough as they are; adding several of them together makes it very hard to find the start of the next one, as well as selecting which ones you want to send
[14:59] <pitti> it's like thinking about 3 unrelated things at the same time
[15:00] <mpt> ok
[15:01] <ogra_> humans can handle up to seven, dont they ?
[15:01] <ogra_> :P
[15:01] <jdstrand> @pilot in
[15:02] <mpt> pitti, we could make it a proper tree with collapsed-by-default child items each with their own checkbox
[15:02] <mpt> That's independent from whether the multiple-apps alert is worth doing, because that would still be useful for the multiple-system-errors alert
[15:02] <slangasek> pitti: thanks much :)
[15:03] <pitti> mpt: reports from different users (system vs. user) would still appear separately
[15:04] <mpt> pitti, yep.
[15:04] <pitti> so, it seems to me that it is a rather large code and UI complication/change for little benefit, but if ev wants to work on it, I won't stop him of course :)
[15:05] <pitti> it's changing all three GUIs for that, too, as well as many of the test cases
[15:05] <mpt> All three?
[15:08] <seb128> bah, NBS is empty again
[15:08]  * seb128 removes cache
[15:08] <pitti> mpt: well, if we change the whole logic of the UI, we don't want to break the KDE and CLI one
[15:09] <mpt> oh, right
[15:09] <cjwatson> All three UIs, not all three GUIs :-)
[15:09] <ev> (still working, but we don't have to modify the KDE or CLI UI)
[15:09] <seb128> hum, no cache to remove
[15:10] <pitti> ev: no changes to apport/ui.py ?
[15:10] <seb128> cjwatson, did you beat me at trying to fix the NBS report? ;-)
[15:10] <ev> pitti: we still need the existing one crash UI, which then gets upgraded to multiple reports
[15:10] <ev> so the KDE and CLI UIs just don't get upgraded
[15:11] <ev> upgraded> the one crash UI changes to the multiple crash UI when multiple reports come in
[15:12] <cjwatson> seb128: Yeah, just
[15:12] <seb128> cjwatson, ok, thanks
[15:12] <cjwatson> But you beat me to saying so
[15:12] <seb128> hehe
[15:12] <cjwatson> So I figured it didn't matter :-)
[15:12] <seb128> as long as it's fixed I'm happy :-)
[15:13] <Laney> you should cron that rm ;-)
[15:14] <seb128> is there any way to turn off launchpadlib caching for a script?
[15:14] <cjwatson> You can nominate a different cache, but the problem is that there are multiple scripts involved here and it gets cumbersome
[15:14] <cjwatson> I deliberately haven't bothered because the right fix is to get this lazr.restfulclient fix in
[15:15] <cjwatson> I did it for sru-report because there was only one script there so it was easy
[15:15] <mpt> bdmurray, cjwatson, hi, any progress on the grub configuration data?
[15:18]  * xnox cause cmake is not build on i386 yet, packages that build deps on cmake ftbfs.... *argh*
[15:21] <ev> someday we'll make suspending your laptop during upgrade not eat your installation
[15:23] <ev> (I'm not counting break=top; …; sudo chroot /root dpkg --configure -a as a viable solution)
[15:23] <slangasek> ev: er, what do you mean by "suspend"?
[15:23] <slangasek> because suspending shouldn't require anything of the sort to recover
[15:24] <tedg> slangasek, Hey, so I'm looking at pamtester, but it's seemingly not in Debian.  Is that possible?  (I mean, OSS code that isn't in Debian)  http://pamtester.sourceforge.net/
[15:25] <slangasek> tedg: sure, that happens from time to time :)
[15:25] <ev> slangasek: sorry, powering off
[15:25] <tedg> slangasek, It's old, but it seems to work.  I unsuccessfully tried to get the pam-krb5 test suite out of it's tree.
[15:25] <ev> slangasek: ellen unplugged her 11.10 laptop from a projector, which hit some bug that leaves the laptop screen blank
[15:26] <ev> her only recourse in that situation is to hold down the power button
[15:26] <ev> but she was upgrading in the background
[15:26] <ev> (ellen arnold, this is)
[15:26] <tedg> ev, So you're saying we should disable upgrading while presenting on a projector?  ;-)
[15:26] <slangasek> ev: and is there a reason that the recovery mode boot option didn't work?
[15:27] <ev> slangasek: well for one it's not something she was able to find on her own, and indeed it did not
[15:27] <ev> the boot process just hung part way through
[15:27] <slangasek> hmm
[15:27] <ev> tedg, slangasek: I'm saying we should stick dpkg --configure -a in early boot
[15:27] <slangasek> because those boot menu options aren't supposed to be updated until we actually have viable initramfs
[15:27] <slangasek> er, yuck
[15:28] <ev> and if that's too slow, find a way to detect that dpkg's brain is mush
[15:28] <ev> but we shouldn't be solving this with choose your own misadventure dialogs
[15:28] <slangasek> if boot hung partway through, dpkg's brain being mush is probably not the root problem
[15:28] <tedg> ev, Eh, I think the real solution is to get btrfs in good enough shape we can use that, and then apt-snapshot with fallback.
[15:28] <ev> slangasek: seems to be the case here
[15:28] <ev> tedg: btrfs is built on unicorns and rainbows
[15:28] <ev> it's just not gonna happen
[15:28] <tedg> ev, Both of which make it better.
[15:28] <xnox> tedg: it also gives ponies =)
[15:29]  * tedg likes ponies too
[15:31] <infinity> Daviey: I was hoping for the drive-by patch submitter to justify the (in)consistency of his patch logic, but that never happened.  I'll have a look at it all and sponsor something that feels sane to me later.
[15:31] <infinity> Daviey: Well, "sponsor"... It'll not be the submitter's patch.
[15:31] <slangasek> infinity: did you see my response?
[15:32] <slangasek> explaining why we want different behavior for a trailing slash vs. only-a-slash?
[15:33] <infinity> slangasek: I did, yeah.  Though, that's an odd definition of the word "normalise". ;)
[15:37] <Daviey> infinity: well, it's in someones hands.. which is good enough for me :)
[15:39] <slangasek> infinity: it's a perfectly usual normalization of paths
[15:43] <infinity> slangasek: The second bit, perhaps, the first bit of the conditional is still a bit weird ("/" -> "")
[15:48] <cjwatson> mpt: no, sorry, too many plates ...
[15:49] <cjwatson> ev: I would go further than slangasek and say that if recovery mode doesn't work it's highly debatable whether running dpkg --configure -a is even safe
[15:49] <cjwatson> ev: For example necessary filesystems might not be mounted
[15:51] <cjwatson> shadeslayer: FWIW I'm working on the live-build merge now
[15:52] <shadeslayer> \o/
[15:52] <shadeslayer> I could upload my merge somewhere if you want
[15:52] <cjwatson> No thanks
[15:52] <shadeslayer> right, thought so :P
[15:52] <cjwatson> I'm too far along, it'd be confusing now :)
[15:52] <cjwatson> where merge => "reapply all patches one by one from scratch, and redesign the interface with livecd-rootfs along the way since live-build upstream doesn't believe in stable interfaces"
[15:52] <shadeslayer> yeah, you probably have a better idea of what you're doing
[15:52] <shadeslayer> cjwatson: fwiw livecd-rootfs will have to be changed as well
[15:52] <shadeslayer> they changed foo.list to list.foo
[15:53] <shadeslayer> ( for 3rd party archives and the likes )
[15:53] <cjwatson> Yeah, I think that's what I said :)
[15:53] <cjwatson> There's a bunch of interface changes
[15:53] <shadeslayer> hah, yes, a bit distracted by some other things atm
[15:54] <shadeslayer> yeah
[15:54] <shadeslayer> cjwatson: any chance the merge will also fix the boot issues?
[15:54] <cjwatson> I have no idea
[15:54] <shadeslayer> alright
[16:01] <mpt> tedg, ev, xnox: Since you asked. http://i.imgur.com/IaxrL.png
[16:01] <tedg> mpt, Beautiful, and functions!
[16:01] <tedg> functional
[16:02] <xnox> mpt: it even has kitty! =)
[16:17] <ev> mpt: that's so becoming my wallpaper
[16:18] <ogra_> telly me if you print t-shirts too ... i'll take one
[16:18] <silverarrow> how do you go about retieving a log on what goes wrong with mplayer and gecko on ppc?
[16:18] <silverarrow> I have been at this for days now
[16:18] <silverarrow> getting now where
[16:19] <silverarrow> any thoughts or ideas?
[16:20] <ogra_> silverarrow, ~/.xsession-errors
[16:20] <silverarrow> so far I have started firefox from terminal, and get some info there
[16:20] <silverarrow> oh, from terminal just like that?
[16:20] <silverarrow> or file manager?
[16:21] <ogra_> however you like, that file usually logs apps that run in your x sessiom
[16:21] <ogra_> *session
[16:21] <silverarrow> permisson denied?
[16:22] <silverarrow> http://paste.ubuntu.com/1157449/
[16:24] <mitya57> silverarrow: less ~/.xsession-errors
[16:24] <mitya57> silverarrow: it's a text file, not a script :)
[16:31] <silverarrow> I don`t understand less?
[16:32] <silverarrow> http://paste.ubuntu.com/1157463/
[16:34] <xnox> silverarrow: it's a text file you can open it in gedit, kate, openoffice, nano...
[16:37] <ev> bryceh, or anyone that knows X: around?
[16:38] <bryceh> ev, yeah
[16:38] <ev> I've got a weird one. The xorg log just says "xinit: connection to X server lost" no further details
[16:38] <ev> no EE lines or anything
[16:38] <ev> it's Intel
[16:38] <ev> not sure where to even begin to remedy this
[16:39] <bryceh> ev, reproducible?
[16:39] <ev> setting the driver to fbdev by copying the failsafe config to xorg.conf doesn't help
[16:39] <ev> bryceh: very
[16:39] <ev> it's an upgrade from 11.10 to 12.04
[16:39] <bryceh> anything in dmesg?
[16:39] <bryceh> also check lightdm logs
[16:40] <ev> nothing in dmesg...
[16:41] <ev> and just ddxSigGiveUp in x-0.log
[16:42] <bryceh> ev, hmm that just means normal exit
[16:42] <ev> yeah it does say it exited 0 there
[16:42] <ev> hm, so xinit works
[16:42] <ev> what on earth is going on here
[16:43] <bryceh> ev, from what you've described it *sounds* like X is working normally
[16:43] <bryceh> just that it's being terminated early
[16:43] <ev> so now if I run start X and switch back to the VT
[16:43] <silverarrow> xnox: sorry for being this slow, but from where in file manager do I open the text file?
[16:44] <ev> I get "No protocol specified" over and over again
[16:44] <xnox> silverarrow: support is in #ubuntu channel. They can help you. The is channel for developers, developing ubuntu.
[16:45] <bryceh> anything in your .xsession-errors?
[16:45] <silverarrow> no they can`t
[16:46] <ev> bryceh: settings schema 'org.gnome.desktop.interface' is not installed
[16:46] <silverarrow> xnox, if they could I would not have been sent here
[16:47] <silverarrow> but if you don`t have time, I shall have to come back another time
[16:47] <silverarrow> it`s all right though,
[16:47] <bryceh> ev, tried booting into a different window manager, like gnome fallback?
[16:47] <ev> bryceh: nothing else in there other than noise from me doing startx
[16:47] <ev> bryceh: mm, how would I drive that?
[16:49] <bryceh> ev, actually, let me ask - are you seeing the login screen at all,or is it failing prior to that?
[16:49] <xnox> silverarrow: can you please open terminal, type "ubuntu-bug xserver-xorg" without quotes, press enter.
[16:50] <bryceh> ev, if you can see the login screen, then install gnome-session-fallback and then select it from the login screen
[16:50] <xnox> silverarrow: this should collect information and upload it to launchpad and create a bug
[16:50] <xnox> silverarrow: describe what's wrong, and post the bug number here.
[16:52] <ev> bryceh: no login screen at all
[16:54] <bryceh> ev, right, well then it's not the window manager.
[16:54] <bryceh> ev, a mystery with no clues!
[16:55] <bryceh> ev, any chance something errored during the upgrade?
[16:55] <bryceh> e.g. any incorrect versions installed?  leftover ppas or the like?
[17:05] <bryceh> xnox, btw when directing people to file bugs against X, unless you know for certain the issue is the xserver you should have them file "ubuntu-bug xorg".  It'll get reviewed and re-filed from there.
[17:06] <bryceh> xnox, however silverarrow's issue is unlikely to be an X bug.
[17:06] <bryceh> but hard to say with ppc
[17:09] <xnox> bryceh: thanks. noted. I was searching which package to use and it was the best "generic" yet with apport-hooks package I managed to come up with.
[17:11] <ev> bryceh: yes, sorry for not giving you sufficient background
[17:11] <ev> so this whole thing started when ellen had to press the power button part way through an upgrade
[17:12] <barry> bryceh: while you're thinking about xorg problems ;)  can you take a quick look at bug 1039097 ?
[17:12] <ev> apparently there was a bug in 11.10 where if you were connected to a projector and disconnected, you lost the screen on the laptop
[17:12] <ev> so her only recourse was to hold the power button down
[17:12] <ev> so maybe something is corrupt?
[17:13] <bryceh> xnox, and actually I'm not sure any of the apport hooks will attach the xsession-errors file since that one can contain some private info.
[17:13] <bryceh> ev, aha
[17:13] <bryceh> ev, yeah power cycling in the midst of an upgrade can leave your system in an inconsistent state
[17:14] <ev> bryceh: indeed, I had to rescue it with a usb disk
[17:14] <ev> and a few dpkg --configure -a's
[17:14] <bryceh> ev, and not likely worth your time to troubleshoot the bug...  if I were you I'd just backup everything and do a fresh install at this point, but I'm no apt guru...
[17:14] <ev> bryceh: yeah, indeed
[17:14] <ev> bryceh: thanks!
[17:15] <bryceh> ev, fwiw from what you described it *sounds* like X is working, my guess is it's something slightly higher or lower in the stack that's breaking and making X terminate early.
[17:15] <bryceh> ev, but could also be something silly like the wrong DDX driver version installed, causing an ABI break or something.
[17:16] <cjwatson> shadeslayer: Into the tedious bit - doing comparison testing to make sure all the differences in output between old and new live-build+livecd-rootfs are reasonable
[17:16] <shadeslayer> yay :)
[17:16] <ev> bryceh: okay
[17:16] <stgraber> I'm being less and less convinced that letting users use their system during a dist-upgrade is a good idea... I guess shutting down everything and using plymouth as a frontend to the upgrader would give us much more reliable upgrades
[17:16] <bryceh> barry, sure, although I have a meeting with intel in a bit so only have a few minutes to look
[17:16] <stgraber> especially in the LTS-to-LTS upgrade cases
[17:16] <barry> bryceh: np, and thanks.
[17:17] <ev> cjwatson: fair point (Sorry for the late reply)
[17:18] <bryceh> barry, yeah could be from the X transition.  Small fonts issues often are DPI issues
[17:18] <bryceh> barry, there's a GUI dialog where you can manually fiddle with the DPI
[17:18] <barry> bryceh: assuming i can get logged in ;)
[17:20] <bryceh> barry, you might also ask tjaalton if there are known issues with vmware with the new stack.  I'm not aware of any, but it's possible a driver needs updated or something
[17:20] <barry> bryceh: cool, thanks. i'll do that, though i want to get some lunch first
[17:20] <bryceh> barry, also I'd suggest refiling the bug against xorg; it's unlikely to be lightdm's fault here, plus filing against xorg would gather a lot more logs.
[17:21] <bryceh> if you can ssh into the system while it's in this state and file the bug from the command line, that'd give the maximal info
[17:21] <bryceh> barry, anyway, gotta run ttyl.
[17:38] <silverarrow> I have filed a bug on this really
[17:39] <silverarrow> xnox: , but as an issue with the gnome mplayer gecko media player setup, problem being with play in browser
[17:40] <silverarrow> I think it is something up with gecko
[17:41] <silverarrow> regardless of the error messages, gnome mplayer seems to work on its own
[17:41] <silverarrow> even the test page
[17:43] <ogra_> dpkg-source: info: using source format `3.0 (quilt)'
[17:43] <ogra_> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[17:43] <ogra_> when was that changed to an error ?
[17:44] <ogra_> (and is there any doc about how to override it... sponsoring uploads for linaro people gets hard through it )
[17:45] <slangasek> infinity: ("/" -> "") -- that's the exact opposite of what's intended, I think?
[17:47] <silverarrow> the issu is common for all powerpc
[17:47] <infinity> slangasek: If you read the patch, it leaves :/ alone, but turns / into an empty string.  I'm not sure what the point of that bit is.  I can concede that the other conditional (that strips slashes from long paths) makes some sense.
[17:48] <silverarrow> I think it might be related to the problem with flash video replacer in firefox, it does not work with browser embedded play, only as stand alone
[17:52] <slangasek> infinity: ah, ok - then I'm sure the latter is a bug
[18:17] <barry> bryceh: thanks.  i've filed bug 1039157 with updates to the problem
[19:01] <Logan_> barry: see my reply
[19:02] <barry> Logan_: thanks, will paste output...
[19:03] <Logan_> barry: if you get LLVMpipe, then it's a dupe of that bug
[19:03] <Logan_> I'm experiencing the same thing in VBox
[19:04] <barry> Logan_: i get no output
[19:04] <barry> Logan_: iow, the grep doesn't match
[19:04] <Logan_> oh
[19:04] <Logan_> hmm
[19:36] <slangasek> tjaalton: ah, I see you've fixed the libglsl issue now, great :)  does the Ubuntu mesa branch build now?
[19:59] <arges> micahg, hello. I noticed that https://bugs.launchpad.net/lucid-backports/+bug/1035365 shows you've uploaded this package to source NEW? Is there a link that tracks where this package is?  thanks!
[20:01] <Laney> arges: https://launchpad.net/ubuntu/lucid/+queue
[20:01] <micahg> arges: ah, sorry, I meant to sit down with an AA about that
[20:01] <arges> Laney, thanks, bookmarked that
[20:01] <arges> micahg, no problem
[20:02] <Laney> micahg: sit down about what?
[20:02] <micahg> Laney: what review needs to be done for source NEW and binary NEW in backports
[20:06] <tjaalton> slangasek: no there are still some missing bits due to the automake'ification, but getting closer
[20:06] <slangasek> ok
[20:07] <tjaalton> patched osmesa to build, now need to fix the dh_install phase. also, libgallium.so patch needs to be reworked, but hoping RAOF has time to have a look
[20:11] <cjwatson> ogra_: hoary or breezy or so, but only if your DEBEMAIL is @ubuntu.com or @canonical.com
[20:13] <Laney> just ubuntu.com
[20:16] <cjwatson> ogra_: actually a bit more recently than I thought.  dpkg 1.13.24ubuntu4 in feisty.
[20:17] <cjwatson> still fairly ancient history by now :-)
[20:32] <jdstrand> @pilot out
[20:33] <barry> kenvandine: com.Gwibber.Messages has a Message() method that takes two strings, but no-ops.  is this used anywhere and can I remove it?  i'm inclined to keep it for backward compatibility (i.e. it's part of the dbus service api), but it looks like it's not used, or at least useless ;)
[20:34] <kenvandine> barry, i think that might be used to emit a signal
[20:35] <kenvandine> for new a new message
[20:35] <barry> kenvandine: it's entire body is 'pass' ;)
[20:35] <kenvandine> ok, might not be used then :)
[20:35] <barry> :)
[20:36] <barry> kenvandine: i can keep it with a big XXX and then some day remove it in a cleaning pass
[20:36] <kenvandine> yes please
[20:38] <barry> cool, thanks
[20:48] <bryceh> barry, mind attaching your glxinfo to bug 1039157 ?
[20:48] <barry> bryceh: sure thing
[20:49] <barry> bryceh: oh awesome, compiz crashed
[20:49] <bryceh> barry, of course :-)
[20:49] <bryceh> barry, actually I see in the UnitySupportTest.txt attachment that yes you are on llvmpipe
[20:50] <barry> bryceh: that's interesting.  why would that be if i (supposedly) have 3d enabled?
[20:50] <bryceh> so Logan might be right that it's llvmpipe troubles
[20:50] <bryceh> barry, well llvmpipe gives you 3D, but it's software accelerated rather than hardware
[20:51] <bryceh> barry, looks like unity_support_test is failing
[20:51] <barry> bryceh: interesting.  maybe fusion doesn't present the necessary info to trick x into thinking it's got h/w suport
[20:51] <bryceh> possibly
[20:52] <bryceh> or perhaps like I mentioned earlier, something needs updated in order to work with xserver 1.13.  that's not uncommon
[20:53] <slangasek> barry: what 3d interface does fusion actually provide?
[20:53] <bryceh> barry, as a workaround have you tried running gnome-session-fallback (no effects)?  if the above is correct then at least that should work problem free
[20:54] <barry> slangasek: good question.  i don't know how to answer that.  all i know is that the fusion settings have a switch for "Accelerate 3D Graphics" which i turn on.
[20:54]  * slangasek nods
[20:54] <barry> bryceh: i could try that, if i can get back to a usable login screen ;)
[20:55] <slangasek> barry: so the X server running inside fusion needs to know how to access the 3d accelerated interface
[20:55] <barry> bryceh: bug 1039223 is the compiz crash
[20:55] <slangasek> Ctrl+Alt+F1 + login + killall gnome-session? :)
[20:56] <barry> bryceh: glxinfo attached to bug 1039157
[20:56] <barry> slangasek: let's see if i can make that work ;)
[20:58] <slangasek> GraphicsCard:
[20:58] <slangasek>  VMware SVGA II Adapter [15ad:0405] (prog-if 00 [VGA controller])
[20:58] <slangasek>    Subsystem: VMware SVGA II Adapter [15ad:0405]
[20:58] <slangasek> er, heh; that doesn't look promising
[20:58] <barry> slangasek: interesting.  killing the gnome session reverts back to the tiny fonts
[20:58] <seb128> bryceh, I don't think  the unity_support_test is having any impact in quantal
[20:59] <seb128> bryceh, the 2d session got dropped so there is no fallbacking, it just starts 3d and let it render through gl or llvmpipe
[20:59] <slangasek> barry: so unless it's mocking up one of the video card families that X knows how to do hw 3d on, which does not appear to be the case here, I think you're stuck with sw rendering inside the VM
[21:00] <barry> slangasek: sadly, i've been unable to reinstall vmware-tools.  it can't find the right kernel headers to recompile the tools (and understandably, the existing tools don't support the 12.10 kernels yet)
[21:00] <slangasek> barry: where the set of supported families is AIUI those listed in /usr/lib/x86_64-linux-gnu/dri/
[21:00] <slangasek> (or $insert_your_arch_here)
[21:00] <slangasek> oh hmm, what's /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so?
[21:00] <slangasek> looks suspiciously like vmware in the name
[21:01] <slangasek> so maybe vmware-tools is the problem
[21:01] <barry> slangasek: tbh, i've never installed vmware-tools and it's always Just Worked
[21:01] <slangasek> ah?
[21:02] <barry> yeah
[21:03] <barry> slangasek: yep, i have vmwgfx_dri.so from the libgl1-mesa-dri package
[21:03] <slangasek> yeah, and I've confirmed (from source) that .so is for VMWare
[21:03] <barry> slangasek: yes, and i think 12.04 was the first version where 3d on linux actually worked
[21:03] <slangasek> now I've told you all I know, and will stop interfering with the debugging by the X experts :)
[21:03] <barry> :)
[21:04] <bryceh> seb128, I know unity2d got dropped; is gnome-session-fallback (i.e. gnome 2d) gone as well?
[21:04] <barry> bryceh: if there's llvm bugs, and if the 3d acceleration isn't being used for some reason, then the corruption and compiz crashes make some sense i suppose
[21:05] <bryceh> barry, I've updated the bug report, I think there's multiple different problems being exposed here.  But the root is the missing drm driver like slangasek pointed out
[21:05] <seb128> bryceh, that's not installed by default and unity session will not do autofallbacking for you
[21:05] <seb128> bryceh, the fallback for unity3d is unity3d through llvmpipe
[21:06] <seb128> so I don't think the helper is even used anymore
[21:06] <seb128> unity3d is started when selected and then it's xorg's job to figure how to render it
[21:08] <bryceh> seb128, ah maybe you misunderstood... I was suggesting trying 2D as diagnosing and isolating if it's just the 3D driver that's broken.
[21:10] <bryceh> barry, apt-cache policy xserver-xorg-video-modesetting ?
[21:10] <barry> bryceh: k, sec. rebooting the guest...
[21:10] <tjaalton> barry: I think you need the kernel part for the dri driver to work
[21:11] <barry> apt-cache policy xserver-xorg-video-modesetting
[21:11] <barry> xserver-xorg-video-modesetting:
[21:11] <barry>   Installed: (none)
[21:11] <barry>   Candidate: 0.4.0-0ubuntu1
[21:11] <barry>   Version table:
[21:11] <barry>      0.4.0-0ubuntu1 0
[21:11] <tjaalton> -modesetting is not yet pulled in by default, though it wouldn't help here
[21:11] <barry>         500 http://us.archive.ubuntu.com/ubuntu/ quantal/universe amd64 Packages
[21:11] <barry>  
[21:12] <barry> tjaalton: what needs to be installed?
[21:12] <tjaalton> barry: you said it yourself. vmware-tools, which won't build against the quantal kernel?
[21:13] <tjaalton> the joys of vbox/vmware during devel series ;)
[21:13] <bryceh> tjaalton, heya
[21:13] <tjaalton> bryceh: hi
[21:13] <bryceh> tjaalton, so... known issue?  or just unsurprising?
[21:13] <barry> tjaalton: ah.  yep, i can't get it to build.  i'll contact vmware, but i suspect they're either on top of it, or won't have anything any time soon
[21:14] <tjaalton> bryceh: looks solved to me :)
[21:14] <barry> tjaalton: yeah, i really should have kept my snapshot before the last update (as i usually do), but i thought i'd weathered the xorg shuffle already ;)
[21:14] <tjaalton> barry: one of their devs is on #ubuntu-x
[21:14] <barry> tjaalton: but, i think the llvm problem causing the corruption is still an issue right?
[21:14] <barry> tjaalton: cool, i'll hop on there
[21:15] <bryceh> barry, yeah and could be #1021104
[21:16] <tjaalton> bryceh: yes it is
[21:17] <barry> tjaalton: that does look like it could be the problem
[21:17] <tjaalton> its _a_ problem :)
[21:17] <barry> tjaalton: well, *my* problem :)  subscribed now!
[21:18] <tjaalton> :)
[21:18] <tjaalton> but if vmware-tools would build then you'd not see this one
[21:19] <barry> tjaalton: right, because then i'd be using 3d and not llvmpipe
[21:19] <tjaalton> yep
[21:50] <seb128> is anyone still having a natty or oneiric install to help testing the fix for bug #1035305
[22:12] <YokoZar> Hmm, it seems like the i386 buildd for PPAs is over a day behind the amd64 one...
[22:13] <micahg> YokoZar: arch: all vs arch:any
[22:13] <micahg> and we're still missing ~20 or so builders
[22:13] <YokoZar> micahg: Ahh reasonable.  Still, my buddy uploaded directly to wine ppa rather than copying from a staging PPA so now wine is uninstallable for like 2 days.
[22:14] <YokoZar> (really wanting a feature that prevents publishing until all arch builds are complete...hell we might want that in Ubuntu proper)
[22:15] <stgraber> YokoZar: url?
[22:15] <cjwatson> You can do that by using a staging PPA.
[22:15] <cjwatson> And copy in when it's complete.
[22:15] <cjwatson> (Probably scriptable, even.)
[22:16] <YokoZar> cjwatson: right, but you have to manually copy it when it's done.  Which is some random amount of time in the future that can range from 3 to 30+ hours
[22:16] <cjwatson> Like I say, it's almost certainly scriptable.  It's certainly exposed over the API.
[22:16] <YokoZar> (according to launchpad the source package was uploaded 2 days ago)
[22:16] <micahg> cjwatson: any hope of switching squashfs to use xz compression?
[22:16] <cjwatson> micahg: No.
[22:16] <cjwatson> micahg: Kills rsyncability.
[22:17] <micahg> cjwatson: so, for live ISOs my only options are to gut packages?
[22:17] <micahg> wow...bad english
[22:17] <cjwatson> micahg: The live image size is officially due to be raised for 12.10, I believe.  cdimage just hasn't caught up.
[22:17] <YokoZar> cjwatson: scriptable maybe...though I will need a script to run for the 30 hours then.
[22:18] <micahg> cjwatson: that's great for Ubuntu, but not Xubuntu which wants to keep a 700MB ISO
[22:18] <micahg> cjwatson: is squashfs compression format configuarable on a per ISO basis?
[22:19] <cjwatson> Dunno.  Maybe.
[22:19] <cjwatson> You have no testers with limited bandwidth, then?
[22:20] <micahg> idk, if it's an option, I'll ask
[22:20] <cjwatson> Because it really does kick the hell out of poor connections.
[22:20] <micahg> or rather that was my thinking :)
[22:20] <cjwatson> I'd suggest seeing if any fat has crept into the package list first.  There's usually something.
[22:22] <micahg> yeah, I've been digging through it, most of it came from python3 and some fonts apparently, I think I can probably kill the fonts, but I'm stuck with python 3
[22:34] <bmhatfield> Hi there, I got redirected here from #debian, because I am in territory where I'm not sure where to turn next. Specifically, I am having trouble with dh_python2 adding a dependency on python 2.7.1, even when I specify XS-Python-Version. I can't figure out how to make it stop, because I need my package to work on python 2.6 and 2.7
[22:34] <bmhatfield> Is there a better place to ask for help than here?
[22:44] <jtaylor> dh_python2 uses X-Python-Version
[22:45] <jtaylor> bmhatfield: ^
[22:45] <jtaylor> and you need to build depend on python-all where python-all also includes 2.6
[22:45] <jtaylor> so oneiric or older
[22:58] <bmhatfield> jtaylor: I'm having a mental block reading your sentence there; were you saying that in order for it all to work right, I need to run my build on oneric?
[22:59] <infinity> bmhatfield: We haven't shipped python2.6 since oneiric.  The way the python-all/dh_python2 magic works is by pulling in all the available/blessed versions and then doing what amounts to The Right Thing for each.
[23:00] <infinity> bmhatfield: So, if your goal is to have a package that works with 2.6, it kinda needs to build on a release that has 2.6
[23:02] <bmhatfield> infinity:  That makes sense. I had hoped that I could work around it with a flag or something, since my syntax is 2.6+ compatible
[23:07] <infinity> bmhatfield: Well, the only reason people generally want to be able to depend on older packages is to be able to run on older releases.  If you were compiling, say, a C program linking to libc, and wanted lucid's libc6 as your lowest-common-denominator, you'd build on lucid.  This is no different, really.
[23:07] <infinity> bmhatfield: So, if the goal is to run on old releases, build on old releases, basically.
[23:14] <bmhatfield> infinity:  Thank you for the info. I appreciate it.