[01:21] Hooray Python 2.6.4 is out. https://mail.google.com/mail/?shva=1#inbox/124930ebf2a4eb61 [01:21] oops, not a good link [01:22] python.org will be good enough I suppose ;) === bjf is now known as bjf-afk [01:24] Yeah, just don't link python.com by mistake. [01:25] ScottK: considering that I use that site several times a week, not much chance for such mistakes from me ;-) [01:26] and python.com seems to be about "other snakes" [01:27] (and NSFW) [01:27] well, depending on your job etc. [02:28] Hm, on second thought I don't see how to generate a smaller test case than "rebuild libcrypto++8". [02:28] I would assume that the problem is between the amd64 asm in Crypto++ and the recent patches to gas, but that's just a guess on my part. [02:29] I guess I should do what doko suggested and try reverting one or a few of the hunks in binutils, rebuild binutils, then try the "rebuild libcrypto++8" test? [02:29] Sheesh, that's a lot of tedious effort. I wish there were a robot that would do that for me. [02:30] It took me most of today to manually bisect and identify which binutils update introduced the problem. [02:52] zooko: But imagine how great it's going to feel when you nail it. [02:52] I had one of these a couple of weeks ago where I ended up having to build kdelibs one svn committ at a time. === ]reed[ is now known as [reed] [06:07] "Installing new version of config file /etc/init/gdm.conf ..." [06:08] is /etc/gdm/gdm.conf no longer used? Doesn't seem to appear on my test system anymore. [06:13] bryce_: /etc/init/gdm.conf is an upstart job, not gdm configuration [06:13] I don't think /etc/gdm/gdm.conf is used any more, though, no [06:13] there's custom.conf for a few things [06:15] cjwatson, ok, guess this is something that changed while I was on leave. Is it known that bulletproof-x no longer kicks in when there is a bad xorg.conf? [06:16] cjwatson, (do we care about this use case anymore?) [06:16] that I don't know [06:16] though sounds potentially accidental [06:17] problem can be reproduced by setting Driver "foo" in xorg.conf. [06:17] (beware; only do it if you hate your computer) [06:17] it seems gdm tries to start X 5 times, but fails and then exits [06:18] upstart sees gdm has exited and restarts it [06:18] on my system this goes on for a while and then the console locks up. ssh over ethernet still works [06:19] we no longer ship an xorg.conf either, so maybe this is not an important use case, but people might have an xorg.conf from an upgrade or something [06:28] aha, this is bug #441638 [06:28] Launchpad bug 441638 in gdm "gdm main process keeps dying and respawning on reboot after karmic beta install" [Undecided,Confirmed] https://launchpad.net/bugs/441638 [06:45] good morning [06:57] Good morning === dpm-afk is now known as dpm === highvolt1ge is now known as highvoltage === dholbach_ is now known as dholbach === cjwatson_ is now known as cjwatson === bfox_ is now known as bfox === jono_ is now known as jono === warp10_ is now known as warp10 === tkamppeter_ is now known as tkamppeter === wakingrufus_ is now known as wakingrufus === MacSlow is now known as MacSlow|lunch [13:15] superm1: you know this myththemes upload happened well after the deadline for the start of image mastering, right? :) [13:15] superm1: it happens that we're doing a respin shortly for some ubiquity bugs - so there's a window where I can include this... how well tested is it? [13:18] superm1: also, unversioned Replaces against an existing opens the door to future problems, things that should have been file conflicts being silently swept under the rug by dpkg [13:21] soren: would you consider bug 461725 a feature or a bug ? [13:21] Launchpad bug 461725 in upstart "rc-sysinit job might start before loopback is up" [Medium,Incomplete] https://launchpad.net/bugs/461725 [13:22] soren: slangasek already said he considers differences with what rcS provided to be a regression [13:22] ttx: I think slangasek made the case very well yesterday, saying "everything that rcS did for us before should still be guaranteed" [13:23] soren: hm, right [13:23] ttx: At the very least, if such an assumption is broken, it should be documented.. [13:23] ...and there should be another way to make sure it's taken care of. [13:23] slangasek, thanks for letting me know about the translations notes. I've made some small changes according to the latest update of the translation stats yesterday, so I'm just letting you know in case you need extra notification: https://wiki.ubuntu.com/KarmicKoala/ReleaseAnnouncement?action=diff&rev2=7&rev1=6 and https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview?action=diff&rev2=128&rev1=127 [13:24] ..but seeing as this affects things that don't have upstart jobs, but as old style runlevel init scripts, I don't see how we can do that. [13:24] * hyperair waves at YokoZar [13:24] hmmm [13:25] Keybuk: May we invite you to join the discussion? :) [13:25] ultimately, the way it should be taken care of is by having everything migrated to upstart jobs [13:25] hello there hyperair [13:25] but in the meantime, backwards-compat should be preserved [13:26] * liw thinks s_langasek should write a book about distro release management [13:26] starting rc-sysinit later isn't a problem [13:26] liw: what, and become dispensible? :-) [13:27] soren: I'm no expert at all on the issue, but... 1) if I understand correctly, rc-sysinit compat is implemented as an upstart job itself; 2) upstart jobs can have a pre-req on the old rcS stuff [13:27] YokoZar: hello there. this is regarding the ia32-libs issue, if you haven't already noticed =) [13:27] slangasek, there ain't nothing to make you dispensable, but writing the book would mean you'd have a convenient place to point at when people repeat mistakes :) [13:27] Chipzz: Oh, there are certainly mechanics for doing it. [13:27] so why not add that pre-req to the upstart job that handles rc-sysinit compat? [13:27] liw: heh :) [13:27] liw: so you should get plenty of time developing that killer picture manager ? [13:28] hyperair: which issue? [13:28] Chipzz: The discussion is whether or not it's desirable. I believe it is. Key people are undecided. [13:28] ttx, yes, it is my cunning plan to get Steve have some free time so he can write the missing bits [13:29] slangasek: Don't think of yourself as "dispensable", think "modular" [13:29] YokoZar: https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/248392 [13:29] Launchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] [13:29] YokoZar: plugin-able ? [13:29] soren: in my (irrelevant :P) opinion, if ppl are too lazy to migrate to upstart jobs, they shouldn't complain about being started later [13:31] Chipzz: Just because Ubuntu decides to switch to upstart doesn't make every person out there who ever wrote an init script lazy for not following suit. [13:31] soren: I was referring to ubuntu packages that haven't migrated [13:32] Chipzz: So was I. [13:32] the rc-sysinit compat stuff is exactly for external stuff [13:32] but maybe "lazy" was a bit unnuanced :) [13:33] anyway, just my 2c [13:33] hyperair: so it's a mesa bug -- did you ever find the mesa bug that was said to already exist in the winehq thread? [13:34] Chipzz: there's little point in providing a compatibility system that provides an incompatible environment. [13:34] YokoZar: i did, yes. [13:34] hyperair: link please (so I can attach it to launchpad) [13:34] but it's just related [13:34] it's not the same [13:34] soren: in what way would it be incompatible? or are you referring to the state of affairs atm? [13:35] well, the hard-coding is a bug we should file then [13:35] s/atm/now [13:35] YokoZar: http://bugs.freedesktop.org/show_bug.cgi?id=23335 [13:35] Freedesktop bug 23335 in Drivers/DRI/i965 "[wine] Mesa returns invalid framebuffer status" [Normal,Assigned] [13:35] YokoZar: yes, pretty much. which is the bug that's mentioned there. [13:35] YokoZar: imo it's hardcoded based on the --prefix passed to mesa. [13:35] Chipzz: The loopback interface used to be configured when rc2.d/S* ran. That is no longer the case. [13:35] YokoZar: i'm not sure about how ia32-libs is built, but is it built with --libdir=/usr/lib32? [13:36] Chipzz: No longer /necessarily/ the case, I mean. [13:36] It's a race. [13:36] YokoZar: and i raelly meant that it's hardcoded based on --libdir. [13:36] soren: right, so you're referring to the current state of affairs :) [13:36] hyperair: no it's nowhere near smart enough to do that. It literally downloads the 32 bit packages, rips their libraries out, and shoves them into /usr/lib32 [13:36] figures [13:36] Chipzz: Yes. [13:37] YokoZar: perhaps the bundled source/deb pair within ia32-libs could be patched. [13:37] hyperair: accordingly it may be ok for us to have a workaround patch in mesa itself until we can fix the issue properly [13:37] hyperair: that's an option too [13:37] YokoZar: what do you mean workaround patch? [13:38] to fallback on /usr/lib? [13:38] Well that would actually be a proper fix I guess === lamont` is now known as lamont === MacSlow|lunch is now known as MacSlow [13:40] hmmm [13:40] i'll go talk to some mesa peoples then. [13:40] is it possible to get this fix into karmic? [13:41] even if this is just a workaround, it hides a more serious bug in wine (segfault issue) [13:41] hyperair: with an SRU shortly after release probably [13:41] ah [13:41] I dunno though depends on how fast you are ;) [13:42] for inspiration you can look at how glib does things (asac and I were working on this earlier) https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/369498 [13:42] Launchpad bug 369498 in glib2.0 "32bits gtk and glib modules not found in ia32-libs" [Medium,In progress] [13:42] yes. i think the patch i prepared shouldnt be that far off from what is needed [13:43] just needs to be checked why it didnt work [13:43] must be something obvious [13:43] it did work with canberra I think though [13:43] eg we have /usr/lib/gtk-2.0/i486-pc-linux-gnu [13:44] ah GTK_HOST eh.. [13:44] maybe the issue with gvfs was a similar hard-coded path determined by --prefix at build time [13:44] actually there are loads of these [13:46] oh, there was a missing lib in ia32-libs. libgnomekeyring i think [13:46] used by adobe air [13:46] directhex: is it still missing? I went on a blitz adding libraries about a month back or so [13:47] oh, i haven't checked for about a month or so [13:48] mvo: I'm looking at bug #461077.. The dpkgterminallog does not mention mysql-server anywhere. How can this happen? [13:48] Launchpad bug 461077 in mysql-dfsg-5.1 "package mysql-server-5.1 5.1.37-1ubuntu5 failed to install/upgrade: subprocess new pre-installation script killed by signal (Broken pipe)" [Undecided,New] https://launchpad.net/bugs/461077 [13:49] YokoZar, definitely not there. [13:53] soren: I don't know, I suspect it might be happen in pre-configure already [13:53] soren: the log has "debconf: unable to initialize frontend: Dialog^M [13:53] debconf: (Dialog frontend requires a screen at least 13 lines tall and 31 columns wide.)^M [13:53] " [13:58] mvo: Perhaps. Hmm... Ok, thanks. === bjf-afk is now known as bjf [14:15] slangasek, soren: I was only referring to the fact that loopback was never up before rcS [14:15] rc2, certainly [14:16] Keybuk: You don't believe it was brought up by rcS.d/S40networking? [14:17] Oh, I see what you're saying. [14:17] Perhaps I'm misunderstanding rc-sysvinit. [14:17] Keybuk: something must have been lost in communication; I was asserting that before the rc2 scripts are run, everything that was previously handled by rcS should be finished [14:17] * soren rereads [14:17] including the bits that have been converted to upstart jobs [14:18] rc-sysinit is the job that switches to runlevel 2, isn't it? [14:18] (or another configured runlevel) [14:18] Ah, no. [14:18] yues [14:18] Well, yes, that too. [14:18] it's probably correct to change rc-sysinit [14:18] maybe to: [14:18] but it also runs the rcS script? [14:19] start on startup and filesystem and net-device-up lo [14:19] ? [14:19] start on (filesystem and virtual-network) [14:19] ? [14:19] That matches the old behaviour. [14:19] except for the lack of "virtual-network" event ;) [14:19] (adding "on startup" fixes another bug - which WOULD BE NICE) [14:19] Oh, I was thinking of the virtual-filesystems event. Bah. My bad. [14:20] start on (startup and networking) ? [14:20] start on startup and filesystem and net-device-up lo [14:22] Keybuk: If the goal is to make sure that what was true when starting runlevel 2 pre-upstartification, it should be networking, me thinks. [14:23] Err.. [14:23] Keybuk: If the goal is to make sure that what was true when starting runlevel 2 pre-upstartification, is still true now, it should be networking, I mean. [14:23] then you will have the very strange effect where rcS/rc2 don't get started until well after X [14:23] and honestly, "networking" hasn't started networking for many releases now [14:24] so you're being unnecessarily picky :p [14:24] we've called ifup from udev for *ages* [14:24] since hardy certainly [14:24] possibly before [14:24] Keybuk: Except for bonded interfaces, for instance. [14:24] in fact, I think we may have even called ifup from hotplug [14:24] ...and similar stuff. [14:25] you could do that [14:25] the side-effect will be quite odd an unexpected though ;) [14:25] What, the bond device being configured, but having no physical interfaces attached to it? :) [14:25] no, I mean the X11 sockets being removed after X is running [14:25] Ngh.. [14:26] YokoZar: a bit of digging shows that exporting DRI_DRIVER_SEARCH_DIR to /usr/lib/dri:/usr/lib32/dri during build should do the trick. [14:26] Yes, that would certainly qualify for "odd and unexpected" :) [14:26] is the loopback device being missing the problem, [14:26] Keybuk: In this case, yes. [14:26] or is an actual network device being missing the problem? [14:26] hyperair: ooh, that does sound promising [14:26] Keybuk: Loopback. [14:26] in which case, only fix the problem [14:26] YokoZar: =) [14:26] Keybuk: I'm just less convinced that you that that is the whole problem. :) [14:27] there are bound to be regressions throughout the switch-over [14:27] oh, I know it's not the whole problem [14:27] all the time we have both sysvinit and upstart jobs, we're going to have bugs [14:27] YokoZar: http://pastebin.com/f49573d3e is what i have for mesa. [14:27] * soren nods [14:27] side-effect of only having 6 months for each release [14:27] can't develop everything in 6 months [14:27] right, other network interfaces not being guaranteed up at the end of 'networking' isn't a regression [14:29] I think it is, but I realise that fixing that causes other problems and may not be as critical. [14:29] hyperair: do you mean to define DEFAULT_DRIVER_DIR as that or just export DRI_DRIVER_SEARCH_DIR ? [14:29] soren: no, it's not a /regression/ [14:29] slangasek: I think it is. [14:29] you're mistaken, and I defer to Keybuk to prove it :) [14:30] YokoZar: that's a patch meant for upstream. downstream, without the patch, just exporting DRI_DRIVER_SEARCH_DIR will do the trick. [14:30] YokoZar: it's untested though. i'm going to give it a go [14:30] Go for it :) [14:30] =) [14:30] soren: by "not a regression" I mean "this hasn't regressed since jaunty" [14:30] * hyperair has a full archives mirror on LAN ;-) [14:30] slangasek: So do I. [14:30] slangasek: bonded interfaces were brought up by rcS.d/S40networking. [14:31] slangasek: ..so when you reached rc2.d/S* they were available. [14:31] slangasek: That is no longer necessarily the case, as you yourself determined yesterday. [14:31] soren: that could only be done if the underlying physical hardware had been detected and had its drivers loaded first, and that's not guaranteed to be the case [14:31] hyperair: there is an (awkward) way to supply a home-built package into ia32-libs for testing too. So just make sure mesa doesn't break on i386 and then we can push it as a normal update (and then have ia32-libs pull it in the natural way) [14:31] hurray for udev asynchronicity [14:32] YokoZar: how? [14:32] right, it was never guaranteed that the underlying interfaces were up before S40networking ;) [14:32] or even the underlying hardware [14:32] soren: now, there's a difference in the likelihood of a user /hitting/ this state [14:32] slangasek: Not /strictly/ guaranteed, but in almost every case a very reasonable assumption. [14:32] soren: we always had a race condition [14:32] you could have triggered it by just buying faster hardware [14:32] hyperair: you apt-get source ia32-libs and put it in the pkgs folder in it ;) [14:32] so, in theory, you need to just get slower hardware :p [14:33] (or slower hardware, I can't remember which way things work) [14:33] Keybuk: Yet I didn't, and I've changed nothing about my hardware, but the system behaves differently. It's racy now on systems that did not used to be. that's a regression in my book. [14:33] Keybuk: faster hardware> or putting your bridging interface on USB network devices :) [14:34] soren: it really was racy before, too, you just never hit the race; this is a quantitative difference only [14:34] I'm not hugely interested in discussing theoretical properties of asynchronous device configuration. I'm talking about what /actually/ happens and how it affects users. [14:34] soren: that's like saying the fact that the default theme is more brown than before is a regression [14:34] it was always brown [14:34] YokoZar: ah. [14:35] Why the fsck do I always end up having this kind of argument with people? [14:35] Forget it. [14:35] Forgive me for trying to fix people's problems. [14:35] YokoZar: how do i get ia32-libs to add an extra symlink? [14:35] hyperair: you add it manually in debian/rules [14:36] ok [14:36] hyperair: using dh_link [14:36] there's a bunch of examples in there to follow [14:36] okay [14:36] soren: we're not saying there's no race here [14:36] Keybuk: I know. [14:37] just the right way to fix that race is to convert the job to upstart [14:37] which is designed, from the ground up, to avoid races [14:37] Keybuk: I know. [14:37] soren: the point is precisely that this problem can't be fixed without converting the bridge initialization to an asynchronous model as well, and you'll lose a lot of time trying to hack around it [14:39] I'm just saying that we're trying to provide a compatibility layer for stuff that is not yet converted to upstart jobs and that the compatibility layer provides an environment that demonstrably is /functionally/ incompatible with what we're trying to be compatible with. [14:40] I find that unfortunate, but if the owner of the project that holds the keys to the the magic box of tricks to fix it as well as the release manger things differently, I'm not going to waste more time on it. [14:40] s/things/thinks/ [14:41] s/thinks/think/ [14:41] soren: well, not entirely [14:41] it's compatible with what we *had* [14:41] it's just not compatible with what people thought we had [14:42] The operative word being "functionally". [14:42] and that's quite a big difference ;) [14:42] Hey, I can split hairs almost as well as the next guy. [14:42] cf. recovery mode :) [14:43] you could quibble about the return value of runlevel ;) [14:43] (during rcS) [14:43] that's much more fun [14:43] * jdstrand remembers dealing with that one... [14:44] in this case, I made a decision not to be compatible [14:44] and instead fixed a bug [14:45] slangasek, yes sorry it was so late, these problems were just caught in testing last night. it's had some testing by myself and someone else with a PPA during a dist-upgrade to make sure it DTRT (and does). that's a good point about the versioned file replaces, i can repeat the upload with that corrected for a re-roll [14:46] soren: AFAICS this conversation stems from you disagreeing with a very narrowly construed statement of mine that a particular race condition existed prior to karmic ("is not a regression"). I certainly didn't say the current behavior isn't unfortunate; I'm just perhaps a bit more sanguine about it than you because it's one in a long historical series of unfortunate design problems with sysvinit in general and the Debian init scripts in particular.. [14:46] ... and also because I'm not the one who needs this to work personally [14:47] this is currently buggy; overall, however, I think karmic's init is no more buggy than jaunty's was, for the most part the bugs have just moved up the stack a little [14:47] superm1: yes, please reupload with that change, and I'll quick-accept to get it into the mythbuntu reroll [14:47] great thanks [14:48] keybuk: What’s the kernel in the ubuntu-boot PPA for? [14:49] ion: tell you later :p [14:49] ugh. gnome-screensaver has stopped working again in Xubuntu. [14:49] * cody-somerville moans. [14:52] slangasek: I don't believe in resting on laurels because we're "no worse" than Jaunty. People using stuff like bonding device are not the sort of people who install beta versions or RC's of stuff, so they will not start seeing the problems and complaining about them until after release. I happen to work on the edition of Ubuntu that has to deal with them, so by extension it annoys me. [14:52] ...and I just don't know what to tell them if they come complaining. "sorry, you shouldn't run Karmic, so please use the downgrade tool.. Oh, wait.." [14:53] Add a sysvrc script that just waits for the bonding device to appear. :-P [14:54] tseliot: can you have a look at #459829 please ? [14:54] If I /know/ what the fix is, I'd like to do it for them instead of having to tell them one. at. a. time. [14:54] mvo: sure [14:54] bug #459829 [14:54] Launchpad bug 459829 in update-manager "Upgrade from Hardy to Karmic didn't remove lrm-video" [Undecided,New] https://launchpad.net/bugs/459829 [14:54] tseliot: if its true that this causes failure on all nvidia systems on upgrade, that is pretty bad [14:56] mvo: from what I remember that script modprobes the nvidia modules and we don't need that anymore [14:56] soren: so, do you know what the fix is here? Because as I said, I don't see a way to reliably address this without a lot of work to make bridge devices work asynchronously, and then we need some way for the rc job to wait for "the network" generally [14:56] mvo: so it's entirely possible that it's causing some nasty problems to the nvidia drivers [14:57] slangasek: In Jaunty, rcS.d/S40networking was finished when we reached runlevel 2. [14:58] slangasek: I realise that adding that dependency causes other problems, but virtaully all of this discussion has been about whether or not "being racy" is a binary, not about how to solve the problems. [14:58] soren: and with the way things are parallelized now, with rcS.d much shorter and faster, using that script as a synchronization point is not likely to do the job anymore [14:58] you're much more likely to reach that script before all your network hardware is up [14:59] Then we're far worse off than I thought. [14:59] that means bonding device will *never* be configured. [14:59] slangasek: but good point. [15:00] wait, are you talking about the network interfaces not coming up properly on karmic when a static /etc/network/interfaces is used and has bridging configured? 'cause I'm seeing that occasionally on my desktop machine [15:00] liw: yes [15:00] liw: Yes. [15:00] is there a workaround? (or you can tell me to read all of backlog) [15:01] liw: stick a sleep 5 in /etc/init/networking.conf? [15:01] oh, that's clever. I'll do that, thanks [15:02] (as soon as I figure out the actual syntax) [15:02] liw: I mean 'pre-start exec sleep 5' [15:02] liw: have a cronjob run "ifup -a" every minute or so [15:02] :) [15:03] why does it work for me then? :) [15:03] slangasek, thanks (I used sleep 30, just to be sure) [15:03] sistpoty|work, if it's a race condition, you're just lucky; wanna play some poker? :) [15:04] heh [15:04] depends on things like how long it takes to init your network devices, how many distinct local filesystems you have, how much other extraneous hardware you have in the box [15:05] even depends on how initramfs-tools is configured on your system [15:05] soren, has the KVM page on help.ubuntu.com (or wherever it is these days) been updated with this workaround? if not, could you take care of that? === cody-somerville_ is now known as cody-somerville [15:12] soren, liw: so that workaround takes care of half of the problem, the other half being that we still need to make rc wait for networking [15:18] liw: I only just realised this very problem twenty minutes ago. [15:18] liw: 14:59:06 < soren> Then we're far worse off than I thought. [15:18] liw: The moment of epiphany :) [15:19] soren, that's more than 1500 seconds for you have to have patched the docs ;) [15:19] slangasek: Yeah. Adding the sleep will make that problem even worse. [15:19] liw: I think it should be somewhere not quite as virtualisation specific. [15:21] Keybuk: do you plan to SRU for bug #461725? [15:21] Launchpad bug 461725 in upstart "rc-sysinit job might start before loopback is up" [Medium,Incomplete] https://launchpad.net/bugs/461725 [15:22] would you like me to SRU for bug 461725 [15:22] Launchpad bug 461725 in upstart "rc-sysinit job might start before loopback is up" [Medium,Incomplete] https://launchpad.net/bugs/461725 [15:25] yes [15:26] then I will ;-) [15:27] slangasek: should the latest edubuntu .iso be up on the iso tracker? I don't see anything listed for final release testing [15:27] LaserJock: I can post it, but we're in a full-spectrum reroll right now due to some generic installer bugs that turned up [15:28] LaserJock: if you'd like me to post it for you for smoketesting purposes, I can do so [15:28] slangasek: ok, no problem, I just wondered what you needed from us for final release [15:31] LaserJock: will you do a release announcement this cycle that I should link to? (e.g., http://edubuntu.org/news/9.10-release) [15:32] LaserJock: there's also upgrade testing that can be done in the meantime (http://iso.qa.ubuntu.com/qatracker/build/upgrade/all) [15:32] slangasek: yes to the release announcement [15:33] slangasek: and that's the url we'll use === Whoopie_ is now known as Whoopie [15:38] mvo: are you going to remove /ect/modprobe.d/lrm-video in dist-upgrades? [15:40] tseliot: what wrote/shipped that file? [15:40] shouldn't that package clean it up on upgrades? (to also work with aptitude/apt-get dist-upgrade) [15:40] pitti: linux-restricted-modules-common i.e. the l-r-m [15:40] I don't know why it's not removed [15:40] was it a conffile? [15:41] I suppose something conflicts: l-r-m on upgrade [15:41] but packages are removed, not purged [15:41] it's a script which used to modprobe fglrx and nvidia [15:41] oh [15:42] I meant, was it shipped in the package, or created/removed in postinst/postrm? [15:42] I *think* it was in the package [15:42] tseliot: I'm currently setting up my test machine with nvidia to see if I can reproduce, but yeah, I think something should rmeove it [15:42] * tseliot nods [15:42] pitti: its in the package, shows up in apt-file-search [15:43] pitti: and a conffile [15:44] from what I remember it modprobed either nvidia, nvidia_new or nvidia_legacy (from the l-r-m) or just nvidia if envyng was there [15:44] Keybuk: current m-i-t still evaluates files which don't end in .conf ? [15:46] yes [15:46] tseliot: ^ ok, so that won't help us then [15:46] Keybuk: thanks [15:46] tseliot: and fglrx it seems [15:46] yes, I noticed that. It should just give you a warning [15:47] mvo: yes, of course. Fortunately there was only 1 version of fglrx [15:47] is there something like fglrx-common? it sounds like we should just rm -f it in nvidia-common (and fglrx-common) [15:48] no, I don't think we've ever had an fglrx-common script [15:48] mvo: did you mean nvidia-kernel-common? [15:48] nvidia-common is a different thing [15:49] aah [15:49] ok, I misread what you wrote [15:50] rm -f in the preinst or postinst of nvidia-common should work [15:51] tseliot: ok, cool. I prepare a update. thanks for your input [15:51] Hi. I am interested to find out if the Ubuntu installer has been modified with regards to the treatment of the swap partition? I am comparing two versions 8.10 and 9.04, and I have found 8.10 to cache some setup data in the swap partition, but 9.04 seems not to do so. I would like to know what code has been changed and where if anyone could point me in the right direction? [15:51] mvo: thanks for reporting the problem :-) [15:52] pitti: do you know why hal might be failing (at random) to apply some settings in the synaptics fdi? [15:53] tseliot: no idea, without further details [15:53] the XML might be malformed or the cache outdated [15:53] those are the two most common ones [15:53] pitti: I thought of the latter but apw told me that it's random [15:54] is the cache updated automatically on boot? [15:54] tseliot: no, just when something installs/changes/removes an .fdi [15:54] it's a dpkg trigger [15:54] pitti, i see the 'fix' for the 10v touchpad fail to apply about one boot in 4 or 5 [15:55] i saw it occur for scott too today, so its not just me === dmart_ is now known as dmart [15:55] that fix matches the product id of the netbook and apply the appropriate options accordingly [15:55] which .fdi are we talking about? [15:56] /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi [15:56] Gizmo: "setup data"? [15:56] (as in he saw Keybuk thump his computer angrily) [15:56] apw: would be interesting if you can reproduce it under hal debug mode (https://wiki.ubuntu.com/DebuggingHal); I'd love to see a log where it's failing [15:57] cjwatson: yes - bits and pieces of text gathered during the iinstallation [15:57] Gizmo: I'd expect that to be essentially random [15:58] cjwatson: yes, I think it is. [15:58] the swap partition will contain all sorts of random stuff that happened to be in memory [15:58] Gizmo, isn't it normal that the swap partition has some data that was in RAM during installation but got swapped out due to memory constraints? [15:58] apw: and corresponding lshal output [15:58] to my knowledge there was no relevant behavioural change [15:59] any emergent change will be due to things like slightly different memory consumption figures causing different swap usage [15:59] cjwatson: liw yes, it is. But my tests are indiciating currently that on the same machine with the same amount of RAM data is swapped with 8.10 but not with 9.04. I was curious to know if this was a deliberate change or just circumstantial. [15:59] 8.10 and 9.04 don't take up exactly the same amount of memory due to installation [15:59] swapped from the installation, to be precise [15:59] I'm curious why you're bothering to test this :) [15:59] it's certainly circumstantial [16:00] cjwatson: I am doing a study. [16:00] do you understand virtual memory, in general? === jamie is now known as Guest82689 [16:04] using some swap doesn't really tell you anything === beuno is now known as beuno-lunch [16:04] i have some swap used on a 8GB machine but it also has 6896MB free [16:06] I am in the process of conducting various tests, but in my first test I found that the password entered during setup was cached in the swap partition, in plain text. I was seeing if this also occured with ver 9.04. This is why I am asking. [16:06] the kernel (aiui) just moves some stuff out if it is not used much to allow more space for cache/buffers [16:06] Gizmo: oh [16:07] I am doing a MSc project you see. [16:07] And this is part of my chosen area of strudy [16:07] study [16:07] It may have been a ranom dump of data, and I am trying to see if I can repeat it [16:07] Gizmo: well cjwatson is one of the best people to be talking to for that :) [16:08] It hasn't happended with 9.04, so I wondered if the dev's had realised the problem with 8.10 and patched it. I fthey had, I wanted to know where [16:08]