=== asac_ is now known as asac
[00:07] <rgreening> ScottK: I have tac_plus uploaded to my PPA... assuming it builds, I'll be able to test it out... not sure if the sql stuff will work this go around.
[00:15] <rgreening> ScottK: if you have time, I'd appreciate you taking a peek at the package.
[00:16] <ScottK> rgreening: Perhaps tomorrow.
[00:17] <rgreening> ScottK: awesome. ty
=== fta_ is now known as fta
=== bluefoxicy is now known as [GM]Dave
=== [GM]Dave is now known as bluefoxicy
[00:38] <doctormo> Have some packagaing problems, how do you deal with an automake based project where one of the parts is off in it's own directory, with it's own Makefile that isn't connected to anything else. Files that don't even get bundled when we do a make dist?
[00:38] <lifeless> doctormo: so, is this yours, or something you're inheriting /upstream
[00:38] <doctormo> Do I try and merge the Makefile into the autotools system somehow, do I move the c file to the src directory or do I keep it where it is?
[00:39] <doctormo> lifeless: Inheriting Orphaned
[00:39] <lifeless> if it will build ok with the Makefile, but you want to make 'make dist' work, add the directory and its contents to EXTRA_DIST
[00:40] <lifeless> it won't VPATH build though
[00:40] <lifeless> so you may want to take it over upstream and Just Fix It
[00:40] <doctormo> right, so I did manually copy the dir and it still didn't build
[00:40] <doctormo> Oh we've already put it into launchpad, so it's bzr branches are upstream as far as we're concerned.
[00:44] <doctormo> lifeless: Where is the best place for a python programmer (me) to go in order to learn how to "just Fix it"(tm), distutils is much easier to me.
[00:44] <lifeless> do you know why they have this odd directory?
[00:44] <lifeless> knowing the reason may avoid spending effort trying to fix it ;)
[00:45] <lifeless> point me at the branch if you would
[00:51] <epiphany> hi
[00:51] <epiphany> what is that package that contains that little networking icon in the GNOME panel?
[00:52] <doctormo> lifeless: The reason I believe is that the main Makefile deals with building the xorg-input driver and this makefile is for building a simple c program for configuring the calibration.
[00:52] <lifeless> network-manager?
[00:53] <epiphany> i got it now. thanks
[00:53] <lifeless> doctormo: so one option is to not build the program :)
[00:53] <doctormo> It is, the existing debian build expected it, but I could strip it out
[00:53] <lifeless> I see
[00:53] <lifeless> so, two things
[00:54] <lifeless> one is that you don't need  to fix this to update the package - just don't use 'make dist' (as apparently the old author didn't either)
[00:54] <lifeless> the second is that this sounds like just crummy organisation, and I would indeed fix the build
[00:54] <epiphany> can one go about setting up their own APT mirror?
[00:54] <lifeless> if its using automake+autoconf the goat book is pretty good
[00:55] <doctormo> lifeless: for your curiosity - lp:wizardpen
[00:55] <lifeless> I'd tend to use non-recursive make which means a single Makefile.am
=== VK7HSE1 is now known as VK7HSE
=== VK7HSE is now known as VK7HSE_
=== VK7HSE_ is now known as VK7HSE
[01:51] <omerm> Hi everyone. I just tried packaging for the first time to fix this bug: https://bugs.launchpad.net/launchpad-foundations/+bug/90150 . I applied the patch found in the comments, and followed the packaging guides to create a debdiff. I don't have an AMD64 system, so I can't test it. Should I send it to one of you for approval? Post it in launchpad? Thanks in advance.
[01:51] <ubottu> Ubuntu bug 90150 in launchpad-foundations "Launchpad does not automatically know about LP-managed username@ubuntu.com email addresses" [High,Triaged]
[02:31] <mrooney> omerm: that sounds like a #launchpad question but you may know more than I
[02:32] <omerm> alright I'll try there. thanks!
[02:36] <lifeless> mrooney: actually, its totally on topic here
[02:36] <omerm> I just realized I linked to the wrong bug
[02:36] <omerm> https://bugs.launchpad.net/ubuntu/+source/vnc4/+bug/119982
[02:36] <lifeless> omerm: If the patch has been validated already - if its known to fix the problem
[02:36] <ubottu> Ubuntu bug 119982 in vnc4 "amd64 vncconfig crashes" [Undecided,Confirmed]
[02:36] <lifeless> then, put it into REVU
[02:37] <lifeless> if its not known to fix the problem, make a PPA, upload it there, and ask for testers
[02:38] <omerm> commenters said that it fixed the bug, but it doesn't seem there was any kind of official confirmation. Is it enough?
[02:40] <lifeless> we're a community group :)
[02:40] <lifeless> people commenting are official in that sense ;)
[02:41] <lifeless> REVU is the review process
[02:41] <lifeless> or you can put your debdiff up
[02:41] <lifeless> and put it in the universe sponsors queue
[02:41] <lifeless> either is fine
[02:41] <lifeless> and both are documented on the motu wiki pages, I think
[02:42] <omerm> alright, will do. thanks
[03:46] <mirsal> Hello. Anyone awake ?
[03:47] <mirsal> I'll assume so.
[03:47] <mirsal> I need five minutes of a package maintainer's time for a little update about how to contribute a patch the right way. Anyone ?
[03:52] <mirsal> (or maybe you could give me a pointer on where to look / who to ask )
[04:00] <doctormo> mirsal: Ask the question as best you are able.
[04:02] <mirsal> doctormo, Basically, I'd like to know how not to just edit the sources and rebuild the package. I don't know how to make a proper patch, update the changelog, bump the version number etc, I guess it's not done by hand.
[04:06] <doctormo> mirsal: Some is, most isn't.
[04:06] <doctormo> Now I'm not an expert, but experts don't seem to be awake right now, so I'll fill you in on as much as I know.
[04:06] <mirsal> doctormo, thanks that would be nice :)
[04:07] <doctormo> mirsal: use apt-get source [package-name] to get the source typically, if your updating to say a new bzr or git checkout then still get this for the debian dir
[04:08] <doctormo> mirsal: Now you need to make sure you get a good dist tar.gz of the sources, this is everythign without the debian directory or .bzr hidden dirs that will be used to build and install. Usually the makefile or build utils will have a dist option to generate the required gz.
[04:08] <doctormo> (this part is after you've modified the source)
[04:08] <mirsal> ok
[04:09] <mirsal> (some of my changes are specific to the debian/ubuntu package btw)
[04:09] <doctormo> mirsal: so, now you unpack your gz, say it's foo-0.1.4, you should then have at least 2 directories ./foo (from which you edit code) and ./foo-0.1.4 which you are doing the packaging in.
[04:10] <doctormo> mirsal: Ah if your only updating the package then your not updating the source... depends on what your up to.
[04:10] <mirsal> I'm updating both actually
[04:10] <doctormo> Source updates should incur a version bump for the actual program ver, but package updates should bump just the 0ubuntu0 versions.
[04:11] <doctormo> If both, then program ver bump clobbers package ver and package ver should be 0ubuntu1 I believe.
[04:11] <mirsal> ok
[04:11] <doctormo> So you'll be editing it in two parts, because packaging is considered down stream and source editing is considered upstream and your wearing two hats.
[04:12] <doctormo> Hence two directories.
[04:12] <mirsal> I see.
[04:16] <mirsal> (maybe I should give you a little more context: I'm adding support to new devices to the evtouch xorg driver, this requires to alter a bit the sources and to add new udev rules / HAL fdi files. The hal config files are part of the ubuntu package whereas the rest is in the vanilla sources)
[04:17] <doctormo> mirsal: I've done 3 driver packages and I'm working on xorg-input-wizardpen are you any good with automake btw, you might be able to help me in exchange.
[04:18] <mirsal> doctormo, I know my basics :)
[04:18] <doctormo> mirsal: I'm also very familar with HAL fdi files and udev rules since I manage a barry PPA (for blackberry support)
[04:18] <mirsal> cool, lucky me then ^^
[04:21] <doctormo> heh
[04:22] <doctormo> mirsal: so if all your doing is updating the hal fdi or udev rules, just stick them in the debian directory like I do with wizardpen and epson-scanners. They're not upstream so their really additions during packaging.
[04:24] <mirsal> yeah
[04:24] <mirsal> for the rest, should I just add a patch to debian/patches/ ?
[04:25] <mirsal> or is it not possible to mix the changes ?
[04:27] <doctormo> mirsal: In that instance you can, so long as you keep everything in debian dir and call it "packaging"
[04:27] <doctormo> Just bump the packaging ver in that case.
[04:28] <mirsal> ok
[04:28] <doctormo> mirsal: Was I any help at all?
[04:29] <mirsal> doctormo, absolutely !
[04:29] <mirsal> thanks a lot, it's now way clearer in my head
[04:30] <mirsal> just one last thing: should I update the changelog by hand ?
[04:30] <mirsal> (I mean debian/changelog)
[04:32] <doctormo> mirsal: You can use the dch tool or you can update it by hand, up to you.
[04:32] <mirsal> ok
[04:39] <doctormo> mirsal: Perhaps I can get your help now? See I'm fairly ok with the systematics of the whole thing and I also teach (if you've never seen my nickname before on the planet) so I'm getting good at explaining things too.
[04:40] <doctormo> But so far Makefile proper combined with autotools have mistified me.
[04:41] <mirsal> :)
[04:42] <mirsal> doctormo, so how can I help ?
[04:42] <mirsal> (if I can)
[04:43] <doctormo> mirsal: I have the wizardpen stuff mostly working, but the upstream (now orphaned) put the calibration tool into it's own directory with it's own makefile that doesn't use autotools and automake, it's just a bog standard Makefile
[04:44] <lifeless> doctormo: in short; delete the Makefile ;)
[04:44] <doctormo> mirsal: So I want someone to help me get the package so it compiles the calibration tool and puts the source files in the dist (using make dist) which at the moment it doesn't
[04:44] <doctormo> lifeless: really?
[04:44] <lifeless> yes, its contents should be rolled into Makefile.am in the root
[04:45] <mirsal> lifeless, yeah, does the makefile do funky things ?
[04:45] <mirsal> lifeless, +1
[04:45] <lifeless> doctormo: unless its depending on gnu Make features, which is unlikely for a simple tool lie you describe
[04:45] <doctormo> lifeless: nah it's a strain gcc call, one liner
[04:46] <lifeless> its probably just
[04:46] <lifeless> bin_PROGRAMS = calibration/foo
[04:46] <lifeless> in the top Makefile.am then
[04:48] <doctormo> lifeless: Sounds too good to be true, let me try it :-D
[04:50] <mirsal> (plus subdirs if any, foo_SOURCES / _SCRIPTS if any / _CFLAGS / _LDFLAGS etc, the usual stuff
[04:51] <doctormo> mirsal: gcc -o wizardpen-calibrate wizardpen-calibrate.c, heh nothing. Lets see if it builds
[04:51] <mirsal> huhu
[04:52] <mirsal> doctormo, oh, I forgot to ask you one other thing: what are the diff options I should use in order to produce a patch suitable for debian/patches/ ?
[04:52] <doctormo> lifeless: worked perfectly, now I just have to re-jig it's auto generation of the ChangeLog via git, since it's a bzr branch it's failing that.
[04:53] <doctormo> mirsal: Wrong person to ask, my knol stops there.
[04:53] <mirsal> heh ok :)
[04:53] <mirsal> I'm asking out of laziness, I think I can figure out
[04:53] <doctormo> mirsal: lol, for that you get to critique my work http://divajutta.com/doctormo/learning/local-computer/identifying-computer-ports.pdf
[04:56] <mirsal> damn, evince is taking its time...
[04:56] <lifeless> mirsal: foo_SOURCES is automatic if its a single file; subdirs aren't needed with non-recursive syntax:)
[04:59] <mirsal> lifeless, yeah, I missed the 'single file' part :)
[05:01] <mirsal> doctormo, it's perfect, apart from the fact that the LEDS on female RJ45 ports are not standard, and that I think you sould include ExpressCard slots :)
[05:04] <doctormo> mirsal: If you have a picture of an express card slot, leds aren't standard I know, it's what I call an editorial desision.
[05:04] <mirsal> doctormo, well, I just HAD to say something ^^
[05:05] <doctormo> mirsal: Best response is "It's a masterpiece and I'm going to blog about it right away, I hope the author also writes a similar one for internal slots" etc etc.
[05:06] <mirsal> It's a masterpiece and I'm going to blog about it right away, I hope the author also writes a similar one for internal slots
[05:07] <mirsal> well, won't blog about it (because I'm lazy, I told you) but I'm going to identwitfacebook it.
[05:09] <doctormo> mirsal: Ah your using grubber
[05:10] <mirsal> gwibber yeah
[05:11] <doctormo> woot: https://launchpad.net/~doctormo/+archive/xorg-wizardpen it built on lpai, that's a good sign
[05:12] <mirsal> :)
[05:13] <doctormo> lifeless: I owe you a drink... or at least the idea of a drink (till I get a new job)
[05:13] <lifeless> :P
[05:13] <lifeless> pay it forward
[05:33] <doctormo> lifeless: I've got so much being paid forward right now, that's one of the reasons I don't have a job, don't have time for one.
[05:33] <doctormo> ;-)
[05:33] <doctormo> Good night all
[05:34] <tgm4883> Please redirect me if there is a better channel for this, but when installing packages, is there a way to pass info to debconf from say, the command line?
=== Blendiac is now known as Bugsbane
[05:52] <mirsal> lifeless, when you see doctormo, tell him that I also owe _him_ a drink :)
[05:52] <mirsal> tgm4883, yeah
[05:52] <mirsal> there is a way
[05:53] <mirsal> tgm4883, don't remember how though
[05:53] <tgm4883> mirsal, i'm reading about preseeding right now, is that the way?
[05:53] <tgm4883> ah
[05:55] <mirsal> tgm4883, there is a 'noninteractive' debconf frontend, for debconf
[05:56] <mirsal> tgm4883, use it along with --assume-yes and you've got a fully automated apt-get
=== YDdraigGoch is now known as Fluffles
=== ejat is now known as e-jat
[09:19]  * hyperair wonders how much space ia32-libs would need.
[09:29] <geser> hyperair: I hope you don't need the source package of it
[09:30] <hyperair> geser: i've already gotten the source package. what a behemoth.
[09:30] <hyperair> geser: i'm trying to update this thing.
[09:30] <geser> good luck
[09:30] <hyperair> thanks.
[09:31] <hyperair> i wonder if anyone would sponsor me if i had it updated.
[09:31] <hyperair> the .dsc is humongous X_X
[09:32] <geser> my upload bandwidth is way to small to sponsor this monster
[09:33] <hyperair> heh
[09:39] <hyperair> on second thoughts, there appears to be an ia32-libs-testing ppa around
[09:39] <hyperair> https://launchpad.net/~cjwatson/+archive/ia32-libs-testing
[09:39] <hyperair> i think i'll just use that pacakge instead
[09:40] <cjwatson> it's not quite right yet, but I'm working on it
[09:40] <cjwatson> (see #ubuntu-devel)
[09:41] <hyperair> hmm
[11:41] <lamothe> Hi, with man pages, if I create a package that has 2 executable binaries in it, but only one is designed to be run by the user (i.e. the first one calls the second one) do I need to create a man page for the one that is not designed to be run by the user?
[11:41] <cjwatson> not in general, but if that's the case then the one not designed to be run manually should not be in /usr/bin
[11:42] <cjwatson> e.g. /usr/lib/<package>/
[11:42] <cjwatson> everything in /usr/bin/ (and /bin/, /sbin/, /usr/sbin/) should have a manual page
[11:42] <lamothe> cjwatson: Ahhh, really! I didn't know that, thanks, that makes it a lot clearer then doesn't it.
[11:45] <lamothe> cjwatson: Thanks, again.  I appreciate it.
=== proppy1 is now known as proppy
=== WelshDragon is now known as Fluffles
[13:46] <Laney> wgrant: Are mdt package sets dynamically updated?
[13:47] <wgrant> Laney: Yes.
[13:47] <wgrant> Well, except for those that aren't.
[13:47] <wgrant> Let me see which aren't.
[13:47] <Laney> No, it's OK
[13:47] <Laney> Can you create a set out of a big list of packages and a query?
[13:48] <wgrant> What sort of query?
[13:48] <Laney> maintainer
[13:49] <wgrant> Yep. Already got a couple of them.
[13:49] <Laney> I'm interested in tracking Haskell packages. We just formed a team but a lot of them haven't been moved over yet
[13:49] <Laney> cool, I'll rustle you up a list shortly if that's OK?
[13:50] <wgrant> Sure.
[13:50] <wgrant> I'm about to head off for the night, so I'll do them tomorrow some time.
[13:51] <Laney> no worries
=== bastiao_ is now known as k0p
[13:53] <wgrant> Laney: There are currently lists automatically calculated from rdepends and a team's +packagebugs, if that makes it any easier.
[13:53] <Laney> recursive rdepends would be good if you could do that
[13:53] <Laney> seeding from ghc6
[13:54] <Laney> rbuild depends, that is
[13:55] <wgrant> That's not so easy.
[13:56] <wgrant> (the recursive bit, that is)
[13:56] <Laney> thought it might not be
[14:01]  * wgrant disappears.
=== azeem_ is now known as azeem
[15:43] <james_w> yay statik!
[17:37] <maxb> Does anyone have any thoughts on the best way to develop packages for Karmic whilst also making them backportable to earlier releases, specifically concerning debhelper 7?
[17:38] <Laney> get the newer version of dh backported
[17:39] <hyperair> there are  debhelper packages around for jaunty and intrepid floating aroudn the PPAs
[17:39] <maxb> I am contemplating attempting to merge debhelper 7.0.52 from upstream  with the Intrepid / Jaunty versions and backport it to Hardy. The key thing being override_dh_foo support in 7.0.50, but I'm not sure I want to backport 7.2
[17:39] <hyperair> and quilt 0.46-7 as well
[17:39] <maxb> indeed
[17:39] <hyperair> 7.0.50 has override support.
[17:39] <hyperair> why do you need 7.2?
[17:39] <maxb> I don't need 7.2 - that's the point
[17:40] <hyperair> then just backport 7.0.50
[17:40] <hyperair> but there's no harm in backporting 7.2 if it's easier
[17:40] <maxb> 7.0.50 is not in any Ubuntu distroseries
[17:40] <hyperair> it isn't eh
[17:40] <Laney> nah
[17:40] <Laney> I'd just ask for a backport of whatever's in Karmic
[17:41] <ScottK> But if you want it to go to Hardy, also backport it to Intrepid/Jaunty.
[17:41]  * maxb goes to figure out what changed 7.0 -> 7.2
[17:41] <hyperair> the changelog's pretty good for that
[17:41] <hyperair> aptitude changelog debhelper
[17:42] <Laney> dh_gencontrol: Ensure misc:Depends is set in substvars to avoid dpkg complaining about it when it's empty
[17:42] <Laney> :O!1!
[17:43] <hyperair> O_o. the hell?
[17:43] <hyperair> isn't debhelper supposed to generate that?
[17:44] <maxb> It does - if it has anything to put there
[17:44] <maxb> I guess after that change it generates an empty one
[17:45] <maxb> (in all cases)
[17:45] <maxb> "Depend on dpkg-dev 1.14.19" could back a hardy backport of 7.2 a little trickier
[17:51] <maxb> I guess it would be feasible to carefully revert the changes relying on the newer dpkg
[18:57] <ScottK> james_w: Got a moment for an archive admin task?
[19:05] <ScottK> Maybe StevenK?
[19:06] <ScottK> If either of you turn up whilst I'm out, I'm looking for someone to promote kubuntu-netbook-default-settings to Main.  The MIR is approved, just needs moving ....
=== mrooney is now known as mrooney_
[20:00] <ajish> hi
[20:01] <ajish> I am looking for ubuntu build system documents? google didn't help
[20:01] <ajish> can some one help here?
[20:02] <coolbhavi> ajish, search for launchpad PPA packaging help
[20:02] <coolbhavi> there you can find faq
[20:03] <coolbhavi> about buildds
[20:06] <ajish> thanx coolbhavi
[20:06] <ajish> is any one here from bangalore india?
[20:08] <coolbhavi> ajish, I am
[20:09] <ajish> is their any group in bangalore for ubuntu?
[20:09] <ajish> where i can join
[20:09] <ajish> ?
[20:10] <coolbhavi> no but go to #ubuntu-in and we better stop this right here as its a devel channel
=== bluefox_ is now known as Braufuchs
[21:38] <pwnguin> is anyone left on hardy-backports?
[21:39] <Laney> anyone quickly know how to tell vim to always :set expandtab for changelog/control/rules files?
[21:44] <jpds> Laney: autocmd BufEnter */debian/* set expandtab
[21:44] <Laney> you beauty
[21:45] <jpds> You might want to: autocmd BufEnter */debian/rules set noet tabstop=8 shiftwidth=8 - for rules.
=== runasand is now known as ninjarobot
=== ninjarobot is now known as runasand
[22:06] <jmarsden> Is it normal for a firefox 3.5 daily build to take more than a day?  lemon, one of the PPA build hosts, is running such a build now... seems like over time that behaviour would use up and backlog the entire set of PPA build machines :)
[22:07] <Laney> you can look at a previous successful build to check
[22:07] <jmarsden> OK, will do.
[22:09] <jmarsden> Looks like a previous build of it took under 7 minutes... who should be asked to take a look at that build machine?
[22:10] <Laney> I believe if you click on the name of a buildd you can find the owner
[22:12] <jmarsden> OK.
[23:50] <lfaraone> If I want dch to act as if I was running it using Debian, what option do I pass.
[23:50] <lfaraone> *?
[23:51] <lfaraone> Despite bug 85366 being fixed, "--distribution=Debian" errors out.
[23:51] <ubottu> Launchpad bug 85366 in devscripts "debchange should not add Ubuntu specific stuff to my changelog" [Undecided,Fix released] https://launchpad.net/bugs/85366
[23:53] <geser> doesn't dch -D Debian (or --distributor Debian) work?
[23:53] <lfaraone> geser: No, that gives an error.
[23:54] <lfaraone> geser: oh, the latter works.
[23:56] <geser> right, -D is --distribution and not --distributor which doesn't have a short option