[00:01] <diwic> sladen_, sure, but debuild rebuilds from scratch and takes lots of time. I'm just trying to be more productive by running "make" instead (which takes a few seconds when you've only changed one source file)
[00:02] <micahg> diwic: debuild -nc
[00:05] <diwic> micahg: thanks, that seems to go much faster, still not as fast as make though (it seems to do "relinkning" of some kind)
[00:06] <diwic> and then all the dh_ stuff at the end
[00:06] <diwic> also, with make I can use "make -j3" to make it faster on my triple-core CPU, is that possible with debuild as well?
[00:08] <Laney> you can pass -j to debuild
[00:08] <Laney> -jX
[00:10] <diwic> Laney, nice :-)
[00:13] <diwic> Laney, perhaps I should study the man pages for dpkg-buildpackage and debuild closer
[00:14] <crimsun> diwic: install and configure ccache, too. You may also want to put /var/cache/pbuilder/build on tmpfs
[00:14] <crimsun> diwic: and ~/.ccache
[00:17] <diwic> crimsun, thanks for the tip :-)
[00:22] <diwic> crimsun, btw, Jaroslavs wakeup patches are in Lucid now, right?
[00:22] <crimsun> diwic: no
[00:23] <diwic> crimsun, how come?
[00:23] <crimsun> they're only available in linux-alsa-driver-modules in ppa:ubuntu-audio-dev
[00:23] <crimsun> a bit too intrusive
[00:23] <diwic> ok
[00:24] <crimsun> I really wish I had access to some surround sound hardware; it's a pain to debug this pulse business remotely :(
[00:24] <crimsun> and I'd like to stab cs46xx hardware for being so busticated. Even worse than many HDA controllers, which is flippin' impressive!
[00:25]  * crimsun wanders off toward cs46xx_lib.c
[00:25] <jayvee> Laney: honestly surprised that debuild doesn't default to something like -j2.
[00:26] <diwic> crimsun, as for the stabbing, that's also hard to do remotely ;-)
[00:34] <wzssyqa> hi,i am using debian format v3,and have a patch in debian/patches.how to edit rules?
[04:25] <Linux000> How would I write a script to run at install time(like the triggers) when installing a Debian package(.deb)?
[04:26] <micahg> PKGNAME.preinst or PKGNAME.postinst
[04:26] <RAOF> Linux000: preinst, postinst, prerm, postrm are the four scripts that do that.
[04:26] <Linux000> Thanks
[04:27] <Linux000> Where would I put those?
[04:29] <Linux000> Nevermind, google always helps:)
[04:32] <RAOF> micahg: Any joy on the gjs front?
[04:35] <micahg> RAOF: sorry, no haven't had a chance yet..spent an hour on another build failure w/out a solution though....
[04:35] <RAOF> :(
[04:35] <RAOF> Ok.
[04:36] <RAOF> I'll upload work-around packages now then.
[04:36] <micahg> RAOF: yeah, probably a good idea
[04:38] <RAOF> Why do IDEs feel the need to have splash screens?
[04:38] <micahg> RAOF: so people don't think nothing is happening?
[04:38] <RAOF> Then start up faster, damnit!
[04:39] <micahg> RAOF: that would be nice :)
[04:40] <RAOF> Also... not a monospace font?  What crack are you smoking, anjunta?
[04:40] <RAOF> Oh, well.  It obviously heard me.  Merely loading up the preferences pane sets a monospace font.
[05:02] <micahg> what's the way to manually do a merge?
[05:05] <RAOF> Grab the ubuntu bzr tree, grab the sid bzr tree, bzr merge.
[05:06] <RAOF> That's one option.  Alternatively, you can grab the respective source packages and manually merge the changes; meld is good for that if you go that route.
[05:07] <micahg> RAOF: are there branches for experimental?
[05:08] <RAOF> I think there are, yeah.
[05:08] <RAOF> Give it a try! :)
[09:39] <jariq> I am trying to build a package of daemon that depends on libraries/packages that are not included in ubuntu repositories. I made packages for libraries but I am not sure how to tell pbuilder to first install these libraries when building daemon package. Any help is appreciated.
[09:44] <persia> jariq: You need to put them in some repository that pbuilder can access from the sources.list in the chroot.
[09:44] <geser> you need a repository with them (can be a local one, a PPA or completely external)
[09:45] <jariq> I thought the same.. thanks a lot
[09:46] <geser> or alternatively build the package manually (dpkg-buildpackage -b) inside the pbuilder (as I'm lazy and need the new packages only once or twice)
[10:55] <mok0> Riddell: ping
[10:58] <\sh> bdrung, are you planning a sync from debian to ubuntu regarding eclipse 3.5.2?
[10:59] <bdrung> \sh: yes
[11:04] <\sh> bdrung, nice :)
[11:04] <mok0> OT: Do you like the fantasy of 5-year old boys? Check out http://axecop.com it's hilarious. I am still chuckling after exploring the site this morning...
[11:36] <Riddell> mok0: you pung?
[11:37] <mok0> Riddell: yeah, it's about bug 533042
[11:38] <mok0> Riddell: where can I see the backport script?
[11:38] <ScottK> mok0: Sorry for missing the backporters meeting yesterday.  Right as it was starting I get side tracked by a $WORK phone call.
[11:38] <mok0> ScottK: I realized something like that had happened
[11:39] <mok0> ScottK, but siretart and myself had a good chat :-)
[11:39] <mok0> I will schedule a new meeting in a couple of weeks. Need to check out easter and such first
[11:40] <ScottK> mok0: The big issue we have compared to Debian backports is the lack of not automatic.  There was a spec to change this for Lucid, but mvo did not have the time for it.
[11:40] <mok0> ScottK, I see
[11:41] <mok0> ScottK, still a good idea. But we need to make sure that the guis play nice with it
[11:41] <ScottK> So we have to enforce backports should just work, meaning rdepends have to work.
[11:41] <ScottK> For Debian, they don't insist on that.
[11:41] <mok0> I see
[11:41] <ScottK> It means easier backporting, but if you just install everything from backports, there will be problems.
[11:42] <ScottK> This is OK for them due to not automatic and also they aim at a more technical user base.
[11:42] <mok0> I think there is no easy solution
[11:42] <mok0> We need to stay away from some very basic components
[11:42] <ScottK> My experience with this is it takes some dedication to testing.
[11:43] <ScottK> In the case of bzr, the bzr developers keep a PPA.  It'd be nice to engage them and see if that could be used as a staging/testing area for backports.
[11:43] <mok0> ScottK, yes, otoh, there aren't many bug reports on backported packages
[11:43] <ScottK> mok0: Yes, but that's because we've insisted on at least basic testing.
[11:43] <mok0> ScottK:  it is already, they provide a bunch of backports
[11:44] <ScottK> Right, but use that as a gateway to Ubuntu backports.
[11:44] <ScottK> Test it there and then get it in  Ubuntu backports
[11:45] <ScottK> I did once give in and allow an svn backport without testing all the rdepends.  There were a LOT of bug reports over that one.
[11:45] <mok0> ScottK, I am concerned that things will not happen if the procedure is too convoluted
[11:46] <ScottK> It turns out the ones we tested weren't the ones affected by the ABI changes.
[11:46] <ScottK> Agreed.
[11:46] <mok0> There is not way we can guarantee that there won't be any problems, and that is made quite clear when backports is activated
[11:47] <mok0> -> no way
[11:47] <ScottK> Certainly.  It's a balance of risk and benifit.
[11:47] <ScottK> OTOH, with the ongoing clamav effort I'm involved in, https://wiki.ubuntu.com/MOTU/Clamav - we've gained experience to know where we have to test every single package and where we can test just a few.
[11:48] <mok0> ScottK, what exactly do you mean by "testing"?
[11:48] <mok0> ScottK, because it is really hard to check every aspect of a piece of software
[11:48] <ScottK> So I think, for the example of bzr, the bzr devs could likely tell us where the risks are and what needs to be updated with bzr/tested.
[11:49] <mok0> ScottK, I agree
[11:49] <Riddell> mok0: groovy, sorted
[11:49] <ScottK> mok0: For backports, the standard has always been builds, installs, runs.  I think that's enough testing.
[11:49] <mok0> Riddell: cool, thanks!
[11:49] <ScottK> Generally if it's going to explode, it does it right away.
[11:50] <ScottK> We test things a lot more thoroughly for clamav, but I don't suggest we require that as a general case.
[11:50] <mok0> ScottK, wrt bzr, the main app works in my hands. I've used the same port for weeks without problems.
[11:50] <mok0> ScottK, it's the plugins that need testing
[11:50] <ScottK> mok0: OK, find out from the bzr people what needs to be updated with it and then see about getting them tested.
[11:51] <ScottK> I doubt it will take long once you find out which ones they are.
[11:51] <mok0> ScottK, My ambition is to use exactly those packages that the bzr team has for hardy in their ppa
[11:51] <mok0> It's a handful only
[11:51] <ScottK> mok0: I suspect that's the right list.  I'd just like to get someone from bzr to say that.
[11:51]  * ScottK nudges lifeless.
[11:52] <mok0> ScottK, I will see if I can get hold of one of those guys
[11:52] <ScottK> IIRC I just poked at one.
[11:52] <mok0> ScottK, hm, nomen est omen
[11:52] <mok0> "lifeless"
[11:53] <mok0> :)
[11:56] <hakaishi> Hi, is there a way to remove a package from revu?
[12:00] <hakaishi> is there?
[12:00] <hyperair> you can archive
[12:02] <hakaishi> hyperair: to archive doesn't mean it'll be removed...
[12:02] <hyperair> hakaishi: it'll be removed from the front page/main listing
[12:03] <ScottK> hakaishi: Once it's archived, there's an option to nuke the package entirely.  You may have to ask someone else to do this if you don't have it available to you.  Archive it first to see.
[12:03] <hyperair> hakaishi: but otherwise, no,  i don't think there's a way to remove it
[12:03] <hyperair> oh there is?
[12:03] <hyperair> =O
[12:04] <hakaishi> ScottK: I have tried this nuke option a view times, but it's still there. It doesn't seem to change anything at all...
[12:04] <ScottK> hakaishi: What package?
[12:05] <hakaishi> ScottK: qt-shutdown-p. It's uploaded to debian and already has a newer version
[12:05] <ScottK> hakaishi: Checking.
[12:06] <hakaishi> ScottK: In Debian I've had to rename it. It's now called qshutdown
[12:06] <ScottK> OK.
[12:06] <hakaishi> http://packages.qa.debian.org/s/shutdown-qapps.html
[12:09] <hakaishi> ScottK: http://revu.ubuntuwire.com/p/qt-shutdown-p
[12:10] <ScottK> hakaishi: I tried to nuke it too and it wouldn't go.  I wouldn't worry about it too much, as long as it's archived, it won't get reviewed.
[12:10] <ScottK> We need a REVU admin to figure out why it won't go away.
[12:10]  * persia looks
[12:10] <ScottK> mok0: Are you a review admin?
[12:11] <mok0> ScottK, yes
[12:11] <ScottK> Ah.  nevermind mok0, persia got to it first.
[12:11] <persia> More eyes don't hurt :)
[12:11] <persia> Nuked fine for me.  Dunno.
[12:12]  * mok0 < lunch
[12:12] <persia> Can anyone else see it?
[12:12] <ScottK> permissions issue?
[12:13] <persia> Quite possibly.
[12:13] <hakaishi> thank you persia. Thank you all ^^
[12:13] <persia> Would need a REVU Hacker to dig through the logs to be sure.
[12:13] <ScottK> It's gone now.  That's for sure.
[12:13] <persia> Yes.  Very gone.
[12:14] <hakaishi> see you, bye bye :)
[12:40]  * mok0 > burp
[12:40] <mok0> Did you solve the REVU problem?
[12:41] <mok0> Ah yes good
[12:41]  * mok0 < coffee
[13:30] <lfaraone> If a package has a patch applied in Ubuntu, and the patch was applied upstream in Debian (with no other changes on Debian's side) does it make sense to request a sync or should we wait for A) the next cycle or B) when they make some important changes :)
[13:32] <persia> Either A) or B), whichever comes first.
[13:32] <persia> otherwise it's just a waste of archive-admin time.
[13:34] <nigelb> what does the Replaces: filed in control file do?
[13:40] <persia> nigelb: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
[13:40]  * nigelb fails at hunting through docs
[14:02] <filip> hi :)
[15:39] <filip> any ideas why this pinning doesn't work: http://pastebin.com/ZvzbNXmr ?
[15:39] <filip> it does on another machine just fine, and I am unable to spot the difference
[15:42] <geser> missing Release file perhaps?
[15:47] <filip> geser: I do have it in the archive
[15:47] <filip> geser: and I am able to install things from this archive
[15:49] <geser> and both machines have the same Release file? (as I see it's a file:-repository)
[15:50] <geser> did you run "apt-get update" after pinning? (not sure if it's needed but I needed also some attempts will it worked when I last setup pinning)
[15:51] <filip> geser: yes I did
[16:15] <jariq> This may not be the right channel but I know there are C gurus here :) I've got a huge problem: My_app uses openssl1.0 as shared library and also uses unixodbc as shared library. Unixodbc loads postgresql driver that depends on OTHER VERSION of openssl0.9.8. And that is the point where my app segfaults. Any ideas how to fix this? Why can't my program use two versions of same shared library? Scheme is: openssl0.9.8 <---> pgsql <
[16:21] <geser> you don't need a C guru a library expert
[17:45] <nigelb> debian bug 515054
[17:46] <nigelb> A fix was reported in debian last year.  Is this worth an nmu so we can sync it next time?
[18:21] <nigelb> can someone guide me on changing to source format 3.0 on a package?
[18:25] <shadeslayer_> nigelb: like changing from old format to 3.0 or vice versa?
[18:25] <nigelb> old format to 3.0
[18:25] <shadeslayer_> nigelb: ah no idea there :)
[18:26] <shadeslayer_> nigelb: #ubuntu-packaging might know how tho
[18:26] <nigelb> I didn't know there existed such a channel
[18:26] <shadeslayer_> nigelb: its a shiny new channel
[18:26] <shadeslayer_> nigelb: a closely guarded secret
[18:27] <shadeslayer_> nigelb: its quiet most of the time but youll probably get a answer here or there
[18:27] <nigelb> I'll stick here since there is a chance of someone reading scroll back
[18:28] <hyperair> nigelb: echo '3.0 (quilt)' > debian/source/format
[18:28] <hyperair> nigelb: that's all there is to it.
[18:28] <hyperair> nigelb: well there's also the de-patch-system-ization
[18:28] <shadeslayer_> hyperair: really? i knew that but wasnt sure :P
[18:29] <nigelb> hyperair: thats exactly that I want, modifying the rules file
[18:29] <hyperair> shadeslayer_: yeah, that's all there is to it, but if you have a patch system, you have to remove it.
[18:29] <shadeslayer_> hyperair: and is there a doc on the new rules file?
[18:29] <nigelb> the package uses quilt now
[18:29] <shadeslayer_> all the new stuff with dh and dh --with-quilt
[18:29] <hyperair> nigelb: use a quilt patch system, drop whatever patch system build-dep in the debian/control, and remove any patch/unpatch things in debian/rules
[18:30] <nigelb> thats it?
[18:30] <hyperair> shadeslayer_: --with=quilt
[18:30] <hyperair> nigelb: yes.
[18:30] <nigelb> o_0
[18:30] <hyperair> shadeslayer_: and you should get rid of that when going to 3.0 (quilt)
[18:30] <shadeslayer_> hyperair: oh yes... im new to the format
[18:30] <shadeslayer_> ok
[18:30] <hyperair> nigelb: dpkg-source will take care of the rest.
[18:30] <hyperair> nigelb: the next time you debuild or whatever, it'll generate a 3.0 package.
[18:30] <shadeslayer_> hyperair: so is there a doc on the new format?
[18:30] <nigelb> no need to say 3.0 in control?
[18:31] <hyperair> nigelb: no.
[18:31] <shadeslayer_> nigelb: nah
[18:31] <nigelb> cool :)
[18:31] <hyperair> shadeslayer_: there is, but i'm lazy to look for it.
[18:31] <nigelb> how do I add a new patch then?
[18:31] <hyperair> shadeslayer_: it's easier to just vomit out whatever i have in my head, since there's so little.
[18:31] <shadeslayer_> hyperair: lol.. ok ill pester you tommorow then :D
[18:31] <hyperair> nigelb: the same way you do for a normal quilt patch system.
[18:31] <nigelb> aha :)
[18:31] <hyperair> nigelb: the difference is when the patches are applied.
[18:31] <shadeslayer_> my exams get over tomorrow and then ill learn the new stuff :D
[18:32] <nigelb> hyperair: build versus unpackage?
[18:32] <hyperair> nigelb: in 1.0, the patches are applied by debian/rules. in 3.0, the patches are applied by dpkg-source when unpacking.
[18:32] <hyperair> nigelb: yeah.
[18:32] <hyperair> shadeslayer_: good for you. my exams are in approximately a month.
[18:32] <nigelb> hyperair: thank you for the quick lesson :)
[18:32] <shadeslayer_> nigelb: btw how long did you use ubuntu before becoming a member?
[18:32] <nigelb> shadeslayer_: 1 year
[18:32] <hyperair> that's pretty fast
[18:32] <hyperair> i took a few.
[18:32]  * ejat poke hyperair .. 
[18:33]  * hyperair dodges
[18:33] <ejat> hyperair: when is your next semester brake ?
[18:33] <hyperair> ejat: may.
[18:33] <ejat> hyperair: can u conduct a packaging @ patch class for us
[18:33] <ejat> :p
[18:33] <hyperair> ejat: haha maybe. see how.
[18:33] <ejat> i just have a few in my ppa .. not like u :)
[18:34] <hyperair> ejat: i'll probably end up showing you the debian policy manual =p
[18:34] <ejat> may ? a few month to go ..
[18:34] <hyperair> ya
[18:34] <ejat> :(
[18:34] <hyperair> hehe
[18:34] <ejat> at least hands on / sample packaging  @ patching ..
[18:35] <hyperair> just apt-get source packages and see how it's done
[18:37]  * ejat not for me .. but for the other member :)
[18:38] <hyperair> =p
[18:41] <ejat> :p
[18:46] <nigelb> should I be seeing "W: galrey source: quilt-series-but-no-build-dep"?
[18:46] <nigelb> hyperair: ^
[18:47] <hyperair> nigelb: did you echo 3.0 (quilt) into debian/source/format?
[18:47]  * nigelb headdesks
[18:47] <hyperair> hehehehehe
[18:48] <nigelb> now I get "E: galrey source: unsupported-source-format 3.0 (quilt)"
[18:48] <nigelb> is that because I'm doing this in karmic?
[18:49] <hyperair> you need a new lintian
[18:49] <nigelb> so upload would get through fine right?
[18:49] <hyperair>  *** 2.3.3ubuntu2~karmic1 0 500 http://linux.ntuoss.org karmic-backports/main Packages
[18:49] <hyperair> use karmic-backports and install the new lintian
[18:53] <nigelb> okay, now I only have "E: galrey source: missing-build-dependency quilt"
[18:55]  * nigelb pokes hyperair
[18:55] <persia> nigelb: Try in a lucid chroot.  I suspect that's a dpkg bug.
[18:55] <hyperair> nigelb: are you sure you have a 3.0 package there?
[18:55] <persia> Or insufficient removal of the patch system.
[18:56] <hyperair> nigelb: did you remove the quilt bits from the debian/rules?
[18:56] <nigelb> I removed the build dep, removed patch and unpatch from rules, and did the echo
[18:56] <persia> nigelb: Did you check for any include in debian/rules that may need to be removed?
[18:56] <nigelb> "include /usr/share/quilt/quilt.make" has to go?
[18:56] <nigelb> persia: ah
[18:56] <hyperair> nigelb: check if you've got a ../package_version.debian.tar.gz
[18:56]  * hyperair sighs
[18:57] <nigelb> yeah, I do
[18:57] <hyperair> yeah it was that include
[18:57] <hyperair> i thought i told you to remove all trace of the patch system =\
[18:57] <hyperair> traces*
[18:57] <nigelb> I mistakenly thought that quilt 3.0 and that was related
[18:58] <persia> quite the opposite, actually.
[18:59] <nigelb> persia: look at what just happened.  found an ubuntu patch. now, I'm uploading debian fix.  irony
[19:00] <persia> Why?
[19:00] <hyperair> what irony?
[19:00] <persia> Was it not a bug in Debian?
[19:00] <persia> Did it not need fixing?
[19:00] <nigelb> bug upstream, needed fixing, yes
[19:01] <nigelb> irony is.  we started at reducing the number of reviewers subscribed bugs to <200 and here I am fixing 1 bug (which is good btw)
[19:01] <persia> Why upload in Debian, rather than getting it all the way upstream?
[19:01] <persia> Yeah, that happens :)
[19:03] <nigelb> persia: getting to debian was self reasons of getting something to debian
[19:03] <hyperair> getting things into debian should always be the first choice =p
[19:03] <hyperair> because syncs are sexy.
[19:04] <persia> hyperair: No.  Getting stuff upstream should be the first choice.
[19:04] <hyperair> er. right.
[19:04] <persia> Because syncs + no patches in packaging are even sexier.
[19:04] <hyperair> sorry, i had the wrong context.
[19:04] <hyperair> =p
[19:04] <hyperair> agreed.
[19:04] <nigelb> duploading to mentors now :)
[19:05] <persia> Mind you, I agree we should always let Debian know about the issues and share the patches.  I just don't think the job is done just because Debian is informed when we're doing patch review.
[19:06] <nigelb> Oh great mentors just rejected my upload
[19:06] <hyperair> lol
[19:06] <nigelb> Your .dsc file (galrey_1.0.2-4.dsc) mentions a file named
[19:06] <nigelb> 'galrey_1.0.2.orig.tar.gz' which is part of the source package
[19:06] <nigelb> that isn't in the repository apparently
[19:06] <hyperair> debuild -S -sa
[19:06] <hyperair> the -sa is important.
[19:06] <hyperair> even if you use dpkg-buildpackag
[19:06] <hyperair> e]
[19:06] <hyperair> it makes the .orig.tar.gz get uploaded
[19:07] <nigelb> ah, never knew
[19:08] <hyperair> haven't you ever uploaded to a PA?
[19:08] <hyperair> PPA*
[19:09] <nigelb> nope
[19:09] <nigelb> only attached debdiffs to bug reports
[19:10] <hyperair> heh
[19:10] <hyperair> i see.
[19:22] <nigelb> wonder why I dont get a mail after so long
[19:34] <nigelb> any DD's around to sponsor a fix in debian?
[19:48] <micahg> nigelb: I thought there was a way to upload NMUs w/out a sponsor
[19:48] <micahg> with a delay
[19:48] <nigelb> micahg: its a QA upload
[19:50] <micahg> nigelb: so it's orphaned?
[19:50] <nigelb> micahg: yup.  I asked on debian-mentors channel.  They said, just do a QA upload
[19:58] <iulian> One cannot upload anything to the official Debian archive without being either a DD or DM.
[19:59]  * hyperair would like to become a DM, but is in a place too geographically remote to get a signature.
[20:00]  * nigelb is worried about that too
[20:00] <AnAnt> hyperair: I have the same case
[20:00] <hyperair> AnAnt: i suspect it's not uncommon.
[20:00] <hyperair> what a troublesome policy.
[20:00] <AnAnt> I was told to at least get a signature from someone that is in web of trust
[20:00] <hyperair> yeah exactly.
[20:00] <iulian> hyperair: I had the same problem as well.
[20:00] <hyperair> but there is nobody around this region within that web of trust.
[20:01] <AnAnt> hyperair: did you search on biglumber ?
[20:01] <hyperair> AnAnt: what's that?
[20:01] <AnAnt> http://biglumber.com/x/web
[20:02] <hyperair> hmm cool
[20:02] <AnAnt> hyperair: there are 14 names in China
[20:02] <jorgerosa> hello all
[20:02]  * hyperair coughs
[20:03] <AnAnt> hyperair: I guessed from your name
[20:03] <hyperair> AnAnt: if i were in china i think it would be easier to find DDs.
[20:03] <hyperair> AnAnt: i've never been to china.
[20:03] <hyperair> AnAnt: i'm malaysian, studying in singapore.
[20:03] <AnAnt> hyperair: I think there is a DD in Malaysia
[20:03] <hyperair> and i have never experienced natural winter before.
[20:03] <hyperair> wait, there is?
[20:03] <hyperair> last i checked, there wasn't.
[20:03] <hyperair> ejat: do you know any DD in malaysia?
[20:05] <AnAnt> hyperair: sorry, I was mistaken
[20:06] <AnAnt> well, there are 8 names in singapore
[20:06] <hyperair> ah well
[20:06] <hyperair> nevermind
[20:06] <nigelb> yaay
[20:07] <nigelb> 1 DD in my city
[20:07] <hyperair> heh how nice
[20:07] <nigelb> when I get to that stage, that would help
[20:07] <hyperair> hmm come to think of it, i wonder if mario behling is connected to debian's web of trust.
[20:07] <hyperair> he's been around here a few times
[20:10] <jorgerosa> Is anyone here able to upload games (or submit for review, etc... I dunno) to ubuntu repository?
[20:10] <AnAnt> hyperair: if you know his key ID, you can check it
[20:10] <hyperair> AnAnt: heh i don't.
[20:10] <hyperair> i'll go poke him the next time i see him
[20:10] <AnAnt> hyperair: you can search for it, if you know his email
[20:11] <hyperair> i think he doesn't have one =O
[20:13] <nigelb> how to check if a person is in the web of trust?
[20:16] <AnAnt> nigelb: try checking his key on http://pgp.cs.uu.nl/stats/<keyID>.html
[20:17] <AnAnt> nigelb: or you can use keyanalyze tool from signing-party package
[20:17] <nigelb> AnAnt: what is the keyID there?
[20:17] <AnAnt> nigelb: replace it iwth the GPG keyID of that person
[20:18] <nigelb> AnAnt: the short ID?
[20:18] <AnAnt> yup
[20:18] <nigelb> ugh, how do I find that
[20:18] <nigelb> I only see the finger print
[20:19] <AnAnt> ?
[20:19] <nigelb> CC18 3BF4 9D17 1DA7 E11E 67D3 1729 F586 6A9F 3C38 ?
[20:19] <AnAnt> gpg --list-key <person>
[20:19] <AnAnt> nigelb: is his key in your keyring ?
[20:19] <nigelb> nope
[20:20] <AnAnt> nigelb: I think you can search for his key using the fingerprint
[20:20] <nigelb> aha :)
[20:20] <AnAnt> nigelb: try it
[20:21] <nigelb> AnAnt: doing now :)
[20:22] <nigelb> AnAnt: gpg --search-keys <fingerprint> not working
[20:23] <AnAnt> do you know his email ?
[20:24] <nigelb> yeah
[20:24] <jpds> nigelb: The short ID, is the last 8 digits of the fingerprint; ie. 6A9F3C38
[20:24] <MTecknology> Any chance you guys have any ideas what is causing this compile error? http://launchpadlibrarian.net/41314423/buildlog_ubuntu-karmic-i386.nginx_0.8.34-0ppa4_FAILEDTOBUILD.txt.gz
[20:24] <nigelb> jpds: ah, thanks :)
[20:25] <nigelb> so how do I figure out if that person is in the web of trust?
[20:26] <MTecknology> "error: 'ngx_http_request_t' has no member named 'utf8'" This is the best I can figure out in the errors but I don't know what's causing it
[20:28] <jpds> nigelb: http://pgp.cs.uu.nl/
[20:29] <nigelb> jpds: I got to that page, but how do I figure it out?
[20:29] <AnAnt> nigelb: http://pgp.cs.uu.nl/stats/<keyID>.html
[20:29] <jpds> nigelb: See if someone's key is signed by DDs basically.
[20:30] <nigelb> i.e. @debian.og?
[20:31] <AnAnt> nigelb: the guy is a DD !
[20:31] <nigelb> wait, all DD are trusted right?
[20:31] <nigelb> and anyone who got signed are trusted again?
[20:31] <AnAnt> nigelb: usually, yes
[20:32] <nigelb> like DD signs my key, then I can sign someone else's key and they are also trusted?
[20:32] <AnAnt> nigelb: I think so
[23:13] <^arky^> Any chance of getting this bug 541721 fix into lucid now ?
[23:18] <geser> ^arky^: why subscribing ubuntu-release? ubuntu-sponsors is more correct as you don't need a FFe or similar (just someone sponsoring)
[23:20] <ScottK> geser: I just removed the release team.
[23:25] <^arky^> geser: sorry, didn't know that
[23:26] <^arky^> geser: thanks for subscribing ubuntu-sponser team
[23:39] <crimsun> ^arky^: in the future, please remember to also modify debian/control given that you've introduced a new Ubuntu delta
[23:39] <crimsun> ^arky^: uploaded, thank you for your contribution to Ubuntu Lucid!
[23:49] <crimsun> would someone add me to ~ubuntu-sponsors, please?
[23:51] <^arky^> crimsun: Thank you for quick upload !
[23:55] <^arky^> crimsun: I usually do 'dch -i' thought this would also edit debian/control ?
[23:58] <JontheEchidna> dch -i shouldn't ever modify debian/control, afaik
[23:59] <^arky^> JontheEchidna: then I should always manually edit debian/control after doing dch -i ?
[23:59] <geser> ^arky^: update-maintainer
[23:59] <geser> from ubuntu-dev-tools