[01:38] <Corey> Should there be a .dsc file included in the debian/ branch?
[01:43] <StevenK> No
[01:52] <Corey> StevenK: Okay. What generates that?
[01:53] <StevenK> Corey: dpkg-source
[01:53] <StevenK> A .dsc is part of a source package
[01:53] <Corey> StevenK: I'm attempting to find a (semi sane) way to have Hudson automatically build a .deb from a git repo.
[01:53] <Corey> ER, Jenkins even.
[01:54] <StevenK> Check out the pieces, cd into it and run dpkg-buildpackage -S
[01:54] <StevenK> That gives you a source package at least
[01:54] <StevenK> If you can sure you have build-depends and a clean environment, just run dpkg-buildpackage
[01:55] <Corey> StevenK: I can't be sure of any such thing, which is why I'll be running it in pbuilder.
[01:55] <StevenK> Oh, then build a source package and toss it into pbuilder
[01:55] <Corey> Need to find a sane way to get the b-ds into pbuilder's chroot-- probably a pbuilder --login --save in my future.
[01:58] <micahg> Corey: pbuilder does that for you
[02:02] <Corey> micahg: Unfortunately it doesn't in this case, the deps aren't in Lucid's repo.
[02:02] <Corey> I do believe they'll be in 12.04's though.
[02:02] <micahg> Corey: oh, then how do you expect to test?  why are you testing in a lucid chroot?
[02:03] <Corey> micahg: Because the package is going out to Lucid boxes that will also grab the deps.
[02:04] <micahg> Corey: then you need to add the repo that has those packages to the sources file for pbuilder (or use one of the flags to pass it when calling pbuilder)
[02:06] <Corey> micahg: As of now the repo is a PPA.
[02:06] <micahg> that's fine
[02:06] <Corey> That'll still work?
[02:06] <Corey> k.
[02:08] <Corey> micahg: What would the pbuilder line look like then, so the chroot doesn't get whiny about missing GPG keys?
[02:09] <micahg> Corey: you probably want to add the source and import the key inside the chroot if you don't want it to whine about the GPG keys
[02:10] <micahg> if you're just testing stuff, you might not care about the keys
[02:11] <micahg> (i.e. just throw away the binaries or use them in a clean env)
[02:17] <micahg> udienz: you can sync stuff yourself now using the API, try syncpackage in ubuntu-dev-tools, just please remember that in general  we're syncing from testing by default this cycle, so anything from unstable or elsewhere should have a good reason to sync before it hits testing
[02:18] <Corey> micahg: Well the plan is to pipe this into my repository eventually so I don't have to build new packages. :-)
[02:19] <micahg> Corey: ah, so you don't intend to keep using a PPA then
[02:19] <Corey> micahg: Right.
[02:20] <micahg> ah, ok
[02:21] <udienz> micahg, sorry it was my fault, i would like to simulate first but i submit a bugs. huh..
[02:21] <udienz> perhaps we need --simulate options
[02:22]  * udienz will back, need to go to office
[02:23] <Corey> micahg: I can build it faster on my hardware than Launchpad can. :-)
[02:25] <lifeless> Corey: whats your hardware?
[02:29] <Corey> lifeless: HP DL360 G7
[02:34] <lifeless> nice
[02:38] <Corey> lifeless: Yeah, it's fun hardware.  Just need to get it set up to build something properly.
[02:39] <Corey> I've got the repo working (https://github.com/saltstack/salt) but want to start doing testbuilds sanely as the next step.
[02:45] <Corey> micahg: So the way that would play out would be what, git clone, dpkg-buildpackage, sudo pbuilder $someflags?
[02:46] <micahg> Corey: sounds about right
[16:36] <psusi> anyone have any idea why stack retracer can't seem to find the symbols for libgtk-x11-2.0.so.0?  https://launchpadlibrarian.net/71632202/Stacktrace.txt
[16:36] <psusi> it looks like the -dbg package has the symbols to me: http://packages.ubuntu.com/oneiric/i386/libgtk2.0-0-dbg/filelist
[16:38] <psusi> is there supposed to be a symlink for libgtk-x11-2.0.so.0 pointing to .2400.6?
[16:38] <psusi> in the -dbg that is
[17:25] <Laney> I just came across slicer: FTBFS & maintainer thinks this version shouldn't be released with Debian. Remove?
[17:26] <tumbleweed> slicer of VTK pain? remove
[17:27] <Laney> it would be good if we could use a per-version blacklisting for something like this
[17:28] <tumbleweed> yeah
[19:15] <ScottK> Remove without blacklisting does it just fine after DIF.
[19:15] <ScottK> Laney: If you wait until after DIF to remove it, it won't come back unless it's updated.
[19:15] <Laney> yeah I said that in the bug
[19:17] <Laney> ish
[21:26] <tumbleweed> do we rebuild to make them shut up? bug 873984 (IIRC I looked and it worked fine, just displayed a warning)
[21:28] <micahg> tumbleweed: is it actually starting up the secure service?
[21:28] <tumbleweed> I assume I checked and it was, but I'll check again
[21:30] <micahg> tumbleweed: if it does need a rebuild, that means that the package should be fixed in precise to depend on the version it's built against only (which probably means it's using private symbols and shouldn't be) or it should just be fixed to not be so strict
[21:32] <tumbleweed> at any rate it needs to be fixed to have stricter dependencies or be less noisy
[21:32] <micahg> sure, but one's a wishlist/low and one's a medium/high
[22:09] <tumbleweed> micahg: verified that it works just fine
[22:09] <micahg> ok, so idk
[22:58] <psusi> is there a way to force a hung app to crash and generate an apport crash report?  I thought sending it a SIGABRT would do that but I guess not
[22:58] <broder> SIGSEGV?
[22:59] <psusi> doesn't SIGABRT normally do the same thing?  I've seen apport crash reports where it died with SIGABRT?
[22:59] <broder> i don't know, but i know SIGSEGV works
[23:00] <psusi> hrm... I'll try that next time then.. seems when I resume from suspend, banshee hangs
[23:01] <psusi> stuck on pthread_cond_timedwait() according to gdb, but got no other symbols
[23:02] <tumbleweed> ubuntu-bug pid?
[23:03] <tumbleweed> or will that not stack trace?
[23:03] <EvilResistance> i've always used SIGSEGV for killing when it hangs and I want a bug report
[23:03] <psusi> ahh, of course
[23:03]  * EvilResistance did that twice for 12.04 programs
[23:04] <Laney> getting tempted to upgrade
[23:04] <EvilResistance> although that was from within a VM, so... :P
[23:05] <broder> i've been thinking about it
[23:05] <Laney> everyone goes on about how magically stable it is
[23:05] <tumbleweed> I'm seeing lots of ath9k related kernel panics with the 3.2 kernel, otherwise the world is fine
[23:08] <EvilResistance> hmm... is there any specific thing one has to do in order to throw a package's results to /usr/local/progname (where progname is the name of the program in the package)?
[23:09] <EvilResistance> it keeps failing to build from source (pastebin coming shortly)
[23:09] <tumbleweed> packaged stuff doesn't belong in /usr/local
[23:10] <EvilResistance> tumbleweed:  where would you recommend extracting a program to, then?  (note that i'm putting it where the program developer wants it placed :/)
[23:11] <tumbleweed> EvilResistance: /usr/share and/or /usr/lib (see the FHS)
[23:11] <EvilResistance> thanks
[23:11] <tumbleweed> the upstream developer should use /usr/local, yes, but we don't
[23:13] <Laney> most common build systems are capable of dealing with this, use one of those if possible
[23:38] <psusi> how does the software center decide how to categorize packages?  gparted is listed under "Themes and Tweaks" and it shouldn't be
[23:40] <RAOF> It slurps data out of the .desktop file, right?
[23:41] <psusi> I dunno... but the desktop file says categories=GNOME;System;Filesystem;... not themes/tweaks
[23:42] <psusi> reassign bug to software-center?
[23:43] <RAOF> That'd be my starting point, yeah :)