| === yofel_ is now known as yofel | ||
| udienz | Hi, anybody can see bug 915257? i can't reproduce in my pbuilder/sbuild/ppa | 07:12 |
|---|---|---|
| ubottu | 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:12 |
| geser | udienz: did you have pkg-create-dbgsym installed in your pbuilder when you tried to reproduce it? | 07:24 |
| udienz | geser: no, it's clean | 07:38 |
| udienz | then we must add BD to pkg-create-dbgsym? | 07:38 |
| 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:41 |
| dholbach | good morning | 07:48 |
| geser | good morning dholbach | 07:53 |
| dholbach | hey geser | 08:00 |
| === 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 | ||
| 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:25 |
| Laney | looks so, indeed | 13:31 |
| Laney | wgrant: ^^^^? | 13:31 |
| === al-maisan is now known as almaisan-away | ||
| === Ng_ is now known as Ng | ||
| OwaisL | Guys, it seems revu is down. | 20:04 |
| 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:05 |
| tumbleweed | use mentors.debian.net instead? | 20:06 |
| OwaisL | tubleweed, thanks but the package is ubuntu specific. | 20:06 |
| OwaisL | depends on unity | 20:06 |
| 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:07 |
| OwaisL | Uploaded my package to mentos.debian.net; Anyone interested please have a look http://mentors.debian.net/package/gmailwatcher | 20:22 |
| 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:23 |
| OwaisL | tumbleweed, thanks! | 20:24 |
| === and`_ is now known as and` | ||
| Adri2000 | anyone has thought about syncing opencv 2.3 into precise? | 21:17 |
| === nixternal is now known as fifo | ||
| === fifo is now known as nixternal | ||
| 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:01 |
| 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:02 |
| 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:06 |
| 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:07 |
| jtaylor | (as long as you don't work with --save-after-login of course) | 22:08 |
| 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:10 |
| Corey | Build failure. :-( Now I get to figure out what I broke. | 22:14 |
| jtaylor | fun :) | 22:14 |
| 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:15 |
| 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:16 |
| Corey | Which is a static, non-compiled file. $packageroot/conf/minion is the file | 22:17 |
| broder | what is debian/compat? | 22:17 |
| 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:18 |
| 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:19 |
| Corey | I have to rerun debuild -S first, don't I... | 22:20 |
| 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:21 |
| 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:24 |
| Corey | If you wonder what's in the debian directory, https://github.com/saltstack/salt/tree/develop/debian | 22:25 |
| 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:27 |
| jtaylor | Isee no conf/minion in that source | 22:34 |
| jtaylor | Corey: ^ | 22:34 |
| jtaylor | only a conf/minion.template | 22:34 |
| 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:35 |
| Corey | Should I revert the changes to pathing I just made? | 22:36 |
| jtaylor | yes, I don't think dh_install does what broder though | 22:37 |
| jtaylor | also usually the destination has no leading / | 22:37 |
| Corey | Rebuilding. | 22:39 |
| Corey | I do appreciate how pbuilder caches packages it needs. | 22:39 |
| 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:41 |
| Corey | h_install: salt-minion missing files (modules/*), aborting <-- Progress! | 22:44 |
| Corey | Pathing issue, whee. | 22:45 |
| Corey | Holy crap, successful build. Thanks, jtaylor / broder. Now to figure out what else I've pooched. | 22:47 |
| Corey | Yay, a pile of things to fix from lintian! | 22:53 |
| Corey | When do I use architecture all vs any? | 22:55 |
| 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:56 |
| jtaylor | *C compiled, java mono are also all | 22:57 |
| 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:58 |
| Corey | Right, which causes lintian to moan | 22:59 |
| jtaylor | what error? | 22:59 |
| Corey | E: salt source: magic-arch-in-arch-list | 22:59 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| jtaylor | whats your control? | 23:01 |
| Corey | https://github.com/saltstack/salt/tree/develop/debian <-- jtaylor | 23:02 |
| 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:05 |
| 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:06 |
| Corey | Hmm. Will I break anything horrible if I throw the lintian version for Precise into Lucid? | 23:11 |
| jtaylor | no idea, but there is a hook to run lintian after a pbuilder build | 23:12 |
| jtaylor | which can be precise | 23:12 |
| 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:13 |
| jtaylor | I'd ahve to see a fully built package for that | 23:16 |
| Corey | jtaylor: Okay, we'll proceed for now. :-) | 23:16 |
| jtaylor | you should not build depend on libzmq1 | 23:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| Corey | A bunch of stuff to fix in the man pages, which I can punt on for a bit. | 23:27 |
| 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:28 |
| jtaylor | it should be salt-common (= ${binary:Version}) | 23:29 |
| Corey | salt-common already grabs python (>= 2.6), | 23:29 |
| 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:30 |
| Corey | jtaylor: This is new now that that's been applied; E: salt source: not-binnmuable-all-depends-any salt-minion -> salt-common | 23:33 |
| jtaylor | do what it suggests or override it | 23:34 |
| jtaylor | binNMU's are only important for offical debian packages | 23:34 |
| Corey | jtaylor: Yeah, it will be at some point, but not today. :-) | 23:36 |
| 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:37 |
| jtaylor | just add a python depends to silence it then | 23:38 |
| Corey | jtaylor: Worked, thanks. | 23:41 |
| 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:42 |
| Corey | jtaylor: The client needs to build a module for msgpack that's architecture dependant; the rest is python and doesn't care. | 23:44 |
| Corey | But it's that blend that's annoying lintian, I suspect. | 23:46 |
| jtaylor | sry I have to leave | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!