[00:02] <Ampelbein> pace_t_zulu: in the glib i would suppose
[00:02] <pace_t_zulu> Ampelbein: thank you
[00:27] <pace_t_zulu> Ampelbein:  how do i test the package using pbuilder
[00:27] <pace_t_zulu> i followed the instructions to build
[00:28] <pace_t_zulu> what is unclear is how to test the newly built package
[00:46] <Ampelbein> pace_t_zulu: sorry, was offline for a moment. you can install the package created by pbuilder with 'sudo dpkg -i /var/cache/pbuilder/result/<packagename>'
[00:55] <pace_t_zulu> Ampelbein: to be clear, pbuilder is just for building clean debs...
[00:56] <Ampelbein> pace_t_zulu: right. it provides a clean build environment so you can check if the build-depends specified are correct. and it does not pollute your working system with unnecessary -dev packages.
[00:56] <pace_t_zulu> cool
[00:57] <pace_t_zulu> but it doesn't provide a safe testing environment
[00:57] <geofft> for that, for something on the order of gnome-panel, you want a VM or a live CD
[00:59] <Ampelbein> pace_t_zulu: what geofft says. i use virtualbox for testing such intrusive changes.
[00:59] <Ampelbein> pace_t_zulu: you can define snapshots so you can always revert to a clean state.
[00:59] <pace_t_zulu> yeah... i am coming to realize that
[00:59] <pace_t_zulu> i am running ubuntu in vmware fusion
[01:00] <pace_t_zulu> on a mac pro
[01:00] <SuperLag> I just wanted to tell you guys that Jaunty ROCKS. Thanks for your work.
[01:02] <pace_t_zulu> lesson learned about taking snapshots... i my have done a bit of damage... i think i can clean it up though
[01:33]  * calc bets he will be sick within the next day or two :-\
[01:33]  * calc hopes whenever it inevitably happens that he will be well before he has to leave for barcelona
[01:36] <pace_t_zulu> Ampelbein: thank you for your help... i am heading home from work... maybe see you later
[01:51] <cavedon> hi, what is the correct procedure to request a package removal from universe?
[01:52] <cavedon> (package superseeded by another one: i.e. changed name)
[01:52] <cavedon> fire a bug a subscribe ubuntu-archive?
[01:52] <cavedon> ...and subscribe...
[01:55] <DktrKranz> cavedon, file a bug with every detail needed to analize the request and subscribe ubuntu-universe-sponsors
[01:55] <cavedon> DktrKranz: tnx!
[01:56] <DktrKranz> :)
[03:18] <TurtlePie> how do I decrypt my key to sign the CoC
[03:18] <TurtlePie> i am stuck :(
[05:30] <pwnguin> when was the "leadership code of conduct" written?
[05:31] <jdong> what is the leadership code of conduct.
[05:31] <jdong> wow that question looks bad for me to be asking :-/
[05:31] <pwnguin> hah
[05:31] <pwnguin> http://www.ubuntu.com/community/leadership-conduct
[05:34] <jdong> cool, never noticed that
[05:34] <pwnguin> me either!
[05:34] <pwnguin> i was just looking up attribution on the normal CoC for some silly reason, and noticed this new thing
[05:35] <pwnguin> apparently archive.org found it may 2007
[05:36] <jdong> shame on me then :)
[05:36] <pwnguin> im not sure it was ever met with any fanfare
[05:37] <ScottK> I'm fairly certain I don't do so well on 'show more civility'.
[08:33] <mdke> pwnguin: 10 November 2006 - https://wiki.ubuntu.com/LeadershipCodeofConduct?action=info
[13:09] <geser> doko: do you know why python-distutils.mk from cdbs (karmic) renames dist-packages to site-packages?
[14:12] <calc> looks like we need to do a boost1.37 transition for karmic, 1.35 is requested for removal from Debian
[14:39] <lesshaste> hi.. my X restarted again spontaneously with this log http://pastebin.com/f4d283a92
[14:39] <lesshaste>  I thought i  had installed debug symbols.. what can I do to get a better backtrace for next time?
[14:44] <ScottK> calc: Debian is targetting 1.38 for squeeze.  Maybe go straight to that?
[14:45] <lesshaste> I have installed xserver-xorg-core-dbg  for example so I am mystified
[14:45] <calc> ScottK: ah yea probably a good idea
[14:46] <calc> ScottK: i just noticed the request for removal of 1.35 i didn't realize there was a 1.38 already
[14:47] <lesshaste> anyone got any ideas?
[14:58] <ScottK> calc: Not sure if it's through New yet.
[14:58]  * ScottK hasn't looked
[14:59] <calc> ok
[14:59] <calc> yea boost1.38 has been in debian for about a month
[15:01] <calc> do packages get removed semi-automatically from Ubuntu after being removed from Debian... except for cases where they are 0ubuntuX ?
[15:01] <calc> or how does that happen?
[15:01] <martijn933> lesshaste: you know https://wiki.ubuntu.com/X/Backtracing ?
[15:02] <lesshaste> martijn933: ah maybe I am missing the debug symbols specific to my driver you mean?
[15:04] <lesshaste> martijn933: which xserver-xorg-video-<name> do I need for the fglrx driver?
[15:05] <lesshaste> ah.. it's none of those right?
[15:09] <martijn933> sorry, can't help you any further on this
[15:09] <martijn933> just gave you the link in case you had not seen it
[15:14] <lesshaste> martijn933: ok thanks.. the top tip is to change to the open source driver of course
[15:14] <lesshaste> which I will do as soon as I can
[15:19] <lamont> I wonder how I tell the gimp to come up with the same window size as it had the last time, instead of the apparently new with jaunty "ZOMG YOU MUST WANT ME TO FILL THE SCREEN" belief
[15:40] <Riddell> pitti or asac: bug 369918 MIR is blocking KDE merges, able to take a look?
[15:41] <Riddell> I don't know if it even needs a MIR since as far as I can make out the code is also in cmake anyway
[15:42] <rickyb> Can anyone help me with an Ubuntu 9.04 display related problem - "Display Preferences" does not give me the correct refresh rate values
[15:42] <soren> rickyb: xmlrpc-c also includes a server implemention, doesn't it?
[15:44] <soren> Err...
[15:44] <soren> Riddell: xmlrpc-c also includes a server implemention, doesn't it?
[15:44] <rickyb> good question
[15:44] <soren> rickyb: Sorry, not fo you :)
[15:44] <rickyb> lol
[15:49] <Riddell> soren: I'm not sure on that, I havn't even worked out why cmake needs it
[15:57] <Chipzz> Riddell: it would also fix an other problem which I filed a bug for :)
[15:57] <Chipzz> (unrelated to kde though :P)
[15:58] <Riddell> Chipzz: moving it to main?
[15:58] <Chipzz> no :)
[15:58] <Chipzz> but it would be a side-effect I suppose :)
[15:59] <Chipzz> https://bugs.launchpad.net/ubuntu/+source/rtorrent/+bug/173850
[15:59] <Chipzz> https://bugs.launchpad.net/ubuntu/+source/xmlrpc-c/+bug/173848
[15:59] <Chipzz> filed allmost 1.5 years ago *ugh*
[16:41] <kirkland> cjwatson: hi there, i have a couple of ssh implementation questions for you ...
[16:41] <kirkland> cjwatson: thinking about encrypted-home and ssh public key authentication
[16:42] <kirkland> cjwatson: currently, we can't mount the home directory until the user enters their login passphrase through pam
[16:42] <kirkland> cjwatson: since the wrapped-passphrase file is symmetrically encrypted with the login passphrase itself
[16:43] <kirkland> cjwatson: however, i'd like to support something like a wrapped-passphrase.ssh
[16:43] <kirkland> cjwatson: which would instead be wrapped with an ssh private key
[16:44] <kirkland> cjwatson: so a user ssh'ing in via public key authentication, if the homedir is not mounted, would need to have pam_ssh pass pam_ecryptfs the incoming private key
[16:45] <kirkland> cjwatson: pam_ecryptfs would use that key to try and mount $HOME
[16:45] <kirkland> cjwatson: if that works, then kick back to pam_ssh, and let it check authorized_keys
[16:45] <kirkland> cjwatson: if that succeeds, PAM_SUCCESS or whatever
[16:46] <kirkland> cjwatson: if that fails, then we'd need to unmount $HOME first, and then PAM_FAILURE
[16:46] <kirkland> cjwatson: can you offer any thoughts/insight on this idea?
[16:49] <kirkland> slangasek: you might have some insight too...  See the last 10 minutes of cjwatson-directed messages :-)
[17:02] <asac> Riddell: looking
[17:03] <asac> Riddell: you say it was in cmake ... the dir mentioned in MIR isnt in cmake from jaunty
[17:03] <asac> oh sorry
[17:06] <asac> Riddell: do we need all binary packages in main?
[17:24] <dMoberg> How do I make my own gnome-panel applets?
[17:24] <dMoberg> I want the tmeperature from this site: http://www.frryd.se to show in the panel :)
[17:26] <Riddell> asac: no, just the library
[17:26] <Riddell> libxmlrpc-c3-dev and libxmlrpc-c3
[17:39] <asac> Riddell: lib*abyss does server sockets
[17:40] <Riddell> asac: what's that?
[17:40] <Riddell> I don't see abyss mentioned in xmlrpc-c
[17:41] <asac> Riddell: not sure. i would feel more comfortable if we could put the server libs to a separate binary package
[17:41] <asac> Riddell: libxmlrpc-c3
[17:41] <asac> err
[17:41] <asac> http://paste.ubuntu.com/162353/
[17:41] <asac> Riddell: ^^
[17:42] <Riddell> mm, I see /usr/lib/libxmlrpc_abyss.so.3.6.15
[17:42] <asac> yeah
[17:42] <asac> and there is also server*so
[17:42] <asac> and stuff
[17:42] <mnemo> dMoberg: "mkdir code ; cd code ; apt-get source gnome-panel ; cd gnome-panel-2.26.0/applets/fish ; gedit fish.c" but there is probably really nice step by step tutorials if you google for it, plus you can probably do in some nicer language like for example Vala
[17:43] <Riddell> asac: I wonder if it would be easier to juse go bck to using the xmlrpc from within cmake
[17:43] <asac> Riddell: running ldd on those suggests that they could be sorted to a separate lib. not sure what cmake would need from those
[17:43] <asac> Riddell: hmm
[17:43] <asac> Riddell: in general having the code in one place is worthwhile. but i think that such high-level server lib code needs security review
[17:46] <asac> Riddell: does the cmake code still exist?
[17:47] <asac> or was it removed upstream?
[17:48] <Riddell> asac: it's still in cmake
[17:48] <asac> Riddell: so just a drop of build depends and a change of a configure flag ? ... if so, i would think its better to do that
[17:49] <Riddell> asac: I think so, trying that now
[18:08] <Riddell> asac: uploaded without that as a build-dep
[18:08] <asac> Riddell: good
[18:53] <Riddell> asac: hmm, I screwed up
[18:53] <Riddell> asac: it doesn't compile without xmlrpc-c
[18:53] <Riddell> that's what I get for compiling two things at the same time
[18:54] <Riddell> I can separate out the libraries it doesn't use though
[18:54] <Riddell> -lxmlrpc -lxmlrpc_util -lxmlrpc_xmlparse -lxmlrpc_xmltok is what it needs
[18:54] <asac> Riddell: yeah. that would make me feel comfortable ... e.g. moving server, abyss stuff to a separate pkg
[19:49] <rom> hi
[19:49] <rom> will this critical bug fixed soon : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/346691
[19:49] <rom> it makes jaunty final worse than an alpha1 release
[20:07] <slangasek> kirkland: what exactly do you mean by "pass pam_ecryptfs the incoming private key"?  I'm not sure how to map that statement to what ssh actually does...
[20:12] <calc> anyone around that can sync some packages for me... please? :-)
[20:15] <mdz> slangasek: I'm not seeing xserver-xorg-video-intel binaries in -proposed, despite your comment on 359392 (only source)
[20:16] <slangasek> mdz: the comment is the generic template generated by the sru-accept script, it doesn't take into account that all the SRU builds are currently backlogged because of the karmic archive opening :(
[20:16] <slangasek> mdz: if you're in a position to bump the build scores, that would be welcome
[20:16] <infinity> slangasek: What needs abusing?
[20:17] <slangasek> infinity: xserver-xorg-video-intel, linux, compiz in jaunty-proposed could use build scores bumped
[20:17] <infinity> slangasek: On it.
[20:17] <slangasek> cheers
[20:17] <mdz> I'll leave it to infinity
[20:19] <mdz> slangasek: will that wait for a publisher cycle, or does it come right out ppa-style?
[20:20] <slangasek> mdz: binary availability? subject to the publisher cycle
[20:20] <infinity> mdz: Of course, you can snag it from the librarian immediately, if you're in a hurry.
[20:22] <mdz> infinity: I will, though I'm hoping to get it to the huddled masses ASAP
[20:22] <bryce> thanks guys
[20:22] <mdz> the subscriber list on that bug is as long as my arm
[20:22] <infinity> mdz: They will, sadly, be huddling for another hour and a half or so. :/
[20:23] <infinity> (Oh how I miss 30 minute cron.dailies...)
[20:23] <mdz> infinity: does launchpad's 'estimated build time' mean much of anything at all?
[20:23] <mdz> 'estimated build start' I mean
[20:23] <infinity> mdz: It's based on queue order and stuff that it feels you're stuck behind.
[20:24] <infinity> mdz: Which arch/package has you unhappy?
[20:24] <mdz> infinity: they're both building now
[20:24] <infinity> mdz: I may have accidentally queued a "linux" before the video driver on one arch...
[20:24] <mdz> they just said "estimated build start: 1 minute" for about 10 minutes
[20:24] <mdz> oh, my mistake, i386 is building but not amd64 (the one I need)
[20:25] <mdz> it says "estimated build start: 0 seconds ago"
[20:25] <mdz> ah, now it's started
[20:25] <infinity> mdz: Oh, yeah.  The code that estimates that has no clue whatsoever about the fact that buildd-manager takes its sweet time scanning the buildds. :/
[20:26] <infinity> mdz: Things have improved drastically since the old slave-scanner, but "drastic improvement" over "30 minutes to iterate over all the buildds when they're not all idle" isn't saying much.
[20:29] <infinity> mdz: Should be built and uploaded now, FWIW.
[20:30] <mdz> slangasek: binaries awaiting acceptance
[20:30] <slangasek> mdz: ok - that should be entirely automatic, just needs a publisher cycle
[20:31] <infinity> Hahaha.  I get an OOPS trying to load that bug.  How many "me toos" does it have?
[20:31] <infinity> Oh, there we go.
[20:32] <mdz> infinity: there's no link to the librarian entry at https://edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/2:2.6.3-0ubuntu9.1/+build/982845
[20:32] <mdz> maybe that doesn't work for -proposed?
[20:32] <infinity> It claims they want to be accepted.  That's... Odd.
[20:33] <slangasek> hmm, indeed
[20:33] <slangasek> looks like a UI bug, though
[20:33] <infinity> They're definitely not in the queue though.
[20:33] <infinity> UI bug indeed.
[20:33] <infinity> Annoying.
[20:33] <mdz> could one of you file it?  I'm not sure I can describe the problem fully
[20:34] <LaserJock> man, Jaunty's only been out like a week and there's 68 .debs in -proposed
[20:34] <slangasek> mdz: yep
[20:35] <mdz> thanks
[20:35] <mdz> LaserJock: I count *1*68
[20:36] <LaserJock> well, I meant I had 68 updates
[20:36] <LaserJock> should have been clearer
[20:36] <LaserJock> but still, that's quite a lot of fixing in a week
[20:41] <slangasek> mdz: bug #370529
[20:42] <mdz> slangasek: thanks.  I'm pretty sure I've run into this before without knowing what was going on.
[20:43] <infinity> slangasek: Yeah, it's definitely related to the bug fix you noted.
[20:43] <infinity> slangasek: "RF 7590. Ensures that builds have a package upload in the 'DONE' state before providing links to the binary package publishing record"
[20:43] <slangasek> ah, doh
[20:43] <infinity> slangasek: And the builds aren't "DONE" until the publisher queues them for on-disk publication.
[20:43] <slangasek> indeed
[21:01] <athasm> ?DCC SEND "ff???f?" 0 0 0