[01:00] <Keybuk> directhex: HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
[01:01] <directhex> Keybuk: :)
[01:02] <directhex> Keybuk: see? your time with ubuntu can still be a source of great lulz!
[01:04] <Keybuk> I know, right
[01:04] <Keybuk> the funny thing is that I don't actually like Mono
[01:06] <ion> What’s the funny?
[01:08] <Keybuk> ion: because I was chairing the TB meeting the week the Mono debate came up, it's my name on the TB's position statement
[01:08] <ion> I mean, what made you laugh
[01:08] <directhex> Keybuk: i made this point when the rumour mill first started up, over such an innocently trolling tweet
[01:09]  * micahg wonders why DIF is so early this cycle
[01:09] <Keybuk> which means Boycott Novell think I'm Ubuntu's chief Monoista or something
[01:09] <Keybuk> ion: http://bit.ly/kB3NcO
[01:09] <ajmitch> it's amusing that they'd bite at something that obvious
[01:09] <ion> Thanks
[01:09] <directhex> Keybuk: i'd need to not be in gameos to check my irc logs, but i think it was along the lines of "keybuk doesn't actually like mono, he just hates douchebags"
[01:12] <ion> heh
 people have even weirder names. probably in this local or family or culture, it means something good	
[01:13] <ion> Upstart 2 will be written in C#!
[01:14] <Keybuk> anyway, I like to fuck with them
[01:14] <Keybuk> because they are exceptionally nasty people
[01:15] <directhex> Keybuk: anyway, how's the googletron treating you?
[01:16] <RAOF> I especially like “trojarin” :)
[01:16] <Keybuk> directhex: free food, free gym, free bowling alley, what's not to like?
[01:17] <directhex> Keybuk: i can't imagine actively wanting to live in yankland :/
[01:18] <Keybuk> the weather is better, the scenery is prettier, the people are friendlier, ...
[01:19] <broder> directhex: california is most definitely not yankland :-P
[01:20] <directhex> broder: last time i was in the US i was in CA, and... bleh
[01:20] <directhex> perhaps i just have a knack for being in crap parts of the US when i visit
[01:20] <directhex> although san antonio was nice enough, certainly compared to fremont
[01:20] <broder> you were in fremont?
[01:21] <broder> yeah, it's hard to say if that counts
[01:21] <Keybuk> Fremont is pretty ghetto
[01:21] <directhex> SGIUG meeting
[01:22] <ion> The last time i was in the US i was in Gitmo. Didn’t like it much, although the waterboarding was cool.
[01:23] <Keybuk> heh, waterboarding does sound like a fun surf-related activity, doesn't it?
[01:26] <directhex> it's a few years since i've been to cuba. it was certainly sunny
[01:26] <ion> Speaking of which, my keyboard has this between the arrow keys and the pageup/pagedown/… block: http://heh.fi/tmp/extreme_sports
[01:26] <Keybuk> at least your keyboard *has* a pageup/down keys
[01:27] <Keybuk> vaguely related
[01:28] <Keybuk> does anyone how whether Spatula is Christian?
[01:28] <Keybuk> ie. is he likely to be raptured?
[01:28] <directhex> raptored?
[02:16] <micahg> any archive admins around that can pocket copy from -proposed?
[02:23] <bryce> jcastro, if you want to see the change to the xorg package hook deployed, you can test and give feedback @ #778758; else it'll be live in a few weeks or however long sru's take these days
[02:37] <micahg> siretart: will you be doing a new libav merge soon?
[02:38] <micahg> siretart: actually, nm, it won't fix my issue in any case I think
[03:40] <ohsix> hm are the 404 changelogs going to be fixed?
[03:41] <ohsix> input has been acting weird since the last update that included some xorg stuff, but i haven't been able to fetch the changelog yet
[03:47] <broder> ohsix: changelogs are always accessible through launchpad and the source
[03:48] <ohsix> can you give ne a prototypical example for xserver-xorg or the xorg package?
[03:48] <jcastro> bryce: so from looking at the branch you just have the option of "Yes."?
[03:48] <ohsix> most changelogs do work from aptitude; some tend to never do though
[03:49] <ohsix> maybe they're packages in -proposed
[03:49] <ohsix> but they worked in mav
[03:49] <broder> https://launchpad.net/ubuntu/natty/+source/xorg/1:7.6+4ubuntu3.1
[03:49] <broder> ohsix: or you can just apt-get source the package and look in debian/changelog
[03:51] <ohsix> hm thats probably untenable, on metered internets; any idea why it's broken for some packages in aptitude now? maybe the multiarch name mangling?
[03:55] <ScottK> SpamapS: I'd appreciate it if you could go ahead and accept the SRU for Bug #755608.  It's got a major negative effect on people using Kubuntu and VPNs and I'd like to get it in proposed before everyone who's got the problem and is vaguely connected to Ubuntu development has the fix from my PPA and doesn't care about SRU verification.
[04:00] <broder> ohsix: it should have nothing to do with multiarch mangling
[04:00] <broder> but i don't know anything other than that
[04:01] <ohsix> ok thanks
[04:01] <ohsix> it'd be great if it worked again
[05:26] <pitti> Good morning
[05:26] <pitti> sconklin, SpamapS, jdstrand: I'll reply with the instructions
[07:25] <pitti> lool: ah, seems you registered https://launchpad.net/pkgbinarymangler -- can you please disable upstream bug reports in LP for this project? having them as Ubuntu bugs is enough, as it's a native package
[07:33] <lool> pitti: pkgbinarymangler's config says bugs are tracked "somewhere else"
[07:33] <lool> I see no bugs on https://bugs.launchpad.net/pkgbinarymangler
[07:34] <lool> pitti: so perhaps someone else just changed that, or I don't see what to change
[07:40] <pitti> lool: I just closed the upstream one in bug 783565 and moved it to null
[07:41] <pitti> lool: but anyway, not that important
[07:49] <dholbach> good morning
[07:52] <lool> pitti: This looks like a lp bug then
[07:53] <pitti> hey dholbach, guten Morgen
[07:54] <dholbach> hey pitti
[07:54] <lool> pitti: NULL has bug tracking disabled as well; it seems you can't prevent bugs from going to projects which disabled the bug tracker
[07:54] <pitti> lool: ah, the intent is probably that you'd use those for linking to external bug trackers
[07:55] <pitti> lool: so for this we probably shouldn't have a project in the first place
[07:55] <lool> that's a way to kill it indeed
[07:55] <lool> pitti: but we need one for lp:pkgbinarymangler to work
[07:55] <lool> pitti: I don't mind either way (keeping it with some ghost bugs or demoving it and using the UDD branch)
[07:56] <lool> s/demoving/removing
[07:56] <pitti> ah, that was the reason for it?
[07:56] <pitti> WFM
[07:56] <mdke> pitti: hi. Any idea why the gnome-user-docs SRU that was accepted and built in maverick-proposed yesterday has not appeared on archive.ubuntu.com? The source package seems to be there. Sorry always to pick on you with my questions
[07:57] <pitti> mdke: ah, it's probably in binNEW, as it added new translations; I already binNEWed lucid yesterday, but not maverick
[07:57] <pitti> mdke: accepted, will be on archive.u.c. in an hour
[07:58] <mdke> pitti: magic, thanks. Obviously the translations won't be picked up until the next language packs I guess
[07:58]  * mdke looks to see when they are
[07:58] <mdke> mid-June, cool
[08:00] <pitti> mdke: no, language-selector should pick them up, I think?
[08:00] <pitti> ah, no, we strip them out and put them into the langpacks
[08:00] <mdke> right
[08:00] <didrocks> good morning
[08:45] <apw> does anyone happen to know which process during x setup makes the .ICEauthority file ?
[08:46] <apw> @pilot in
[08:48] <Satoris> Building Evince git head works fine in 32 bit natty, but fails on 64 because it links to both GTK+ 2 and 3. Any ideas on how to fix this?
[08:50] <pitti> Satoris: are you sure that this is platform specific? sounds like a bug in evince's makefiles
[08:52] <Satoris> pitti: could be, I have no idea. How do I find out?
[08:53] <pitti> it's just weird that it's architecture specific
[08:53] <pitti> Satoris: it's much more likely that on your 64 bit system you have both 2.0 and 3.0 -dev packages installed, and on your 32 bit system just one, or something similar
[08:53] <pitti> so I wanted to ensure you test with identical build dependencies
[08:54] <ohsix> apw: gnome-session from the looks of it, or whatever the session manager is
[08:55] <apw> ohsix, ahh there it is ... thans
[08:56] <seb128> what gnome-session?
[08:59] <ohsix> er maybe libice does
[08:59] <ohsix> i was just grepping :]
[08:59] <Satoris> pitti: found out the issue, thanks.
[09:01] <seb128> ohsix, what is the issue?
[09:01] <ohsix> no idea, he just asked
[09:03] <pitti> seb128: apw | does anyone happen to know which process during x setup makes the .ICEauthority file ?
[09:04] <seb128> pitti, thanks
[09:04] <seb128> yeah it's likely gnome-session
[09:04] <apw> seb128, i've found it thanks ... it is indeed gnome-session
[09:05] <apw> i am getting and error (of my own making on it)
[09:17] <maswan> pitti: hm. where's the prefered support channel for your postgresql 9 ppa, blog entry, email, /query?
[09:18] <pitti> maswan: /query will do fine
[09:18] <pitti> maswan: are you going to ask why libpq is at 9.1? :-)
[09:18] <pitti> seems that people spam me with that question a lot these days
[09:18] <maswan> pitti: no, why pg_upgradecluster fails hard :)
[09:19] <pitti> that's more interesting indeed; which version are you upgrading to?
[09:19] <maswan> 8.4 on lucid
[09:19] <pitti> maswan: debian bug 627227 probably
[09:19] <pitti> ?
[09:19] <maswan> pitti: yeah, it looks like it
[09:19] <pitti> maswan: I'll try to fix it today
[09:20] <maswan> pitti: I get more error messages though, starting with ERROR:  could not access file "$libdir/tablefunc": No such file or directory
[09:20] <maswan> pitti: maybe I should update that bug or so with the full error paste, or would that annoy debian purists?
[09:20] <pitti> maswan: wouldn't annoy me at least, and I'm the maintainer
[09:20] <maswan> pitti: would it be helpful?
[09:21] <pitti> can't hurt
[09:21] <maswan> ok, adding it
[09:21] <pitti> thanks
[09:25] <geser> pitti: I'm only using the Debian squeeze backport of postgresql-9.0, but did you already update the versions in the README.Debian? Not that people follow it blindly and drop their 8.4 clusters
[09:25] <pitti> geser: well, I'd expect a certain amount of thinking there :) but I'm happy to generalize it to not say a particular version
[09:26] <pitti> but it says that it's only an example
[09:31] <flower>  could it be true that if you backport from meerkat to lucid and let meerkat stand in you changelog file, the system asks for a partial distro upgrade?
[09:36] <pitti> it's not related to the changelog; presumably the new backport version grew a new dependency
[09:48] <ohsix> hm what's the story with powertop, is oneiric going to see a bump to 1.97? and what stopped it from happening with natty
[09:50] <amitk> ohsix: if you're doing work on getting powertop in, could you get it from tip instead?
[09:50] <amitk> it has fixes to make it run on ARM
[09:50] <ohsix> hm
[09:50]  * amitk is not sure what is currently packaged in debian
[10:33] <pitti> maswan: fixed p-common uploaded to sid; uploading backports for lucid/maverick/natty to PPA now
[10:34]  * sebner hugs pitti :)
[10:34]  * pitti hugs back sebner
[10:53] <cdbs> cjwatson: All default CD packages in Oneiric are installable now, time to fire up daily builds? :)
[11:01] <pitti> cdbs: yeehaw!
[11:02] <cdbs> pitti: Thanks to you, geser, seb128 and cjwatson for keeping the archive consistent
[11:02] <pitti> we are still breaking gnome, but trying hard to not break it too hard/long
[11:03] <Laney> aw, that's no fun
[11:36] <doko> pitti: ping on bug #784029
[11:38] <cjwatson> cdbs: oh, yeah, I was thinking of doing that soon - I was kind of hoping to switch to live-build first, but that'll probably take too long
[11:39] <cjwatson> need to check on all the dailies that weren't released with natty first though, and maybe take archive copies
[11:40]  * sebner hugs cjwatson :D
[11:45] <cjwatson> :)
[12:12] <jdstrand> pitti: re kernel-sru> thanks!
[12:20] <ScottK> pitti: I'd appreciate it if we could get the fix for Bug #755608 into natty-proposed.  It's hitting quite a number of people pretty hard.
[12:31] <siretart> micahg: what is the issue?
[12:31] <siretart> micahg: and yes, I intend to upload 0.7_beta2 RSN
[12:49] <ScottK> micahg: I was wondering if you might have a look at this thread https://lists.ubuntu.com/archives/kubuntu-users/2011-May/054073.html and see if you have any ideas about this problem or suggest someone better to look into it?
[12:57] <pitti> ScottK: will do now
[12:57] <ScottK> Thanks.
[12:58] <pitti> doko: I'll have a look
[13:00]  * sebner hugs ScottK too :D
[13:02] <sebner> ScottK: we'll definitely meet again, maybe not in orlando but someday. I'm looking forward to it
[13:02]  * ScottK too
[13:09] <ScottK> asac: I'd appreciate it if you could have a look at the patch in Bug #785119 soonish.
[13:11] <asac> added to list
[13:13] <ScottK> Thanks.
[14:29] <broder> sebner: i'm going to be disappointed with you if you don't make it to orlando, so work harder :-P
[14:33] <sebner> rofl
[14:33]  * sebner hides
[15:36] <apw> doko, are we expecting any compilers in the next couple of days?  we are likely uploading a kernle tommorrow
[15:38] <doko> apw: just the ones currently building
[15:38] <stgraber> mdeslaur: hey! I just noticed that usb-creator in Oneiric has a lower version number than the one in Natty. Is there a reason you didn't upload your security upload to Oneiric too?
[15:38] <apw> doko, thanks, i'll try and avoid them till they finish :)
[15:40] <cjwatson> stgraber: I can copy it ...
[15:40] <stgraber> cjwatson: would be great
[15:40] <broder> hmm...does strcpy's buffer overrun detection tend to have false positives?
[15:42] <apachelogger> tkamppeter: pingy, is the call to com.redhat.NewPrinterNotification something ubuntu specific or something worthwhile to implement in upstream KDE?
[15:42] <broder> (i'm trying to evaluate the patch on bug #723830)
[15:43] <mdeslaur> stgraber: ev had a commit to go in his bzr tree, I was waiting for him to commit it
[15:45] <cjwatson> mdeslaur: I'm generally happy to just batch-copy everything non-divergent from -updates to the next development series along
[15:45] <cjwatson> mdeslaur: and assume that somebody will take care of merging any bzr branches etc.
[15:46] <mdeslaur> cjwatson: so I would ask an AA to do that?
[15:47] <cjwatson> yes - I'm in the process of doing it now
[15:47] <mdeslaur> cjwatson: ok, cool. thanks
[16:12] <micahg> ScottK: ISTR an old bug like that
[16:28] <sabdfl> hi
[16:47] <hrw> pitti: I found reason of bug 784029 - but is in pkg-create-dbgsym
[16:47] <hrw> s/but/bug
[16:47] <pitti> hrw: oh, you did? I just added a simple test case (dhtest++1), but that works
[16:47] <hrw> pitti: in_line() function uses egrep and fails if $pkg argument consists + character
[16:47] <pitti> hrw: right, that was my first suspicion -- but shoudln't that fail on dhtest++1 as well?
[16:48] <pitti> hrw: I got distracted by some other stuff, but I'll continue to look into this
[16:48] <hrw> pitti: fails for me
[16:48] <hrw> dhtest++1 I mean
[16:49] <hrw> http://paste.ubuntu.com/610143/
[16:49] <pitti> ah, it might magically work with just one package name
[16:49] <pitti> hrw: I'll write a more appropriate test case
[16:50] <pitti> .. in a bit, need to run out to supermarket
[16:50] <hrw> no problem
[16:51] <RoAkSoAx>  /win 16
[17:01] <lool> pitti, hrw: Issue seems to be the grep in "in_list" in pkg-create-dbgsym/dh_strip
[17:01] <lool> echo "g++4.6" | egrep -q "(^|[[:space:]])g++4.6(\$|[[:space:]])" fails
[17:01] <hrw> 17:47 < hrw> pitti: in_line() function uses egrep and fails if $pkg argument consists + character
[17:01] <lool> in_list()
[17:01] <hrw> s/in_line/in_list ;D
[17:10] <pitti> lool, hrw: I already had the fix, but as my first initial test case wasn't reproducing, I postponed it
[17:10] <hrw> ok
[17:11] <hrw> fine for me - you know the problem, will solve it and I will get g++-4.6-dbgsym package
[17:12] <hrw> on 26 March 2010 g++-4.4-dbgsym package got created so maybe you can check how it was done at that time
[17:13] <hrw> pkg-create-dbgsym (0.41) lucid; urgency=low
[17:13] <hrw> you added in_list in this version
[17:14] <hrw> it was fix for bug 566602
[17:16] <hrw> bzr rev 174
[17:17] <hrw> anyway time for me to take care of nonwork related stuff
[17:17] <hrw> have a nice rest of day
[17:24] <apw> @pilot out
[17:26] <nigelb> persia: welcome back to IRC ;)
[17:26] <persia> nigelb, Thanks!
[17:27] <apw> persia, does that mean some normality is returning ?
[17:28] <persia> apw, Yes, indeed.
[17:28] <micahg> welcome back persia
[17:28] <maco> persia: you're back! *hug*
[17:28] <persia> Although, honestly speaking, my infrastructure setup time causes a lag between apparent normality and connetion monitoring
[17:31] <pitti> ev: FYI, I just re-merged lp:~pitti/usb-creator/pygi to trunk (just saw  your new upload)
[17:32] <ev> yay
[17:32] <ev> thanks
[17:32] <pitti> ev: any chance to merge this soon, that it stops getting out of date? or do you want to wait on something else?
[17:32] <ev> oh
[17:32] <ev> I thought you meant you merged it into trunk
[17:32] <ev> yes, I'll do a merge now
[17:32] <pitti> well, technically I can commit myself, of course, but I wondered whether you'd prefer to review it
[17:32] <ev> I'll have a quick look over
[17:32] <ev> just to put another set of eyes on it
[17:33] <pitti> thanks
[17:41] <tkamppeter> apachelogger, this is used at least in Fedora/Red Hat, Ubuntu, and Mandriva (distros which use system-config-printer). The D-Bus signal is sent by the Plug'n'Print part of s-c-p (udev-configure-printer, udev-add-printer, both in /lib/udev/) and received by the s-c-p applet.
[17:49] <pitti> hrw, lool: ah, got my failing test case at last; it only hits builds which use dh_strip -p..., so my initial attempt failed
[17:50] <pitti> as usualy, 30 minutes for test case, 30 seconds for the fix, but I'm anal about having this stuff covered
[17:51] <jdstrand> hallyn: hey, so I started looking at your libvirt merge
[17:51] <jdstrand> hallyn: first off, you will want to use '-v<last version in ubuntu>' when building your source package
[17:52] <jdstrand> hallyn: more importantly, it seems that attaching of physical devices has changed/is broken
[17:52] <hallyn> jdstrand: i'm certain i did
[17:52] <hallyn> hm
[17:53] <jdstrand> hallyn: the changes file only lists the changes for 0.9.1-1ubuntu1, so not sure what happened there
[17:53] <jdstrand> hallyn: I looked upstream and there is a lot of stuff on 'phyp' cleanups and bug fixes, etc

