[00:18] <Quintasan> I'm going to bed. Good night Ladies and Gentleman
[01:00] <ChogyDan> I'm trying to put a kernel into a ppa, and I'm getting ABI errors.  Do I have to pack the ABI files in with the source?  I know when building it locally, I could d/l the ABI files...
[01:12] <jmarsden> ChogyDan: Buildd's have no Internet access during the build process.  By design.
[01:13] <ChogyDan> fair enough, but I don't know what to do regardless
[01:15] <jmarsden> ChogyDan: Look at how the official Ubuntu kernel packages do things, and do it that way.  I guarantee they do not go out and grab stuff from the Internet during package building.  So your kernel paclages should not need to do that either.
[01:16] <wgrant> ChogyDan: IIRC there's a script that you run to grab the latest ABI files and put them in the source.
[01:17] <wgrant> Or you enable PPA mode, which disables the ABI check and uses something different.
[01:17] <wgrant> Although that might not exist any more; I haven't done it for 18 months.
[01:17] <ChogyDan> wgrant: how do I enable ppa mode?  ok.  Well, I will try packing in the ABI files, see if that works
[02:13] <doctormo> Hey everyone, I'm getting an error when I tried to include a postinst script into my package.
[02:13] <doctormo>  dpkg (subprocess): unable to execute installed post-installation script: Exec format error
[02:14] <doctormo> I thought the postinst was just a bash script, am I wrong?
[02:17] <wgrant> doctormo: The postinst has to be an executable of some kind. Are you missing a #!/bin/sh?
[02:23] <doctormo> I was
[03:36] <ScottL_> anyone care to give some pointers for using debhelper 7 style format?
[07:53] <zooko> ScottK: the last feature of Tahoe-LAFS is in trunk now. And it kicks ass! http://allmydata.org/pipermail/tahoe-dev/2010-January/003723.html
[07:53] <zooko> But I must sleep...
[07:53] <zooko> I'll be back on IRC tomorrow!
[10:19] <kklimonda> can I merge packaging branch with a full branch somehow?
[10:42] <kklimonda> anyone familiar with "distributed development" online? I have few questions
[10:43] <geser> sort of familiar, I've done some successful merges with it
[10:43] <kklimonda> geser, are there plans to drop debian/patches/ in favour of branches?
[10:44] <geser> that I don't know
[10:44] <randomaction> I think these are *very* remove plans
[10:45] <kklimonda> geser, is there an easy way of working with both "full" branches and and branches that contain only debian/ directory or do I have to diff them by hand?
[10:45] <kklimonda> also can I get branches for all packages uploaded to -proposed and -security?
[10:45] <geser> I've only used the packaging branches from LP till now
[10:46] <kklimonda> (I've tried lp:ubuntu/<package>/karmic-security and lp:ubuntu/karmic-security/[package] and neither works)
[10:46] <geser> the second one should work
[10:46] <geser> have you a package name with an upload to security at hand?
[10:46] <kklimonda> transmission
[10:49] <geser> hmm, apparently no -security branches (see https://code.edge.launchpad.net/ubuntu/+source/transmission)
[10:51] <kklimonda> weird
[10:51] <kklimonda> django have -security branches so it would seem that it's dependant on developer.. but aren't those branches created automatically?
[10:52] <geser> yes, but I don't know how it's triggered as it runs "external" to LP itself
[10:56] <geser> or not so external as I just found out
[11:05] <wgrant> geser: "not so external"?
[11:06] <geser> I found an loggerhead branch mentioning package-import.ubuntu.com but it was 2 years old
[11:07] <geser> wgrant: do you know how bundled this package-import.ubuntu.com is with LP itself?
[11:07] <wgrant> It is external. It checks LP regularly for new uploads.
[11:07] <wgrant> It's not part of LP. It uses the public API and bzr to communicate.
[11:08] <jetienne> q. im writing a /etc/init.d script..  where can i get info on the language between ### BEGIN INIT INFO and ### END INIT INFO
[11:13] <jetienne> http://wiki.debian.org/LSBInitScripts got it
[11:21] <Laney> what does that mean?
[11:21] <Laney> oh, no channel ctcps I guess
[11:22] <tsimpson> yeah, except for /me
[11:22] <geser> Laney: http://freenode.net/using_the_network.shtml explains them
[11:23] <Laney> got it
[13:52] <kklimonda> can I append ubuntu version to the version string generated by bzr builder/dailydeb ?
[13:55] <RainCT> norsetto: I'm running Sid here and it's really not that scary :)
[13:57] <norsetto> RainCT, oh, I'm not afraid of that, just to screw up since what I'm running now is a kind of monster-patch system, loosely based on hardy
[15:25] <kemmotar> hi all! what you do? can i join your team? (sorry for my bad english)
[15:29] <randomaction> kemmotar: see links in the channel topic
[15:30] <ari-tczew> randomaction, are you bored?
[15:30] <randomaction> ari-tczew: not too much :)
[15:30] <ari-tczew> want to sponsor?
[15:32] <randomaction> I can ack a sync for gambas2 :)
[15:32] <ari-tczew> are you sure?
[15:32] <ari-tczew> yesterday I have checked patch  with upstream
[15:33] <ari-tczew> code aren't the same
[15:35] <randomaction> ok, let's look
[15:35] <randomaction> snprintf(ctx, sizeof(ctx), "%.2g", THIS->doc->getPDFMajorVersion () + THIS->doc->getPDFMinorVersion() / 10.0);
[15:36] <randomaction> %.2g prints a floating-point number. The floating-point number is supplied in the next argument.
[15:36] <randomaction> snprintf(ctx, sizeof(ctx), "%d.%d", THIS->doc->getPDFMajorVersion () + THIS->doc->getPDFMinorVersion() / 10.0);
[15:36] <randomaction> %d prints an integer, so two integers should be supplied
[15:37] <randomaction> instead, one floating-point number is supplied
[15:37] <ari-tczew> so what's the conclusion?
[15:37] <randomaction> that replacing the first line with the second is not a good idea
[15:38] <ari-tczew> ok, give me a moment, I'll convert request to sync
[15:45] <ari-tczew> randomaction, bug 514755
[16:00] <ari-tczew> could lm-sensors backport from lucid to karmic?
[16:04] <randomaction> ari-tczew: done gambas2
[16:32] <ari-tczew> requestsync is bugged
[16:32] <ari-tczew> lazr.restfulclient.errors.HTTPError: HTTP Error 412: Precondition Failed
[16:35] <geser> argh, a 2nd occurance of this :(
[16:36] <ari-tczew> randomaction, thanks
[16:37] <geser> ari-tczew: the bug itself got filed, you just need to "finish" like subscribe the sponsoring team
[16:38] <ari-tczew> huh? which bug is filed?
[16:38] <ari-tczew> ahh, you mean by requestsync
[16:38] <geser> your sync request
[16:38] <ari-tczew> I know
[16:39] <ari-tczew> randomaction just give an ACK, so no problem ;-)
[16:39] <ari-tczew> btw. do you will fix this issue, geser?
[16:40] <Quintasan> fabrice_sp: FYI, most of the rdepends of liblo built fine, didn't test all of them tough
[16:40] <geser> I plan to. I only know a possible reason for this so I can only hope my fix will really fix it
[16:49] <ari-tczew> is there any statistic (LP) who did upload the most packages? just like top10 or something
[16:50] <geser> there was in the past
[16:51] <randomaction> https://launchpad.net/ubuntu/+topcontributors gives some idea, especially soyuz karma
[16:53] <ari-tczew> lol, stupid tool, e.g. Martin Mai has only 5 packages uploaded
[16:54] <ari-tczew> ups, I'm looking on wrong field! sorry!
[16:55]  * iulian wonders where emgent is.
[17:25] <kklimonda> hmm, when I do bzr merge-package tags aren't merged (i.e. only tags from ubuntu branch are present in a working branch)
[17:25] <kklimonda> works fine when I use normal merge
[18:02] <ari-tczew> does MOTU have official logo?
[18:04] <ari-tczew> like this: https://launchpadlibrarian.net/1516491/motu-image-2.png
[18:04] <ari-tczew> anybody have bigger image than this?
[18:26] <fabrice_sp> Quintasan, cool: we will just have to upload build1 versions after sync of liblo. Thanks for taking care of that check ;-)
[18:29] <Quintasan> fabrice_sp: do you mind uploading it? My connection is pretty screwd now and I have lags even when typing :S
[18:30] <ari-tczew> Quintasan: fabrice wrote after sync
[18:31] <fabrice_sp> Quintasan, it's a sync, right?
[18:31] <ari-tczew> so no this time
[18:32] <Quintasan> urgh, looks like broken central heating affect my reading ability
[18:32] <Quintasan> @_@
[18:32] <fabrice_sp> too hot?
[18:32] <Quintasan> too cold
[18:32] <Quintasan> :/
[18:33] <Quintasan> too hot wouldn't be a problem since I could open the door to garden :P
[18:34] <fabrice_sp> right! If we begin to see repeated caracters, we will ping you to keep you awake :-D
[18:34] <Quintasan> lol :D
[18:40] <geser> fabrice_sp: lliikkee tthhiiss??
[18:40] <fabrice_sp> geser, ping
[18:40] <fabrice_sp> :-P
[18:40] <geser> there is a bug in lucid which causes this?
[18:41] <geser> s/?//
[18:42] <geser> just set the delay to "repeat keys" to it's minimum value and this will happen
[18:48] <fabrice_sp> oh, right: remember seing the discussion in ubuntu-devel
[18:53] <geser> can someone access here https://edge.launchpad.net/ubuntu/+source/hypre
[18:54] <hyperair> no permissions
[18:54]  * geser files a bug then
[18:55] <fabrice_sp> yes I can
[18:55] <fabrice_sp> geser, ^
[18:55] <geser> hmm, interesting
[18:56] <fabrice_sp> only when unlogged
[18:56] <fabrice_sp> when I log in, no permission
[19:02] <geser> thanks, added that info to the bug
[19:03] <ScottL> fabrice_sp, when you looked at zynjacku in REVU you mentioned some files were LGPL, how could you tell?
[19:04] <fabrice_sp> click on the legal link
[19:04] <fabrice_sp> ScottL, ^
[19:06] <fabrice_sp> or use licensecheck
[19:07] <geser> DktrKranz: do you know if we can get a newer gpsd into lucid? some other packages are in DEPWAIT on a newer libgps-dev
[19:08] <DktrKranz> geser: I'll have a look with bzed
[19:08] <fabrice_sp> geser,  bug 508013
[19:14] <ScottL> thanks fabrice_sp...I'm learning more and more stuff :)
[19:15] <fabrice_sp> :-D
[19:17] <ari-tczew> geser, so what's the conclusion about gpsd? we can sync it from testing?
[19:19] <geser> not unless DktrKranz or bzed give their OK
[19:24] <ScottL> fabrice_sp, you also mentioned using debhelper 7 format, but I had trouble finding explicative information, can you suggest somewhere to learn more about it?
[19:25] <Laney> man dh
[19:25] <fabrice_sp> ScottL, /usr/share/doc/debhelper/examples/rules.tiny ?
[19:26] <fabrice_sp> man dh is definitively better
[19:27] <ScottL> yes, I found both of those fabrice_sp
[19:28] <ScottL> but my understanding of makefiles, /debian/rules, et al is rather limited still and I'm not sure really how to convert
[19:28] <ScottL> but thanks for your help nonetheless :)
[19:29] <fabrice_sp> ScottL, well, you can try with the tiny rules file (#!/usr/bin/make -f
[19:29] <fabrice_sp>                %:
[19:29] <fabrice_sp>                        dh $@)
[19:30] <fabrice_sp> arghh: bad paste
[19:30] <ScottL> i know which one you are trying to show
[19:30] <fabrice_sp> and if you ,iss something, uses override_<what you need>
[19:31] <ScottL> I did try that last night with the zynjacku but it didn't work
[19:31] <ScottL> I've been reading the FSF gnu make book and I need to devote the time to really understand a large percentage of the dh scripts
[19:32] <fabrice_sp> ScottL, according to the actual rules files, it should work quite easily (it uses ./configure, make and make install )
[19:32] <fabrice_sp> you miss perhaps some extra parameters
[19:33] <ScottL> probably, i tried it very late last night and was a bit fuzzy in the head to dry to problem solve, i'll try again later
[19:34] <ScottL> s/dry/try
[19:35] <fabrice_sp> if you can try now,  we can help you looking after the errors
[19:36] <ScottL_> okay, but I have very limited time (really should be cleaning up for daughter's 8th birthday/sleep over party)
[19:37] <ScottL_> okay, i run debuild -S and:    debian/rules:3: *** missing separator.  Stop.
[19:38] <ScottL_> hmmm, I guess I should revisit what i put into the rules file :/
[19:39] <fabrice_sp> and uses tabs ;-)
[19:40] <ScottL_> blimey, you beat me to it...yes, it was the tab
[19:41] <ScottL_> i compared to /usr/share/doc/debhelper/tiny    but I thought that I had copied it from there last night, perhaps not
[19:42] <ScottL_> so basically for all rules there are no targets and it runs dh clean, dh build, dh *  as called
[19:43] <ScottL_> debuild -S works now again   :)
[19:43] <ScottL_> and building again in pbuilder
[19:44] <ScottL_> but fabrice_sp, how can I pass arguments?   directories and the like?
[19:45] <ScottL_> nevermind, I think this page I found last night (told you it was late) probably has the information   http://kitenet.net/~joey/blog/entry/cdbs_killer___40__design_phase__41__/
[20:18] <Quintasan> hmm, fabrice_sp, shouldn't pbzip2 provide some sort file for update-alternatives?
[20:19] <fabrice_sp> Quintasan, not sure what is the context of the question :-D
[20:21] <Quintasan> fabrice_sp: well pbzip2 is obviously faster with mulicore processors and it should be available to choose as an alternative to standard bzip2
[20:22] <fabrice_sp> Quintasan, sounds logical, yes
[20:23] <Quintasan> well, just a test case, pbzip2 took 7 seconds to zip a 234mb text file and normal bzip almost 20 :P
[20:25] <cody-somerville> Quintasan, absolutely not
[20:25] <fabrice_sp> wouah!
[20:25] <Quintasan> oh
[20:26] <fabrice_sp> cody-somerville, why?
[20:26] <Quintasan> cody-somerville: why not?
[20:26] <fabrice_sp> :-D
[20:26] <cody-somerville> Thats not how alternatives are supposed to be used.
[20:26] <Quintasan> cody-somerville: hm?
[20:27]  * fabrice_sp is learning something new
[20:28] <Quintasan> I though if we provide an alternative in kubuntu-artwork-usplash or unrar & unrar-nonfree we could do something like this for pbzip2
[20:28] <cody-somerville> Yes and that would be wrong
[20:28] <cody-somerville> and cause breakage
[20:28] <Quintasan> why so?
[20:29] <cody-somerville> They take different command line options
[20:29] <Quintasan> uhh, right, I did not consider that
[20:29] <Quintasan> -_-
[20:29]  * Quintasan feels bit stupid now
[20:32] <jmarsden> Quintasan: If you really want to, writing a wrapper script to map the bzip2 options to pbzip2 and using the wrapper as the alternative might be worth a look.
[20:34] <Odd-rationale> Is using the CDBS the recommended way of packaging python modules? From what I've read on the wiki, there seems to be a couple other ways, but I cannot find much information about them.
[20:37] <ScottK> Odd-rationale: For a python module that uses distutils it's an easy way to do it, but currently using debhelper is recommended.  WIth debhelper 7 rules.tiny it's just as easy and technically better.
[20:38] <Odd-rationale> ScottK: ok thanks. I'm kind of new to ubuntu packaging. So I'm experimenting around...
[20:39] <ScottK> Odd-rationale: If you are interested in packaging Python modules I recommend joining #debian-python on OFTC and working with that team (it has a lot of Ubuntu participation) to get your package into Debian (and sync'ed to Ubuntu from there)
[20:39] <Odd-rationale> ok.
[20:39] <ScottK> They are also willing to help people who are new and just learning.
[20:40] <Odd-rationale> so if i want to use dh7, i should call dh_make without the -b option?
[20:57] <hyperair> if you want to use dh7, you run without -b and then get rid of the debian/rules file and start afresh
[20:57] <ScottK> Odd-rationale: I'd start with a working package as a template and use that.
[20:58] <ScottK> Odd-rationale: I'll suggest my python-ipaddr package for one.
[20:58] <fabrice_sp> how is that a package in testing since the 16th of January is not yet in Ubuntu? It's libmoosex-types-common-perl
[20:58] <fabrice_sp> No 'autosync' since the 16th?
[20:59] <ScottK> fabrice_sp: Normal autosync and new package sync are two different archive admin actions.
[20:59] <fabrice_sp> ohh
[20:59] <ScottK> Also new packages need to go through source and binary New in Ubuntu.
[20:59] <fabrice_sp> I thought autosync was sync existing and new packages
[20:59] <ScottK> So "How" is lots of possibilities.
[20:59] <ScottK> Nope.
[21:00] <fabrice_sp> ok
[21:01] <Odd-rationale> hyperair, ScottK: thanks!
[21:03] <Odd-rationale> ScottK: is your python-ipaddr in the repositories?
[21:03] <Odd-rationale> so i can apt-get source it?
[21:09] <ScottK> Odd-rationale: Yes.  In lucid
[21:09] <Odd-rationale> ScottK: oh, ok...
[21:19] <randomaction> fabrice_sp: are you planning to make any uploads of aqsis? If not I'll rebuild it for boost 1.40 (it's uninstallable in lucid now)
[21:37] <fabrice_sp> randomaction, no: no new version in the short term.
[21:37] <fabrice_sp> thanks for taking care of it ;-)
[21:48] <Odd-rationale> ScottK: Thanks for all your help! Would you be willing to take a look at my package and offer some feedback? or is there a way to get someone to show me if I was doing it correctly? Thanks again!
[23:26] <ockham> hi, i'd like to announce my first package: http://revu.ubuntuwire.com/p/pysolfc
[23:26] <ockham> (and my second one: http://revu.ubuntuwire.com/p/pysolfc-cardsets :-)
[23:35] <blueyed> Why am I getting conflicts with "bzr merge-upstream" in debian/* ? e.g. in debian/control.. where does "merge source" come from?
[23:35] <blueyed> james_w: ^^
[23:49] <Odd-rationale> What does it mean by "The changelog does not close a bug from Launchpad."?
[23:50] <Quintasan> Odd-rationale: you are doing a new package?
[23:50] <Odd-rationale> Quintasan: yes. I am learning how.
[23:51] <Quintasan> Odd-rationale: okay, every new package should close a bug from Launchpad
[23:51] <Quintasan> Odd-rationale: please file a bug on launchpad - [needs-packaging] <your package name> and assign yourself to it
[23:52] <Quintasan> Odd-rationale: then in changelog you should add (Closes LP: #<your bug number>)
[23:52] <Odd-rationale> Quintasan: ok. do i file it under ubuntu?
[23:52] <Quintasan> Odd-rationale: yes
[23:53] <Quintasan> Odd-rationale: https://wiki.ubuntu.com/PackagingGuide/Complete
[23:53] <Quintasan> You will use it very often :)
[23:55] <Odd-rationale> Quintasan: yes. i've been reading that. very helpful doc.
[23:59] <Odd-rationale> Is there a way to search within all needs-packaging bugs for a string?