[00:11] <shaya> should bluez stuff be able to handle more than one bluetooth connection at a time?  it seems to have issue with a2dp and a pand network going at the same time
[00:13] <calc> why isn't tar smart enough to autodetect compression type for uncompressing files? it has -a for compressing but it doesn't work for decompressing
[00:14] <directhex> calc, it isn't? i use "tar xvf foo.tar.gz" all the time
[00:14] <directhex> also, *ngh* @ OOo build system
[00:14] <calc> doesn't work for lzma
[00:14] <calc> tar xvf ../ubuntu-8.10-desktop-i386.tar.lzmatar: This does not look like a tar archive
[00:15] <calc> tar: Skipping to next header
[00:15] <directhex> ah, then it's just old & lame
[00:15] <calc> so i end up using tar --lzma -xvf foo
[00:15] <calc> but tar -acvf iirc works with lzma
[00:15] <azeem> maybe it that codepatch just hasn't been tought about lzma yet
[00:15] <azeem> -it
[00:15] <calc> directhex: yep OOo build system is crap, can't be improved until Sun does the right thing
[00:16] <calc> azeem: ah maybe so
[00:16] <azeem> codepath*
[00:16] <azeem> I should stop drinking
[00:16] <azeem> and/or stop listening to Prince
[00:16] <calc> azeem: heh even when sober i often drop entire words, etc ;-)
[00:17] <directhex> calc, i think the configure script they use in ooo-build is hideously broken
[00:17] <directhex> checking for mcs... /usr/bin/csc
[00:17] <directhex> Cannot open assembly '/usr/lib/mono/1.0/mcs.exe': No such file or directory.
[00:17] <directhex> why is it even looking there in the GAC? i forced a given compiler for a reason!
[00:17] <calc> heh, probably
[00:18] <calc> OOo is horrid in general :\
[00:18] <directhex> switch to abiword! imagine the space saved on the livecd!
[00:18] <calc> i am somewhat surprised the mono stuff is broken like that considering Novell wrote that code (afaik)
[00:18] <calc> directhex: heh yea
[00:19] <directhex> calc, they're always cocking up their configure scripts, but that's extra broken
[00:19] <directhex> calc, if a grep doesn't show anything, then surely it must be in a ooo-build/src tarball?
[00:20] <calc> directhex: hmm maybe it is after all
[00:20] <calc> directhex: if so they probably got it merged upstream
[00:20] <directhex> go go gadget bzgrep
[00:20] <directhex> time for anap -_-
[00:20] <calc> directhex: i'm sure Sun didn't write code for Mono though
[00:21]  * calc thinks java and .net should both die, go C go C ;-)
[00:22] <walters> writing entire apps in unmanaged code in 2008 just doesn't make sense
[00:23] <calc> java is just beginning to become run anywhere and last i checked mono isn't very close either
[00:23] <azeem> walters: good thing it's almost 2009!
[00:23] <calc> run anywhere a working RE exists maybe
[00:23] <directhex> walters, how else do we run them on our ARM systems?
[00:24] <walters> directhex: what do you mean?  there are VMs for ARM
[00:24] <directhex> walters, i was more thinking JIT footprint
[00:24] <calc> the java vm for ppc is so bad i can't even get it to compile OOo
[00:24] <azeem> probably mono FTBFS on arm, *duck*
[00:24] <directhex> azeem, fixed in 2.0.1-0ubuntu2
[00:24] <calc> and ppc is not nearly as obscure as many other platforms
[00:25] <directhex> and the exciting new 2,0.1-1 in debian Incoming
[00:25] <TheMuso> calc: How can ppc hardware owners help fix that one up?
[00:25] <walters> directhex: nothing prevents one from having an ahead-of-time cache of managed code -> native
[00:25] <calc> TheMuso: determine why the build fails in java on ppc
[00:26] <directhex> calc, which JRE?
[00:26] <walters> directhex: that's what GCJ does and I think various embedders do use it
[00:26] <calc> directhex: iirc gcj and openjdk both die
[00:26] <calc> directhex: or rather hang forever, the logs are available for review, i had to disable java support which is why it builds now, but without a lot of features on ppc
[00:26] <directhex> huh? i can't find the source of this configure weirdness anywhere!
[00:27] <calc> directhex: should either be in the tarballs or in the configure or in a patch in patches/dev300 (iirc)
[00:27] <calc> directhex: unless it is magic :)
[00:28] <directhex> definitely smells like a bad check in a configure
[00:30] <directhex> ehm..... this patch is sick
[00:31] <TheMuso> calc: When I'm off work in the next couple of days, I'll take a peak if you'd like.
[00:31] <calc> TheMuso: ok
[00:31] <calc> TheMuso: it might just work for you again like before, but if it does that is also a good data point
[00:31] <walters> calc: is debian's openjdk tracking the latest icedtea?  Red Hat has an engineer working on complete zero-assembler for OpenJDK which should remove architecture dependency
[00:31] <calc> walters: not certain, doko works on it
[00:32] <directhex> oh poot
[00:32] <directhex> this is... vile
[00:32] <calc> directhex: any program that has its own version of make i think qualifies as vile ;-) which OOo does
[00:32] <directhex> calc, srsly, whoever thought this was the right way to make a patch needs a slap
[00:32] <calc> along with KDE, X (or used to?), etc
[00:32] <directhex> calc, most sun apps do. ever heard of gridengine?
[00:33] <directhex> +                       AC_PATH_PROG(MCS, mcs)
[00:33] <directhex> +                       test -z "$MCS" || CSC_PATH=`dirname $MCS`
[00:33] <directhex> +               MCS="$CSC_PATH/mcs"
[00:33] <directhex> spot the problem
[00:33] <calc> oops :)
[00:33] <calc> should be MCS="$CSC_PATH/$MCS"
[00:33] <calc> i think?
[00:34] <calc> or basename $MCS
[00:34] <azeem> directhex: I thought Sun bought gridengine from somewhere, though
[00:34] <azeem> mabye not
[00:35] <directhex> calc, or just $MCS"
[00:36] <directhex> calc, it should not override it! why would it use an overridable AC_PATH_PROG and then undo any changes you make, unless it's *mad*
[00:36] <calc> dirname $MCS would indicate that the full path is in $MCS
[00:36] <directhex> azeem, nah, not in recent memory. we've run SGE for dinkeys years
[00:36] <directhex> donkeys
[00:36] <directhex> dinkeys too if you like
[00:37] <calc> directhex: yea it sounds crazy, feel free to send me a patch and i will get it into ooo-build
[00:37] <directhex> calc, has this file changes in 3.0? i'm working against 2.4.1 from current jaunty
[00:37] <calc> directhex: oh which file is it, i can check
[00:38] <TheMuso> 8/c
[00:38] <directhex> calc, well i'm looking at patches/mono/mono-build.diff - but i'm assumig that's the one being applied
[00:38] <directhex> there's also -m16 and -m17
[00:39] <calc> directhex: i think it is still the same (at least more or less)
[00:39] <calc> its a pretty long bit of code but i still see:
[00:39] <calc> +               if test "z$CSC_PATH" = "z"; then
[00:39] <calc> +                       AC_PATH_PROG(MCS, mcs)
[00:39] <calc> +                       test -z "$MCS" || CSC_PATH=`dirname $MCS`
[00:39] <directhex> in theory this just needs the line removing:
[00:39] <directhex> +               MCS="$CSC_PATH/mcs"
[00:40] <directhex> let me check further down
[00:41] <directhex> nah, mono-climaker-config seems less foolish
[00:42] <calc> well it looks like it is rewriting the path for MCS there
[00:42] <calc> so it probably needs to be MCS="$CSC_PATH/`basename $MCS`"
[00:42] <directhex> calc, it rewrites the path for MCS to `dirname $MCS`
[00:42] <calc> unless they are redoing it entirely for crack reasons
[00:43] <calc> hmm yea
[00:43] <calc> oh its using the path to setup AL properly i think
[00:43] <directhex> which is fine
[00:43] <directhex> i approve of setting al
[00:43] <calc> so yea MCS doesn't need to be done at all
[00:44] <directhex> well... assuming 'al' is a 2.0 al on mono 2... i think it is...
[00:45] <directhex> al:exec /usr/bin/mono $MONO_OPTIONS /usr/lib/mono/2.0/al.exe "$@"
[00:45] <directhex> yes. so, believe it or not, OOo would break when building on mono 2.0, if we DIDN'T do this transition
[00:46] <directhex> as it uses 'al' (for compiling CLI assembly) from CLI 2.0, but the 'mcs' compiler from CLI 1.0
[00:46] <directhex> you don't need to know this stuff, mind. raof dos, but he's special
[00:47] <raof> Yay!
[00:47]  * RAOF is special
[00:48] <calc> directhex: heh
[00:49] <directhex> calc, i'm trying another test build, with that one line removed (and the diff indexes lowered a little accordingly, assuming i remember my diff-fu)
[00:49] <directhex> even just 'debuild' takes ages with ooo, let alone the pbuild
[00:50] <calc> yep
[00:50] <calc> directhex: i use ccache to make it somewhat reasonable
[00:50] <RAOF> That'd be substantially faster if you didn't clean the tree, right?
[00:50] <calc> takes it down to 1hr build after cached
[00:51] <RAOF> (And assumed that they've got their makefile dependencies correct)
[00:53] <directhex> broken makefiles is the problem!
[00:53] <directhex> :p
[00:53] <directhex> Need to get 0B/261MB of archives. After unpacking 916MB will be used.
[00:53] <directhex> obscene :x
[00:53] <directhex> and people call mono bloated
[00:54] <Riddell> calc: KDE has its own make?
[00:55] <directhex> yeah. it's one of those damned apps with a "k" in the name. "make" i think!
[00:57] <calc> Riddell: isn't it called cmake or something like that?
[00:57] <calc> Riddell: i might be misremembering as i don't work with it anymore
[00:57] <directhex> dpkg-source: info: applying openoffice.org_2.4.1-11ubuntu4.diff.gz
[00:57] <directhex> here it goes again
[01:00] <calc> Riddell: perhaps they were just threatening to write their own make/build system?
[01:00] <directhex> here it goes. configuring
[01:00] <directhex> configuring some more
[01:01] <directhex> wait... it configures twice before even unpacking _src_core ?
[01:01] <directhex> o_o
[01:01] <calc> maybe, don't remember what all it does, heh
[01:01] <directhex> mono might win on 'number of binaries from 1 source package', but OOo wins for 'batguano insane'
[01:02] <Riddell> calc: cmake is a build system, it converts files into make, it's not kde specific.  automake does the same but is way more ugly especially on !gnu
[01:02] <directhex> i backported cmake once
[01:02] <directhex> i think wodim uses it?
[01:02] <Riddell> yes
[01:03] <directhex> my memory rocks, or i'm really sad.
[01:03] <calc> Riddell: ah ok
[01:04] <directhex> patched without error. configuring...
[01:04] <directhex> checking for mcs... /usr/bin/csc
[01:04] <directhex> checking for gmcs... /usr/bin/csc
[01:04] <directhex> checking for mkbundle2... /usr/bin/mkbundle
[01:04] <directhex> configure: mono is up-to-date enough - building mono climaker
[01:04] <directhex> thank $DEITY
[01:05] <calc> cool! :)
[01:05] <directhex> i'd better let this build finish as a sanity-check, but i think that was the missing link
[01:05] <directhex> a little slice of wtf from novell
[01:06] <calc> heh
[01:06] <calc> i'm surprised they haven't fixed it for mono 2 already themselves
[01:06] <directhex> consistency has been an issue with that upstream for a while
[01:08] <directhex> had a nice one today from iulian - his app "giver" has been correctly patched for the mono transition, yet somehow is still not using the right compiler..... seems configure ignores the compiler you give it, makefiles have 'gmcs' hardcoded whatever you do
[01:09] <calc> fun
[03:19] <hyperair> pitti: regarding bug 292256, there is an upstream bug filed already (see bfo 18461), but i can't seem to find anywhere to link it back to launchpad.net
[03:23] <kirkland> bryce: sorry about not using a patch system ...  there wasn't one in place, so i just applied directly
[03:24] <bryce> kirkland: yeah adding a patch system is a bit more involved ;-)
[03:26] <bryce> kirkland: for reference, here's the snippets from my packaging notes on adding patch systems:  http://pastebin.ubuntu.com/77006/
[03:26] <bryce> in this case I followed the notes on quilt, and it worked without issue
[03:41] <kirkland> bryce: right
[03:51] <psusi> pitti: was wondering if you had any thoughts on my response to your message on dev-discuss about permissions and removable media, or if you just tuned it out due to low s/n ratio
[03:58] <ScottK> psusi: Please note that pitti work on European time, so it's the middle of the night for him right now.
[03:58] <ScottK> work/works
[04:07] <psusi> ScottK: ahh that's right... well, maybe he'll see it in the morning and I'll talk to him tomorrow
[04:09] <psusi> would be nice to get rid of those annoying permission problems with removable media without telling people to use fat so as to avoid the issue.
[04:16] <jdong> oh god this is such a hack....
[04:16] <psusi> lol
[04:16] <jdong> trying to make a pseudo-magical 32-bit and 64-bit system
[04:16] <jdong> mainly through the use of schroot and bindfs (FUSE) :)
[04:16] <psusi> don't we have one of those by now?  I thought someone has been working on that since like fiesty?
[04:17] <jdong> passing through 32-bit or 64-bit executables based on a whitelist and whether the requester is 32-bit or 64-bit
[04:17] <psusi> damn... what do you need all that for?  I thought there was a spec with a sane way to do it
[04:17] <jdong> there is?
[04:18] <jdong> I sure haven't found it.
[04:18] <psusi> something like having ld.so choose either a 32 or 64 bit search path depending on the executable
[04:18] <jdong> it's for things like if I want to run 32-bit firefox but have 32-bit firefox start up 64-bit evince
[04:19] <jdong> currently I just use dpkg selections to mirror the 32-bit and 64-bit environments to be pretty similar
[04:19] <psusi> yea, I swear someone was working on implementing a spec to just let you install normal 32 bit packages on a 64 bit system and run them
[04:19] <jdong> hmm I've heard nothing about that for at least 3 release cycles now.
[04:19] <jdong> I've seen plenty of ugly hacks like getlibs.
[04:19] <psusi> and this was like, back in feisty I remember talking to someone about it
[04:19] <jdong> which seeminly just hack apart the deb and sed installpaths into lib32....
[04:20] <jdong> I tried to critize it for being ridiculously hackish but ended up being flamed to death by 64-bit junkies.
[04:20] <jdong> grumble.
[04:20] <psusi> hehe
[04:22] <psusi> well I thought the idea was to patch dpkg to fix the install paths to use the *32 versions, and handle the depends properly so it installs the 32 bit version of the depends, then patch ld.so to notice when it is being asked to load a 32 bit image and link against the *32 libs instead
[04:25] <viviersf> cjwatson, ping
[04:27] <psusi> jdong: so you're debootstrapping a 32 bit chroot and instaling the 32 bit versions of packages there?
[04:27] <psusi> now who was it that was working on that before?  tolef?
[04:28] <psusi> yea, I think it was tfheen
[04:28] <TheMuso> viviersf: He is not around now. Just make your statement/ask your question and he will get back to you when he is around.
[04:28] <jdong> psusi: yeah that's what I'm doing.
[04:29] <psusi> jdong: yikes.... that sounds horrid ;)
[04:29] <jdong> psusi: meh mostly just a waste of space and administration hassle
[04:29] <jdong> it's primarily to give skype a more 32-bit like home, and also give firefox a better chance of not crashing every other flash page.
[04:30] <viviersf> TheMuso, cool
[04:30] <TheMuso> jdong: well if the 64-bit flash plugin improves, that shouldn't be a problem re firefox.
[04:31] <jdong> TheMuso: that's a big if.
[04:31] <viviersf> cjwatson, do you know why an ubuntu install with a live cd and an ubuntu install via kickstart would be different, if the kickstart does do the @ubuntu-desktop in the %packages section
[04:31] <psusi> jdong: ask Mithrandir about it some time, I think he's the one who was working on that iirc and it sounded like he had a plan that wasn't a total kludge ;)
[04:32] <jdong> psusi: hey! you haven't seen my kvm + X forwarding plan yet!
[04:32] <jdong> version 2.0 is a lot less kludgy than version 1.0 ;-)
[04:33] <psusi> jdong: x forwarding?  why should X need any special handling?  it shouldn't make any assumptions about the word size on the other end of the connection
[04:34] <jdong> 32-bit apps are run in a virtual machine with a separate copy of X :)
[04:34] <jdong> a bit of session manager glue brings them together
[04:36] <psusi> oh my god, why?
[04:36] <jdong> before I figured out schroot and dchroot existed :)
[04:36]  * psusi recoils physically from that
[04:38] <psusi> so how is this better than having sed replace paths in the 32 bit package? ;)
[04:38] <jdong> lol it's not :)
[04:38] <psusi> lol....
[04:38] <jdong> well you can argue it's better since it's technically two unsoddomized Ubuntu installs.
[04:38] <jdong> just bridged together via a remote-desktopping solution :)
[04:39] <jdong> but I won't try to argue that :)
[04:39] <psusi> I'd argue that's an incestuous relationship and shouldn't be allowed ;)
[04:39] <jdong> I'd be inclined to agree :)
[04:40]  * psusi wonders why schroot suggests lvm2
[04:41] <jdong> probably because of its COW modes?
[04:41] <psusi> oh weird
[04:42] <jdong> apparently it with sbuild results in some mighty-fast builds :)
[04:42] <psusi> could be nicer than the tar approach pbuilder uses though
[04:43] <jdong> absolutely
[04:58] <psusi> fabbione: is ornellas.apanela.com/dokuwiki your wiki?  I'm trying to read an article there linked to from the ubuntu wiki and it looks like it's been spammed all to hell
[05:02] <fabbione> psusi: nope.. not mine
[05:09] <psusi> I swear there was a multiarch spec and now I can't find it
[05:09] <psusi> s/spec/blueprint
[05:09] <fabbione> i am pretty sure there is one
[05:09] <fabbione> not sure how up-to-date it is tho
[05:10] <fabbione> but it should be on the main wiki
[05:10] <fabbione> it was done by Mithrandir afair
[05:10] <fabbione> and doko
[05:10] <fabbione> but I might be mistaken.. it's been too long since I looked at that stuff
[05:10] <psusi> fabbione: that's what I thought
[05:11] <psusi> and I thought their idea did not involve a chroot
[05:11] <psusi> the only stuff I can find on the subject now is all about having a whole 32 bit system in a chroot
[05:11] <fabbione> i don't think it does involve chrooting at all
[05:12] <fabbione> that's the whole point of multiarch :)
[05:12] <ScottK> Doesn't Debian have mutliarch?
[05:12] <ScottK> mutli/multi
[05:13] <psusi> I dunno.... I assumed that since jdong was mucking around with a way of doing it that Mithrandir never finished it
[05:14] <fabbione> not that I know off (debian multiarch)
[05:20] <fabbione> psusi: i can only find a few references here and there
[05:20] <fabbione> psusi: i think Mithrandir was working with Debian for that goal..
[05:21] <fabbione> http://wiki.debian.org/multiarch
[05:21] <fabbione> that's the closest thing I can find
[05:27] <psusi> fabbione: that's what I thought too, but that was a long time ago... looks like it was forgotten about
[05:29] <psusi> wow, yea, according to that Mithrandir and sjr were working on that back in '04 and
[05:29] <psusi> '05
[05:31] <psusi> jdong: fabbione found this, which has some good info for you in the morning: http://wiki.debian.org/multiarch
[05:39] <fabbione> psusi: i suggest you talk to Mithrandir in a few hours :)
[05:39] <fabbione> i am really not into multiarch
[06:28] <dholbach> good morning
[06:32] <dholbach> can you guys please update https://wiki.ubuntu.com/TeamReports/November2008 for your teams? thanks :)
[06:32] <mathiaz> dholbach: I had a question related to the TeamReports - what's done with them?
[06:34] <dholbach> mathiaz: the most obvious thing: they're available and this time Nick Ali is going to highlight them on the fridge/planet/ubuntu weekly news
[06:34] <dholbach> mathiaz: I think it's great to show the world (and another teams) what kind of stuff you've done
[06:34] <mathiaz> dholbach: good. How does that tie into the Ubuntu News suggestion from james_w ?
[06:34] <dholbach> also does it show that the team is healthy
[06:34] <mathiaz> dholbach: oh yes - I agree with you. I think it's a good thing to do.
[06:35] <mathiaz> dholbach: I just found that there weren't really advertised much.
[06:35] <dholbach> mathiaz: you're right
[06:35] <dholbach> mathiaz: interesting question regarding UbuntuDevelopment/News
[06:36] <dholbach> mathiaz: I'll talk to James about it
[06:36] <mathiaz> dholbach: to me it looks very similar
[06:37] <mathiaz> dholbach: the same processes to gather input could be the same
[06:37] <dholbach> mathiaz: I think there's different audiences, the monthly report is also not useful if you want to give people a headsup of a transition or something
[06:38] <dholbach> mathiaz: but I agree, it'd be nice if there's not too many wiki pages and too many different processes for this
[06:38] <dholbach> brb
[06:39] <Hobbsee> dholbach: there's going to be a topic at UDS about it, FYI
[06:45] <Hobbsee> or at least, part fo it will be allocated to that.
[06:47] <Hobbsee> james_w: I wonder if it's worth having a separate session for the news
[06:48]  * Hobbsee is avoiding studying prolog again, incidently, but only for a bit
[06:49] <ScottK> Hobbsee: I think the News is something someone ought to just DO.  I don't think it needs a bunch of meetings an paperwork.
[06:51] <Hobbsee> ScottK: that's a point - but how's it best done?
[06:51] <ScottK> I'd say whoever actually does some work gets to decide.
[06:51] <pitti> Good morning
[06:52] <Hobbsee> hey pitti!
[06:52] <pitti> TheMuso: eww, they are using *tdb* for sample caching? sigh, what's wrong with a simple hashtable...
[06:53] <pitti> TheMuso: losing sample caching would really be bad, let's not do that
[06:54] <pitti> TheMuso: I just wonder why instead of hashtable, sqlite, or bdb, they had to pick tdb of all things...
[06:54] <StevenK> Maybe they're trying to impress Tridge
[06:55] <pitti> hyperair: right, because there is no pm-utils project in LP; I'm going to create it
[06:55] <TheMuso> pitti: Take it up with Lennart. :)
[06:56] <pitti> hyperair: done
[06:57] <dholbach> Hobbsee: great
[06:57]  * pitti hugs Hobbsee
[06:58]  * Hobbsee hugs pitti back :)
[07:05] <hyperair> pitti: okay i'll go link the upstream bug
[07:05] <pitti> hyperair: already done
[07:05] <hyperair> oh
[07:05] <hyperair> okay thanks =)
[07:05] <pitti> hyperair: if you click on "also affects project" and the project doens't exist yet, you can click on "register", give it a name and short description, and then it will be there
[07:05] <hyperair> i see
[07:06] <hyperair> i never knew
[07:24] <dholbach> asac, fta: what about the thunderbird task of bug 190688? will you merge the fix in bzr and upload it to jaunty?
[07:25] <dholbach> it's in the sponsoring queue for a while now :)
[07:32] <tjaalton> are there any known security bugs that can't be exploited due to hardened default compiler settings in Ubuntu?
[07:32] <kees> tjaalton: probably :)
[07:33] <tjaalton> kees: hehe, you should know right?-)
[07:33] <kees> tjaalton: well, I'd like to spend the time to research every one, but I haven't had time.  but basically, there have been a few lately that we've lowered in priority because they're "just" a DoS instead of a working overflow, for example.
[07:34] <kees> tjaalton: are you looking for anything in particular?
[07:35] <tjaalton> kees: if you noticed my blog post on the planet, the reason why I'm asking is that I need to know how big a risk it is to open a (linux) server with 20000 user accounts to the world
[07:35] <tjaalton> and how to diminish it
[07:35] <kees> tjaalton: I'm about 8 hours behind on planet reading (it's almost midnight for me)
[07:35] <kees> tjaalton: 20k shell accounts?
[07:35] <kees> tjaalton: or service accounts (imap, etc)?
[07:36] <tjaalton> kees: yes, or maybe 18k but anyway
[07:36]  * kees whistles
[07:36] <tjaalton> :)
[07:36] <tkamppeter> pitti, good news for you, see bug 292690, you will soon be able to print with SpliX 2
[07:36] <kees> I would say you're brave to have 18k shell accounts on one machine, regardless of the security risks.  :P
[07:37] <kees> tjaalton: well, my basic "simple" advice is to run 64bit and make sure you've got a CPU with a functioning "nx" bit.
[07:37] <tjaalton> kees: well, we've had them for years, and on Real unices they've been local, in this case behind ldap
[07:37] <tjaalton> kees: yep, that's the plan
[07:38] <kees> local users can DoS the crap out of eachother unless there are sane resource limits and quotas.
[07:38] <kees> if you're running a webserver on it, you may be in for a world of hurt.
[07:38] <tjaalton> no, only ssh
[07:39] <tjaalton> and the current servers do have some limits on them, so that'd be ported for sure
[07:40] <kees> tjaalton: I'll never say you're 100% safe, but running Intrepid on 64bit with nx puts you in a very good place.
[07:41] <tjaalton> kees: how about hardy then? we got some SELinux expertise, so that could be used as well
[07:42] <kees> tjaalton: if you go hardy and you can tune up a workable SELinux policy, you should be quite happy too.
[07:42] <kees> tjaalton: the SELinux infrastructure should work just fine in Hardy.
[07:43] <kees> tjaalton: intrepid's selinux seems to have a few packaging bugs.
[07:43] <tjaalton> kees: ok, thanks.. I think this makes me feel cozy for the time being :)
[07:43] <kees> tjaalton: :) \o/
[07:44] <tjaalton> fwiw, we have ~180 workstations that are open to the campus network
[07:44] <tjaalton> would be a nice chance to harden them as well
[07:57] <lool> hi there
[08:33] <tkamppeter> pitti, in some seconds splix_2.0.0~rc2-0ubuntu6 will appear (I have uploaded it now). Please test it on your printer to see whether the garbage of bug 292690 goes away. Thanks.
[08:46] <pitti> tkamppeter: cool, will do!
[08:49] <tkamppeter> pitti, I can also load the same fix onto intrepid-proposed, it is already prepared, I only need to upload it.
[08:50] <pitti> tkamppeter: if you are unsure, I can test it first, otherwise please go ahead
[08:51] <tkamppeter> pitti, here we go, it is uploaded.
[08:52] <tkamppeter> pitti, the fixes are identical, either both work or both fail.
[09:06] <tkamppeter> pitti, splix has arrived in the -proposed queue now.
[09:35] <viviersf> Mithrandir, is it possible to boot casper over the network ?
[09:35] <Mithrandir> viviersf: it doesn't know how to find the ISO over the network, iirc
[09:40] <viviersf> Mithrandir, :( ok, that would be really cool tho
[09:40] <Mithrandir> yeah, somebody should implement that
[09:40] <viviersf> then one does not need to use kickstart
[09:40] <viviersf> cos the install time would be much faster
[10:00] <cjwatson> viviersf: those are two radically different installation methods so there's lots of room for differences. What exactly is different for you?
[10:01] <cjwatson> you should be able to boot casper over the network nowadays, I think, but it's a very lightly-tested installation path so it might only work in 8.10 not 8.04
[11:31] <ogra> tjaalton, * Make libdrm-dev depend on libdrm-intel1.
[11:31] <ogra> where is libdrm-intel1 supposed to come from ?
[11:31]  * ogra doesnt see it anywhere
[11:33] <Hobbsee> debian experimental, apparently
[11:35] <ogra> ah
[11:36] <Hobbsee> Source package is drm-snapshot, but that doesn't seem to be in ubuntu either
[11:36] <tjaalton> ogra: uh, libdrm should build it :)
[11:36] <StevenK> It didn't
[11:36] <tjaalton> right
[11:37] <tjaalton> since it's not mentioned on the control file
[11:37] <ogra> yeah, doesnt look like its n the binary list
[11:38] <tjaalton> I'll fix it shortly
[12:06] <tkamppeter> pitti, any news with your printer?
[12:06] <pitti> tkamppeter: not tested yet, just finished conf call and before that a presentation; I'll report back to the bug once I tested it
[12:52] <tkamppeter> pitti, can you upload the curtrent BZR state of CUPS into Debian and Jaunty and then SRU bug 271350?
[12:53] <tkamppeter> Currently all PowerPC users cannot print at all with Intrepid and Jaunty.
[13:29] <tjaalton> could an archive admin push the new libdrm through so that xserver 1.5.3 could build?
[13:36] <asac> doko: can you please bump build score for tbird 2.0.0.18 ... so we see if armel build is fixed?
[13:37] <doko> asac: was already building
[13:39] <asac> oh
[13:42] <ogra> asac, https://launchpad.net/+builds/kahikatea
[13:43] <asac> thx ... found it
[13:45] <asac> sigh ... finished "inbox" processing ... next bugmail: 8000 unread :(
[13:45]  * asac pushes that back till tomorrow :/
[14:13] <pitti> tkamppeter: can do; this morning I moved the previous cups SRU to -updates
[16:07] <cjwatson> pitti: is the Schedule section on http://summit.ubuntu.com/uds-jaunty/ supposed to be invisible to those without admin access?
[16:07] <cjwatson> (brought over from #ubuntu-meeting)
[16:07] <pitti> cjwatson: ATM yes, according to Scott, since it's still preliminary
[16:08] <cjwatson> pitti: is there a timeline for making it public, perhaps with a note that it's still a draft?
[16:09] <cjwatson> pitti: it would be useful for team members to be able to see at least what's been scheduled, even if the times are still in flux
[16:09] <pitti> cjwatson: I don't know whether it's possible to add such a note, but we can publish it without any problem, should we wish to do so
[16:09] <pitti> right, I agree
[16:10] <pitti> cjwatson: better now?
[16:11] <pitti> I can't test it myself, since I always get auto-logged in as pitti
[16:11] <cjwatson> me neither, asked others
[16:11] <mvo> nothing new for me
[16:11] <cjwatson> might need to log out and back in?
[16:12] <pitti> I set it to "published", which is what Scott told me
[16:13] <cjwatson> apparently it works with URL hacking; good enough
[16:13] <pitti> how so?
[16:36] <MacSlow> how can I revert/undo a bzr commit?
[16:36] <MacSlow> is this possible at all?
[16:37] <james_w> MacSlow: "bzr uncommit" if it was the last
[16:37] <james_w> if you've already pushed then you it will complain next time you try to push
[16:37] <MacSlow> james_w, just found it thanks
[16:38] <MacSlow> already everything fixed again *phew*
[16:39] <tkamppeter> pitti, great to haer that your printer finally works with SpliX 2.
[16:39] <pitti> tkamppeter: the foomatic GDI driver always did, but now splix does again, too
[16:59] <cjwatson> mvo: oh, chdist (in devscripts) might be able to do this
[17:01] <james_w> mvo: something else I've been meaning to bring up in a meeting, but forgot to add to the agenda. When I was in Lex Cody asked whether it would be possible to install the apt https transport by default?
[17:02] <mvo> james_w: sure, I think we just did not do it because of the libcurl-gnutls dependency
[17:02] <mvo> but it should be no problem
[17:03] <james_w> libcurl3-gnutls says "Task: minimal"
[17:04] <cjwatson> doko,mvo: yeah, chdist is exactly the tool we need here
[17:04] <cjwatson> chdist -a armel create jaunty-armel
[17:04] <cjwatson> # edit .chdist/jaunty-armel/etc/apt/sources.list
[17:04] <cjwatson> chdist apt-get jaunty-armel update
[17:04] <cjwatson> chdist apt-get jaunty-armel install <package>
[17:04] <cjwatson> obviously you won't *actually* be able to install it
[17:04] <mvo> cjwatson: nice
[17:09] <cjwatson> I'm fixing initramfs-tools uninstallability on armel
[18:14] <psusi> pitti: ping
[18:25] <pitti> psusi: quick pong
[18:28] <psusi> pitti: hey... was wondering if you had any thoughts on my reply to your post on devel-discuss about the permissions on external drives, or if you just tuned it out due to low s/n
[18:28] <psusi> the thread appears to have died out
[18:29] <pitti> psusi: the bindfs option sounds quite promising, but I haven't ever tried that myself
[18:29] <psusi> pitti: I think we can just do it with the uid= and gid= options
[18:30] <pitti> however, being FUSE it can potentially decrease performance quite severely?
[18:30] <psusi> yea... seems overkill for this
[18:30] <pitti> psusi: we do already for vfat and ntfs, but there aren't such options for ext3 and hfs
[18:30] <jdong> pitti: I use bindfs here to run my 32-bit chroot for my 64-bit machine, performance seems acceptable
[18:30] <pitti> jdong: do you have some numbers?
[18:31] <jdong> pitti: I don't have any on hand
[18:31] <psusi> pitti: right.... did you see my reply to you?  about 2 years ago I modified the arguments to the udf filesystem to make more sense and allow more flexability... maybe we just need to make ext3 and hfs behave the same way, and modify the mount options a bit, possibly adding a nice gui checkbox to toggle them
[18:31] <jdong> I even use it to pass through pbuilder and I haven't really noticed much of a performance impact
[18:31] <jdong> I guess I can try to get some solid numbers :)
[18:32] <pitti> jdong: maybe with dbench or postmark or so
[18:32] <psusi> jdong: did you see the message I sent you last night after you went to bed?  there was a good page of info on Mithrandir's old efforts for multiarch not using chroots and all that jazz
[18:32] <pitti> doesn't need to be rock-solid science, but it'd be intersting whether it's 1% or 50%
[18:32] <jdong> psusi: yeah, I was reading that.
[18:32] <pitti> psusi: yes, as soon as the kernel actually supports those options for ext3 (with an "override" semantics instead of a "fallback", as in vfat), we can easily adapt userspace to cope
[18:33] <pitti> anyway, I need to leave for Taekwondo
[18:33] <pitti> cu tomorrow!
[18:33] <psusi> o/
[18:33] <psusi> looks like I need to get kernel hacking then
[19:10] <slangasek> so after all the trouble that went into getting gnome-panel to do weather by default, why has it recently stopped working for me?  GNOME upstream changed their mind, or did the NOAA decide they couldn't handle the load from all the Ubuntu users? :)
[19:10] <slangasek> I guess the former, since it seems to correlate with the last time I added a location, and the location chooser no longer semes to integrate with airport codes
[19:12] <ogra> or portland did stop having weather
[19:12] <lool> slangasek: I guess you mean in 2.25?  I saw vuntz mention some patches weren't integrated in trunk and were only in 2.24, but I thought these were only translations
[19:13] <slangasek> ogra: all the cities I have listed appear to have stopped having weather
[19:13] <lool> Hmm looks like the same upstream version in intrepid and jaunty
[19:13] <ogra> well, thats positive, at least no bad weather anywhere then :)
[19:13] <slangasek> lool: still in 2.24 on intrepid, not 2.25
[19:14] <lool> (no 2.25 anyway)
[19:14] <lool> slangasek: You upgraded to 1:2.24.1-0ubuntu2.1?
[19:14] <slangasek> meh, there's been plenty of bad weather here, and now I've become accustomed to being able to check my panel for the temp :)
[19:14] <slangasek> lool: 2.24.1-0ubuntu1; where's that other version from?
[19:14] <lool> gnome-panel | 1:2.24.1-0ubuntu2.1 | intrepid-updates | source, amd64, i386
[19:14] <slangasek> oh, gnome-panel
[19:14] <slangasek> I was looking at libgweather, hang on
[19:15] <lool> Could as well have been libgweather
[19:15] <ogra> -pane or -applets :)
[19:15] <ogra> *panel
[19:15] <slangasek> yeah, that's the version of gnome-panel I have
[19:18] <lool> I get this problem too in intrepid
[19:18] <lool> With gp 1:2.24.1-0ubuntu2.1
[19:18] <lool> But not in Debian sid, so it's not the weather service
[19:19] <lool> There's this in my .xsession-errors:
[19:19] <lool> (gnome-panel:8726): Gdk-WARNING **: /build/buildd/gtk+2.0-2.14.4/gdk/x11/gdkdrawable-x11.c:878 drawable is not a pixmap or window
[19:19] <lool> Not sure whether it's new
[19:19] <lool> slangasek: Downgrading to intrepid's gp fixes the issue for me
[19:19]  * lool reupgrades
[19:20] <lool> No, probably just a delay, after an upgrade it works
[19:20] <lool> slangasek: So it was blank upon login; I had the time to downgrade and kill gnome-panel, got weather almost immediately, then upgraded again, killed gnome-panel, got weather info
[19:21] <lool> That said, a) I have a slow dsl (really slow right now) b) I have issues with squid on boot, so the first panel start might have been unconclusive
[19:21] <slangasek> hrm, so should I try downgrading & restarting?
[19:21]  * lool logs out
[19:22] <lool> now confirms that the xorg bug isn't due to his .gnomerc and reboots
[19:23] <lool> (I have this odd Xorg bug where Xorg seems to come up fine, I see the mouse on the screen, but then the session never starts...)
[19:24] <lool> ohhh
[19:24] <lool> +(WW) intel(0): ESR is 0x00000001, instruction error
[19:24] <lool> +(WW) intel(0): Existing errors found in hardware state.
[19:27] <lool> slangasek: So it was definitely my local squid; restarting it and gnome-panel and I have weather
[19:27] <lool> slangasek: Does killall gnome-panel help in any way?  You see any net traffic?
[19:27] <lool> slangasek: BTW I have portland configured
[19:27] <ogra> so he could simply ask you then
[19:31] <slangasek> lool: well, killing gnome-panel brought up all the weather, doh
[19:31] <slangasek> lool: possible that if gnome-panel doesn't find the server on start-up, it caches the negative result?
[19:32] <slangasek> (i.e., no network when the panel started)
[19:36] <lool> slangasek: That was my case, but I don't know how often it retries getting the weather
[19:36] <slangasek> lool: somewhere on the order of 5-15 minutes, I don't remember exactly which; my session has definitely been up for much longer than that :)
[19:37] <lool> slangasek: Might be a bug that there's no retry if it can't fetch on startup
[19:37] <lool> I don't know the code at all
[19:37] <lool> You do!  :)
[19:38] <slangasek> I don't know the code /that/ well :)
[19:38] <slangasek> but yeah, I'll look into it 'n' stuff
[19:42] <lool> slangasek: BTW didn't reproduce that hang since I disable bluetooth after startup
[19:42] <lool> I fear it's going to be really hard to hunt
[19:42] <slangasek> lool: hmm, ok
[19:43] <lool> It's clearly kernel stuff, and it looks so suspiciously similar to the cmpc bug
[19:43] <slangasek> lool: fwiw, Friday night I was getting reports of the same sort of hang from Thinkpad users with non-Intel wireless, too
[19:43] <slangasek> in fact, bluetooth seems to be one of the few components the systems have in common
[19:43] <lool> So I actually have two bugs; one which is just plain hang, and another one which is a hang with the panic leds blinking
[19:43] <lool> The former looks like it's bluetooth related
[19:43] <slangasek> (mako's work Thinkpad)
[19:44] <lool> One thing I could try is leaving the bluetooth dongle plugged on my desktop intrepid system
[19:44] <ogra> lool, the cmpc has no BT
[19:44] <lool> ogra: The model hanging had bt
[19:45] <ogra> oh
[19:45]  * ogra is out of cmpc dev for to long apparently
[20:01] <slangasek> james_w`: why did you subscribe u-m-s to bug #207150?
[20:02] <slangasek> james_w`: the people who've followed up to the bug all appear to be core-dev :)
[20:54] <mitsuhiko> friend of mine just managed to trash grub by resizing partitions from inside windows (grub error 17)
[20:54] <james_w`> slangasek: I was just working through the list of bugs with patches, and it seemed like the quickest way to handle it I guess
[20:54] <mitsuhiko> are there ways / ideas how to prevent grub from totally crashing in that situation?
[20:54] <mitsuhiko> for dual boot users that's pretty annoying i could imagine
[20:55] <slangasek> asac: I thought there was a bzr branch somewhere for firefox-3.0?  was looking at bug #270477 in the sponsorship queue, and I don't see any Vcs fields on the source package but I'm hesitant to upload such a small change on its own directly
[20:55] <slangasek> james_w`: ah - well, I've unsubbed u-m-s now, on the grounds that there doesn't appear to be anyone needing a sponsor... perhaps ScottK or doko just need a prod, instead?
[20:56] <james_w`> likely
[21:03] <asac> slangasek: fix committed to 3.0 and 3.1 development branches
[21:15] <ScottK> james_w or slangasek: I'm suffering from a deep lack of context here.  Need prodding on what?
[21:15] <james_w> ScottK: I just commented in the bug
[21:15] <james_w> ScottK: it's an old debdiff you posted that hasn't been commented on
[21:15] <james_w> bug 207150
[21:17] <ScottK> james_w: Yeah.  I wasn't core-dev at the time I submitted that.  I'd rather leave it to doko as it's a rather small thing for an upload.
[21:17] <ScottK> And I'm reasonably sure I don't care to be TIL for python-central.
[21:21]  * slangasek grins
[22:25] <fta> what happened to the "multiarch" initiative ?
[22:26] <Mithrandir> fta: people got bored
[22:26] <fta> really?
[22:26] <slangasek> where "people" == "Mithrandir"? :)
[22:26] <slangasek> I never got bored, just distracted ;)
[22:27] <Mithrandir> slangasek: well, or that
[22:29] <fta> that would have helped me for chromium :(
[22:29] <slangasek> it would help for lots of things
[22:30] <slangasek> currently, the toolchain status is in a weird state of "binutils says the patch doesn't belong here and nobody has figured out where to shove it in gcc"
[22:30] <slangasek> and package management patches are all over the place
[22:31] <fta> worth a talk at uds ?
[22:33] <slangasek> fta: I would be interested; I suspect that we've already filled our plates for jaunty, so it would probably be a blue-sky session
[22:36] <NCommander> hola world
[22:37]  * RainCT glances at NCommander 
[22:37] <NCommander> did something self-destruct while I've been offline?
[22:38] <fta> slangasek, i'm going through the blueprints.. i would love to see multiarch tracked, so it doesn't slip through more cycles than necessary
[22:38] <RainCT> NCommander: should it? :)
[22:38] <slangasek> kirkland: I see you followed up to bug #277517 suggesting testing via ppa; I think for lpia that if the package builds with the lpia-targeted gcc then it ought to be fine, and persia represents that kvm is supported on ia64 - maybe this would be an ok change to dump straight to the archive?
[22:38] <slangasek> NCommander: nope, all the destruction has been externally imposed
[22:39] <slangasek> fta: if you have the energy to chase this up and keep it on the radar, I would definitely welcome that - what multiarch lacks most of all is someone who can act as a driver for it
[22:40] <NCommander> slangasek, what can I do to fix it?
[22:40] <NCommander> I can do test building of kvm on ia64
[22:40] <slangasek> NCommander: fix what?
[22:40] <NCommander> sladen, the destruction that was externally imposed
[22:40] <NCommander> e,r slangasek
[22:41] <slangasek> oh, does it need fixing?
[22:41] <slangasek> I thought it was all the good kind of destruction
[22:41] <james_w> I prefer a certain level of unfixed descruction
[22:41] <james_w> and a certain level of poor spelling
[22:41] <slangasek> anyway, one thing you can do is act on my follow-up to the linux-atm sponsorship request :)
[22:41] <NCommander> slangasek, yes my lord and master :-)
[22:41]  * NCommander sees if he can debootstrap a sid chroot
[22:42] <NCommander> I'm sorta stuck in a dialup wonderland
[22:52] <directhex> OOo3 Mono transition patch written *properly* and tested
[22:53] <directhex> that's 10 hours i won't ever get back again
[22:53] <directhex> (and that's only compile time, doesn't count failed test builds)
[22:54] <TheMuso> directhex: ouch.
[22:55] <directhex> TheMuso, it's an I/O intensive build... on a laptop...
[22:56] <TheMuso> directhex: Even more ouch.
[22:57] <directhex> a fast new laptop, but still only a little spinny disk
[22:57] <directhex> pig to build, tbh
[23:06] <pochu> directhex: hey, you should try PPAs ;)
[23:06] <pochu> they're really fast
[23:06] <directhex> pochu, i think people would swoop in and stab me through the brain if i tried repeatedly to do a 10-hour, 15-gig build like OOo
[23:06] <directhex> pochu, that and LP is lame and has no debian support
[23:07] <pochu> oh, if it's for debian...
[23:07] <pochu> but I've heard PPAs are idle most of the time, so probably noone would complain ;)
[23:08] <NCommander> Huh?
[23:08]  * NCommander returns
[23:08] <rlaager> pochu: Plus, PPAs are limited to 1 GB, aren't they?
[23:09] <pochu> rlaager: for source and binaries, not for space during the build
[23:09] <directhex> the patch is un-intrusive outside my domain, so it should apply fine to 3.0.0-4ubuntu1
[23:09] <directhex> but honestly, i cannot be arsed to test it on there. 3.0.0-4 is enough
[23:12]  * cjwatson hugs his new 'debi --upgrade'
[23:13] <TheMuso> 8/c
[23:13] <ion_> What’s it do, as opposed to e.g. aptitude safe-/full-upgrade?
[23:13] <cjwatson> ion_: nothing to do with that
[23:13] <slangasek> wow, I've never seen this before
[23:13] <ion_> Heh, alright.
[23:13] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506663
[23:14] <slangasek> "debpkg -i"?  this is like, alternate-universe package management?
[23:14] <cjwatson> the redirection through debpkg is silly, but it's otherwise useful
[23:14] <directhex> Thanks. Will commit to ooo-build.
[23:14] <directhex> Grüße/Regards,
[23:14] <directhex> René
[23:15] <directhex> okay, OOo3 improves :)
[23:25] <ScriptRipper>  NCommander Hi