[05:51] <excalibr> Say you have only *.debian.tar.gz, how do you generate those .dsc and .changes without running commands to build package?
[05:53] <StevenK> .dsc is generated from an unpacked tree, you'll need an orig and the debian.tar.gz unpacked properly into it. debuild -S will then generate a .changes.
=== jamesh_ is now known as jamesh
=== nesthib is now known as Guest64829
[12:53] <zyga> hey, can launcpad PPAs host any code, including propretary stuff?
[12:53] <saiarcot895> For proprietary code, you need a private PPA
[12:53] <saiarcot895> *proprietary packages
[12:54] <zyga> ok
[12:54] <zyga> thanks
[12:54] <zyga> how do I report violations?
[12:55] <saiarcot895> Proprietary code, however, might be hosted on Launchpad, since you could set the visibility to private (although I'm not sure on this)
[12:55] <saiarcot895> as for violations, I guess someone else here could help, or you could post a question on Launchpad
[12:56] <zyga> I just posted this question: https://answers.launchpad.net/launchpad/+question/236264
[12:57] <saiarcot895> Scratch what I said earlier; see https://answers.launchpad.net/launchpad/+question/230751
[12:57] <zyga> ah
[12:57] <zyga> thanks
=== Guest64829 is now known as nesthib
=== BradCrittenden is now known as bac
[14:09] <saiarcot895> I have a package that should provide a -dbg package. I'm using the dh auto commands and have override_dh_strip to tell it to place the debug symbols in the specified package. however, dh_strip isn't being called at runtime. Is this a bug?
[14:21] <dobey> saiarcot895: #ubuntu-packaging, but you don't need to provide your own -dbg packages in ubuntu. dbgsym packages are automatically built already, and installable via the ddebs archive
[14:21] <saiarcot895> I should have mentioned, this is for a PPA
[14:22] <dobey> you can request to have dbgsym support enabled on your PPA then by asking a question at https://answers.launchpad.net/launchpad
[14:24] <saiarcot895> oh, nice
[14:25] <cjwatson> or we could try to fix the problem, since it's weird nevertheless - do you have a build log?
[14:26] <saiarcot895> will do
[14:26] <saiarcot895> Build log: https://launchpadlibrarian.net/151337512/buildlog_ubuntu-saucy-amd64.flightgear_2.12.0-0ubuntu1~ppa1~saucy3_UPLOADING.txt.gz
[14:27] <saiarcot895> rules file: http://paste.ubuntu.com/6150314/
[14:28] <saiarcot895> I noticed that the simgear package (in the same PPA) got debug symbols, and the only difference was the debian/compat level, which was 8 in simgear and 9 here
[14:28] <cjwatson> saiarcot895: your rules file is badly formatted
[14:28] <cjwatson> saiarcot895: command lines such as the one starting dh_strip *MUST* begin with a tab character
[14:29] <saiarcot895> cjwatson: I just noticed that
[14:29] <cjwatson> not four spaces masquerading as a tab in your editor or anything else, a literal ASCII tab
[14:58] <tlonim> is there a maintenance going on? I am getting client timeout (of 300s) with a fresh bzr branch
[15:05] <cjwatson> tlonim: No maintenance I'm aware of
[15:06] <tlonim> cjwatson: I am getting https://gist.github.com/cbd155d6d90c09f74be7 .. any way around it
[15:10] <cjwatson> tlonim: it at least starts branching fine for me - I have a fairly slow connection so I'm not going to wait for the whole thing to finish, but I get a progress indicator
[15:10] <cjwatson> maybe a local network difficulty?
[15:21] <tlonim> checking
[16:06] <mapreri> can someone tell me why this build is waiting? https://launchpad.net/ubuntu/+source/dump/0.4b44-4/+build/5039990 the sync was made 2 days ago...
[16:06] <cjwatson> mapreri: arm64 is still being bootstrapped
[16:06] <cjwatson> mapreri: You shouldn't expect anything on arm64 to build for a while
[16:06] <cjwatson> mapreri: But I somehow doubt you were actually looking for arm64 ...
[16:08] <cjwatson> mapreri: Ah, your own sync; well, you'll just have to wait, it doesn't block anything for you unless you're one of the handful of people caring specifically about arm64 at the moment
[16:08] <cjwatson> mapreri: Don't worry, it's not a problem with your package
[16:12] <mapreri> cjwatson: ah, ok. I'm only wondering why it's waiting. It's the first time I see an arm64 build, I'm curios if the build ends fine :)
[16:13] <cjwatson> mapreri: We're waiting for a new kernel for our buildds so that it stops randomly segfaulting in the middle of compiler builds
[16:13] <cjwatson> ... don't hold your breath *too* much
[16:15] <mapreri> cjwatson: don't worry, I used to "keep calm and keep packaging" :D
[16:25] <karlicoss> Hi guys. Could you tell me, what does "3:" in the version number mean there? https://launchpadlibrarian.net/127144064/mc_4.8.7-0~eugenesan~raring1_source.changes
[16:26] <cjwatson> karlicoss: epoch, see http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[16:26] <karlicoss> cjwatson: thanks!
[19:39] <mattw> I've uploaded a source package that requires ia32-libs to a ppa and tried to build for 64-bit precise. The build can't begin due to an uninstallable ia32-libs-multiarch which I've encountered on my own machine and fixed without issue before (usually a broken package), but I don't know what to do in this situation.
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha