=== v is now known as vorian [01:30] Would it be possible to separate malloc() from glibc? [01:31] Yes; why would you want to? [01:32] I'm having severe memory use issues-- 4 gigs just isn't enough for Chrome, Rhythmbox, Xchat, and Thunderbird all at once--so I've switched allocators to see if any of the others out there do better [01:33] I wouldn't imagine that they'd do appreciably better. You could always try LD_PRELOAD something with a different malloc/free set. [01:33] Particularly in this case Hoard, although Boehm with malloc() overriding is a potential direction (that I'd like to avoid) [01:34] yes that's what I have going now [01:34] ld.so.preload [01:34] but preloading of course breaks wine [01:34] well, it breaks multilib in general [01:34] this is a known bug from about 47 releases ago [01:35] (it's #33994) [01:35] Oh, right. You need a different preload per arch. [01:52] RAOF: What do I do if Thunderbird keeps eating 1.8 gigs after 2-3 hours but under a different allocator it only eats 400 megs? [01:53] Oh, wow. That's a big difference! [01:53] maybe. [01:53] I guess you work out what the different allocator is doing differently and file a bug at the appropriate level. [01:53] It could also hit the same end state just further down the line, or I haven't sufficiently loaded the application yet to cause the access patterns that bring trouble [01:53] But yeah [01:53] Oh, right. [01:54] thunderbird has been resident 1800 megs lately, and i've restarted it multiple times today [01:54] resident doesn't even count what's in swap :| [01:54] That's not 400MB after 2-3 hours of use under the new allocator? [01:55] We'll see. It was mostly hypothetical [01:55] Ah. [01:55] I don't think a lot of experimentation happens with allocators. [01:56] but it's long been known to me that the entire heap model is a huge failure in design anyway. [01:56] Got anything better? :) [01:57] Hoard seems to be designed for modern systems. That's what I'm trying to determine though. [01:57] I mean, there are certainly known-failings in heaps. [01:58] You gotta realize, with brk() heap, if you allocate 300 megs, then free all but the highest allocation, you have 1 megabyte in use and 300 megs that the system thinks are in use [01:58] Yeah; fragmentation is an issue. [01:58] fragmentation and other stupidity can land you with a huge heap. Imagine how that pans out with threaded applications. [01:59] the buddy allocator in glibc was pretty fantastic when it was made, but it may be behind the times.. but that only holds true if something else significantly improves performance or memory usage, or both [02:03] It's a bit of a pity you can't (easily) run C code in a GC'd VM ;) [02:03] GC has its own issues, like touching all over memory a lot messing with the CPU cache state and of course if anything's in swap... [02:04] in a VM it's a little less of an issue [02:04] since assignments of pointers can be tracked easily [02:04] Right. [02:05] and of course there's lots of research there--Mono in fact uses a compacting GC that pauses the world, alters pointers, and defragments memory to free more back to the system [02:06] Right - not (yet) by default for mono, but the Microsoft CLR has used that for ages. Presumably Java does the same. [02:07] Java recently stopped ref counting for a really crappy garbage collector that's much worse [02:07] but they may have moved to a better one since then [02:08] erm [02:09] hi lifeless [02:09] java has had that for decades [02:09] current java stuff is concurrent multi-threaded gc without stop-the-world [02:09] ... java's been around for decades? [02:10] *I* haven't been around for decades and I remember when Java first came into existence. [02:11] anyway it's not technically infeasible or really difficult to implement a C to CIL compiler [02:11] (sun/oracle) java doesn't refcount anyhow - I don't think it evcer has [02:11] it inherited its initial gc model from smalltalk [02:11] it's on the level of implementing a C to x86 compiler, plus some muckery about how to handle pointers and malloc and such [02:11] which is generational [02:12] which isn't to say that building a compiler is a child's task; just that when we're talking about how difficult a task is, it turns out building an ABWR reactor isn't "difficult" because it's a normal task in some context [02:13] The bigger question is do you want to run absolutely everything on top of Mono [02:13] Bluefoxicy: java was created in 91 [02:13] so, > 1 decade :P [02:13] and it -heavily- learnt from smalltalk, which goes back to early 70s [02:14] (and, as an aside, if you did build C onto CIL, you could easily have Mono catch things like memcpy() more data than the total length of an array into an array and block it) [02:14] automatic run time analysis :D [02:45] are there any known problems with wifi (intel variants thereof) in precise currently? [02:46] N [02:47] google is freaky [02:48] searching for "BUG: unable to handle kernel paging request at fffffffffffffb88" finds the bug apport filed for me about 5 minutes ago [02:48] My Intel card drops out in Oneiric, and then brings up a network passphrase window every 3 minutes. [02:49] So I will occasionally unlock my laptop and find 200 windows open all asking for the wireless password. [02:49] nice [02:49] this was an oops though [02:53] I know of no oopses. [02:53] I think .11n is still a little flaky, but disconnect-y flakey, rather than oopsy. [02:58] RAOF: could you take a very quick look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/982738 then? [02:58] Launchpad bug 982738 in linux (Ubuntu) "BUG: unable to handle kernel paging request at fffffffffffffb88" [Undecided,New] [03:00] That seems like a bug? :) [03:00] heh fair enough [03:00] I don't have much to say about it; I'm sure if the kernel team needs more info they'll ask. [03:00] ok [03:00] “fffffffffffffb88” seems pretty unlikely to be a valid memory address, though ;) [03:08] yeah [03:08] it's not a surprising failure, on the face of it :) [03:19] -0x477 seems like a perfectly good place to store data, if you ask me [04:23] good morning [04:24] slangasek: sudo> I don't see a reason why it shouldn't invoke pam_env for itself [04:24] pitti: [04:24] pitti: though in practice, it's missing some other bits to be able to use it effectively... sudo doesn't export pam_getenvlist() to the session environment ;) === doko_ is now known as doko [06:17] is there a tool to purge obsolete kernel images? [06:17] tjaalton: the best that we have is computer-janitor [06:17] pitti: oh it's still available? thanks [06:17] sudo dpkg -P linux- works reasonably well, too (and then pick) [06:18] but in general it's a major unsolved problem [06:18] yeah, dpkg works for me, just a friend was asking/complaining about those :) [06:40] good morning [06:45] hey dholbach [06:46] hi pitti [07:06] hi, could I interest someone into reviewing this SRU? https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/978884 [07:06] Launchpad bug 978884 in landscape-client (Ubuntu Oneiric) "SRU: release 12.04.3 for lucid, natty and oneiric" [Undecided,New] [07:12] ahasenack: there is not much to approve, it's got a standing SRU exception anyway? [07:13] pitti: yes, but some steps must be followed, I guess the approval is the first one, then I can start hunting for a sponsor and get it uploaded to proposed [07:15] ahasenack: so, consider it approved by https://wiki.ubuntu.com/StableReleaseUpdates#Landscape [07:15] pitti: don't you need to add a tag to it? [07:15] no, we don't do that for SRUs [07:15] we review uploads from the unapproved queue [07:26] pitti: ok, thanks, so we need an uploader now :) [07:27] ahasenack: I'll do patch piloting later today, so I'll grab them unless someone beats me to it [07:27] pitti: ok, thanks [07:57] @pilot in === udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti [08:03] pitti, good morning [08:03] bonjour jibel [08:03] pitti, I proposed a fix for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648161 can we have it in Precise ? [08:03] Debian bug 648161 in autopkgtest "autopkgtest: Extracting sources with ~ or + in the version fails" [Normal,Open] [08:06] jibel: ooh, thanks [08:07] jibel: oh, so it was even me who reported that, sheesh [08:19] jibel: uploaded; needs another -release member to approve the upload [08:19] jibel: merci beaucoup for fixing this! [08:21] pitti, thanks for uploading it ! [08:28] infinity, slangasek: the new armhf linker path isn't yet in the debian eglibc repo, correct? [08:32] doko: It will be shortly. [08:32] doko: I needed a nap first. :P [08:33] cd .. [08:33] Err. [08:33] ^-- See? [08:33] ssh infinity cd /bed [08:33] pitti: I did go to bed, and it lasted about 4 hours. :/ [08:34] pitti: After having been awake for about 40. [08:34] pitti: Grr. [08:34] infinity: does it help you sleeping if I threaten you with having to review my glib/gtk/other gnome 3.4.1 uploads? :-) [08:34] err, "threat", I think [08:34] Nah, I don't mind that. [08:34] pitti, infinity is used to pain [08:35] infinity, man, go to bed! [08:35] * dholbach hugs infinity [08:35] pitti: Check the debdiff from eglibc -0ubuntu7 and -0ubuntu9 and then get back to me on how bad you can make a GNOME review. [08:35] From -0ubuntu7 *to* -0ubuntu9, that is. [08:36] infinity, do the gnat-4.6 bootstrap, or go to bed ;p [08:36] doko: Considering it. [08:36] infinity: ok, you win [08:36] doko: And I'd be in bed if I could. Just woke up 10 minutes ago for no good reason. [08:37] * infinity sets about committing all of this to Debian. [08:43] https://bugs.launchpad.net/ubuntu/+source/amule/+bug/610385 , needs to be fixed in oneierc. Would it be right to file a sync request for oneiric? [08:43] Launchpad bug 610385 in amule (Ubuntu) "amule memory usage increases to 100% and makes the whole system unusable" [Undecided,Fix released] === gord_ is now known as gord [09:23] Hi all, I wonder if anyone can help me, does anyone have full documentations of Ubuntu-Core rootfs? [09:24] pitti, hi [09:25] hello tkamppeter [09:26] pitti, I have got a fix for bug 980673. The bug prevents N-up printing of many PDFs. [09:26] Launchpad bug 980673 in cups-filters (Ubuntu) "pdftopdf crashed with SIGSEGV" [Critical,In progress] https://launchpad.net/bugs/980673 [09:26] pitti, how should I proceed? Probably 0-day SRU? [09:27] tkamppeter: do you have a patch? if it's 100% risk free, you can upload to precise still [09:29] pitti, yes, I got the patch. The patch is small and simple. As I am upstream project leader I will make a new upstream release which differs from the old one only by this patch, as I always did with cups-filters. [09:30] anyone working on Ubuntu Core rootfs? [09:37] tkamppeter: I'd say, upload it and see whether it sticks; if not, reupload to -proposed :) [10:08] pitti: please could you see what needs to be done on bug 947309? Is it missing from the sponsors queue because it's "Fix Released"? [10:08] Launchpad bug 947309 in ipsec-tools (Ubuntu) "racoon phase 2 negotiation fails with Win Vista/7" [Medium,Fix released] https://launchpad.net/bugs/947309 [10:08] rbasak: indeed; I approved the lucid task nomination [10:09] rbasak: will look at this next [10:09] pitti: thanks! [10:14] rbasak: uploaded, thanks [10:15] thank you! [10:17] pitti, I have uploaded the fix to precise now and it is waiting for approval. [10:21] hi which is the better way to start coding for ubuntu with python? Do you have any suggestion? books, tutorial, etc.. [10:35] tkamppeter: I can upload current cups-filters to Debian, too if you want === yofel_ is now known as yofel [10:53] tkamppeter: done now [10:59] i'm still confused about the dlm-pcmk removal from precise [11:00] functionality has been removed without replacing it, or noting why it was done or how you can work around it or anything [11:00] sucks :( [11:02] roaksoax, can you spare a moment of your time? :) [11:03] still depressive about it verwilst :) [11:04] verwilst: https://launchpad.net/ubuntu/precise/amd64/dlm-pcmk [11:04] sagaci, yes? [11:05] it says why it was done [11:05] myeah, ok, the why is maybe the clearest part in this story :P [11:05] :) [11:06] but tracking down the location of the module so i can maybe make my own deb or compile it from source is pretty awkward too [11:06] the pacemaker guys strive to make not only their configs awkward and overly complex, they do the same with versioning and branches and repositories and websites ;) [11:06] well the pcmk can't be build anymore it seems. Its just dlm_controld daemon. [11:07] myeah, so cman is required now [11:07] yuk [11:09] well seems so :) [11:09] building the .pcmk has been removed completely, so I guess it will not come back :) === dantti_away is now known as dantti [11:15] didrocks: popey suggested you might be the person to poke about bug 975029, I added a patch a while ago to enable ezoom to work by default [11:15] Launchpad bug 975029 in compiz-plugins-main (Ubuntu) "bindings to activate ezoom not set" [Undecided,Confirmed] https://launchpad.net/bugs/975029 [11:16] AlanBell: hey, they are not set on purpose [11:16] oh ok [11:16] AlanBell: people triggered them without noticying at the time and got stucked [11:17] AlanBell: what I proposed at UDS at the time is someone looking at activating them when a11y is enabled [11:17] silly people :( [11:17] I think that's what will make more sense, isn't it? [11:17] well not really [11:18] if a11y is enabled that generally means you are using orca and have no vision [11:18] AlanBell: hum, there are other a11y parameters, isn't it? [11:18] ezoom is full of awesome if you are just the kind of person who wears glasses, or might take a large print book out of the library [11:18] or someone like me doing a presentation and wanting to zoom in on stuff [11:19] yeah, those options like "manifier" should be exposed in gnome-control-center I guess [11:19] with enable/disable [11:19] that makes sense [11:19] there was such an option but it is bound to gnome-shell magnifier [11:20] AlanBell: yeah, the right patch here is to make it working on unity, and acting differently depending on the shell running [11:20] yup [11:20] ok, looks like this simple patch won't get in, and the proper patch is going to be out of scope at this stage [11:20] ccsm to the rescue :) [11:21] I will write it up in the a11y release notes [11:21] AlanBell: sure! thanks ;) [11:21] are you going to UDS? [11:23] yes, as usual, you too? :) [11:27] yes, looking forward to it :) === MacSlow is now known as MacSlow|lunch [11:49] Hi all, I just wonder if anyone have full documentation about Ubuntu-core rootfs [12:10] i have an idea, let's switch back to cluster 3.0.12 for precise! :P [12:11] the pacemaker resources all need dlm_controld.pcmk by default so it seems === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow [13:14] @pilot out === udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [13:17] bdmurray: may you release new version of firefox-lp-improvements so we (poor users) will get working workitems editor? [13:20] * dholbach hugs pitti [13:29] * pitti hugs dholback === dholbach_ is now known as dholbach === dendro-afk is now known as dendrobates [15:26] slangasek: I'm looking at a ubiquity install bug with an update-notifier conffile prompt in it [15:26] bug 982473 [15:26] Launchpad bug 982473 in ubiquity (Ubuntu) "Installation of Pangolin Beta 2 failed." [Undecided,New] https://launchpad.net/bugs/982473 === salem_ is now known as _salem [16:21] mvo: looking at bug 905454 and bug 961719, how could we modify the postgresql blacklist option? [16:22] Launchpad bug 905454 in update-manager (Ubuntu) " 'postgresql-plperl-8.4' is marked for removal but it is in the removal blacklist" [Undecided,Confirmed] https://launchpad.net/bugs/905454 [16:22] Launchpad bug 961719 in update-manager (Ubuntu) "Cannot calcuate upgrade on postgresql-plperl-8.4" [Undecided,New] https://launchpad.net/bugs/961719 [16:29] * SpamapS starts reviewing precise-proposed uploads [16:29] bdmurray: where does the conffile prompt show up/ [16:30] bdmurray: n/m, found it [16:30] slangasek: it looks like it was installing an updated update-notifier-common version 0.119ubuntu7 [16:30] but you know that know ;-) [16:33] yeah, interesting [16:34] bdmurray: I'd like to know why there *was* an old version of that conffile around, if he was installing beta 2 [16:35] bdmurray: because the conffile was introduced in 0.119ubuntu2, the log shows an upgrade from 0.119ubuntu1 which is the correct version from beta-1 [16:35] er, from beta-2 === mdz` is now known as mdz [16:50] is precise-proposed 0-day SRU's now? [16:50] or are we still using it to stage up things? [16:50] I want to know how to handle the bug statuses and such [16:51] started to accept bug 982267 as an SRU but now I'm not sure.. [16:51] Launchpad bug 982267 in apport (Ubuntu Precise) "dump_acpi_tables.py crashed with UnboundLocalError in dump_acpi_table(): local variable 'hex_str' referenced before assignment" [Medium,Fix committed] https://launchpad.net/bugs/982267 === deryck is now known as deryck[lunch] === _salem is now known as salem_ [17:47] jibel: known issues with jenkins? I haven't seen an upgrade test since the 12th... and I was looking forward to seeing lucid->precise server go green :) === deryck[lunch] is now known as deryck === albrigha is now known as Guest63515 === emma is now known as em === dendrobates is now known as dendro-afk [19:11] Hello, I want to build mysql-workbench 5.2.38+dfsg-3 from Debian with pbuilder [19:11] but pbuilder fails horrible with unmet dependencies: http://pastebin.ubuntu.com/932988/ [19:12] can somebody give me a hint what package the problem is? [19:32] Streamstormer: "Depends: libtinyxml-dev but it is not installable" [19:32] and above that it mentions that it's a virtual package, and the same for libctemplate-dev. my guess is your pbuilder might not be using universe [19:48] ah ok thanks cyphermox [19:56] mdz, cjwatson, stgraber: so TB meeting is now or in 1 h? [19:56] pitti, soren, kees, stgraber, I have it for now [19:57] google calendar entry was never updated, it has been at 21:00 [19:57] could someone update the calendar or delete it? :-) [19:57] the wiki says one time and the calendar another [19:58] I'd very much prefer having it now, it's late enough already; but ISTR that last meeting there was a decision to keep the UTC time? [19:58] hmm, looks like I may have permission to change it [19:59] pitti, now is somewhat better for me as well tbh [19:59] not least because that's what I was planning for [19:59] I thought it was now too, but I'm in San Francisco, so Imy sense of time is useless. [20:01] that sounds like quorum to me [20:01] stgraber, kees, any objections to having the meeting now instead of +1 hour? [20:09] cjwatson: Re subversion FTBFS... I'm up to 12 upstream revisions backported plus a couple of local hacks, and I'm still not done making it build :-( === Dr_Who is now known as tgall_foo [20:32] slangasek, yes, there was a problem with the publication which was fixed this afternoon. I confirm that lucid server is green. result should be published when the current run finishes. [20:33] slangasek, but last run of lucid main i386 failed with http://paste.ubuntu.com/933111/ [20:34] hmm [20:35] jibel: the bug isn't in python2.7-minimal if it only happens for the 'main' upgrade; but we'll probably need to reproduce this to figure out where the bug is. How far along in the upgrade does this happen? === salem_ is now known as _salem === _salem is now known as salem_ [20:44] slangasek, difficult to say. I uploaded the logs http://people.canonical.com/~j-lallement/lucid_main_i386_89.zip if you want to have a look. [20:45] jibel: I guess by "how far along" I mean "how many hours will someone have to wait to reproduce it" [20:46] slangasek, according to the log: 2 hours [21:03] bdmurray: has there been only the one report of bug #982473? I've confirmed there's no conflicting file on the beta-2 liveCD, so I really don't know what could have caused this [21:03] Launchpad bug 982473 in ubiquity (Ubuntu) "Installation of Pangolin Beta 2 failed." [Undecided,New] https://launchpad.net/bugs/982473 [21:03] except cosmic rays :P [21:06] slangasek: I'll look for duplicates shortly [21:06] ok [21:09] or installing over an existing installation without formating [21:10] there is this line in the log [21:10] Preparing to replace update-notifier 0.119ubuntu1 (using .../update-notifier_0.119ubuntu7_amd64.deb) [21:17] jibel: 0.119ubuntu1 is the version on the CD itself, which doesn't contain that conffile [21:19] slangasek, yeah, I'm too much in dailies and didn't see it was a beta 2 cd sorry. [21:42] do we support setting up full disk encryption from the GUI installer yet ? [21:43] lifeless: no === salem_ is now known as _salem [21:44] slangasek, upstart question for you [21:44] yay! [21:45] slangasek, X needs to have the DRI device set up by the kernel (i.e. i915, nvidia, et al) before it can start [21:45] oh, no [21:45] I want a different upstart question [21:45] not one about hybrid graphics :P [21:45] heh [21:45] no, not hybrid [21:45] oh, ok :) [21:45] slangasek, there's cases where the system starts up really fast (or the dri driver is really slow) [21:45] so X comes up before the kernel is ready for it to [21:46] 982889 is an example on -intel; we see it more often on the blobs [21:47] really? [21:47] slangasek, it seems like we need upstart to wait until the kernel driver is "ready to go" but aren't sure a) if that's possible, or b) how to set it up [21:47] slangasek, I would not joke about such matters [21:47] bryceh: I'd like to see a /var/log/udev from an affected system [21:47] ok [21:49] slangasek, I guess my real question is, are we thinking right thoughts to be thinking about upstart here, or should we be thinking different thoughts? [21:49] i915 isn't ready until 2.76 seconds into the boot process, but X already starts at 2.44 and gives up at 2.55 on that bug :( [21:49] also i'm extremely jealous of his 3 second boot time :) [21:49] hmm.. can I use dpkg to query its database on a package status (installed or not) and get a easily parsable response (or a return code)? [21:49] indeed [21:50] dpkq-query [21:50] dpkg [21:50] Laney: thanks, I just found the name in man dpkg and slapped my head ;) [21:50] bryce: because what's supposed to happen is: kernel starts scanning everything and finds out what devices it knows about; somewhere in parallel to that the initramfs hands over to upstart; udev starts up via /etc/init/udev.conf after the virtual filesystems have been mounted; then in turn, we run 'udevadm trigger' via /etc/init/udevtrigger.conf, which cold-plugs drivers for all of the hardware seen so far by replaying the kernel events t [21:50] ... we call udevadm settle, and only then after everything is settled do we use /etc/init/udev-fallback-graphics.conf to load vesafb as a fallback [21:51] slangasek: thanks [21:52] so if this is a bug with the upstart jobs, it's that the video doesn't get *seen* until we're already out of the initramfs [21:53] if we *did* see the video (which the udev log will tell us), and this is happening, then it looks like a kernel bug to me [21:54] oh, in fact there's a udev log on that bug; let's see [21:54] bryceh: oh i believe that's teh same as my bug 969489 [21:54] Launchpad bug 969489 in lightdm (Ubuntu) "lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489 [21:55] hallyn, interesting, I think you might be right [21:56] and yes that's what i was wondering, if there's any way upstart can get an event when the driver is ready... [21:56] If not, perhaps long-term we should add one (a uevent...) === jsjgruber-x-p is now known as jsjgruber [21:56] hallyn: I think the event it's already keyed on is supposed to *be* that event :) [21:57] apw, ^^ [21:57] drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1 [21:57] why would the kernel claim the drm device is available before it's usable? === jsjgruber is now known as Guest33918 [21:57] slangasek: yeah, i *did* see that... which is why threw my hands in the air and filed a bug :) [21:58] slangasek: i wonder if nouveau does the right thing there, and nvidia is just sticking their tongues out at us [21:58] slangasek: so you think the drm-device-added device might be sent too early? interesting [21:59] it appears to be failing in querying the drm interface version [21:59] bryceh: line 4396 of the udev log shows drm card0 coming up at 1.901920 after boot; the udev doesn't start on the root filesystem until 2.244658 according to BootDmesg.txt [21:59] bryceh: so the drm device *was* there for coldplugging, which makes this a kernel bug [21:59] hallyn, can you post your /var/log/Xorg.0.log and dmesg to bug 969489? [21:59] Launchpad bug 969489 in lightdm (Ubuntu) "lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489 === Guest33918 is now known as jsjgruber [21:59] slangasek, ok thanks [22:00] fundamentally, there is still a race in how we're handling video at boot... but as my earlier surprise indicates, I think it's incredibly unlikely we'll hit it in practice [22:00] slangasek, I'm gathering it was there but not reporting the right version [22:01] bryceh: I had actually attached those to the dup, bug 964830 [22:01] Launchpad bug 969489 in lightdm (Ubuntu) "duplicate for #964830 lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489 [22:04] hallyn, ok thanks [22:04] odd, vesafb module isnt found but its at /lib/modules/3.2.0-23-generic/kernel/drivers/video/vesafb.ko so that modprobe vesafb in udev-fallback-graphics would never work? [22:04] bryceh: no, actually, i don't see it. i remember attaching both Xorg.0 and Xorg.1, but i don't see them [22:05] sudo modprobe -b vesafb [22:05] FATAL: Module vesafb not found. [22:05] might explain why proprietary drivers have used the text splash for the past few releases [22:05] i'll post them the next time it boots wrongly [22:05] Sarvatt: I think that's a generic error [22:06] Sarvatt: cf. dmesg [22:06] (and curse you for tricking me into testing that on my running intel system :) [22:07] gave me a very nice kernel oops on modprobe -r :P [22:07] bryceh: ok, there's one more thing I'm checking here [22:07] it's possible upstart is getting the event itself too early [22:07] slangasek, we know that the drm driver can be opened by splash before its ready. we had to add an 'EAGAIN' failure there [22:07] hallyn, ok so in your case nvidia is ready at 7.9 sec [22:07] [ 7.915284] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 295.20 Mon Feb 6 21:07:30 PST 2012 [22:07] slangasek, we may or may not cope witht aht in userspace [22:07] i.e., when the kernel declares the device is added instead of when udev has actually loaded the driver for it [22:08] apw: really? [22:08] molasses! [22:08] hallyn, but X has given up by 7.3 sec [22:08] slangasek: apologies, it really does nothing here [22:08] slangasek, really yes [22:08] [ 7.389] (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module. Please see the [22:08] apw: you sure you're not thinking of the EAGAIN in the VT opening? [22:08] hallyn, so seems to support idea it's the same problem, although the logs differ a bit [22:09] commit 6d74feca6235b463ade4ecddd1dfdb73d30a2ff7 [22:09] Author: Andy Whitcroft [22:09] Date: Thu Jul 29 16:48:21 2010 +0100 [22:09] UBUNTU: SAUCE: drm -- stop early access to drm devices [22:09] slangasek, ^^ [22:09] hmm! [22:09] bryceh: ^^ apw did it ;P [22:09] ahaa [22:10] slangasek, apw stoped the machine exploding in a heap when you opened it too early ... and we return EAGAIN to tell you to try again ... how nice are we [22:10] bryceh: are the timestamps in Xorg.log time since boot? [22:10] slangasek, I believe so, yes [22:10] ok [22:11] * apw wonders if we returned ERESTARTSYS that we'd DTRT without you knowin [22:11] apw, is there a signal it sends when it really is ready to go, that upstart should listen for instead? [22:11] bryceh, nope not that i know of [22:12] apw: why does udev get the uevent at all before it's ready to go? [22:12] bryceh, its a race, we need to know the minors to tell the load method, but till its run we can't actually safely open them [22:12] w [22:12] that's the real question, I think [22:12] which is why we have to tell you to hang fire a sec [22:12] ah [22:13] ok, so upstart needs to catch and block and retry until it doesn't get EAGAIN? [22:13] no [22:13] upstart shouldn't do that for you [22:13] though any open can return EAGAIN and you really should damn well listen :) [22:13] upstart should not open the drm device at all - it's up to whatever wants to use it to handle this [22:14] (assuming the kernel really can't defer announcing it until it's initialized) [22:14] right, we presumably run plymouth or X and its crapping self cause the open failed [22:14] ok, so then _X_ should block and retry on the device until it gets something working? [22:14] yes [22:14] that'd be helpful if it could [22:14] hum [22:14] as EAGAIN really means, ooops could you try that again please [22:14] jibel: even installing over an existing installation without formatting is supposed to clear out all system directories [22:15] we may be able to do it to you in the kernel, but its harder to make it safe against failure [22:15] at least you can shoot X from a shell [22:15] heh, was just thinking it'd be hard to make it safe against failure in X. ;-) [22:15] bryceh, well it should only do it for open == -1 and errno == EAGAIN [22:16] * apw looks at the time ... time for some shuteye rsn [22:33] bryceh: bug #969489 is going to be slightly different... binary driver, no drm, we'll *always* hit the fallback AFAIK [22:34] Launchpad bug 969489 in lightdm (Ubuntu) "lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489 [22:34] so that's a case where the events really are wrong... we just don't really have a way to fix them, because it's binary [22:35] slangasek: that'd be good to know, and i suppose a nice stick to force ppl like me to switch [22:35] hallyn: you won't have this particular issue with nouveau, for sure [22:36] slangasek, yeah I was just musing about that on #ubuntu-x [22:36] hi guys I have a question about upgrades and dependencies. PackageA used to depend on PackageB, but now it Depends on PackageC. PackageC, however, Conflicts/Replaces on PackageB. On dist-upgrade, dpkg wants to remove packageA. However, if I install PackageC it replaces PackageB successfully. Any ideas of why would this be? [22:37] slangasek, so, fixing 982889 doesn't really buy us much; that case is kind of a corner case of a system with really fast hw. the blob case is where we've seen the bulk of this type of problem, and hacking libdrm doesn't help us there. [22:38] well, it buys you better reliability on systems with good drivers ;P [22:39] but yeah, it doesn't help much if you're getting lots of complaints with nv/fglrx [22:40] slangasek, my guess is as more people get (faster) ssd's we may see more in general across all drivers [22:40] also, I need one of these SSDs :-) [22:41] slangasek, at least I feel like I have a better understanding of the problem, thanks. Bummer that upstart isn't of help here though. [22:44] God forbid upstart should stand between X and the kernel ;) [22:44] if you can figure out a better way to make the kernel even reliable in the first place, that'd be something [23:03] doko: is python-argparse still going to be fixed or not? its currently blocking an update of mine [23:21]