[00:12] <mohbana> do i need nspluginwrapper for java 32bit
[00:13] <Hobbsee> mohbana: #ubuntu for support, please.
[01:44] <TheMuso> c
[07:55] <fabbione> soren: ping?
[08:32] <soren> fabbione: Wazzup?
[08:33] <fabbione> soren: nevermind... apt-get install acpid in the guest and virsh define foo.xml did it
[08:33] <fabbione> soren: the management for that stuff in hardy is really bad.. and unclear
[08:36] <fabbione> soren: is there a specific reason why virsh reboot <domain> is not supported?
[08:48] <soren> fabbione: Isn't it?
[08:49] <fabbione> soren: nope... it's not
[08:49] <fabbione> soren: keep in mind.. hardy
[08:50] <fabbione> soren: libvir: error : this function is not supported by the hypervisor: virDomainReboot
[08:50] <soren> fabbione: Hm... Same in Intrepid (and Jaunty), it seems.
[08:50] <fabbione> soren: ok..
[08:50] <soren> Weird. I'venever used it.
[08:50] <soren> Apparantly.
[08:50] <fabbione> well it's a pain :)
[08:55]  * soren wonders how that would work... 
[08:55] <soren> Is there an ACPI reboot event of some sort?
[09:32] <NCommander> soren, yeah, there is, but I'd need to look it up
[09:40] <soren> NCommander: Looking at acpid and friends, I don't thingk we have anything that handles it, though.
[09:41] <NCommander> handles, what, reboots?
[09:41] <NCommander> That's all kernel space
[09:41] <NCommander> Its done via a syscall
[09:43] <soren> NCommander: Err... Yeah, but something in userspace needs to shut everything down, just like when we handle an acpi shutdown event.
[09:43] <NCommander> soren, I honestly won't be suprised if halt simply called int 0x80 directly,
[09:46] <NCommander> soren, shutdown simply changes the runlevel to 0 which handles the shutdown
[09:47] <soren> Yes....
[09:48] <soren> When you press your power button, acpid catches this, does a bunch of stuff, and finally calls shutdown.
[09:49] <NCommander> I think I'm missing your question soren
[09:50] <soren> a) Does an ACPI reboot event exist?
[09:50] <soren> b) If it does, is there anything that will handle it?
[09:50] <NCommander> Define ACPI reboot event
[09:50] <soren> AFAICS, the answer to b) is "no".
[09:50] <NCommander> You mean an ACPI event from the kernel to reboot the machine?
[09:50] <soren> The acpi subsystem can emit events of various sorts.
[09:51] <NCommander> Oh, I get it
[09:51] <soren> Like when you press your power button.
[09:51] <NCommander> Ok, I don't
[09:51] <NCommander> I assume we're talking about a hardwired reboot button?
[09:51] <hyperair> the reboot button is generally a hard-reboot button
[09:51] <hyperair> doesn't even hit the software
[09:51] <hyperair> i don't think there's an acpi event for that
[09:51] <soren> I've never seen a machine with a "reboot" button, but that doesn't mean acpi couldn't support it.
[09:51] <NCommander> I have
[09:51] <NCommander> as hyperair says
[09:51] <hyperair> so have i
[09:51] <soren> "reboot"? Not "reset"?
[09:51] <hyperair> all the older PCs have it
[09:51] <hyperair> oh
[09:51] <hyperair> hmm
[09:52] <NCommander> Some newer servers do too
[09:52] <hyperair> reset most probably
[09:52] <NCommander> Someone would have to go digging in the ACPI specifications to find out the answer to 1.
[09:52] <hyperair> i don't think there's such a button, really
[09:52] <hyperair> "reboot" button?
[09:52] <soren> If b) is "no", a) doesn't matter :)
[09:53] <hyperair> probably not?
[10:15] <directhex> calc, FYI: OOo 1:3.0.0-6 from experimental works with the mono 2.0 transition
[10:16] <NCommander> Nice!
[10:18] <directhex> NCommander, t'is the only green for debian on http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO o_o
[10:18] <NCommander> ah
[10:18] <directhex> lots waiting to be sponsored, some left to be done (for apps, this is)
[11:29] <_Groo_> hey/all
[11:29] <_Groo_> is this the right place for kubuntu dev also?
[13:03] <PeskyJ> ahh, I see from the topic this is not channel for app dev discussion, what is the channel for that? I've never developed an app for X before and want to get started
[13:04] <directhex> PeskyJ, picking a language or framework is a good starting point, then try channels related to it
[13:04] <directhex> PeskyJ, if you already program a given framework, you can just go from there. if you want something different, pick it & find some tutorials
[13:06] <PeskyJ> directhex: well probably C++ will be the language, but I have no idea about programming for X so my initial questions are mostly related to frameworks does KDE* work on gnome and vice versa, is there a portable one that works on more/other systems, etc. etc.
[13:06] <hyperair> PeskyJ: i'm using C++ and gtkmm
[13:06] <directhex> Qt is the framework you're thinking of, and yes, you can run Qt apps fine on gnome
[13:07] <hyperair> actually i think qt is more portable than gtk, and especially if you use qt4, you can get a nice native look even on GNOME environments. the file chooser will be different though.
[13:08] <directhex> gtk's much more popular for proprietary apps, if you weren't planning on heading down a free software route
[13:08] <hyperair> directhex: why so?
[13:09] <directhex> hyperair, LGPL versus GPL/£££££££££££
[13:09] <hyperair> what's with the pound signs
[13:09] <directhex> hyperair, qt's the most expensive & restrictive framework on the market if you don't want to GPL your app
[13:09] <hyperair> i see
[13:09] <directhex> hyperair, enormous price, per-seat cost, and explicit forbidding in the license to dev against the free one then recompile later against the expensive one
[13:10] <hyperair> but opera went for qt anyway
[13:10] <hyperair> and so did virtualbox
[13:10] <directhex> yep
[13:10] <hyperair> and skype
[13:10] <directhex> vmware's gtk though, as an example
[13:10] <hyperair> yeah
[13:10] <hyperair> but that's the only one i know of that's proprietary
[13:10] <hyperair> crossover uses what?
[13:11] <NCommander> Qt is nice because it looks and feels consistant on all archs
[13:11] <NCommander> GTK applications stick out on non-*nix architectures
[13:11] <directhex> true. that's one reason it's used
[13:11] <PeskyJ> directhex: I haven't even looked at or considered licenses yet.. don't want to be commercial though, whatever is most free (I don't really know much about this area) - I think that means GPL
[13:11] <NCommander> That being said, I perfer GTK over Qt apps
[13:11] <hyperair> NCommander: the last time i ran a gtk app on windows, it looked pretty nice
[13:11] <hyperair> i think it was pidgin
[13:11] <hyperair> had a pretty native look about it
[13:11] <NCommander> GTK is getting better
[13:12] <NCommander> but look at codeblocks
[13:12] <NCommander> On windows, its hard to tell its not native
[13:12] <directhex> there's a windows theme for gtk, which hooks into the windows theme subsystem
[13:12] <hyperair> yes, that's true
[13:12] <hyperair> directhex: yeah that's what i was talking about
[13:12] <directhex> but not all gtk widgets can be rendered by windows gdi+
[13:12] <NCommander> directhex, its similar to SWT
[13:12] <hyperair> NCommander: wx looks good on windows, but not as good on gtk, especially with dark themes
[13:12] <directhex> e.g. gdi+ has no concept of a notebook with tabs on the side instead of at the top
[13:13] <NCommander> GDI is just the drawing API
[13:13] <NCommander> It has no concepts of widgets and such :-)
[13:13] <hyperair> the last time i tried my hand at windows GUI programming, everything was statically sized. yuck.
[13:14] <hyperair> well not really "tried". i carried it through. those were my two a levels computing projects
[13:14] <NCommander> You need to remember Win32's APIs are similar to say DOS C APIs than something more modern
[13:14] <PeskyJ> ok... so it seems that GTK or Qt would be the frameworks to use
[13:14] <NCommander> TBH, I don't actually mind raw win32 too much if I'm not doing something too crazy
[13:15] <directhex> hyperair, standard windows toolkits use pixel-based layout
[13:15] <hyperair> PeskyJ: you could also use GNOME and KDE libs, but unless you bind the user to a DE
[13:16] <NCommander> hyperair, well, GNOME is essentially GTK
[13:16] <directhex> hyperair, the first "proper" toolkit from MS is the Windows Presentation Foundation for .net. all the nice things like container-based layout.
[13:16] <NCommander> directhex, well, there was MFC ...
[13:17] <hyperair> MFC is hell
[13:17] <NCommander> No denying it
[13:17] <PeskyJ> hyperair: that's what I wanted to avoid... I have ubuntu gnome and I tried to run something that was KDE specific and it really didn't like it... I want to avoid restricting the environments it can run
[13:17] <NCommander> But MFC made Win32 programming not be incredibly difficult
[13:17] <NCommander> Then again, raw Win32 programming with resource files isn't horrible if you know what you are doing
[13:18] <hyperair> PeskyJ: qgtkstyle is coming. in fact, it's in my PPA. all QT4 applicatiosn can look very native in GNOME. even skype and virtualbox
[13:18] <hyperair> NCommander: you've got to hook onto the resize event and then resize everything yourself
[13:18] <hyperair> and do the calculations
[13:18] <hyperair> bah
[13:18] <hyperair> what a nightmare
[13:18] <NCommander> hyperair, no you don't
[13:18] <hyperair> you don't?
[13:18] <NCommander> hyperair, don't catch RESIZE, and then let DefProcWindow() handle it
[13:19] <PeskyJ> hyperair: qgtkstyle? is that yet another framework?
[13:19] <NCommander> Unless your using custom widgets, it works fine
[13:19] <NCommander> If your using custom widgets, then you need to have catch the resize event, resize your widgets, and then pass it along
[13:19] <hyperair> PeskyJ: no, it's a qt engine that uses Gtk to render, so everything coded in qt4 and above looks nice and native in GNOME
[13:20] <hyperair> NCommander: scary. i never bothered dealing with resizing. it was a visual basic 6 project
[13:20] <NCommander> ewww
[13:20] <hyperair> i just arranged my widgets nicely and then removed the resizable property
[13:20] <hyperair> heh
[13:20] <NCommander> You shouldn't have to do that in VB6
[13:20] <NCommander> YOu can get something similar with resource files
[13:20] <hyperair> wel you know what, that's all they taught
[13:20] <NCommander> Resource files with raw Win32 APIs aren't too bad
[13:20] <NCommander> Unless you need to do something nutty
[13:21] <PeskyJ> hyperair: so it sounds to me like the best recommendation would be to use Qt, then it can run in KDE, Gnome, Windows, etc. right, and with the advent of qgtkstyle it will even look like a native app?
[13:21] <hyperair> PeskyJ: well, gtk and qt4 are on equal ground on this one i would say
[13:21]  * directhex uses gtk#, but will not evangelize here ;)
[13:21] <NCommander> I'd go with Gtk
[13:21] <hyperair> gtk looks native on kde already
[13:21] <hyperair> even with kde3
[13:21] <NCommander> But Qt apps usually look like KDE apps on GTK environments
[13:22] <directhex> oh, you wanted c++....... iirc qt is threadsafe, gtk is not. if that matters to you
[13:22] <NCommander> Only parts of Qt are threadsafe (if you use QThreads ..)
[13:23] <PeskyJ> directhex: I'm not too bothered about the language actually.. C++ is just probable.. I could learn python or something else if required.
[13:23] <NCommander> ARGH
[13:23]  * NCommander lets a trail of obscenities go
[13:24]  * DktrKranz filters NCommander context
[13:24] <NCommander> DktrKranz, sorry
[13:24] <NCommander> ANother KDE/Qt FTBFS
[13:24] <DktrKranz> \o/
[13:25] <NCommander> I think Qt lies when they say Qt is portable
[13:25] <PeskyJ> well.. I would likely be using threads a lot, not so sure if I understand what impact the windowing environment being threadsafe is though - surely you can post messages safely from any thread in all windowing environments??
[13:25] <NCommander> At least I know my fixes will work
[13:25] <NCommander> If I can stay sane enough to finish writing them all
[13:26] <directhex> PeskyJ, i think, in essence, in qt you can just do stuff - in gtk, some stuff can only be done in the main application thread, so you need to use your language's method for doing so
[13:26] <directhex> PeskyJ, try changing a window label outside the main thread in gtk, and the window will just go screwy
[13:27] <PeskyJ> directhex: I see - I'd likely only have one GUI thread and other threads to do app-specific stuff, though it might be convenient for some stuff as you say to just go ahead and change something without having to post a message about it
[13:28] <PeskyJ> directhex: tbh, I've not done much window-environment programming, mostly games where you render your own GUI
[13:33] <PeskyJ> so a GTK app can run on KDE and Gnome, and Windows, right?
[13:34] <PeskyJ> how about IRIX (is that even still around)?
[13:44] <NCommander> PeskyJ, Probably.
[13:44] <NCommander> lamont, morning
[13:45] <lamont> g'morning
[13:49] <NCommander> how goes it lamont
[13:56] <directhex> PeskyJ, irix is dead, but old installations may persist
[14:07] <PeskyJ> directhex: so what other window environments are there these days?
[14:08] <directhex> PeskyJ, irix isn't a window environment, it's an os. which are you asking about?
[14:10] <PeskyJ> directhex: oh.. well the 4DWM that came on IRIX was pretty cool... I'm just wondering what other window environments there are in use these days, other than KDE, Gnome, Windows?
[14:10] <directhex> xfce, openbox... e17? and minimal things like awesomewm
[14:11] <NCommander> infinity, hey, are you floating around?
[14:11] <PeskyJ> and does both Qt and GTK work on those too?
[14:12] <directhex> bien sur.
[14:43] <hyperair> PeskyJ: as long as you've got the dependencies, gtk/qt stuff will work on anything. heck, even gnome and KDE specific applications will work. just that kde specific applications start a whole string of unwanted daemons with them if you're not already on kDE
[14:44] <hyperair> *KDE
[15:47] <pitti> bryce, tjaalton: a dist-upgrade to jaunty caused X to fail because it couldn't load libdrm_intel.so. Shouldn't -intel Depends: libdrm-intel1?
[16:15] <tjaalton> pitti: -intel should pick the dependency when building against the new libdrm, but doesn't for some reason I've yet to find out
[17:16] <kees> so we haven't hit DIF, but I see a gap between unstable and jaunty at the moment -- is there a giant backlog still?
[17:18] <kees> better question, where can I see the Ubuntu Archive Auto-Synce queue?
[17:19]  * kees assumes https://edge.launchpad.net/~katie/+uploaded-packages
[17:19] <kees> which means UAAS hasn't run for 4 days?
[17:21] <NCommander> hey kees
[17:21] <kees> heya NCommander
[17:21] <NCommander> kees, how goes it?
[17:21] <kees> NCommander: goes busy and well :)
[17:21] <sebner> kees: well 20 days until DIF, maybe nobody had time because of the UDS
[17:22] <fta> doko, gcc seg fault: http://launchpadlibrarian.net/20235151/buildlog_ubuntu-jaunty-sparc.xulrunner-1.9.1_1.9.1~b2%2Bbuild1%2Bnobinonly-0ubuntu3_FAILEDTOBUILD.txt.gz
[18:18] <calc> directhex: ah he finally released 3.0.0-6? :)
[18:19] <calc> directhex: i'll be uploading an ubuntu version asap in that case, at FOSSCamp right now
[18:19] <directhex> calc, aye
[18:19] <directhex> calc, okay, cool, was just keeping you updated
[18:19] <calc> it will take a little while to get built since i have to get everything pulled in from universe, heh
[18:22] <directhex> dude, it's OOo. it'll take 8-10 hours to build Lpo
[18:22] <directhex> :p
[18:23] <directhex> gah, can't type today
[18:55]  * StevenK kicks libkdcraw in the -dev
[18:55] <StevenK> E: Package libkdcraw-dev has no installation candidate
[18:55] <StevenK> Grah
[18:56] <calc> directhex: a little while as in several days due to ~ 20 MIRs ;-)
[18:57]  * directhex whistles innocently
[18:58]  * calc bbl
[19:00] <slangasek> directhex: so I guess kdebindings-kde4 needs some kind of migration off of libkimono4.1-cil, do you know if anyone's working on that?
[19:01] <directhex> slangasek, to the best of my knowledge, nobody's working on it - but if my memory serves me correctly, those libs are already built against CLI 2.0 - so only minor build-dep & rules tweaks should be needed
[19:01] <directhex> depends on libmono-corlib2.0-cil, so yes, just a little bit of tweaking required
[19:05] <directhex> slangasek, is that a request, then?
[19:10] <slangasek> directhex: a subtle hint :)
[19:11] <slangasek> directhex: you mention only libmono-corlib2.0-cil, though - I'm looking at the NBS list, which shows it depends on the no-longer-extant libkimono4.1-cil?
[19:11] <directhex> slangasek, still exists - disabled in debian/control due to, well, lack of buildability right now
[19:11] <slangasek> hrm
[19:12] <slangasek> k, ignoring that one for now then
[19:14] <directhex> slangasek, with autofoo, you can override an AC_PROG_PATH by specifying it on the configure line (e.g. ./configure FOO=/usr/bin/bar). do you know if the same or similar can be done with cmake?
[19:14] <slangasek> my working assumption is that it's impossible to do anything useful with cmake
[19:14] <directhex> :)
[19:17] <StevenK> Blah. libkdcraw7-dev does not Provide libkdcraw-dev
[19:20] <StevenK> NCommander: Why did libkdcraw-dev get renamed to libkdcraw7-dev?
[19:21] <StevenK> NCommander: And all the other -dev's that kdegraphics build?
[19:22] <StevenK> Ah ha. Debian did it.
[19:23] <StevenK> Well, that sucks
[19:30] <tmccrary> Where can I located the busybox configuration for ubuntu's initrd that comes with kernels?
[19:32] <tmccrary> is there a source package for ubuntu's initrd?
[19:32] <tmccrary> does it come in the kernel sources?
[19:34] <TheMuso> tmccrary: The initrd is made up of files from several packages. The initramfs-tools package is the one responsible for putting it all together.
[19:34] <TheMuso> tmccrary: You want to look at /usr/share/initramfs-tools for the scripts used to put the initrd together.
[19:35] <tmccrary> TheMuso: awesome thank you
[19:35] <directhex> so many build deps..... why does kde4bindings build-dep on so many -dbg packages? o_O
[19:35] <tmccrary> I need to build the brctl applet into busybox
[19:35] <tmccrary> I didn't want to go though the entire busybox config ;)
[19:42] <TheMuso> tmccrary: Your best option is to probably extend the brctl package to add files to the initrd, and run it in the initrd.
[19:42] <tmccrary> does busybox's brctl not work adequately?
[19:42] <directhex> apachelogger, ping
[19:45] <fabbione> who is in charge of the installer these days?
[19:45] <TheMuso> tmccrary: I don't know, I didn't even know busybox had brctl.
[19:45] <tmccrary> Well, it has an option in make menuconfig
[19:46] <tmccrary> ;)
[19:47] <tmccrary> brctl looks statically linked and is pretty small when built
[19:47] <tmccrary> so that's not a bad way to go
[19:50] <directhex> bah
[20:03] <kirkland> pitti: hey, can we take a quick look at that adduser --encrypt-home patch at some point today :-)
[20:06] <TheMuso> kirkland: let me know if there is a time today when there are no session s you are interested in, and perhaps we can sit down and have a look at the mdadm merge.
[20:06] <kirkland> TheMuso: sounds good, perhaps after a quick bite to eat for lunch?
[20:06] <TheMuso> kirkland: Sounds good to me.
[20:10] <bryce> pitti: I've added a Depends on -intel for that as a workaround, until the libdrm symbols stuff gets sorted out
[20:21] <directhex> sigh. kde4bindings fails to build - near the end, in cpp code (ie.. not my fault)
[20:22] <ScottK> directhex: Feel free to join us in #kubuntu-devel to discuss
[22:03] <ion_> When will Keybuk return, btw?
[22:13] <pochu> kees, jdstrand: hi. there is a security update for vinagre upstream, which fixes a printf without format. Should that go through -security or -updates? The patch is this: http://svn.gnome.org/viewvc/vinagre/branches/gnome-2-22/src/vinagre-utils.c?view=patch&r1=528&r2=527&pathrev=528
[22:13] <pochu> kees, jdstrand: affected releases are hardy, intrepid and jaunty
[22:15] <nxvl> pochu: there is a bug in launchpad already?
[22:15] <jdstrand> pochu: also, is there a CVE?
[22:15] <pochu> nxvl: nope, not yet
[22:15] <pochu> jdstrand: I don't think so, I've googled for it without luck
[22:15] <pochu> jdstrand: and upstream doesn't mention it in the changelog or NEWS file
[22:16] <pochu> see http://svn.gnome.org/viewvc/vinagre?view=revision&revision=529
[22:16] <pochu> http://svn.gnome.org/viewvc/vinagre/branches/gnome-2-22/ChangeLog?r1=529&r2=528&pathrev=529
[22:16] <nxvl> pochu: then report it
[22:16] <kees> pochu: do you have a reproducer for it?
[22:16] <nxvl> :S
[22:16] <jdstrand> pochu: is that message user-controllable?
[22:16] <jdstrand> s/user/remotely/
[22:16] <pochu> not sure, let me check
[22:17] <jdstrand> pochu: the changelog would suggest as much
[22:18] <jdstrand> pochu: if it is indeed a security issue, then it should go through -security
[22:18] <jdstrand> pochu: I've made a note to look into it-- if you find a reproducer/PoC, that would be great
[22:19] <kees> and if there's a reproducer, I'd like to try it on intrepid, as I suspect it'll get caught by FORTIFY
[22:19] <jdstrand> there is a version of vinagre in hardy that'll need to be checked
[22:20] <pochu> looks like it's not remotely controllable
[22:21] <pochu> it could be controlled through translations though
[22:23] <pochu> the bug is on the vinagre_utils_show_error function, which is used 11 times in the source (in the hardy version), and looks like in all of them the string is hardcoded in the source
[22:23] <pochu> except that in some cases it is translated
[22:23] <pochu> so a malicious translator could control it... not sure if that's a reasonable situation :)
[22:24] <jdstrand> pochu: is it pretty much the same on intrepid?
[22:25] <pochu> BTW I'm no security expert, so would be fine if you could check it too just in case I overlook anything
[22:25]  * jdstrand nods
[22:27] <jdstrand> (not at the non-expert part-- at the me checking part :)
[22:28] <kees> jdstrand: I'll looking through it now, so far so good
[22:28] <jdstrand> kees: ah, well, if you're looking at it, I'll take it off my TODO list :P
[22:28] <pochu> looks more or less the same in Intrepid
[22:28] <pochu> it's used some more, but looks like the messages are all hardcoded in the code
[22:29] <pochu> if it's hardcoded, then it's no security issue, right?
[22:29] <pochu> jdstrand, kees: thanks :)
[22:29] <kees> hrm, it's used on filename errors...
[22:29] <kees> in vinagre_cmd_machine_open
[22:31] <kees> vinagre %x
[22:31] <kees> so, yeah, it's user-assisted, but still an issue
[22:31] <kees> an on intrepid...
[22:31] <kees> $ vinagre %n
[22:31] <kees> *** %n in writable segment detected ***
[22:31] <kees> heheh
[22:32] <kees> pochu: so yeah, if you can, can you open a bug report for it an mark it a public security issue along with the links you gave above?
[22:32] <pochu> kees: sure
[22:32] <pochu> kees: so this affects intrepid only, or both intrepid and hardy?
[22:32] <kees> pochu: thx! and thanks for noticing it in the upstream commits.  :)
[22:33] <kees> looks like hardy through jaunty
[22:33] <pochu> ah yeah, due to vinagre_utils_show_many_errors right?
[22:33]  * kees nods
[22:34] <pochu> ok
[22:34]  * pochu reports a bug
[22:50] <pochu> kees, jdstrand, nxvl: reported as bug 305623
[22:50] <jdstrand> pochu: thanks :)
[22:51] <pochu> I can prepare debdiffs, but I have never done them before for the -security pocket :)
[22:51] <mneptok> hrmf.
[22:51]  * mneptok goes in search of ubottu
[22:51] <jdstrand> pochu: just follow https://wiki.ubuntu.com/SecurityUpdateProcedures
[22:52] <nxvl> which package is it again? vinagre, right?
[22:52] <pochu> nxvl: yup
[22:52] <pochu> jdstrand: ok, thanks
[22:53] <nxvl> is it private?
[22:53] <pochu> nope
[22:53] <pochu> https://bugs.edge.launchpad.net/ubuntu/+source/vinagre/+bug/305623
[22:53] <pochu> jdstrand: can you approve the hardy and intrepid tasks?
[22:53] <kees> pochu: cool, thanks
[22:53] <pochu> you're welcome :)
[22:53] <kees> pochu: I'll approve them, one sec
[23:50] <calc> jcastro: ping
[23:53] <pochu> kees: what do you mean with segv on hardy? sigsegv?
[23:54] <pochu> it doesn't crash here on a hardy VM if I launch vinagre as "vinagre %n"
[23:54] <pochu> it just doesn't display the %n in the error dialog, but with the patched vinagre it does
[23:54] <pochu> is that alright?
[23:55] <kees> pochu: yeah, that's fine.  the sigsegv will show up if you add enough %n's.  :)  %n%n%n%n%n%n%n eventually it'll hit bad memory
[23:56] <pochu> ah, got it now :)
[23:56] <kees> :)
[23:57] <mathiaz> evand: http://ubuntumathiaz.wordpress.com/2008/09/18/automate-ubuntu-server-iso-testing/
[23:58] <pochu> kees: hardy debdiff submitted
[23:58] <kees> pochu: great, thanks!