[00:25] <TheMuso> calc: Do you know where I may be able to find a PPS file with audio, so I can test bug 298494?
[00:33] <TheMuso> Or anyone else? ^^
[00:33] <[Relic]> is anyone else alive, or are they all bots like pitti :)
[00:34] <TheMuso> [Relic]: I'm alive.
[00:38] <calc> TheMuso: the one in the bug report doesn't work?
[00:40] <TheMuso> calc: Oh there is one in the bug? Haven't looked at the bug in that much detail yet. Thanks.
[00:42] <calc> ok np
[02:28] <TheMuso> calc: Am I correct in deducing that openoffice now uses gstreamer for its audio output?
[02:34] <calc> TheMuso: yes
[02:36] <TheMuso> calc: Right, well that audio stutering with pps bug is very weird, because openoffice doesn't seem to be respecting the settings from the sound preferences applet.
[02:36] <TheMuso> I get audio stutter whether I use OSS, alsa or pulseaudi in those settings. Examining open devices from a terminal, when I have oss selected, no oss device node is being used what soever.
[02:36] <TheMuso> Only alsa nodes get used.
[02:37] <TheMuso> So I am not convinced its an audio infrastructure bug.
[02:37]  * TheMuso will update the bug in a bit when I've done a bit more testing.
[02:38] <calc> ok well it might not be after all, i just thought it might be since he claimed it worked previously
[02:39] <calc> feel free to bounce it back to openoffice.org with that info added to the report :)
[02:40] <TheMuso> calc: Ok will do.
[02:42] <wasabi> hmm. at some point UDF vols stopped auto mounting.
[02:42] <wasabi> it's trying iso9660 first and succeeding.
[05:58] <dholbach> good morning
[06:29] <vhaarr> Hey, what does "SRU" and "FFE" mean? I see these abbrevations in some bugs on launchpad, for example.
[06:29] <Hobbsee> !sru
[06:29] <Hobbsee> !ffe
[06:29] <Hobbsee> ^
[06:30] <vhaarr> ffe == uvf?
[06:30] <Treenaks> vhaarr: no, FFE is exception to the freeze
[06:30] <vhaarr> ah
[06:30] <vhaarr> thank you
[06:31] <vhaarr> is jaunty in feature freeze at the moment?
[06:33] <StevenK> vhaarr: No
[06:34] <vhaarr> why is it that nvidia-graphics-drivers-180 is stuck in https://launchpad.net/ubuntu/jaunty/+queue then, does it still need some sort of "initial approval" since it's a new package?
[06:37] <vhaarr> ah, I should probably be in #ubuntu-motu with these questions
[06:37] <vhaarr> apologies for spamming the devel channel
[06:43] <Hobbsee> vhaarr: yes
[06:44] <Hobbsee> @ initial approval
[06:44] <vhaarr> righty, thanks
[08:09] <fabbione> soren: ping?
[08:19] <soren> fabbione: wazzup?
[08:20] <fabbione> soren: hey.. do you still maintain kvm/libvirt stuff?
[08:20] <soren> fabbione: Yes.
[08:21] <fabbione> soren: when you have time, can you give me a crash course on how to setup libvirt networking?
[08:21] <fabbione> soren: I am fighting with bridges and stuff that I am not very familiar with
[08:21] <soren> Sure.
[08:21] <soren> fabbione: With bridging, it's really quite simple. Do you have a bridge setup already and just want libvirt to use it?
[08:22] <fabbione> soren: i only have the default installation (hardy)
[08:22] <soren> Alright.
[08:22] <fabbione> soren: basically i want the guests to access the real network directly
[08:22] <soren> Right.
[08:22] <fabbione> soren: not via all that NAT stuff
[08:22] <NCommander> hey apachelogger
[08:22] <fabbione> soren: and make that permanent
[08:23] <soren> fabbione: Could you put your /etc/network/interfaces on a pastebin? I can make the changes there and you can see what I did. That's lots easier than explaining it.
[08:23] <NCommander> Well, you could just set it up to use IPv6 ...
[08:23] <fabbione> soren: sure thing.. sec
[08:24] <fabbione> soren: http://www.fabbione.net/interfaces
[08:25] <soren> fabbione: I presume it's the bond0 interface you want to bridge to?
[08:25] <fabbione> soren: well that's connected to the real net.. so yeah
[08:28] <soren> fabbione: Any particular reason you're not using the "slaves" directive in your interfaces file?
[08:28] <soren> (for setting up the bonding)
[08:29] <fabbione> soren: not really
[08:29] <soren> fabbione: Ok. We can fix that afterwards :)
[08:29] <fabbione> soren: i didn't even know ifup did grow bonding support :)
[08:29] <fabbione> soren: <- very very old school
[08:29] <fabbione> soren: it doesn't really matter as long as it works
[08:30] <soren> fabbione: Ok, for the really simple, general case: http://people.ubuntu.com/~soren/interfaces-example.txt
[08:31] <fabbione> soren: looking
[08:32] <fabbione> soren: well i doubt there is network manager installed on the server
[08:32] <fabbione> it's not a desktop + kvm thingy
[08:32] <soren> So, for your setup it, this should probably work: http://people.ubuntu.com/~soren/fabbione.txt
[08:32] <fabbione> it's a decent _real_ server :)
[08:32] <soren> Just leave that bit out, then :)
[08:33] <soren> fabbione: This one should deal with the bonding as well: http://people.ubuntu.com/~soren/fabbione-even-better.txt
[08:34] <fabbione> eheheh
[08:34] <fabbione> soren: one thing I am not sure I understand
[08:34] <fabbione> soren: the bond will not get the ip address
[08:34] <soren> Hm?
[08:34] <fabbione> (sec)
[08:35] <soren> Oh, I think I know what you mean..
[08:35] <soren> The bond0 interface no longer gets an ip address. Only the bridge interface does.
[08:35] <fabbione> ah ok
[08:35] <soren> That's the way it works.
[08:35] <fabbione> so i also need to make sure the bridge will get the same mac address
[08:36] <soren> IIRC, the bridge assumes the numerically lowest MAC address of the interfaces attached to it.
[08:37] <soren> ...so it doesn't change over time, if that's what you mean.
[08:37] <fabbione> ok perfect :)
[08:37] <fabbione> yeah
[08:37] <fabbione> that's what I was looking for
[08:37] <soren> Ok, so now you've got a bridge.
[08:38] <fabbione> ok just a sec.. customer on the phone
[08:38] <soren> To hook a virtual machine into that, you put <interface type='bridge'><source bridge='ifbr0'/></interface>  in your domain XML definition.
[08:38] <soren> ...and that's it.
[08:39] <soren> fabbione: sure, take your time.
[08:39] <fabbione> thanks :)
[08:48] <RAOF> wgrant: I'm sure you'll be overjoyed to hear that syndaemon in Jaunty fails to work with a BadDevice error.
[08:51] <fabbione> soren: re
[08:51] <fabbione> ok... testing fancy-interface-file-from-soren
[09:00] <soren> fabbione: First: Does the host's network still work?
[09:00] <fabbione> soren: you need to add auto bond0 otherwise the bridge can't bind
[09:00] <fabbione> soren: i am fixing bits and pieces :)
[09:00] <fabbione> soren: bond0 needs to be UP
[09:00] <fabbione> now.. i am testing again.. one sec
[09:00] <fabbione> soren: this is that kind of testing that I hate the most.. "if the server reboots.. will it work?"
[09:01] <soren> fabbione: Ah, yes, good point on the bond0.
[09:01] <fabbione> soren: and this thing has something like 10 pages of POST before you get to grub
[09:01] <soren> fabbione: Yikes. What is it?
[09:01] <fabbione> soren: Dell Poweredge 2900-III
[09:02] <fabbione> soren: decently equipped
[09:02] <soren> Yeah, it must be :)
[09:03] <fabbione> ok
[09:03]  * soren -> coffee
[09:03] <fabbione> ifbr0     Link encap:Ethernet  HWaddr 00:1e:c9:eb:2a:1c   inet addr:192.168.1.7  Bcast:192.168.3.255  Mask:255.255.252.0
[09:03] <fabbione> works :)
[09:04] <soren> \o/
[09:04] <fabbione> soren: enjoy your coffee...
[09:04] <fabbione> soren: i still need to pick your brain a bit :)
[09:05] <soren> Sure thing. Just shoot.
[09:09] <fabbione> soren: ok.. host networking works fine now
[09:37] <asac> doko_: armel seems to have built fine. Thanks a bunch!
[09:39] <NCommander> doko_, do you know why there seems to be no implicate cast from float to double? (or via versus I suppose, since that works on i386)
[09:39] <NCommander> (on arm)
[09:52] <glatzor> morning james_w, do you arrive at sfo?
[09:53] <glatzor> james_w, if so we could share a taxi, since I would arrive three minutes after you
[10:01] <tseliot> Riddell: you're the archive admin today, aren't you?
[10:02] <Riddell> tseliot: I would be if I wasn't on holiday
[10:02] <Riddell> tseliot: what do you need?
[10:02] <tseliot> Riddell: can you see nvidia-glx-180 in NEW?
[10:03] <tseliot> (Jaunty)
[10:03] <Riddell> tseliot: yes
[10:04] <tseliot> Riddell: good. Can you accept it, please?
[10:04] <Riddell> into restricted presumably?
[10:04] <tseliot> yes
[10:05] <tseliot> BTW it makes KDE4 usable with nvidia cards
[10:05] <tseliot> :-)
[10:06] <Riddell> yay
[10:06] <Riddell> accepted
[10:06] <tseliot> Riddell: thanks a lot
[10:11] <NCommander> hey Riddell
[10:12] <Riddell> morning NCommander
[10:12] <NCommander> how goes it Riddell?
[10:13] <Riddell> NCommander: lovely thanks, currently enjoying the hospitality of the Kubuntu Stuttgart Office
[10:14] <NCommander> o_O?
[10:15] <NCommander> Riddell, I'm working on running down the all evil pyKDE4 arm bindings FTBFS
[10:15] <NCommander> bah
[10:15] <Riddell> brave man
[10:17] <NCommander> I can't figure out where its choking
[10:17] <NCommander> If its the Python-C API, QT, bindings, or sip
[10:17] <NCommander> :-/
[10:17] <NCommander> Are we the only distro with KDE4 and an ARM port?
[10:17] <Riddell> NCommander: there's Debian experimental
[10:18] <Riddell> NCommander: have you tried asking Sime?
[10:18] <NCommander> who?
[10:18] <Riddell> pykde maintainer
[10:18] <NCommander> armel doesn't appear to have an experimental buildd ...
[10:18] <Riddell> NCommander: on IRC as Sime_
[10:19] <NCommander> hrm
[10:20] <james_w> glatzor: I do, that would be great
[10:21]  * directhex wonders if ScottK tried to catch up with him again after ~11pm yesterday
[10:22] <lool> NCommander: Hmm the error in the build log seemed pretty clear, did you get past that one?
[10:22] <NCommander> lool, it's not clear
[10:22] <NCommander> lool, its FTBFS on a generated file
[10:22] <NCommander> (that file is generated by the KDE python binder lexer AFAIK)
[10:22] <NCommander> I'm hoping once I get a chance to fully look through the lexers output I can see whats going wrong
[10:23] <NCommander> As far as I can tell from the build log, it LOOKS some stupidity w.r.t. to float/double on ARM
[10:23] <NCommander> (man, ARM is picky about its floating points)
[10:24] <NCommander> Since this issue with float/doubles seems to only happen in KDE and Qt, I'm thinking its Qt specific vs. some bug in GCC
[10:25] <glatzor> james_w, yeah, great. Do you have got a credit card? have already reserved a taxi?
[10:25] <NCommander> I'm hoping/praying its just something in the input sip file I can change to clear the build failure right up
[10:25] <NCommander> (although knowing my luck)
[10:26] <james_w> glatzor: nijaba is arriving at the same time as well, I haven't, but I don't know if he has
[10:27] <nijaba> glatzor: no, I haven't booked a cab, but there generally is no need to do so, plenty are waiting there.  I do have a cc
[10:28] <NCommander> man, my external is making death noises
[10:28] <NCommander> But its working fine
[10:28] <NCommander> ...
[10:28]  * NCommander wonders how long until it fails
[10:28] <nijaba> glatzor: we are you flying in from? International?
[10:29] <glatzor> nijaba, I will fry from London to SF with UA995
[10:29] <glatzor> fly
[10:29]  * NCommander wants to share a cab if possible
[10:29] <nijaba> glatzor: I certainly hope you won't fry ;)
[10:30] <glatzor> :)
[10:30] <glatzor> james_w, nijaba: have you ever been to sf? where is good place to meet?
[10:30] <nijaba> glatzor: ok, so we'll join at custom exit in the international terminal
[10:31] <nijaba> glatzor: about a 100 times.  If you do not find me, I might be outside getting stoned from a first cigarette in about 12h
[10:43] <NCommander> lool, so I found the FTBFS
[10:43] <NCommander> and its ugly
[10:44] <NCommander> Real ugly
[10:45] <NCommander> But it does explain why Qt is a miserable pile of exceptions on ARM
[10:46] <lool> NCommander: I think I'd file it under sip
[10:47] <NCommander> lool, its a bug in kdelibs
[10:47] <lool> NCommander: What did you find?
[10:47] <NCommander> Under normal cirmstances, qreal is a typedef on double
[10:47] <NCommander> But on Windows CE, and ARM its a float
[10:47] <NCommander> kdelibs has a few cases where it explicately assumes double and ...
[10:48] <NCommander> The hardcoded doubles need to be changed to qreal in kdelibs, AND in kdebindings
[10:48] <NCommander> (unless we want to change Qt on ARM and then transition Qt's rdepends)
[10:48] <lool> NCommander: Well are you sure they intended qreal and not double?
[10:48] <NCommander> lool, http://pastebin.ca/1273380
[10:48] <NCommander> lool, QList<double> in the source :-)
[10:48] <NCommander> If we change it to QList<qreal>, it would make the assignments work properly
[10:49] <ogra> are you sure it gets the QT_ARCH_ARM properly handed over ?
[10:50] <NCommander> ogra, yeah, qreal becomes a float
[10:50] <NCommander> I think that check exists because ARM's FPU performance kinda sucks
[10:50] <NCommander> But there is no comment explaining it :-/
[10:50] <lool> NCommander: My question is: are you sure they want to handle qreals and not doubles; it's the same question for QList<double> versus QList<qreal>
[10:51] <NCommander> I'm not sure I'm following
[10:51] <NCommander> QList is simply a container
[10:52] <NCommander> lool, http://paste.ubuntu.com/79246/ - this is the generated code its choking on
[10:52] <lool> NCommander: level 1) qreal is defined to foo or bar depending on various conditions; we could look into this, perhaps armel's qt is using doubles or other projects, and that would make our life simpler; level 2) kdelibs might be using qreal and doubles for various things; perhaps it calls into other APIs or simply wants double in some places
[10:52] <NCommander> Its two function calls that use double vs. qreal, I think its an isolated fluke that just didn't get catched. Since the behavior is the same on all architectures expect ARM ...
[10:53] <lool> level 3) sip generates code from kdelibs (AIUI) but doesn't handle some cases of type mistmatches
[10:53] <NCommander> Qt's docs recommend you use their own types over C's to prevent fun mistakes like this
[10:54] <NCommander> As a general rule of thumb, I don't like changing library APIs like QTs, and we'd break binary compatbility with Qt on other ARM systems if we changed qreal to double
[10:54] <NCommander> (not that we really care, but ...)
[10:54] <lool> NCommander: Sure, but you might have to use other types for various reasons; perhaps it's truly wrong to use double, perhaps it's not?
[10:55] <lool> NCommander: TBH I don't know how much binary compatibility there is for running qt bits on arm platforms
[10:55] <ogra> heh
[10:55] <NCommander> Chanigng qreal's type would break it
[10:56] <NCommander> Personally, I'm against changing a core library against Qt unless there is a serious reason to do so
[10:56] <lool> NCommander: Well by changing double to qreal in kdelibs, you'd break kdelibs binary compatibility as well anyway
[10:56] <NCommander> lool, no it won't
[10:57] <NCommander> qreal == double on !ARM
[10:57] <NCommander> ABI doesn't change
[10:57] <lool> It doesn't change on !ARM
[10:57] <lool> and !WINCE
[10:57] <NCommander> Considering KDE doesn't compile on ARM ... :-)
[10:57] <lool> You want to avoid an ABI change on ARM with an ABI change on ARM
[10:57] <NCommander> O_o?
[10:57] <NCommander> oh
[10:58] <NCommander> I perfer smaller ABI changes
[10:58] <lool> Anyway, I think we're being distracted
[10:58] <NCommander> yeah
[10:58] <NCommander> The question is do we file a bug with the Qt devs, or a bug with the KDE guys :-)
[10:58] <NCommander> (there a compile time arguements to force qreal to double on ARM it seems)
[10:58] <lool> Best would be to check what others are doing for qreal (1), and whether upstream kdelibs thinks of this (double -> qreal)
[10:59] <lool> These are in fact orthogonal and we can solve both
[10:59] <NCommander> Well, I found the note on why this was done in Qt
[10:59] <NCommander> Doubles eat performance for lunch on ARM
[10:59] <lool> Which ARM?  with vfp?
[10:59] <ogra> which arm ? :) i heard v7 behave differently
[11:00] <NCommander> We technically target v5, with v7 optimized libraries
[11:00] <NCommander> and we're softfloated, unless we have an optimized library, VFP isn't used on ARM
[11:01] <ogra> using the VFP of the v7 will definately be in our focus
[11:01] <NCommander> Well, to get the VFP used, optimize specific binaries and libraries which would benefit
[11:01] <NCommander> We'll have to figure out a way to give dpkg a brain for this case
[11:01] <NCommander> (I think we need subarchitecture support in dpkg/apt TBH, but for another time)
[11:02]  * ogra didnt say it would be easy ... or happen right now :)
[11:02] <lool> NCommander: I think I care most for being compatible with Debian on this particular point of ABI anyway
[11:02] <lool> So let's check whether Debian's qt is patched for armel and live with the same for Ubuntu's armel qt
[11:02] <NCommander> Good idea
[11:02]  * NCommander ventures to Debian's source packages
[11:03] <lool> NCommander: In all cases, why wouldn't we want to fix sip to handle this gracefully?
[11:04] <NCommander> lool, its not a bug in sip.
[11:04] <lool> NCommander: Are you subscribed to the upstream kdelibs lists and all?  Perhaps you want to bring this up there
[11:04] <NCommander> lool, anything trying to use these APIs would have caused a similar issue I think
[11:05] <lool> NCommander: You're saying sip can't handle API's mixing doubles and qreal?
[11:06] <NCommander> lool, I don't think its a bug in sip. the API and qreal should always match if you want compability with Qt types
[11:06] <NCommander> sip can't be blamed if the author ignored the user friendly typedefs
[11:06] <lool> NCommander: What if I need to pass doubles and qreals to two sub APIs?
[11:06] <NCommander> We're dealing with the return type here of a template
[11:07] <ScottK> directhex: No.  I didn't gry to get ahold of you again.  I ran into a related problem that's nothing to do with the mono transition and got stuck. I suspect, but cannont yet prove, that adjusting the build-dep as you suggested is sufficient for the transition.
[11:08] <NCommander> lool, Debian doesn't change Qt's behavior
[11:16] <lool> NCommander: yup
[11:16] <lool> I checked the headers and the patches and didn't find any such change either
[11:16] <lool> (and it does set QT_ARCH_ARM)
[11:16] <NCommander> lool, Debian hasn't run into the issue on the virtue they still use KDE3
[11:17] <NCommander> lool, so now what :-)?
[11:18] <asac> doko_: do you maintain all java packaging in a svn repo? or are there packages that i just need to upload if i want to extend those Xpp- headers?
[11:18] <lool> NCommander: Well we eliminated level 1 from the equation
[11:18] <lool> NCommander: you filed level 2
[11:18] <NCommander> o_o?
[11:18] <NCommander> level 1/2? huh?
[11:21] <NCommander> lool, well, beside KDE, I think the ARM port is fairly good in main
[11:21] <NCommander> (universe is another story)
[11:22] <lool> NCommander: levels: see discussion we had earlier here?
[11:24] <NCommander> lool, nope
[11:24]  * NCommander has been MIA over a week
[11:24] <NCommander> lool, well, I looked deep within the sourcecode of kplotaxis.cpp, and its just a return of an internal variable
[11:25] <NCommander> which boils down to a         QList<double> m_MajorTickMarks, m_MinorTickMarks;
[11:25] <lool> NCommander: ?
[11:25] <NCommander> No, I'm finding the code in kplotpoint that we're considering changing to qreal after upstream guidance
[11:25] <NCommander> I'm seeing what it does specifically :-)
[11:25] <lool> NCommander: By "earlier" I meant a couple of hours earlier, not days
[11:26] <lool> NCommander: /lastlog level
[11:26] <NCommander> ooooh
[11:26] <NCommander> handy IRC command!
[11:27]  * NCommander looks for KDE's SVN repo
[11:27] <NCommander> Time to create a proposed patch now that I know what needs editing
[12:14] <Silicium> hi there
[12:15] <Silicium> i want to create a custom installer CD, this works fine with getting the packages from a external repository
[12:15] <Silicium> now i want to add the custom packages to the local CD Repository
[12:16] <Silicium> should i create a own new repository or should i merge my packages into the exist hardy repo?
[12:18] <asac> slangasek: can you take a look at network-manager-pptp SRU in -proposed. has been pending for a while and all bugs fix committed have verification-done. thanks
[13:44] <doko_> asac: "all java packaging" ?
[14:00] <asac> doko_: all java plugins ;)
[14:01] <hwilde> anybody an ssh port forwarding expert
[14:02] <hwilde> i've got all these leftover sshd's waiting for an EOF that netcat will never send...
[14:04] <doko_> asac: sun-java* in svn, openjdk in bzr
[14:05] <asac> doko_: what other java plugins do we have?
[14:05] <asac> or is that it for jaunty?
[14:08] <doko_> gcjwebplugin will go away
[14:48] <lamont> wow.  d-i actually picked the first(?) link-present interface for network config.  kewl.
[14:48] <lamont> (eth2)
[15:46] <lamont> dear open&*%)&$%&%vpn.  stop dropping the damn local network route. kthx
[15:47] <bddebian> Fix it! :)
[15:51] <lamont> so... at what point does the intrepid openvpn go ripping through the routing table and remove all routes to subnets that have supernets routed over the vpn?
[15:51] <lamont> thereby leaving me with a default route pointing to, um, me.
[15:57] <lamont> bddebian: well, I thought I had fixed it.. by explicitly doing the routing table addition myself, rather than telling openvpn to do it via the config.  however... it appears to do it after it runs the up script
[15:58] <lamont> and it's only a problem when I plug the machine into the lan cable at home...
[15:59] <bddebian> Ah :)
[16:00] <psusi> TheMuso: you remember that dmraid bug with isw breakage caused by the raid10 patch I was working on?  I basically gave up as fixing it correctly is far more complicated than I first thought.  What are the odds on just backporting rc15? ;)
[16:15] <Silicium> hi there
[16:15] <Silicium> i have created a custom install disk
[16:16] <Silicium> so how i can regenerate te main Packages file with all hashes?
[16:43] <asac> doko_: gcjwebplugin.so  or IcedTeaPlugin.so what is used?
[16:45] <doko_> hardy: gcjwebplugin.so, later: IcedTeaPlugin.so
[16:46] <asac> doko_: and the  .so filename in the IcedTeaPlugin.so case is "IcedTeaPlugin.so" ... right?
[16:46] <asac> (seems obvious, but better ask ;))
[16:50] <doko_> asac: yes
[16:50] <doko_> asac: but you should only see libjava-plugin.so
[16:50] <asac> doko_: because of the alternative?
[16:51] <asac> i need the filename of the link target
[16:51] <asac> thats what mozilla sees internally
[16:54] <doko_> asac: this is ugly
[18:00] <slangasek> tseliot: it appears to be in binary new
[18:34] <slangasek> asac: published, cheers
[18:40] <slangasek> kees, Mithrandir: ah, pam_env user-environment support merged upstream
[18:42] <kees> slangasek: oooh nice
[19:05] <asac> doko_: you dont even know what this is about ;)
[19:17] <slangasek> ScottK: thanks for filing the lintian MIRs ahead of me :)
[19:23] <ScottK> slangasek: You're welcome.  I figured I asked for the sync without checking for that, so I earned it.
[19:24] <sebner> ScottK: well, no I'm here :)
[19:24] <ScottK> slangasek: Now we just need someone from the MIR team to actually look at them ...
[19:43] <slangasek> kirkland: so why is per-user encrypted homedirs preferable to either use of ~/Private, or system-level encryption of /home?
[19:45] <ScottK> Per user would be better if the user didn't trust the sysadmin?
[19:48] <slangasek> ScottK: how does ~/Private not already solve that, with less of a performance hit?
[19:48] <ScottK> slangasek: Dunno.
[19:48]  * ScottK was taking a stab in the dark.
[19:52] <lifeless> if you don't trust the sysadmin you're already wedged
[19:52] <lifeless> once your CPU can read your data, so can they
[19:53] <slangasek> maybe you're running SELinux at the same time ;)
[19:53] <lifeless> even so :)
[19:53] <lifeless> you might think you're running SELinux, but are they :)
[19:54] <slangasek> my attempts to compromise the machine say yes
[19:54] <lool> slangasek: Re: p7zip MIR: I wonder whether we could replace zip/unzip with p7zip
[19:55] <slangasek> lool: possibly!  I have no preference, I just don't want us to ship both zip/unzip /and/ p7zip on the CDs :)
[19:55] <lool> That would be more functionality and space efficient
[19:55] <lifeless> slangasek: humour aside, a VM with selinux in it, and you are talking to the VM, sysadmin has raw hardware
[19:55] <lool> slangasek: full ack
[19:55] <pwnguin> slangasek: ive been looking at p7zip as part of squashfs
[19:56] <pwnguin> slangasek: unfortunately, debian packages aren't optimized for compression
[19:56] <pwnguin> but i hear the livecd doesn't have traditional .debs?
[19:56] <slangasek> er?  what does p7zip (the userspace package) have to do with squashfs (a kernel fs implementation)?
[19:56] <pwnguin> p7zip is the lzms implementation ;)
[19:57] <pwnguin> lzma i mean
[19:58] <slangasek> AIUI, p7zip is a container format.  We have an "lzma" package that implements lzma compression.
[19:59] <pwnguin> huh
[20:00] <pwnguin> look at the lzma package description
[20:03] <slangasek> what about it?
[20:04] <pwnguin> it's got 7zip all over it ;)
[20:04] <pwnguin> i dare say 7zip and lzma are interchangeable terms ;)
[20:04] <slangasek> they are not
[20:04] <pwnguin> anyways, back to business as usual
[20:07] <pwnguin> oh that's right, i remember now; 7z lets you use a lot of compression algorithms but mainly promoted lzma as it's 'new hotness'. clearly i got up too early today
[20:14] <psusi> 7zip and lzma are as interchangable as gzip and lz
[20:15] <TheMuso> psusi: There would really have to be a strong case for it. We could try backporting just the intel code.
[20:15] <pwnguin> its more like avi and divx ;)
[20:16] <TheMuso> psusi: But even then backporting rc15 is probably not a good idea.
[20:16] <psusi> TheMuso: even to get it into -updates?
[20:16] <psusi> err, -backports?  which was it?
[20:16] <psusi> the one you have to choose to enable to get the latest and greatest
[20:17] <TheMuso> psusi: -backports if an option of course, but thats not always useful to everyone.
[20:17] <TheMuso> psusi: I thought you meant intrepid-updates.
[20:17] <psusi> right.... but it would be better than having them install a broken version from my ppa to get their system working
[20:18] <TheMuso> Agreed.
[20:18] <psusi> and don't forget, it is a regression
[20:19] <TheMuso> Yes I know.
[20:19] <TheMuso> psusi: But just putting a newer version in backports is not ideal either.
[20:20] <psusi> all I know is that raid10 patch from mandriva is a lot different than the raid10 implementation in rc15, so it seems a lot easier to just go with that rather than try to fix the very broken mandriva patch
[20:20] <TheMuso> Yep agreed.
[20:21]  * TheMuso will have a look at it during UDS, since rc15 allows the creation of dmraid metadata now, so I'll try creating a raid10 vm and get rc14 to try looking at it and see if I can reproduce locally.
[20:21] <psusi> now if only I could make heads or tails out of this code to figure out why it doesn't like volumes with long names with spaces in them....
[20:22] <psusi> ohh yea, that's true... good idea
[20:22] <psusi> I've been using the metadata dumps people have attached to the bug reports to simulate the setup for testing
[20:23] <TheMuso> that hasn't worked for me I've found, as you need same drives with same models, serial numbers, etc.
[20:23] <psusi> you have to build dmraid with a testing option so it considers /dev/dm-* as underlying disks, place the drive serial numbers in /dev/dm-*.serial, and use dmsetup to create a device mapper that returns zeros for everywhere but where the metadata is linearly mapped to a loopback device
[20:25] <TheMuso> meh I think I'll use rc15 and a vm.
[20:25] <TheMuso> Anyway, I must continue to prepare for my flight today.
[20:25] <psusi> hehe
[20:26] <tseliot> slangasek: ok, thanks for the information
[21:23] <hwilde> last chance before reinstall... anybody know why this is failing reference two different kernels ? http://pastie.org/329186
[23:00] <Lancao> hi
[23:02] <ScottK> Is it's a regression that qualifies for SRU, then it's really inappropriate for -backports.
[23:08] <Mez> can someone confirm me this? if you install a minimal system (mine's done through debootstrap) - and then try to install openssh-server - it won't work
[23:08] <Mez> I've tested it and it seems to fail with log_daemon_msg
[23:09] <superm1> Mez, generally you need to divert invoke-rc.d if you are working directly in a chroot doing these kinds of things unless you bind mount /proc and possibly /sys
[23:09] <ScottK> Mez: Does it depend on lsb-base?
[23:10] <superm1> Mez, you can look at livecd-rootfs for an example of what's done while live disks get build
[23:11] <Mez> ScottK: lsb-base is installed, and it has the call for /lib/lsb/init-functions too...
[23:11] <Mez> other scripts in init seem to work, which is a bit weird.
[23:14] <Mez> superm1: I am working in a chroot, yes (trying to setup an EC2 image)
[23:16] <Mez> superm1: seems it was proc