[00:15] <tumbleweed> l3on: looks good, I'll upload it. Please state your intention to nmu (nmudiff --delay=2) and pts-subscribe to the package (for a limited time)
[00:16] <l3on> tumbleweed, nmudiff --delay=2 ? how ?
[00:17] <tumbleweed> nmudiff is like submittodebian, you run it inside the unpacked source
[00:28] <ajmitch> stgraber: does the isc dhcpv6 client work properly on ppp links?
[00:29] <stgraber> ajmitch: no idea how ipv6 works on PPP, my guess is that the point to point /64 should be handled by ppp itself, then your /48 or /56 routed over it without using dhcpv6
[00:30]  * ajmitch saw a mailing list thread about ppp support in the isc client from august, there was a patch submitted back then
[00:30] <ajmitch> I know that dhcpv6 works with the wide-dhcpv6-client, as that's what I use at home
[00:30] <ajmitch> just wasn't sure if the ipv6/ppp patch made it into the version you want tested :)
[00:31] <stgraber> ah, ok, well, there were a lot of fixes for ipv6 in the new package, but if the patch was pushed in august, it likely made it to 4.2, not 4.1
[00:31] <ajmitch> ok
[00:53] <l3on> tumbleweed, bug debian 660041
[07:33] <Whoopie> Hi, what needs to be done that the vpnc package is synced from Debian?
[07:35] <micahg> Whoopie: requestsync -e -d unstable vpnc
[07:36] <Whoopie> micahg: hehe, and who could do that? The Debian version now supports my Fritzbox router so that I don't have to maintain my own package in my PPA.
[07:37] <micahg> Whoopie: you can run that if you have ubuntu-dev-tools installed, it'll ask you to explain why it needs a feature freeze exception
[07:37] <micahg> then if the release team approves, it'll go in the sponsorship queue
[07:38] <Whoopie> micahg: ah, nice. Didn't know that. Thanks.
[07:38] <micahg> being that'd we'd much prefer stuff in distro than in PPAs, it will probably be approved
[07:39] <micahg> and that it's mostly bug fixes, we're right after feature freeze and a bunch of other reasons
[07:39] <micahg> but IANA release team member, but will be happy to sync it once it's approved
[07:53] <Whoopie> micahg: lp #937548 opened
[07:53] <dholbach> good morning
[07:53] <micahg> Whoopie: thanks
[07:53] <micahg> dholbach: good morning
[07:55] <dholbach> hey
[15:39] <tkennedy> Having some issues with creating a binary package and the upstream tarball has one python script for creating documentation
[15:40] <tkennedy> can any one help me figure this out
[15:40] <tumbleweed> tkennedy: it helps if you tell us what the problem is
[15:40] <tkennedy> was just waiting for a response before I spit out the details....thansk for responding
[15:42] <tkennedy> basically when I run pbuilder I get this error:
[15:42] <tkennedy> /usr/bin/python "./html.py" -d . csd.xml > csd.html || (rm csd.html; exit 1)
[15:42] <tkennedy> Traceback (most recent call last):
[15:42] <tkennedy>   File "./html.py", line 15, in <module>
[15:42] <tkennedy>     import pprint
[15:43] <tkennedy> ImportError: No module named pprint
[15:43] <tkennedy> but I can run that python script manually without issue
[15:43] <tumbleweed> where is pptrint.py?
[15:44] <tkennedy> it's appart of the python package
[15:44] <tumbleweed> oh, sorry :)
[15:44] <tumbleweed> one of those modules I don't use much
[15:45] <tumbleweed> err ever
[15:45] <tkennedy> I thought that maybe it was a dependancy that wasn't installed but it is
[15:45] <tumbleweed> are you build-depending on python?
[15:46] <tkennedy> well the main part of the package is native code
[15:46] <tkennedy> but there is just this python script to build the documentation
[15:46] <tumbleweed> right, so it needs python to build
[15:46] <tkennedy> so I guess in a way it would need python support in the control file
[15:46] <tkennedy> but there are other import modules in the python script that don't error out
[15:47] <tumbleweed> no, you don't need python-support if you aren't shipping python modules
[15:47] <tumbleweed> chances are you have python-minimal installed in your chroot, and that's why you can import some modules
[15:47] <tkennedy> well by support I meant dependancy
[15:47] <tumbleweed> but your package must build-depend on everything it needs
[15:47] <ScottK> python-minimal is essential in Ubuntu.
[15:47] <ScottK> So it's certainly there.
[15:47] <tumbleweed> indeed :)
[15:48] <tkennedy> right. Like I said I can run the script manually and it runs just fine
[15:49] <tkennedy> I'm not sure why pprint module is causing this issue
[15:49] <tumbleweed> tkennedy: pprint isn't in python-minimal
[15:49] <tumbleweed> and you aren't build-depneding on python, which is what you need
[15:50] <tkennedy> so I need to add python to the list of dependancies then
[15:50] <tumbleweed> yes
[15:56] <tkennedy> ok that got me past the python issue
[15:56] <tkennedy> thanks
[16:30] <mdomsch> o
[16:45] <tkennedy> ok having another issue now with pbuilder and building that same package.
[16:45] <tkennedy> Now I get this error
[16:45] <tkennedy> cp: cannot stat `debian/tmp/usr/bin': No such file or directory
[16:45] <tkennedy> dh_install: cp -a debian/tmp/usr/bin debian/openconnect//usr/ returned exit code 1
[16:45] <tkennedy> make: *** [binary] Error 2
[16:45] <tkennedy> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
[16:45] <tkennedy> E: Failed autobuilding of package
[16:45] <tkennedy> my rules file just has this
[16:45] <tkennedy> %:
[16:45] <tkennedy> 	dh $@ --list-missing
[16:52] <tkennedy> I know what the error means, but I'm not sure why it's trying to cp to a directory that it didn't create
[16:52] <tkennedy> I'm a noob to packaging...been reading the PackagingGuide for a few days
[16:53] <tkennedy> what I'm trying to build is probably a bit advanced for a noob
[16:54] <tkennedy> Just in case someone is actually reading this I'll go over what I've been doing thus far.
[16:56] <tkennedy> I want to create a package for openconnect-3.15 to put in my PPA. So I downloaded the 3.02 source from universe like so:
[16:56] <tkennedy> apt-get source openconnect
[16:56] <tkennedy> which got me openconnect_3.02
[16:56] <tkennedy> then I did uscan --verbose to get the latest code from the watch file
[16:56] <tkennedy> then I did uupdate to apply the latest code
[16:56] <tkennedy> checked the changelog like this dch -e
[16:57] <tkennedy> Modified the control file to add python2.7 to the build dependancies
[16:57] <tkennedy> then ran debuild -S -sa
[16:57] <tkennedy> then ran pbuilder build openconnect_3.15-0ubuntu1.dsc
[16:58] <tkennedy> thats when I get the error
[16:59] <tkennedy> the 3.02 source rules file expects to make two packages I think. one binary and one dev library.
[16:59] <tkennedy> I think I did away with that when I edited the rules file and just left the default rule in there for autobuild
[17:02] <dholbach> for finding issues like this I'd recommend to build locally (just 'debuild' - not with pbuilder) to figure out what exactly was installed where and find which paths might have changed
[17:03] <tkennedy> it results in the same error
[17:04] <dholbach> sure, but you can inspect debian/tmp and see where files are actually installed to
[17:04] <dholbach> so you can update your debian/<binarypackage>.install files, etc.
[17:09] <tkennedy> so the debian directory reference would be within the source package correct?
[17:10] <tkennedy> or maybe it's under /tmp/source_name
[17:11] <tkennedy> nevermind I found it
[17:16] <tkennedy> so under debian/tmp/ there is no bin directory
[17:16] <tkennedy> just an sbin directory
[17:18] <tkennedy> so the old .install file for 3.02 has it getting installed in usr/bin but the debuild is putting it in usr/sbin
[17:22] <tkennedy> why does debuild want to put it in usr/sbin rather than usr/bin
[17:22] <tkennedy> clearly the 3.02 Makefile has an install: section where it's copy to /usr/bin
[17:26] <tkennedy> so I guess I could fix this one of two ways. Either modify the newer Makefile.in and copy over the install: section from the old Makfile or edit the .install file under debian and change the path to /usr/sbin
[17:26] <tkennedy> I'm not sure which is the more correct way to go
[17:35] <Ampelbein> tkennedy: you should change the debian/install file, upstream most likely knows best where it's stuff should go.
[17:44] <tkennedy> good point. In the case of an upgrade would apt/dpkg auto remove the old version or do I need to take care of that in POST-INST script
[17:45] <Ampelbein> It would be automatic
[17:49] <tkennedy> ok. thanks.
[17:49] <tkennedy> after making the change to the debian/install file debuild ran without issue and created the package
[18:03] <stefanct> before filing a FFE (or normal sync requests in the future) id like to compile the debian source package. i tried setting up a debian unstable mirror in sources.list and pinned the packages (via origin) to priority -10. the problem is now: how to tell apt-get source the right mirror? -t unstable does not work (Ignore unavailable target release 'unstable' of package ...)
[18:05] <jtaylor> stefanct: you should try and build it in ubuntu not unstable
[18:07] <stefanct> jtaylor: sure that's what i wanna do. but i thought getting the existing debian source package is the easiest way to get started?
[18:07] <jtaylor> you can get it easily with pull-debian-source from ubuntu-dev-tools
[18:08] <jtaylor> dget'ing the dsc also works
[18:08] <stefanct> i knew about dget, not pull-debian-source. great, thank you.
[18:32] <orbisvicis> I'm getting a bunch of "Cannot open: No space left on device" when building a package using pbuilder
[18:33] <orbisvicis> since none of my partitions are running out of space, I assume the chroot has a fixed size
[18:33] <orbisvicis> how do I increase it ?
[18:33] <jtaylor> pbuilder uses the root filesystem
[18:33] <jtaylor> sure there is enough space?
[18:35] <orbisvicis> i though it used whatever BUILDPLACE is, /var/cache/pbuilder/build/
[18:35] <orbisvicis> yes
[18:36] <orbisvicis> oh it is probably a write error (cannot open), pdebuild didnt obtain root privileges probably
[18:37] <orbisvicis> shouldn't it ask ?
[18:37] <orbisvicis> iirc
[19:03] <orbisvicis> it seems to be a problem with dpkg-source called by dpkg-buildpackage called by pdebuild
[19:06] <orbisvicis> dpkg-source: info: building php5 using existing php5_5.3.6.orig.tar.gz
[19:06] <orbisvicis> tar: php-5.3.6/scripts/dev/generate-phpt/tests/gtErrorTestCaseFunctionTest.php: Cannot open: No space left on device
[19:12] <orbisvicis> hmm maybe I don't have space...
[19:12] <orbisvicis> probably some xfs fragmentation issue
[19:35] <soren> ?!?
[19:35] <soren> xfs fragmentation issue?
[19:46] <orbisvicis> soren: yeah not enough contiguous blocks for additional inodes
[20:04] <broder> hmm...i wish there was an easy way to generate a reverse-dependency tree for a single package
[20:04] <broder> i wonder if reverse-depends should do that
[20:04] <broder> i guess i can probably script it easily enough
[20:04] <soren> broder: apt-cache dotty?
[20:04] <broder> soren: is there any way to filter that, though? i *really* don't care about the dependency graph for the whole archive...
[20:05] <soren> "apt-cache dotty <the package>"
[20:05] <broder> that's forward dependencies
[20:05] <soren> Oh, you wanted rdeps. Sorry.
[20:06] <tumbleweed> broder: that'd be best done server-side (reverse-deps)
[20:06] <soren> broder: In that case:
[20:06] <broder> tumbleweed: yeah, that'd certainly be better
[20:06] <soren> broder: apt-cache --recurse depends <whatever>
[20:06] <tumbleweed> and it would very easily get massive...
[20:06] <broder> whoa...soren wins
[20:07] <broder> (--recurse rdepends also works)
[20:07] <tumbleweed> neat, didn' tknow that
[20:07] <soren> Turning that into a queryable tree structure is left as an exercise to the reader.
[20:07] <broder> soren: the tree isn't actually important. i mostly just want a list of packages
[20:07] <soren> broder: Sorry, meant rdepends of course. Mistyped :)
[20:07] <broder> so sort -u is sufficient
[20:07] <soren> Cool beans.
[20:07] <soren> Enjoy.
[20:22] <soren> orbisvicis: You think that's more likely than being out of disk space?
[23:36] <jtaylor> wtf hdf5 has a 7mb source package and a 13mb debian diff oO
[23:36] <EvilResistance> sounds like its huge :P
[23:37] <jtaylor> omg uuencoded docs
[23:37] <EvilResistance> o.O
[23:42] <jtaylor> does arm{el,hf} have something equivalent to x86 cpu caches (L1-3=
[23:45] <jtaylor> because the pytables non86 failures seem to be related to their in memory compression for cache hit improvement
[23:45] <jtaylor> would probably make sense to just disable that on those arches
[23:46] <jtaylor> unlikely to have much effect anyway on slower cpu's
[23:48] <jtaylor> ffs "Unfortunately, you cannot disable blosc in PyTables"