[01:11] <quidnunc> I am trying to create a package with cabal-debian. Prevu is spitting out the following error output http://paste.ubuntu.com/857260
[01:11] <quidnunc> Can anyone help?
[01:14] <quidnunc> I never managed to understand prevu's error messages. Usually it fails because a dependency is missing and I guess that might be the case here but I can't tell what exactly may be the missing dependency. Some of those listed should be installable.
[13:33] <pipedream> how do I disable a ./configure option in debian/rules ?
[13:33] <geser> depends on the configure script, but --disable-foo might work (see --help to be sure)
[13:35] <tumbleweed> pipedream: you'll want to add an override_dh_auto_configure rule (if you haven't figured that out already)
[13:35] <Ampelbein> pipedream: like http://paste.ubuntu.com/857790/
[13:36] <tumbleweed> even better :)
[13:36]  * tumbleweed stops playing with rcbugs for the day
[13:41] <pipedream> thanks
[14:30] <pipedream> I tried this in debian/rules, but it did not seem to have an effect:
[14:30] <pipedream> export DEB_LDFLAGS_STRIP=-Wl,-Bsymbolic-functions
[14:32] <tumbleweed> I'd prefer fixing that bug to stripping the flag
[14:32] <tumbleweed> but more to the point, that won't work because dpkg-buildpackge exports LDFLAGS before you export this
[14:33] <tumbleweed> you need to do something like export LDFLAGS=$(shell DEB_LDFLAGS_STRIP=-Wl,-Bsymbolic-functions dpkg-buildflags --get LDFLAGS)
[14:33] <tumbleweed> (this will get easire when dpkg-buildpackge stops exporting build flags
[14:42] <pipedream> tumbleweed: OK, really I want to first do the prebuilt binary version, and then perhaps that bug has been looked at. (But I'll try that other LD stuff in the meantime as well)
[14:46] <pipedream> So I want to create a deb package the "bzr-less" way from this:
[14:46] <pipedream> 0 jan@osprey:~/src/sagemath-upstream-binary$ls
[14:46] <pipedream> sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux.tar.lzma  usr
[14:47] <pipedream> I've unpacked it, and there is no building to do
[14:51] <tumbleweed> pipedream: right, so rename sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux.tar.lzma to sage-binary_4.8.orig.tar.lzma (or something like that)
[14:51] <tumbleweed> add add a debian/install file, to instruct dh_install
[15:06] <pipedream> tumbleweed: dh_install says the filename is package.install (not just install)
[15:06] <pipedream> dh_install man page
[15:07] <tumbleweed> if you only have one binary pcakage, you can drop package.
[15:09] <pipedream> So I can have contents like:
[15:09] <pipedream> # to instruct dh_install
[15:09] <pipedream> usr/bin/sage /usr/bin/sage
[15:09] <pipedream> usr/lib/sage /usr/lib/
[15:09] <tumbleweed> yes
[15:09] <tumbleweed> except that the second column is always a directory
[15:09] <pipedream> and then I need copyright, control, and changelog?
[15:09] <tumbleweed> and compat
[15:10] <pipedream> ok, re directory
[15:10] <tumbleweed> so "usr/bin/sage /usr/bin"
[15:10] <pipedream> yes
[15:11] <tumbleweed> see debhelper(7) for explanation of compat
[15:14] <pipedream> OK, I think that is done
[15:15] <tumbleweed> did you do any rearrangement? I don't have a usr at the root of the binary tarball
[15:16] <pipedream> uhm, I created usr/lib/ and untarred in there; then I copied /usr/lib/sage.../sage to /usr/bin and edited the variable SAGE_ROOT to point to it /usr/lib/sage...
[15:17] <tumbleweed> if you want to use their original tarball, you should do that all programmatically
[15:17] <pipedream> ok
[15:17] <pipedream> in rules with shell commands?
[15:17] <tumbleweed> so, a quilt patch for the SAGE_ROOT, and change the dh_install paths to match the original locations
[15:17] <pipedream> ooer
[15:18] <tumbleweed> quilt is easy, /me digs out the nice howto
[15:19] <tumbleweed> http://pkg-perl.alioth.debian.org/howto/quilt.html#the_post_modern_way + the quiltrc from http://www.debian.org/doc/manuals/maint-guide/modify.en.html#quiltrc
[15:19] <pipedream> install changed to:
[15:19] <pipedream> # to instruct dh_install
[15:19] <pipedream> sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux /usr/lib
[15:19] <pipedream> sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux/sage /usr/bin
[15:20] <tumbleweed> you can omit the root directory name
[15:20] <pipedream> ?
[15:20] <tumbleweed> sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux
[15:20] <tumbleweed> every tarball should have a root directory, and the name is unimportant
[15:21] <pipedream> so changed to:
[15:21] <pipedream> * /usr/lib/sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux
[15:21] <pipedream> sage /usr/bin
[15:22] <tumbleweed> I would call it /usr/lib/sage instead of /usr/lib/sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux but sure
[15:23] <pipedream> maybe for the real built-from-source (then you can also install both next to each other)
[15:23] <tumbleweed> not if thy both provide /usr/bin/sage
[15:23] <pipedream> /etc/alternatives, maybe, hmm, but yes
[15:24] <pipedream> I wouldn't want to change the /usr/bin/sage name now, so I guess they can Conflict:
[15:24] <tumbleweed> yup
[15:24] <pipedream> ok, reading some quilt..
[15:27] <tumbleweed> pipedream: if I wasn't clear earlier, your debina directory should be inside sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux
[15:32] <pipedream> thanks
[15:33] <pipedream> d=. ; while [ ! -d $d/debian -a `readlink -e $d` != / ]; do d=$d/..; done
[15:33] <pipedream> if [ -d $d/debian ] && [ -z $QUILT_PATCHES ]; then # if in Debian packaging tree with unset $QUILT_PATCHES QUILT_PATCHES="debian/patches" QUILT_PATCH_OPTS="--reject-format=unified" QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto" QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index" QUILT_COLORS="diff_hdr=1;32:diff_add=1;34:diff_rem=1;31:diff_hunk=1;33:diff_ctx=35:diff_cctx=33"
[15:33] <pipedream>  if! [ -d d$d/debian/patches ]; then mkdir $d/debian/patches; fi
[15:33] <pipedream> oops
[15:33] <pipedream> sorry
[15:33] <pipedream> mouse trouble :-P
[15:48] <pipedream> ok, so I still need a rules file and --with-quilt?
[15:48] <tumbleweed> sorry, yes rules
[15:48] <tumbleweed> rather put '3.0 (quilt)' in debian/source/format than use with-quilt
[15:50] <pipedream> OK, got source/format and the standard almost-empty rules that just does %: dh $@
[15:51] <tumbleweed> yup
[15:55] <pipedream> OK, and cat debian/postinst
[15:55] <pipedream> # Run sage once as root to set the paths correctly
[15:55] <pipedream> echo 'exit' | /usr/bin/sage
[15:56] <tumbleweed> urgh, do you have to do that?
[15:57] <tumbleweed> will that create files?
[15:58] <pipedream> uhm
[15:58] <pipedream> mebbe
[15:58] <pipedream> I'll ask
[15:59] <tumbleweed> if so, they must be deleted again in prerm/postrm
[16:00] <tumbleweed> also, you want to check postinst arguments, see the standard examples: /usr/share/debhelper/dh_make/debian/postinst.ex
[16:00] <pipedream> ok
[16:05] <Zhenech> http://www.ebay.de/itm/BRAND-NEW-BOX-UNLOCKED-SAMSUNG-GALAXY-S-GLIDE-ROGERS-/230731758356?pt=Cell_Phones&hash=item35b8af3b14#ht_500wt_922
[16:06] <Zhenech> kauf ich mir das jetzt oder nid
[16:06] <Zhenech> ups, ECHAN :)
[16:21] <arand> Is it possible to submit a screenshot to USC via some other means that screenshots.d.n? redeclipse is contrib/non-free and hence not hosten via s.d.n ...
[16:22] <arand> *hosted at
[16:30] <pipedream> if I want to add a symlink, /usr/bin/sage -> /usr/lib/sage-.../sage, do I do this with postinst? (This will mean not having to do the quilt patching)
[16:31] <tumbleweed> dh_link
[16:32] <tumbleweed> packages are much more reliable if they don't do anything in maintainer scripts (postinst et al), or at least only do things that were automatically added by debhelper
[16:36] <pipedream> $cat links
[16:36] <pipedream> /usr/bin/sage /usr/lib/sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux/sage
[16:37] <tumbleweed> other way around
[16:37] <pipedream> woops, ja
[16:37] <pipedream> so then I can change format/source to '3.0'?
[16:38] <pipedream> as quilt is no longer used
[16:38] <tumbleweed> there is no "3.0". 3.0 (quilt) is the right choice for almost all packages
[16:38] <pipedream> and remove the .pc the quilt commands made?
[16:38] <pipedream> debian/patches and .pc
[16:38] <tumbleweed> you can remove .pc and debian/patches
[16:39] <pipedream> So, from what I can tell the running sage once from the postinst will not create new files (waiting on dfinitive answer though)
[16:39] <tumbleweed> what *does* it do then?
[16:39] <pipedream> so I think I might be ready to turn this into a package?
[16:39] <pipedream> it removes pyc files and recreates them
[16:40] <pipedream> with a new path hardcoded
[16:40] <psusi> the output of apt-cache rdepends --recurse is about useless.  is there a better way to visualize the dependency tree?  for instance, see how ubuntu-desktop depends on packageX?
[16:40] <psusi> ( indirectly )
[16:40] <quidnunc> Can someone help me with this prevu error? http://paste.ubuntu.com/857260/
[16:41] <pipedream> 0 jan@osprey:~/src/sagemath-upstream-binary/sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux$find local/lib/python/site-packages/ -name '*pyc' | wc -l
[16:41] <pipedream> 4268
[16:42] <tumbleweed> pipedream: more likely it recreates them with the system's python. If this weren't a hacky binary-only package, I'd suggest doing that properly with dh_python2
[16:47] <tumbleweed> quidnunc: I suggest trying to install all of those build-deps in a oneiric chroot, to figure out which one isn't installable. pbuilder doesn't give the most helpful errors
[16:50] <pipedream> tumbleweed: ok, what are the next steps to turn that into a package?
[16:50] <tumbleweed> debuild -uc -us
[17:01] <pipedream> it fails, I think because it is finding the Makefile which shouldn't be there anymore, as everything is built. So I moved it out the way (to test that theory) and built a 1.2M deb
[17:01] <pipedream> I had to change install as well (it tried to copy the debian directory as well)
[17:02] <tumbleweed> ah, helpful makefile
[17:03] <tumbleweed> I suggest putting empty override_dh_auto_configure override_dh_auto_build and override_dh_auto_install rules in your debian/rules
[17:05] <pipedream> OK, but dinner first ;)
[17:08] <tumbleweed> pipedream: oh, and I left out override_dh_auto_clean, which will actually be the culprit here
[17:10] <nava> Hi, is software centre have a channel ?
[17:11] <pipedream> is this channel logged?
[17:12]  * pipedream realised his screen is not logging :-\
[17:23] <tumbleweed> pipedream: yes, irclogs.ubuntu.com. But there's 1hr lag
[17:23] <quidnunc> tumbleweed: <sigh>. Thanks
[17:24] <tumbleweed> quidnunc: jtaylor was suggesting an alternative pbuilder dependency resolver a few days ago, apparently it gives better errors
[17:25] <quidnunc> tumbleweed: Is grepping the irc logs to the best way to find it?
[17:26] <quidnunc> I really hate debian packaging
[17:26] <quidnunc> I can't understand why no one shares that disdain
[17:27] <tumbleweed> quidnunc: what would you fix?
[17:28] <quidnunc> tumbleweed: Less painful to make packages, less painful to add custom patches to packages. Essentially more like arch's packaging system
[17:28] <quidnunc> tumbleweed: But I would put the question back to you: Why do think it is the best packaging system on the "market" today?
[17:29] <tumbleweed> quidnunc: I don't find it painful at all. And I don't know arch's packaging system
[17:29] <tumbleweed> quidnunc: 00:27 < jtaylor> I prefer PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-gdebi"
[17:29] <quidnunc> Make is sane to build packages that have dependencies that also need to be built.
[17:29] <quidnunc> ^ tumbleweed What about that use case?
[17:29] <tumbleweed> Debian is a binary distribution, not source
[17:29] <quidnunc> That's pretty painful
[17:30] <quidnunc> tumbleweed: Arch is mixed
[17:30] <tumbleweed> Debian isn't
[17:30] <quidnunc> I know
[17:31] <quidnunc> It just shouldn't make it so difficult to build from source.
[17:31] <quidnunc> In arch/gentoo it is possible to write a package that will build from git head.
[17:31] <quidnunc> That is really nice
[17:32] <quidnunc> and it will build all the dependencies for you too
[17:32] <quidnunc> Debian is clearly worse there
[17:32] <tumbleweed> quidnunc: I don't see a reasonable way to implement something like that in a pure-binary distribution
[17:33] <quidnunc> tumbleweed: I don't understand what the impediment is. There are already poor methods that do it in debian (e.g. uupdate)
[17:33] <quidnunc> tumbleweed: THanks for the alt pbuilder
[17:33] <tumbleweed> quidnunc: I never use uupdate. If you have your packages in VCS, you don't really need it
[17:34] <tumbleweed> launchpad daily builds accomplish a lot of what you are talking about, but they need to be set up
[17:34] <quidnunc> tumbleweed: ? How do you get changes from upstream?
[17:35] <quidnunc> i don't think we are talking about the same thing
[17:36] <quidnunc> tumbleweed: Anyway I have been beating this dead horse for years and I have to go.
[17:36] <tumbleweed> quidnunc: https://help.launchpad.net/Packaging/SourceBuilds
[17:36] <quidnunc> thanks for the help with pbuilder
[17:36] <tumbleweed> of course we aren't. The same thing isn't really applicable here
[17:36] <quidnunc> tumbleweed: This is for code stored in lp only?
[17:37] <tumbleweed> launchpad can import branches from elsewhere
[17:38] <quidnunc> tumbleweed: Thanks that looks interesting, despite how comparatively convoluted it is.
[17:38] <quidnunc> Though it still doesn't solve building dependencies I imagine.
[17:39] <quidnunc> Anyway I really have to go
[17:39] <quidnunc> Thanks for the help
[17:39]  * tumbleweed should stop feeding trolls, anyway
[18:43] <pipedream> tumbleweed: http://pastebin.ubuntu.com/858168/
[18:45] <pipedream> ^^ the from-
[18:45] <pipedream> upstream-binary package
[18:45] <pipedream> On the other hand, the from source, with -Bsymbolic-functions removed got a LOT further
[18:45] <tumbleweed> aargh, dh_auto_test
[18:45] <pipedream> http://pastebin.ubuntu.com/858170/
[18:46] <tumbleweed> trying to help without playing along never works well
[18:46] <tumbleweed> pipedream: you need another override: ^
[18:46] <pipedream> I'll do the override
[18:46] <pipedream> in the from-source packages, those html docs are always the last thing to build in sage. That means all the components built successfully
[18:47] <pipedream> I think
[18:47] <pipedream> the dh_auto_test is the from-source package, not the from-binary packge
[18:47] <pipedream> sorry, I am mixing two things
[18:47] <tumbleweed> I was talking about the binary one
[18:47] <pipedream> ok
[18:47] <pipedream> funny, the from-source one had this near the end
[18:48] <pipedream> dh_auto_test: make -j1 test returned exit code 2
[18:48]  * tumbleweed suspects that they don't make test very often
[18:48] <pipedream> actually, they make test quite a lot
[18:48] <tumbleweed> I suggest disabling the test suite (overriding dh_auto_test here too) for now
[18:49] <pipedream> (and make testlong and make ptestlong and many more)
[18:49] <tumbleweed> debug it later
[18:49] <pipedream> (they got almost 90% doctest coverage now)
[18:49] <pipedream> ok
[18:49] <pipedream> will disable dh_auto_test
[20:17] <l3on> Hi all!... someone of you can try a rebuild of flowscan ?
[20:17] <l3on> I'm getting this error: checking that service name for 80/tcp is www... no
[20:17] <l3on> configure: error: Please change /etc/services so that the service name for 80/tcp is www with alias http
[20:18] <l3on> so it's a local configuration issue... and I don't know if it's affect also the ubuntu build machines..
[20:18] <l3on> buildlog → http://debomatic.debian.net/precise/pool/flowscan_1.006-13build1/flowscan_1.006-13build1.buildlog
[20:21] <jbicha> l3on: would you be interested in packaging epiphany-extensions 3.3.90?
[20:24] <l3on> jbicha, why not...
[20:24] <l3on> but, we can still add new features in ubuntu ?
[20:26] <jbicha> l3on: epiphany-extensions 3.2 isn't installable & it should really be the same version as epiphany-browser so it shouldn't be a problem
[20:28] <jbicha> I don't think it needs a feature freeze exception
[20:32] <micahg> tumbleweed: chemical-mime-date was just uploaded to Debian to fix the rsvg issue, so maybe we can just sync
[20:33] <micahg> jbicha: still needs one if it has new features, but should be easy to get
[20:33] <tumbleweed> micahg: I see
[20:35] <jbicha> micahg: 1 new feature: rewritten adblock extension
[20:36] <micahg> jbicha: right, so you need to request the FFe, just include the whole backstory and it shouldn't be an issue
[21:20] <Adri2000> Laney: https://launchpad.net/oneiric-backports's description needs s/natty/oneiric/
[21:22] <micahg> Adri2000: Laney: oneiric-backports description fixed
[21:55] <stefanct> i have not grasp launchpad completely yet... but the upstream connection here is bogus afaics https://launchpad.net/ubuntu/+source/flashrom
[21:56] <tumbleweed> stefanct: unlinked
[21:57] <stefanct> tumbleweed: thanks and sorry about filing the unnecessary FFE
[21:58] <tumbleweed> np
[21:58] <tumbleweed> better that than ignoring the freeze and uploading new upstream versions :)
[21:58] <tumbleweed> ockham: o/
[21:58] <Adri2000> micahg: thanks.
[21:59] <stefanct> hm.. i presume qastaging.launchpad.net is synced by a cron job once in a while?
[21:59] <Adri2000> Laney: you can ignore my previous message, it's been fixed
[21:59] <ockham> tumbleweed: setting DEBEMAIL and DEBFULLNAME in ~/.bashrc now.
[22:00] <ockham> thx
[22:00] <tumbleweed> stefanct: qastaging is where LP developers test every new revision
[22:00] <tumbleweed> I don't know how often its data is updated, but I don't think that often
[22:01] <stefanct> tumbleweed: hm ok... because i cant link my project as the upstream project because it is already linked... ;)
[22:02] <tumbleweed> stefanct: don't worry about qastaging, it's contents are throw-away
[22:02] <stefanct> can projects be removed easily (so i can test on the live server without fear)?
[22:03] <stefanct> tumbleweed: i dont worry about that.. i just cant test there because the upstream link you removed is still present there...
[22:03] <tumbleweed> ah, let me unlink it there too
[22:04] <stefanct> thanks, now that step works.
[22:24] <quidnunc> How do I confirm universe is available in pdebuild?
[22:24] <tumbleweed> pbuilder --login and read the sources.list
[22:25] <quidnunc> argh. Why does it say hardy?
[22:26] <tumbleweed> quidnunc: what's in your .pbuilderrc ?
[22:27] <quidnunc> Right now: COMPONENTS="main restricted universe multiverse"
[22:27] <quidnunc> tumbleweed: But I had some other things in there that I copy-pasted from who knows where a long time ago
[22:27] <quidnunc> which I have now deleted
[22:28] <quidnunc> best to restart pbuilder create I guess
[22:28] <tumbleweed> right, and presumably those used to support multiple distributions
[22:28] <Laney> micahg: merci
[22:28] <ockham> tumbleweed: i've succesfully run backportpackage
[22:28] <ockham> now
[22:28] <ockham> would you suggest to just build a deb locally now, or upload to my PPA, or...?
[22:29] <quidnunc> What the hell? sudo pbuilder create says "Distribution is hardy"
[22:29] <tumbleweed> ockham: whatever works for you. I generally end up with hacked versions of a few packages on my machines :)
[22:31] <ockham> tumbleweed: then i'll probably build it locally. thx for introducing me to backportpackage, looks nifty.
[22:37] <quidnunc> "sudo DIST=oneiric pbuilder create" -> "Distribution is hardy". What gives/
[22:37] <quidnunc> ?
[22:38] <ajmitch> quidnunc: got DISTRIBUTION set in ~/.pbuilderrc?
[22:38] <tumbleweed> quidnunc: because you removed the bits of your .pbuilderrc that did anything useful with DIST?
[22:42] <quidnunc> tumbleweed: pbuilderrc is responsible for that automagic?
[22:42] <quidnunc> ajmitch: No
[22:42] <arand> quidnunc: Also, pbuilder-dist might be more convenient.
[22:43] <tumbleweed> quidnunc: yes
[22:43] <tumbleweed> but if you use pbuilder-dist, you don't need any of that
[22:43] <quidnunc> arand, tumbleweed: thanks
[22:45] <ockham> this is a bit embarassing, but given a source dsc file, what's the quickest way to build a binary deb?
[22:45] <ockham> do i *have* to dpkg-source -x it?
[22:46] <tumbleweed> ockham: whatever you've already set up :)
[22:46] <tumbleweed> if you're going to use pbuilder/sbuild, no
[22:47] <ockham> tumbleweed: sry, now i don't quite understand. backportpackage produced the dsc, but didn't leave a source directory, so i was wondering if i had to extract it...
[22:47] <quidnunc> ockham: Use pbuilder
[22:47] <quidnunc> man pbuilder
[22:48] <tumbleweed> ockham: if you want to build it directly on your system, you have to extract it
[22:48] <tumbleweed> if you are going to use a build system, they normally just take a source package
[22:49] <ockham> tumbleweed: do i have to use pbuilder even if the target system is the one i'm on?
[22:50] <ockham> or  is there another way that also can deal with the source package
[22:50] <tumbleweed> not at all. Packages should build correctly on dirty systems
[22:52] <bobbyrward> How does attaching a debdiff to a bug work when there's a version in -proposed?  Should I base it off of the proposed version?
[22:52] <ockham> tumbleweed: could you sync now? :P
[22:52] <tumbleweed> only when LP picks it up. Wait 12 hours
[22:56] <stefanct> btw.. where can i check if LP has picked up a new debian version?
[22:56] <tumbleweed> stefanct: launchpad.net/debian/+source/$packagename
[22:57] <stefanct> ah the "latest upload" thingy is the debian version?
[22:58] <stefanct> yes.
[23:52] <quidnunc> What is the pbuilder-dist equivalent of pdebuild?