[12:44] <ajmitch> morning
[01:05] <jmg> anyone know how to print a range in awk?
[01:44] <Hobbsee> morning all
[01:45] <bhale> hi Hobbsee 
[01:45] <Hobbsee> bhale: :)
[02:20] <micahcowan> ping BenC
[03:46] <keescook> g'night folks
[03:46] <ajmitch> night keescook 
[03:47] <keescook> cya ajmitch 
[03:47] <Hobbsee> night keescook 
[03:47] <keescook> bye Hobbsee
[03:47] <keescook> oh, ajmitch, did you happen to snag the SELinux initramfs stuff off your laptop?
[03:49] <ajmitch> keescook: I should grab it now 
[03:49] <ajmitch> it's on there somewhere :)
[03:52] <ajmitch> keescook: dget http://ajmitch.net.nz/debuild/selinux/selinux-basics_0.3.0ubuntu1.dsc
[03:52] <ajmitch> I haven't really changed anything except adding in the hook 
[03:52] <ajmitch> so don't upload it as-is :)
[04:04] <BenC> micahcowan: pong
[04:11] <keescook> ajmitch: thanks (though the tar.gz is missing.)
[04:14] <ajmitch> hm, shouldn't be, I put it there
[04:14] <keescook> the ubuntu1 tar.gz was missing
[04:15] <ajmitch> it's there now :)
[04:31] <keescook> +mount -t proc ${rootmnt}/proc ${rootmnt}/proc
[04:31] <keescook> +umount /root/proc
[04:32] <keescook> should that last one be umount ${rootmnt}/proc  ?
[04:32] <Hobbsee> keescook: you dont appear to be giong to bed... :P
[04:33] <keescook> Hobbsee: yeah, there does seem to be that problem.  :P
[04:33] <ajmitch> keescook: quite likely, this was more along the lines of an experiment :)
[04:33] <Hobbsee> :P
[04:33] <keescook> ajmitch: very cool.  Now I can experiment too.  :)  thanks!
[04:33] <ajmitch> have fun!
[04:34] <ajmitch> nb: it won't work if you have / & /usr on separate partitions
[04:44] <djf_jeff> hi, maybe not at the right place but I have a small question : is there a reason why libevent is still at the version 1.1a and not the lastest?
[04:45] <Hobbsee> djf_jeff: because no one has updated it?
[04:46] <djf_jeff> Hobbsee: I already guess this ;) Just want to know if there was a compatibility reason for this
[04:46] <Hobbsee> no idea
[04:50] <djf_jeff> Hobbsee: ok, thank you, checking the package page on the debian website show some reasons, I should have check there first
[04:50] <Hobbsee> no problem :)
[05:32] <micahcowan> BenC, did you see my recent response on my patch submission?
[06:03] <BenC> micahcowan: yeah, but at the same time, I'd rather patches like that make their way down through -mm and finally to Linus' tree
[06:13] <micahcowan> BenC, okay, understood. It's currently in -mm. I'll let you know when it's in the main tree.
[06:13] <BenC> micahcowan: if it makes it into 2.6.22, it'll get into gutsy
[06:15] <micahcowan> BenC, yeah, that's what I figured. It's not like we don't have plenty of time. :) Just want to keep progress going on it so I can eventually close the bug.
[06:15] <micahcowan> Thanks, Ben.
[06:22] <tepsipakki> morning
[06:23] <tepsipakki> how come does MoM claim a package to be on the normal merge list when the tarballs differ?
[06:23] <tepsipakki> the package being x-x-v-suncg6
[07:55] <Burgundavia> is powernowd not run by default for a reason?
[07:56] <Hobbsee> Burgundavia: it's in universe...
[07:56] <Hobbsee> iirc
[07:56] <Burgundavia> hmm
[07:57] <Burgundavia> nope
[07:57] <Burgundavia> installed by default
[07:57] <Mithrandir> Burgundavia: we use the ondemand governor by default.
[07:57] <Burgundavia> hmm
[07:58] <Burgundavia> which doesn't scale my celeron M
[07:58] <Burgundavia> guess that is a bug
[08:00] <Mithrandir> sounds like a bug, yes
[08:05] <Burgundavia> would that be a laptop-detect bug, or a kernel one?
[08:06] <dholbach> good morning
[08:06] <Burgundavia> morning dholbach
[08:06] <Hobbsee> morning dholbach 
[08:06] <dholbach> hey Burgundavia, hey Hobbsee
[08:09] <pitti> Good morning
[08:10] <Hobbsee> hiya pitti!
[08:10] <Burgundavia> Mithrandir: what should I report the bug against. It doesn't look like the proper module is being loaded
[08:10] <pitti> hey Hobbsee 
[08:10] <Mithrandir> Burgundavia: if there's a kernel that's not being loaded, but should be, it's a kernel bug.
[08:11] <Mithrandir> morning Martin, Daniel
[08:13] <tepsipakki> morning folks, I'll repeat the earlier question; any idea why MoM shows x-x-v-suncg6 to be on the main merge queue when it should be on main-manual (different tarball)?
[08:13] <pitti> hi Tollef
[08:13] <pitti> tepsipakki: that should only happen if it ever shared a tarball with Debian; an earlier version perhaps?
[08:14] <StevenK> I note that MoM still shows python-xml for main.
[08:14] <tepsipakki> pitti: no, same version (1.1.0)
[08:15] <Fujitsu> StevenK: Is it not in main? It seems to be here...
[08:15] <StevenK> Fujitsu: Compare the versions in LP versus MoM for python-xml.
[08:16] <Fujitsu> Hm, right.
[08:19] <hydan> what's the status of zfs being ported?
[08:44] <dholbach> grrrrrrr network-manager grrrrrrrrr
[08:45] <Burgundavia> dholbach: has it been hardlocking your X as well?
[08:47] <dholbach_> Burgundavia: no, not that - but it seems it can only connect to my wireless once, if I want to reconnect or if it disconnects for some reason, I have to remove the key from gnome-keyring-manager, then re-add it again
[08:47] <dholbach_> back on cable network *GRRRRR*
[08:47] <Hobbsee> it just hates you
[08:48] <dholbach> maybe somebody is going to updated nm to the newest version in gutsy and all will be good
[08:48] <dholbach> maybe
[08:56] <Hobbsee> dholbach: you volunteering?
[08:57] <dholbach> Hobbsee: maybe not
[08:57] <Hobbsee> aww
[09:13] <pitti> dholbach: is 0.7 actually released now?
[09:13] <dholbach> pitti: 0.6.5
[09:14] <pitti> dholbach: if someone beats me to it hard enough I might give it a try
[09:14] <pitti> fixing the broken zeroconf negotiation is on my wishlist for a long time anyway
[09:28] <Jim7J1AJH> Where should I go to find out about python-central and python-support?  (I packaged my app on Feisty, but want to make versions installable on Dapper.  I'm wondering if I should have stuck with the dummy package and underlying python2.n- binaries scheme.)
[09:29] <pitti> Jim7J1AJH: dapper didn't have central/support and the new-world python policy yet
[09:29] <pitti> Jim7J1AJH: so I'm afraid that's the case
[09:30] <Jim7J1AJH> Thanks.  I didn't think to check that until after packaging.
[09:44] <doko_> dholbach, seb128: will you do the glade merge?
[09:46] <dholbach> doko: yes
[09:46] <pitti> dholbach: hm, ISTR that you already talked about the solution of that '<fdopen>' attachment problem (bug 115347); do you already have something in mind, API-wise?
[09:46] <doko> dholbach: thx
[09:46] <ubotu> Launchpad bug 115347 in apport "retracer needs to hint at MIME type text/plain" [Low,In progress]  https://launchpad.net/bugs/115347
[09:47] <dholbach> doko: did you have a chance to find out why and how the python-dbg packages are broken?
[09:48] <tepsipakki> doko: I've done the syslinux-merge, grabbed an updated patch from suse and the gfxboot works with the new syslinux. I've been in touch with colin about it
[09:48] <pitti> slomo: argh, texlive-bin still has this weird 'multiple _init/_fini' problem; argh
[09:49] <doko> tepsipakki: very cool, I did move that one to the end of my merge list ...
[09:49] <tepsipakki> doko: heh, can't blame you :)
[09:52] <dholbach> pitti: hum... shouldn't MultipartPostHandler pass the mime-type?
[09:53] <pitti> tepsipakki: rock! I'm TIL for it, but traded it with cjwatson
[09:53] <pitti> dholbach: I'll think about it, I just want to avoid double work, since I remember you saying something about it
[09:53] <dholbach> pitti: I don't know what I should have said about it :)
[09:54] <pitti> ok; nevermind then :)
[09:55] <dholbach> MultipartPostHandler already does   contenttype = mimetypes.guess_type(filename)[0]  or 'application/octet-stream'  - maybe it doesn't get called?
[09:55] <pitti> I'll look into it
[09:59] <Keybuk> morning
[09:59] <dholbach> heya seb128
[10:00] <seb128> hi dholbach
[10:08] <Keybuk> seb128: was the Debian menu supposed to have turned up?
[10:08] <tepsipakki> pitti: about syslinux&no-stack-protector; it seems that upstream has set -fno-stack-protector in some of the Makefiles, but not in all of them. Do you think the rest should still have that?
[10:08] <seb128> Keybuk: no
[10:08] <seb128> Keybuk: and it's not on my desktop
[10:08] <pitti> tepsipakki: as long as it builds, it's fine
[10:08] <pitti> tepsipakki: i. e. just try ;)
[10:08] <tepsipakki> pitti: ah, ok
[10:09] <pitti> tepsipakki: you'll get a linker failure about a missing __stack_chk_fail() if it's missing somewhere
[10:09] <tepsipakki> I've built it but maybe the gentoo-patch was applied then
[10:09] <tepsipakki> yep, I'll try dropping that
[10:09] <Keybuk> seb128: odd; I clicked the Revert button in Edit Menus by accident, and it turned up
[10:10] <seb128> Keybuk: looks like an alacarte bug then
[10:10] <Keybuk> yeah could be
[10:11] <Keybuk> I removed the .local/share/applications/X-Debian-blah-blah.desktop it created, and it went away again
[10:41] <slomo> pitti: yes... no idea why :)
[11:13] <dholbach> doko: glade merge done
[11:37] <Keybuk> when did Ctrl+Shift+Unicode break?
[11:38] <ion_> Ctrl-Shift-Unnnn
[11:38] <Keybuk> you have to put a U now?
[11:38] <pitti> Keybuk: since edgy or so
[11:38] <pitti> Keybuk: yep, Ctrl+Shift+u, then enter the digits
[11:41] <seb128> Keybuk: 
[11:41] <seb128> 	* gtk/gtkimcontextsimple.c: Rework the Unicode hex input
[11:41] <seb128> 	code. Now we only steal a single key combination, Ctrl-Shift-U,
[11:41] <seb128> 	instead of sixteen. 
[11:41] <seb128> that's since dapper
[11:41] <Keybuk> :-)
[11:42] <Keybuk> fortunately I don't remember the numbers of many Unicode characters,
[11:42] <Keybuk> and those I do, I don't feel the need to type very often
[11:42] <pitti> seb128: too bad that it doesn't work in xchat
[11:42] <Keybuk> wfm
[11:42] <pitti> Keybuk: 
[11:42] <Keybuk> ctrl-shift-U then type the numbers
[11:42] <Keybuk> it's nice that you don't need to hold down ctrl-shift afterwards
[11:42] <seb128> pitti: weird, it should work in any GTK+ application
[11:43] <pitti> oh, indeed, it just looks confusing
[11:43] <Keybuk> now if only we could fix Mono's lame-arse-broken keybindings, I'd be happy
[11:43] <seb128> ;)
[11:43] <Keybuk> (shift-delete, control-insert & shift-insert don't work)
[11:46] <pitti> mvo: can you please take a look at bug 107474? when would apt.Cache()[pkg] ._lookupRecord() fail?
[11:46] <ubotu> Launchpad bug 107474 in apport "[apport]  apport-retrace crashed with AssertionError in install_missing_packages()" [Undecided,Needs info]  https://launchpad.net/bugs/107474
[11:47] <pitti> mvo_: can you please take a look at bug 107474? when would apt.Cache()[pkg] ._lookupRecord() fail?
[11:47] <ubotu> Launchpad bug 107474 in apport "[apport]  apport-retrace crashed with AssertionError in install_missing_packages()" [Undecided,Needs info]  https://launchpad.net/bugs/107474
[11:48] <mvo_> pitti: yes
[11:55] <mvo_> pitti: it could fail if a) no version can be found in the cache b) if it can't find a indexfile for it. the most likely cause is that there is no version, but that is strnage because there should be at least the CurrentVer from /var/lib/dkg/status
[11:55] <doko> pitti: would you mind doing the pbbuttonsd merge?
[11:55] <pitti> doko: no, I wouldn't
[11:55] <doko> not sure if we really want to drop the i386 packages
[11:55] <pitti> doko: ... mind doing it
[11:56] <pitti> doko: I'm not sure to which extend it is useful on the x86 apples
[11:56] <pitti> I'll have a look
[11:58] <pitti> mvo_: hm, that sounds a bit strange; would that happen if someone dpkg -i's a package?
[11:58] <pitti> mvo_: NB that it is not a KeyError, apt.Cache() has an entry for it
[12:00] <mvo_> pitti: that is fine, apt will look into its own lists/ dir and into the dpkg status file
[12:00] <pitti> ah, so if I dpkg -i a package which is not in the lists, apt.Cache() will pick up the entry from /v/l/dpkg/status
[12:00] <pitti> ?
[12:00] <mvo_> pitti: yes
[12:01] <pitti> but _lookupRecord() would fail in that case?
[12:01] <mvo_> pitti: no, it should pickup the record from /v/l/dpkg/status
[12:02] <pitti> mvo_: (that's why I added that assert, since I could not think of a situration where the function would fail)
[12:03] <mvo_> pitti: let me do a bit more research
[12:08] <mvo_> pitti: it happens for virtual packages too. they have no version. and it can happen if a package is denoted in dpkg status but no information can be obtained about it (e.g. old conflicts etc)
[12:09] <pitti> mvo_: ah, good
[12:09] <pitti> mvo_: but usually virtual packages generate a KeyError
[12:09] <pitti> mvo_: but if it's a removed-but-not-purged package, that could happen
[12:10] <mvo_> mvo_: yes
[12:10] <mvo_> pitti: there seems to have been a amanda package but its gone now. that seems to cause the issue
[12:10] <mvo_> pitti: heh :)
[12:11] <pitti> mvo_: alright; thank you!
[12:11] <mvo_> cheers
[12:25] <carlos> mvo_: hi
[12:25] <mvo_> hey carl
[12:25] <mvo_> hey carlos
[12:26] <carlos> mvo_: We did a merge this week to fix the problem with that huge file from ddtp
[12:26] <mvo_> carlos: cool! so I can try to import that again?
[12:26] <carlos> mvo_: I think it's going to be deployed today or tomorrow
[12:27] <carlos> let me check, I think I just left it 'blocked' so It's just a matter of change its status once the change lands on production
[12:28] <carlos> mvo_: indeed, it's blocked
[12:28] <carlos> mvo_: if you don't have updates, you don't need to upload it again
[12:28] <carlos> I will care to get it imported
[12:28] <pitti> bdmurray, seb128, asac, mvo: FYI, with today's upload, apport drops the '[apport] ' bug title prefix and instead sets tags like apport-crash, apport-packaging, apport-bug, etc.
[12:28] <carlos> mvo_: btw, do you have time to talk about the languages you are adding to ddtp ?
[12:28] <seb128> pitti: cool
[12:29] <carlos> like ru_RU, sv_SE and others...
[12:29] <mvo_> carlos: I think I have some new stuff
[12:29] <carlos> mvo_: then go ahead and upload it
[12:29] <carlos> will override what is now there
[12:30] <carlos> but will be still blocked
[12:30] <carlos> I will unblock it once we are able to import it
[12:30] <mvo_> carlos: why is it still clocked?
[12:30] <carlos> mvo_: because the patch is not yet on production
[12:30] <carlos> so we still have that problem
[12:31] <carlos> until the code is actually deployed
[12:31] <asac> pitti: cool
[12:31] <pitti> cu later
[12:31] <asac> cu
[12:32] <mvo_> carlos: aha, ok. I misunderstood that
[12:32] <mvo_> carlos: what talk about languages to import do you mean exactly? I remember you pointed me to a feature request about language-selector for fallback locales, but I do not remember a ddtp discussion
[12:33] <carlos> mvo_: new topic
[12:33] <carlos> mvo_: I saw you are uploading ru_RU.po, sv_SE.po files  and others like that 
[12:33] <carlos> when you shouldn't...
[12:33] <mvo_> I see
[12:34] <mvo_> I will check that
[12:34] <mvo_> that could be a problem with the import script
[12:46] <carlos> mvo_: except for zh_*, pt_BR and en_* you should not use the country code at all
[12:46] <carlos> at least those are the most common that are valid
[12:47] <mvo_> carlos: thanks, I check it
[12:48] <carlos> mvo_: ok, thanks
[12:51] <cjwatson> carlos: is it likely that Rosetta will stop letting people create those at some point?
[12:51] <cjwatson> there's a lot of junk like de + de_DE + de_AT etc. in various templates
[12:51] <cjwatson> which I routinely filter out by eye when doing imports, but that's hardly ideal
[12:51] <carlos> we already prevent them to do it by default
[12:51] <carlos> automatic approvals are not handled in those cases
[12:52] <carlos> and the UI doesn't allow you to create it directly, unless you navigate by hand to its URL
[12:52] <carlos> but kiko wants to remove that too
[12:52] <cjwatson> e.g. https://translations.launchpad.net/ubuntu/feisty/+source/debian-installer/+pots/debian-installer has en_AU, en_CA, en_NZ, en_GB, en_US
[12:53] <carlos> cjwatson: usually, what is there is just because we didn't cleanup old ones
[12:53] <carlos> cjwatson: well
[12:53] <carlos> en_* is allowed
[12:53] <cjwatson> fr and fr_FR, de and de_AT and de_DE, pt and pt_PT, es and es_ES
[12:53] <cjwatson> en_* is the worst of it
[12:53] <carlos> not all of them, but most of them are
[12:53] <cjwatson> especially because the language packs don't currently filter out the msgid == msgstr case
[12:54] <cjwatson> so it takes up an awful lot of unnecessary space on Ubuntu CDs
[12:54] <cjwatson> there are a small number of cases where en_* translations are indeed useful, but they fall victim to translation completism rather badly
[12:55] <carlos> cjwatson: hmm, I guess the problem there is that we are copying it with every new distro opening
[12:56] <carlos> cjwatson: hmm, English should be handled different, I know
[12:57] <carlos> so we only ship msgstr that are different from msgid
[12:57] <carlos> but we don't have yet such feature
[12:57] <carlos> about the others, I will request its removals
[12:59] <carlos> mvo_: btw, now that you talked about language-selector. Should I assume that the change you did to the bug report is because it's something you should fix in language-selector?
[01:00] <carlos> mvo_: just wondering whether I could reject it for Rosetta
[01:06] <mvo_> carlos: its something that l-s can fix, not sure what to do with rosetta
[01:07] <carlos> mvo_: well, if you can fix it quite easily with ln -s we don't need to ask for translations 
[01:07] <carlos> which is a better solution
[01:07] <carlos> mvo_: I'm going to close our task then
[01:07] <carlos> mvo_: thanks
[01:10] <mvo_> carlos: ok, thanks
[01:21] <seb128> Treenaks: around? you were sort of leading the pppoe BOF at UDS, right? ;) Did you write a spec about it?
[01:48] <Mithrandir> doko: is it possible to permanently turn off the OOo recovery thing?
[01:50] <ogra> seb128, is there a gconf-key to adjust the startu notification deay ?
[01:50] <ogra> *delay
[01:50] <ogra> *startup
[01:50] <seb128> ogra: what do you mean by "startup notification"?
[01:50] <seb128> the delay is "until the app start"
[01:50] <ogra> the clock cursor
[01:51] <ogra> no, it switches back on slow systems before the app starts
[01:51] <seb128> no, it runs until the app start
[01:51] <ogra> not here
[01:51] <seb128> that would be a bug then
[01:51] <seb128> how long does it take for your app to start?
[01:51] <ogra> i have about 10 seconds delay until the ff window shows up after the cursor changed back
[01:52] <doko> Mithrandir: hmm, env var OOO_DISABLE_RECOVERY might do it
[01:52] <doko> If set this stops the recovery dialog prompting you as OO.o starts up - instead the recovery files are just silently accumulated.
[01:52] <ogra> (the classmate has a slow flashdisk)
[01:52] <Mithrandir> doko: ok, thanks.
[01:53] <seb128> ogra: libstartup-notification doesn't use gconf anyway, so no
[02:38] <Hobbsee> hi all
[02:41] <zul> cool: http://direct2dell.com/one2one/archive/2007/05/24/15994.aspx
[02:51] <enrico> If, in rc.S, mountkernfs is run before mountall, how can /var/run and /var/lock be mounted properly if /var is mounted from a separate partition?
[02:51] <enrico> This is on feisty, where the network doesn't come up because ifup believes that the network is already up because /var/run isn't mounted from tmpfs but persists from the previous boot
[02:58] <cjwatson_> enrico: the installer ensures that /var/run and /var/lock exist on /, so that they're mounted there
[02:58] <cjwatson_> and then IIRC we do a mount --move trick to preserve them when /var gets mounted
[03:05] <enrico> cjwatson: I see
[03:14] <enrico> cjwatson: indeed recreating those two directories fixed the problem.  You may want to add two explicit mkdirs to mountkernfs, as I'd say that when people move the /var contents to a different partition, they'd tend to remove everything left in it, without suspecting that those two directories are still needed
[03:15] <cjwatson> unfortunately we can't, as / is read-only when mountkernfs runs
[03:15] <cjwatson> or at least may be
[03:21] <Keybuk> I actually have a cunning plan
[03:21] <Keybuk> we can add the mkdirs to the umountfs script instead ;)
[03:21] <Keybuk> or umountroot
[03:21] <Keybuk> so if you shutdown a machine, when /var is unmounted, if the dirs don't exist then, they're created
[03:22] <Keybuk> (before / is made read-only again)
[03:24] <cjwatson> Keybuk: heh, neat idea
[03:35] <keescook> hiya pitti
[03:35] <pitti> hey keescook; early for you
[03:36] <keescook> pitti: indeed.  I drove my wife to the airport early, figured I'd stay up and try to help get the kernel update sorted.  :)
[03:36] <StevenK> keescook: For which release?
[03:36] <keescook> StevenK: yes.  :)
[03:36] <StevenK> Oh.
[03:37] <pitti> keescook: I'm not sure about it either; you got my mail with the log except?
[03:37] <pitti> keescook: cprov wasn't there yet when I left, let's try now
[03:37] <keescook> StevenK: feisty is getting an ABI bump, but not the others.
[03:37] <pitti> keescook: how come that we have so many ABI bumps now?
[03:37] <StevenK> Oh feisty I can deal with.
[03:38] <StevenK> pitti: You can smell those? :-P
[03:38] <pitti> StevenK: very few security patches need to bump the ABI
[03:38] <StevenK> That's a point.
[03:38] <keescook> pitti: funny, I could barely find the security patches in the feisty kernel update.  I think the changelog is 2 pages long.  :)
[03:38] <pitti> and TBH I'd rather avoid smuggling complicated updates into -security, without a proper SRU
[03:39] <pitti> keescook: we should not accept those; they need staging in -proposed even more than the other SRUs we are doing
[03:39] <keescook> yeah, I was really surprised to find that stuff.
[03:40] <StevenK> Gratious kernel changes so the ABI can turn even? :-P
[03:41] <ogra> Mithrandir, why do you disable readahead on the liveCD exactly ? because all ram is already taken or because squashfs preforms badly with it ?
[03:41] <Mithrandir> it blew up with squashfs
[03:42] <ogra> well, on which side ?
[03:43] <ogra> i have plenty of ram in my classmate image, but still use squashfs in the back
[03:43] <Mithrandir> "blew up" as in kernel oops
[03:43] <ogra> ah, k
[03:44] <ogra> but i guess you only tried with tmpfs /cow ?
[03:44] <Mithrandir> tmpfs and real filesystems there, yes.
[03:47] <keescook> it really confuses me to see "cow" as a meaningful file.  I (used to) use it as my "foo"-like temp file name.  :)
[04:09] <mvo> siretart: do you have experience with cryptsetup? I need some help debuging a problem with luksFormat in feisty
[04:11] <tkamppeter> someone has added Plug'n'Print (printer auto-install) to GNOME? See bug 116616. It seems not to recognize whether there is already a print queue.
[04:11] <ubotu> Launchpad bug 116616 in gnome-cups-manager "Cups runs into a printer detection loop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116616
[04:12] <slomo> mjg59: hi... you're aware that your gst-plugins-base patch for the alsa stuff breaks API and ABI? :) imho we should better wait until upstream found a good solution for this... and until now this is still under discussion
[04:15] <siretart> mvo: sort-of
[04:16] <mvo> siretart: in a nutshell luksFormat is not working and I wonder why. opening existing luks device works fine apparently. I get  loads of stat64("/dev/mapper/temporary-cryptsetup-7931", 0xbff94848) = -1 ENOENT (No such file or directory)
[04:16] <mvo> stock feisty
[04:18] <tkamppeter> no one here who knows who has added printer auto-installation to GNOME?
[04:19] <siretart> mvo: I didn't see this, but it looks like a typical device node creation race, which was introduced in feisty
[04:19] <mvo> siretart: wonderful, any idea what I could do to a) debug it further or b) workaround the problem?
[04:20] <tkamppeter> pitti, do you know perhaps from the UDS Sevilla talk who has added printer auto-installation?
[04:20] <pitti> 'added'?
[04:20] <siretart> mvo: that's indeed a good question. in theory, libdevmapper (which cryptsetup hopefully uses) is patched to not create the device node
[04:21] <siretart> mvo: since feisty, there should be some udev rules creating them
[04:21] <siretart> to debug the problem you first need to check if that is correct, and if yes, craft udev rules to create the nodes
[04:21] <tkamppeter> pitti, in Ubuntu up to Feisty nothing happened when I connected a USB printer. I had to call the printer setup tool manually.
[04:22] <siretart> mvo: are you using pitti's script to format an usb stick?
[04:22] <pitti> tkamppeter: right
[04:22] <tkamppeter> pitti, and now (probably Gutsy or some Feisty/Gutsy mix-up) a user reports bug 116616
[04:22] <ubotu> Launchpad bug 116616 in gnome-cups-manager "Cups runs into a printer detection loop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116616
[04:22] <pitti> tkamppeter: and I'm not aware of anyone else working on that
[04:23] <mvo> siretart: I tried both (luksformat and cryptsetup) 
[04:23] <tkamppeter> Unfortunately I cannot see the screenshot of the notification window as librarian seems to be down.
[04:24] <siretart> mvo: that's indeed strange.
[04:24] <siretart> mvo: it looks to me that cryptsetup expects libdevmapper to create the devicenode. Keybuk changed libdevmapper to not do that anymore
[04:24] <tkamppeter> Or did GNOME have plug'n'print all the time, only deactivated by default?
[04:24] <siretart> mvo: so maybe he can help a bit out here
[04:25] <mvo> siretart: thanks, that is quite helpful
[04:25] <tritium> How is /etc/papersize set?  A new feisty install with en_US locale has a4 set, and openoffice insists that I use a4 paper, despite cups and gnome-cups-manager settings to the contrary.
[04:26] <Keybuk> siretart: depends
[04:26] <tritium> (contrary being letter)
[04:26] <Keybuk> siretart: in edgy, devmapper created the devices nodes and udev ignored them
[04:26] <Keybuk> in feisty, devmapper waited for udev to create the devices nodes (spinning in a loop)
[04:26] <cjwatson> tritium: known bug, fixed in gutsy ubiquity
[04:26] <cjwatson> reconfigure libpaper1 to fix it
[04:26] <Keybuk> in gutsy, devmapper creates the device nodes, and udev turns it into a symlink to a device node with better permissions
[04:26] <tritium> cjwatson: great.  Thanks.
[04:26] <cjwatson> bug 104160
[04:26] <ubotu> Launchpad bug 104160 in ubiquity "/etc/papersize incorrecly configured" [Medium,Fix released]  https://launchpad.net/bugs/104160
[04:26] <Keybuk> (the symlink thing may not work if something lstat()s and checks the type *shrug* if so, it can always just make the device node)
[04:27] <pitti> tkamppeter: gnome-volume-manager supports it, but we never set the 'autoprinter' gconf key
[04:27] <pitti> tkamppeter: just because so far we did not have anything sensible to put in
[04:27] <tritium> I wanted to know what to report a bug against, but I guess I don't have to :)
[04:27] <tkamppeter> Note that OpenOffice saves printer defaults per-document, so if you continue on a document with paper size set to A4 it will continue with A4, also if you have changed the paper size option in another document in the meantime.
[04:28] <tritium> tkamppeter: I rarely create openoffice documents.  I mostly open attachments in my email.
[04:28] <tkamppeter> pitti, can it then simply be that the reporter of the bug turned the feature on by himself?
[04:28] <tritium> My hope is to not have to change paper size to letter each time I want to print an attachment.
[04:28] <pitti> tkamppeter: yes, that's likely; a gconftool -R output from the g-v-m settings will let us know
[04:29] <siretart> Keybuk: uuh, that's interesting
[04:29] <siretart> Keybuk: is that somewhere documented, like in UbuntuUdevRoadmap? 
[04:29] <Keybuk> siretart: ?
[04:29] <siretart> because it's very unconvinient to look for all these tiny bits of information from the changelogs of the various packages 
[04:29] <Keybuk> it's documented in UdevMdadmEvmsGutsy or whatever that spec name is :p
[04:29] <tkamppeter> tritium, also imported documents have printer option settings embedded, but I do not know what happens if all print queues of the sender's PC have different names to your print queues.
[04:29] <keescook> gah! failed to start lvm on boot again.  grr
[04:30] <Keybuk> udev roadmap is an ancient spec
[04:30] <Keybuk> in theory, you shouldn't care what happens behind the scenes
[04:30] <ssam> Hobbsee, i asked a few days ago about doing an sru for goffice to fix bug #109204 are you free to ask a few questions?
[04:30] <ubotu> Launchpad bug 109204 in gnumeric "Gnumeric strange colors (purple charts) on bigendian" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109204
[04:30] <Keybuk> since we've tried to preserve the libdevmapper API
[04:30] <Keybuk> (device node exists when the function call returns, WIN)
[04:30] <tkamppeter> Perhaps you should start OOo without any document and then go into "Print" or "Print Setup" to set defaults for new or imported documents.
[04:30] <siretart> Keybuk: in practice, mvo is fighting with cryptsetup to work at all! 
[04:30] <tritium> tkamppeter: thanks.  They're almost always MS docs.
[04:30] <Keybuk> cryptsetup has never worked
[04:31] <Keybuk> IME
[04:31] <Hobbsee> ssam: i'm around, yes.
[04:31] <siretart> it did perfectly in dapper
[04:31] <ssam> Hobbsee, :-) is a private message better than here
[04:31] <Keybuk> other things didn't work in dapper
[04:31] <siretart> and every new ubuntu release broke it more. I couldn't keep up with all the changes ubuntu was doing to udev and devmapper
[04:31] <Keybuk> e.g. HAL seeing devices created by cryptsetup
[04:32] <Keybuk> it's only being broken because we're trying to fix it
[04:32] <Keybuk> and we're messing around with things we don't understand that much
[04:32] <Keybuk> because the people who do understand aren't helping
[04:32] <tkamppeter> tritium, note also that the document itself has a paper size (to set somewhere in the "Format" menu).
[04:32] <Hobbsee> ssam: either
[04:32] <tritium> tkamppeter, cjwatson: dpgk-reconfigure libpaper1, and selecting letter, worked.  MS doc attachments open up with correct printer settings now.
[04:32] <siretart> so the solution is to revert our changes we have no clue about?
[04:32] <Keybuk> no
[04:32] <Keybuk> because that leaves things in a broken state
[04:33] <Keybuk> cryptsetup devices wouldn't be mounted because udev/HAL/upstart would never find out about them
[04:33] <Keybuk> that's what we're attempting to fix
[04:33] <tkamppeter> tritium, can you report a bug against the tool for I18n configuration, setting/changing the locale should do this dpkg-reconfigure libpaper1 automatically.
[04:33] <Keybuk> which requires that udev in some part knows about the device
[04:34] <Keybuk> which requires that we solve the "when does mknod() get called?" race
[04:34] <tritium> tkamppeter: sure, I'll do that.  Thanks for the help.
[04:36] <Keybuk> and once solved, we get lots of goodies
[04:36] <Keybuk> like you can then do lvm on a cryptsetup'd md device
[04:36] <Keybuk> or some such madness ;)
[04:37] <mvo> I would be happy to be able to do it on a regular CF card for now :) I think I give up for now, it just eats too much time
[04:37] <Keybuk> mvo: have you tried in gutsy?
[04:38] <mvo> Keybuk: early this week I did, let me check if I have the latest code
[04:44] <tritium> tkamppeter: which is the tool for I18n configuration?
[04:54] <tkamppeter> Iritium, I do not know, unfortunately, go into the "System" -> "Administration" menu to start it and then look with "ps" for its executable name.
[04:59] <mvo> Keybuk: under gutsy I seem to have the same problem
[04:59] <Keybuk> interesting
[04:59] <Keybuk> ok
[05:00] <Keybuk> let's debug!
[05:00] <mvo> Keybuk: it might be something specific to cryptsetup
[05:00] <Keybuk> what dm-* are in /sys/block ?
[05:00] <mvo> Keybuk: I also run 2.6.20 on gutsy the newer one does not boot for me
[05:00] <Keybuk> kernel shouldn't matter much
[05:01] <Keybuk> also what command(s) are you running, and do you have strace of them?
[05:01] <mvo> Keybuk: no dm-* in /sys/block
[05:02] <mvo> Keybuk: dm-crypt, dm-mod, dm-mirror are loaded
[05:02] <mvo> Keybuk: I use cryptsetup luksFormat /dev/sdc1
[05:02] <mvo> Keybuk: entirely possible
[05:02] <mvo> :)
[05:03] <Keybuk> can you strace that for me?
[05:04] <mvo> Keybuk: sure. I will upload the strace in a moment. I did it earlier and noticed that "ioctl(4, DM_TABLE_LOAD, 0x80b7508)      = -1 EINVAL (Invalid argument)" looked suspicous
[05:05] <Keybuk> oh
[05:05] <Keybuk> are you sure you're running .20 ? :p
[05:05] <Keybuk> that looks a lot like .22 :p
[05:05] <mvo> uname -r tells me 2.6.20-15-generic
[05:06] <Keybuk> interesting
[05:06] <Keybuk> BenC: 2.6.20-15-generic has the bd_claim patch, right?
[05:07] <BenC> yeah
[05:07] <ogra-classmate> BenC: any news on the ralink front ?
[05:08] <ogra-classmate> i got my image nearly ready
[05:08] <BenC> ogra-classmate: was trying to get around to testing the tarball last night, but didn't, so today for sure
[05:08] <ogra-classmate> only the suspend issue, usplash and the wlan driver are missing
[05:08] <ogra-classmate> great
[05:08] <BenC> I think our whole issue may have just been firmware...so I'm trying to see what to do about that
[05:08] <ogra-classmate> do we ship firmware for it ?
[05:09] <ogra-classmate> i didnt see any
[05:09] <BenC> no, that's the problem :)
[05:09] <ogra-classmate> ah
[05:09] <BenC> but it also doesn't use firmware-loader, and has a hardcoded firmware location
[05:09] <ogra-classmate> ouch
[05:09] <mvo> Keybuk: http://people.ubuntu.com/~mvo/tmp/cryptsetup.strace
[05:09] <mvo> Keybuk: the same behvaiour on three machines (two feisty, one gutsy)
[05:10] <Keybuk> mvo: right
[05:10] <Keybuk> that ioctl is the problem
[05:10] <BenC> I can include the firmware, but I need to hack the driver to use a `uname -r` based location
[05:10] <Keybuk> is sdc1 mounted?
[05:10] <ogra-classmate> BenC: ah, right
[05:12] <mvo> Keybuk: it is! and that is the only problem it seems. OMG
[05:15] <cjwatson> tritium: great
[05:16] <cjwatson> tritium: language-selector is the thing tkamppeter is getting at, I think
[05:44] <lamont> pitti: ping
[05:45] <pitti> hey lamont
[05:46] <lamont> pitti: re texlive-bin ftbfs on ia64...
[05:46] <lamont> 1) decide wether or not we want libcairo.la to be part of the development environment
[05:47] <lamont> 2) either remove it from libcairo2-dev and rebuild a few things, or fix dependencies so that libcairo2-dev comes in.
[05:47] <lamont> note that rebuilding a few packages on i386 will trigger this issue there, too.
[05:47] <pitti> lamont: in general we want to get rid of .la files
[05:47] <lamont> right
[05:47] <lamont> libcairo2-dev has libcairo.la, and libcairo2-dev wasn't installed for the build
[05:48] <lamont> and something (/me didn't look which) was built with a current enough libcairo2-dev
[05:48] <Mithrandir> pitti: Any reason not to have something like pkgstriptranslations which cleans .la files, then we can later remove them?
[05:49] <pitti> Mithrandir: seb128 knows more, but I think that there's a cdbs rule somewhere which does that
[05:49] <lamont> fwiw, our bootstrapping of hppa/feisty working towards gutsy ran into this very issue
[05:49] <Mithrandir> pitti: there is, but we don't use it universally
[05:50] <lamont> anyway, that one isn't ia64 specific and I have an urgent boss-task, so I'm gonna disappear
[05:50] <seb128> Mithrandir: that's basically what /usr/share/gnome-pkg-tools/1/rules/clean-la.mk do
[05:50] <pitti> lamont: so we need to find all reverse build depends of libcairo2-dev which are build depends of texlive-bin? sorry, this entire libtool stuff is just black magic to me
[05:50] <seb128> Mithrandir: I'm not sure if .la are useful for some packages though
[05:50] <pitti> lamont: thank you for the heads-up!
[05:51] <lamont> the trivial way is to install all the build deps and then 'grep libcairo.la /usr/lib/*.la'
[05:51] <Mithrandir> seb128: they're useful for static builds.
[05:51] <seb128> right
[05:51] <lamont> then see what package delivered that file
[05:51] <seb128> so we don't want to do it for everything
[05:51] <Mithrandir> but we don't have many of those, and even fewer where something provides .la files for it.
[05:51] <Mithrandir> so we have stuff like sash which depends on.. libc6.
[05:52] <seb128> I've to go, bbl
[05:54] <mvo> pitti: could you please have a look at #116633? a small additon to luksformat, but my perl-foo is weak
[05:59] <pitti> mvo: I'm used to writing "while (<MOUNT>) { die 'bla' if /$device/; }", but if you tested your's, that's alright as well, I guess
[06:00] <pitti> mvo: "$line =~ $device" actually works? I had expected /$device/ to mark it as a regexp
[06:04] <ion_> 0) <MOUNT> is bad, use <$mount> (and my $mount earlier), 1) Perhaps one of $_ eq $device, /\Q$device\E/, (split)[0]  eq $device suits you better (depending on exactly what youre trying to achieve).
[06:08] <ion_> Each of the three examples i pasted do completely different thing.
[06:08] <mvo> pitti, ion_: my perl is pretty bad :) I tested it and it work for me(tm). but I'm more than happy if someone with better perl skilz can update the patch to be more perl-ish
[06:08] <ion_> does
[06:08] <mvo> ion_: the idea is just just check if the $device is in /proc/mounts 
[06:11] <cjwatson> /\Q$device\E/ would be reasonable then
[06:12] <cjwatson> \Q ... \E is a bracketing construct that escapes whatever's inside it to avoid regexp metacharacters in $device being interpreted
[06:14] <ion_> If you want to compare the first column to the string $device, (split)[0]  eq $device
[06:18] <ion_> You could also use Keybuks getmntent.c: getmntent -mq "$device" && echo yeah
[06:26] <Burgundavia> mjg59: ping re: laptop cpu freq oddities
[06:26] <mvo> ion_, cjwatson: thanks! 
[06:27] <mjg59> Burgundavia: Mm?
[06:27] <mvo> ion_: i updated it yet again, hope its better now
[06:28] <Burgundavia> mjg59: busy trying to track down why this bug exists: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/116562
[06:28] <ubotu> Launchpad bug 116562 in linux-source-2.6.22 "celeron M system refuses to scale" [Undecided,Rejected]  
[06:28] <mjg59> Celerons don't scale
[06:28] <Burgundavia> mjg59: my celeron m claims to and apparently does
[06:29] <mjg59> How?
[06:29] <Burgundavia> via the p4-clockmod module
[06:30] <mjg59> p4-clockmod is a net-loss in energy consumption
[06:30] <mjg59> Under almost every single possible circumstance
[06:31] <Burgundavia> http://pastebin.ca/507496
[06:31] <mjg59> Yeah, there's no est bit
[06:31] <mjg59> So no speedstep
[06:31] <mjg59> clockmod drops the frequency, but not the voltage
[06:32] <Burgundavia> ahh, ok
[06:32] <mjg59> Which results in a linear decrease in power consumption, but also a linear increase in time taken to do anything
[06:39] <Keybuk> mvo: if you're writing it in Perl, why are you using regex and not getmntent() ?
[06:40] <mvo> Keybuk: I usually stay away from perl. but I'm happy to use that instead
[06:41] <Keybuk> (Perl having access to the C standard library)
[06:42] <gicmo> Soo, what do I do if (after upgrading to gutsy) my fonts are HUGE, Xorg reports that I have a dpi of (142, 148) and the gnome font dialog says 145
[06:42] <gicmo> but those fonts are WAY to big
[06:43] <mvo> gicmo: lucky you, mine are way too small
[06:43] <ion_> keybuk: I took a quick look at whether perl itself or the POSIX module provides getmntent, with no luck.
[06:43] <gicmo> change to fontsize (currently 10) or tweak the dpi?
[06:43] <ion_> keybuk: No luck with perldoc -q mount or mnt either. I didnt look into it any further, though.
[06:43] <gicmo> mvo: haha ;-) .. well my one look like a almost blind person had set it up
[06:44] <gicmo> on the macpro machine its similar for some fonts
[06:44] <gicmo> but on the laptop, ugh,
[06:45] <gicmo> Setting every font to 8 helps but still not ideal
[06:47] <ion_> Monitors reporting their physical dimensions (so that Xorg can calculate the DPI value automatically) is great. Its a shame all monitors dont do that, and even bigger shame that some monitors lie.
[06:51] <ion_> A new strip about Dell & Ubuntu at ELER. :-)
[06:56] <wasabi> Keybuk: Ya remember that conversation we had at some point about evms/md/lvm and the mess of all of them, and using evms for everything including partitions... what became of that? Did it just disappear because nobody has time to look at it?
[06:58] <wasabi> evms seems to be rather silent lately... as in I guess nobdoy is working with it.
[06:58] <wasabi> upstream-wise
[07:04] <Keybuk> wasabi: evms doesn't even work on plain 2.6
[07:04] <Keybuk> so it's a bit of a moot point really
[07:04] <wasabi> Hmm. Say that again?
[07:04] <Keybuk> evms doesn't even work on plain 2.6
[07:04] <wasabi> I meant with more context. ;)
[07:04] <wasabi> Thought evms was in linus' tree.
[07:04] <Keybuk> it tries to make devmapper devices for existing block devices
[07:04] <Keybuk> e.g. /dev/mapper/sda /dev/mapper/sda1 /dev/mapper/sda2 etc.
[07:04] <wasabi> Yes, it does.
[07:05] <Keybuk> and fails if they're mounted
[07:05] <wasabi> Well, not `sda`, just `sda1`
[07:05] <wasabi> it does the partition mapping in userspace using dm... and yes, it redoes it.
[07:05] <Keybuk> right
[07:05] <Keybuk> and breaks
[07:05] <wasabi> The conversation I seem to remember having at uds-mtv was about using evms for that, and removing the in-kernel support.
[07:05] <Keybuk> because sda is already claimed by the internal partition stuff
[07:05] <Keybuk> and sda1 is already mounted
[07:06] <Keybuk> tbh, given that evms seems undermaintained, and we have almost no expertise in it, that idea scares the shit out of me
[07:06] <wasabi> Which would give the benefit of a default install using DM< and thus being able to migrate a default install to RAID1.
[07:06] <wasabi> Jeff seemed to like that.
[07:06] <wasabi> Yeah. It's looking pretty quiet on that front now... was just wondering what happened with that all. :0
[07:07] <ion_> What benefits does evms have compared to plain md + lvm?
[07:07] <wasabi> ion_: A sane UI and API.
[07:07] <wasabi> Err, s/sane/single/
[07:07] <Keybuk> nobody seems to know evms well enough to really own it
[07:07] <wasabi> Yeah. Seems to be the case.
[07:07] <wasabi> ion_: It uses md and lvm and dm. It provides one API unifying the terms container, segment, and all that jazz... and it comprehends it all for complex operations.
[07:07] <ion_> Alright, thanks.
[07:08] <Keybuk> the fact the evms upstream basically say "la la, don't use 2.6, or apply this patch to revert a kernel feature" is kinda worrying too
[07:08] <wasabi> For instance, it shows you a file system, and lets you resize it, and considers all that is involved. 
[07:08] <wasabi> Whether the FS supports it, online of offline, whether it's mounted, what hte underlying md and lvm stack looks like, and does it all in one move.
[07:08] <ion_> Thats quite nice.
[07:08] <Keybuk> yet is missing a "hey, evms, there's this new block device, do something with it" command <g>
[07:08] <wasabi> It's nothing new, really. It's just comprehensive.
[07:09] <wasabi> Keybuk: Totally. It's probably just waiting for somebody to take ownership.
[07:09] <wasabi> Hell, I don't particularily care if whatever solves the problem even is EVMS... but as I see it it's a pain in the ass to deal with md and lvm seperatly.
[07:10] <Keybuk> yeah
[07:10] <Keybuk> I'm kinda hoping the devmapper stuff in gutsy is gonna work
[07:10] <wasabi> And I think at least the concept of evms is a wonderful idea.
[07:10] <wasabi> Whether the current code base is good, I don't know.
[07:10] <Keybuk> evms sounds like it should be done inside the kernel :p
[07:10] <wasabi> Why?
[07:11] <wasabi> The basic device mapping should be done in the kernel, and is.
[07:11] <wasabi> THe management API, no way.
[07:11] <Keybuk> the whole md/lvm/evms thing seems inelegant to me
[07:11] <Keybuk> it's layers and layers of complexity, built on the kernel block layer
[07:12] <Keybuk> there should be disks
[07:12] <wasabi> There are pieces which should be converted to dm, no doubt.
[07:12] <Keybuk> and there should be filesystems
[07:12] <wasabi> md for instance.
[07:12] <Keybuk> where filesystems span/mirror/stripe across however many disks as necessary
[07:12] <wasabi> zfs-style.
[07:12] <Keybuk> yeah
[07:12] <wasabi> zfs is interesting.
[07:13] <Keybuk> that seems to be the right kind of solution
[07:13] <Keybuk> merge md/dm/lvm/evms into one thing
[07:13] <ion_> That would be nice.
[07:14] <wasabi> Sure. Well, either way... on my systems that use pure EVMS, things run great. I remove lvm and md tools. evms does it all, and it's golden.
[07:15] <Keybuk> wasabi: right, pure-evms works; but mixed evms-and-non-evms is broken because of the bd_claim stuff
[07:18] <wasabi> bd_claim... new stuff to lock a block device?
[07:18] <wasabi> I see.
[07:18] <Keybuk> not exactly new
[07:18] <Keybuk> we've historically patched it out of the kernel to support evms
[07:18] <Keybuk> but the wisdom of patching out a kernel feature to support a program we barely support is questionable
[07:20] <wasabi> So what is hte long term plan for this type of functionality, at least in Ubuntu?
[07:20] <wasabi> That is, a nice UI for doing RAID and various LVM task.
[07:20] <Fjodor> I can't seem to register a bug with launchpad. Is it in trouble, or am I doing something wrong?
[07:21] <Keybuk> there is no long term plan that I'm aware of
[07:21] <Keybuk> or even a short term plan
[07:21] <wasabi> The problem with the current EVMS approach is a subset of users Really Likes It (me) because it is seriously usable. But with support for it waning, we're left with nothing but command line md and lvm tools.
[07:21] <wasabi> Which is certainly a downgrade.
[07:21] <Keybuk> the question is why these users aren't stepping up to help maintain it ...
[07:21] <wasabi> That is a good question. ;)
[07:26] <Fjodor> Anyways, I seem to have hit a bug with gcc-4.1.2 (as shipped with feisty), but since I can't seem to register it on launchpad, would someone be willing to do so instead on my behalf (plus possibly look into it ^-^)?
[07:30] <Keybuk> Fjodor: why can't you register it?
[07:31] <Keybuk> https://launchpad.net/ubuntu/feisty/+source/gcc-4.1/+filebug
[07:31] <Fjodor> Keybuk: Thanks. I just seemed to hit timeout errors...
[07:31] <Fjodor> Trying at this place now
[07:38] <Fjodor> Keybuk: Done. Klose has requested preprocessed code in other similar bugs. Would you happen to know how I make those?
[07:39] <Fjodor> bug 116648 btw
[07:39] <ubotu> Launchpad bug 116648 in gcc-4.1 "internal compiler error: Illegal instruction" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116648
[09:10] <Keybuk> Fjodor: -generic is the correct kernel
[09:10] <seb128> geser: there is a new kiwi upstream version in case you want to update it also ;)
[09:10] <Keybuk> -386 is only for real 386s
[09:13] <ogra-classmate> Keybuk: not really true ... the classmate here (900 mhz celeron) crawls badly with -generic and flies with -386
[09:17] <Keybuk> that's not a real celeron, though, right?
[09:18] <ogra-classmate> well, /proc/cpuinfo doesnt indicate it could be something else
[09:18] <ogra-classmate> model name      : Intel(R) Celeron(R) M processor          900MHz
[09:19] <ogra-classmate> cpu family      : 6
[09:20] <ogra-classmate> the cache size is a joke though, cache size      : 64 KB
[09:25] <geser> seb128: I'll perhaps look at it on the weekend
[09:25] <seb128> cool
[09:27] <Fjodor> Keybuk: I am getting some weird errors here, though. And nothing in dmesg suggesting hardware errors
[09:27] <Keybuk> have you run a memory test?  you can do that from the ubuntu CD
[09:28] <Fjodor> That would be worth trying. Have to get it out of the closet first though. Thanks for the suggestion
[09:28] <Keybuk> (it might be a gcc bug, but it's worth testing other things while you wait for a toolchain maintainer to get to the bug)
[09:29] <Fjodor> Keybuk: Indeed
[09:29] <Fjodor> Thanks
[09:33] <Fjodor> Still going to try the -386 kernel though. IIRC, K6-2 had some very peculiar quirks and inconsistencies that people may have been forgetting about since it's heyday
[09:47] <wereHamster> can someone with wine installed please check if wine uses DT_RPATH? (I don't have ubuntu, so please don't tell me to install it and check myself ;) )
[09:58] <Seveas> wereHamster, try #ubuntu-wine :)
[09:58] <wereHamster> nobody there :(
[09:59] <Seveas> be patient :)
[10:00] <wereHamster> .. will I have more luck in #ubuntu?
[10:01] <ogra-classmate> if -wine == 0 you have 1269 more chances in #ubuntu :)
[10:02] <Keybuk> Mithrandir: see, this bit works
[10:02] <Keybuk> wing-commander scott# hcitool scan
[10:02] <Keybuk> Scanning ...
[10:02] <Keybuk>         00:1A:75:92:A8:B7       Keybuk's W880i
[10:02] <Keybuk> wing-commander scott# rfcomm connect rfcomm0 00:1A:75:92:A8:B7
[10:02] <Keybuk> Connected /dev/rfcomm0 to 00:1A:75:92:A8:B7 on channel 1
[10:02] <Keybuk> Press CTRL-C for hangup
[10:02] <Keybuk> as does this bit
[10:02] <Mithrandir> rfcomm bind is probably what you want.
[10:03] <Mithrandir> and you need a gprs chat script and pppd peers file.
[10:03] <Keybuk> right, that's where I get stuck
[10:03] <Mithrandir> possibly also a username and password
[10:03] <Mithrandir> I can send you mine, no idea if they'd work for you
[10:03] <Keybuk> and don't I want a 3G chat script?
[10:03] <Mithrandir> my phone changes from gprs to 3g and back by itself
[10:04] <Mithrandir> on the fly
[10:04] <wereHamster> another question.. what's the status of DT_RPATH use in ubuntu's packages? is that allowed or deprecated?
[10:06] <Mithrandir> unless you have a good reason to use rpath, avoid it.
[10:07] <ogra-classmate> doko: i'm not registered, cant answer pm ... see bug 116566
[10:07] <ubotu> Launchpad bug 116566 in gcompris "[Sync Request]  gcompris 8.3.1-3 from Debian unstable" [Wishlist,Fix released]  https://launchpad.net/bugs/116566
[10:07] <doko> ogra-classmate: ok, thanks
[10:10] <Mithrandir> Keybuk: http://err.no/tmp/gprs.tar contains my gprs script and my chatscripts.  You probably need to google for the username and password for your provider.
[10:10] <Mithrandir> (I can provide mine, but it won't help you one bit)
[10:11] <Keybuk> it says leave blank
[10:11] <Mithrandir> I think I had to put something there, BICBW
[10:12] <ogra-classmate> Mithrandir: well, if he used the right country prefix he could use your login data :P
[10:12] <Mithrandir> ogra-classmate: that could get expensive.
[10:12] <Keybuk> 	OK		'AT+CGDCONT=1,"IP","internet","",0,0'	\
[10:12] <Keybuk> what does that mean?
[10:12] <ogra-classmate> heh, indeed
[10:12] <ompaul> ogra-classmate, mind if I pm you - given my "status" you can reply to me
[10:13] <Mithrandir> the next line tries to call the gprs profile, AIUI
[10:13] <Mithrandir> *99#
[10:13] <Mithrandir> my phone is a nokia and not SE, though
[10:13] <ogra-classmate> dholbach: two, max three at a time, else i wont get it done with my other work
[10:13] <ogra-classmate> ompaul: pm ogra after the meeting, -classmate isnt registered
[10:14] <ompaul> okay
[10:14] <dholbach> ogra-classmate: I'll add you to the list with two and add something that says that they should be interested in edubuntu
[10:14] <ogra-classmate> (i cant answer from here atm)
[10:14] <dholbach> ogra-classmate: http://wiki.ubuntu.com/MOTU/Mentoring/Mentor
[10:14] <ogra-classmate> dholbach: laserjock is on my list already
[10:14] <dholbach> ogra-classmate: yeah, but he's not a new contributor who wants to become MOTU
[10:14] <dholbach> ogra-classmate: make sure that you have some easy tasks at hand which you can hand out to people
[10:15] <ogra-classmate> right
[10:16] <dholbach> I added you to the list
[10:17] <ogra-classmate> thanks :)
[10:20] <Keybuk> May 24 21:20:34 wing-commander chat[6234] : send (AT+CGDCONT=1,"IP","internet","",0,0^M)
[10:20] <Keybuk> May 24 21:20:34 wing-commander chat[6234] : expect (OK)
[10:20] <Keybuk> :-/
[10:20] <pitti> Seveas: so, with 0.81 I got rid of that [apport]  prefix; I guess that's what you filter on ATM?
[10:20] <Keybuk> that's as far as it gets
[10:20] <pitti> Seveas: it was commonly requested to remove this and replace it with tags
[10:20] <pitti> Seveas: so now it uses apport-<problemtype>, like apport-crash, apport-package, apport-kernel, etc.
[10:21] <Seveas> pitti, please poke some launchpad people to add tags to the RFC822 output of bugs on http://launchpad.net/bugs/bugid_here/+text
[10:21] <Seveas> otherwise I can't filter on that
[10:22] <pitti> depend on what you use; python-launchpad-bugs supports tags
[10:22] <pitti> s/depend/depends/
[10:22] <Seveas> I use only the RFC822 format pages
[10:22] <Keybuk> see, I don't think that rfcomm0 is working
[10:22] <Keybuk> since minicom doesn't help
[10:23] <pitti> hmm, https://bugs.launchpad.net/ubuntu/+bug/116387/+text does not seem to work here
[10:23] <ubotu> Launchpad bug 116387 in Ubuntu "austrian repository mirror broken" [Undecided,In progress]  
[10:23] <Seveas> it only works for /bugs/id/+text
[10:23] <pitti> aah
[10:24] <pitti> Seveas: sweet, I didnt' know about that; right, that needs support for tags
[10:24] <Seveas> pitti, so please poke LP people :)
[10:25] <Keybuk> lesson #1
[10:25] <Keybuk> bind to the right port
[10:26] <Mithrandir> yeah, and occasionally, your phone will switch them around just to confuse you
[10:27] <Keybuk> at+cgdcont?                                                                     
[10:27] <Keybuk> +CGDCONT: 1,"IP","general.t-mobile.uk","0.0.0.0",0,0                            
[10:27] <Keybuk> +CGDCONT: 2,"IP","general.t-mobile.uk","0.0.0.0",0,0           
[10:27] <Keybuk> cool
[10:27] <Keybuk> so the phone already has those programmed into it
[10:27] <Mithrandir> yeah, they're on the sim card or something
[11:13] <Riddell> infinity2: could you give back kdelibs, kdebase, kdegames (ia64), kdeartwork (ia64), kdeutils (ia64), kdeaddons (ia64) and kdegraphics?
[11:13] <Riddell> or, maybe not if you're sick
[11:20] <ogra> ompaul, ?
[11:20] <ompaul> ogra, pm
[11:20] <ogra> shoot
[11:27] <bryce> yay http://www.dell.com/open/
[11:27] <Burgwork> indeed
[11:28] <mc44> and ubuntu.com is a dell advert :)
[11:28] <bryce> I like that the laptops are $200 cheaper than the windows version
[11:28] <Burgwork> I think this attempt mike actually stick
[11:29] <ion_> bryce: Wow. I was afraid that theyd charge the same price.
[11:30] <mc44> shame dell don't point to any ubuntu community support options but instead to their own forums
[11:30] <Keybuk> ?
[11:30] <ion_> Re: Dell and Ubuntu, http://geekz.co.uk/lovesraymond/wp-content/images/ep067.jpg (somewhat offtopic, sorry)
[11:46] <ogra-classmate> enoseb :(
[11:49] <_3oo3> can quispiam relatum mihi ut pizza peruro?
[11:50] <_3oo3> EGO sum unfamiliar per is cella. Quam operor vos utor restruum.
[11:51] <ion_> English, please.
[11:51] <_3oo3> quis?
[11:51] <ion_> Contrary to the common misconception, not everyone on the Internet speaks your native language.
[11:52] <azeem> plus latin isn't very common as a native language these days
[11:53] <ogra-classmate> hehe
[11:53] <mc44> _3oo3 is a troll
[11:54] <ogra-classmate> mc44: but unlikely the most others that seems to be an educated one :)
[11:54] <mc44> ogra-classmate: we have a higher standard of troll in the ubuntu community :D
[11:54] <pochu> mc44: lol :)
[11:54] <ogra-classmate> right *g*
[11:54] <Amaranth> dude is that latin?
[11:55] <pochu> It is.
[11:55] <ajmitch> as said about 5 minutes ago, yes
[11:55] <ajmitch> or some form similar 
[11:55] <Amaranth> if i read everything said on IRC i wouldn't have time for anything else :P
[11:55] <_3oo3> Est illic a channel pro latin orator?
[11:56] <azeem> Amaranth: just ignore everybody but me
[11:56] <_3oo3> mc44: quis?
[11:56] <Keybuk> sodomy non sapiens
[11:56] <_3oo3> Keybuk: quam rudis
[11:57] <_3oo3> est illic a #ubuntu-dev_ln?
[11:57] <ajmitch> if you're that bored, you can translate some stuff on rosetta into latin
[11:58] <pochu> Do we have latin lang-packs?
[11:58] <Burgwork> likely
[11:58] <ajmitch> pochu: yes
[11:58] <ajmitch> the translation is rather incomplete
[11:59] <ogra-classmate> only for cds , iso-latin-1
[12:00] <_3oo3> quare mos nemo succurro mihi?
[12:00] <_3oo3> !
[12:02] <Keybuk> dragostea din tei
[12:02] <_3oo3> Deus Frendo vos omnis!
[12:02] <ion_> Babelfish doesnt support Latin. I want my money back!
[12:06] <ajmitch> amusing