[00:00] <soren> Yeah, wow, that's four years ago.
[00:01] <soren> Time flies.
[00:01]  * soren gets all misty eyed thinking about Breezy.
[00:01] <ajmitch> and that was a modern release
[00:01] <debfx> bryce: what do you think about including virtualbox in xserver-xorg-*-all packages (bug #348497)?
[00:01] <soren> ajmitch: Weren't they all? :)
[00:02] <ajmitch> soren: back in the day, when we were young :)
[00:12] <cjwatson> billybigrigger: were you looking for me? there's more than one developer named Colin in Ubuntu
[00:14] <bryce> debfx: will reply on the bug
[00:18] <debfx> ok, thanks
[00:19] <ebroder> Any main uploaders around who could look at bug #362691?
[00:21] <TheMuso> wwwwwwwwwwwwww/c
[00:21] <TheMuso> gah
[00:52] <shtylman> is inkscape crashing for anyone else?
[01:05] <johanbr> shtylman: yep
[01:05] <johanbr> my libraries aren't completely updated, though, so that might be the cause
[01:06] <shtylman> johanbr: I just got the latest pre-release inkscape from their ppa and it works :)
[01:06] <johanbr> alright
[01:06] <johanbr> well, considering that one of their main developers works too Canonical, I'm pretty sure it'll be fixed soon :)
[01:07] <johanbr> *works for
[01:07] <shtylman> indeed :)
[01:09] <shtylman> new inkscape is nice...glad to see they fixed the export to relative location stuff
[01:12] <johanbr> I had trouble with gradients when exporting to SVG... do you know if that's been fixed?
[01:55] <micahg> is this the channel to talk about papercuts?
[02:17] <ScottK> micahg: #ayatana
[02:30] <micahg> thanks ScottK
[02:36] <LucidFox> Riddell, why is arora being promoted to main? Is it going to be the new default browser in Kubuntu?
[03:29] <ScottK> LucidFox: It's likely.
[03:29] <LucidFox> Sweet.
[04:30] <lifeless> anyone else having their laptop randomly power off under karmic?
[04:30] <lifeless> nothing in messages/syslog/etc indicating why
[04:33] <Hobbsee> lifeless: power off, or graphics die and machine doesn't recove?
[04:33] <lifeless> Hobbsee: power off
[04:34] <lifeless> occassional black screen for 1 second with no side effects
[04:34] <Hobbsee> i get the latter, but i've not seen the former
[04:34] <lifeless> I've seen the former twice now
[04:34] <Hobbsee> it wouldn't suprise me
[04:42] <AnAnt> LP 388515
[04:50] <lifeless> where would be appropriate for a bug on this
[05:29] <lamont> I just wish I knew who decided that armel needed to be off MANUAL before it was ready to be off MANUAL
[05:30]  * lamont -> bed
[06:32] <dholbach> good morning
[06:44] <pitti> Good morning
[06:44] <dholbach> hiya pitti
[07:03] <superm1> hi pitti
[07:15] <micahg> are there any plans to allow an underscore in username?
[07:33] <StevenK> pitti: Can haz MIR? :-)
[07:34] <pitti> lool, asac, infinity: ^ got some time for MIR?
[07:34] <pitti> StevenK: I didn't actually get a UNRish request, though
[07:34] <StevenK> pitti: I was talking about celt :-)
[07:35] <micahg> \are there any plans to allow an underscore in username?
[07:36] <pitti> uid=1003(test_user) gid=1003(test_user) Gruppen=1003(test_user)
[07:36] <micahg> sorry
[07:36] <pitti> micahg: that should have worked forever already?
[07:36] <micahg> in the installer
[07:36] <micahg> had a friend install xubunut today
[07:36] <pitti> micahg: can you please file a bug report for this?
[07:36] <micahg> and couldn't use his username with an underscore
[07:36] <micahg> ok
[07:36] <micahg> sure
[07:36] <micahg> wanted to know if it was a known issue or not
[07:36] <slangasek> pitti: except for the part where debian regressed and I had to re-fix it
[07:36] <micahg> what package is the installer?
[07:37] <slangasek> pitti: bug #341698
[07:41] <micahg> pitti: can you tell me which package the Ubuntu Installer is in so I can file the bug?
[07:41] <pitti> micahg: ubiquity
[07:41] <micahg> ok
[07:42] <micahg> what's the official purpose of this channel?
[07:43] <lifeless> micahg: /topic
[07:43] <micahg> yes
[07:43] <micahg> ok
[07:43] <micahg> so generic Ubuntu devel
[07:44] <micahg> so this was the right channel to ask my question
[07:44] <lifeless> yes
[07:44] <micahg> thanks for your help
[07:45] <slangasek> micahg: which release of Ubuntu were you using for the installation?
[07:45] <micahg> Xubuntu jaunty
[07:45] <micahg> LiveCD
[07:45] <slangasek> ok
[07:45] <slangasek> then I guess there's a separate bug in ubiquity, indeed
[07:45] <micahg> I found an open bug in one of the gnome tools package
[07:46] <micahg> but that seemed gnome specific
[08:02] <slangasek> pitti: btw, I did get the explanation from mjg59 about what the last bit of hotkey-setup was for; I'll get that documented and into one of the specs before killing hotkey-setup from the archive
[08:02] <pitti> \o/
[08:03] <pitti> slangasek: so it's confirmed obsolete now?
[08:03] <slangasek> also, update-manager seems unwilling to remove hotkey-setup from my system, here - have you seen that?
[08:03] <slangasek> pitti: the DOS stuff isn't obsolete, but it should certainly be moved somewhere else, such as the kernel
[08:09] <pitti> slangasek: haven't heard about it, no?
[08:09] <mattn_> hi
[08:09] <pitti> slangasek: perhaps udev-extras should also Replaces: hotkey-setup then?
[08:09] <mattn_> i'm trying to set up an modified live-cd at our company
[08:09] <mattn_> it works already great
[08:09] <pitti> slangasek: btw, udev-extras was merged into udev yesterday, so we need to move the Conflicts anyway
[08:09] <mattn_> but now i'm trying to add a casper script to modify some gconf settings and desktop stuff
[08:10] <MacSlow> Greetings everybody!
[08:10] <mattn_> adding a new script to /usr/share/initramfs-tools to the casper-bottom folder doesn't help
[08:10] <mattn_> seems the new script is not executed at all
[08:10] <mattn_> is there any documentation available on how to customize casper?
[08:11] <mattn_> even update-initramfs -u isn't helping
[08:11] <mattn_> every hint is welcome ;)
[08:12] <slangasek> pitti: heh, perhaps that will make a difference in update-manager's willingness to remove it
[08:12] <slangasek> pitti: I wouldn't think a Replaces is needed; maybe it's actually one of the other packages that u-m is declining to upgrade that's really to blame
[08:12] <slangasek> gnome-bluetooth or audacious, I guess
[08:15] <slangasek> let's tentatively blame audacious
[08:19] <ebroder> pitti: could you take a look at bug #362691 (specifically comment 37)? There's one more patch needed to make future upgrades work
[08:19] <ebroder> Err, sorry, comment 38
[08:23] <lool> StevenK: What is celt for?
[08:23] <lool> I mean in main
[08:23] <StevenK> lool: It's a new Built-Depends of opal, which is already in main
[08:23] <StevenK> *Build-Depends
[08:23] <lool> Aha
[08:24] <StevenK> Which is in the MIR ... :-)
[08:26] <pitti> ebroder: hm, it seems strange to change init script installation in a SRU
[08:26] <lool> StevenK: Weird, I see the bdep in place already, but no opal package dep-ing on celt or libvelt
[08:26] <StevenK> lool: It can't build!
[08:26] <StevenK> It's in DEPWAIT
[08:26] <lool> Hmm I need a cup of coffee
[08:26] <ebroder> pitti: I haven't been able to figure out any other way to get the unpacking/prerm/postinst/etc order to work out
[08:26] <StevenK> lool: Or two ...
[08:28] <ebroder> pitti: My best guess is that something weird is happening with the various provides/conflicts/replaces
[08:29] <pitti> ebroder: during upgrade, python modules won't work, that's a known fact
[08:29] <pitti> ebroder: what does -R do?
[08:30] <ebroder> pitti: Instead of stopping in the prerm and starting in the postinst, it does a restart in the postinst
[08:30] <pitti> oh, right, it's not an option to xend
[08:31] <ebroder> pitti: As far as I can tell, the prerm for a package shouldn't be running before the prerm for packages that depend on it. That's the weird bit
[08:31] <ebroder> But that's what was happening
[08:31] <pitti> ebroder: that's a bit dangerous, though; while the upgrade is running, xend can't use any python modules or other stuff
[08:31] <ebroder> Sure it can - it just might have trouble importing new modules
[08:32] <ebroder> But I don't think it does imports mid-execution under normal circumstances
[08:32] <pitti> right, that's what I mean
[08:32] <pitti> okay, just wanted to point it out
[08:33] <ebroder> I guess it might be an issue if you try to...use xm to manipulate domains or config while the upgrade is running?
[08:35] <superm1> pitti, lirc now depends on libfti-dev for the latest version which is living in universe, should I file a MIR on libfti, or will it show up on component mismatches or something like that and get taken care of via other regular archive admin work?
[08:35] <StevenK> superm1: An MIR needs to be filed.
[08:35] <superm1> okay thanks StevenK
[08:38] <pitti> ebroder: uploaded
[08:39] <ebroder> pitti: Great! Thanks. I'll try to test it some time in the next week or so
[08:39] <pitti> ebroder: this needs fixing in karmic as well, apparently
[08:39] <ebroder> Yeah, there's a patch on the ticket, but I've had a horrible time finding a sponsor
[08:40] <pitti> tkamppeter: ah, you didn't upload cups to jaunty-proposed yet?
[08:41] <mattn_> nobody can help me with my casper questions? is this the wrong location to ask questions about caspar? if yes, can somebody please point me to a proper location or channel?
[08:50] <tkamppeter> pitti, I have sent you the debdiff because I thought you want to pass it through your BZR repo.
[08:50] <pitti> tkamppeter: right, and I just remembered to bump the poppler-utils dependency
[08:59] <lool> StevenK: I'm quite scared with the bitstream situation if it's going to be used in ekiga; the maintenance part and the other small issues call for further input too
[09:00] <StevenK> lool: Bitstream situation?
[09:01] <StevenK> lool: I'm not sure if Ekiga will pull it in
[09:01] <lool> StevenK: The bitstream isn't frozen claims the README
[09:02] <StevenK> lool: That's a problem?
[09:03] <lool> See my comments in the MIR
[09:04] <seb128> slangasek, are you sure that the gvfs change for hardy was not working correctly?
[09:05] <lool> StevenK: celt seems optional in opal; if it's not used in ekiga, what's the point of pulling it in main?
[09:05] <seb128> slangasek, it's the same that has been used for intrepid and jaunty and seems to work for quite some users
[09:05] <StevenK> lool: Well, I can merge opal to drop celt
[09:05] <slangasek> seb128: the bug report has follow-ups saying that it introduced regressions; it's possible that this fix was insufficient, that it depends on other changes?
[09:06] <seb128> slangasek, I think it's hard to track properly those bugs because there is so many users having different issues commenting on wrong bugs
[09:06] <seb128> it's not clear to me that the update actually broke anything
[09:06] <slangasek> this was a user commenting specifically on regressions after installing the new packages in hardy-proposed.
[09:06] <seb128> *shrug*
[09:07] <asac> pitti: i have StevenK's and 3 other on my list for today (MIR)
[09:08] <StevenK> asac: lool has already looked at it
[09:08] <lool> StevenK: I think ekiga is the only user of opal in main and it's not on the CDs AFAIK (only DVD), so I wouldn't mind pulling it to avoid a delta with Debian modulo the other questions (and if it's not exposed in the list of codecs used by ekiga as long as the bitstream isn't frozen)
[09:08] <asac> StevenK: yeah saw that now.
[09:08] <lool> asac: I picked celt
[09:08] <seb128> slangasek, ok fair enough, I guess we will just not get that change in hardy now, people will have to wait for the next lts
[09:09] <asac> lool: fine. i actually started yesterday on it. i think i should have assigned explicitly to me.
[09:09] <StevenK> lool: So we can move celt to main to avoid a delta?
[09:10] <lool> StevenK: That's a good rationale, but the other questions stand
[09:11] <lool> I would have objected if we have had other Ubuntu changes in opal or if ekiga had been on the CD
[09:41] <juanje> hi guys, anyone knows how to debug acpi stuff? when a laptop doesn't suspend and stuff like that
[09:42] <lifeless> there is a wiki page for debugging power support
[09:42] <juanje> ummm
[09:42] <juanje> lifeless: thanks :-) do you know the url or so?
[09:42] <lifeless> no
[09:42] <juanje> lifeless: oki, don't worry, I'll find it
[09:42] <juanje> thanks
[09:54] <lool> pitti: Hmm ISTR you asked about a new poppler for cups, but this was for Debian alone, we have the one you need in Ubuntu right?
[09:56] <seb128> lool, yes
[09:56] <seb128> lool, we have poppler 0.11
[09:57] <lool> Yes, but I think pitti asked about it last week or so and we have 0.11 in Ubuntu for longer than that
[09:58] <seb128> lool, but cups requires this version now apparently
[09:58] <seb128> I'm not sure what your question is now ;-)
[10:00] <lool> seb128: I'm asking pitti to confirm whether it's only in Debian that he was asking for the update   :-)
[10:00] <seb128> yes
[10:00] <seb128> since ubuntu already has 0.11 which is current
[10:01] <seb128> not sure if you want to track the unstable version in debian though
[10:01] <seb128> they changed the soname
[10:01] <seb128> and the api might still change
[10:02] <lool> Ok I find it unlikely that I find much time for it then; I don't have a lot of Debian time, even less for poppler, in particular when it's a development series
[10:08] <pitti> re
[10:10] <pitti> lool: yes, I asked about Debian; there's a pending patch (-origpagesizes) that I need for cups, and it would be nice to upgrade to newer version so that we can add a new pdf filter to cups
[10:10] <pitti> lool: but I was told that Debian usually doesn't update to the odd-numbered devel releases
[10:11] <lool> It depends whether there's interest and manpower as usual
[10:11] <seb128> stable version is schedule for in some weeks
[10:11] <seb128> so you might as well wait for it if there is no hurry
[10:13] <tseliot> pitti: does this log look good to you (note: I don't have the hardware here but the modaliases and the modules are already in place)? http://pastebin.ubuntu.com/198356/
[10:13] <tseliot> pitti: the modalias file is bcmwl
[10:16] <pitti> tseliot: if you create a fake modalias for any other piece of hw, do you get it offered, and does it install okay?
[10:22] <tseliot> pitti: no, it doesn't show up, even with a fake alias: http://pastebin.ubuntu.com/198365/
[10:22] <pitti> tseliot: can you please show me the modalias file? does it have the correct package name?
[10:23] <pitti> BroadcomWLHandler enabled(): kmod disabled, bcm43xx: blacklisted, b43: blacklisted, b43legacy: enabled
[10:23] <tseliot> pitti: sorry, I've just tried again and there was a typo in the modalias. It works now
[10:23] <pitti> tseliot: perhaps the issues is that the b43 blacklist is incomplete and misses b43legacy?
[10:23]  * tseliot blames it on vim
[10:24] <tseliot> let me try to remove it now
[10:26] <tseliot> pitti: ok, the package was removed correctly. Shall I add a better description to the handler (if one is provided)?
[10:28] <tkamppeter> pitti, the CUPS SRU package hangs in "Waiting for approval" for some hours now. Is it not you who approves it?
[10:29] <pitti> tkamppeter: I had to run for the dentist, I returned to SRU work now
[10:30] <pitti> tseliot: if you can think about one; otherwise just leave like it is now
[10:37] <tseliot> pitti: my package already contains a file with the modules to blacklist (we need it for our customised OEM images) so we may end up blacklisting the same module twice. Would this be a big problem (I know it's ugly)?
[10:37] <pitti> tseliot: shouldn't be a problem, just that jockey can't unblacklist it then
[10:38] <tseliot> pitti: right but when you remove the package the blacklist goes away
[10:38] <pitti> tseliot: ah, you mean the bcm package itself ships the blacklist?
[10:38] <tseliot> yep
[10:39] <pitti> tseliot: nice, that's even better than doing it in the jockey handler
[10:39] <pitti> tseliot: we couldn't do that with l-r-m obviously
[10:39] <pitti> tseliot: so we could just rip out the jockey handler blacklisting code now, since the package itself will DTRT
[10:39]  * pitti favors solutions which also work with apt-get install
[10:39] <tseliot> pitti: ah, right it was in the lrm before. Sure it's a good idea
[10:55] <tseliot> pitti: do you know if the trick to load wl before b44 is still required? http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/annotate/head%3A/data/handlers/broadcom_wl.py
[10:55] <pitti> tseliot: I think so, unless wl was changed to use the ssb module now?
[10:56] <tseliot> pitti: I'm asking because I only blacklist b43 and ssb but maybe something more should be done
[10:57]  * tseliot is unsure as to how to solve this problem in the blacklist file
[10:58] <pitti> tseliot: the legacy ones need blacklisting as well then, I think
[10:58] <pitti> tseliot: well, let's just keep the current code as it is then, and test it properly
[10:59] <tseliot> pitti: jockey's blacklist file is blacklist-bcm43.conf while I could use a different name
[11:05] <tseliot> pitti: this way I think we should cover all cases
[11:05] <tseliot> s/should/would/
[11:05] <pitti> tseliot: is wl's a conffile? if so, then mere removal of the package won't remove it
[11:06] <pitti> if it's created/removed in postinst/prem, that's fine
[11:07] <tseliot> pitti: it's listed in the .install file of the package, therefore it's removed when the package is removed
[11:07]  * tseliot is using CDBS
[11:12] <joaopinto> does anyonw know about NILFS stability ? It would be great to have such an improved file system recoverability
[11:39] <super__rad> could someone upgrade empathy (and related telepathy packages) to newest versions as it's empathy hug day today and the newest versions contain a lot of bug fixes
[12:05] <hyperair> hmm is anyone noticing that the getty processes disappear after logging out?
[12:06] <hyperair> and that /etc/inittab is now missing O_o
[12:06] <hyperair> no wait, it was always missing
[12:18] <hyperair> hmmm the tty[1-6] services weren't running
[12:25] <ogra> asac, hmm, FF 3.5 seems to ignore the shift key if i hit shift-ctrl-reload
[12:37] <asac> ogra: please check latest firefox-3.5 and xulrunner-1.9.1 daily from ~ubuntu-mozilla-daily
[12:37] <ogra> will do
[12:38] <asac> ogra: i go to https://launchpad.net/ and type something in the search field. then hit ctrl+R -> text i typed is still there. then i hit shift+ctrl+R -> text is gone. so it seems to work somehow
[12:39] <ogra> well, my prob is that it opens in a new tab instead of reloading (sorry, should have said that in the first sentence :) )
[12:40] <asac> ogra: so you hit the reload toolbar button with ctrl+shift? thats a feature. its just shift
[12:41] <ogra> oh, so the "clear cache" function if you hold ctrl+shift while hitting reload is gone ? or does it immediately work with shift only now ?
[12:42] <liw> I thought it had been shift-reload since netscape 1
[12:42] <asac> ogra: yeah. you probably think its ctrl because you usually type ctrl+shift+R on the keyboard
[12:42] <ogra> that didnt clear out pictures, ctrl+shift+reload did
[12:42] <asac> but if you click on the button it was always just shift
[12:43] <ogra> it used to remove all pic of the site from the cache
[12:43] <ogra> and load them newly ...
[12:43] <ogra> anyway, i'm just irritated because it opens a new tab now
[12:45] <asac> ogra: i checked in ffox 3.0 and ctrl+shift vs. shift is not different
[12:45] <ogra> ok
[12:45] <asac> at least not according to sniffed http headers
[13:03] <DktrKranz> Riddell: I've been asked why we bumped sip b-d in python-qt4, so it could have it in sync again. Could you shed a light on that?
[13:03] <vorian> it wont build otherwise, iirc
[13:05] <Riddell> DktrKranz: I had errors  building sip/pyqt/pykde with anything  other than the latest
[13:05] <Riddell> and we  can't be in sync, Debian has  an older  version
[13:05] <DktrKranz> I see, thanks.
[13:15] <geser> @archive-admins: maven-plugin-tools build-depends on a package build by itself, would a deb build from the Debian deb (as done with cup in the past) pass NEW? this would be undone asap
[13:18] <pitti> geser: I wouldn't know how to upload this; I think this might need a manual build
[13:19] <geser> pitti: I'd do it similar to http://launchpadlibrarian.net/25782720/cup_0.11a%2B20060608-1_0.11a%2B20060608-1build1.diff.gz
[13:21] <pitti> geser: ah, I see
[13:21] <geser> the question is: would such a package pass NEW?
[13:21] <pitti> geser: if the included binaries get reverted, it will probabl
[13:21] <pitti> y
[13:22] <pitti> it's obviously a bootstrap issue, so it should be fine
[13:25] <ogra> pitti, are you still hunting the memleak =
[13:25] <ogra> ?
[13:25] <pitti> ogra: me? what memleak?
[13:26] <ogra> dunno, you asked about xrestop some days ago
[13:26] <pitti> aah
[13:26] <pitti> I don't get that, but seb128/mdz do, I think
[13:26]  * pitti has a 945
[13:26] <ogra> i just stumbled over that:
[13:26] <ogra>  4717 ogra      20   0 3071m  44m 4152 S    1  1.5  20:12.36 compiz.real
[13:26] <pitti> it only seems to happen on 965 as it seems
[13:26] <ogra> 3G virtual ram ...
[13:26] <pitti> wow
[13:26] <ogra> after 24h
[13:27] <seb128> videocard?
[13:27] <ogra> 965
[13:28] <soren> pitti: You don't see it on your laptop?
[13:28] <pitti> apparently not
[13:28] <pitti> I boot it every day, though
[13:28] <soren> pitti: Mine's identical (apart from the wifi), and I see it.
[13:28] <pitti> but so does seb128, and he notices
[13:28] <soren> pitti: Oh, right, that would explain it.
[13:29] <ogra> mine runs all the time
[13:29] <ogra> and i see swap being eaten after about 12h
[13:29] <pitti> suspend is broken with xorg-edgers as well as karmic, so I have to
[13:29] <soren> pitti: It happens to me after ~30 hours.
[13:29] <seb128> pitti: no, I tend to suspend my laptop at the moment
[13:30] <ogra> the swap usage raises constantly then ... untill all swap is used ...
[13:30] <seb128> not sure for how long it was not rebooted the other day but my 2Go of ram and all swap was used
[13:30] <ogra> the intresting part is that it then doesnt move over to RAM or something to raise further
[13:30] <pitti> ogra: so if you just do "compiz --replace", does that help?
[13:30] <pitti> ogra: that wouldn't happen if it's just a memleak
[13:31] <pitti> swap->ram happens on demand, not "just because it can"
[13:31] <pitti> so, if it's dead allocated memory, it should stay in swap
[13:32] <ogra>  3047 ogra      20   0  111m  24m 7688 S    4  0.8   0:01.84 compiz.real
[13:32] <ogra> after compiz --replace
[13:32] <ogra> though the swap isnt freed ...
[13:32] <ogra> its using 3.5G
[13:32] <Hobbsee> oh, is that why i end up having a whole bunch fo swap in use?
[13:33] <seb128> Hobbsee: video card?
[13:33] <ogra> swapoff failed: Cannot allocate memory ... and it seems to be used still ...
[13:33] <Hobbsee> seb128: 945GM
[13:34] <pitti> hm, seems I just didn't notice then
[13:34] <seb128> pitti: if you reboot daily it might not be enough to notice
[13:34] <ogra> yeah
[13:35] <Hobbsee> 968mb virtual ram by compiz, anothe 508 to xorg, anothe 511 to firefox...no wonder my system's going into swap
[13:35] <pitti> I have 0 used swap ATM
[13:35] <seb128> pitti: how much is compiz using for you?
[13:35] <pitti> martin    4610  0.5  2.0 388624 41880 ?        S    11:07   1:14 /usr/bin/compiz.real --ignore-desktop-hints --replace --sm-client-id 107cc6fd5a54f6c25f124531603772994800000044390021 core ccp
[13:35] <pitti> seb128: what's the magic number, 388624?
[13:35] <ogra> heh, nothing ...
[13:36] <pitti> 388624 VSZ
[13:36] <ogra> yeah, thats nothing
[13:36] <seb128> pitti: yeah, watch how this one is moving, ie in one hour
[13:36] <pitti> well, 388 MB != "nothing"
[13:36] <pitti> but I understand it's counting all the shlibs, etc.
[13:36] <ogra> compared to 3G it is ;)
[13:37] <pitti> a few minutes ago it was 385072
[13:37] <pitti> so it's growing
[13:37] <ogra> funnily mine isnt after the --replace
[13:37] <ogra> it jumped from 111M to 134 after the start and seems to stay there
[13:37] <seb128> could be when switching workspace or something
[13:38] <seb128> where you stay on front of IRC now ;-)
[13:38] <ogra> i only have two workspaces and never switch
[13:38] <seb128> ok, so that's not it
[13:38] <pitti> I switched ws, changed window focus, that didn't do it
[13:38] <pitti> simply waiting did
[13:38] <ogra> oops, mine jumped to 136 ...
[13:39] <seb128> just did 495 to 507 in on minute there
[13:39] <seb128> 508
[13:39] <ogra> just alt-tab'bing between a htop terminal and xchat
[13:39] <pitti> I never ever use alt-tab, so that's not it either
[13:39] <ogra> well, i meant all i do is switching windows ...
[13:39] <seb128> pitti: I guess you have the issue too then, one day is just enough to eat your ram and swap apparently
[13:40] <pitti> seb128: *nod*
[13:40] <seb128> +not
[13:40] <seb128> still we are lucky, mdz get gpu hangs while he's working
[13:40] <ogra> everyone running KMS here ?
[13:40] <pitti> o/
[13:41] <seb128> do I have to do something to get kms used?
[13:41] <pitti> although recently gdm doesn't use it any more
[13:41] <pitti> that worked fine some weeks ago
[13:41] <ogra> seb128, yeah, enable it in modprobe.d iirc
[13:41] <pitti> gnome session itself does, though
[13:41] <seb128> ok so I don't
[13:41] <pitti> $ cat /etc/modprobe.d/i915-kms.conf
[13:41] <pitti> options i915 modeset=1
[13:41] <seb128> I didn't touch anything, I'm on jaunty upgraded
[13:41] <ogra> right
[13:41] <pitti> seb128: does it work OOTB on your ATI box?
[13:41] <ogra> so its not kms related
[13:41] <pitti> seb128: recent karmic kernel was supposed to auto-enable it on radeon
[13:41] <seb128> pitti: dunno, how do I notice if it's used?
[13:41] <pitti> ogra: very unlikely, too
[13:42] <pitti> seb128: ctrl+alt+f1
[13:42] <pitti> seb128: get a huge nice VT and no flicker?
[13:42] <seb128> I will try later my desktop is not booted right now
[13:42] <seb128> but I don't think it's used
[13:42] <pitti> should switch in an instant
[13:42] <seb128> I switched recently and I still had the standard textmode
[13:42] <seb128> but I've a r6xx
[13:42] <seb128> no compiz working on this box etc
[13:42] <seb128> so I would not be surprised if kms was not working
[13:43] <pitti> ah, perhaps KMS is just for <= r5xx
[13:43] <ogra> hmm, after vt switch i notice xchat drops a shadow on my panel
[13:43] <ogra> in fact all windows do
[13:44] <ogra> and clicking the panel makes it go away
[13:44] <ogra> and now i cant reproduce :(
[13:45] <pitti> lool: shall we just try and ditch https://merges.ubuntu.com/libi/libipc-sharelite-perl/libipc-sharelite-perl_0.13-1ubuntu1.patch and sync it? 0.17 might have fixed the test failure
[13:45] <ogra> pitti, we can reintroduce the patch, sync it first
[13:45] <pitti> that was my thought
[13:48] <pitti> NCommander: can you please forward patches like bug 300000 to Debian? it's a nuisance having to carry and merge them
[13:49] <pitti> NCommander: (either way, still your merge)
[13:50] <NCommander> pitti, the fix is Ubuntu specific, and I talked to the maintainer about it. (its an issue with the restrictiveness of our build environment)
[13:50] <pitti> NCommander: wouldn't it work on Debian, too?
[13:51] <mib_o6egw3k8> Help bring Google Gears to Opera, star this issue http://code.google.com/p/gears/issues/detail?id=15&q=opera&colspec=Version%20Milestone%20Owner%20ID%20Summary%20Component
[13:51] <pitti> mib_o6egw3k8: this channel is not an adboard
[13:51] <NCommander> pitti, I had the conversation a few months ago, but I think the maintainer didn't want to merge an ubuntu specific changeset. That being said, I'll ping him again on it
[13:52] <pitti> NCommander: I'm curious, what's the difference on our buildds?
[13:52] <mib_o6egw3k8> Sorry pitti
[13:52] <NCommander> pitti, something prevents xvfb from properly initializing
[13:52] <mib_o6egw3k8> I just realised I clicked on the WRONG irc
[13:52] <NCommander> pitti, *is digging into his memory*
[13:52] <mib_o6egw3k8> My bad
[13:53] <pitti> NCommander: that sounds more like a bug, or it works on debian's buildds for sheer luck?
[13:53] <pitti> NCommander: anyway, thanks for having pinged him
[13:53] <NCommander> pitti, its too far back for me to remember. It works on Debian, but not on Ubuntu.
[13:53] <NCommander> pitti, funny, I thought I put a sync request in, the delta wasn't needed anymore
[13:54] <NCommander> let me reconfirm that
[13:54] <pitti> NCommander: for libgtk2-perl?
[13:54] <pitti> I just checked the diff, the xvfb call is basically unchanged
[13:54] <pitti> but perhaps that underlying bug was fixed
[13:54] <seb128> xvfb got some changes though
[13:54] <seb128> what was the build error?
[13:54] <NCommander> pitti, the maintainer axed the test suite run
[13:54] <NCommander> pitti, due to bugs on most port architectures
[13:54] <pitti> (hmm)
[13:55] <pitti> NCommander: no pending sync request
[13:55] <seb128> I would say "try to sync and see how it works and fix if required"
[13:55] <seb128> easy enough ;-)
[13:55] <NCommander> seb128, I'm about to punt it into my PPA
[13:55] <NCommander> to see if we need to merge anything
[13:59] <lool> pitti: I think you asked about taking a new libipc-sharelite-perl upstream version some time ago already, and NCommander tested it and it didn't help
[13:59] <NCommander> lool, the issue however only persists on our build hardware :-/
[14:00] <lool> I'm pretty sure it's a kernel issue, for which we need a test case   :-(
[14:01] <NCommander> lool, which after two weeks I still couldn't produce :-/
[14:10] <dholbach> pitti: thanks for sponsoring python-crypto
[14:11] <pitti> n/p
[14:11] <dholbach> al-maisan: there's the "what-patch" command you can run in a source tree to figure out which patch system a package uses :-)
[14:11] <dholbach> (in ubuntu-dev-tools)
[14:12] <cjwatson> mvo: how do you think that foundations-karmic-repository-management and foundations-karmic-golden-iso-image interact?
[14:12] <al-maisan> dholbach: ah, another great tip :) thanks!
[14:12] <mvo> cjwatson: I have not read the iso-image one yet, let me do that now
[14:13] <dholbach> anytime :)
[14:16] <mvo> cjwatson: there is a quite a bit of overlap, especially in the mirror part
[14:16] <cjwatson> that's what I was thinking
[14:16] <cjwatson> I was wondering if my spec should depend on yours ...
[14:18] <mvo> cjwatson: sounds sensible, at least the add-distribution, add-package are something I need to add too
[14:20] <mvo> cjwatson: I update my spec to point to the golden-image one
[14:21] <mvo> cjwatson: did you had a chance to look at my debconf question btw? (not urgent, I'm just curious if I'm on the right track in general)
[14:26] <cjwatson> mvo: I've looked at it, but haven't worked out the answer yet :-)
[14:26] <cjwatson> mvo: I think you're on the right track in general, yes; that's the same approach that installer bits use
[14:27] <cjwatson> mvo: sorry, it literally took me four hours this morning to get through stuff that had accumulated overnight
[14:27] <cjwatson> mvo: I don't suppose you could get a 'DEBCONF_DEBUG=.' log?
[14:28] <mvo> cjwatson: no problem, thanks for looking at it
[14:28] <cjwatson> I think you're probably accidentally talking to the wrong frontend at some point, or one of the frontends isn't quite being configured right, or something
[14:28] <cjwatson> the file descriptor plumbing for these things can be insanely delicate
[14:28] <cjwatson> especially with confmodules re-execing themselves
[14:29] <cjwatson> I got it wrong in debconf-apt-progress several times
[14:29] <mvo> cjwatson: no worries, if I'm doing the right thing in general, I will try to work it out, I just wanted to avoid debugging something that was the wrong approach :)
[14:33] <NCommander> pitti, we're going to need to promote pango-perl for libgtk2-perl to be buildable
[14:34] <pitti> NCommander: ok, can you please file a MIR bug?
[14:34] <pitti> sounds like an easy package
[14:34] <NCommander> pitti, I assume a full MIR is also needed :-/
[14:39] <pitti> NCommander: if it's a trivial package (perl bindings to a lib), just check Debian maintenance and bug status
[14:39] <pitti> and add that to the bug report
[14:45]  * ScottK thinks NCommander should do the full MIR just for practice.
[14:45]  * NCommander stabs ScottK for practice
[14:46] <NCommander> pitti, http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=libpango-perl
[14:47] <jpds> Anyone know what happened to http://cdimage.ubuntu.com/daily/current/ ?
[14:48] <pitti> NCommander: fair 'nuff :)
[14:49]  * NCommander loads the coffee maker
[14:50] <NCommander> crap
[14:50] <NCommander> My home folder backup seems to have been corrupted
[14:50] <ScottK> NCommander: Not good with coffee.
[14:50]  * NCommander gives ScottK the EVIL eye
[14:52]  * NCommander has concerns about the wiseness of using ext4 as the default filesystem ...
[14:54] <ogra> NCommander, to late ... switch already happened
[14:54] <toggles_w> works great for me, been using it since jaunty alphas
[14:54] <NCommander> ogra, I know it did
[14:54] <NCommander> toggles_w, sam ehere, and I suspect I may have had data corruption due to it :-/
[14:54] <toggles_w> i must say i like the fsck speed ;-)
[14:54] <NCommander> That I do like.
[14:54] <toggles_w> Oh really?
[14:54] <NCommander> toggles_w, well, I can't prove it
[14:54] <toggles_w> loose anything interesting?
[14:55] <NCommander> Near miss on my GPG and SSH keys
[14:55] <NCommander> I just wiped the HDD after doing badblocks and reinstalled today
[14:55] <toggles_w> sorry to hear that, im running it on a bunch of machines, power failures etc, seems to be fine
[14:55] <NCommander> Parts of my music collection and a few episodes of TV :-/
[14:55] <NCommander> Well, I was suspecting the HDD, but that passed badblocks ...
[14:56] <toggles_w> backup ;-)
[14:56]  * toggles_w ducks
[14:56] <NCommander> I did
[14:56] <NCommander> It was partially corrupted
[14:56] <NCommander> That's what I managed to salvage out of the tbz2 I made of my home folder
[14:56] <toggles_w> ouch
[14:56] <NCommander> Yeah
[14:56] <NCommander> I'm trying to figure out how that happened
[14:57] <NCommander> Because I backed it up on the machine, then punted it to my Babbage board, then punted it back.
[14:57] <ogra> for your gpg keys you just use the backup you burned on CD when you got them signed first :P
[14:58] <NCommander> argh
[14:58] <NCommander> I think I lost my .vimrc
[14:58] <NCommander> .... *hopes theres a spare copy on the ARM porting box ..*
[14:59] <NCommander> -rw-r--r-- 1 mcasadevall warthogs 178 Jun 12 16:19 .vimrc - bahahahahaha
[15:00] <cody-somerville> mvo, ping
[15:01] <mvo> cody-somerville: hello
[15:02] <NCommander> Lesson learned: Test your ability to restore from backup before wiped your HDD
[15:02] <NCommander> *sigh*
[15:04] <ScottK> NCommander: "Amateurs back up.  Professionals restore."
[15:04] <ogra> ++
[15:05] <NCommander> *glares*
[15:06] <cody-somerville> lol
[15:07] <NCommander> Well, the absolute irreplacebles survived
[15:07] <NCommander> so thats good
[15:23] <rtg> tseliot: whats the name of the Karmic Broadcom wl DKMS package? It appears to have disappered from the archive.
[15:23] <tseliot> rtg: bcmwl-kernel-source
[15:24] <rtg> tseliot: universe still ?
[15:24] <tseliot> superm1: ^^
[15:24] <superm1> rtg, tseliot : https://edge.launchpad.net/ubuntu/+source/bcmwl it's in restricted
[15:25] <rtg> doh!
[15:26] <al-maisan> hello Riddell, could you please take a look at https://bugs.edge.launchpad.net/ubuntu/+source/lcms/+bug/388987 ?
[15:27] <tseliot> rtg: BTW I haven't uploaded my changes yet. I'm working on it
[15:28] <rtg> tsk
[15:28] <rtg> tseliot: damn tab completion. OK
[15:31] <Viper550> ooh so they changed the grub menu design?
[15:32] <cjwatson> err, by virtue of switching to grub2
[15:32] <cjwatson> what's there right now is not permanent
[15:33] <Viper550> you can still do customization right?
[15:33] <Viper550> and I knew it was probably grub 2
[15:33] <cjwatson> I have no idea what its customisation facilities are
[15:33] <cjwatson> they're in flux anyway
[15:34] <lool> evand, cjwatson: Would it make sense to consider GRUB 2 for USB disks created by usb-creator instead of syslinux?  One thing I have in mind is EFI support, but I don't know whether it's possible to have both classical BIOS and EFI support on USB
[15:35] <cjwatson> lool: maybe
[15:35] <lool> (/me knows next to nothing on EFI, just that more platforms are switching to it)
[15:35] <cjwatson> there are still USB fixes going into GRUB 2 though ...
[15:35] <Viper550> why can't we use isolinux on the bootloader as a temp?
[15:35] <Viper550> on the CD
[15:36] <cjwatson> huh? we do
[15:36] <lool> I didn't here any complains about CDs, isolinux is fine there
[15:37] <Viper550> on karmic you use grub2?
[15:37] <Viper550> oh wait
[15:37] <lool> Not on the CDs (for now at least)
[15:37] <lool> grub2 is the bootloader we now install for the installed system
[15:38] <Riddell> al-maisan: ok
[15:39] <cjwatson> Viper550: what lool said.
[15:39] <Viper550> oh
[15:39] <cjwatson> long-term I might be comfortable switching to grub2 on the CDs as well
[15:39] <cjwatson> but not this release
[15:40] <cjwatson> for one thing, the graphical menu patches to grub haven't landed yet
[15:40] <Viper550> not until suse does them right?
[15:40] <cjwatson> nothing to do with suse
[15:41] <cjwatson> I shouldn't think grub2 will get gfxboot; there's an independent graphical menu effort going on
[15:41] <cjwatson> http://grub.gibibit.com/ if you want to look into it, I haven't really yet
[15:43] <Viper550> so ubuntu will probably use that?
[15:44] <cjwatson> maybe
[15:44] <cjwatson> we haven't fully evaluated it - I just know it exists
[15:45] <lool> I just thought of something
[15:45] <lool> Why don't we load the kernel in the background when waiting for the grub timeout?
[15:46] <lool> (Add an optional enabled by default feature to autopreload the default entry)
[15:46]  * cjwatson has no idea if grub can do that
[15:46] <lool> I doubt it can do that know, but I am pretty sure it would save us exactly timeout seconds boot time  :-)
[15:46] <cjwatson> suggest it upstream :)
[15:47] <lool> Actually I only ever looked at GRUB1, don't take my word GRUB2 can't do it, I don't use it yet
[15:47] <cjwatson> it's not completely impossible that it can
[15:47] <cjwatson> GRUB 2 does have scripting support
[15:48] <Riddell> al-maisan: uploaded, thanks
[15:48] <al-maisan> Riddell: thank you :)
[15:53] <rtg> cjwatson: what was the decision on the minimum supported x86 instruction set for Karmic? What it i586 and higher?
[15:53] <rtg> s/What/Was/
[15:55] <rtg> in other words, the 386 ports kernel is pretty much at a dead end with Jaunty.
[15:55] <lool> cjwatson: According to random upstream developer on IRC, it's not possible yet and better to file a patch implementing it than a feature request (which I can understand)
[15:55] <evand> kenvandine: am I correct in believing that we're getting webkit on the CD via gwibber per the social from the start work?
[15:55] <evand> please say yes :)
[15:56] <lool> That said, it might be mot as I think Scott mentionned a zero timeout and entering grub is a key is held down; but I'm not 100% sure I remember correctly
[15:56] <rtg> lool: that is my recollection
[15:58] <lool> rtg: I suggested doing that two cycles ago, but Scott argued back then that some BIOSes would disable keys if you'd press them down during boot (considering the keyboard/key as buggy)
[15:58] <Keybuk> lool: then Fedora did it, and proved there weren't any
[15:58] <evand> apparently that's no the case
[15:58] <evand> not*
[15:58] <evand> heh
[15:59] <Keybuk> or at least, not many
[15:59] <lool> Too bad we didn't do it then
[15:59] <NCommander> pitti, how goes the MIR :-)
[15:59] <lool> But we're going to do it!  \o/
[15:59] <rtg> lool: using the shift key is evidentally OK
[16:00] <NCommander> rtg, the only reason the 386 kernel survived into the karmic cycle is because we needed at least one kernel building on i386 or increase the delta between the ports kernel and mainline kernel
[16:00] <rtg> NCommander: but what good is the 386 kernel if user space won't work?
[16:01] <lool> rtg: I'm using ctrl/alt/shift just fine with "mbr", but I'd be interested in knowing why it's inherently ok?  You mean because these are modifiers?
[16:01] <NCommander> rtg, its virtually useless, the problem is Arch: all binaries needed to be built on i386, and the build system when snap when we tried dropped 386.
[16:01] <NCommander> rtg, it was on my to-be-fixed list, but there isn't much point since ports will be merging into the mainline kernel git tree.
[16:01] <rtg> lool: that is my understanding
[16:02] <rtg> NCommander: ok, at least I'm not insane
[16:03] <NCommander> rtg, I told Luk to drop it (with the HPPA kernel) as part of the merge he generated (I have a set of outstanding patches to fix ia64 and sparc's config files which will hopefully be posted shortly after everything lands in the main tree)
[16:04] <rtg> NCommander: I was responding to mvo about upgrades. It sounds like there is no upgrade path for 386.
[16:04] <cjwatson> rtg: decision not made because we're still waiting for benchmarking which is waiting for infinity to get back from being ill
[16:05] <rtg> ah, limbo.
[16:05] <NCommander> rtg, oh, sorry, missed that bit. Yeah, thats correct. (strictly speaking, the 386 kernel only worked on 486 machines)
[16:05] <cjwatson> rtg: and in any case we were talking about optimisation not minimum supported set
[16:05] <cjwatson> rtg: i.e. -mtune not -march
[16:05] <cjwatson> rtg: so no effect on the 386 ports kernel
[16:05] <rtg> cjwatson: so the 386 ports kernel will still workl?
[16:05] <cjwatson> rtg: ought to
[16:06]  * NCommander wonders if anyone actually uses it
[16:06] <cjwatson> yes
[16:06] <cjwatson> I get people showing up on #ubuntu-installer asking for help with such systems from time to time
[16:06] <NCommander> cjwatson, I'll be darned.
[16:08]  * NCommander needs to sit down and see if we can drop powerpc-smp as a individual kernel
[16:08] <NCommander> I'd like to drop sparc-smp, but to my knowledge, our userland will work in places where that kernel won't ....
[16:09] <tgpraveen> evand: some amount of webkit support will
[16:09] <tgpraveen> be there as empathy uses it for their adium themes
[16:09] <tgpraveen> and iirc there will be a human theme for it by default also
[16:10] <NCommander> cjwatson, BTW, d-i sparc should be fixed with the next kernel upload, I found out what was breaking it :-), ia64 images should also start building with the next upload
[16:12] <evand> tgpraveen: empathy in karmic does not currently list webkit as a dependency, are you saying that a newer version will?
[16:12] <cjwatson> NCommander: good, thanks
[16:12] <tgpraveen> don't know exactly bt I do know libwebkit is needed for the adium themes for empathy which WILL ship in karmic
[16:13] <tgpraveen> so yes maybe it will be added soon . maybe some dev could confirm?
[16:13] <NCommander> cjwatson, the problem was we've been shipping uncompressed kernels for the last two and half cycles on port architectures due to a little mistake dating from when the ports tree and the mainline tree were separated :-/
[16:23] <Keybuk> cjwatson: bug #385911 - what kind of "more careful" were you thinking of?
[16:25] <MacSlow> asac, what means it exactely when the nm-applet ghosts the wifi-devices in its the menu?
[16:25] <al-maisan> Hello Keybuk, please take a look when you have time: https://bugs.edge.launchpad.net/ubuntu/+source/lm-sensors-3/+bug/389031
[16:27] <Keybuk> cjwatson: nm, I have an idea
[16:28] <cjwatson> Keybuk: maybe whitespace or start/end-of-string either side?
[16:28] <Keybuk> cjwatson: for ARG in $(cat /proc/cmdline) seems like a good way ;)
[16:28] <cjwatson> it's just being a bit too liberal about word boundaries is all
[16:29] <cjwatson> that works too
[16:29] <Keybuk> split on $IFS
[16:30] <asac> MacSlow: screenshot please ;)
[16:32] <MacSlow> asac: well "Gerät wird nicht verwaltet" is stated there too for both wifi-devices
[16:32] <MacSlow> asac, but I've no clue where to instruct nm to "feel responsible" for these two
[16:33] <asac> MacSlow: anything in /etc/network/interfaces?
[16:34] <MacSlow> asac, yes auto wlan0 ... and auto wlan1 ...
[16:34] <MacSlow> asac, should I get rid of those entries?
[16:34] <asac> MacSlow: hmm. remove those too lines, then do sudo killall nm-system-settings
[16:34] <asac> two
[16:34] <asac> MacSlow: also if that helps, file a bug please ... auto lines alone shouldnt make the devices unmanaged i think
[16:35] <MacSlow> asac, I think I had someone like you or keybuk once mess with my laptop... so that might explain these lines... I think to remember now
[16:36] <asac> MacSlow: did you have iface lines too? or just auto?
[16:36] <asac> MacSlow: if it was just auto i definitly want a bug
[16:36] <asac> thx
[16:37] <MacSlow> asac, no there were also "mode managed" and "essid ubuntu" lines below each "auto wlan*" line
[16:40] <asac> MacSlow: ok. so also iface wlan0 ... etc?
[16:40] <asac> thats a feature then
[16:41] <MacSlow> yes
[16:42] <MacSlow> hm... nothing changed
[16:42] <MacSlow> do I need to restart more than NetworkManager after doing "sudo killall nm-system-settings"?
[16:45] <MacSlow> *sigh* fsck
[16:47] <MacSlow> asac, well that didn't change anything
[16:49] <asac> MacSlow: paste your interfaces please
[16:49] <MacSlow> asac, "iwlist scan" tells me for wlan0 "Failed to read scan data: Network is down" and for wlan1 I get "No scan results"
[16:49] <asac> MacSlow: also paste hat you get in syslog after killall and restarting NM
[16:53] <ttx> cjwatson, pitti, slangasek: By FeatureDefinitionFreeze "all features with updates to be landed  in main for the release must be named and acked by the ReleaseTeam" -- how do you want to proceed exactly ?
[16:54] <ttx> get an email ? be subscribed to the relevant blueprints ?
[16:55] <ttx> Hobbsee, Riddell: same question ^
[16:57] <MacSlow> asac, http://pastebin.ubuntu.com/198631
[16:57] <asac> MacSlow: you didnt paste your current /etc/network/interfaces
[16:58] <asac> MacSlow: anyway. the problem now is your killswitch
[16:58] <asac> (no need to paste more)
[16:58] <asac> MacSlow: so either use fn+F5 until you see the wifi led
[16:58] <asac> MacSlow: or check that you dont have the hardware killswitch flipped
[17:00] <MacSlow> asac, the hw-killswitch is certainly off
[17:00] <MacSlow> asac, Fn-F5 only makes the bluetook LED switch on or off
[17:02] <asac> MacSlow: please flip the hw-killswitch a few times and paste the tail of syslog you get when doing that
[17:10] <MacSlow> asac, http://pastebin.ubuntu.com/198638
[17:10] <MacSlow> asac, only bluetooth seems to be affected by the killswitch
[17:13] <asac> MacSlow: thats not syslog ;)
[17:13] <asac> (guess its dmesg)
[17:13] <asac> MacSlow: anyway. try to reboot. maybe its a bad driver state
[17:14] <asac> (or check that you havent disabled wireless in the applet menu)
[17:14] <MacSlow> asac, I did "tail -f /var/log/syslog >/tmp/log.txt"
[17:14] <MacSlow> if that's not syslog then call me stupid
[17:15] <MacSlow> what's the difference between dmesg and syslog anyway?
[17:19] <asac> MacSlow: try to reboot or reload the iwlagn driver (you are still using thinkpad right)?
[17:20] <asac> MacSlow: also paste output of nm-tool ;)
[17:24] <MacSlow> asac, rebooted no change
[17:24] <MacSlow> asac, I'm using the iwl3945 driver here and the ath9k fro the wifi-card plugged into the PCMCIA-slot
[17:24] <MacSlow> asac, looking at the nm-tool output now
[17:25] <asac> why do you have two wifi cards? does it change if you boot without the ath9k thing?
[17:26] <MacSlow> asac, http://pastebin.ubuntu.com/198643/
[17:26] <MacSlow> asac, no
[17:26] <MacSlow> asac, no matter if I boot with the ath9k plugged in or not
[17:27] <MacSlow> I cannot get any wifi-connection
[17:27] <asac> MacSlow: when did this start? are you using karmic or jaunty?
[17:27] <MacSlow> between interpid/jaunty timeframe
[17:30] <MacSlow> asac, if that observation is any hint...
[17:30] <MacSlow> when I plug in the ath9k
[17:30] <MacSlow> I do get a scan result from "iwlist scan"
[17:31] <asac> MacSlow: have you tried to install linux-backport-modules-jaunty?
[17:31] <MacSlow> asac, no
[17:31] <asac> MacSlow: do that and restart your system
[17:31] <MacSlow> asac, I guess I should try?!
[17:31] <asac> yeah
[17:32] <asac> MacSlow: anyway. i am out for today and have two days holidays. if backport modules dont help, i would like to look next week closer. so just ping me after tue ;)
[17:33] <asac> MacSlow: its linux-backports-modules-jaunty ... ok out for a while
[17:35] <DrPepperKid> asac, it's me MacSlow (on the laptop now... ethernet-based internet for the moment)
[17:35] <superm1> tseliot, one more thing on the bcmwl, i'm not sure shipping that blacklist file in /etc/modprobe.d/blacklist-bcmwl.conf is the right solution. when jockey enables it, it builds a blacklist that is a little more advanced (queries to see if it needs to work with b44 too)
[17:36] <superm1> pitti can comment hopefully more on what jockey is doing
[17:36] <DrPepperKid> asac, I'm on karmic on this laptop not jaunty
[17:36] <superm1> maybe it's best to just move that logic for building the blacklist into the postinst, and then all jockey has to do is install bcmwl-kernel-source and bcmwl-kernel-source's postinst then would figure out what to do about b44 and how to build such a blacklist
[17:40] <rtg> superm1: the bcm wl Karmic package does appear to work, I have it on a mini-9.
[17:40] <rtg> (after futzing with blacklists)
[17:40] <superm1> rtg, good to hear
[17:41] <superm1> hoping to see the proper blacklist preparations sorted out before tseliot's new modalias stuff hits to prevent too much confusion
[17:41] <rtg> superm1: did Jernone pass on Tony and my thoughts about their user space version of the driver?
[17:42] <superm1> rtg, yes but keep in mind the channel you're discussing in
[17:43] <rtg> I don't think its a secret. I've already seen discussion of it in the wild.
[17:44] <superm1> i'll  be summarizing the points I saw for next time we discuss with them
[17:55] <MacSlow> asac, ok ath9k based wifi works on the laptop again now
[17:57] <MacSlow> asac, thanks for the help sofar!
[17:59] <MacSlow> asac, http://pastebin.ubuntu.com/198664
[17:59] <MacSlow> asac, does that tell you anything about the remaining problem with iwl3945 wifi-card (that's the internal one)?
[18:19] <ccheney> slangasek: is there anything needed to be approved for OOo 3.1.1 wrt FDF, we already have 3.1.0 in and 3.1.1 will release sometime in august
[18:53] <MacSlow> 800 MBytes worth of updates *sigh*
[18:58] <tseliot> superm1: yes, I'm aware of what jockey does. I'm not sure as to whether I can do the same in a blacklist file. Currently we have separate blacklist files: one in my package and one is created by jockey. The one in jockey can blacklist b44 and make sure that it's loaded after wl
[19:00] <tseliot> superm1: here's what jockey does:
[19:00] <tseliot> http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/annotate/head%3A/data/handlers/broadcom_wl.py
[19:06] <MacSlow> hm... how can gnome-power-manager-2.27.1 compile on Karmic if it does not have the right version of DeviceKit-power defining dkp_client_lid_is_closed() ?
[19:11] <MacSlow> pitti, do you know how that can work ... compiling gnome-power-manager 2.27.1 under Karmic although DevKit-power-dev is not current enough?
[19:11] <MacSlow> pitti, my installed DevKit-power-dev is missing the definition for dkp_client_lid_is_closed() which is used in gnome-power-manager 2.27.1
[19:11] <ccheney> didn't dapper desktop support already go away by now? i didn't see mention of it on ubuntu-announce yet though
[19:28] <superm1> tseliot, i think that same stuff can be done in sh in the postinst, just checking lsmod for b44, and writing out a different blacklist if so
[19:52] <Keybuk> 64-bit gdb can't read 32-bit core files and executables
[19:52] <Keybuk> I honestly did not expect that
[19:54] <elmo> Keybuk: there's a gdb64 on 32-bit; is there not a gdb32 for 64-bit?
[19:55] <Keybuk> elmo: not that I could see
[20:13] <tseliot> superm1: only on 1st installation?
[20:30] <Sarvatt> anyone familiar with usplash here that I could nag? usplash segfaults (but leaves the graphic on the screen) under a KMS framebuffer which is kind of a problem when fsck or a password entry is needed
[20:31] <Sarvatt> is it only designed to work at certain resolutions?
[20:37] <mterry> cjwatson: I'm looking at the oem-config desire to translate city names.  What's the best thing to do for a case like that, where translating city names would leave us with a large translation delta?  Only do it through debian?  Use a separate template in its own directory?
[20:37] <mterry> evand: ^^
[20:38] <jpds> Sarvatt: You'd probably want to talk to Keybuk.
[20:39] <Sarvatt> I'm not sure how to debug it further is all. when you build i915 with KMS enabled into the kernel to get the high resolution drmfb from the start of boot you get the initial graphic and it segfaults right away instead of running throughout the boot process looking at my bootcharts. some people on the ubuntu stock kernel with i915 as a module have their screen black out after the cryptloop password entry when it switches to the KMS framebuffer. if
[20:39] <Sarvatt> they build i915 into the initrd so it switches to the KMS fb earlier they can no longer see the password entry screen at all
[20:57] <superm1> tseliot, not necessarily.  Here's what i'm thinking (untested) http://pastebin.com/f45ce73aa
[20:57] <superm1> so if someone removes it and say runs dpkg-reconfigure bcmwl-kernel-source, it would be rebuilt for them
[20:57] <RainCT> pitti: I've just given you reviewer rights on REVU (so you can advocate/veto/archive).
[20:58] <RainCT> If any other MOTU/Core Dev is missing them poke me or another REVU admin (there's a full list at REVU's Statistics page, at the bottom right)
[21:00] <cjwatson> mterry: make every possible effort to use an existing source for the translations - we don't want the quadratic effort of doing it ourselves
[21:00] <cjwatson> mterry: and then have a dynamic build process that uses that existing source
[21:00] <cjwatson> mterry: yes, it should be a separate set of .pot/.po files that get merged. there are already some udebs that do this sort of thing
[21:01] <cjwatson> mterry: I'm not sure if any of Debian's installer interfaces ever display all available cities in any given language
[21:01] <cjwatson> mterry: if there are any, it would be tzsetup
[21:02] <tseliot> superm1: and how do I decide whether I should remove the blacklist file or not (which jockey might have modified in the meantime) in the postrm? Shall I simply remove it if it exists?
[21:02] <superm1> ah yeah probably
[21:02] <superm1> tseliot, ^
[21:02] <cjwatson> Sarvatt: try to set up usplash to run in an environment with 'ulimit -c unlimited' set, and then try to arrange that the core dump ends up somewhere useful that you can look at after boot
[21:03] <cjwatson> Sarvatt: usplash hasn't been adapted for KMS in an initramfs environment yet though - I did make a start on that but ran into some problems with KMS on my hardware and haven't finished
[21:03] <tseliot> superm1: now that I think of it, pitti is available to remove those commands from the handler in Jockey if I can deal with the blacklist directly in the package (we discussed this today)
[21:05] <superm1> tseliot, yeah so that's what i'm thinking, jockey wouldn't do any of that, it would all be handled by the package itself indeed
[21:06] <superm1> tseliot, so jockey really is just a frontend then to say "install me" and the postinst/postrm would do what the handlers did soley
[21:06] <tseliot> superm1: ok then, I'll work on it tomorrow.
[21:06] <superm1> tseliot, awesome thanks!
[21:06] <slangasek> ttx: an email listing all the specs for your team, and a discussion item at tomorrow's release meeting
[21:08] <slangasek> ccheney: no, nothing we need to worry about with OOo 3.1.1 there
[21:08] <ccheney> slangasek: ok
[21:58] <Fabio23> salve c'è un modo per vedere il numero dei cicli che ha compiuto il mio hd da linux ubuntu?
[22:15] <EvanCarroll> I just merged together 13 bugs related to a debian-perl group problem.
[22:25] <directhex> banshee magnatune extension developer is coming out of the woodwork
[22:25] <directhex> he's accepted my fixes to get the preview stream part (the only implemented part so far) working on banshee 1.5.0
[23:31] <EvanCarroll> https://bugs.launchpad.net/ubuntu/+source/libxml-sax-perl/+bug/13917
[23:32] <EvanCarroll> Anyway, I'm not sure the Debian Perl guys will fix this. I'm thinking about blueprinting out a removal of all Debian hacked perl modules.
[23:32] <EvanCarroll> Becaues it is dirty thing they do, fork a cpan module, modify the contents of it, pollute its namespace ,and then publish it under the same name.
[23:33] <EvanCarroll> the gain isn't worth it
[23:48] <cjwatson> EvanCarroll: (a) I don't see why Debian wouldn't fix this; yes, I know there was a semi-objection raised by a maintainer in the past, but the Debian Perl Group has had a good deal of turnover since then; (b) this is the first case I've ever heard of featuring this kind of change so I don't think it's all that big a thing
[23:50] <cjwatson> and just look at all those rdepends - this needs to be fixed, not removed
[23:54] <Caesar> So multiple hyphens in a version is a no no isn't it?
[23:54] <slangasek> it's tacky, but not prohibited :)
[23:54] <StevenK> Caesar: It's not, but only if the package is non-native
[23:54] <Caesar> I seem to have grown a plus sign
[23:55] <slangasek> "If there is no <debian_revision>, then hyphens are not allowed [in the upstream version]"
[23:55] <Caesar> So I'm looking at the sun-java6-jre package for example
[23:55] <Caesar> With a version of 6-14-1 in karmic/multiverse
[23:56] <slangasek> Caesar: perfectly permitted, since the -1 is the Debian revision
[23:57] <Caesar> Okay, so the problem is grep-dctrl in Hardy then
[23:57] <Caesar> It's spitting out stuff like: grep-dctrl: -:10221: expected a colon.