=== yofel_ is now known as yofel [07:12] Hi, anybody can see bug 915257? i can't reproduce in my pbuilder/sbuild/ppa [07:12] Launchpad bug 915257 in nginx (Ubuntu) "FTBFS nginx 1.1.12-1 in ubuntu precise except amd64" [High,New] https://launchpad.net/bugs/915257 [07:24] udienz: did you have pkg-create-dbgsym installed in your pbuilder when you tried to reproduce it? [07:38] geser: no, it's clean [07:38] then we must add BD to pkg-create-dbgsym? [07:41] pkg-create-dbgsym (and pkgbinarymangler) is installed on the buildds by default [07:41] so if you want to reproduce certain build failures, it's good to them installed in pbuilder too [07:48] good morning [07:53] good morning dholbach [08:00] hey geser === almaisan-away is now known as al-maisan === bilal_ is now known as bilal === chris|| is now known as chris| === Adri2000_ is now known as Adri2000 === chrisccoulson_ is now known as chrisccoulson === Riddelll is now known as Riddell [13:25] does anyone have information about REVU possibly being down? [13:25] i've tried to log in for two days and can't get the website [13:31] looks so, indeed [13:31] wgrant: ^^^^? === al-maisan is now known as almaisan-away === Ng_ is now known as Ng [20:04] Guys, it seems revu is down. [20:05] I'm aware of the plans to move away from revu. So how does one get a package into universe without going the debian way? [20:05] REVU is just a tool for reviewing packages. It's not a submission system [20:06] use mentors.debian.net instead? [20:06] tubleweed, thanks but the package is ubuntu specific. [20:06] depends on unity [20:07] is unity package in debian? [20:07] no [20:07] s/package/packaged [20:07] OwaisL: you can use mentors.debian.net without intending to upload to debian [20:07] tumbleweed, ah ok. I'll check it out. [20:22] Uploaded my package to mentos.debian.net; Anyone interested please have a look http://mentors.debian.net/package/gmailwatcher [20:23] Earlier it was http://revu.ubuntuwire.com/p/gmailwatcher but revu has been down for quite a while and don't know if someone is working on it anymore. [20:24] tumbleweed, thanks! === and`_ is now known as and` [21:17] anyone has thought about syncing opencv 2.3 into precise? === nixternal is now known as fifo === fifo is now known as nixternal [22:01] I have a dsc file generated via debuild -S; I'm trying to build it in pbuilder in a sid chroot, but I'm seeing lookup failures from ftp.debian.org/debian when it tries to grab deps, such as Err http://ftp.debian.org/debian/ sid/main python2.7 amd64 2.7.2-9; 404's out. [22:01] Corey: is the chroot up to date? [22:01] jtaylor: Hmm. Is there a sane way to update it? I build it a couple weeks back. [22:01] python2.7 is version -11ubuntu1 [22:01] built* [22:01] pbuilder --update [22:02] That would do it; thanks jtaylor [22:02] there is also an example hook script shipped with pbuilder that'll do an update before building [22:02] (but that update is thrown away, you still want to pbuilder --update regularly) [22:06] I assume that update when invoked via --update unpacks the tarball, updates it, repacks it? [22:06] yes [22:06] At what point does it make sense to rebuild the chroot from scratch? [22:07] rare, should only be necessary when some upgrade breaks it for some reason [22:07] I think I only ever had to rebuild experimental chroots [22:08] (as long as you don't work with --save-after-login of course) [22:10] the most common reason to rebuild is that there's a package in it that wouldn't have been installed if it was freshly built [22:14] Build failure. :-( Now I get to figure out what I broke. [22:14] fun :) [22:15] Not really. :-) The code is solid, so it's a packaging error of some sort. [22:15] cp: cannot stat `debian/tmp/conf/minion': No such file or directory [22:15] dh_install: cp -a debian/tmp/conf/minion debian/salt-common//etc/salt/minion/ returned exit code 1 [22:16] So I think it's a pathing issue; there's definitely a minion file. [22:16] And the line in the .install file is conf/minion /etc/salt/minion [22:16] how does the .install look like? [22:17] Which is a static, non-compiled file. $packageroot/conf/minion is the file [22:17] what is debian/compat? [22:18] 7 [22:18] (Forgive the paste there, I figured 1 character would be okay...) [22:18] dh_install looks in debian/tmp/foo if foo doesn't exist, so it's not finding foo for some reason [22:19] maybe set "export DH_VERBOSE=1" in the rules file and try again? [22:19] Okay. [22:19] or execute dh_install -v after the failure [22:20] I have to rerun debuild -S first, don't I... [22:21] yes [22:21] there is a hook in pbuilder to drop you in a shell after the failure [22:21] That'd probably be easier, what's the hook? [22:21] /usr/share/doc/pbuilder/examples/C10shell [22:24] http://pastebin.com/DxXmuqzM is the output after that verbosity flag was enabled. [22:24] I snipped the first part of it grabbing deps and whatnot. [22:25] If you wonder what's in the debian directory, https://github.com/saltstack/salt/tree/develop/debian [22:27] hmm. it's possible that dh_install decides whether to look at the project root or debian/tmp for all files, as opposed to deciding for each file [22:27] so you could try changing the usr/share/blah paths to debian/tmp/usr/share/blah (which is where make install will install them to with the default multi-package config) [22:27] broder: Doing it now. [22:34] Isee no conf/minion in that source [22:34] Corey: ^ [22:34] only a conf/minion.template [22:35] jtaylor: ...you're kidding me. [22:35] They changed it on me. [22:35] probably as you are using git snapshot instead of the ready tarball that has the conf/minion [22:35] its not unsual that git trees and release tarballs differ in some autogenerated stuff [22:35] Yeah, I should probably do this with the tarball. [22:35] classic case are autotools stuff [22:36] Should I revert the changes to pathing I just made? [22:37] yes, I don't think dh_install does what broder though [22:37] also usually the destination has no leading / [22:39] Rebuilding. [22:39] I do appreciate how pbuilder caches packages it needs. [22:41] I recommend using a cacher like apt-cacher-ng [22:41] makes sharing package caches much easier [22:41] also you should use eatmydata to speed up installation [22:41] or place everything on a ramdisk [22:44] h_install: salt-minion missing files (modules/*), aborting <-- Progress! [22:45] Pathing issue, whee. [22:47] Holy crap, successful build. Thanks, jtaylor / broder. Now to figure out what else I've pooched. [22:53] Yay, a pile of things to fix from lintian! [22:55] When do I use architecture all vs any? [22:56] any if it architecture dependent and compiles everywhere, all if independent [22:56] e.g. python, documentation = arch all [22:56] compiled code any [22:57] *C compiled, java mono are also all [22:58] jtaylor: One package (multiple packages, for a client/server package) requires compilation that's arch dependant, the rest do not. [22:58] then you have some any and some all packages [22:59] Right, which causes lintian to moan [22:59] what error? [22:59] E: salt source: magic-arch-in-arch-list === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [23:01] whats your control? [23:02] https://github.com/saltstack/salt/tree/develop/debian <-- jtaylor [23:05] shared libraries in a -common package? [23:05] thats "unusual" [23:05] = wrong [23:05] hm its if their private [23:06] jtaylor: Yeah, we inherited some strangeness. I'm quite open to feedback on this. :-) [23:06] This is my first Debian/Ubuntu package. [23:06] I want to get it "right" because once that's done I really don't have to play with it anymore. :-) [23:11] Hmm. Will I break anything horrible if I throw the lintian version for Precise into Lucid? [23:12] no idea, but there is a hook to run lintian after a pbuilder build [23:12] which can be precise [23:13] Yeah, I'm running a version that's 3.9.1, it whines that it's not 3.9.2 [23:13] jtaylor: So what was the verdict on my common package, is that done improperly? [23:16] I'd ahve to see a fully built package for that [23:16] jtaylor: Okay, we'll proceed for now. :-) [23:17] you should not build depend on libzmq1 [23:18] you are probably missing shlib:Deps for the any package [23:18] you seldom can rely on python:Depends getting everything right, that needs manual checking [23:19] also use dh_python2 (dh $@ --with python2) [23:19] if you are not packaging for lucid [23:19] also stick with what you have [23:19] *else [23:20] jtaylor: I don't quite understand. There's a dependency for the python zeroMQ library, not sure how else to reference that. [23:20] libzmq-dev takes care of that [23:20] And this is ideally going to be tossed to a number of different releases; personally I do need it on Lucid. :-) The PPA that'll contain this for dev purposes will contain the deps. [23:20] -dev packages always depend on the newest binary package [23:20] Ahhh. [23:21] Fixed. [23:21] jtaylor: So I should copy the python-deps by hand into each sub-package? [23:21] the actual library package dependency is determined automatically by dh_shlibdeps and put into shlibs:Depends [23:21] probably [23:21] check what dependencies your packages have after build [23:21] make installation and run tests in a clean chroot [23:22] jtaylor: Technically don't I just need to declare them for the common package, since the rest depend on that? [23:22] if that is the case yes [23:27] A bunch of stuff to fix in the man pages, which I can punt on for a bit. [23:28] Bah: E: salt-minion: python-script-but-no-python-dep ./usr/share/salt/salt-call/salt-call [23:28] The python dep is inherited from the common package. [23:29] it should be salt-common (= ${binary:Version}) [23:29] salt-common already grabs python (>= 2.6), [23:30] And ${python:Depends}, [23:30] you still need that [23:30] unless you can guarantee that it will work with other -common versions [23:30] jtaylor: You mean throw the line (= ${binary:Version}) in there explicitly? [23:30] salt-common (= ${binary:Version}) [23:30] in depends [23:33] jtaylor: This is new now that that's been applied; E: salt source: not-binnmuable-all-depends-any salt-minion -> salt-common [23:34] do what it suggests or override it [23:34] binNMU's are only important for offical debian packages [23:36] jtaylor: Yeah, it will be at some point, but not today. :-) [23:37] E: salt-minion: python-script-but-no-python-dep ./usr/share/salt/salt-call/salt-call is still annoying, given that I've updated the control file: https://github.com/KB1JWQ/salt/tree/master/debian [23:38] just add a python depends to silence it then [23:41] jtaylor: Worked, thanks. [23:42] jtaylor: Do I want to set architecture to any, or architecture to all? It's getting upset at the blend. [23:42] depends whats in it [23:44] jtaylor: The client needs to build a module for msgpack that's architecture dependant; the rest is python and doesn't care. [23:46] But it's that blend that's annoying lintian, I suspect. [23:53] sry I have to leave