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