[17:54] <jdstrand> hallyn: here is the xml that fails:
[17:54] <jdstrand> <disk type='block'> <driver name='phy'/> <source dev='%s'/> <target dev='sdb'/>

[17:54] <hallyn> jdstrand: there's a qa test that does that?
[17:54] <hallyn> If so, can we open a debian bug for it?
[17:54] <jdstrand> where '%s' is the name of some file created with 'dd if=/dev/zero of=<foo> bs=1M count=64'
[17:55] <jdstrand> hallyn: yes-- test_guest_aa_attach_detach_physical()
[17:55] <jdstrand> "attach-device (physical)"
[17:56] <jdstrand> hallyn: there were other failures-- save/restore that I am not worried about (nested qemu issue)
[17:57] <jdstrand> hallyn: and then test_CVE_2010_2239(). I need to investigate that
[17:57] <hallyn> hm, i thought i tested save/restore on the vostro
[17:57] <jdstrand> hallyn: save/restore certainly works, what doesn't work is nested virtualization with save/restore where the nested vm is qemu (iirc)
[17:58] <hallyn> interesting
[17:58] <hallyn> for a sec i thought you meant nested on amd
[17:59] <jdstrand> no
[17:59] <jdstrand> kvm for the guest that is running test-libvirt.py. test-libvirt.py runs a qemu guest
[18:00] <pitti> kees, jdstrand: releasing karmic linux-ec2, smb confirmed testing
[18:00] <pitti> to -updates and -security
[18:00] <jdstrand> hallyn: that didn't work right on natty either, fwiw
[18:00] <pitti> not sure whether you want to release an USN for this, as it's past EOL
[18:00] <hallyn> jdstrand: it should work in natty-proposed
[18:01] <jdstrand> hallyn: you have a patch for that?
[18:01] <hallyn> jdstrand: (the mishandling of int in kvm.ko stopped restore from working)
[18:01] <jdstrand> ah, a kernel update
[18:01] <jdstrand> hallyn: is that in oneiric already?
[18:01] <hallyn> i'm not seeing anything in libvirt git tree for phys
[18:01] <hallyn> should be in o, yes
[18:01] <hallyn> (i haven't checked, but was told it was)
[18:02] <jdstrand> $ cat /proc/version_signature
[18:02] <jdstrand> Ubuntu 2.6.39-2.8-generic 2.6.39-rc7
[18:02] <jdstrand> still busted there ^
[18:02] <jdstrand> might be a different issue
[18:02] <jdstrand> istr finding a bug on it, but I can't locate it right now
[18:02] <hallyn> sigh, yup
[18:02] <hallyn> that's with libvirt 0.8 ?
[18:03] <jdstrand> pitti: thanks, I'll let kees handle it
[18:03] <jdstrand> hallyn: no, the new 0.9.1
[18:03] <hallyn> oh, ok
[18:03] <jdstrand> I can tell you it was busted with natty and 0.8 that is in release
[18:03] <hallyn> i suppose i need a debian box to test its libvirt on
[18:03] <apachelogger> tkamppeter: ah, sounds like something we should implement in upstream KDE then, thanks :)
[18:04] <hallyn> or, maybe better to test with daily build
[18:05] <jdstrand> hallyn: regarding phys, I looked in http://libvirt.org/news.html-- tons on phyp (I'm assuming those are the relevant changes)
[18:06] <tkamppeter> apachelogger, this would be great, best would be if both KDE and GNOME ship with a printing applet and the applets being compatible to each other.
[18:07] <tkamppeter> apachelogger, GNOME 3 comes with its own printing applet, but I do not know anything about its D-Bus interface.
[18:09] <hallyn> jdstrand: (wouldn't those be ones which are in th epackage?
[18:09] <hallyn> I see one phyp 'avoid a crash' post-0.9.1 in git changelog
[18:10] <jdstrand> hallyn: yes, presumaly they are in the package, and something is wrong cause I get:
[18:10] <jdstrand> error: Failed to attach device from /tmp/tmpSMveEB/device.xml
[18:10] <jdstrand> error: internal error unsupported driver name 'phy' for disk '/tmp/tmpSMveEB/device_disk.img'
[18:10] <hallyn> i'll look into it, thanks
[18:11] <jdstrand> hallyn: it might be an intentional change-- I don't know, but the test is there cause iirc euca and openstack attach physical devices
[18:11] <jdstrand> hallyn: and this could break them
[18:12] <apachelogger> tkamppeter: if the interfaces were specified somewhere that would probably help with that
[18:12] <jdstrand> hallyn: it is conceivable the restore/save failures are test suite failures-- please ignore those for the time being
[18:12] <jdstrand> hallyn: I'll look at that and the CVE test
[18:14] <pitti> ev: cheers
[18:14] <hallyn> jdstrand: cool, thanks.  i can trivially reproduce the phys one here  :)
[18:15]  * jdstrand nods
[18:15] <hallyn> btw, no need to smack me, i'm realizing i should've run the qatests, i'll smack myself
[18:15] <pitti> ev: thanks
[18:17] <ev> sure thing
[18:19] <tkamppeter> apachelogger, signals sent by CUPS should be no problem. They are defined in CUPS and the applets have to follow. The problems are signals from the printer setup tool and other utilities.
[18:21] <apachelogger> tkamppeter: yeah... though if they signals are all dbus signals it should be easy enough to introspect the existing ones and come up with a cross-desktopy spec (maybe also outside the com.redhat namespace ;))
[18:21] <tkamppeter> apachelogger, do you know how Plug'n'Print works in Kubuntu?
[18:22] <apachelogger> tkamppeter: you mean how well?
[18:22] <tkamppeter> In Ubuntu the system-config-printer-udev is installed which provides everything.
[18:22] <apachelogger> we have that too, Riddell wrote a KDE clone of system-config-printer
[18:22] <tkamppeter> apachelogger, how and how well.
[18:23] <apachelogger> it only misses the newPrinterNotification it seems
[18:23] <apachelogger> other than that plug'n'print works fine
[18:23] <tkamppeter> apachelogger, so the printers get set up if there is an exact driver match and no notification appears?
[18:24] <apachelogger> yep
[18:24] <jono> pitti, hey, just a quick FYI - I just reviewed https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-default-apps-unity-integration/ with Jorge, but you are the Approver and I inadvertently approved it - let me know if you are not happy with the approval, and we can adjust it
[18:25] <jono> I will be expecting jcastro to ensure the assignments here get completed
[18:25] <tkamppeter> This would once mean that users do not get aware of the automatic process and even worse if there is no exact driver match (for example if a driver is only available for auto-download from the internet) the printer setup tool does not pop up for interactive setup and so the printer stays without queue silently.
[18:26] <tkamppeter> apachelogger, ^^ so catching newPrinterNotification is very important.
[18:27] <apachelogger> eww
[18:28] <tkamppeter> apachelogger, does Kubuntu do automatic printer driver download with Jockey?
[18:28] <apachelogger> tkamppeter: I have not the slightest idea, JontheEchidna does jockey stuff
[18:28] <apachelogger> JontheEchidna: pingy pinlingy
[18:29] <JontheEchidna> pong
[18:29] <tkamppeter> JontheEchidna, does Kubuntu do automatic printer driver download with Jockey?
[18:29] <JontheEchidna> hmm, dunno. I've never seen it but I've never needed it
[18:29] <JontheEchidna> it should work, in theory
[18:29] <JontheEchidna> jockey has some nice backend/frontend separation
[18:29] <JontheEchidna> and the kde frontend should implement all the necessary bits
[18:30] <tkamppeter> JontheEchidna, can you run the command
[18:30] <tkamppeter> system-config-printer --setup-printer='file:/tmp/printout' --devid='MFG:Epson;MDL:EP-702A;'
[18:30] <tkamppeter> on your Kubuntu system?
[18:31] <JontheEchidna> hmm, I don't have that executable, it's part of the gnome package
[18:31] <tkamppeter> JontheEchidna, one minute please ...
[18:34] <tkamppeter> JontheEchidna, replace "system-config-printer" by the KDEish executable of system-config-printer.
[18:34] <JontheEchidna> it's not an executable, but a plugin for KDE's System Settings app
[18:35] <JontheEchidna> http://i.imgur.com/v3q2G.png
[18:35] <tkamppeter> JontheEchidna, can you do something like
[18:36] <tkamppeter> cd /usr/share/system-config-printer
[18:36] <tkamppeter> python newprinter.py --setup-printer='file:/tmp/printout' --devid='MFG:Epson;MDL:EP-702A;'
[18:37] <tkamppeter> JontheEchidna, I hope the debug modes for pretending that a given printer got detected are somehow implemented in the KDE incarnation of s-c-p.
[18:37] <JontheEchidna> !find newprinter.py
[18:38] <tkamppeter> JontheEchidna, you need to call the file where this functionality ended up for KDE.
[18:40] <JontheEchidna> I don't really know much about that
[18:40] <tkamppeter> Riddell, ping
[18:52] <Keybuk> pitti: I don't think that replacing TCL with Vala really helps :-/
[18:53] <pitti> Keybuk: why not?
[18:53] <pitti> it's about as fast as C, and avoids a runtime dependency
[18:53] <Keybuk> err, it adds a massive amount of runtime dependency
[18:54] <pitti> ?
[18:54] <Keybuk> libgobject, libgee, libgio, etc.
[18:54] <pitti> but we ship those anyway
[18:54] <Keybuk> you do
[18:54] <pitti> janimo's port uses gee and gio?
[18:54] <Keybuk> we don't
[18:54] <pitti> if you don't import anything, it should just depend on glib
[18:55] <Keybuk> glib is large
[18:57] <pitti> anyway, I don't personally mind what it's written in, as long as it's not something which requires a new runtime
[18:57] <Keybuk> yeah, agree
[18:57] <Keybuk> for us, glib is effectively a new runtime too
[18:57] <pitti> Keybuk: upstream mentioned python, that would be too big for you as well then, I guess?
[18:57] <Keybuk> it's not clear to me why the dispatcher is needed at all, since all it does is run the C program
[18:57] <Keybuk> right, we don't have Python
[18:57] <Keybuk> and that would be considered both a size problem and security problem, just like TCL
[18:58] <pitti> wow, you want usb 3G support, but don't have glib?
[18:58] <pitti> what kind of environment is that, OOI?
[18:58] <Keybuk> Chromium OS
[18:59] <pitti> sabdfl: TB meeting now?
[19:00] <sabdfl> pitti: en route
[19:14] <kees> 550 Changes file must be signed with a valid GPG signature: Verification failed 3 times: ["(7, 9, u'No public key')", "(7, 9, u'No public key')", "(7, 9, u'No public key')"] : Permission denied.
[19:14] <kees> anyone else seeing this on oneiric uploads?
[19:14] <pitti> kees: sometimes, but the upload works anyway if you use dput
[19:15] <kees> that error is from dput. :(
[19:17] <slangasek> kees: yes, the error is spurious - the upload succeeded anyway
[19:17] <kees> slangasek: oh, how ... odd
[19:17] <slangasek> yep
[19:17] <slangasek> the bug is filed against lp somewhere
[19:18] <kees> that's kind of alarming... can I upload stuff that doesn't pass signature tests too? >_>
[19:19] <slangasek> you can upload it, yes; it won't get accepted into the archive
[19:19] <slangasek> this is basically a new LP feature intended to check the signatures at upload time in order to give more immediate feedback in case of a problem
[19:19] <slangasek> it doesn't work right because the upload queue sometimes has the wrong keyring :)
[19:23] <kees> "wrong"? my key hasn't changed in months now...
[19:23] <kees> but okay, fair. early rejection is not an indication of later rejection. sounds good
[19:23] <james_w> I think wrong == empty
[19:34] <maco> kees: this is why i uploaded the same 0-day sru for natty 3 times :P
[19:34] <davmor2> james_w: your beer glass is wrong.........yeah I can see how that would work
[20:54] <kees> maco: hah, d'oh
[21:00] <nigelb> fta: ping, around?
[21:37] <ScottK> kees and slangasek: As I understand the error it's not that LP has the wrong key but that it's lost contact with the keyserver so it has no keys at all.
[21:38] <geser> doesn't it also happen when a tmp directory goes missing?
[21:39] <geser> bug 757248
[21:41] <ScottK> Nice.  OK.  That too.
[22:27] <cnd> ScottK, do you know where the "canonical" (not the company) source for the qt4-x11 packaging lives?
[22:28] <cnd> I've proposed my patch in the past, but it felt like I was doing it wrong by branching lp:ubuntu/qt4-x11 and proposing a merge request
[22:30] <ScottK> cnd: https://code.launchpad.net/~kubuntu-packagers/qt/ubuntu
[22:32] <cnd> ScottK, thanks!
[22:32] <cnd> so I should propose merge requests to merge into that branch?
[22:36] <ScottK> Yes and probably ping someone on #kubuntu-devel.
[22:37] <sebner> persia: contentless ping (email reminder) :)
[22:38] <cnd> ScottK, ok, will do
[22:39] <persia> sebner, heh.
[22:40] <sebner> persia: :D but don't worry, you can take your time
[23:50] <virhilo> hello
[23:51] <virhilo> the "-L/lib/x86_64-linux-gnu -L/usr/lib64 -L/usr/lib/x86_64-linux-gnu" directories are not in library path by default, i think they should be, or there shuld be symlinks from /usr/lib/x86_64-linux-gnu/libjpeg.so to /usr/lib
[23:51] <virhilo> should i create bug on it?
[23:52] <virhilo> the middle(-L/usr/lib64) one is problbly in library path i just coppied too much:)
[23:53] <slangasek> virhilo: what do you mean, "by default"?  They are certainly part of the library path in natty and oneiric for both gcc and binutils