| zooko | Hooray Python 2.6.4 is out. https://mail.google.com/mail/?shva=1#inbox/124930ebf2a4eb61 | 01:21 |
|---|---|---|
| zooko | oops, not a good link | 01:21 |
| JanC | python.org will be good enough I suppose ;) | 01:22 |
| === bjf is now known as bjf-afk | ||
| ScottK | Yeah, just don't link python.com by mistake. | 01:24 |
| JanC | ScottK: considering that I use that site several times a week, not much chance for such mistakes from me ;-) | 01:25 |
| JanC | and python.com seems to be about "other snakes" | 01:26 |
| JanC | (and NSFW) | 01:27 |
| JanC | well, depending on your job etc. | 01:27 |
| zooko | Hm, on second thought I don't see how to generate a smaller test case than "rebuild libcrypto++8". | 02:28 |
| zooko | 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:28 |
| zooko | 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 |
| zooko | Sheesh, that's a lot of tedious effort. I wish there were a robot that would do that for me. | 02:29 |
| zooko | It took me most of today to manually bisect and identify which binutils update introduced the problem. | 02:30 |
| ScottK | zooko: But imagine how great it's going to feel when you nail it. | 02:52 |
| ScottK | I had one of these a couple of weeks ago where I ended up having to build kdelibs one svn committ at a time. | 02:52 |
| === ]reed[ is now known as [reed] | ||
| bryce_ | "Installing new version of config file /etc/init/gdm.conf ..." | 06:07 |
| bryce_ | is /etc/gdm/gdm.conf no longer used? Doesn't seem to appear on my test system anymore. | 06:08 |
| cjwatson | bryce_: /etc/init/gdm.conf is an upstart job, not gdm configuration | 06:13 |
| cjwatson | I don't think /etc/gdm/gdm.conf is used any more, though, no | 06:13 |
| cjwatson | there's custom.conf for a few things | 06:13 |
| bryce_ | 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:15 |
| bryce_ | cjwatson, (do we care about this use case anymore?) | 06:16 |
| cjwatson | that I don't know | 06:16 |
| cjwatson | though sounds potentially accidental | 06:16 |
| bryce_ | problem can be reproduced by setting Driver "foo" in xorg.conf. | 06:17 |
| bryce_ | (beware; only do it if you hate your computer) | 06:17 |
| bryce_ | it seems gdm tries to start X 5 times, but fails and then exits | 06:17 |
| bryce_ | upstart sees gdm has exited and restarts it | 06:18 |
| bryce_ | on my system this goes on for a while and then the console locks up. ssh over ethernet still works | 06:18 |
| bryce_ | 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:19 |
| bryce_ | aha, this is bug #441638 | 06:28 |
| ubottu | 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:28 |
| dholbach | good morning | 06:45 |
| pitti | Good morning | 06:57 |
| === 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 | ||
| slangasek | superm1: you know this myththemes upload happened well after the deadline for the start of image mastering, right? :) | 13:15 |
| slangasek | 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:15 |
| slangasek | 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:18 |
| ttx | soren: would you consider bug 461725 a feature or a bug ? | 13:21 |
| ubottu | Launchpad bug 461725 in upstart "rc-sysinit job might start before loopback is up" [Medium,Incomplete] https://launchpad.net/bugs/461725 | 13:21 |
| ttx | soren: slangasek already said he considers differences with what rcS provided to be a regression | 13:22 |
| soren | ttx: I think slangasek made the case very well yesterday, saying "everything that rcS did for us before should still be guaranteed" | 13:22 |
| ttx | soren: hm, right | 13:23 |
| soren | ttx: At the very least, if such an assumption is broken, it should be documented.. | 13:23 |
| soren | ...and there should be another way to make sure it's taken care of. | 13:23 |
| dpm | 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:23 |
| soren | ..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 | |
| YokoZar | hmmm | 13:24 |
| soren | Keybuk: May we invite you to join the discussion? :) | 13:25 |
| slangasek | ultimately, the way it should be taken care of is by having everything migrated to upstart jobs | 13:25 |
| YokoZar | hello there hyperair | 13:25 |
| slangasek | but in the meantime, backwards-compat should be preserved | 13:25 |
| * liw thinks s_langasek should write a book about distro release management | 13:26 | |
| slangasek | starting rc-sysinit later isn't a problem | 13:26 |
| slangasek | liw: what, and become dispensible? :-) | 13:26 |
| Chipzz | 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 |
| hyperair | YokoZar: hello there. this is regarding the ia32-libs issue, if you haven't already noticed =) | 13:27 |
| liw | 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 |
| soren | Chipzz: Oh, there are certainly mechanics for doing it. | 13:27 |
| Chipzz | so why not add that pre-req to the upstart job that handles rc-sysinit compat? | 13:27 |
| slangasek | liw: heh :) | 13:27 |
| ttx | liw: so you should get plenty of time developing that killer picture manager ? | 13:27 |
| YokoZar | hyperair: which issue? | 13:28 |
| soren | Chipzz: The discussion is whether or not it's desirable. I believe it is. Key people are undecided. | 13:28 |
| liw | ttx, yes, it is my cunning plan to get Steve have some free time so he can write the missing bits | 13:28 |
| YokoZar | slangasek: Don't think of yourself as "dispensable", think "modular" | 13:29 |
| hyperair | YokoZar: https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/248392 | 13:29 |
| ubottu | Launchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] | 13:29 |
| ttx | YokoZar: plugin-able ? | 13:29 |
| Chipzz | 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:29 |
| soren | 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 |
| Chipzz | soren: I was referring to ubuntu packages that haven't migrated | 13:31 |
| soren | Chipzz: So was I. | 13:32 |
| Chipzz | the rc-sysinit compat stuff is exactly for external stuff | 13:32 |
| Chipzz | but maybe "lazy" was a bit unnuanced :) | 13:32 |
| Chipzz | anyway, just my 2c | 13:33 |
| YokoZar | 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:33 |
| soren | Chipzz: there's little point in providing a compatibility system that provides an incompatible environment. | 13:34 |
| hyperair | YokoZar: i did, yes. | 13:34 |
| YokoZar | hyperair: link please (so I can attach it to launchpad) | 13:34 |
| hyperair | but it's just related | 13:34 |
| hyperair | it's not the same | 13:34 |
| Chipzz | soren: in what way would it be incompatible? or are you referring to the state of affairs atm? | 13:34 |
| YokoZar | well, the hard-coding is a bug we should file then | 13:35 |
| Chipzz | s/atm/now | 13:35 |
| hyperair | YokoZar: http://bugs.freedesktop.org/show_bug.cgi?id=23335 | 13:35 |
| ubottu | Freedesktop bug 23335 in Drivers/DRI/i965 "[wine] Mesa returns invalid framebuffer status" [Normal,Assigned] | 13:35 |
| hyperair | YokoZar: yes, pretty much. which is the bug that's mentioned there. | 13:35 |
| hyperair | YokoZar: imo it's hardcoded based on the --prefix passed to mesa. | 13:35 |
| soren | Chipzz: The loopback interface used to be configured when rc2.d/S* ran. That is no longer the case. | 13:35 |
| hyperair | YokoZar: i'm not sure about how ia32-libs is built, but is it built with --libdir=/usr/lib32? | 13:35 |
| soren | Chipzz: No longer /necessarily/ the case, I mean. | 13:36 |
| soren | It's a race. | 13:36 |
| hyperair | YokoZar: and i raelly meant that it's hardcoded based on --libdir. | 13:36 |
| Chipzz | soren: right, so you're referring to the current state of affairs :) | 13:36 |
| YokoZar | 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 |
| hyperair | figures | 13:36 |
| soren | Chipzz: Yes. | 13:36 |
| hyperair | YokoZar: perhaps the bundled source/deb pair within ia32-libs could be patched. | 13:37 |
| YokoZar | 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 |
| YokoZar | hyperair: that's an option too | 13:37 |
| hyperair | YokoZar: what do you mean workaround patch? | 13:37 |
| hyperair | to fallback on /usr/lib<arch>? | 13:38 |
| YokoZar | Well that would actually be a proper fix I guess | 13:38 |
| === lamont` is now known as lamont | ||
| === MacSlow|lunch is now known as MacSlow | ||
| hyperair | hmmm | 13:40 |
| hyperair | i'll go talk to some mesa peoples then. | 13:40 |
| hyperair | is it possible to get this fix into karmic? | 13:40 |
| hyperair | even if this is just a workaround, it hides a more serious bug in wine (segfault issue) | 13:41 |
| YokoZar | hyperair: with an SRU shortly after release probably | 13:41 |
| hyperair | ah | 13:41 |
| YokoZar | I dunno though depends on how fast you are ;) | 13:41 |
| YokoZar | 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 |
| ubottu | Launchpad bug 369498 in glib2.0 "32bits gtk and glib modules not found in ia32-libs" [Medium,In progress] | 13:42 |
| asac | yes. i think the patch i prepared shouldnt be that far off from what is needed | 13:42 |
| asac | just needs to be checked why it didnt work | 13:43 |
| asac | must be something obvious | 13:43 |
| YokoZar | it did work with canberra I think though | 13:43 |
| YokoZar | eg we have /usr/lib/gtk-2.0/i486-pc-linux-gnu | 13:43 |
| hyperair | ah GTK_HOST eh.. | 13:44 |
| YokoZar | maybe the issue with gvfs was a similar hard-coded path determined by --prefix at build time | 13:44 |
| hyperair | actually there are loads of these | 13:44 |
| directhex | oh, there was a missing lib in ia32-libs. libgnomekeyring i think | 13:46 |
| directhex | used by adobe air | 13:46 |
| YokoZar | directhex: is it still missing? I went on a blitz adding libraries about a month back or so | 13:46 |
| directhex | oh, i haven't checked for about a month or so | 13:47 |
| soren | mvo: I'm looking at bug #461077.. The dpkgterminallog does not mention mysql-server anywhere. How can this happen? | 13:48 |
| ubottu | 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:48 |
| directhex | YokoZar, definitely not there. | 13:49 |
| mvo | soren: I don't know, I suspect it might be happen in pre-configure already | 13:53 |
| mvo | soren: the log has "debconf: unable to initialize frontend: Dialog^M | 13:53 |
| mvo | debconf: (Dialog frontend requires a screen at least 13 lines tall and 31 columns wide.)^M | 13:53 |
| mvo | " | 13:53 |
| soren | mvo: Perhaps. Hmm... Ok, thanks. | 13:58 |
| === bjf-afk is now known as bjf | ||
| Keybuk | slangasek, soren: I was only referring to the fact that loopback was never up before rcS | 14:15 |
| Keybuk | rc2, certainly | 14:15 |
| soren | Keybuk: You don't believe it was brought up by rcS.d/S40networking? | 14:16 |
| soren | Oh, I see what you're saying. | 14:17 |
| soren | Perhaps I'm misunderstanding rc-sysvinit. | 14:17 |
| slangasek | 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 | |
| slangasek | including the bits that have been converted to upstart jobs | 14:17 |
| soren | rc-sysinit is the job that switches to runlevel 2, isn't it? | 14:18 |
| soren | (or another configured runlevel) | 14:18 |
| soren | Ah, no. | 14:18 |
| Keybuk | yues | 14:18 |
| soren | Well, yes, that too. | 14:18 |
| Keybuk | it's probably correct to change rc-sysinit | 14:18 |
| Keybuk | maybe to: | 14:18 |
| soren | but it also runs the rcS script? | 14:18 |
| Keybuk | start on startup and filesystem and net-device-up lo | 14:19 |
| Keybuk | ? | 14:19 |
| soren | start on (filesystem and virtual-network) | 14:19 |
| soren | ? | 14:19 |
| soren | That matches the old behaviour. | 14:19 |
| Keybuk | except for the lack of "virtual-network" event ;) | 14:19 |
| Keybuk | (adding "on startup" fixes another bug - which WOULD BE NICE) | 14:19 |
| soren | Oh, I was thinking of the virtual-filesystems event. Bah. My bad. | 14:19 |
| soren | start on (startup and networking) ? | 14:20 |
| Keybuk | start on startup and filesystem and net-device-up lo | 14:20 |
| soren | 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:22 |
| soren | Err.. | 14:23 |
| soren | 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 |
| Keybuk | then you will have the very strange effect where rcS/rc2 don't get started until well after X | 14:23 |
| Keybuk | and honestly, "networking" hasn't started networking for many releases now | 14:23 |
| Keybuk | so you're being unnecessarily picky :p | 14:24 |
| Keybuk | we've called ifup from udev for *ages* | 14:24 |
| Keybuk | since hardy certainly | 14:24 |
| Keybuk | possibly before | 14:24 |
| soren | Keybuk: Except for bonded interfaces, for instance. | 14:24 |
| Keybuk | in fact, I think we may have even called ifup from hotplug | 14:24 |
| soren | ...and similar stuff. | 14:24 |
| Keybuk | you could do that | 14:25 |
| Keybuk | the side-effect will be quite odd an unexpected though ;) | 14:25 |
| soren | What, the bond device being configured, but having no physical interfaces attached to it? :) | 14:25 |
| Keybuk | no, I mean the X11 sockets being removed after X is running <g> | 14:25 |
| soren | Ngh.. | 14:25 |
| hyperair | 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 |
| soren | Yes, that would certainly qualify for "odd and unexpected" :) | 14:26 |
| Keybuk | is the loopback device being missing the problem, | 14:26 |
| soren | Keybuk: In this case, yes. | 14:26 |
| Keybuk | or is an actual network device being missing the problem? | 14:26 |
| YokoZar | hyperair: ooh, that does sound promising | 14:26 |
| soren | Keybuk: Loopback. | 14:26 |
| Keybuk | in which case, only fix the problem | 14:26 |
| hyperair | YokoZar: =) | 14:26 |
| soren | Keybuk: I'm just less convinced that you that that is the whole problem. :) | 14:26 |
| Keybuk | there are bound to be regressions throughout the switch-over | 14:27 |
| Keybuk | oh, I know it's not the whole problem | 14:27 |
| Keybuk | all the time we have both sysvinit and upstart jobs, we're going to have bugs | 14:27 |
| hyperair | YokoZar: http://pastebin.com/f49573d3e is what i have for mesa. | 14:27 |
| * soren nods | 14:27 | |
| Keybuk | side-effect of only having 6 months for each release | 14:27 |
| Keybuk | can't develop everything in 6 months <g> | 14:27 |
| slangasek | right, other network interfaces not being guaranteed up at the end of 'networking' isn't a regression | 14:27 |
| soren | I think it is, but I realise that fixing that causes other problems and may not be as critical. | 14:29 |
| YokoZar | hyperair: do you mean to define DEFAULT_DRIVER_DIR as that or just export DRI_DRIVER_SEARCH_DIR ? | 14:29 |
| slangasek | soren: no, it's not a /regression/ | 14:29 |
| soren | slangasek: I think it is. | 14:29 |
| slangasek | you're mistaken, and I defer to Keybuk to prove it :) | 14:29 |
| hyperair | YokoZar: that's a patch meant for upstream. downstream, without the patch, just exporting DRI_DRIVER_SEARCH_DIR will do the trick. | 14:30 |
| hyperair | YokoZar: it's untested though. i'm going to give it a go | 14:30 |
| YokoZar | Go for it :) | 14:30 |
| hyperair | =) | 14:30 |
| slangasek | 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 | |
| soren | slangasek: So do I. | 14:30 |
| soren | slangasek: bonded interfaces were brought up by rcS.d/S40networking. | 14:30 |
| soren | slangasek: ..so when you reached rc2.d/S* they were available. | 14:31 |
| soren | slangasek: That is no longer necessarily the case, as you yourself determined yesterday. | 14:31 |
| slangasek | 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 |
| YokoZar | 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 |
| slangasek | hurray for udev asynchronicity | 14:31 |
| hyperair | YokoZar: how? | 14:32 |
| Keybuk | right, it was never guaranteed that the underlying interfaces were up before S40networking ;) | 14:32 |
| Keybuk | or even the underlying hardware | 14:32 |
| slangasek | soren: now, there's a difference in the likelihood of a user /hitting/ this state | 14:32 |
| soren | slangasek: Not /strictly/ guaranteed, but in almost every case a very reasonable assumption. | 14:32 |
| Keybuk | soren: we always had a race condition | 14:32 |
| Keybuk | you could have triggered it by just buying faster hardware | 14:32 |
| YokoZar | hyperair: you apt-get source ia32-libs and put it in the pkgs folder in it ;) | 14:32 |
| Keybuk | so, in theory, you need to just get slower hardware :p | 14:32 |
| Keybuk | (or slower hardware, I can't remember which way things work) | 14:33 |
| soren | 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 |
| slangasek | Keybuk: faster hardware> or putting your bridging interface on USB network devices :) | 14:33 |
| slangasek | soren: it really was racy before, too, you just never hit the race; this is a quantitative difference only | 14:34 |
| soren | 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 |
| Keybuk | soren: that's like saying the fact that the default theme is more brown than before is a regression | 14:34 |
| Keybuk | it was always brown | 14:34 |
| hyperair | YokoZar: ah. | 14:34 |
| soren | Why the fsck do I always end up having this kind of argument with people? | 14:35 |
| soren | Forget it. | 14:35 |
| soren | Forgive me for trying to fix people's problems. | 14:35 |
| hyperair | YokoZar: how do i get ia32-libs to add an extra symlink? | 14:35 |
| YokoZar | hyperair: you add it manually in debian/rules | 14:35 |
| hyperair | ok | 14:36 |
| YokoZar | hyperair: using dh_link | 14:36 |
| YokoZar | there's a bunch of examples in there to follow | 14:36 |
| hyperair | okay | 14:36 |
| Keybuk | soren: we're not saying there's no race here | 14:36 |
| soren | Keybuk: I know. | 14:36 |
| Keybuk | just the right way to fix that race is to convert the job to upstart | 14:37 |
| Keybuk | which is designed, from the ground up, to avoid races | 14:37 |
| soren | Keybuk: I know. | 14:37 |
| slangasek | 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:37 |
| soren | 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:39 |
| soren | 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 |
| soren | s/things/thinks/ | 14:40 |
| soren | s/thinks/think/ | 14:41 |
| Keybuk | soren: well, not entirely | 14:41 |
| Keybuk | it's compatible with what we *had* | 14:41 |
| Keybuk | it's just not compatible with what people thought we had | 14:41 |
| soren | The operative word being "functionally". | 14:42 |
| Keybuk | and that's quite a big difference ;) | 14:42 |
| soren | Hey, I can split hairs almost as well as the next guy. | 14:42 |
| Keybuk | cf. recovery mode :) | 14:42 |
| Keybuk | you could quibble about the return value of runlevel ;) | 14:43 |
| Keybuk | (during rcS) | 14:43 |
| Keybuk | that's much more fun | 14:43 |
| * jdstrand remembers dealing with that one... | 14:43 | |
| Keybuk | in this case, I made a decision not to be compatible | 14:44 |
| Keybuk | and instead fixed a bug <g> | 14:44 |
| superm1 | 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:45 |
| slangasek | 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 |
| slangasek | ... and also because I'm not the one who needs this to work personally | 14:46 |
| slangasek | 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 |
| slangasek | superm1: yes, please reupload with that change, and I'll quick-accept to get it into the mythbuntu reroll | 14:47 |
| superm1 | great thanks | 14:47 |
| ion | keybuk: What’s the kernel in the ubuntu-boot PPA for? | 14:48 |
| Keybuk | ion: tell you later :p | 14:49 |
| cody-somerville | ugh. gnome-screensaver has stopped working again in Xubuntu. | 14:49 |
| * cody-somerville moans. | 14:49 | |
| soren | 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 |
| soren | ...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:52 |
| ion | Add a sysvrc script that just waits for the bonding device to appear. :-P | 14:53 |
| mvo | tseliot: can you have a look at #459829 please ? | 14:54 |
| soren | 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 |
| tseliot | mvo: sure | 14:54 |
| tseliot | bug #459829 | 14:54 |
| ubottu | 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 |
| mvo | tseliot: if its true that this causes failure on all nvidia systems on upgrade, that is pretty bad | 14:54 |
| tseliot | mvo: from what I remember that script modprobes the nvidia modules and we don't need that anymore | 14:56 |
| slangasek | 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 |
| tseliot | mvo: so it's entirely possible that it's causing some nasty problems to the nvidia drivers | 14:56 |
| soren | slangasek: In Jaunty, rcS.d/S40networking was finished when we reached runlevel 2. | 14:57 |
| soren | 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 |
| slangasek | 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 |
| slangasek | you're much more likely to reach that script before all your network hardware is up | 14:58 |
| soren | Then we're far worse off than I thought. | 14:59 |
| soren | that means bonding device will *never* be configured. | 14:59 |
| soren | slangasek: but good point. | 14:59 |
| liw | 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 |
| slangasek | liw: yes | 15:00 |
| soren | liw: Yes. | 15:00 |
| liw | is there a workaround? (or you can tell me to read all of backlog) | 15:00 |
| slangasek | liw: stick a sleep 5 in /etc/init/networking.conf? | 15:01 |
| liw | oh, that's clever. I'll do that, thanks | 15:01 |
| liw | (as soon as I figure out the actual syntax) | 15:02 |
| slangasek | liw: I mean 'pre-start exec sleep 5' | 15:02 |
| soren | liw: have a cronjob run "ifup -a" every minute or so | 15:02 |
| soren | :) | 15:02 |
| sistpoty|work | why does it work for me then? :) | 15:03 |
| liw | slangasek, thanks (I used sleep 30, just to be sure) | 15:03 |
| liw | sistpoty|work, if it's a race condition, you're just lucky; wanna play some poker? :) | 15:03 |
| sistpoty|work | heh | 15:04 |
| slangasek | 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:04 |
| slangasek | even depends on how initramfs-tools is configured on your system | 15:05 |
| liw | 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? | 15:05 |
| === cody-somerville_ is now known as cody-somerville | ||
| slangasek | 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:12 |
| soren | liw: I only just realised this very problem twenty minutes ago. | 15:18 |
| soren | liw: 14:59:06 < soren> Then we're far worse off than I thought. | 15:18 |
| soren | liw: The moment of epiphany :) | 15:18 |
| liw | soren, that's more than 1500 seconds for you have to have patched the docs ;) | 15:19 |
| soren | slangasek: Yeah. Adding the sleep will make that problem even worse. | 15:19 |
| soren | liw: I think it should be somewhere not quite as virtualisation specific. | 15:19 |
| slangasek | Keybuk: do you plan to SRU for bug #461725? | 15:21 |
| ubottu | Launchpad bug 461725 in upstart "rc-sysinit job might start before loopback is up" [Medium,Incomplete] https://launchpad.net/bugs/461725 | 15:21 |
| Keybuk | would you like me to SRU for bug 461725 | 15:22 |
| ubottu | Launchpad bug 461725 in upstart "rc-sysinit job might start before loopback is up" [Medium,Incomplete] https://launchpad.net/bugs/461725 | 15:22 |
| slangasek | yes | 15:25 |
| Keybuk | then I will ;-) | 15:26 |
| LaserJock | slangasek: should the latest edubuntu .iso be up on the iso tracker? I don't see anything listed for final release testing | 15:27 |
| slangasek | 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:27 |
| slangasek | LaserJock: if you'd like me to post it for you for smoketesting purposes, I can do so | 15:28 |
| LaserJock | slangasek: ok, no problem, I just wondered what you needed from us for final release | 15:28 |
| slangasek | LaserJock: will you do a release announcement this cycle that I should link to? (e.g., http://edubuntu.org/news/9.10-release) | 15:31 |
| slangasek | LaserJock: there's also upgrade testing that can be done in the meantime (http://iso.qa.ubuntu.com/qatracker/build/upgrade/all) | 15:32 |
| LaserJock | slangasek: yes to the release announcement | 15:32 |
| LaserJock | slangasek: and that's the url we'll use | 15:33 |
| === Whoopie_ is now known as Whoopie | ||
| tseliot | mvo: are you going to remove /ect/modprobe.d/lrm-video in dist-upgrades? | 15:38 |
| pitti | tseliot: what wrote/shipped that file? | 15:40 |
| pitti | shouldn't that package clean it up on upgrades? (to also work with aptitude/apt-get dist-upgrade) | 15:40 |
| tseliot | pitti: linux-restricted-modules-common i.e. the l-r-m | 15:40 |
| tseliot | I don't know why it's not removed | 15:40 |
| pitti | was it a conffile? | 15:40 |
| pitti | I suppose something conflicts: l-r-m on upgrade | 15:41 |
| pitti | but packages are removed, not purged | 15:41 |
| tseliot | it's a script which used to modprobe fglrx and nvidia | 15:41 |
| tseliot | oh | 15:41 |
| pitti | I meant, was it shipped in the package, or created/removed in postinst/postrm? | 15:42 |
| tseliot | I *think* it was in the package | 15:42 |
| mvo | 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 | |
| mvo | pitti: its in the package, shows up in apt-file-search | 15:42 |
| mvo | pitti: and a conffile | 15:43 |
| tseliot | 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 |
| pitti | Keybuk: current m-i-t still evaluates files which don't end in .conf ? | 15:44 |
| Keybuk | yes | 15:46 |
| pitti | tseliot: ^ ok, so that won't help us then | 15:46 |
| pitti | Keybuk: thanks | 15:46 |
| mvo | tseliot: and fglrx it seems | 15:46 |
| tseliot | yes, I noticed that. It should just give you a warning | 15:46 |
| tseliot | mvo: yes, of course. Fortunately there was only 1 version of fglrx | 15:47 |
| mvo | is there something like fglrx-common? it sounds like we should just rm -f it in nvidia-common (and fglrx-common) | 15:47 |
| tseliot | no, I don't think we've ever had an fglrx-common script | 15:48 |
| tseliot | mvo: did you mean nvidia-kernel-common? | 15:48 |
| tseliot | nvidia-common is a different thing | 15:48 |
| tseliot | aah | 15:49 |
| tseliot | ok, I misread what you wrote | 15:49 |
| tseliot | rm -f in the preinst or postinst of nvidia-common should work | 15:50 |
| mvo | tseliot: ok, cool. I prepare a update. thanks for your input | 15:51 |
| Gizmo | 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 |
| tseliot | mvo: thanks for reporting the problem :-) | 15:51 |
| tseliot | pitti: do you know why hal might be failing (at random) to apply some settings in the synaptics fdi? | 15:52 |
| pitti | tseliot: no idea, without further details | 15:53 |
| pitti | the XML might be malformed or the cache outdated | 15:53 |
| pitti | those are the two most common ones | 15:53 |
| tseliot | pitti: I thought of the latter but apw told me that it's random | 15:53 |
| tseliot | is the cache updated automatically on boot? | 15:54 |
| pitti | tseliot: no, just when something installs/changes/removes an .fdi | 15:54 |
| pitti | it's a dpkg trigger | 15:54 |
| apw | pitti, i see the 'fix' for the 10v touchpad fail to apply about one boot in 4 or 5 | 15:54 |
| apw | i saw it occur for scott too today, so its not just me | 15:55 |
| === dmart_ is now known as dmart | ||
| tseliot | that fix matches the product id of the netbook and apply the appropriate options accordingly | 15:55 |
| pitti | which .fdi are we talking about? | 15:55 |
| tseliot | /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi | 15:56 |
| cjwatson | Gizmo: "setup data"? | 15:56 |
| Keybuk | (as in he saw Keybuk thump his computer angrily) | 15:56 |
| pitti | 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:56 |
| Gizmo | cjwatson: yes - bits and pieces of text gathered during the iinstallation | 15:57 |
| cjwatson | Gizmo: I'd expect that to be essentially random | 15:57 |
| Gizmo | cjwatson: yes, I think it is. | 15:58 |
| cjwatson | the swap partition will contain all sorts of random stuff that happened to be in memory | 15:58 |
| liw | 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 |
| pitti | apw: and corresponding lshal output | 15:58 |
| cjwatson | to my knowledge there was no relevant behavioural change | 15:58 |
| cjwatson | any emergent change will be due to things like slightly different memory consumption figures causing different swap usage | 15:59 |
| Gizmo | 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 |
| cjwatson | 8.10 and 9.04 don't take up exactly the same amount of memory due to installation | 15:59 |
| Gizmo | swapped from the installation, to be precise | 15:59 |
| cjwatson | I'm curious why you're bothering to test this :) | 15:59 |
| cjwatson | it's certainly circumstantial | 15:59 |
| Gizmo | cjwatson: I am doing a study. | 16:00 |
| cjwatson | do you understand virtual memory, in general? | 16:00 |
| === jamie is now known as Guest82689 | ||
| ccheney | using some swap doesn't really tell you anything | 16:04 |
| === beuno is now known as beuno-lunch | ||
| ccheney | i have some swap used on a 8GB machine but it also has 6896MB free | 16:04 |
| Gizmo | 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 |
| ccheney | the kernel (aiui) just moves some stuff out if it is not used much to allow more space for cache/buffers | 16:06 |
| ccheney | Gizmo: oh | 16:06 |
| Gizmo | I am doing a MSc project you see. | 16:07 |
| Gizmo | And this is part of my chosen area of strudy | 16:07 |
| Gizmo | study | 16:07 |
| Gizmo | It may have been a ranom dump of data, and I am trying to see if I can repeat it | 16:07 |
| ccheney | Gizmo: well cjwatson is one of the best people to be talking to for that :) | 16:07 |
| Gizmo | 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 |
| mvo | tseliot: nvidia-common bzr and arcihve are out of sync (FYI) | 16:08 |
| tseliot | mvo: :-/ let me check | 16:09 |
| Gizmo | ccheney: cjwatson yes, I have repeated the test with 8.10 again, using a diff username and password. It's definately cached to swap with a machine using 1Gb. Might not with higher RAM levels. | 16:10 |
| tseliot | mvo: my bad, the last commit was rejected. I'll remove it | 16:11 |
| Gizmo | I was starting to panic that the 5 pages I've written on the subject might have been wrong, but thankfully not. If it's reliably dumping this data, but isn't with 9.04, there must have been a code page somewhere | 16:11 |
| Gizmo | code change somewhere, rather | 16:11 |
| joaopinto | Gizmo, if something was changed it is related to the installer swap configuration, linux kernel virtual memory management, it was not related to the installer/security per si | 16:12 |
| liw | Gizmo, not necessarily; it might just be that under 8.10 it happened to always do it and random changes in 9.04 makes the password not be swapped out; but hopefully someone's realized that locking the password into memory is a good thing, you could grep the sources for that | 16:12 |
| Gizmo | joaopinto: OK - so would you be able to tell me where I would find the code for the installwer swap config? liw yes - good idea | 16:13 |
| joaopinto | Gizmo, erm, better go the way around look for the password config code | 16:13 |
| Gizmo | liw: how would one grep the sources? | 16:14 |
| Gizmo | forgive me - I am not a developer :-( | 16:14 |
| mvo | tseliot: i have nvidia-common rev17 from 2009-07-30 here | 16:14 |
| joaopinto | if there is nothing mandating that the entire process should always be on physical RAM, it can randomly get swapped | 16:14 |
| mvo | tseliot: that is what I get with debcheckout (that looks at the vcs-bzr header) | 16:14 |
| cjwatson | Gizmo: I think you are attempting to study something essentially random | 16:14 |
| tseliot | mvo: actually, now that I look at the diff, revision 17 should be ok | 16:15 |
| cjwatson | Gizmo: I don't know of any relevant code changes | 16:15 |
| tseliot | mvo: but it's not here: https://code.launchpad.net/~ubuntu-branches/ubuntu/karmic/nvidia-common/karmic | 16:15 |
| Gizmo | cjwatson: you could well be right, but I have created 3 virtual machines, each with different usernames and passwords. When I examined each one afterwards (of the 8.10 distribution) all of the 3 passwords were cached. Same tests done with 9.04 showed no passwords. So I take your point that in theory it would be random, but my tests suggest otherwise. | 16:16 |
| cjwatson | Gizmo: the password utilities don't call mlock, which is what I would expect to see if passwords were being locked out of swap | 16:16 |
| joaopinto | Gizmo, you are reproducing the conditions on your tests, that is not random :) | 16:17 |
| tseliot | mvo: can you put revision 17 in your upload too? | 16:17 |
| Gizmo | I think the best way for me to document this one way or another is to work out which part of the installer is responsbile for the collection of the password (Step 5 of the installation) and which part does anything with the swap. Maybe it does a cleanup or something at the end? | 16:18 |
| cjwatson | Gizmo: of course, the passwords go between several different processes before ending up in the password file | 16:18 |
| mpt | mvo, I have a couple of questions about packaging relationships if now's an okay time (perhaps it isn't?) | 16:18 |
| cjwatson | Gizmo: and I'm certain that not all of those lock it out of swpa | 16:18 |
| cjwatson | swap | 16:18 |
| Gizmo | cjwatson: I quite agree, but I'm not suggesting it's deliberately stored and read back from swap. The PW is entered by the user, put into RAM, and then written to the /etc/passwd & shadow files having being encoded etc, but that is obviously once the filesystem has been built, whicvh at the time the PW is requested, it hasn't been. | 16:20 |
| cjwatson | it's entered into the frontend (ubiquity in the desktop CD, cdebconf in the alternate/server CD); in the desktop CD case, ubiquity passes it to debconf; that gets returned to user-setup, which passes it through the shell a couple of times; and user-setup passes it to chpasswd | 16:20 |
| joaopinto | Gizmo, anyway, you mentioned a problem, and the possibility of it being fixed, have you reported it ? | 16:20 |
| mvo | tseliot: the last revision i have in bzr is 0.2.12 the last in the archive is 0.2.15 | 16:20 |
| cjwatson | there are several places there where it'll be in RAM temporarily | 16:20 |
| Gizmo | cjwatson: excellent - that's what I was after | 16:20 |
| cjwatson | I don't believe any of those saw significant changes in 9.04, and certainly not all of them | 16:21 |
| mvo | mpt: not a good time, but ask anyway, if you don't mind delays in answering | 16:21 |
| cjwatson | so I'm not disputing that you see it in swap - what I'm saying is that the fact that it *isn't* in swap in 9.04 is essentially random, even if the variables controlling that are always more or less the same in *your* tests | 16:21 |
| Gizmo | joaopinto: no, I haven't. I am a forensic practitioner so my study is to work out potential weaknesses. | 16:21 |
| cjwatson | random in the sense that there's nothing in the installer to prevent it | 16:22 |
| cjwatson | I would certainly accept a bug report on this | 16:22 |
| mvo | tseliot: I wonder if we could move it to something like ~ubuntu-core-dev or ~ubuntu-desktop from the current ~tseliot location ? not important though | 16:22 |
| cjwatson | although I would also argue that people who are concerned about attackers having direct access to their swap partition should be using encrypted swap | 16:22 |
| tseliot | mvo: I'm not a core-dev or a motu yet | 16:22 |
| mvo | tseliot: aha, ok | 16:23 |
| Gizmo | cjwatson: ha - it's funny you mention that. My MSc study is, in fact, relating to eCryptFS, introduced in 8.10. | 16:23 |
| cjwatson | (only root, or other physical access, can get direct access to swap, and those people can also grab the shadow password file and crack it at their leisure) | 16:23 |
| cjwatson | ecryptfs isn't encrypted swap | 16:23 |
| cjwatson | in 9.10, however, we take more care here | 16:23 |
| Gizmo | cjwatson: No, but it can be encrypted with it | 16:23 |
| cjwatson | if encryption is enabled, 9.10 zeroes swap at the end of installation | 16:23 |
| Gizmo | yes, buit it is not enabled by default...yet | 16:24 |
| cjwatson | correct | 16:24 |
| cjwatson | there are many other vulnerabilities open to an attacker with this level of access when the disk isn't encrypted | 16:24 |
| cjwatson | zeroing in on a particular one of them isn't necessarily the best answer :) | 16:24 |
| mvo | Riddell: I saw some "widget-plugins/kde4.py" releated errors in u-m (like bug #459471) | 16:25 |
| ubottu | Launchpad bug 459471 in update-manager "[Karmic] update-manager-kde: not handled exception in KDE frontend" [Undecided,New] https://launchpad.net/bugs/459471 | 16:25 |
| Gizmo | cjwatson: thanks. This is just one of 15 areas I am looking at, unfortunately. My project is not just about the swap. Are you one of the main Ubuntu dev's? | 16:25 |
| mvo | Riddell: is there any news on what is causing this? | 16:25 |
| joaopinto | the login password is probably not the most valuable asset if you can read the entire disk :P | 16:25 |
| cjwatson | Gizmo: yes | 16:25 |
| Gizmo | joaopinto: quite true, but if you want to crack encryption, it might be!! | 16:25 |
| tseliot | mvo: maybe it's easier if I put the code from karmic in my branch (after cleaning up my branch) | 16:26 |
| Gizmo | cjwatson: do you know Dustin Kirkland? | 16:26 |
| cjwatson | I would be inclined to say that there is not very much valuable data on a system that was only just installed! | 16:26 |
| cjwatson | and if it wasn't only just installed, whatever part of swap that holds the password is very likely to have been overwritten | 16:26 |
| Gizmo | cjwatson: as a generalisation, I quite agree. | 16:26 |
| cjwatson | so this is unlikely to be a realistic attack on a system containing real valuable data | 16:27 |
| mvo | tseliot: I can just upload as a normal package and let you sort it out. its only affecting hardy->karmic so it is just a minority | 16:27 |
| cjwatson | yes, I know Dustin | 16:27 |
| joaopinto | cjwatson, there is a lot of people doing fresh installs with a /home partition :P | 16:27 |
| Riddell | mvo: pyqt got a late move to python-support, that file is now in /usr/share/pyshared/PyQt4/uic/widget-plugins/kde4.py | 16:27 |
| tseliot | mvo: ok, thanks. I'll clean my branch tomorrow and pull from karmic after your upload | 16:27 |
| cjwatson | joaopinto: which won't be encrypted, then | 16:27 |
| mvo | tseliot: thanks, I will uplaod when karmic-proposed opens, not sure when that will happen. I will let you know | 16:28 |
| cjwatson | or at least if it is, ubiquity already probably won't cope very well | 16:28 |
| tseliot | mvo: ok, there's no hurry | 16:28 |
| mvo | Riddell: urgh, that seems to be causing issues, maybe we need to add a symlink or something | 16:28 |
| mvo | Riddell: I will try to figure out if its a general problem or just a corner case | 16:29 |
| Gizmo | cjwatson: the thoery and liklihoods of things are not what I am trying to document. I am documenting potential areas of interest and possibilities. As a forensic finding, the fact that a setup sudo password may pontetially be recovered from the swap is a good thing. Yes, it may have been overwritten, but it may not. It's all about possibilities. | 16:29 |
| Gizmo | Obviously from a security point of view for Ubuntu, it's not so good. | 16:30 |
| Gizmo | But then, as you say, it's not likely to be recovered anyway | 16:30 |
| Gizmo | so it's not that much of a bad thing | 16:30 |
| Riddell | mvo: /usr/share/python-qt4/widget-plugins/kde4.py is pointing at the wrong place | 16:30 |
| slangasek | mvo: karmic-proposed is already open for business | 16:31 |
| mvo | Riddell: on jaunty? karmic? during the upgrade? | 16:31 |
| Riddell | mvo: but I'm not sure why that file would be used rather than the /var/lib/python-support/python2.6/PyQt4/uic/widget-plugins/kde4.py one which is actually in the python library path | 16:31 |
| mvo | slangasek: sweet, many thanks | 16:31 |
| Riddell | mvo: in karmic | 16:31 |
| cjwatson | Gizmo: right, from a development point of view, it's important to prioritise likely problems over unlikely ones | 16:32 |
| cjwatson | Gizmo: of course you're free to document whatever you like :) | 16:32 |
| mvo | Riddell: I don't know, maybe its because the jaunty version was loaded when hte upgrade starts and its still having a memory refrecne to it | 16:32 |
| Riddell | yes maybe | 16:32 |
| Gizmo | cjwatson: absolutely. I doubt this is really worth the investment of time for Canonical. It's an interesting find though, do you not think? | 16:33 |
| mvo | Riddell: I will try to reproduce and see if I can come up with a workaround | 16:33 |
| Gizmo | cjwatson: The answer you gave me above regarding the cycle of the password through the various steps, I'd like to use in my work. I can't quote IRC channels as an academic resource but I can quote individual developers. Would you object to being named? If so, do you know where I would find that information in a published sense? Where did you get it from, for example? | 16:35 |
| Riddell | mvo: it sounds like it's only in the cases where upgrade is already failing? I should do a SRU for kdebindings to fix the symlink and that would solve it once it got in? | 16:35 |
| mvo | Riddell: I'm not sure, it maybe when there is a conffile prompt or something else that need to pop up a dialog | 16:36 |
| mvo | Riddell: at least that is my theory right now | 16:36 |
| Riddell | mvo: even so a SRU should sort it surely | 16:37 |
| mvo | Riddell: yeah, looks much like being caused by a conffile prompt | 16:37 |
| mvo | Riddell: yes, if you have that in the works I will just dup the bugs | 16:37 |
| zooko | Folks, the problem with binutils assembling incorrectly is being looked at by Wei Dai: https://bugs.launchpad.net/ubuntu/+bug/461303 | 16:38 |
| ubottu | Launchpad bug 461303 in binutils "generates-bad-code regression" [Undecided,New] | 16:38 |
| mvo | Riddell: do you have a master bug for this? | 16:38 |
| Riddell | mvo: no, I think you can just move this one to kdebindings if you want | 16:38 |
| mvo | Riddell: thanks, done that and targeted to karmic-updates | 16:40 |
| cjwatson | Gizmo: I got it from having written a fairly substantial amount of the code and knowing it well :) | 16:40 |
| cjwatson | Gizmo: feel free to quote me | 16:40 |
| Gizmo | cjwatson: ha - I see!! | 16:41 |
| Gizmo | cjwatson: thats impressive then | 16:41 |
| cjwatson | Gizmo: you can 'apt-get source PACKAGE' with any of the things I quoted instead of PACKAGE (except that chpasswd is in shadow) | 16:41 |
| cjwatson | and read the code | 16:41 |
| Gizmo | Would you tell me your real name? Mine is Ted Smith, if that helps | 16:41 |
| cjwatson | though it's a pretty big codebase | 16:41 |
| cjwatson | Gizmo: type '/whois cjwatson' at your IRC client | 16:41 |
| cjwatson | Gizmo: yes, I think it is interesting, and we may want to consider just always zeroing swap at the end of installation | 16:42 |
| Gizmo | Can I ask what your offocial title is in Canonical? | 16:42 |
| cjwatson | since there's a lot of code in the installer that is not especially security-conscious | 16:42 |
| cjwatson | Gizmo: you can't reliably assume that all Ubuntu developers work for Canonical, although as it happens I do | 16:43 |
| * slangasek patches ubiquity to call mlockall() | 16:43 | |
| cjwatson | Technical Lead, Ubuntu Foundations Team | 16:43 |
| Gizmo | cjwatson: Thanks very much. Will I get my name in lights anywhere if you implement this...ha? | 16:43 |
| cjwatson | slangasek: hah. (does fork/execve preserve mlockall) | 16:43 |
| cjwatson | Gizmo: if you file a bug, you might get a changelog mention :) | 16:43 |
| cjwatson | slangasek: ah, fork documents that it doesn't | 16:44 |
| slangasek | right :) | 16:44 |
| cjwatson | and indeed so does execve | 16:44 |
| Gizmo | cjwatson: maybe I'll do that then. Is there a proper place to do that (obviously there is, I am being lazy and asking you what it is!!)? | 16:44 |
| cjwatson | Gizmo: https://help.ubuntu.com/community/ReportingBugs; the relevant package name (to start with, anyway) is ubiquity | 16:45 |
| spaetz | Gizmo, bugs.ubuntu.com | 16:45 |
| joaopinto | Gizmo, you maybe interested in http://philosecurity.org/research/cleartext-passwords-linux | 16:45 |
| joaopinto | you are just addressing a particular case of plaintext passwords lifecycle | 16:46 |
| mathiaz | cjwatson: I'm trying to find a workaround for bug 458904 | 17:17 |
| ubottu | Launchpad bug 458904 in eucalyptus "Adding nodes in several waves after launching VMs is not possible" [High,Confirmed] https://launchpad.net/bugs/458904 | 17:17 |
| mathiaz | cjwatson: is there a reason why euca_find_cluster is using avahi_address_snprint? | 17:18 |
| mathiaz | cjwatson: it seems that in some cases avahi_address_snprint doesn't return the correct IP address | 17:18 |
| mathiaz | cjwatson: we've already run into a similar bug when the IP was 169.254.169.254 and we've special-cased it | 17:19 |
| mathiaz | cjwatson: it seems that the bug comes back in other configurations | 17:19 |
| mathiaz | cjwatson: so I was wondering why we should not always use the name and no the human_address? | 17:20 |
| mathiaz | cjwatson: see https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/458904/comments/4 | 17:20 |
| ubottu | Launchpad bug 458904 in eucalyptus "Adding nodes in several waves after launching VMs is not possible" [High,Confirmed] | 17:20 |
| === beuno-lunch is now known as beuno | ||
| cjwatson | mathiaz: I have no idea, I think I was using what appeared to make sense at the time :) | 17:46 |
| MacSlow | ehm... what happened to the packages name xserver-xorg-video-ati? | 17:47 |
| cjwatson | MacSlow: nothing | 17:47 |
| MacSlow | I can't reassign a bug to that package anymore | 17:48 |
| MacSlow | cjwatson, some lp issue? | 17:48 |
| cjwatson | I have no idea | 17:48 |
| cjwatson | it's a valid package name | 17:48 |
| MacSlow | cjwatson, ehm... hm.. *shrug* | 17:49 |
| Chipzz | Gizmo: btw, there's also (I think) #ubuntu-installer | 17:57 |
| Chipzz | which is about ubiquity/debian-installer | 17:57 |
| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| === MacSlow is now known as MacSlow|capoeira | ||
| === robbiew is now known as robbiew-afk | ||
| LaserJock | are the Ubuntu release notes kept on the wiki after release? | 18:36 |
| slangasek | yes | 18:36 |
| slangasek | "kept" in the sense that they're available there for further editing, not that the wiki is the official location | 18:37 |
| LaserJock | ah | 18:37 |
| LaserJock | slangasek: the official location is on ubuntu.com? | 18:38 |
| LaserJock | I assume anyway | 18:38 |
| slangasek | yes, e.g. http://www.ubuntu.com/getubuntu/releasenotes/910 | 18:38 |
| primes2h | cr3: Hello, I just upgraded checkbox to 0.8.5 version but translation is still missing some strings | 18:40 |
| primes2h | cr3: it's not updated | 18:41 |
| primes2h | cr3: any ideas? | 18:42 |
| cr3 | primes2h: I downloaded the strings when we last discussed, but I actually received confirmation that launchpad accepted my pot file yesterday | 18:45 |
| cr3 | primes2h: I'm not sufficiently familiar with launchpad translations to understand exactly what might be the problem | 18:45 |
| primes2h | cr3: That strings are ok, I just checked them | 18:45 |
| primes2h | cr3: did you put them in your package? | 18:46 |
| cr3 | primes2h: cool, so what strings aren't translated then? | 18:46 |
| cr3 | primes2h: yeah, I'll pull up the commit I did with the tarball launchpad sent me... one moment | 18:47 |
| primes2h | cr3: I mean the tar.gz I showed you is ok. | 18:47 |
| cr3 | primes2h: this is what I received by email: http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/revision/682 | 18:48 |
| primes2h | cr3: but translations appearing using the package are the same as they were | 18:48 |
| primes2h | two days ago | 18:48 |
| cr3 | err, that's the commit I did based on the tarball I received by email | 18:48 |
| cr3 | primes2h: hm, that's very strange indeed | 18:48 |
| primes2h | cr3: those po are ok | 18:49 |
| primes2h | cr3: but the application still shows them not correctly | 18:50 |
| cr3 | primes2h: it seems that lp:ubuntu/karmic/checkbox has not been updated, so I don't know from what sources the package was built | 18:51 |
| primes2h | cr3: What is strange is that some new strings are translated, other are not. | 18:52 |
| primes2h | cr3: it seems that they have been taken in the middle of translations | 18:52 |
| primes2h | cr3: I mean | 18:52 |
| primes2h | cr3: there is a string (a new one) that I translated and then I updated one hour after. | 18:53 |
| primes2h | cr3: it shows the first translation | 18:53 |
| primes2h | but it was still Thursday.. 17.00 in the afternoon | 18:54 |
| mathiaz | cr3: https://launchpad.net/ubuntu/+source/checkbox/ | 18:54 |
| mathiaz | cr3: ^^ this has the updated source package | 18:54 |
| mathiaz | cr3: http://launchpadlibrarian.net/34423527/checkbox_0.8.4_0.8.5.diff.gz | 18:55 |
| mathiaz | cr3: ^^ diff between 0.8.4 and 0.8.5 - new translations are there | 18:55 |
| cr3 | primes2h: can you have a look at the above diff and let me know if those po changes look alright? | 18:55 |
| primes2h | cr3: The italian one is OK. | 18:57 |
| cr3 | primes2h: is the italian translation in the above diff different from the one in the package? | 18:57 |
| hyperair | YokoZar: i've more or less nailed it down, filed the bugs, and attached the patches =) | 19:00 |
| primes2h | cr3: no, it's the same | 19:00 |
| === asac_ is now known as asac | ||
| primes2h | cr3: I just downloaded the source package | 19:00 |
| primes2h | I've | 19:02 |
| primes2h | cr3: now I must go. I'll be here in 1 and a half hour | 19:03 |
| slangasek | LaserJock: ETA of 1h30 for the respin of edubuntu DVDs to finish | 19:24 |
| slangasek | LaserJock: will be 20091027.1 when available | 19:24 |
| LaserJock | slangasek: k, thanks | 19:24 |
| hdon | hi all. i have some funny iconv behavior.. i think. can someone take a look at these couple of lines? http://pastebin.mozilla.org/679415 | 19:32 |
| slangasek | cody-somerville: will http://xubuntu.org/news/9.10-release be the url I want to link from the announcement? | 19:32 |
| slangasek | superm1: is http://mythbuntu.org/9.10/release going to be the right url to link from the announcement? | 19:33 |
| slangasek | TheMuso, luisbg: will there be a release announcement page for Ubuntu Studio that you want me to link to, or will you use the download page like before? | 19:34 |
| ion | hdon: Looks right. | 19:34 |
| hdon | ion: well, isn't UTF-8 "C3 89" the character e-accent-acute? in ISO-8859-1 that should be C9 | 19:35 |
| luisbg | slangasek, we can use the download page as before... the release notes are linked from there | 19:35 |
| luisbg | slangasek, or we can send you the link to the release notes (once we publish them) | 19:35 |
| luisbg | what do you think is best? | 19:35 |
| cody-somerville | slangasek, what is the url the ubuntu website is using? | 19:36 |
| ion | hdon: You’re saying “please convert this ISO-8859-1 string to UTF-8” and passing it C3 89. | 19:36 |
| slangasek | cody-somerville: I don't think there's an equivalent, really | 19:36 |
| hdon | ion: no, that's backwards | 19:36 |
| superm1 | slangasek, Yes | 19:36 |
| slangasek | cody-somerville: this is the draft content for the email: https://wiki.ubuntu.com/KarmicKoala/ReleaseAnnouncement | 19:36 |
| hdon | !! | 19:37 |
| hdon | oh | 19:37 |
| hdon | ion: thanks | 19:37 |
| cody-somerville | slangasek, Okay, the url you mentioned will be used. | 19:37 |
| slangasek | luisbg: would need to have the url available to me beforehand, timing is a little tight at release time :) I can just use the download page, then | 19:37 |
| slangasek | superm1: ok, thanks for confirming | 19:37 |
| slangasek | cody-somerville: ack, thanks | 19:37 |
| luisbg | slangasek, we use the wiki so I can have the URL decided before writing the document | 19:40 |
| luisbg | slangasek, https://wiki.ubuntu.com/UbuntuStudio/9.10release_notes | 19:40 |
| luisbg | like that :) | 19:41 |
| slangasek | luisbg: ok - fwiw, I'm not sure how available the wiki is going to be during the release, but I can point there if you wish | 19:42 |
| luisbg | slangasek, how available the wiki si going to be during release? | 19:43 |
| luisbg | what do you mean? | 19:43 |
| slangasek | luisbg: wiki.ubuntu.com tends to get crushed by the traffic around release time | 19:44 |
| luisbg | ahhh ok | 19:44 |
| luisbg | slangasek, thats fine, I will get the document ready then sooner possible | 19:45 |
| === dendro-afk is now known as dendrobates | ||
| jdstrand | ttx: hey. I noticed people are getting rather vocal in bug #426497 | 20:22 |
| ubottu | Launchpad bug 426497 in qemu-kvm "kqemu mode not compiled for karmic" [Wishlist,Won't fix] https://launchpad.net/bugs/426497 | 20:22 |
| jdstrand | ttx: I don't know if it is documented anywhere, but it perhaps should be that kqemu support is no more. just my two cents | 20:23 |
| jdstrand | ttx: though, I must say I am saddened that it is gone myself | 20:23 |
| jdstrand | *sniff* | 20:23 |
| jdstrand | (I know why though) | 20:23 |
| primes2h | cr3: I think I've worked out what happened | 20:23 |
| ttx | jdstrand: let me look | 20:24 |
| primes2h | cr3: langpacks should have priority over package pos | 20:24 |
| primes2h | cr3: but | 20:24 |
| primes2h | cr3: for a strange reason translations were taken early during the day (22) | 20:27 |
| primes2h | cr3: They are usually taken on the evening, I don't know why in this cycle they have been worked out earlier | 20:30 |
| cr3 | primes2h: thanks for sharing that, I still have a lot to learn about the release process | 20:32 |
| ttx | jdstrand: makes sense to document that... | 20:35 |
| ttx | kirkland: ^? | 20:35 |
| primes2h | cr3: no problem. ;) I'm only a bit angry about that out-of-the-common thing. | 20:41 |
| LaserJock | I need a KDE karmic user | 20:42 |
| dtchen | LaserJock: ...for? | 20:44 |
| LaserJock | dtchen: I'd like to know what comes up when you search for Edubuntu in Kpackagekit (or whatever GUI package installer is used) | 20:44 |
| highvoltage | what is the kubuntu package tool thingy these days? I think last when I used Kubuntu it was Kynaptic | 20:46 |
| dtchen | LaserJock: sec, vbox is taking a bit | 20:53 |
| dtchen | LaserJock: http://kernel.ubuntu.com/~dtchen/20091027_vbox_kubuntu-desktop-i386-kpackagekit-edubuntu-search.png | 20:56 |
| LaserJock | dtchen: perfect! | 20:58 |
| highvoltage | heh, I guess I can stop my kpackagekit installation then | 20:59 |
| TheMuso | slangasek: Re studio, I don;t know what the others want, I am not involved with putting pages together etc, so unless you've received a different answer, I'd just say go the download page... If its been updated. :) | 21:21 |
| === rbelem__ is now known as rbelem | ||
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| dupondje | https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/456261 | 22:14 |
| ubottu | Launchpad bug 456261 in network-manager "NetworkManager won't allow user to edit settings of Mobile Broadband connection" [Undecided,New] | 22:14 |
| dupondje | surely a to-fix-for-final :P | 22:14 |
| === MacSlow|capoeira is now known as MacSlow | ||
| TheMuso | dupondje: Likely an SRU at this point. | 22:16 |
| joaopinto | or maybe not | 22:16 |
| joaopinto | it doesn't look reproducible | 22:16 |
| dupondje | can reproduce it every time :s | 22:17 |
| dupondje | just make a Mobile Connection in NetworkManager | 22:17 |
| dupondje | enable 'availible to all users' | 22:17 |
| dupondje | close Network Manager | 22:17 |
| dupondje | start it again | 22:17 |
| dupondje | try to edit the connection | 22:17 |
| dupondje | it asks for password, you enter it, you get error | 22:18 |
| dupondje | and NetworkManager crashes | 22:18 |
| dupondje | :p | 22:18 |
| dupondje | joaopinto: you can reproduce ? .) | 22:25 |
| joaopinto | no | 22:25 |
| msaraujo | hi | 22:27 |
| msaraujo | hi | 22:33 |
| msaraujo | if I install libsvn-dev, how can I include the svn headers? | 22:34 |
| joaopinto | msaraujo, read the topic :) | 22:34 |
| msaraujo | joaopinto: okay. | 22:35 |
| jdstrand | slangasek: fyi-- bug #462258 | 22:35 |
| ubottu | Launchpad bug 462258 in mdadm "raid1 won't boot in degraded mode" [Undecided,New] https://launchpad.net/bugs/462258 | 22:35 |
| jdstrand | slangasek: I can't do any more triage atm | 22:35 |
| jdstrand | will try back later | 22:35 |
| msaraujo | joaopinto: have a nice day | 22:36 |
| === mnepton is now known as mneptok | ||
| William-Ubuntu | can any body tell me the different between ubuntu 9.10dvd and cd? | 22:41 |
| TheMuso | William-Ubuntu: The DVD has both the live image, and the packages in individual debs. | 22:41 |
| William-Ubuntu | thanks | 22:42 |
| TheMuso | np | 22:42 |
| maxb | Is the DVD basically the live CD plus the alternate CD plus lots of .debs ? | 22:50 |
| TheMuso | maxb: I believe so. | 22:53 |
| === dupondje- is now known as dupondje | ||
| ebroder | The security team's PPA is restricted access, right? How do they do that? | 23:29 |
| ebroder | (on an apt level, not a Soyuz level) | 23:29 |
| wgrant | ebroder: HTTP authentication, with the credentials embedded in the URL in sources.list. | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
