[01:08] SpamapS: I don't know if you saw the followup email, but I was able to get the Quantal version of cups 1.6.1 to build on precise (is that right? 12.04) [01:09] I had to comment on one line of the apparmor profile for the cupsd binary, but then it started up just fine using my old cupsd.conf. Now the ios 6 devices see the printer instantly. [01:09] I also think that your method looks a LOT simpler than the way that I did it, but I now have a _slightly_ better understanding of what is going on during deb builds. [01:10] Just slightly though...there's still a lot going on in the background (tons and tons of dh* commands rolling by) that I don't yet grok. :-) [01:10] Thanks for the feedback, see you at a LUG or maybe SCALE. [03:11] doko_: new cairo-5c in Debian still fails on quantal [03:22] doko_: sounds like you already know this :), nevermind === cpg is now known as cpg|away === Guest52174 is now known as vibhav === cpg|away is now known as cpg === fisted_ is now known as fisted === cpg is now known as cpg|away [08:34] doko_: Thanks for sorting out java3d. [09:24] something wrong with the universe repo? bug #1066445 [09:24] Launchpad bug 1066445 in apt (Ubuntu) "Crashes doing update or upgrade operations" [Undecided,Confirmed] https://launchpad.net/bugs/1066445 === morphis_ is now known as morphis === dendrobates is now known as dendro-afk === yofel_ is now known as yofel [12:33] Mirv, confirmed on a fresh install on amd64 [12:33] thanks === doko_ is now known as doko [12:54] Laney, there are some haskell ftbfs on arm, which don't look like the usual timeouts, e.g. https://launchpadlibrarian.net/119722073/buildlog_ubuntu-quantal-armhf.haskell-chell_0.3-1build1_FAILEDTOBUILD.txt.gz === dendro-afk is now known as dendrobates [14:06] hi, i've uploaded a new media player to Ubuntu Software Center 2 day ago but my status is pending review. anyone knows why is it taking so long to show? === dendrobates is now known as dendro-afk [14:30] PN1: there are a ton of other apps in front of yours waitin for review is probably the cas.e [15:17] doko: already known, reported upstream (http://hackage.haskell.org/trac/ghc/ticket/7316), and not likely to be fixed for 12.10. I already removed all the out-of-date binaries affected by this. [15:29] apt-get -qq update [15:29] Segmentation fault (core dumped) [15:29] that does not happy make [15:52] having quantal/universe in the sources.list at the same time as having quantal/main seems to cause that [15:53] lamont: Seems fine here [15:53] penguin42: it's quite possibly mirror issues [15:54] as in my mirror [15:54] lamont: http://paste.ubuntu.com/1279419/ is my sources.list [15:55] that it's working well elsewhere tells me it's likely just me and that I'm special. :( [15:55] no worries. [15:55] * lamont digs deeper [15:57] lamont, bug 1066445 [15:57] Launchpad bug 1066445 in apt (Ubuntu Quantal) "apt-get crashed with SIGSEGV in pkgCacheGenerator::ListParser::NewProvides()" [Critical,Confirmed] https://launchpad.net/bugs/1066445 [15:57] fact [15:58] 0x00007ffff7b4dd20 in pkgCacheGenerator::ListParser::NewProvides(pkgCache::VerIterator&, std::string const&, std::string const&, std::string const&) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 [15:59] it seems to be triggered by the record for grub-ieee1275 in universe [16:02] though interestingly, apt-get update seems happy if universe is there and main is excluded === mcclurmc_away is now known as mcclurmc === dendro-afk is now known as dendrobates [17:09] lamont, what were you starting from? we're trying to figure out the pattern. [17:33] doko: no, that is the usual [17:47] skaet: the last reboot-requiring (desktop) upgrade on the machine was probably yesterday morning (-0700) [17:49] since the reboot was 18 hours ago [17:50] skaet: when I commented out universe and did the dist-upgrade, it installed debian-installer, nothing more [17:52] * lamont reboots his irc box, brb === Quintasan_ is now known as Quintasan === cpg|away is now known as cpg === dendrobates is now known as dendro-afk === Ursinha-afk is now known as Ursinha === rsalveti_ is now known as rsalveti === cpg is now known as cpg|away [19:36] got caught by a pretty nasty regression when I upgraded from 12.04 to 12.10: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1066324 [19:36] Launchpad bug 1066324 in grub2 (Ubuntu) "core.img too large for embedding with msdos partition style" [Undecided,New] [19:40] for some reason, 12.10's core.img generation results in larger files than 12.04's [19:40] had that too :/ [19:41] or still have it, but I resized my boot sector to fix it [19:41] so, combinations that worked perfectly under 12.04 no longer work under 12.10 and sadly you don't find out (or at least I didn't) until you try to reboot [19:41] when did you setup the partitioning of your machine? [19:41] if you pay attention during upgrade you do find out [19:41] it's changed over time [19:41] jtaylor, had no warning during the upgrade... [19:42] there should be a message that core.img is to large [19:42] but its easy to overlook [19:42] if there was, I overlooked it... should be pretty big blocker [19:42] it kind of sucks that you land in a rescue prompt then instead of grub being left unchanged [19:43] as for the partitioning, I migrated the system into purely LVM during its 12.04 lifetime... but had no issues with grub after [19:43] yes... if grub had been unchanged it would still have worked... and rescue prompt is rather useless at this point [19:44] had to move the system to a GPT partition table to resolve it [19:44] just sizing it to a sane size is enough [19:44] unfortunately that takes ages [19:44] even though there was a full 1M at the start of the drive before the first partition [19:45] ok that is different than what I had [19:45] sizing it to 1M fixed it for me [19:46] it's solved for me now, but I can't image that I'm the only person that has everything residing inside LVM with an MSDOS style partition table [19:46] cjwatson: you may want to look into that again ^ [19:47] I hit it at the time bug 1051154 was opened, after resizing and the bug being closed I didn't bother about it anymore [19:47] would love to know why the core.img has increased in size from 12.04 though... [19:47] Launchpad bug 1051154 in grub2 (Ubuntu) "mdraid1x core image too large for minimal MBR?" [High,Fix released] https://launchpad.net/bugs/1051154 [19:47] but my core.img is still larger than 32k [19:48] jtaylor, yea, I read that report... seemed like an off by 1 bug based on the feedback... but that doesn't seem to be what I'm running into [19:48] jtaylor, what's the exact size of yours now? [19:48] 33294 [19:49] odd, even larger than mine... so if your's fit, mine should have [19:49] I now have 2024 sectors at the start [19:49] it where 64 before [19:50] maybe there wasn't a full 1M free at the start before I moved to GPT... [19:50] what does sudo fdisk -l /dev/boot-device say for the start? [19:50] could have sworn there was [19:50] I've repartitioned the device now [19:51] booted to a live-cd attached an external drive and pvmoved all the volumes off the internal drive... then repartitioned as GPT and pvmoved them all back [19:51] though I think I saved the partition table layout as a precaution... let me see [19:56] jtaylor, looks like it started at 63 [19:56] found the backup file... *sigh* [19:57] I'm going to mark it critical, my machine was not partitioned to long ago (about 1-2 years) so its probably a not to uncommon thing [19:57] and very hard to fix for inexperienced users [19:57] very [20:02] I believe that everything in lvm is one of the automatic partitioning configurations for partman isn't it? or does that one keep /boot out? [20:06] don't know [20:07] I too use lvm, probably its somehow related to it [20:07] would explain why there aren't more reports of this [20:09] it is related to lvm... if you rebuild core.img without the lvm module it's small enough to fit [20:10] and looking at the automated recipes, they all appear to have /boot outside the lvm volume [20:46] jamin,jtaylor: it'll definitely fit in 1MB. As for the case where you only have 63 sectors at the start, no Ubuntu installer for the last few years will produce that layout by default, and I'm afraid I have approximately zero likelihood of being able to fix it by release [20:47] cjwatson: figured as much, as it only appears to affect lvm feel free t reduce the importance or set it won't fix [20:47] cjwatson, then it's safe to say that a number of people are going to wind up with unbootable boxes [20:47] jamin: yes [20:47] but I can't fix it [20:47] not in time anyway [20:48] we'll have to release-note it [20:48] even if it's not "fixed" in an automated fashion is it not possible to have it seriously error in an in your face sort of fashion? [20:48] not in time [20:48] I mean, that's the only terribly plausible way to "fix" this at all [20:48] but I have sooooooo many things to do [20:49] of course people would complain about the resulting upgrade failure too, and it's not like moving partitions around is an easy thing to do [20:49] how about an upfront check? [20:49] it would at best defer the upgrade failure [20:49] or defer the boot failure [20:49] something at the start of the upgrade process that checks for only 63 sectors on the drive? [20:50] if somebody else wants to attempt that ... [20:50] it won't be me [20:50] (and of course plenty of layouts do still work fine with 63 sectors, particularly after I fixed the off-by-one error in grub-setup) [20:50] any reason the core.img increased in size? [20:50] no very straightforward way to tell which in advance, without having the upgraded code [20:50] grub 1.99 -> 2.00 - various bug fixes which involved bigger code [20:51] guessing it's not possible to get it back down to 12.04 size [20:51] no single cause [20:51] it may be possible but requires serious work; I looked and there was no single obvious smoking gun [20:51] just general drift [20:51] I'd think a blanket warning for any 63 sector configuration would be better than waiting to see which can no longer boot [20:51] I don't mind if somebody else wants to do that [20:52] like I say, it's simply not physically possible for it to be me at this point, due to lack of hours [20:52] yea, understood... just thinking of the fallout if this hits any decent number of users [20:52] nearly every boot loader bug is critical for those it hits [20:53] agreed, just never seen one from an upgrade like this [20:53] yours is likely because of the combination of GPT and LVM; I'm fairly sure MBR and LVM fits [20:54] nope... was MBR and LVM that caused it [20:54] oh, wait, your grub-install debug output was from after you moved from GPT [20:54] moved to GPT to resolve it [20:54] way to file a confusing report :P [20:54] yes [20:54] sorry... couldn't file from a non-bootable system [20:55] better not to mention the grub-install debug output then - I'll delete it from the description as it's actively misleading [20:55] sounds like I could have stayed with MBR if I'd just moved my partitions down to start at 1MB in [20:55] Yes [20:55] sorry... wanted to show which modules were being used [20:55] That's the default partitioner configuration since 10.04 [20:56] Now, gparted may be stupid [20:56] I mean the actual Ubuntu installer partitioner [20:56] gparted puts it at 1M [20:56] Confusing given jtaylor's comment, unless that was a more recent fix [20:56] I think I used gparted in default config for my setup [20:56] I'd replaced the drive and migrated the installation from rotation to ssd [20:56] Bear in mind that gparted may have different defaults for SSD [20:56] but maybe I also left the boot partition at stock settings [20:57] its been a while [20:57] libparted typically tries to pick up the topology from the driver [20:57] *drive [20:57] So this kind of thing basically only affects people who've done by-hand partitioning with non-default tools, or who've upgraded since before 10.04 [20:57] think I may have used cfdisk to layout the partition on this SSD originally [20:57] Yeah, cfdisk is dark-ages stuff [20:58] seeing that now... =( [20:58] I don't believe it's really kept up with modern alignment requirements and such === cpg|away is now known as cpg === cpg is now known as cpg|away === lfaraone|sh is now known as lfaraone === cpg|away is now known as cpg