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