[00:38] <legreffier> Hello here :)
[01:17] <lifeless> does jockey complain about non-free firmware?
[01:27] <maxb_> ooi, why have the recent intrepid updates been issued through intrepid-security rather than intrepid-updates? The changelogs don't make them sound like security issues.
[01:39] <kees> maxb_: the kernel update was a security issue.  the base-files thing is mostly to clean up a pre-release glitch, which was security related.  all very confusing and last minute.  :P
[02:16] <nixternal> kees: would the base-files package cause issues I am seeing where when running ant all of a sudden changes - to _ ? this issue is driving me up a wall and it just started happening today, and for everyone else at work at upgraded to Intrepid
[02:44] <NCommander> Hola world
[02:44] <TheMuso> hey NCommander.
[02:45] <NCommander> I'm in Boston, I just attended my first Ubuntu release party <g>
[02:47]  * ajmitch hasn't been to one yet :)
[02:49] <nixternal> I was supposed to go to the Michigan one on Saturday, but a silly wedding is stopping me
[02:49] <NCommander> I also got to meet my first (X)ubuntu developer in real life
[02:50] <nixternal> who was it?
[02:50] <NCommander> cody-somerville
[02:52] <TheMuso> NCommander: and how was that experience?
[02:52] <nixternal> NCommander: oh man, don't ever talk to cody-somerville again, he can be dangerous :P
[02:53] <NCommander> TheMuso, fascinating
[02:53] <NCommander> nixternal, I'll make sure to tell him you said that, he's less than five feet away from me ATM
[02:53] <nixternal> he will see the highlight when he gets back, and then he will beat me up I am sure
[02:53]  * cody-somerville sucker punches nixternal.
[02:54] <nixternal> told ya
[02:54] <nixternal> if it is a release "Party", why are you geeks online?
[02:54] <nixternal> see, in Chicago, our parties are...well just that, a party :)
[02:54] <NCommander> nixternal, I thought in Chicago they ended in a fight on how the White Soxes play baseball ;-)
[02:55] <nixternal> the real people in Chicago don't care about the White Sox
[02:55] <NCommander> nixternal, cause $Party->over();
[02:55] <NCommander> nixternal, I was said when the Chicago Sun building was town down. There is like a big gap where it used to be in my heart
[02:56] <nixternal> well, there is a big golden building now in that spot with Trumps name all over it :)
[02:56] <NCommander> ewwwwwwwwwwwwwww
[02:56] <nixternal> I work right down the street from it
[02:56] <NCommander> I would pass if it I still took the 10 bus to go anywhere
[02:56] <nixternal> ooh the 10...I take the 51 or a cab everywhere now...CTA is garbage
[02:57] <NCommander> They haven't run the Loop into the ground (yet)
[02:57] <nixternal> the loop will be there forever
[02:58] <NCommander> Not for a lack of trying
[02:58]  * NCommander remembers when the Loop used to be faster then taking a car from O'Hare
[02:59] <nixternal> oh, you are just talking about the El in general.... ya, that is a long ass ride on the blue line from o'hare to the city
[03:00] <NCommander> I've always referred to it as the Loop
[03:00]  * NCommander is not a Chicago native, but it is a place I would love to live
[03:01] <NCommander> Although I've always wanted to go see Hell when its frozen over
[03:04] <nixternal> haha
[03:05] <NCommander> nixternal, ah, good you know what I'm talking about
[03:06] <nixternal> in 3 more months, hell will freeze over
[03:06] <vorian> werd
[03:06] <vorian> that's the truth
[03:06] <vorian> in more ways than one :P
[03:07] <NCommander> Yeah, Microsoft will open source Vista
[05:52]  * calc wants his jaunty fix :)
[06:00] <MK93013> I have installed package ubuntu-xen-server using apt-get  command. When I restart my computer I dont' get choice to boot from xen server... I have ubuntu 8.04 on my machine.. Has anyone run into this issue ?
[06:10] <kees> nixternal: not base-files, sorry.  it just fixes some file perms that were only a problem if you installed intrepid from a beta or earlier.
[06:45] <dholbach> good morning
[07:02]  * soren gets all excited as he subscribes to jaunty-changes
[07:02] <dholbach> yeeehaaaaw
[07:02]  * dholbach hugs soren
[07:03]  * soren hugs dholbach :)
[08:03]  * lool waves 'morning
[08:24] <lool> Hmm weird, I have a 404 with the .deb referenced of rhythmbox referenced in intrepid-proposed
[08:25] <mvo> lool: probably one of the round-robin servers not in sync yet
[08:26] <lool> Could be; thanks
[08:30] <seb128> hey mvo lool
[08:30] <seb128> mvo: not on holiday?
[08:31] <mvo> hey seb128
[08:31] <mvo> seb128: no, should i?
[08:32] <seb128> mvo: well, pitti sent a mail saying most of germany has a national holiday today so I was wondering ;-)
[08:34] <seb128> mvo: you likely have tomorrow as we have
[08:34] <seb128> but that's a saturday this year so
[08:35] <mvo> I have no touch to the real world, let me check with wikipedia ;)
[09:35] <kagou> i'v some problem hacking gfxboot. I'm doing localised iso in french for ubuntu-fr. I'v created lang and langlist with just "fr" in but help menu are always english version at menu boot.
[09:36] <kagou> im ean for F1 help screens
[09:38] <VSpike> Can anyone who knows how to use GDB have a look at this bug and suggest how I can debug it further? https://bugs.launchpad.net/ubuntu/+source/samba/+bug/290673
[09:39] <VSpike> I want to add a backtrace to the report but I can't seem to get gdb to attach properly
[09:39] <kagou> cjwatson, may be can you help me
[09:39] <VSpike> The essence is that when using fusesmb, libsmbclient.so crashes out with a segfault.
[09:53] <cjwatson> kagou: what version?
[09:53] <kagou> cjwatson, 8.10
[09:53] <kagou> included in intrepid 8.10
[09:54] <kagou> cjwatson, i'v do this :
[09:54] <kagou> cd extract-cd/isolinux
[09:54] <kagou> echo "fr" > langlist
[09:54] <kagou> echo "fr" > lang
[09:55] <kagou> but F1 Help screens are still in english
[09:55] <cjwatson> kagou: pretty sure that's meant to work, perhaps you could file a bug
[09:55] <cjwatson> and I'll see if I can figure it out from there
[09:55] <kagou> cjwatson, on gfxboot-theme ?
[09:55] <cjwatson> gfxboot-theme-ubuntu
[09:55] <kagou> indeed, ok thanks
[09:57] <joaopinto> can someone confirm bug 291161 ?
[09:58] <kagou> cjwatson, in fact it seem's that this is the case on the official iso too
[10:01] <kagou> ok cjwatson #291492
[11:41] <lool> Err do I understand correctly that all exports in /usr/share/initramfs-tools/init are passed down to init and the whole sysv init scripts?!
[11:56] <apw> superm1: about?
[12:02] <soren> lool: I believe that's the intent, yes.
[12:21] <lool> soren: that's awful :-(
[12:21] <lool> MODPROBE_OPTIONS for one is disruptive
[12:22] <lool> It leaks so many generic names: blacklist panic debug ROOT quiet
[12:23] <cjwatson> perhaps it should unset disruptive ones
[12:23] <cjwatson> I don't think it should necessarily clear the whole environment
[12:24] <lool> cjwatson: I think it should only export for init the ones which it cares to export to init
[12:24] <soren> lool: Oh, sorry.
[12:24] <lool> it's one thing to do the exports for the other initramfs scripts, but the way it's implemented it's too easy to export to the whole init script
[12:24] <soren> lool: No, I misunderstood your initial question.
[12:25] <cjwatson> lool: it wouldn't surprise me if some things depend on the behaviour that foo=bar passed on the kernel command line sets environment variable foo
[12:25] <soren> lool: Hm... Let me check something.
[12:25] <cjwatson> lool: so I think we should be pretty careful here
[12:25] <lool> cjwatson: I fully agree that it's going to be hard to fix this situation
[12:26] <lool> I suspect this makes it harder to not use an initrd, or to use a different initrd implementation
[12:26] <soren> Doesn't init sanitize the environment?
[12:26] <lool> cjwatson: e.g. I just discovered that modprobe --all --quiet was broken, while modprobe --all works; the quiet is likely to have been set by the above MODPROBE_OPTIONS
[12:27] <lool> (obviously a bug, but I don't want people writing init script to rely on the behavior which is an accidental consequence of MODPROBE_OPTIONS)
[12:27] <cjwatson> the number of exports is strictly bounded, and I think it'd be easy for initramfs-tools to clean up after itself
[12:27] <lool> soren: I think login might
[12:28] <cjwatson> init probably expects some things (e.g. PATH) to be set for it by the kernel
[12:28] <lool> So when runs e.g. /etc/init.d/acpid start, it's not the same env as during boot and can behave differently
[12:28] <cjwatson> but it's been a while since I looked
[12:29] <cjwatson> of course, it's not the same environment anyway. ISTR some people being bitten by DISPLAY being set, and there's always the problem of daemons hanging on to file descriptors.
[12:29] <lool> I certaintly don't want to add an env -i or something to initramfs; perhaps having something like an env dump and restore, or a subshell, or unsetting some specific env vars would do
[12:29] <cjwatson> So I don't think we necessarily need to be too set on it being an identical environment
[12:30] <cjwatson> a certain amount of cleanup does need to be handled on a per-package basis
[12:30] <lool> cjwatson: Well it's the opposite bug here
[12:30] <soren> cjwatson: Actually, upstart seems to explicitly set PATH.
[12:30] <cjwatson> oh, ok
[12:32] <soren> From upstart/init/process.c:
[12:32] <soren>         /* Inherit PATH and TERM from our parent's environment, everything
[12:32] <soren>          * else is often just overspill from initramfs.
[12:32] <soren>          */
[12:32] <soren>         NIH_MUST (path = nih_strdup (NULL, getenv ("PATH")));
[12:32] <soren>         NIH_MUST (term = nih_strdup (NULL, getenv ("TERM")));
[12:32] <soren>         if (clearenv () < 0)
[12:32] <soren>                 nih_return_system_error (-1);
[12:32] <lool> cjwatson: I kind of wonder whether invoke-rc.d shouldn't be cleaning the environment in some ways
[12:33] <lool> cjwatson: It strikes me that if you restart apache2 with DISPLAY, dbus, XDG and what not env vars, you might be leaking interesting information
[12:33] <cjwatson> mm, I'd tend to agree there
[12:33] <soren> lool: No.
[12:33] <soren> lool: Apache's init script clears the environment.
[12:33] <lool> Not as grave has the filehandle on the terminal but still
[12:33] <lool> soren: Pretty bad example then
[12:34] <lool> soren: $other service :)
[12:34] <soren> lool: But you're right about the theory.
[12:34] <soren> lool: :)
[12:34] <lool> arf, i see apache resets path which puts the discussion on ruby gems in yet another light
[12:36] <lool> Hmm if we try to not leak too much env when invoke-rc.d-ing services, then we ought to do the same on startup
[12:37]  * lool pictures months of effort to fix this
[12:42] <ma10> bryce: why do you keep closing Bug #211610? Do I have to open another bug so that I am the original reporter?
[12:43] <cjwatson> ma10: it's often a good idea to file a new bug anyway. It's easier to mark a bug as a duplicate when it turns out to be the same than it is to split comments out of a bug when it turns out to be different.
[12:44] <cjwatson> ma10: hence why we talk about "original reporter", because it's very common for people to tag along with an existing bug when it actually turns out that they have a different bug with similar symptoms
[12:45] <ma10> cjwatson: I'm pretty sure it's the exact same issue.. I'll do it anyway. Thanks
[12:48] <lool> I didn't get the env vars I fear I'd get with upstart
[12:49] <lool> It might be clearing the env
[12:51] <lool> clearenv() in init/procesS.c
[12:51] <lool>         /* Inherit PATH and TERM from our parent's environment, everything
[12:51] <lool>          * else is often just overspill from initramfs.
[12:51] <lool>          */
[12:51] <soren> lool: i pasted that code 20 minutes ago :)
[12:51] <lool> soren: Doh
[12:52] <soren> lool: i also just checked.. I don't have a lot of superfluous stuff in my environment in my init scripts..
[12:52] <lool> soren: I guess it's only with sysvinit
[12:52] <soren> lool: I have the following variables:
[12:52] <soren> runlevel, QUIET, UPSTART_JOB, UPSTART_JOB_ID, TERM, PATH, RUNLEVEL, PREVLEVEL, UPSTART_EVENT, PWD, previous, and VERBOSE. That's it.
[12:54] <lool> I have about the same
[12:54] <lool> So at least this is a strong motivation that fixing initramfs wouldn't break Ubuntu :)
[12:56] <soren> lool: or fix sysvinit?
[12:56] <soren> lool: Why are you using sysvinit anyway?
[12:56] <lool> soren: or fix both; but I can't help but think we should limit the number of places where we clear the env
[12:57] <soren> lool: "fixing initramfs" is kind of hard. There are quite a lot of packages that put stuff in initramfs.
[12:57] <lool> soren: I'm not; I wanted to fix a bug in modprobe in boht Debian and Ubuntu, but I'm using upstart on both; when I understood the bug, it seemed it would affect everybody equally but it doesn't affect upstart
[12:58] <lool> soren: Well if upstart clears the env, initramfs could do so as well -- jsut an example quick solution, i don't want to advocate this particular implementation of the fix
[12:59] <lool> bbiab
[13:02] <cjwatson> I suspect lots of the exports in casper at least are unnecessary and that plain shell variable settings would do fine
[13:04] <ogra> dont drop COMPCACHE_SIZE !
[13:04] <ogra> its necessary to be exported
[13:05] <lool> ogra: down upstart?
[13:05] <ogra> (it can be unset before changing over to eh real root though)
[13:05] <ogra> *the
[13:05] <ogra> lool, its not used after initramfs, but inside initramfs it needs to stay exported
[13:07] <benjo> Hello everybody, I have a problem
[13:08] <benjo> I installed ubuntu 8.10 on my macbook
[13:09] <benjo> but this doesn't work correctly, the rEfit doesn't work
[13:09] <Pici> benjo: The support channel is #ubuntu, have you asked there yet?
[13:10] <benjo> ok
[13:52] <rtg> anyone know where smbd gets its list of shares from?
[13:54] <sistpoty|work> rtg: /etc/samba/smb.conf
[13:55] <rtg> sistpoty|work: thats what I thought too, but no joy.
[13:56] <sistpoty|work> rtg: strange... but I guess slangasek would know for sure ;)
[13:57] <rtg> If you do it via the gnome file manager, I wonder if its stored in a binary format somewhere.
[13:57] <amitk> rtg: do what?
[13:57] <sistpoty|work> that would leave the question, how smbd would access it then
[13:58] <amitk> rtg: you can check gconf-editor in for gnome specific configs
[13:58] <sistpoty|work> rtg: maybe gnome file manager directly uses ipcclient?
[13:58] <rtg> amitk: if you share a folder so that a windoz box can mount it. I'm replicating my dev box, and just want to copy a conf file.
[14:00] <rtg> amitk: if I don't share this one directory , then the spousal unit checkbook doesn't work and I will suffer sudden and intense grief.
[14:02] <rtg> amitk: .gnome2/nautilus-share-modified-permissions
[14:02] <amitk> rtg: didn't know you could share a folder using gnome file manager. So you have your windows domain, etc. configured in smb.conf already?
[14:03] <rtg> amitk: I just left it as the default WORKGROUP, but you have to add whatever account will be attaching using 'smbpasswd -a'
[14:07] <amitk> rtg: then I'm at a loss since I don't run samba on the network.
[14:07] <rtg> amitk: oh, I found it in /.gnome2/nautilus-share-modified-permissions, but I guess it means I have to be logged in before the shares are advertised.
[14:08] <amitk> aah.. i don't even have that file. I guess it is created when you first create a share
[14:08] <rtg> thats what I assume
[14:21] <jdong> asac: is network-manager supposed to forget wired static settings every reboot? :(
[14:22] <asac> jdong: yes there is a bug for "nm forgets settings if you change auto connection without renaming them"
[14:22] <asac> jdong: so try to rename your connection or create a new one
[14:22] <asac> jdong: is that system or user setting?
[14:23] <jdong> asac: I did rename it to "MIT Static" and appled it system wide, after some combination of rebooting and suspending it was lost
[14:23] <jdong> only figured out this morning when I had to scan all of 18.96.0.0/16 to find my machine :D
[14:23] <asac> jdong: try again. if no file is saved in /etc/NetworkManager/system-connections then its not saved
[14:24] <asac> jdong: could also be a dbus/policykit bustage thing (especially if your system is running for a while this appears to become more unreliable)
[14:24] <jdong> asac: ok, I'll give it another shot
[14:24] <jdong> asac: apply systemwide should trigger a policykit dialog, right?
[14:24] <asac> jdong: yeah ... and look for crsahes of consolekit ... if that thing goes down nothing works anymore
[14:25] <asac> jdong: yes. it should and it does if everything is in clean state. i think consolekit crashes are the most common reason for this not working
[14:25] <asac> jdong: please play around
[14:25] <asac> jdong: and let me know when the file is created and when not
[14:25] <jdong> asac: okay I'll give this a try when I get back in my room in an hour
[14:25] <jdong> asac: I'll let you know if the file gets created
[14:26] <asac> jdong: yes try different things: a) rename auto ... b) create new ...
[14:26] <jdong> ok, will do
[14:27] <jdong> asac: one clue is I don't recall ever getting a policykit auth dialog when I hit apply systemwide
[14:27] <jdong> I'll verify that when I get back
[14:27] <jdong> if policykit is rejecting something, where is it logged?
[14:27] <asac> jdong: i think it should pop up ... not sure how much any "do auto authentication" might prevent that from happening
[14:27] <asac> but i think policykit is at least supposed to pop up
[14:28] <asac> jdong: well if nothing happens look at syslog ... and see if consolekit has crashed
[14:28] <jdong> will do
[14:50] <MacSlow> pitti, dbus still hates me
[14:50] <MacSlow> pitti, got a minute (or perhaps 5)=
[14:50] <MacSlow> ?
[14:54] <james_w> jdong: /var/log/auth.log
[15:08] <Keybuk> kees: ah, you've already done a fix for the dictionaries-common problem?
[15:11] <pitti> Good afternoon
[15:12] <pitti> MacSlow: how does it hate you today?
[15:15] <pitti> hm, still no -proposed updates for me
[15:15] <lool> in base-files 4.0.4ubuntu2.2 AIUI
[15:16] <jdong> asac: Update: Editing or renaming the Auto eth0 connection has no effect, even when system-wide is checked. No PolicyKit auth dialog, no /etc/network-manager files, completely lost when network-manager restarts
[15:17] <jdong> asac: creating a new profile does work and survive reboots AFAICT
[15:17] <asac> jdong: no policykit pop up in any case?
[15:17] <jdong> asac: the latter case (creating a new profile system-wide) does pop up PolicyKit correctly
[15:18] <jdong> asac: but it seems like renaming or modifying Auto eth0 doesn't work period
[15:32] <kees> Keybuk: yeah, it was a bit of a sledgehammer solution, but it seems to behave okay
[15:32] <kees> Keybuk: http://people.ubuntu.com/~kees/base-files_4.0.4ubuntu2.2.debdiff
[15:33] <Keybuk> :p
[15:33] <Keybuk> I assume it was dictionaries-common you noticed too?
[15:36] <Keybuk> lool: ROFL @
[15:36] <Keybuk> This isn't a problem for upstart systems such as Ubuntu systems as
[15:36] <Keybuk> upstart clearenv()s in init/process.c (with the comment that initramfs
[15:36] <Keybuk> is leaking env!), but it is a problem for sysvinit systems such as
[15:36] <Keybuk> Debian.
[15:41] <superm1> hi apw yeah
[15:42] <sabdfl> BADSIG on update today?
[15:43] <lool> Keybuk: Hmm?
[15:43] <lool> Keybuk: Eh I actually didn't reproduce an acpid problem by using upstart instead of sysvinit
[15:47] <MacSlow> pitti, remember the email I send you some days ago.
[15:48] <MacSlow> pitti, by now I tried every combination of yes, no and auth_admin ... reboot and shutdown can no long be triggered
[15:49] <MacSlow> pitti, I tried it via my own calls to dbus and also via d-feet
[15:49] <MacSlow> everytime I get "no privilege"-errors
[15:49] <ogra> sabdfl, seems to work here
[15:49] <ogra> (though i'm using a.u.c directly, not the german mirror)
[15:50] <sabdfl> ogra: that's the one i'm using too
[15:51] <ogra> its very slow but i just got all updates including new kernel
[15:52] <apw> superm1: you said i should check back in with you at the end of the week about a studio 15 i have which has some issues with intrepid
[15:52] <Keybuk> lool: ?
[15:52] <superm1> apw, sure what's happening
[15:54] <apw> i have two issues right now.  first the sound is all crackles under alsa (which may be a wider issue than just dells) and resume has become 95% hangs
[15:55] <apw> on the resume (from suspend or hibernate) we get as far as flipping to X and typically it hangs the machine hard with just the cursor on the black screen, sometimes it gets a little further
[15:56] <apw> and puts up the background of the password box, but no actual contents.  on the hardy kernel i still have the sound is ok, and the resume is more like 95% successful, but it does hang the same way intermittantly
[15:57] <apw> there is a bug for both out there.  bug#289212 and bug#273578
[15:58] <pitti> MacSlow: sounds like a missing XDG_SESSION_COOKIE then
[15:59] <MacSlow> pitti, like I mentioned in my email-reply XDG_SESSION_COOKIE is set for sure
[15:59] <superm1> apw, are you on the intel or amd graphics variant?
[15:59] <pitti> MacSlow: have a confcall now, will look at your mail later
[15:59] <apw> intel usin the i915 driver i believe
[15:59] <MacSlow> pitti, it used to work just during the week of the summit/hackfest
[16:00] <MacSlow> pitti, main changes were only package-updates on my intrepid-based laptop
[16:00] <MacSlow> pitti, ok I'll look out for your emails
[16:00] <apw> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
[16:00] <superm1> apw, well normally you should be testing on command line with pm-suspend.  sleep.sh is deprecated
[16:01] <apw> yep pm-suspend hangs just the same as using the fast-user-switcher
[16:01] <superm1> apw, you are the first report that i've heard with issues related to this though
[16:01] <superm1> apw, when it's hung, can you get ssh'ed in?
[16:02] <apw> i was put onto sleep.sh just because it is how one is meant to debug suspend, and it showed that the machine can come back from resume.  in that case it gets stuck trying to use vbetool post to restore the graphics
[16:03] <apw> nope, enabled sshd and she is not back on the network.  _but_ there is no gueantee that network manager has restored the network if x is stopped
[16:03] <superm1> right
[16:04] <superm1> apw, you might check with rtg on the sound.  it shares the same chipset as another laptop rtg was struggling with similar issues
[16:04] <apw> yeah, i did talk to him earlier in the week, but with the release it seemed sensible to wait a while
[16:05] <apw> i think its pretty widespread and as he has a broken example too i suspect it'll get fixed without my input
[16:05] <superm1> apw, but i'd also keep all your debugging to your own audio bug rather than mooching onto the t61p's audio bug.  snd-hda-intel has different code paths for different codecs
[16:06] <apw> ahh ok ...
[16:06] <superm1> but that being said, i've got a studio family laptop with the same codec as yours  that is functional sound wise, so i'd double check on a live disk to rule out configuration issues
[16:08] <apw> yeah thats a fair suggestion, will go download one now.  anything else i can poke here to get more information on the suspend jobbie?  i can't decide if the sleep.sh vbetool post hang is a herring rouge, or something worth chasing; mostly cause its easier to poke than the hard hang on restore.  as i am suspicious that the xserver is doing the same post when it wedge, just internal
[16:10] <superm1> apw, well I think it's a good idea to take NM out of the picture, switch to networking without it, and then if you can get into SSH, there's your best debug route.
[16:10] <Chipzz> I have a question: someone is asking the following: "I have an old edgy install that I want to upgrade to intrepid". What is he supposed to do? Upgrades are only supported between consequetive (LTS) releases...
[16:10] <Chipzz> and I think feisty is no longer supported?
[16:10] <apw> superm1: oh one thing... i am using an amd64 install
[16:10] <Chipzz> (at least edgy is no longer supported)
[16:11] <superm1> apw, i've we've never done testing here with amd64 at least...
[16:11] <Chipzz> mvo (not sure if you're the right person to ask...): ^^^ ? got any idea?
[16:11] <lool> Chipzz: Perhaps trying to install via http://old-releases.ubuntu.com/releases/ not sure if that's easy though
[16:11] <apw> so another thing to eliminate then
[16:12] <superm1> apw, that and windows 64 bit doesn't even ship on it, so if there are any BIOS bugs that are 64 bit specific, they will certainly show up.
[16:12] <wasabi> Chipzz: Upgrade to whatever came after edgy.
[16:12] <wasabi> Chipzz: And then onward.
[16:12] <directhex> forwards, not backwards!
[16:13] <Chipzz> wasabi: which is feisty, and I think no longer supported (ie no langer installable?)
[16:13] <wasabi> Chipzz: Though I bet an upgrade between thw two would work anyways.
[16:13] <wasabi> Is feisty still in the archives?
[16:13] <Chipzz> that's what I am wondering too
[16:13] <Chipzz> edgy isn't (according to him)
[16:13] <wasabi> Might be in the old archives. heh.
[16:14] <apw> superm1: its more odd that it got so much worse in the intrepid kernel, and just booting back to the hardy kernel improves things majorly (other than wireless not being supported of course)
[16:14] <superm1> apw, ah you went with intel wireless, yeah on hardy only the broadcom wireless is supported.
[16:15] <apw> heh yeah, and that because intel wireless is more commonly supported
[16:15] <apw> life is hard sometimes
[16:16] <superm1> apw, going forward any new Broadcom based Dell adapters will have support via wl
[16:16] <apw> and the intel is supported and good now in 2.6.27 intrepid kernels so ... i just need to sort my other bugs and i'll be laughing :-/
[16:18] <jdong> superm1: wl has really surprised me in how well it actually works
[16:18] <jdong> I'm really close to cannibalizing a computer to transplant a broadcom card into my Macbook :)
[16:19] <superm1> jdong, yeah :/  even performance wise it holds a much more reliable connection.  i can watch HD content via wifi with it on a mini9
[16:19] <jdong> superm1: oh cool the mini9 uses broadcom?
[16:19] <jdong> superm1: please stop tempting me to spend money.
[16:19] <jdong> that's gotta be against the CoC somehow
[16:21] <superm1> jdong, yeah it's a 4312 based adapter.  oh the mini 9 isn't too pricey, just get a few family members to splurge on it for you for xmas or something :)
[16:21] <jdong> :)
[16:21] <mvo> Chipzz: he can still upgrade via old-releases, but its going to be a bit of a pain because he has to do every single one until hardy
[16:22] <mvo> Chipzz: might be easier to do a "preserve-home" install of hardy, intrepid and install the mising packages afterwards
[16:22]  * mvo is out of a bit
[16:27] <dfgas1> can anyone one help with me with a suspend to disk problem, kernel panic afterwards
[17:02] <VSpike> can anyone suggest how I can get a gdb backtrace for a crash in libsmbclient when using fusesmb?
[17:04] <soren> asac: My firefox says (in about:plugins) that libnullplugin isn't enabled... How do I change that?
[17:06]  * soren has to run
[17:06] <asac> soren: it says its not enabled or it isnt there at all?
[17:16] <VSpike> If I have the info "fusesmb[16090]: segfault at 4 ip b7c03590 sp b5514dc0 error 4 in libsmbclient.so.0[b7b88000+386000]", and I have the symbol files loaded for fusesmb and libsmbclient, how can I view the line of code causing the problem?
[17:21] <sistpoty|work> VSpike: in gdb? bt would give you a backtrace
[17:21] <VSpike> sistpoty|work: I can't seem to get it to do so :/
[17:21] <VSpike> sistpoty|work: if I use it to run gdb, it just tells me that the main process exited normally straight after it starts
[17:21] <VSpike> s/gdb/fusesmb/
[17:22] <sistpoty|work> ah, so you didn't get the segfault when run inside gdb, right?
[17:22] <VSpike> sistpoty|work: I tried setting the fork follow children, and the setting to debug threads, but neither helped
[17:22] <VSpike> sistpoty|work: no
[17:23] <VSpike> sistpoty|work: the segfault doesn't happen right away - you have to load up the connection, use a few programs
[17:23] <VSpike> sistpoty|work: according to gdb, fusesmb exits right away, but it must be spawning some kind of child surely?
[17:25] <sistpoty|work> VSpike: not too sure about fusesmb
[17:25] <sistpoty|work> VSpike: you could use disas 0xb7c03590 to look at the function where it crashed
[17:25] <sistpoty|work> (there must be an easier means to do it though, but I'm by far no gdb expert)
[17:26] <VSpike> The samba in 8.10 is one behind the current stable release.  None of the fixes in the change log look very relevant though.
[17:27] <VSpike> sistpoty|work: I tried looking at the disassembly in the area but it makes little sense.  I'd like to relate it to the symbols in the dbgsym package to see which line of code it relates to, really
[17:27] <VSpike> sistpoty|work: I worked out the offset into the library from the message, and used objdump
[17:38] <sistpoty|work> VSpike: sorry, can't help you really then
[18:00] <Kano> hi, is it possible to specify a script that runs at bootup using the preseed way=
[18:25] <superm1> Kano, you can set up early and late commands to run before or after the installer, but not on general systems
[18:40]  * directhex has used it before!
[18:40]  * directhex delights in the joy of preseeds
[18:40] <directhex> especially when the syntax changes with every d-i build
[18:45] <Kano> superm1: well i would like to use it in live mode
[18:46] <Kano> basically after xconfig
[18:46] <superm1> Kano, well it will work in live mode as an early command then.  casper (which is on the live disk) processes early commands
[18:46] <Kano> but is that not too early?
[18:46] <ogra> its in initrmfs
[18:46] <ogra> +a
[18:52] <Kano> is it possible to use a late command for xserver-xorg?
[19:00] <NCommander> Out of curiosity, roughly long after the toolchain is uploaded to Jaunty will the archive open?
[19:01] <ogra> one/two weeks
[19:03] <ogra> NCommander, but usually everyone is cleaning u leftovers or stuff that piled up during release testing the first few days after release anyway
[19:03] <NCommander> ogra, I just was looking for the timeframe I have to get initial work done on the ports kernel :-)
[19:03] <directhex> at what point to i request demoting a package?
[19:04] <ogra> NCommander, well, we usually also copy over the old packages for the first run
[19:04] <ogra> so it will use the old kernels in the beginning anyway
[19:05] <NCommander> ogra, right, this I knew
[19:05] <ogra> so no hurry
[19:06] <ogra> and make sure to coordinate with the kernel team if you do any kernel work ;)
[19:06]  * directhex would like to demote mono-dbg, unless someone knows a good reason not to
[19:07] <pwnguin> directhex: im not sure mono and ubuntu-devel have a big overlap
[19:07] <directhex> pwnguin, sure they do. me!
[19:07] <directhex> pwnguin, and slomo if he's not too busy. which he usually is
[19:08] <pwnguin> directhex: ok then, the next time i find someone upset about mono or monodevelop, i'll drop your name ;)
[19:08] <ogra> pwnguin, enough overlap that we ship f-spot and tomboy by default :)
[19:08] <directhex> pwnguin, since we're planning on making mono 100% syncable, i'd be the right contact
[19:09] <directhex> pwnguin, or pkg-mono-devel@lists.debian.org anyway
[19:09] <directhex> pwnguin, oh, and if they're moaning about patents, send them to /dev/urandom for me plz
[19:12] <superm1> directhex, how is moonlight looking?  will there be a package showing up during jaunty for it, or still a bit premature?
[19:12] <directhex> superm1, you want a package? needs rebuilding against intrepid
[19:13] <superm1> directhex, well i dont have any silverlight websites i visit currently that would need it, just curiosity really :)
[19:13] <directhex> a884d84c51fbd8bff90b27e2c96c9e49  pkg-mono/moon/trunk/debian/rules
[19:14] <directhex> marillat made a package but it's garbage tbh
[19:15] <superm1> well that and i dont know how many silverlight websites need silverlight 2 vs 1 at this point, so i'm not sure how useful it will even be until moonlight w/ stable support for silverlight 2 is around
[19:15] <directhex> superm1, well observed! we're holding back on svn-buildpackage until we can build 2.0 support
[19:16] <directhex> superm1, SL2 support in any state requires mono 2.0, which will happen in about a week tops
[19:17] <superm1> directhex, ah didn't realize it needed mono 2 even.
[19:17] <directhex> superm1, i really don't want to maintain intrepid backports alongside hardy though :/
[19:18] <superm1> directhex, yeah wouldn't blame you there.
[19:18] <directhex> superm1, the hardy backports are classy though ;)
[19:19] <directhex> thoooooooooooousands of users ;)
[19:22] <directhex> superm1, now, smack people around & make them ship me my damn latitude e4300!
[19:23] <NCommander> jdong, ping
[19:23] <tedg> How does NIS work, does it just write all the users to an /etc/passwd file or is there something more complex?
[19:24] <directhex> tedg, on the SERVER, yes, it's just that
[19:24] <tedg> directhex: On the clients?
[19:24] <directhex> tedg, clients, no, it connects via the NIS protocol to get entries
[19:25] <directhex> tedg, think like a solaris developer. all the solarisy ways of doing things
[19:25] <tedg> Then does libc take care of whether you're talking to NIS or /etc/passwd with the functions to access the passwd entries?
[19:26] <directhex> tedg, that's the job of PAM and/or NSS
[19:26] <directhex> tedg, "getent passwd" gets all passwd values publically readable from services in /etc/nsswitch.conf
[19:27] <directhex> tedg, pam is for directly speaking to auth services, nss for things that pretend to be /etc/foo
[19:28] <tedg> Oh, wow.  Crazy.  I think I get it now.  Way more complex than I was hoping for :)
[19:28] <directhex> tedg, if it's in nsswitch, treat it like normal, via things in libc like getent, whether it's in ldap or nis or files or all three
[19:29] <directhex> pam is more complex
[19:29] <directhex> look for libnss-foo packages to see potential options
[19:30] <ogra> shudder, are you guys really discussing NIS ?
[19:30] <directhex> ogra, it's still popular in my like o' work!
[19:30] <directhex> line
[19:30]  * ogra thought that was dead since 10 years
[19:31] <directhex> nope. buy a cluster today, it'll ship with NIS
[19:32] <ogra> how about all the password sniffing ... ?
[19:32] <ogra> ah, well, a cluster mght have its own backbone it uses internally anyway
[19:32] <directhex> ogra, given the problem of getting security updates onto a cluster, it's the leats of your worries
[19:32] <ogra> yeah
[19:32] <directhex> ogasawara, personally i have my own ldaps:// auth server
[19:32] <directhex> (s)
[19:33] <ogra> lean will be happy to hear that :)
[19:33] <ogra> *leann even
[19:33] <directhex> who?
[19:33] <ogasawara> ogra: hehe, thanks for sharing :)
[19:33] <ogra> heh
[19:34] <directhex> deployed on debian. dapper was a catastrophic failure
[19:38] <NCommander> directhex, do you have a hardy box?
[19:39] <pwnguin> so i guess this channel topic needs to change
[19:39] <pwnguin> there is no ubuntu+1
[19:39] <Treenaks> yet
[19:40] <ogra> pwnguin, feel free
[19:40] <djhash> hey.. quick question (not support question).. while looking at my dmesg (8.10).. i noticed something.. [   14.090990] em28xx #0: The support for this board weren't valid yet. Please send a report of having this working not to V4L mailing list (and/or to other addresses).. i'd like to be helpful and i hope this is something someone wants to see.. but i'm not sure who to send to and what is it that I need to send..
[19:41] <ogra> probably to what it say .,...
[19:41] <ogra> "V4L mailing list"
[19:41] <djhash> I have a fairly good idea on which of my hw that is talking about.. Plextor PX-TV1000U
[19:41] <ogra> doesnt sound like #ubuntu-devel :)
[19:41] <djhash> it said NOT to V4L mailing list.. or is that typo?!!
[19:42] <ogra> ogra@osiris:~/Devel$ modinfo em28xx|grep description
[19:42] <ogra> description:    Empia em28xx based USB video device driver
[19:43] <ogra> ogra@osiris:~/Devel$ modinfo em28xx|grep author
[19:43] <ogra> author:         Ludovico Cavedon <cavedon@sssup.it>, Markus Rechberger <mrechberger@gmail.com>, Mauro Carvalho Chehab <mchehab@infradead.org>, Sascha Sommer <saschasommer@freenet.de>
[19:43] <ogra> pwnguin, while your at it, i think the evil bug thing can go as well
[19:43] <pwnguin> wonder what bug #286175 is
[19:44] <pwnguin> priority high and confirmed =/
[19:44] <djhash> ogra: so one of those emails?
[19:44] <ogra> djhash, well, find out where that driver is developed or just file a bug in launchpad and let the devs sort it
[19:45] <djhash> ogra: ok.. thanks..
[19:48] <jcole> hi guys (and gals), i've remastered an iso (installed packages, modified /etc/skel, modified the default gconf db, system wide files, etc.)
[19:49] <jcole> it seems all is well for the live session user except the gconf settings
[19:49] <jcole> adding a new user and switching to the new user seems to work but the live session user does not have the gconf settings... does the live session user get it's gconf from a special place?
[19:50]  * jt66 is away: I'm busy
[19:50] <NCommander> jcole, check the casper package, it generates the ubuntu user and the default config ont he liveCD
[19:53] <jcole> NCommander: ok
[19:57] <ogra> did you run update-gconf-defaults after changing the system keys ?
[19:57] <ogra> (assumng you properly added a gconf file to /usr/share/gconf/defaults/ )
[19:58] <ogra> jcole, ^^^
[19:58] <jcole> ogra: ah, that may be my problem
[19:59] <ogra> make sure your file has a higher number so it will override the existing ones
[19:59] <jcole> ogra: you are too cool, that was my problem
[19:59] <ogra> :)
[19:59] <jcole> ogra: thank you :)
[20:00] <ogra> welcome :)
[20:22] <Keybuk> pitti: around?
[20:25] <Keybuk> cjwatson: ?
[20:27] <Keybuk> maybe this is a silly bug
[20:27] <Keybuk> but the apt cache isn't valid on new intrepid installs
[20:27] <Keybuk> which means jockey doesn't work :p
[20:29] <pwnguin> apt-cache
[20:29] <pwnguin> arg
[20:29] <superm1> Keybuk, I think you need to have a network cable plugged in while you do install to get a valid apt cache
[20:30] <Chipzz> superm1: I think that's an incorrect assertion, since I saw some bug floating by here a few days ago about the need to have an uncompressed Packages file on the live CD
[20:33] <pwnguin> so a simple apt-get update is a workaround, no?
[23:27] <cjwatson> Keybuk: it depends, unfortunately, on whether you had network access during the install
[23:27] <cjwatson> Keybuk: I think the best way to fix this is to copy the Packages files across from the livefs; it's pretty fiddly though as the mirror will in the general case be different from the livefs (which uses archive.ubuntu.com) and so you end up having to predict /var/lib/apt/lists filenames
[23:27] <cjwatson> but, anyway, yes it is a bug
[23:28] <cjwatson> ogra: actually I'm hoping to open jaunty for general development no later than about Monday
[23:32] <wgrant> cjwatson: Isn't that about the earliest ever?
[23:34] <cjwatson> wgrant: I haven't kept notes :) We usually do manage it within about a week, but yes I think this should be pretty quick
[23:34] <cjwatson> wgrant: it helps that the toolchain changes this time aren't quite so huge
[23:34] <wgrant> I guess that would help, yes.
[23:35] <cjwatson> TBH, we're very nearly done now
[23:36] <wgrant> I saw gcc-4.3 in NEW last night, and binutils came through this morning... is that it?
[23:37] <cjwatson> glibc still to come, I'm just eyeballing the interdiff
[23:37] <wgrant> Aha.
[23:38] <cjwatson> but I understand that's it
[23:41] <sistpoty> cjwatson: is that an announcement? *g*
[23:41] <cjwatson> sistpoty: not quite yet :-)
[23:41] <sistpoty> ok :)
[23:41] <cjwatson> sistpoty: one of the steps on the new-release-cycle process is "Inform #ubuntu-devel and ubuntu-devel-announce that the new release is now open for uploads, pointing to merge-o-matic output"
[23:42] <cjwatson> so it will not be forgotten :-)
[23:42] <sistpoty> heh
[23:42] <cjwatson> folks should also be glad to hear that I've already given authoritative go-ahead to LP to open jaunty translations
[23:42] <wgrant> cjwatson: Excellent!
[23:43] <wgrant> And hopefully people will notice earlier this time if something goes wrong.
[23:55] <sistpoty> cjwatson: alright if I send http://pastebin.ubuntu.com/65447/ to ubuntu-motu?
[23:56] <cjwatson> sistpoty: sure
[23:57] <sistpoty> thanks cjwatson :)
[23:58] <wgrant> cjwatson: It looks like dists/jaunty isn't being rsynced to a.u.c... is that intentional?
[23:59] <cjwatson> wgrant: no - it could just be load problems though, I don't think there's any release selectivity there
[23:59] <cjwatson> elmo: confirm?