[03:32] <ESphynx> hey guys :)
[03:32] <ESphynx> at some point I'd like to rant about the horrible experience I had installing Oneiric on my computer :|
[03:33] <ESphynx> it just went from bad to worst...
[05:10] <Corey> I've got a git repository that I'd like to turn into a debian package.  The way it's situated right now is that the entire repo more or less contains a bunch of php files.  I want to drop these into place-- I don't need any configure or make steps for these.  What's the sanest way to structure the .install file?
[05:12] <StevenK> Use debian/dirs to create the directory structure you want, and then debian/install that has 'source <path to dest>'
[05:27] <Corey> StevenK: If everything is going to live in /var/somedirectory, do I need every subdirectory as well?
[05:27] <StevenK> Corey: debian/dirs should just be var/somedir then
[05:28] <Corey> That's simple. Thanks!
[05:33] <Corey> StevenK: Ah, so the install would be 'source /var/somedirectory/' or are my slashes off?
[05:33] <StevenK> No first slash
[05:33] <StevenK> <source file> var/somedir
[05:34] <Corey> Hmm.  When you say source file, how do you encompass "everything in the tarball less the debian directory?"
[05:34] <StevenK> *.php ? :-)
[05:35] <Corey> That's just it.  There are subdirectories to consider as well.
[05:36] <Corey> I more or less want the package to take the orig.tar.gz and unzip it into /var/somedirectory, full stop, the end. :-)
[05:39] <StevenK> Well, it's already unpacked when you build
[05:39] <Corey> Right.  The "build" is that untar process-- no makefile.
[05:39] <Corey> Essentially what I'm trying to do is have a repeatable process that uses the apt system.
[05:40] <StevenK> You can do mkdir ; cp -a --exclude debian  in your rules file if you wish
[05:40] <StevenK> debian/dirs and debian/install are good since they're *simple*, but you need to tell it exactly what you want.
[05:42] <Corey> StevenK: that'd be what, dh_make or dh_install?
[05:42] <StevenK> dh_make is not debhelper. It's dh_install.
[07:54] <vibhav> submittodebian doesn't work for me :(
[08:02] <dholbach> good morning
[08:18] <vibhav> submittodebian doesn't work for me :(
[08:20] <vibhav> dholbach: You told me to submit the patch to debian but It does not report
[08:21] <dholbach> I'm not sure how to debug this - maybe somebody else can help ^?
[08:22] <vibhav> Is there any other way to submit patches to debian?
[08:22] <dholbach> by mail
[08:23] <dholbach> http://www.debian.org/Bugs/Reporting and https://wiki.ubuntu.com/Debian/Bugs should help
[08:23] <dholbach> brb
[08:23] <vibhav> I sent debian the Launchpad Bug tracker address which had the patch
[08:25] <arand> vibhav: Just add the patch as an email attachment when sending it to the bug report.
[08:25] <vibhav> ok
[08:31] <arand> And if you have confirmed that it works *on Debian* add a patch tag by sending "tags bug# + patch \n thanks." to the control server
[08:33] <arand> In what way does submittodebian not work?
[08:38] <vibhav> arand: It just says that the bug has been reported, But I get no email
[08:40] <arand> vibhav: Ah, you haven't set up  sendmail, I presume?
[08:43] <vibhav> arand: must be
[08:43] <vibhav> How do i set it up?
[08:47] <arand> Hmm, from what I remember with exim4, it's rather hassly, it might be easier if you manage to get reportbug to use your current MUA (evolution? thunderbird?) to send things instead of sendmail...
[08:48] <arand> $HOME/.reportrc   add "mua thunderbird -someoptions" I*m guessing based on the manual pages
[08:52] <Laney> it knows how to speak smtp itself
[08:52] <Laney> just put "smtphost reportbug.debian.org" in ~/.reportbugrc
[08:52] <Laney> providing your ISP doesn't block such things
[08:55] <arand> Ah, that's much simpler!
[09:01] <vibhav> thanks Laney
[09:03] <tumbleweed> it should set itself up, these days
[09:04] <Laney> .there is a wizard on first run, yeah.
[12:40] <brainstorm> hello ! I'm trying to package a java-based software suite and upload it to launchpad
[12:40] <brainstorm> https://launchpadlibrarian.net/96625288/buildlog_ubuntu-oneiric-i386.snpeff_2.0.5d-1ubuntu3_FAILEDTOBUILD.txt.gz
[12:41] <brainstorm> unfortunately it fails on the install itsef, which is pretty simple: /usr/bin/sudo mkdir -p /usr/local/java/snpeff
[12:41] <brainstorm> make[1]: /usr/bin/sudo: Command not found
[12:41] <Zhenech> why should it install in usr/local?
[12:41] <jalcine_> Morning all
[12:41] <brainstorm> oops, sorry, that should have been /usr/share/java :-S
[12:42] <Zhenech> you usually install into $(CURDIR)/debian/tmp and copy it to the .deb afterwards
[12:43] <tumbleweed> firstly, it shouldn't be using sudo
[12:43] <Zhenech> yeah, that too
[12:43] <tumbleweed> second, it should respect CURDIR
[12:43] <tumbleweed> and yes, it should also respect PREFIX, which should avoid the /usr/local bit
[12:44] <brainstorm> I wrote an artificial Makefile (the original package did not have it) such as this: install:
[12:44] <brainstorm>         mkdir -p /usr/share/java/snpeff
[12:44] <brainstorm>         cp -a snpEff.* scripts galaxy /usr/share/java/snpeff
[12:44] <brainstorm> would that work ? do I need to tweak anything else ?
[12:45] <tumbleweed> brainstorm: what did it have? ant?
[12:45] <brainstorm> nope, nothing at all, it was just a .zip file: http://snpeff.sourceforge.net/
[12:46] <tumbleweed> ah, so it's binary, not source?
[12:46] <brainstorm> yes
[12:46] <tumbleweed> I'd not bother with the Makefil, and just use dh_install
[12:46] <brainstorm> tumbleweed: great, how should I proceed/read about ? :)
[12:46] <tumbleweed> but this could also be a reasonable learning opportunity on how the makefiel should behave, if you want :P
[12:46] <brainstorm> tweak debian/rules maybe ?
[12:46] <tumbleweed> dh_install has a manpage
[12:47] <tumbleweed> you should just be able to say "snpEff.* /usr/share/java/snpeff" in debian/install
[12:47] <brainstorm> tumbleweed: awesome ! thanks for that :)
[12:51] <geser> do PPAs allow it to just ship the .jar file and not the real source in the source package?
[12:57] <debfx> sure, as long as it's redistributable
[13:12] <brainstorm> oh, btw, dunno where to report this exactly, but there's a step on the packaging guide (http://developer.ubuntu.com/packaging/html/packaging-new-software.html), that does not survive reality: $ pbuilder-dist oneiric build kqrcode_0.4-0ubuntu1.dsc
[13:13] <tumbleweed> brainstorm: what's wrong with it?
[13:16] <brainstorm> tumbleweed: $ pbuilder-dist oneiric build snpeff_2.0.5d-1ubuntu1.dsc
[13:16] <brainstorm> E: File /home/vagrant/pbuilder/oneiric-base.tgz does not exist
[13:17] <tumbleweed> brainstorm: that's covered in http://developer.ubuntu.com/packaging/html/getting-set-up.html
[13:18]  * tumbleweed adds a link
[13:19] <brainstorm> aha, ok, thanks for the pointer :)
[13:21] <brainstorm> I've been thinking on how packaging would benefit from a ton of automation (instead of so much documentation). In that sense I've been looking at FPM: http://www.semicomplete.com/blog/tags/deb and filed an issue on GitHub: https://github.com/jordansissel/fpm/issues/170 … what do you think about that ?
[13:31] <arand> brainstorm: http://xkcd.com/927/ comes to mind, also, I wonder if it is really beneificial if people whi are unfamiliar with packaging can easily dump stuff in a PPA...
[13:31] <arand> *who
[14:36] <brainstorm> does dh_install (debian/install) create directories automatically (mkdir -p) if they don't exist ? i.e: /usr/share/java/snpeff ?
[14:37] <arand> brainstorm: Yes, afaik, you could treat it as "install -D" pretty much.
[14:39] <shadeslayer> hrw: when you're free, would it be possible for you to help me setup a arhf qemu builder?
[15:04] <shadeslayer> *armhf
[15:05] <tumbleweed> armhf works in qemu these days?
[15:05] <shadeslayer> dunno, armel/armhf whatever works, I have little knowledge of the field
[15:05] <tumbleweed> I thought one still needed native packages for a bunch of syscalls that aren't supported yet
[15:06] <tumbleweed> armel should "just work"
[15:06] <shadeslayer> is there a way I can get it to work with pbuilder?
[15:06] <tumbleweed> yeah, use qemu-debootstrap
[15:06] <tumbleweed> pbuilder-dist should know how to do it
[15:07] <shadeslayer> I think I've tried qemu-debootstrap
[15:07] <shadeslayer> I'll try pbuilder-dist
[15:09] <shadeslayer> tumbleweed: https://wiki.edubuntu.org/UbuntuDevelopment/Ports < I tried that earlier ( Specifically "pbuilder and QEMU syscall emulation" )
[15:10] <shadeslayer> heh : Warning: Unknown distribution "armel". Do you want to continue [y|N]?
[15:10] <tumbleweed> yup, that's pretty much what pbuilder-dist will do
[15:10] <tumbleweed> worked fine for me in the past
[15:13] <shadeslayer> tumbleweed: http://paste.kde.org/439076/
[15:13] <shadeslayer> line 7 and 8
[15:13] <Zhenech> armel is not a dist, but an arch
[15:13] <shadeslayer> Zhenech: uh, yea, I used --architechture armel
[15:14] <shadeslayer> another option was multiarch, but that's broken
[15:14] <shadeslayer> multistrap
[15:16] <shadeslayer> I'll try mk-sbuild --arch=
[15:17] <shadeslayer> *mk-sbuild --arch=armel precise
[15:17] <tumbleweed> shadeslayer: pbuilder-dist is doing http://paste.debian.net/159565/ for me
[15:17] <tumbleweed> yes, mk-sbuild should also work
[15:18] <shadeslayer> tumbleweed: pastebin your pbuilderrc? :)
[15:18] <tumbleweed> shadeslayer: empty
[15:18] <tumbleweed> (well, actually not, but for pbuilder-dist, an empty one should work)
[15:19] <shadeslayer> hmm
[15:20] <shadeslayer> lets see
[15:21] <shadeslayer> heh, Zhenech was right, I incorrectly supplied the args
[15:21] <Zhenech> \o/
[15:22] <shadeslayer> I should really stop multitasking, I'm no good at it :P
[15:28] <hrw> shadeslayer: never created qemu builders. I have real arm hardware
[15:28] <shadeslayer> :D
[15:28] <shadeslayer> I'll get a raspberry pi soon, won't be able to run Ubuntu on it tho
[15:34] <dupondje> you'll get a raspberry pi soon
[15:34] <dupondje> right :)
[15:35] <dupondje> still haven't received an order mail :(
[15:35] <Zhenech> I'll get mine this millenium *hope*
[15:57] <shadeslayer> dupondje: yes, I'll get it in like a month or so
[15:57] <shadeslayer> they reserved 400 boards for developers, I've been allocated one from the initial batch of 10000
[15:57] <shadeslayer> hrw: tumbleweed muwhahah, I made pbuilder-satisfydepends segfault
[15:57] <shadeslayer> /usr/lib/pbuilder/pbuilder-satisfydepends: line 60: 26036 Segmentation fault      (core dumped) $CHROOTEXEC aptitude -y --without-recommends -o APT::Install-Recommends=false "${PBUILDER_APTITUDE_CHECK_OPTS[@]}" -o Aptitude::ProblemResolver::StepScore=100 -o "Aptitude::ProblemResolver::Hints::KeepDummy=reject pbuilder-satisfydepends-dummy :UNINST" -o Aptitude::ProblemResolver::Keep-All-Level=55000 -o Aptitude::ProblemResolver::Remove-
[15:57] <shadeslayer> Essential-Level=maximum install pbuilder-satisfydepends-dummy
[15:58] <dupondje> lucky ! :)
[15:58] <tumbleweed> shadeslayer: :)
[15:58] <shadeslayer> dupondje: yeah :P , thanks to Nokia!
[15:59] <tumbleweed> are you using the latest qemu-user-static?
[16:00] <shadeslayer> nope
[16:00] <tumbleweed> that's usually a good idea
[16:01] <shadeslayer> ok
[16:32] <shadeslayer> tumbleweed: http://paste.kde.org/439160
[16:48] <brainstorm> tumbleweed: thanks guys ! it's up there ;) https://launchpad.net/~brainstorm/+archive/galaxy/+packages
[17:19] <shadeslayer> tumbleweed: no luck on upgrading qemu-user-static
[18:31] <tumbleweed> shadeslayer: nafc, worked for me (on sid)
[18:31] <shadeslayer> well
[18:31] <shadeslayer> It might be because of -D_FORTIFY_SOURCE=2
[18:32] <shadeslayer> I'll try it on sid
[18:36] <tumbleweed> I know I've used qemu-arm-static from Ubuntu dev releases before (on Debian) because I wanted newer qemus
[18:46] <shadeslayer> tumbleweed: you make qemu sound like a tasty fruit
[18:47] <tumbleweed> :P>
[18:58] <shadeslayer> \o/
[18:58] <shadeslayer> tumbleweed: thanks man
[19:06] <tumbleweed> np
[19:07] <tumbleweed> I assume that everything that works on Debian works on Ubuntu, not always true :)
[19:17] <Laney> iulian: did you see the removals that went by on d-haskell recently?
[19:17] <Laney> want to file them? :-) :-)
[19:17]  * Laney does some more test builds - soon will be able to unhold ghc again
[19:57]  * micahg wonders if cody-somerville is planning on ever updating catfish in Debian
[19:57] <cody-somerville> micahg, The last time I checked the upstream author had stopped developing it.
[19:58] <micahg> cody-somerville: I gave you a patch for dh_python2 conversion :)
[19:58] <cody-somerville> micahg, really. when?
[19:58] <micahg> months ago?
[19:58] <micahg> debian 641577
[20:00] <cody-somerville> ah. fancy that.
[20:01] <micahg> I needed to get python-support off the Xubuntu images for oneiric
[20:02] <cody-somerville> micahg, I assume you've already made the change in Ubuntu and that you're just looking to be able to drop the delta?
[20:02] <micahg> cody-somerville: yeah
[20:02] <cody-somerville> micahg, cool. I'll take care of that then. thanks for the ping.
[20:03] <micahg> cody-somerville: no rush on it, but there are several other open bugs as well
[20:04] <micahg> laney: how does one tell if a new version of a haskell package has features or not
[20:05] <Laney> the same way as for any other library
[20:06] <Laney> if you are concerned about my current syncs then don't be because there is an FFe
[20:08] <tumbleweed> the FFe being "sort the haskell stack out" :)
[20:08] <Laney> there were API changes in ghc's base libraries so some code changes are inevitable
[20:09] <micahg> laney: with most libraries, there's a changelog either upstream or in the package and I could find neither
[20:10] <Laney> a sad deficiency in the haskell ecosystem indeed
[20:13] <Laney> for a normal haskell freeze exception i would consider the fact that every new upstream is an abi break (so check how many rdepends) and would diff the two packages to see what the API changes are like
[20:28] <ScottK> So an upstream for Haskell always has 'features' since it needs a transition.
[20:28] <ajmitch> sounds like a dream to maintain
[20:29] <ScottK> Happiness is never needs to be confused about if you have to do a transition.