[00:20] <fcuk112> when updating a patch in a merge where the patch is still valid but the line numbers have changed, can you just change the line numbers instead of doing the patch from scratch?
[01:10] <lfaraone> Hey, my build is failing with "dpkg-shlibdeps: error: no dependency information found for /usr/local/lib/libgtksheet-x11-2.0.so.0 (used by debian/python-gtksheet/usr/lib/python2.6/dist-packages/gtk-2.0/gtksheet/_gtksheetmodule.so).". How can I either A) ignore the error, or B) add deps?
[01:13] <ajmitch> first thing would be to fix it so that it doesn't go into /usr/local/lib :)
[01:20] <fcuk112> lfaraone: i had a similar error, i fixed it by adding export LD_LIBRARY_PATH=xxx to my .pbuilderrc.
[01:20] <ajmitch> that really doesn't sound like the right fix
[01:20] <fcuk112> where xxx is a local path where it can find the missing dep.
[01:21] <fcuk112> no? :(
[01:22] <ajmitch> for example in lfaraone's problem - there really shouldn't be a library at /usr/local/lib/libgtksheet-x11-2.0.so.0 - it means that it's been installed into the wrong location
[01:27] <lfaraone> ajmitch: I think that's a local lib I installed when I first tried out the upstream source.
[01:28] <ajmitch> you should build inside pbuilder or sbuild
[01:35] <lfaraone> ajmitch: I should.
[01:36] <lfaraone> ajmitch: right now this is just for a quick, internal-use deb, but eventually I hope to get it into the archives.
[01:37] <ajmitch> it helps a lot just to make sure you get a clean build - some things can be hidden by having the files from a previous build around
[01:38] <lfaraone> ajmitch: main issue is I can't figure out all the packages whcih this package depends upon.
[01:38] <ajmitch> that's the fun part :)
[01:39] <ajmitch> figuring out build-depends can be annoying, reading configure.ac to get an idea of what packages are used will give you a hint at least
[01:40] <ajmitch> as will seeing configure fail
[01:40] <lfaraone> ajmitch: but since pdebuild starts clean every time, it can be a very lengthly process. (since I have to download archives, etc)
[01:41] <ajmitch> caching the downloaded packages helps
[01:41] <ajmitch> pbuilder should be setup to do that, it grabs a copy of packages that are used & stores them
[01:42] <lfaraone> ajmitch: it doesn't seem to be on my system.
[01:43] <ajmitch> in my pbuilder config I have:
[01:43] <ajmitch> APTCACHE="/home/ajmitch/debian/pbuilder/aptcache-${DISTRIBUTION}/"
[01:43] <ajmitch> APTCACHEHARDLINK="yes"
[01:44] <ajmitch> so it stores them there, you may want to check ~/.pbuilderrc or wherever you have your config file
[01:44] <ajmitch> it's a welcome feature when you're rebuilding a package for the 10th time
[03:47] <EzraR> thats not a bad idea
[03:47] <EzraR> and have cron delete it once a day or week or something
[03:48] <EzraR> so it doesnt get too big
[05:25] <fabrice_sp> fcuk112, there?
[05:26] <fabrice_sp> np: I'll answer in bug #485581
[05:29] <StevenK> The pub, like any good sysadmins
[05:29] <StevenK> Bah, stupid lag
[09:07] <\sh> moins
[09:21] <ashiswin> umm
[09:21] <ashiswin> hello
[09:21] <ashiswin> can someone who has done OS development pleeease pm me
[09:21] <ashiswin> urgently
[09:23] <ashiswin> hello
[09:23] <ashiswin> can someone who has done OS development pleeease pm me
[09:23] <ashiswin> urgently
[09:29] <slytherin> ashiswin: it will be better if you ask specific questions
[09:35] <directhex> slytherin, he wants someone to teach him how to write an os from scratch, iirc. kernel, userland, driver model, etc
[09:36] <directhex> slytherin, given the increased urgency, i smell homework
[09:38] <slytherin> directhex: A homework about writing OS form start?
[09:39] <directhex> oh i dunno. maybe just writing about os design? something like that
[09:40] <LucidFox> o_O
[09:40] <LucidFox> An upstream's reply to a request to add the text of the GPL to the tarball:
[09:41] <LucidFox> "Currently i'm very busy and leaving my home, so i have not the time to republish but you can add this file for your package."
[09:41] <hyperair> win
[09:41] <LucidFox> He promised he'll add it in the next release, though.
[09:42] <hyperair> well that's nice
[09:43] <hyperair> but many upstreams are seem to not care much for specifying the license. like it's a hassle and just an extra thing that's not really necessary
[09:43] <LucidFox> Sadly, yes.
[09:44] <LucidFox> They're more interested in development than legal issues. :)
[10:09] <LucidFox> Hmm.
[10:09] <LucidFox> I've started checking qdvdauthor's copyrights, and I noticed that most of its headers don't contain the standard GPL header, but just "License : GPL v 2.0".
[10:09] <LucidFox> And name of author, etc. Is it allowed?
[10:14] <siretart`> the GPL has recommendations in a section "HOW TO APPLY THE GPL"
[10:14] <siretart`> unfortunately many upstreams (and I mean *many*) prefer to skip that section
[10:15] <siretart`> such packages are allowed in both debian and ubuntu so far, as long there is no other indication that some files or produced binaries are licensed otherwise in an incompatible way
[10:15] <siretart`> does this help?
[10:16] <siretart`> LucidFox: just curious, where are you from? in what timezone do you live?
[10:17] <LucidFox> Russia, UTC+6.
[10:17] <LucidFox> It's 16:17 here.
[10:17] <siretart`> ah, cool
[10:18] <siretart`> I've just added you to the team, I'll answer your mail later, OK?
[10:35] <LucidFox> Hmm, this application is GPLv2+, but uses a bundled library under LGPLv3+. Does it make the overall code GPLv3+?
[10:44] <LucidFox> siretart`> Didn't Fabian already add me? :)
[10:45] <maxb> LucidFox: http://www.fsf.org/licensing/licenses/gpl-faq.html has a compatibility matrix which agrees with you
[10:47] <maxb> LucidFox: oh, actually, I misread it. It seems to imply it's ok to use a LGPL3 library in a GPL2+ project without relicensing the project
[10:48] <maxb> Presumably because the potential to relicense the project is enshrined by the GPL2+ licensing
[11:01] <siretart`> LucidFox: no idea who was faster :-)
[12:31] <LucidFox> Oh, Thunderbird 3 has a "reply list" button now. Nifty.
[12:35] <slytherin> LucidFox: What is purpose of that button?
[12:36] <LucidFox> Replying to the mailing list, as opposed to the sender.
[12:59] <slytherin> LucidFox: Ideally it should be handled by list admins. Many lists set 'Reply-To' to blank.
[13:00] <LucidFox> Ah
[13:00] <hyperair> the lists.ubuntu.com lists usually don't set reply-to
[13:13] <LucidFox> I constantly get "gzip: stdout: Broken pipe" errors with pbuilder-dist, but not on every build attempt.
[13:13] <LucidFox> What's going on?
[13:14] <\sh> LucidFox, disk space eventually?
[13:15] <LucidFox> I have more than enough disk space on every partition.
[13:16] <\sh> hmm
[13:42] <rowinggolfer> I'm hoping someone can clear up some confusion I have with putting an app into my ppa. I push sources which specify the target as intrepid.  I then copy those packages into Hardy, Jaunty, Karmic and Lucid. Is that correct?
[13:43] <rowinggolfer> I wonder if my sources should specify a different target.
[13:47] <tsimpson> rowinggolfer: as long as you choose to only copy the source (and not binaries), that should work
[13:47] <tsimpson> hmm, maybe not actually. LP doesn't work like that..
[13:48] <rowinggolfer> no. if I choose "rebuild packages" it rejects them
[13:48] <rowinggolfer> I can copy the binaries though.
[13:48] <rowinggolfer> and they install ok on all systems.
[13:48] <rowinggolfer> but I don't understand the logic there.
[13:48] <tsimpson> that will only be a good idea for arch all
[13:49] <rowinggolfer> well it's pure python stuff...
[13:49] <tsimpson> the reason LP rejects it is because it would build the packages again, against Hardy/Karmic/whatever
[13:49] <tsimpson> but they'll all have the same version
[13:49] <rowinggolfer> perhaps that's where I am going wrong.... specifying a target at all ?
[13:49] <tsimpson> so the binaries would have the same name
[13:49] <rowinggolfer> tsimpson, ok.. I follow that.
[13:50] <tsimpson> if the package has no binary parts, then you should upload with Architecture: all
[13:50] <rowinggolfer> I have automated the entire process, except this "copy packages bit"
[13:50] <rowinggolfer> tsimpson, let me check the control file. I forget what I have in there.
[13:52] <tsimpson> the way I do it with binary packages it just change the version in the changelog to <version>~<release>1, so for example: 1.0.0-0ubuntu1~myppa~jaunty1 (for jaunty)
[13:52] <tsimpson> then upload that
[13:53] <rowinggolfer> ok. I'll adopt that strategy also.
[13:53] <rowinggolfer> thanks. (BTW - I do have archictecture = all)
[13:54] <rowinggolfer> my changelog is     openmolar (0.1.8-5rgppa) intrepid; urgency=low
[13:55] <rowinggolfer> can I remove the reference to intrepid?
[13:56] <rowinggolfer> and, I have to build the sources 5 times now? (hardy, intrepid, jaunty, karmic, lucid)?
[13:58] <tsimpson> you need to have a series set, but you can upload to any series
[13:59] <tsimpson> and you'll have to build for all the releases, yep
[13:59] <rowinggolfer> tsimpson, thanks for your help.
[14:00] <rowinggolfer> BTW - here's the problem in a nutshell. if you look at https://launchpad.net/~rowinggolfer/+archive/openmolar-testing
[14:00] <tsimpson> https://help.launchpad.net/PPAQuickStart/FAQ#Why%20can%27t%20I%20upload%20the%20same%20version%20for%20multiple%20releases%3F
[14:00] <rowinggolfer> you'll see that the intrepid version is now +0.0.1 ahead of the other series.
[14:01] <rowinggolfer> tsimpson, ah.... that link look useful thanks.
[14:02] <rowinggolfer> ok, I need to go ask that question.
[14:02] <rowinggolfer> tsimpson, you have made my day, many, many thanks for your help.
[14:02] <tsimpson> no problem :)
[14:24] <rowinggolfer> tsimpson, I asked a question - https://answers.launchpad.net/soyuz/+question/91003
[14:25] <tsimpson> if you want, you can poke someone in #launchpad to get on it, or just wait for an admin to do it
[14:26] <rowinggolfer> tsimpson, you think I have a valid query?
[14:26] <rowinggolfer> I don't want to be a pest.
[14:27] <tsimpson> sure
[14:28] <tsimpson> someone should be able to help you
[14:28] <rowinggolfer> ok. but if I get my head bitten off, I will hunt you down for making that suggestion ;)
[14:29] <mok0> what channel should I go to to see rowinggolfer getting his head bitten off?
[14:29] <mok0> :-P
[14:30] <rowinggolfer> #launchpad
[14:30] <tsimpson> they are generally happy to help in there
[14:30] <mok0> Indeed
[14:30] <mok0> Not crazy, like here...
[14:30] <rowinggolfer> they've banned me before :(
[14:30] <rowinggolfer> no wait... that was ubuntu-uk
[14:30] <mok0> rowinggolfer: perhaps it's because of your nick
[14:31] <rowinggolfer> lol, probably
[14:31] <mok0> :)
[14:31] <fcuk112> tell me about it.
[14:31] <mok0> LOL :-D
[14:31] <fcuk112> i got banned from the ubuntu release party channel :P
[14:32] <rowinggolfer> fcuk112, because of the obvious typo in your nick?
[14:32] <mok0> fcuk112: Uhm, what country? Probably they couldn't spell
[14:32] <mok0> ehehe
[14:32] <rowinggolfer> fcuk112, rhymes with chuck_ ??
[14:32] <StevenK> fcuk is also "French Connection, United Kingdom"
[14:32] <fcuk112> i'm Frank Cheung and i'm in the UK :)
[14:33] <rowinggolfer> and you are one hundred and twelve?
[14:34] <fcuk112> nah it's an rnb group i used to like; some websites need more than 4 chars so i had to append something...
[14:34] <mok0> fcuk112: be thankful your not "Frank Updike" from Cook Islands...
[14:34] <mok0> you're, damn it
[14:35] <AnAnt> LucidFox: tl2009 PPA is (hopefully) fixed
[14:36] <LucidFox> AnAnt> Great, let's update and install...
[14:36] <JontheEchidna> Is AutoSync doing new-upstream-in-debian syncs this cycle?
[14:37] <slytherin> JontheEchidna: Sure why not. Only it is from testing instead of unstable as usual.
[14:37] <JontheEchidna> oh, that package I was keeping any eye on did finally get synced
[14:38] <JontheEchidna> But I guess it's not doing automatic removals when it's removed in Debian?
[14:41] <slytherin> JontheEchidna: removals are not automatic. Usually archive admins keep an eye on removals from Debian and do similar in Ubuntu.
[14:42] <LucidFox> Okay. Whether it's the fault of Compiz, the NVIDIA drivers or Wine, it's an unwieldy combination in Karmic.
[14:42] <JontheEchidna> It all looked automatic in the past. I guess it just shows to go how good our archive admins are if they look automatic ;-)
[14:42] <LucidFox> Exiting WoW shouldn't crash X and leave Compiz running and eating 100% CPU time.
[14:43]  * JontheEchidna wonders why qlandkartgt and garmindev have not been synced, as they have been in testing for 2 months.
[14:44] <slytherin> JontheEchidna: do they have any ubuntu changes in previous releases?
[14:44] <mok0> JontheEchidna: you're an OSM'er ?
[14:44] <slytherin> JontheEchidna: did you look up on MoM?
[14:44] <JontheEchidna> slytherin: they're new packages
[14:44] <slytherin> then I have no idea.
[14:45] <JontheEchidna> mok0: Open Street Maps? Nope, just looking out for Qt-related packages ;-)
[14:46] <JontheEchidna> Basically, qlandkarte got removed and was replaced by the qlandkartegt and garmindev packages
[14:47] <JontheEchidna> From the looks nobody ever touched it in Ubuntu, and now qlandkarte is on the removed packages list on multidistrotools. I suppose I'll file a few sync/removal bugs.
[14:48] <JontheEchidna> Just didn't know how LTS was affecting these sort of things
[14:48] <JontheEchidna> But it looks like this is just the odd duckling here
[14:49] <mok0> JontheEchidna: I don't really understand how new packages in Debian are treated either. Allegedly they are auto-imported, but I've often seen that not being the case
[14:50] <mok0> JontheEchidna: I for one would really apprecialte qlandkartegt coming into lucid
[14:55] <StevenK> mok0: Then file a bug!
[14:55] <JontheEchidna> bug 485840 and bug 485842
[14:55] <StevenK> mok0: Rather than complaining that something doesn't get done!
[14:55] <JontheEchidna> too late ;-)
[14:57] <StevenK> JontheEchidna: Sigh
[14:57] <StevenK> JontheEchidna: You do realise that both of those are going to get done in the process of new-source I'm doing today
[14:58] <JontheEchidna> Actually, I did not; which is wahat the conversation we had right before this was about. :x
[14:58] <jldupont> sorry guys, newbie to Debian packaging here:  where is the page where the correct format to `changelog` file ?
[14:58] <JontheEchidna> Sorry for the inconvenience
[14:59] <jldupont> i keep having `debuild` crash on me because of `changelog` formatting errors
[14:59] <StevenK> jldupont: Use 'dch'
[15:00] <jldupont> dch shows me the same error messages... the trouble: I can't figure out what's wrong.
[15:00] <jldupont> looking at http://www.debian.org/doc/maint-guide/ch-dreq.en.html seems to be fine
[15:01] <jldupont> It says: no maintainer in changelog!
[15:01] <jldupont> `-- Jean-Lou Dupont<EMAIL_ADDRESS>Fri, 20 Nov 2009 09:44:00 -0500`
[15:01] <jldupont> what's wrong ??
[15:02] <JontheEchidna> I think there should be two spaces between the email end and the date
[15:02] <JontheEchidna> StevenK: if it will make it up, I can keep an eye on those two packages and close the bugs myself
[15:02] <jldupont> JontheEchidna: change it to no avail
[15:02] <JontheEchidna> hmm... one space before the -- at the beginning?
[15:03] <jldupont> YEAH!
[15:03] <jldupont> thanks Jonthe
[15:03] <JontheEchidna> no prob
[15:03] <jldupont> really picky this dch...
[15:05] <jldupont> what's the `source` field in `control` file?
[15:06] <StevenK> jldupont: It is the source package name
[15:06] <jldupont> but I thought this was the `Package` field...
[15:07] <jldupont> FYI: I am building my own PPA... i.e. not a remix
[15:07] <jldupont> so what should I put in `source` ?
[15:07] <StevenK> No, the Package field is the *binary* package name
[15:07] <StevenK> You have one source package which builds one or more binary packages
[15:08] <jldupont> got it!  Thanks!
[15:09] <rowinggolfer> jldupont, here's a working example http://bazaar.launchpad.net/~rowinggolfer/openmolar/trunk/annotate/head%3A/debian/changelog
[15:09] <jldupont> rowinggolfer: thanks!!
[15:10] <rowinggolfer> np
[15:12] <rowinggolfer> launchpad is smokin' quick to build stuff today :)
[15:16] <jldupont> In Synaptics, let's say I have a package "erlang, installed version --> 1:12.b.5-dfsg-2 ", I do write this dependencies in debian/control ?
[15:17] <jldupont> erlang (>=12.b.5) ?
[15:19] <jldupont> anyone?
[15:20] <\sh> erlang (>=1:12.b.5)
[15:20] <jldupont> thanks
[15:28] <mok0> DktrKranz: Do you have and init.d script to start debomatic?
[15:28] <mok0> s/and/an
[15:31] <EzraR> is it a problem if the upstream source code doesnt have a copyright header in every source file? (for a new package in revu)
[15:36] <DktrKranz> mok0: starting from 0.7, yes
[15:36] <DktrKranz> and in trunk, of course
[15:37] <directhex> EzraR, what percentage, roughly, is missing it?
[15:37] <directhex> EzraR, there's a general gut feeling of "a few missing is no big deal" amongst archive admins afaik
[15:39] <mok0> DktrKranz: ah, ok I just apt-get'ted it in karmic
[15:39] <mok0> apt-got perhaps?
[15:44] <mok0> DktrKranz: I would also suggest that the conffile had a default value, e.g. "/etc/debomatic/debomatic.conf"
[15:47] <DktrKranz> mok0: it should already have
[15:47] <mok0> DktrKranz: OK, great! I'm still looking at the karmic version...
[15:48] <mok0> DktrKranz: maybe we should get the most recent version backported :-)
[15:48] <jldupont> what's the field "Standards-Version" ?
[15:49] <jldupont> in debian/control
[15:49] <mok0> jldupont: the version of the most recent Debian Policy Manual
[15:49] <mok0> 3.8.3
[15:49] <jldupont> cool. thanks.
[15:50] <DktrKranz> mok0: probably, it shouldn't be that hard. I also plan to release new upstream when some more features have landed (commands files, l10n support, and probably some mail notificcations)
[15:51] <DktrKranz> the first two are already available in trunk for testing
[15:51] <mok0> DktrKranz: cool
[15:51] <mok0> DktrKranz: I should probably grab that branch then
[15:52] <DktrKranz> commands files are cute, thus not popular in Ubuntu, but very useful in Debian
[15:52] <mok0> DktrKranz: what do you mean?
[15:52] <jldupont> in debian/rules:  what should put in there : my package has a couple a Erlang files and  a couple of .cc files.  What do I need to do in debian/rules ?
[15:53] <StevenK> And no, the Standards-Version field is showing which version of the Debian policy the package conforms to!
[15:53] <mok0> jldupont: Issue the commands that builds the program... but it's a makefile, remember that
[15:54] <StevenK> It also requires a few targets exist since external tools will call them
[15:55] <jldupont> E: erlang-dbus source: debian-rules-missing-required-target binary
[15:55] <jldupont> E: erlang-dbus source: debian-rules-missing-required-target binary-arch
[15:55] <jldupont> E: erlang-dbus source: debian-rules-missing-required-target binary-indep
[15:55] <jldupont> E: erlang-dbus source: debian-rules-missing-required-target build
[15:55] <jldupont> E: erlang-dbus source: debian-rules-missing-required-target clean
[15:55] <jldupont> those I guess\
[15:55] <mok0> jldupont: Look in the wiki. This question is too basic to answer here.
[15:56] <mok0> jldupont: In other words, we can help, but we can't teach you how to package stuff
[15:57] <jldupont> ok, I'll try to refrain from too basic questions... but then, it is not obvious to define "too basic" ...
[15:58] <EzraR> directhex: http://revu.ubuntuwire.com/report.py/legal?upid=7017
[15:58] <StevenK> It also requires a few targets exist since external tools will call them
[15:58] <DktrKranz> mok0: see ftp://ftp-master.debian.org/pub/UploadQueue/README
[15:58] <mok0> jldupont: You need to read the wiki and take it from there. If you have specific questions, we are happy to help. It's just that "teach me how to package" ... no one will bite
[15:59] <mok0> DktrKranz: thx
[15:59] <mok0> DktrKranz: ah, yes I see what you mean now
[16:01] <DktrKranz> debomatic currently handles "rm" case, it has no mv (useless, since it hasn't delayed queues)
[16:02] <jldupont> just a link to a debian/rules file, pretty please?  This one (http://bazaar.launchpad.net/~rowinggolfer/openmolar/trunk/annotate/head:/debian/rules) calls for a dependency that I am not sure I want.
[16:03] <mok0> jldupont: you mean python etc.?
[16:03] <mok0> jldupont: try deleting it
[16:04] <jldupont> include /usr/share/cdbs/1/rules/debhelper.mk
[16:04] <jldupont> deleting it... no more makefile... there is nothing in there
[16:04] <mok0> jldupont: that you almost certainly need
[16:04] <StevenK> debhelper 7 would be nicer
[16:05] <mok0> jldupont: ^^^ see StevenK's comment
[16:05] <mok0> StevenK: (even though I don't agree) :-)
[16:05] <jldupont> hmmm. let me man debhelper 7
[16:06] <jldupont> ... then what's "cdbs" for?
[16:06] <mok0> jldupont: it's just another system to do the same... cdbs is a set of GNU make macros
[16:07] <mok0> jldupont: it's man dh
[16:07] <StevenK> mok0: You prefer debugging cdbs?
[16:07] <mok0> StevenK: yes
[16:07] <mok0> StevenK: anything but evil perl
[16:07] <StevenK> mok0: Everytime I've had to do that, I've had to read the cdbs source code, which is horrid
[16:08] <jldupont> man dh ... Diffie-Hellman ... I don't think so.
[16:08] <mok0> StevenK: Hm, yeah, well I know it pretty well by now
[16:08] <mok0> jldupont: huh?
[16:09] <StevenK> jldupont: Do you have the 'debhelper' package installed?
[16:09] <jldupont> got it now.... a google search "man dh" isn't helpful... lesson learned
[16:10] <mok0> jldupont: In the Examples section is a 3-line makefile template that you can use as debian/rules
[16:11] <jldupont> mok0: thanks!
[16:11] <mok0> jldupont: don't forget the tab character in the makefile if you cut'n'paste
[16:12] <mok0> jldupont: probably your old cdbs rules file failed because you didn't have debhelper installed
[16:14] <jldupont> ?old cdbs?  First time around with debhelper... so no "old" stuff ;-)
[16:14] <jldupont> dh_clean: Compatibility levels before 5 are deprecated.
[16:15] <StevenK> echo 7 > debian/compat
[16:15] <jldupont> what do I do with "W: erlang-dbus source: debhelper-but-no-misc-depends erlang-dbus"
[16:16] <StevenK> jldupont: lintian -v is your friend
[16:16] <jldupont> ok... let me do "lintian"
[16:18] <mok0> StevenK: If you have a package in an bzr branch on LP, is there a way to submit a command: "build this package" (without having to upload)? I know the answer is probably "no" so this is more a retorical question I guess :-)
[16:21] <StevenK> mok0: Not at this point, no
[16:22] <mok0> StevenK: ... but it's a good idea, don't you think?
[16:22] <geser> mok0: not yet, but the LP devs are working on it (BuildFromBranch should be the correct keyword there)
[16:22] <mok0> geser: cool
[16:27] <jldupont> I added "${misc-Depends}: debhelper (>= 7)" to debian/control and debuild still complains with "W: erlang-dbus source: debhelper-but-no-misc-depends erlang-dbus"
[16:27] <jldupont> I am not getting "http://lintian.debian.org/tags/debhelper-but-no-misc-depends.html"
[16:28] <StevenK> Then read what lintain -v says, like I said before
[16:30] <geser> mok0: see https://dev.launchpad.net/BuildBranchToArchive for the spec
[16:31] <mok0> jldupont: hint: the ${...} is expanded
[16:31] <mok0> geser: thx
[16:31]  * mok0 looks
[16:31] <randomaction> jldupont: use "Depends: <your dependencies>, ${misc:Depends}"
[16:32] <jldupont> mok0: my bad... thanks again again!
[16:32] <EzraR> if in a package I had a config file in the debian dir that gets installed with a .install what would be the proper way to set the perms to 600
[16:32] <randomaction> and it's lintian -i, not -v
[16:33] <EzraR> seems that dh_fixperms is only able to exclude files
[16:34] <mok0> EzraR: you need to make sure the file has perms 600 before it's packed into the deb
[16:34] <jldupont> randomaction: thanks!
[16:34] <EzraR> mok0: and then have dh_fixperms exclude it?
[16:35] <mok0> EzraR: I don't think dh_fixperms will hurt it
[16:36] <mok0> EzraR: it will only fix obvious perm errors
[16:36] <mok0> EzraR: like +x on regular files etc
[16:36] <EzraR> mok0: ok, thnx
[16:38] <jldupont> success !!! THANKS TO ALL!
[16:39] <mok0> jldupont: :)
[16:40] <StevenK> randomaction: Oh, blah!
[16:41] <hyperair> dtchen: are pulseaudio's sinks/sources guaranteed to be numbered the same way after a suspend/resume cycle?
[16:43] <hyperair> dtchen: and regarding the changes you've made in lp #404986, are you sure it didn't reopen the bug the 01Pulseaudio pm-utils sleep.d hook script was originally supposed to fix?
[16:43] <jldupont> after dput, I get "Not running dinstall" ... what does this mean?
[16:44] <StevenK> jldupont: It can be ignored
[16:44] <jldupont> ok
[16:51] <jldupont> I got an error report from Launchpad "Unable to find distroseries: stable" what do I do?
[16:52] <StevenK> Change your changelog so it doesn't say stable, but the distro you want to build it for
[16:52] <mok0> jldupont: in debian/changelog, choose an Ubuntu distro (e.g. karmic)
[16:52] <jldupont> e.g. erlang-dbus (0.3) jaunty; urgency=low
[16:52] <jldupont> is this correct?
[16:53] <StevenK> jldupont: Looks good
[16:53] <mok0> jldupont: looks that way, there must be 2 spaces before "jaunty"
[16:54] <mok0> I guess Debian originally used FORTRAN to parse changelog
[16:54] <jldupont> cool!  now, I just have to wait 2minutes for launchpad...
[16:55] <StevenK> mok0: Oh, hardy har har
[16:56] <mok0> StevenK: you caught it, good :-)
[16:58] <geser> FYI: the UDS session about the "future" of MOTU starts soon
[16:59] <mok0> geser: is someone typing it up on IRC?
[16:59] <randomaction> #ubuntu-uds-waverly has a link to audio
[16:59] <geser> there is a channel for this room
[16:59] <geser> exactly that one
[16:59] <mok0> Thanks
[17:00] <mok0> Will rejoin in a little while
[17:00] <ScottK> Future of MOTU UDS session in #ubuntu-uds-waverly
[17:00] <ScottK> Starting now.
[17:01] <jldupont> Accepted by launchpad!  thanks to all!
[17:15] <jldupont> on LaunchPad, next to my package I see "Pending (2505)"  is the 2505 the number of packages waiting in the queue or some status code?
[17:15] <StevenK> jldupont: It is a score
[17:17] <jldupont> a score? related to how my package is formatted/complex to process?
[17:17] <jldupont> can I have an ETA somewhere?  Or I just have to wait??
[17:23] <randomaction> jldupont: https://launchpad.net/builders
[17:26] <jldupont> randomaction: cool!  thanks!
[18:27] <slytherin> What is the usual convention for SRU versions? The SRU page on wiki is not very clear about it.
[18:31] <fabrice_sp> slytherin, did you had a look at the security one?
[18:32] <fabrice_sp> https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging
[18:32] <slytherin> fabrice_sp: Yes I did but I thought it applied to only security updates. Also some packages have this weird ubuntux.9.04.y versioning.
[18:33] <fabrice_sp> slytherin, I've been using it for SRU also.  This versioning is not only for backporting?
[18:34] <slytherin> ok I will use ubuntux.y
[18:35]  * slytherin wonders why the heck PPA do not accept -proposed packages.
[18:35] <jldupont> my package in my PPA is taking forever to build... is there a way to "emulate" the build process locally so I'll know (maybe) what to expect?
[18:35] <fabrice_sp> !pbuilder | jldupont
[18:36] <fabrice_sp> also
[18:36] <fabrice_sp> !sbuild | jldupont
[18:36] <jldupont> cool! thanks!
[18:36] <fabrice_sp> pbuilder is easier to set up
[18:36] <fabrice_sp> yw :-)
[18:37] <slytherin> pbuilder is easier to setup but sbuild is closest to the build servers environment.
[18:37]  * fabrice_sp is using sbuild :-)
[18:38]  * slytherin wants to learn sbuild
[18:38]  * StevenK uses sbuild too
[18:38] <fabrice_sp> you only need to setup a LVM :-)
[18:38] <cyphermox> fabrice_sp, is the LVM requirement the only difference with pbuilder?
[18:40] <slytherin> cyphermox: from what I have heard sbuild is fast.
[18:40] <fabrice_sp> cyphermox, they are both using a kind of 'clean' chroot. The difference is that sbuild clone a partition, when pbuilder uses a chroot
[18:40] <fabrice_sp> sbuild is fast if you use a cache tool :-)
[18:41] <fabrice_sp> you have to setup one with sbuild, but it comes automatically with pbuilder
[18:41] <fabrice_sp> (I'm using apt-cacher-ng for that)
[18:41] <cyphermox> fabrice_sp, what I mean is that when someone says "closest to the buildds", it means that it has to do with the fact that it's cloning partitions, not that there is an actual difference in resulting package, no?
[18:42] <fabrice_sp> cyphermox, I only saw one or two packages that didn't built in sbuild but built in pbuilder, so for the general use, it's good enough :-)
[18:44] <slytherin> cyphermox: not in resulting package but in build process.
[18:45] <slytherin> cyphermox: for example if you specify alternate build-deps (a | b), sbuild always uses first whereas pbuilder will use the one that is available.
[18:45] <slytherin> I had trouble with packages that built fine in pbuilder and then failed to build on server because of such issues.
[18:45] <cyphermox> ah, that's kind of an interesting difference, yes
[18:46] <fabrice_sp> interesting
[18:46]  * slytherin has to leave for some time.
[18:47] <jldupont> ok, i've do sudo pbuilder create... what next?
[18:47] <fabrice_sp> sudo pbuilder build <package.dsc>
[18:48] <jldupont> "W: /home/jldupont/.pbuilderrc does not exist"
[18:48] <StevenK> sbuild -A -d <release> <package.dsc> :-P
[18:49] <av`> fabrice_sp, when you upload something please make sure to forward any patch to Debian please
[18:49] <av`> fabrice_sp, I saw your sponsorship upload of agg
[18:49] <cyphermox> StevenK, pbuilder-dist <release> <package.dsc> ;)
[18:49] <fabrice_sp> as we will 'kill' lpia, is it worth merging a package by adding just lpia support?
[18:49] <av`> fabrice_sp, and I've just uploaded a revision that removes any delta, so we can sync now ;)
[18:49] <av`> fabrice_sp, no
[18:49] <fabrice_sp> av`, I thought Arthur was in touch with you about that
[18:49] <av`> fabrice_sp, sync it
[18:50] <fabrice_sp> ok
[18:50] <cyphermox> gah, i err
[18:50] <av`> fabrice_sp, he said something to me about that, but I forgot to upload a fixed package to Debian
[18:50] <fabrice_sp> av`, do you want me to open the sync request for agg?
[18:50] <av`> fabrice_sp, that's why opening a bug into the Debian's BTS is usually nice
[18:51] <fabrice_sp> yeah: that's what I usually tell to people opening merge request
[18:51] <fabrice_sp> I just made an exception in that case (tht I shouldn't have done, obviouslly)
[18:51] <av`> fabrice_sp, it has been uploaded like 3 minutes ago, so let's wait it gets built
[18:51] <av`> fabrice_sp, then you can open the request
[18:51] <av`> fabrice_sp, thanks for taking care about it though :)
[18:51] <fabrice_sp> I'll wait until it lands in testing then
[18:52] <av`> perfect, thanks!
[18:53] <fabrice_sp> yw :-)
[18:55] <fcuk112> is there a guide for how to use sbuild?
[18:56] <jldupont> help!  "Current status: 0 broken [-1].
[18:56] <jldupont> Aptitude couldn't satisfy the build dependencies
[18:56] <jldupont> E: pbuilder-satisfydepends failed.
[18:56] <jldupont> "
[18:59] <jldupont> what do I do about "Remove the following packages:
[18:59] <jldupont> pbuilder-satisfydepends-dummy"
[19:01] <cyphermox> jldupont, what command were you running that wrote these messages?
[19:01] <jldupont> "sudo pbuilder build erlang-dbus_0.3.dsc"
[19:02] <cyphermox> jldupont, could you paste the full output in a pastebin (paste.ubuntu.com) and provide the url?
[19:03] <jldupont> http://pastebin.com/m614b270f
[19:07] <jldupont> cyphermox: could it be because I have messed up the erlang dependency?
[19:08] <cyphermox> jldupont, yes, trying to figure out what in it is wrong.
[19:09] <jldupont> I've looked what I have installed on my mahcine: Synaptic says "1:12.b.5-dfsg-2"
[19:09] <cyphermox> jldupont, could it be that you need erlang-dev or erlang-base rather than just erlang?
[19:10] <EzraR> jldupont: pbuilder is not the same as your mahcine
[19:10] <jldupont> I'll try adding -dev and -base and see... pbuilder complains about "erlang" just being a virtual package... could that be it?
[19:11] <cyphermox> it's your clue that something is wrong in that build-dep
[19:12] <jldupont> "The following packages have unmet dependencies:
[19:12] <jldupont>   pbuilder-satisfydepends-dummy: Depends: erlang-dev (>= 1:12.b.5) which is a virtual package.
[19:12] <jldupont>                                  Depends: erlang-base (>= 1:12.b.5) which is a virtual package.
[19:12] <jldupont> The following actions will resolve these dependencies:
[19:12] <jldupont> Remove the following packages:
[19:12] <jldupont> pbuilder-satisfydepends-dummy
[19:12] <jldupont> "
[19:12] <jldupont> ?????
[19:13] <EzraR> jldupont: if you have a hard time with depends this script might help tell you what the app uses
[19:13] <EzraR> http://pastebin.com/m3896bcb
[19:13] <cyphermox> jldupont, 12.b.5, that's Jaunty
[19:13] <cyphermox> no?
[19:14] <jldupont> I am on jaunty.
[19:14] <cyphermox> ok, and you're building the package for Jaunty too?
[19:14] <jldupont> yes
[19:14] <cyphermox> jldupont, I think the issue is that pbuilder is not going to get the packages from universe, only main
[19:15] <jldupont> cyphermox: makes sense... how do I correct this?
[19:15] <cyphermox> hold on a second
[19:15] <cyphermox> jldupont, see here: https://wiki.ubuntu.com/PbuilderHowto#Universe%20support
[19:16] <cyphermox> jldupont, the PbuilderHowto page gives you a lot of other useful tricks, too
[19:16] <cyphermox> back in a minute...
[19:21] <fcuk112> in a patch file, what does an entry like @@ -227,7 +233,7 @@ mean?  i know it's supposed to start at line 227.
[19:22] <fcuk112> another one looks like this @@ -190,14 +190,20 @@ - i am not sure why sometimes the x in x,y stays the same and sometimes not.
[19:23] <fcuk112> this is quilt btw.
[19:24] <jdong> fcuk112: probably easier to consult the documentation on the unified diff format :)
[19:24] <jdong> http://en.wikipedia.org/wiki/Diff#Unified_format looks decent
[19:25] <cyphermox> jldupont, any luck?
[19:27] <jldupont> cyphermox: yes I am much further along THANKS.  The problem is "universe" was missing for Erlang.
[19:28] <cyphermox> jldupont, awesome. have fun packaging :)
[19:28] <fcuk112> jdong, thanks.
[19:28] <jldupont> I still have a couple of kinks to work out though ;-)
[19:34] <jldupont> cyphermox: let's say my package depends on some other package in my PPA for building, how do I specify this?
[19:34] <jldupont> ... and how do I make sure that Launchpad picks this up?
[19:35] <cyphermox> if you upload your new package to the same PPA, it just works.
[19:35] <jldupont> so Launchpad includes by default my PPA packages when building?
[19:35] <cyphermox> IIRC, yes
[19:36] <jldupont> IIRC ?
[19:36] <cyphermox> if i recall correctly
[19:36] <jldupont> ok
[19:36] <jldupont> what about when I use pbuilder?  option in .pbuildrrc I guesS?
[19:38] <cyphermox> jldupont, yes. You should take a look at the pbuilder manual (http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html) , but essentially, it's the  --othermirror switch,
[19:38] <jldupont> cool
[20:05] <maxb> This does, of course, require that your dependency packages are in an actual indexed apt repository
[20:06] <maxb> lp:~maxb/+junk/apt-generate has the script I use to achieve this
[20:32] <mrooney> hey, I'm using equivs-build to make a metapackage, but I'm not sure how use this with dput. any tips on how to create the .changes  / upload it?
[20:35] <jldupont> in debian/rules,  for the "install" target, should I be using something like $PREFIX as install prefix?
[20:37] <jldupont> cyphermox ?
[20:40] <nixjunki3> When you are packaging an application what do you do if you are unsure of the copyright dates
[20:43] <cyphermox> jldupont, yeah, put my name in front of the line if you want me to see your messages :)
[20:44] <jldupont> when pbuilder builds stuff,
[20:44] <jldupont> what is the environment variable does it use to tell where to install stuff?
[20:45] <jldupont> in http://www.debian.org/doc/maint-guide/ch-dreq.en.html, I see "$(MAKE) DESTDIR=$(CURDIR)/debian/testpack install" but I am not quite sure what to make of it...
[20:46] <cyphermox> jldupont, it's exactly that
[20:46] <cyphermox> DESTDIR specifies to make install where to drop the files
[20:46] <cyphermox> (where the tree starts, instead of / )
[20:47] <jldupont> so I need to use $(CURDIR) or else everything is going to fall apart with pbuilder / launchpad?
[20:47] <cyphermox> jldupont, $(CURDIR) is a variable that will resolve to your current directory where the build is going on (the base of the source tree)
[20:48] <jldupont> but when I finally have apt-get install my package, I want files to be dropped in /usr
[20:49] <jldupont> I am confused... please help!
[20:49] <cyphermox> jldupont, DESTDIR=$(CURDIR)/debian/<your binary package> should do what you want -- create a tree under <your source base directory>/debian/<name of your binary package>
[20:49] <cyphermox> jldupont, make install doesn't do that by itself?
[20:50] <jldupont> when I use pbuilder, it invokes my makefile... and my "install" target tries to copy stuff in /usr ... and pbuilder barks.
[20:51] <jldupont> cp: cannot create regular file `/usr/bin/epapi_loop_drv_debug': Permission denied
[20:51] <cyphermox> ok
[20:51] <cyphermox> jldupont, and in the end, you want `/usr/bin/epapi_loop_drv_debug' to be the file installed by your package?
[20:51] <jldupont> yes
[20:51] <cyphermox> ok
[20:52] <fcuk112> trying to fix a patch which fails at hunk #77 in pbuilder - how do i find out what hunk #77 is?  it's quite a big patch with lots of translations: http://www.pastie.org/708127
[20:52] <jldupont> I guess I am thinking one step ahead here...
[20:52] <cyphermox> jldupon, then yes, $(MAKE) DESTDIR=$(CURDIR)/debian/<name of your binary package> will do this
[20:52] <jldupont> pbuilder is building a package... right?
[20:52] <jldupont> got it!
[20:53] <jldupont> so my debian/rules file can't be just "#!/usr/bin/make -f
[20:53] <jldupont> %:
[20:53] <jldupont> 	dh $@"
[20:53] <jldupont> right?
[20:53] <cyphermox> jldupont, yes, it is. Roughly, pbuild installs the files in a tree starting at whatever you set DESTDIR to, and the package will install all the files under that tree, but starting at / on the destination system.
[20:54] <cyphermox> jldupont, if you software can be installed by just doing ./configure, make, and make install with no special things, it probably will work
[20:55] <jldupont> it is just a simple port driver library for Erlang, nothing too fancy.
[20:56] <jldupont> why does pbuilder barks at "cp: cannot create regular file `/usr/bin/epapi_loop_drv_debug': Permission denied"
[20:56] <cyphermox> there may be something not quite kosher in make install
[20:56] <fabrice_sp> jldupont, because you can't install file in / in a pbuilder
[20:57] <cyphermox> jldupont, make install usually installs files under /usr/local, I think the trick you put above depends on that case.
[20:57] <fabrice_sp> you have to set whatever is the variable expected by the makefile
[20:57] <fabrice_sp> to $CURDIR
[20:57] <cyphermox> fabrice_sp, thanks
[20:58] <fabrice_sp> cyphermox, generaly, something like that i enough: $(MAKE) install DESTDIR=$(CURDIR)/debian/<packagename>
[20:58] <jldupont> have a look at http://pastebin.com/d23f1e9ec
[20:59] <cyphermox> fabrice_sp, yeah :)
[20:59] <jldupont> I guess I need to fit in $(CURDIR) in there or install stuff in /usr/local
[20:59] <fabrice_sp> cp in a rules file?!
[20:59] <jldupont> no no
[20:59] <jldupont> my debian/rules is:
[20:59] <fabrice_sp> ohhh
[20:59] <fabrice_sp> sorry :-)
[20:59] <jldupont> #!/usr/bin/make -f
[20:59] <jldupont> %:
[20:59] <jldupont> 	dh $@
[21:00] <cyphermox> ahh I see
[21:00] <fabrice_sp> Makefile is clearly buggy
[21:00] <jldupont> fire when ready ;-)
[21:00] <fabrice_sp> in one package similar to this one, I had to manually install files instead of using upstream's Makefile
[21:00] <cyphermox> jldupont, you really should let the user decide where to put the files when installed, and/or install by default to /usr/local
[21:01] <jldupont> how do I do that?
[21:01] <fabrice_sp> DESTDIR is a standard variable in Makefile
[21:01] <fabrice_sp> you can set it by default to /usr/local
[21:02] <jldupont> so, instead of "cp lib/whateverfile /usr/lib/whateverfile"
[21:02] <fabrice_sp> ohhh: jldupont  you're upstream?
[21:02] <fabrice_sp> sorry about the buggy part :-)
[21:02] <jldupont> what does "upstream" mean?
[21:02] <fabrice_sp> "Author of the software"
[21:02] <jldupont> fabrice_sp: it's quite ok, np :-)
[21:03] <jldupont> Yes I am "upstream" then... it's my stuff
[21:03] <fabrice_sp> :-D
[21:04] <jldupont> how do I correct my makefile for the install target??
[21:04] <jldupont> still, same pastebin: http://pastebin.com/d23f1e9ec
[21:04] <fabrice_sp> so instead of "cp lib/whateverfile /usr/lib/whateverfile", put "cp lib/whateverfile $(DESTDIR)/whateverfile"
[21:04] <fabrice_sp> and define DESTDIR to /usr/local if not defined
[21:05] <fcuk112> trying to fix a patch which fails at hunk #77 in pbuilder - how do i find out what hunk #77 is?  it's quite a big patch with lots of translations: http://www.pastie.org/708127
[21:05] <jldupont> oh I see.
[21:05] <jldupont> let me whip something.
[21:05] <fabrice_sp> fcuk112, you should have a .rej file with the rejected hunk
[21:05] <jldupont> you guys are on SO, right?
[21:06] <fabrice_sp> SO?
[21:06] <jldupont> http://stackoverflow.com/
[21:06] <fabrice_sp> nop
[21:06] <cyphermox> nope...
[21:06] <jldupont> ... well, you could help I am sure.
[21:07] <fcuk112> fabrice_sp: where should i find this .rej file?
[21:07] <fcuk112> fabrice_sp: i have a pbuilder hook and i can't see it.
[21:08] <fabrice_sp> fcuk112, in the same place where the file to patch is, IIRC
[21:08] <fcuk112> fabrice_sp: find . -name *.rej doesn't return anything.
[21:09] <fabrice_sp> fcuk112, try to apply the patch manually in your source directory
[21:10] <fabrice_sp> fcuk112, it's CDBS?
[21:10] <fcuk112> quilt
[21:10] <fcuk112> fabrice_sp: i tried quilt push xxx.path --trace
[21:10] <fcuk112> fabrice_sp: but i still cannot see any .rej file - it did fail again on hunk 77 though.
[21:10] <fabrice_sp> or quilt push -a
[21:11] <jldupont> fabrice_cp: so, something like: http://pastebin.com/d7418fa54
[21:11] <jgoppert> i'm packaging a file that doesn't use autotools, the install doesn't install any headers because the guy is using find on src/ basically so how do i get debuild to recognize that
[21:11] <jgoppert> is there a defined variable for the original source directory?
[21:11] <fabrice_sp> jldupont, yes: sounds better :-D
[21:11] <fcuk112> fabrice_sp: quilt push -a, same result.
[21:12] <fabrice_sp> jgoppert, CURDIR represent the root directory of the sourc epacakge
[21:12] <jgoppert> thanks
[21:12] <fabrice_sp> fcuk112,  :-/
[21:13] <fabrice_sp> fcuk112, quilt push -f force the patch to be applied and generate the .rej file
[21:14] <fcuk112> fabrice_sp: ah, thanks - that did it.  dinner time, will be back later.
[21:14] <fabrice_sp> bye ;-)
[21:17] <cyphermox> jldupont, does pbuilder like your Makefile better with that change in ? :)
[21:17] <jldupont> cyphermox: still an issue... http://pastebin.com/d298c2001
[21:17] <jldupont> > copying driver files in /tmp/buildd/epapi-0.7/debian/epapi/bin
[21:17] <jldupont> cp: cannot create regular file `/tmp/buildd/epapi-0.7/debian/epapi/bin/epapi_loop_drv_debug': No such file or directory
[21:18] <fabrice_sp> jldupont, what is the name of your package?
[21:18] <jldupont> epapi
[21:19] <cyphermox> jldupont, ohh. DESTDIR is empty... but you're missing the directories under /tmp/buildd/epapi-0.7/debian/epapi
[21:19] <jldupont> hmmm.... I need to mkdir those myself????
[21:20] <cyphermox> yeah, since they might not exist (for example, under /usr/local/ on a newly installed system
[21:20] <cyphermox> but wait a bit
[21:20] <jldupont> I feel SSSSOOOO stupid!
[21:20] <cyphermox> in your Makefile, you used CURDIR rather than DESTDIR, although you just defined DESTDIR at the top
[21:21] <jldupont> I just have to "mkdir -p" I guess, right?
[21:21] <cyphermox> jldupont, it's not stupid, there's lots to think about all at the same time :)
[21:21] <jldupont> cyphermox: thanks !
[21:22] <cyphermox> jldupont, install might be better than mkdir though.. and better than cp for the files.
[21:22] <jldupont> oh yes.. thanks.
[21:23] <jldupont> so, install -T or ?
[21:23] <cyphermox> jldupont, hold on
[21:25] <cyphermox> jldupont, -D might be better suited, if you don't want to do mkdirs or install -d for the directories first
[21:25] <jldupont> will try.
[21:26] <jldupont> shazam!!! it works!!
[21:27] <jldupont> one little complaint: dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
[21:29] <jldupont> whre does "${misc:Depends}" go again?
[21:29] <jldupont> in the "Package" section of /control ??
[21:30] <cyphermox> yes
[21:30] <cyphermox> under Depends:
[21:30] <jldupont> cool
[21:31] <jldupont> where can I inspect what pbuilder built?
[21:32] <cyphermox> jldupont, look under /var/cache/pbuilder/result
[21:32] <jldupont> cyphermox: I still get "dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}"
[21:33] <jldupont> cool: /var/cache/pbuilder/result
[21:33] <cyphermox> do you have a Build-Depends on debhelper?
[21:33] <jldupont> Build-Depends: erlang-dev (>= 1:12.b.5), debhelper (>= 7)
[21:36] <jldupont> cyphermox: any clue?
[21:37] <cyphermox> jldupont, not sure
[21:37] <jldupont> my complete debian/control: http://pastebin.com/d5234fc66
[21:40] <jldupont> ah... maybe because I put the "Section: devel" line in...
[21:40] <cyphermox> maybe it's just that debhelper has nothing to put in there
[21:41] <jldupont> could it be: ${devel:Depends} ??
[21:42] <jldupont> ... or I am suggesting something stupid ??
[21:42] <cyphermox> nah, but I don't think there is such a thing as devel:Depends ;)
[21:43] <jldupont> ... so it might just be that pbuilder resolves ${misc: Depends} to "empty string" and issues a warning, that's all.
[21:44] <cyphermox> jldupont, I don't know, surely someone else in here could tell you, but I think my skills aren't at that level yet ;)
[21:44] <jldupont> I'll shoot it to Launchpad and see what it has to say... I'll get the result in ~4hours though... ;-(
[21:46] <cyphermox> ah, i see
[21:46] <jldupont> cyphermox: what?
[21:46] <cyphermox> jldupont, this is surely debianbug #498666
[21:48] <cyphermox> if you have your packaging and code up somewhere, maybe I could give it a shot here to see
[21:49] <jldupont> http://epapi.googlecode.com/  in /trunk
[21:49] <cyphermox> didn't you say you were uploading it to your PPA?
[21:49] <jldupont> yes I am uploading to PPA... I am moving stuff to LaunchPad...
[21:50] <cyphermox> ok
[21:50] <jldupont> but I have a "legacy" on GC...
[21:53] <cyphermox> jldupont, it's dinner time over here, so i'll be out for a while, but this is interesting, i'll contact you again later :)
[21:53] <jldupont> cyphermox: cool ... thanks a million!
[21:53] <jldupont> I have to go get my little "monkeys" at school myself..
[21:54] <cyphermox> jldupont, np. sorry if I can't always give you very clear answers, i'm still learning too :)
[21:54] <jldupont> cyphermox: you rock man!
[21:54] <jgoppert> hey i'm not getting anything header files in my deb but they are installing to debian/tmp and  i uncommented dh_install, says missing files /usr/include/*  ???
[22:01] <jgoppert> it works if i proceed it with debian/tmp  what is going on?
[22:01] <jgoppert> ls
[22:01] <jgoppert> oops, sorry
[22:03] <jgoppert> well i guess this works for now :-/ i hate packages that don't use automake lol
[22:19] <foxmike_> 3quit
[22:19] <foxmike_> #quit
[22:42] <ari-tczew> any sponsor is working on main?
[22:43] <lucas> james_w's distributed development stuff is so cool that I'm going to do merges again, I think ;)
[23:20] <av`> ari-tczew, ??
[23:36] <jgoppert> does launchpad not let you put up hardy packages? i already have some jaunty up, do i need to increment the changes file?
[23:37] <av`> jgoppert, sorry?
[23:37] <av`> jgoppert, you mean you are unable to upload?
[23:37] <av`> e.g LP rejects
[23:37] <jgoppert> it uploads fine, just doesn't show up
[23:37] <av`> jgoppert, your LP ID
[23:37] <jgoppert> jgoppert
[23:38] <av`> jgoppert, and package name?
[23:38] <jgoppert> boost-numeric-bindings, hardy version hsl1
[23:38] <jgoppert> boost-numeric-bindings-20081116-hsl1 hardy
[23:40] <jgoppert> i have a a boost-numeric-bindings-20081116-hsl1 under karmic, does it not like that? i'm rolling our servers back to hardy and trying to package for them
[23:40] <av`> jgoppert, https://edge.launchpad.net/~jgoppert/+archive/hsl/+build/1320991
[23:40] <av`> jgoppert, you uploaded it for karmic
[23:40] <av`> jgoppert, or better you didnt increment the revision
[23:47] <jgoppert> how do you specify that its for hardy ?
[23:48] <av`> jgoppert, debian/changelog
[23:48] <av`> jgoppert, targer release is set to karmic now, set it to hardy :)
[23:49] <jgoppert> boost-numeric-bindings (20081116-hsl1) hardy; urgency=low
[23:49] <av`> jgoppert, be sure you check all the build-depends, any dependency to be sure you can build / use it onr karmic as well
[23:49] <jgoppert> not the one i just uploaded
[23:49] <av`> jgoppert, use another version now since you uploaded ~hsl1 already
[23:49] <jgoppert> luckily this is just a set of header files so i'm good
[23:49] <av`> like ~hsl2
[23:49] <av`> or whatever
[23:49] <jgoppert> ok thanks
[23:50] <jgoppert> so hardy and karmic cant have their own set of revision numbers?
[23:51] <av`> jgoppert, actually yes, since they are two different releases
[23:51] <jgoppert> ok well how do i tell dput to go to hardy ?
[23:51] <jgoppert> dput http://ppa /~jgoppert/hsl/hardy ??
[23:51] <av`> jgoppert, but usually the newer release should have an higher version of a package
[23:51] <av`> jgoppert, no
[23:52] <av`> jgoppert, you've specified it into the changelog already
[23:52] <av`> jgoppert, dput ppa:whatever foo.changes
[23:52] <jgoppert> yeah ok, so i guess launchpad jsut doesn't like that i'm trying to put hsl1 back up even though its under hardy and not jaunty
[23:52] <av`> dput doesnt decide where to put a package (or well it does for delayed stuff on Debian)
[23:53] <av`> jgoppert, yes, try another versioning
[23:53] <jgoppert> thanks
[23:53] <jgoppert> i'll go to hsl6 i guess
[23:53] <av`> np
[23:53] <av`> well, it's not the best idea to bump it from hsl1 to hsl6
[23:53] <av`> but your choice :)
[23:54] <jgoppert> well i've got hsl1-5 on karmic, would probably just die again if i went with hsl2
[23:54] <av`> ah ok :)
[23:55] <av`> select your revisions properly to avoid this issues next time
[23:55] <av`> :)
[23:58] <jgoppert> wait.. lol i think i just forgot to add my new opengpg key on launchpad ... doh
[23:58] <av`> xD
[23:58] <jgoppert> think it would have told met that upload failed though