[01:22] <imbrandon> ok forgive my ignorance and being lazy for a moment if you will and will someone give me the 1 - 2 sentance explination as to what "Zeitgeist" as it pertains to gnome ?
[01:22] <imbrandon> a program ? language ? abstration layer ? ....
[02:14] <ScottK> Time sequenced activity history.
[02:47] <arand> imbrandon: awesomeness! (ScottK's answer is short and to the point), It's (afaik) a back-end that creates associations, time, program, place, activity, so that you later on could find out, say, what Kind of music you listened to whilst chatting with a particular person... Is one of the things it can do.
[03:13] <imbrandon> ScottK / arand : ahh like a personal google, sorta
[03:13] <imbrandon> seems intrusive and expensive ... maybe i'm wrong
[03:14] <arand> imbrandon: Yea, but so is google And that has it's uses.
[03:14] <imbrandon> :)
[03:14] <amason_> imbrandon: really up to you if you use it or not.
[03:15] <imbrandon> very true, just was curious i have seen alot of blogs about pieces of it lately but not much on what "it" was
[03:15] <imbrandon> something i can poke into more later ;)
[03:25]  * imbrandon yawns
[03:25] <imbrandon> ugh i have code to write tonight but i just cant motivate myself
[03:25] <imbrandon> hum de dum
[08:58] <BlackZ> how can I delete an old deactivated key from the ubuntu's keyserver?
[08:59] <jpds> BlackZ: That's impossible.
[09:01] <BlackZ> jpds: ok, BTW I have updated the key (e-mail), but I can still seen the old e-mail on ubuntu's keyserver, is that normal?
[09:01] <jpds> Did you remove the old email?
[09:01] <BlackZ> yeah
[09:01] <jpds> Yep, that's also impossible.
[09:02] <jpds> You can only add to keyservers, never remove.
[09:02] <BlackZ> jpds: also, I have signed some uploaded packages with the old key and e-mail, is that a problem?
[09:03] <jpds> Shouldn't be.
[09:03] <BlackZ> jpds: however that is updated in my launchpad's page
[12:22] <arand> chrisccoulson: Hia, talked on friday, BitlBee.. got time over to sponsor Bug #581331 ?
[12:22] <chrisccoulson> arand - oh yeah, sorry, i forgot about that one
[12:22] <chrisccoulson> has nobody else done it yet?
[12:22] <chrisccoulson> i will look at that in a bit
[12:23] <arand> chrisccoulson: Nope :( seems few sponsors are around here on the weekends, or they just didn't like me..
[12:28] <BlackZ> arand: I'm sure your work will be sponsored soon, keep in mind you're in a queue :)
[12:33] <arand> BlackZ: Yea, true. # of bugs with patches are a hefty amount.
[12:34] <BlackZ> ara: I know and I think they will be sorted out ASAP
[12:34] <BlackZ> err, arand - sorry, ara
[12:43] <BlackZ> arand: why is the bug still assigned to you? why is it "Fix Released" instead of "Confirmed", for example?
[12:46] <arand> BlackZ: Fixed in maverick with version 1.2.7, this is for hardy..lucid, what's the policy as far ass assignments go actually, I though, since I was "in charge" of packing the SVN fix, it would be appropriate, no?
[12:47] <arand> *as *thought
[12:50] <BlackZ> arand: since ~ubuntu-sponsors is subscribed, you have to follow https://wiki.ubuntu.com/SponsorshipProcess
[12:50] <BlackZ> for example. "Do not assign a bug to anyone if it needs sponsorship."
[12:52] <BlackZ> s/./,
[12:54] <arand> BlackZ: Ah, hmm, I was going by that I've had been assigned to bugs (by others) in similar cases before. Right, so unassigning then.
[13:15] <Migi32> don't know if this is the right channel, but I would like to inform you that Boinc in the default repositories is horribly out of date, and that I'm forced to install the latest version manually
[16:32] <kobrien> greetings. I packaged my app and it compiles fine. I just need  to figure out how to get it to place the compiled files into  /usr/bin and such. Do I do it in debian/rules? Please advise
[16:52] <persia> kobrien: So, there's two ways to do it.  If you're the upstream developer, it's best to do it in your build script, with an install rule.  For example, `make install`
[16:52] <persia> If you're not upstream, you can work around a buggy set of build scripts with dh_install
[19:15] <micahg> siretart: should I reassign the gxine bug to you?
[19:21] <micahg> siretart: wrapper looks fine I think it should go to maverick first though
[19:24] <lfaraone> One of my mails was flagged as possible spam to the mailing list. Shouldn't we set SpamAssassin to look kindly on GPG-signed mails? :)
[19:28] <siretart> micahg: feel free to do so. what about copying it from lucid-proposed to maverick?
[19:31] <siretart> how do ppl feel breaking maverick's ffmpeg at this point? ;-)
[19:32] <micahg> siretart: I currently cannot push packages yet.  As for copying, idk what the current policy is, but I think that fixes are supposed to go into the devel release first again
[19:32] <micahg> siretart: what will break with ffmpeg?
[19:33] <siretart> micahg: upload ffmpeg 0.6 will probably break quite some applications that link against it
[19:33] <micahg> siretart: ah
[19:33] <siretart> no idea how severe the breakage will be, I did not do testbuilds
[19:33] <siretart> but I guess I should do so in any case. soon.
[19:34] <micahg> siretart: so, do you want me to find a sponsor for gxine, or do you want to push/
[19:35] <siretart> I can do the upload later today
[19:35] <micahg> siretart: k, thanks, I'll reassign to you
[19:37] <micahg> siretart: I'll subscribe to the package to watch for regressions
[19:37] <siretart> great, thanks!
[19:38] <micahg> siretart: thanks for making the wrapper :)
[20:14] <toabctl> hi
[20:15] <toabctl> i want to build a package with pbuilder but have a dependecy on a local package version. how to solve this?
[20:16] <tumbleweed> toabctl: easiest way around that is to create a simple local package repository
[20:17] <toabctl> ok
[20:17] <toabctl> thx
[20:17] <geser> or login into pbuilder, copy all needed files inside and build there manually
[20:18] <tumbleweed> yes, that's easier for once-off
[20:18] <geser> I do it when I need to do it only once (was too lazy to setup a repo for just one build)
[20:20] <toabctl> geser, where is the pbuilder .tgz file extracted?
[20:20] <toabctl> i got the following error when i use "pdebuild": Aptitude couldn't satisfy the build dependencies
[20:20] <geser> usually below /var/cache/pbuilder/build/ (see the output when calling pbuilder)
[20:21] <toabctl> geser, /var/cache/pbuilder/build is empty
[20:21] <geser> yes as it gets cleaned up after pbuilder has finished
[20:21] <toabctl> Reading task descriptions...
[20:21] <toabctl> Aptitude couldn't satisfy the build dependencies
[20:21] <toabctl> E: pbuilder-satisfydepends failed.
[20:21] <toabctl> I: Copying back the cached apt archive contents
[20:21] <toabctl> I: unmounting dev/pts filesystem
[20:21] <toabctl> I: unmounting proc filesystem
[20:21] <toabctl> I: cleaning the build env
[20:21] <toabctl> I: removing directory /var/cache/pbuilder/build//11519 and its subdirectories
[20:22] <toabctl> geser, tumbleweed : that's my output. i try to build a new version of syncevolution for DIST=sid under ubuntu lucid
[20:22] <geser> "pbuilder login" and you get a directory below /var/cache/pbuilder/build as long as don't exit the pbuilder
[20:23] <toabctl> geser, ah. that works. thanks. and do you know what i can do against the error?
[20:24] <geser> check which dependency couldn't get resolved (and why) and fix it
[20:25] <toabctl> pbuilder-satisfydepends-dummy: Depends: libsynthesis-dev (>= 3.4.0.5~) but it is not going to be installed.
[20:25] <toabctl> geser, what does the 4.3.0.5~ mean (especially the ~) ?
[20:26] <geser> this is a versioned dependency on libsynthesis-dev. The package needs a version greater than the specified
[20:27] <geser> and the ~ has a special meaning in Debian version numbers (it sorts below any other char)
[20:28] <tumbleweed> the ~ allows it to be satisfied by a backport. Backports have ~ to make 3.4.0.5~bpo a lower version htan 3.4.0.5
[20:29] <toabctl> hm. then i don't understand the error. libsynthesis-dev is available in version 3.4.0.5 in debian sid.
[20:31] <geser> login into your sid pbuilder and try to install it. don't know about aptitude, but apt doesn't tell the real error (down the dependency chain) but only that a dependency of the package you want installed, can't get installed
[20:33] <toabctl> geser, i had to do a "apt-get update" before i can install the package. pbuilder doesn't do this automatically?
[20:33] <geser> no, "pbuilder update" does it (updates the whole base.tgz including the Packages files)
[20:34] <toabctl> ah. "pbuilder update" does this.
[20:34] <toabctl> geser, thanks!:)
[20:35] <tumbleweed> you can add a pbuilder hook to apt-get update before each build
[20:35] <tumbleweed> there's such a script in the examples directory, IIRC
[20:36] <bdrung> ari-tczew: ping
[20:44] <ari-tczew> bdrung: pong
[20:51] <bdrung> ari-tczew: am i allowed to do the fakesyncs (bug #512430) under my name? this would be faster for me.
[20:52] <ari-tczew> bdrung: I'm not happy for hearing this.
[20:52] <bdrung> ari-tczew: the alternative would be patch dch
[20:52] <bdrung> dch is not able to sponsor a changelog
[20:53] <bdrung> but i am not a perl hacker
[20:54] <ari-tczew> bdrung: you know, I need these uploads this time. I'll be owe to you.
[20:54] <bdrung> ari-tczew: you need them?
[20:54] <geser> bdrung: DEBFULLNAME="foo bar" DEBEMAIL="foo@baz" dch ... doesn't work?
[20:54] <persia> Nobody ever needs uploads.
[20:55] <fabrice_sp> bdrung, I had to add a -k option to the ack-sync script to pass the signing key to syncpackage
[20:55] <persia> Upload count isn't especially meaningful, especially if those are from syncs.
[20:56] <ari-tczew> yea, same method like uploading merges
[20:56] <bdrung> geser: DEBFULLNAME and DEBEMAIL should be only set for this command. let me look at the code...
[20:57] <geser> and if one needs those fakesyncs for the sponsored upload count, then I'm not sure if one is ready to apply
[20:57] <bdrung> geser: he has done enough (sponsored 40 - 50 packages for him)
[20:59] <geser> it was more generally speaking
[20:59] <fabrice_sp> bdrung, should I push the change or you have something similar locally?
[20:59] <geser> and in this case the few not counted fakesyncs shouldn't matter
[20:59] <bdrung> fabrice_sp: you can push - i have no local changes
[21:00] <fabrice_sp> ok
[21:04] <ari-tczew> geser: I could be late for tomorrow's meeting, because we have flood in country and can be public communication problems.
[21:04] <ari-tczew> s/geser/persia
[21:06]  * micahg hopes they get to my item in the meeting :)
[21:07] <geser> micahg: the "Mozilla Uploaders Package Set"? it's on the agenda
[21:08] <micahg> geser: yes, but the mail to the list wasn't approved till Friday so I was worried that it might not be on the actual agenda
[21:21] <micahg> \sh: zf 1.10.5 most likely tomorrow, so I guess you don't have to push 1.10.4
[21:31] <ari-tczew> bdrung: what's next about fakesyncs?
[21:55] <bdrung> ari-tczew: i have to improve the syncpackage script and use your bug for testing
[21:56] <ari-tczew> bdrung: okay! fine!
[23:13] <SpamapS> guidance for naming a perl package.. if the CPAN module is Memcached::libmemcached ... the package still must be named this rather silly name:   libmemcached-libmemcached-perl .. yes?
[23:15] <JontheEchidna> I have seen libxml-libxml-perl in the archive
[23:16] <JontheEchidna> So there is precedent, even if it is silly
[23:18] <SpamapS> I actually like it
[23:19] <SpamapS> I've installed many a perl module just by typing the transformed name after apt-get install.. its like a pleasnt surprise "yes, this is going to work today"
[23:21] <ScottK> SpamapS: libmemcached-libmemcached-perl is correct.  If you want to get it into Ubuntu, it would probably be easier to talk to the pkg-perl people in Debian since they sponsor new perl stuff all the time.
[23:25] <SpamapS> ScottK: will do.
[23:37] <arand> In metacity, (and other gnome packages?) If you add a patch, should it be added before 90_autotools.patch and 99_ltmain_as-needed.patch in the series?
[23:42] <pochu> arand: yes
[23:44] <pochu> 90_autotools is to regenerate autotools file because of other patches, so it goes last, and 99_ltmain_as-needed goes after 90_autotools because it modifies a file autogenerated by 90_autotools, so if it went before, it would have no effect
[23:44] <arand> pochu: aha, hm, is this documented anywhere? (news to me at least)
[23:51] <arand> pochu: Right, it makes a lot of sense with the numbering, although, I've so far simply followed the ubuntu packaging guide by the letter, and used "quilt push -a && quilt new" regardless (slightly annoyed that some evil person had already taken all numbers in the patch prefixes :D), do over and do right, it seems...
[23:54] <pochu> you don't want to do that in these cases then :)