[01:14] whats the name for the metapackage that installs all the packaging related tools? === sikon is now known as lucidfox [09:01] TheLordOfTime: I guess you mean packaging-dev === vibhav is now known as Guest61908 === Guest61908 is now known as vibhav === vibhav is now known as Guest37517 === Guest37517 is now known as vibhav [14:12] !ops [14:12] Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds! [14:13] !ops [14:15] PriceChild: ? [14:16] what up my homey [14:16] why did you call for ops? [14:16] to be banned [14:16] !ops [14:16] kline me [14:16] * tumbleweed has no idea why anyone would want to be banned [14:17] i do! i get high easily [14:17] I suppose we al have odd persuits... [14:18] Pricey: if you could remove your troll self :) [14:18] yay the real pricechild is here to kline me! [14:18] ban me [14:18] i want to get high! [14:18] ban me [14:18] impersonating a channel op and staff member to boot, good idea. [14:18] i am a mental retard by the way [14:19] ah, normality [14:39] Hi all! [15:16] PaoloRotolo: Hi [15:18] scarneiro, hi! [15:47] can i use Lintian on Ubuntu to check for lintian cleanliness for a Debian-destined package? [15:52] TheLordOfTime: yes, lintian on Debian and lintian on Ubuntu is basically the same [15:52] jbicha: so i pretty much just need to run Lintian on the package to find whether its lintian clean, and fix any warnings and/or errors that arise? [15:53] yes, being lintian clean is important :) [15:54] definitely [15:54] i once had a package that was lintian unclean by only one error, and that error was i forgot to change the standards number xD [15:55] and they were like "You're x.x. 1 behind in the standards number, fix it" [16:02] sponsoring is an opportunity to teach, so many of us tend to be pretty pedantic sponsors [16:02] indeed [16:03] although having said this, the debian people rejected a package even though it was lintian clean because they "Didn't agree with the way the source was run after installation" [16:03] so.. i kinda gave up on trying to get packages into Debian (then again, i havent had any need to get anything into Debian lately, so... :P) [16:04] was it totally crazy? [16:05] source code without any compiled executable (because the entire thing was 100% python...) [16:05] so... [16:05] *shurgs* [16:05] probably, although its irrelevant now [16:06] did the sponsor have any experience with python? [16:06] every DD has their own requirements and foibles [16:07] i know right? [16:07] don't know, but idc anymore :P [16:08] Debian teams are awesome, if you can find a team that would be interested in your package [16:09] it makes sponsorship easier and reduces the MIA Debian maintainer problem [16:10] team-maintained packages++ [16:12] ^ that [16:12] but i digress :P [18:42] Err... this is weird. Upstream compiles fine if I run: 'cmake .' and then 'make'. But if fails on PPA as well as locally (when using debuild). [18:42] Here's the PPA buildlog: http://paste.ubuntu.com/1055180/ (please scroll down to line 3883) [18:42] I don't understand why the build exits with error when using debuild. It builds fine when using 'make'. [18:43] (Timezone repost) [18:59] !ops [18:59] Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds! [18:59] ban me [18:59] ban me [18:59] ban me [18:59] please! [19:00] !staff [19:00] hey Christel, Dave2, Gary, KB1JWQ, Levia, Martinp23, SportsChick, VorTechS, jayne, jenda, marienz, nalioth, niko, nhandler, rob, dax, stew, or tomaw, I could use a bit of your time :) [19:00] !ops [19:00] Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds! [19:00] please! [19:00] * iulian sighs. [19:00] lucas: ban me [19:00] yay ban coming! [19:00] Yankees52, lets stop this [19:02] i'm confused. [19:07] AmberJ, could it be a gcc version difference? [19:08] looking at opencog-0.1/opencog/learning/moses/main/moses_exec.cc:828 might give some clues [19:11] james_w, you mean the build breaking maybe because of using a different version of gcc/g++? [19:11] AmberJ, yeah, possibly [19:11] Unfortunately, I'm unable to understand what is wrong with 828 of http://bazaar.launchpad.net/~opencog-dev/opencog/trunk/view/head:/opencog/learning/moses/main/moses_exec.cc [19:13] james_w, I tried building in the same VM... The build breaks with debuild but works fine when manually using cmake/make. (I guess same VM/install cannot have two different versions of gcc) [19:13] AmberJ, it might be something in the environment then [19:15] Not sure if this is the cause but I noticed something... The debuild build breaks when I manually copy orig.tar.gz and debian/ from another repo. The same debuild build works fine if I use 'bzr dh-make' for debianization.. [19:16] I thought that 'bzr dh-make' only creates orig.tar.gz and copies template debian/ files.... but it seems ot [19:17] *but it seems that it (i.e. bzr dh-make) is doing something else as well... Maybe doing with build environment as you suggest) [19:19] * AmberJ_ is reading dh_make source [19:25] AmberJ_, might it be that MOSES_BZR_REVNO has no value when it breaks? [19:25] hmm, doesn't sound right though [19:25] but yeah, that error doesn't seem to have much to do with the file as you say === vibhav is now known as Guest69218 === LordOfTime is now known as TheLordOfTime [20:27] http://paste.ubuntu.com/1056521/ <-- anyone able to tell me what's missing? i told the system to use all the components [20:28] COMPONENTS="main restricted universe multiverse" <-- defined in ~/.pbuilderrc [20:28] for all users [20:29] TheLordOfTime: try with PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-gdebi" in .pbuilderrc [20:29] it gives better error messages in my experience [20:31] bleh, pbuilder base got purged [20:31] * TheLordOfTime is not pleased [20:31] (the base.tgz) [20:31] will that base be rebuilt when i specify distribution 'quantal' instead of precise or when i specify 'natty'? [20:32] yes [20:32] good [20:32] use pbuilder-dist for easy multi distributions [20:33] or set BASETGZ/BASEPATH appropriately [20:43] jtaylor: This package is uninstallable [20:43] Dependency is not satisfiable: debhelper (>= 7.0.50~) [20:44] so... [20:45] not sure what its on about... [20:45] (since this is being caused by the 'juju' source package from quantal) [20:46] and juju's in main, if this is triggered in Quantal, bad things'll happen [20:49] jtaylor: still around? [20:49] TheLordOfTime: debhelper 7 not available in quantal? [20:49] unlikely [20:49] jtaylor: <ubottu> debhelper (source: debhelper): helper programs for debian/rules. In component main, is optional. Version 9.20120419ubuntu2 (quantal), package size 594 kB, installed size 966 kB [20:49] so... [20:49] not sure wth's going on [20:50] just use pbuilder-dist [20:50] and that's with a pbuilder-dist quantal create [20:50] jtaylor: i *did* i was just typing that [20:50] so unless pbuilder's gone wonky and is bugged [20:50] pbuilder-dist * [20:50] can you login and install the dependencies? [20:53] pbuilder-dist quantal login --save-after-login right? [20:54] ah there it is [20:54] jtaylor: i'm going to edit the debian/control [20:55] i think the ~ is throwing it off (its yelling at python, ended with a ~ too) [20:55] I: Installing the build-deps [20:55] This package is uninstallable [20:55] Dependency is not satisfiable: python (>= 2.6.6-3~) [20:55] unless pbuilder-dist is literally broken [20:56] unless you're willing to do me a favor and try to build juju in Quantal yourself [20:56] (its directly synced from Debian, so i wonder if its breaking) [20:57] even installing python myself doesnt fix it [20:57] how much do you want to bet that pbuilder-dist is broken [20:57] jtaylor: ^ [20:58] not sure what the problem [20:58] likely something with components [20:58] well that's unlikely [20:58] debhelper's main [20:58] so's python [20:59] pango-graphite needs SRUing somehow in lucid: Bug #893559 which I'll be marking a dupe of Bug #540035 shortly. [20:59] Launchpad bug 893559 in pango-graphite (Ubuntu) "Installing pango-graphite breaks display manager" [Undecided,Confirmed] https://launchpad.net/bugs/893559 [20:59] Launchpad bug 540035 in pango-graphite (Ubuntu) "pango-graphite causes several applications to crash" [High,Fix released] https://launchpad.net/bugs/540035 [20:59] yep, i think this is a bug in pbuilder [20:59] because i even *installed* python [21:00] This appears to fall into the "upstream microrelease" SRU category. Would it be appropriate here to simply request a sync from debian squeezy for the SRU? [21:00] personally, I use sbuild instead of pbuilder http://wiki.debian.org/sbuild [21:00] jbicha: i dont have it installed [21:07] TheLordOfTime: This is a qq pbuilder and qq juju source? [21:08] arand: precise pbuilder, quantal juju source [21:08] although i have a tarball now built for quantal [21:08] (for the pbuilder) [21:08] i'm just testing a package build [21:08] not actually *producing* the debs here [21:08] * TheLordOfTime tests any and all debian package builds prior to submitting debdiffs for bugs [21:08] s/debian// [21:11] arand: and using pbuilder-dist also breaks [21:11] it doesnt correctly identify that the debhelper and the python is valid [21:12] unless quantal's bootstrapthingy is wrong === fedora is now known as ia [21:15] oh hang on [21:19] "pbuilder-dist quantal build juju_0.5+bzr542-1.dsc" seems to work for me from Debian [21:20] meh might just be pbuilder [21:20] precise doesn't have the python packages/versions that the quantal juju depends on. [21:20] i'll reinstall everything for it later [21:20] arand: but it was a quantal pbuilder-dist [21:20] i *confirmed* that [21:20] it should have still built within the chroot [21:20] no? [21:20] i.e. pbuilder-dist quantal build ... [21:21] Is it old and in need of an update? [21:21] (the base tgz that is) [21:21] i just recreated it [21:21] so i doubt it [21:22] Yeah. [21:22] * TheLordOfTime had to recreate it today after an unfortunate nuking of the cache [21:31] Hmm, I'm seing your exact dependency errors on the precise base and not on the quantal one... [21:31] arand: then i'm going to file a bug against pbuilder at this rate [21:31] pbuilder-dist quantal build did those errors [21:31] it even said * distribution is quantal [21:32] * TheLordOfTime will purge pbuilder stuff and reinstall then test [21:32] if it comes up i'll be filing a bug [21:32] comes up after reinstall* [21:33] Your first log from above is from precise though? [21:33] in pbuilder [21:33] but then i remembered i keep a build-tests ppa on lp [21:33] so i just used that [21:35] uh? [21:36] So you tried it in a precise base.tgz then in a PPA on quantal, then in a quantal base.tgz? [21:36] *PPA quantal pocket [21:41] * TheLordOfTime sighs [21:42] arand: i uploaded to a plain old PPA on Launchpad [21:42] after i said "screw it" to pbuilder locally [21:42] * TheLordOfTime assumed that would have been understood immediately [21:42] the package is targetted against Quantal, so it tried to build in a quantal chroot within the PPA builders [21:42] so it got past the random crap i was seeing in pbuilder [21:43] and stuff [21:43] i'm on a different issue now [21:43] Well, I FTBFS:ed as well, on a bunch of testcases... [21:45] http://paste.debian.net/176022/ But the depends bit you were seing went ok. [21:51] wait, so it FTBFS in Quantal? [21:52] arand: ^ [21:53] Looks like it, but later on in the build preocess than in your case... weird. [21:55] arand: https://launchpadlibrarian.net/108472904/buildlog_ubuntu-quantal-i386.juju_0.5%2Bbzr542-1.1_FAILEDTOBUILD.txt.gz <-- that's what i'm getting when trying to help someone fix a bug (via an LP builder) [21:55] (see -bugs if you're not there already) [21:58] but if you're saying the original package isnt building from that source, then that's a bigger problem= [21:58] whoops [22:04] TheLordOfTime: From what I can tell that build log tells the exact same story as the one from pbuilder-precise-base... Just that it's using a different builder than pbuilder. But I've a hard time imagining that the QQ pocket in a PPA would confuse the series. I have no clue what's up there... [22:04] I would say it's indicating that it's not a pbuilder bug though. [22:10] ok thanks james_w ... I won't settle until I find the source of this bug. [22:12] TheLordOfTime: I'm wondering if it's the latest python that's in flux, and being only half-published on some servers or so, hence everything that's depending on python suffers... [22:18] Hmm, no I misread the publishing dates there, seems pretty unlikely to be python.. [22:22] agreed [22:22] i'm thinking there's an error in the juju code [22:22] especially if its FTBFS without any patches [22:22] s/any/any additional/ [22:25] TheLordOfTime: Which package server were you using for your pbuilder by the way? [22:26] iridium [22:27] Oh, I meant http://archive.ubuntu.com/ubuntu or? [22:27] oh, um... [22:27] * TheLordOfTime checks [22:28] http://archive.ubuntu.com/ubuntu <-- [22:28] (from the sources.list in the base tarball) [22:29] i could try it off of the us archive though [22:29] (the US mirrors) [22:29] Well, we were using the same mirror, so that can't be the dependency mismatch either o_o [22:29] but if the main archives have a major regression issue, then the mirrors wont be much better [22:29] indeed [22:29] hence why i'm going to uninstall and reinstall pbuilder [22:30] Where is dh_make repo? I can see dh_make source on packages.debian.org but isn't there's supposed to be a version controlled repo as well? [22:30] hmm [22:30] arand: is dh-make needed? [22:30] * TheLordOfTime isnt seeing dh-make installed on his system [22:31] It's only for making packaging starter templates [22:31] just making sure [22:31] (although i do need that) [22:32] It's time-saving, though doesn't help you in doing the actual work :) [22:32] well... [22:32] it prevents me from having to bzr branch my debian templates [22:32] because i'll just recreate em [22:32] * TheLordOfTime keeps debian/ templates on a junk branch [22:35] Found it http://anonscm.debian.org/viewvc/collab-maint/deb-maint/dh-make/ (dh-make svn repo on alioth) [22:41] AmberJ_: It's http://git.debian.org/?p=collab-maint/dh-make.git;a=summary nowadays actually. [22:42] ^ that [22:51] TheLordOfTime: alo21's patch does cause a separate (earlier) FTBFS issue, it seems. [22:51] ah, so then his patch is invalid [22:51] Now we've got three of em' :D [22:51] (good thing he didnt upload, i'd have been strict) [22:51] Thanks arand! [22:51] arand: if you can narrow down the FTBFS issue, that'd be awesome. [22:52] http://paste.debian.net/176033/ is the one with alo21's patch [22:59] I'm doubting I'll have much luck with it, but I'll gather as much as possible for a bug report though. [23:14] james_w, I think I now get what you meant by "[00:55] AmberJ_, might it be that MOSES_BZR_REVNO has no value when it breaks?" [23:15] In fact, I strongly suspect that MOSES_BZR_REVNO getting no value is the culprit :) [23:15] I'm doing a build now to see if we are right.. [23:19] Though, now it's turning night here. [23:28] It does NOT matters if I run debuild from package/debian or from package/ .... right? [23:29] arand: at the least, on the bug report, i'd recommend pointing out it FTBFS as well (although note he didnt upload his patch yet) [23:29] AmberJ_: Should not. [23:29] ok [23:30] TheLordOfTime: Yeah, when I said Bug I meant a new one for the current-version ftbfs [23:30] file it and subscribe me? [23:30] (trekcaptainusa-tw is my LPID) [23:53] !ops [23:53] Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds! [23:53] ban me =) [23:53] !staff [23:53] hey Christel, Dave2, Gary, KB1JWQ, Levia, Martinp23, SportsChick, VorTechS, jayne, jenda, marienz, nalioth, niko, nhandler, rob, dax, stew, or tomaw, I could use a bit of your time :)