[06:42] <shadeslayer> could someone sponsor bug 1093220 ?
[07:07] <alkisg> Hi, due to LP #1078679, my sch-scripts package needs to temporarily ship a /usr/local/bin/gnome-panel wrapper. But when I put "local/gnome-panel   usr/local/bin/" in debian/sch-scripts.install, dh_installlocal then complains:
[07:07] <alkisg> dh_usrlocal: debian/sch-scripts/usr/local/bin/gnome-panel is not a directory
[07:07] <alkisg> rmdir: failed to delete «debian/sch-scripts/usr/local/bin»: the directory is not empty
[07:07] <alkisg> How can I workaround the error? Or should I better use dpkg-divert gnome-panel instead?
[07:08] <alkisg> (just until the gnome-panel bug is fixed, then I'll remove the workaround from my package...)
[16:56] <micahg> I'll ask here since I didn't get a response on OFTC over the weekend, if a package in sid won't build from versions of packages in sid, is that an RC bug and is policy 2.2.1 the one to quote or something else?
[16:58] <Rhonda> A FTBFS is clearly a RC bug, and any maintainer wanting to argue which policy checkpoint that fails against is doing a very poor job - leave out the policy line. :)
[16:59] <micahg> it's arch:all (which is why it probably wasn't noticed)
[17:00] <micahg> so, just select FTBFS in reportbug then?
[17:00] <Rhonda> And "over the weekend" is a bit strange, you asked yesterday, we are in the middle of the week.  ;)
[17:00] <Rhonda> Yes.
[17:00] <micahg> sorry, my mind is not grounded ATM :)
[17:01] <Rhonda> Just because it's a day off from work it's not weekend.  *smirks*
[17:01] <micahg> I've been off from work for 2 weeks, so that kinda makes it feel like one big weekend in some ways...
[17:03] <Rhonda> If someone is familiar with upnp, I'd like to have a chat. :)
[17:15] <micahg> Rhonda: BTW, I've done FTBFS bugs before, just not of this type, so wasn't sure if the virtual severity was appropriate since it will always be built locally
[17:16] <Rhonda> It will, always?  Why is it a FTBFS then?
[17:16] <micahg> because the dependency isn't satisfiable from the archive
[17:17] <Rhonda> Then your "always" classification is wrong. :)
[17:18] <geser> micahg: you sometimes find FTBFS bugs for arch:all packages in the BTS too (when someone was doing an archive rebuild test)
[17:36] <micahg> geser: ah, oh, makes sense then
[17:36] <micahg> Rhonda: why is my always classification wrong then?  Debian requires binary+source uploads?
[17:37]  * micahg will check backscroll later
[17:46] <TheLordOfTime> micahg, thanks for handling the backports for znc -> quantal, precise, sorry it took a while
[17:47] <Rhonda> micahg: Because it doesn't work "always", just in special circumstances where the required dependency is installed.  That's not "always" in my area.  It "always" would fail on my system, for a start.
[17:51] <Quintasan> Anyone can tell me where I can find the proper procedure for making an upload that is made so the package is only rebuilt?
[17:59] <geser> Quintasan: use "dch -R" to get the right version number and write a change log entry (usually explaining short the reason for the rebuild)
[17:59] <geser> if the packages has no Ubuntu delta, you should get a version number "-XbuildY" otherwise the usual "-XubuntuY"
[18:02] <micahg> TheLordOfTime: sure, no problem
[18:02] <micahg> Rhonda: I meant locally as in not on buildd, not dkms style
[18:19] <Quintasan> geser: Tahnks!
[18:19] <Quintasan> duh
[18:20] <Quintasan> Thanks even
[20:11] <dkessel> hello. i am trying to backport a package from raring to precise. i have built the package locally using backportpackage, however, i get a build failure when launchpad tries to build my PPA:
[20:11] <dkessel> https://launchpad.net/~d-kessel/+archive/performous/+build/4184133/+files/buildlog_ubuntu-precise-amd64.performous_0.7.0-1ubuntu1%7Eubuntu12.04.1%7Eppa1_FAILEDTOBUILD.txt.gz
[20:13] <jtaylor> did you build it locally in a pbuilder chroot?
[20:14] <dkessel> yes - backportpackage does that by default and i watched it build it
[20:14] <jtaylor> it does?
[20:14] <jtaylor> I though it only builds the source package
[20:15] <dkessel> jtaylor: i have the .deb's here ;) and i think it is something with h2m that is used in the make process... i have another log here from an older version from the original developer:
[20:15] <dkessel> https://launchpadlibrarian.net/58444047/buildlog_ubuntu-lucid-amd64.performous_0.6.1~ppa1~lucid_BUILDING.txt.gz
[20:16] <dkessel> there muste be something different on the build server... which is not in my pbuilder chroot
[20:16] <jtaylor> running ./performous --help during the build might give a clue
[20:18] <dkessel> may i need special pbuilder configuration? i just used "pbuilder create"
[20:18] <dkessel> trying --help next....
[21:37] <Rhonda> I wonder whether canonical payed valve for steam  :)
[21:38] <dkessel> ok, so i gave up and filed a backport bug: https://bugs.launchpad.net/quantal-backports/+bug/1095441
[22:06] <jtaylor> micahg: so the unsolvable yade problem means ipython can't be backported?
[22:07] <jtaylor> can't we just screw that stupid requirement
[22:07] <jtaylor> or make an sru for yade? ...
[22:12] <micahg> jtaylor: let's talk later about it, we should be able to solve it one way or another