[00:03] <zooko> So, I think I'm going to advise the folks on tahoe-dev to add http://ports.ubuntu.com to their /etc/apt/sources.list if they want PowerPC binaries...
[00:27] <RoAk> persia: ping
[00:45] <mase_wk_> morn all
[00:53] <RoAk> TheMuso: ping
[02:07] <jdong> haha ok well that makes btrfs / work... though not in the prettiest of ways.
[02:07] <jdong> yay diverting grub-probe.
[02:11] <mase_wk_> i'm having some problems building a kernel package on 8.04 which will automatically run update-initramfs. I am passing the --initrd flag to make-kpkg but that does not seem to be the way to do it. Can anyone point me in the right directi on ?
[02:42] <tgm4883> in the files in debian/ can I do release specific files such as postinst.karmic?
[02:44] <StevenK> tgm4883: Nope.
[02:44] <tgm4883> bummer
[02:44] <tgm4883> thanks StevenK
[05:51] <slangasek> AnAnt: you were pinging me yesterday?  More effective if you say what you're looking for, saves a round trip...
[06:08] <fabrice_sp> dyfet, ping
[06:09] <fabrice_sp> just to know if you're still working on bug #438450 (still in Progress, but debdiff attached)
[06:40] <fabrice_sp> ScottK, about Bug #424576. Is it mandatory a second motu-release ack, as per the FFe process? Or as delegate, you acked it twice?
[06:41] <ScottK> fabrice_sp: The latter.  It's approved.
[06:42] <fabrice_sp> ok. will have a motu look then. Thanks!
[06:49] <dholbach> good morning
[07:15] <fabrice_sp> Good morning dholbach !
[07:16] <dholbach> hiya fabrice_sp
[07:37] <fabrice_sp> ScottK, do your ack to chef extend to a required dependency? Bug #420674 is required to have chef working correctly. Or it's better to subscribe motu-release for a specific FFe?
[07:56] <_Andrew> How do you make a build-depends package optional
[07:56] <_Andrew> Anyone know?
[07:58] <Amaranth> _Andrew: optional as in only for a certain arch?
[07:58] <Amaranth> Otherwise you can't
[07:58] <_Andrew> yes
[07:59] <Amaranth> ah, iirc it's libgtk2.0-dev [amd64]
[07:59] <_Andrew> So if it is lpia it shouldn't use a certain package
[07:59] <Amaranth> I don't remember how to do "all but amd64" or whatever though
[07:59] <_Andrew> ah
[07:59] <Amaranth> Perhaps [!lpia]?
[07:59] <_Andrew> ok thanks I'll give it a try
[07:59] <maxb> [!amd64] iirc
[08:00] <Hobbsee> yeah, it's that
[08:00] <_Andrew> oh ok
[08:00] <_Andrew> Actually one more question
[08:00] <_Andrew> What's the best way to detect the arch in the rules file. Because I just remembered I have to make sure it doesn't set the flag too
[08:01] <Amaranth> _Andrew: dpkg --print-architecture
[08:01] <maxb> shouldn't you use DEB_BUILD/HOST_ARCH or whatever for that?
[08:02] <Amaranth> Probably
[08:02] <Amaranth> DEB_HOST_ARCH is safer
[08:03]  * RAOF remembers reading something about these variables, but can't remember what.  Maybe the last couple of months worth of debian-devel archives will have something interesting?
[08:04] <_Andrew> So..  if ( DEB_HOST_ARCH == "lpia")  ?
[08:06] <_Andrew> oh, actually that's no problem looks like I was wrong, no need to set the compiler flag
[08:06] <_Andrew> Thanks for the help then
[08:29] <wrapster> I get this msg... after dpkg-buildpackaged.. Failed to sign .dsc and .changes file
[08:29] <wrapster> How do i sign them?
[08:31] <av`> wrapster, debsign -kKEYID *.dsc
[08:31] <wrapster> ok...
[08:34] <YokoZar> wrapster: make sure you have the GPG key for the email address that's at the top of the changelog too
[08:34] <wrapster> ok
[09:00] <moldy> hi
[09:01] <moldy> sometimes (depending on bug state?), lp shows a state change menu where you can change state and comment in one step. but for "new" bugs, it seems you have to take 2 steps...
[09:06] <wrapster> YokoZar: while dpkg-buildpackage itself i specified -kKEYID yet it says it cannot sign
[09:07] <wrapster> KEYID is a 8digit alphanumeric right?
[09:07] <wrapster> or the PGP sign?
[09:08] <YokoZar> not sure
[09:08] <wrapster> hmm
[09:19] <directhex> wrapster, yes, KEYID is the 8-digit hex value of your key
[09:58] <ripps> I need some help, I'm trying learn some basic debelper without cdbs, and I'm trying to create a library pacakge for libmpdclient2. What's the proper method of creating a -dev package?
[10:00] <ripps> fyi, I use dh-make to make the template for /debian
[10:00] <joaopinto> ripps, there is nothing like looking into an existing one :)
[10:01] <joaopinto> ripps, also check: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[10:03] <ripps> Do I have to manually do the installing of the -dev files, or does automake allow me to install some of that automatically?
[10:04] <joaopinto> I am a bit lost on your question, the files that you need to package into the -dev are usually built from the regular app build process,
[10:04] <joaopinto> as for the installation, that depends on the app build system, and how you layout your build and install rules
[10:05] <joaopinto> ripps, packagning libraries is not an easy way to learn packaging :)
[10:05] <ripps> joaopinto: I'm not just doing this for learning, I need to make a library package for a team ppa, several packages now use a new library that hasn't been packaged before.
[10:06] <joaopinto> ah ok :P
[10:06] <ripps> But, I figured I'd take this oppurtunity to steb away from cdbs and level up my packaging skills
[10:07] <maxb> The proper method of creating a -dev package is much the same as creating any other single-source-multiple-binary packaging, other than knowing which files belong in which binary package
[10:07] <maxb> doesn't dh-make give you a pretty thorough template?
[10:08] <maxb> (you ran dh-make in library mode, yes?)
[10:12] <ripps> maxb: yeah, except it made an empty package. So I had to uncomment dh_install, and it started working, but it's saying there was no files in /usr/include for the -dev package. And I know that isn't right, and I just wanted to know I was supposed to manually add it the rules, or I just screwed up something in the building process
[10:14] <maxb> you should probably take a moment to read 'man dh_install'
[10:16] <maxb> Seems a bit silly that it would be commented out in the generated rules file, if *.install files are part of the example
[10:17] <ripps> maxb: okay, by default, the dh-make library template tries to make two seperate packages, using *.install to define them, which implies the use of dh_install. However, when it creates the rules file, it doesn't uncomment the dh_install
[10:17] <ripps> I smell bug
[10:17] <maxb> you could file a bug if you felt like it
[10:18] <ripps> So, I guess I'm going to have to add several commands to move various files to their proper debian/tmp/* directories
[10:19] <maxb> are you?
[10:19] <maxb>     $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
[10:19] <maxb> says my template
[10:20] <maxb> should take care of it all
[10:20] <ripps> I did that, but it didn't seem to install any of the the -dev files
[10:21] <maxb> better figure out why your Makefiles are broken then :-)
[10:21] <ripps> The developer used automake1.10
[10:23] <ripps> the Makefile.am is unglodly long and confusing, wanna take a look?
[10:24]  * maxb wonders how obscure this software is that I can't find it on Google
[10:25] <ripps> maxb: it's only availible at git.musicpd.org
[10:25] <ripps> http://git.musicpd.org/cgit/master/libmpdclient.git/
[10:26] <maxb> doesn't look overly horrendous to me :-)
[10:28] <mok0> maxb: I agree
[10:28] <mok0> ripps: the author has created some local targets that's all
[10:29] <ripps> mok0: ah, where? I'll create a patch.
[10:29] <mok0> ripps: you don't need to patch AFAICS
[10:30] <mok0> ripps: what's the problem? I don't have the scrollback
[10:31] <ripps> mok0: when using the dh-make library template, it doesn't install any of the files into debian/tmp, despite the fact that everything else setup to use it. Uncommenting dh_install fixed it, but it fails, because it can't find any of the files necesary for the -dev.instal pacakge
[10:31] <maxb> although I notice that the upstream has apparently completely changed their buildsystem between the last release tag and current head
[10:32] <mok0> ripps: Ah dh_make....
[10:32] <ripps> maxb: I'm aware, and I'm trying to compensate
[10:32] <mok0> ripps: Here is what I like to say about dh_make:
[10:32] <maxb> basing on what? the tag or head?
[10:32] <mok0> DON'T USE IT!
[10:32] <mok0> :-)
[10:32] <mok0> ripps: did you try using cdbs?
[10:32] <ripps> don't use dh-make?
[10:33] <mok0> ripps: right, it sux bigtime
[10:33] <ripps> mok0: I'm alreay familiar with cdbs, but I'm trying to learn some basic debhelper
[10:33] <maxb> eww. cdbs.
[10:33] <maxb> :-)
[10:33] <maxb> Here's what I like to say about cdbs:    DON'T USE IT!   :-)
[10:33] <_Andrew> lol
[10:33] <mok0> ripps: if you're lucky, an autotools project can be installed with a 3 line cdbs file
[10:34] <ripps> if push comes to shove, I'll just use cdbs, but I keep hearing people say that dh7 should work without cdbs
[10:34] <mok0> maxb: why?
[10:34] <mok0> The dh_make templates are full of bugs, and the multi-arch template doesn't work at all
[10:36] <mok0> dh_make templates puzzled me a lot when I was first learning packaging, I thought there was something wrong with my thinking... turns out now I understand it, that the templates are screwy
[10:36] <maxb> cdbs look like it should make things easy, but sooner or later you end up needing to become an uber-guru in Makefile syntax to figure out what on earth it's doing
[10:37] <mok0> maxb: true, if something out-of-the ordinary needs to be done, you're on your own
[10:37] <mok0> maxb: however, examining /usr/share/cdbs/1/* usually clears up any problems
[10:38] <mok0> maxb: Fact is, you can do anything with cdbs
[10:38] <maxb> yeah.... but the more out of the norm you are, the more of cdbs you chuck away and do it yourself :-)
[10:38] <mok0> maxb: but sometimes the rules file becomes as long as the straight dh_* calls, and then it's not worth it
[10:38] <joaopinto> IMHO cdbs is cleaner for general build cases
[10:39] <mok0> joaopinto: exactly
[10:39] <maxb> That was cdbs's big win, but dh7 competes rather nicely on that stage
[10:39] <ripps> I hear there's a method to make a rules file with one command using dh7
[10:39] <mok0> joaopinto: ... and less likely to get you in trouble with the REVUers
[10:39] <mok0> ripps: there is
[10:40] <mok0> #/usr/bin/make -Bf
[10:40] <mok0> %:
[10:40] <mok0> 	dh $@
[10:40] <joaopinto> debhelper seems better for complex builds, because it's already complex for general builds :P
[10:40] <mok0> joaopinto: lol
[10:40] <ripps> dh $@
[10:40] <ripps> heh, I'll try that and see if it works
[10:41] <mok0> ripps: you need the line before too
[10:41] <mok0> ripps: "%:"
[10:41] <ripps> I know, I found the example with all 3 lines for the file
[10:41] <maxb> ah, I've never seen make -B used like that before
[10:42] <mok0> maxb: it's part of the sneaky secret
[10:42] <ripps> damn, it still aborts
[10:42] <mok0> maxb: IMHO, cdbs is easier... no perl spaghetti to understand
[10:42] <ripps> dh_install: libmpdclient-dev missing files (usr/include/*), aborting
[10:43] <mok0> ripps: a bug in your .install file
[10:43] <ripps> why doesn't it install the include files
[10:43] <mok0> ripps: because they are not where you say they are
[10:43]  * maxb wonders if ripps has forgotten to ./configure --prefix=/usr
[10:44] <ripps> oh, I'm so used to cdbs handling that for me, I suppose it never occured to me
[10:45] <mok0> ripps: you realize, of course, that cdbs uses dh_* behind the scenes?
[10:46] <ripps> geez, this isn't about what's more efficient or easier, I'm trying make this into a learning experience. Never hurts to have more knowledge
[10:47] <mok0> ripps: kk
[10:47] <maxb> ripps: btw, I seem to have muddled together a working packaging whilst we've been discussing it
[10:48] <ripps> pastebinit, good to take a look at good example files
[10:51] <maxb> http://paste.ubuntu.com/281157/
[10:51] <ripps> I can just delete the /usr/share/pkgconfig line fromt the -dev.install, right?
[10:51] <maxb> well sure, it's not installing anything there
[10:52] <maxb> I'm not 100% clear on the difference betweek lib/pkgconfig and share/pkgconfig
[10:52] <ripps> well, dhmake does a nice job of setting up a template for all the files in debian/, but it just sucks at the rules file.
[10:53] <ripps> lol, awesome, my rules is only 5 lines
[10:53] <ripps> it works!
[10:53] <ripps> had to do an override, though
[10:54] <maxb> what for, ooi?
[10:54] <ripps> http://pastebin.com/f34acec6a
[10:54] <ripps> so that it would run autogen with --prefix=/usr
[10:54] <maxb> hm
[10:55] <ripps> now that's zen... packages look good too
[10:55] <maxb> usually the orig tarball would come with autogen stuff pregenerate
[10:55] <maxb> d
[10:55] <maxb> but as you're packaging from git, I guess that's a reasonable stratecgy
[10:56] <ripps> I don't, because since my is daily-ppa-bot built, sometimes new files need to be cleaned and regenerated, so it's just easier to run autogen every time I build
[10:56] <ripps> keeps things cleaner from my end
[10:57] <ripps> especially since I backport across several versions of ubuntu, and each one has different versions of libtool, automake, etc.
[10:58] <ripps> *sigh*, now I just need to finish the documentation in debian/
[10:59] <maxb> remember that hardy doesn't have a debhelper that supports overrides
[11:00] <maxb> and make sure your control file build-depends on debhelper (>= 7.0.50) to reflect this
[11:01] <wrapster> after i changed the changelog im getting this http://pastie.org/634688
[11:02] <maxb> yes?
[11:02] <maxb> so I guess you told it a keyid you don't have the secret key for
[11:09] <ripps> maxb: don't worry, I already have updated debhelper and other files in dependency ppa
[11:09] <maxb> There must be so many backports of debhelper in various ppas :-)
[11:09] <maxb> I have my own
[11:10] <ripps> yeah, my build-depends ppa has only 2 packages I made and around a dozen I've copied from various other ppas
[11:16] <wrapster> maxb: here is what i've did... http://pastie.org/634698
[11:18] <maxb> It is almost always incredibly incorrect to be generating a key as root
[11:27] <dyfet> fabrice_sp: sorry missed your ping...?earlier?  the debdiff finishes #438450
[11:29] <mok0> Hrmmph, pull-lp-source stopped working
[11:37] <fabrice_sp> dyfet, np: I saw it was not the right timezone :-) You should have put the bug report as confirmed, then
[11:37] <fabrice_sp> I'll do it for you, anyway
[11:38] <dyfet> fabrice_sp: sorry. you are correct...I should have changed it to confirmed :)
[11:38] <ScottK> fabrice_sp: It did not apply to that.  I'll have a look.
[11:38] <fabrice_sp> ScottK, ok. Thansk :-)
[11:39] <fabrice_sp> dyfet, done. This way, some sponsor will have a look ;-)
[11:39] <dyfet> fabrice_sp: it was late, and I missed that...
[11:40] <fabrice_sp> dyfet, np ;-)
[11:43] <ScottK> fabrice_sp: Approved.
[11:44] <fabrice_sp> dyfet, do not add a patch system when Debian maintainer has done changes directly in the source. Also, report to Debian, to see if they are willing to adopt the change :-)
[11:45] <fabrice_sp> ScottK, thanks!. I'll check it then.
[11:46] <dyfet> fabrice_sp: ah...ok
[12:05] <sistpoty|work> hi folks
[12:08] <highvoltage> hi sistpoty|work
[12:08] <sistpoty|work> hi highvoltage
[12:27] <mok0> What do you do when upstream steals your work?
[12:28] <Laney> steals?
[12:28] <mok0> Laney: yeah, I wrote a manpage for a package, and in a subsequent release, upstream has changed a few bytes, and removed the accreditation
[12:29] <Laney> presumably they can't remove your copyright attribution
[12:29] <ara> hello #ubuntu-motu, want to help testing some Karmic beta images? http://iso.qa.ubuntu.com
[12:30] <mok0> Laney: there was only the usual blurp about who wrote the manpage in the AUTHORS section, no copyright mentioned there
[12:30] <Laney> mok0: I'm sure if you ask them nicely to put it back they wil
[12:30] <Laney> l
[12:30] <mok0> Laney: I sent him patches including the manpage for inclusion in his distribution
[12:31] <ripps> Okay, I'm trying to build my *.changes files for my libmpdclient with my ppa-bot, but I keep getting something that's interfering.  http://paste.ubuntu.com/281213/
[12:31] <mok0> Laney: I did write to him about a week ago, no reply
[12:32] <mok0> Laney: I am just wondering whether I should patch it back in the package
[12:35] <Laney> that would look rather odd
[12:36] <mok0> It would, that's why I am rather annoyed
[12:37] <mok0> ripps: can you paste the part of the Makefile that's being executed?
[12:37] <mok0> ripps: ah I see it now
[12:37] <iulian> Err.  What is wrong with Launchpad today?  I've got loads of OOPSes.  Error ID: OOPS-1368F1334
[12:38] <mok0> ripps: that construction in line 6 is wrong
[12:38] <ripps> mok0: I didn't make it, dh $@ did.
[12:39] <mok0> ripps: is dh creating some kind of weird file name with a space ?
[12:39] <ripps> *shrugs*
[12:40] <ripps> fta is the one who wrote ppa-bot, I know it uses bzr-builddeb, but other than that, i don't really understand the finer points on how it works
[12:40] <mok0> ripps: where does that ">= 2.0.0~git" ... etc come from?
[12:41] <ripps> mok0: that's generated from some git-orig-sourc: stuff
[12:41] <mok0> ripps: hmm
[12:46] <mok0> ripps: looks like you need to talk to fta
[12:47] <ripps> mok0: unfortunely, he always seems to be out or asleep when I'm active :/
[12:47] <mok0> ripps: hehe
[12:55] <c_korn> where can I find the reason why a package has been dropped in Ubuntu ?
[12:56] <c_korn> this package only exists in dapper: http://packages.ubuntu.com/dapper/knowledgetree
[12:56] <mok0> c_korn: there must be a bug in LP
[12:56] <ripps> mok0: woot, adding a blan override_dh_clean: fixed it... something musth be up with it. the ppa-bot might be using a variable with the same name as the dh_auto_clean wrapper uses.
[12:57] <ripps> s/blan/blank/
[12:57] <mok0> ripps: sounds plaucible
[12:57] <mok0> plausible rather
[12:57] <geser> c_korn: https://edge.launchpad.net/ubuntu/+source/knowledgetree/+publishinghistory: (From Debian) RoM; unused and unmaintained
[12:58] <sistpoty|work> nooo, they removed the knowledge tree. No more fruits of knowledge for me :(
[12:58] <sistpoty|work> *g*
[12:59] <mok0> It wasn't even removed, it was autoremoved
[13:00] <sistpoty|work> this doesn't make my joke better though :P
[13:01] <mok0> Au contraire, it makes it spooky
[13:04] <sistpoty|work> heh
[13:06] <mok0> Heh, take a look at this: http://www.wired.com/culture/education/magazine/17-09/st_sinmaps
[13:06] <mok0> OT sorry
[13:22] <c_korn> hm, currently there is no one active in #cmake. so maybe someone here know how to add a library to be added to the linker with cmake. (in make I would just define LDFLAGS="-lc"). there is something called TARGET_LINK_LIBRARIES in cmake but then I would have to find out each target. I just want to add a library to each linker call and let -Wl,--as-needed do the rest
[13:26] <ripps> mok0: I give up, I'm switching to cdbs. It's never given me any issues with my ppa-bot yet.
[13:31] <mok0> ripps: I told ya' :-P
[15:18] <schierbeck> Hi there! I'm trying to package an extremely simple app consisting of 1 shell script -- is there a dead-easy way to do it? The only dependency is "git-core"
[15:18] <schierbeck> It's mainly the rules file I'm nervous about
[15:21] <slytherin> schierbeck: It depends on the way you want to do it - right way or easy way?
[15:23] <schierbeck> slytherin: they can't be the same? :-)
[15:23] <schierbeck> slytherin: I'd rather avoid autotools
[15:24] <slytherin> schierbeck: autotools will not come into picture if you are not using them.
[15:24] <schierbeck> slytherin: perfect! what's the right way then?
[15:24] <joaopinto> schierbeck, a common cdbs rules will do
[15:25] <joaopinto> it's a 2 lines debian/rules, assuming you just need to install the shell script somewhere
[15:25] <slytherin> schierbeck: simplest way will be to have blank 'build' target. and 'binary-indep' target will just include one dh_install command to instal the file in appropriate place.
[15:25] <joaopinto> slytherin, that is complex compared to cdbs :)
[15:26] <slytherin> joaopinto: I know. While I love CDBS, not everyone does. :-)
[15:26] <schierbeck> I've used CDBS a long time ago, so I think it's alright -- which two lines do I need?
[15:27] <joaopinto> #!/usr/bin/make -f
[15:27] <joaopinto> include /usr/share/cdbs/1/rules/debhelper.mk
[15:27] <joaopinto> and that's all, if you need to install, just create a debian/packagename.install with the list of files to install according to dh_install syntax
[15:27] <joaopinto> source_file target_install_dir
[15:28] <schierbeck> e.g. git-ignore bin ?
[15:28] <schierbeck> (my package is called git-ignore)
[15:28] <joaopinto> source_script_path usr/bin ?
[15:29] <schierbeck> joaopinto: can I include usr?
[15:29] <schierbeck> shouldn't I use some env var?
[15:29] <joaopinto> schierbeck, no, install targets are full pathnames
[15:30] <joaopinto> .deb contents are extracted into the root dir
[15:31] <schierbeck> ok, so just "git-ignore /usr/bin"
[15:31] <joaopinto> right
[15:31] <joaopinto> don't forget build-depends on cdbs
[15:32] <schierbeck> joaopinto, slytherin: ok, i'll try to see if it works! thanks!
[15:36] <bddebian> Heya gang
[15:36] <sistpoty|work> hi bddebian
[15:36] <bddebian> Hi sistpoty|work
[15:45] <ulysses__> greetings
[15:48] <schierbeck> joaopinto, slytherin: it works like a charm! thanks, guys! https://edge.launchpad.net/~dasch/+archive/ppa/+packages
[15:49] <joaopinto> schierbeck, yw :)
[15:54] <iulian> Hi bddebian.
[15:56] <bddebian> Heya iulian
[16:54] <RobOakes> Is there anyone who could help a newbie packager figure out digital signing and PPAs?
[16:55] <ScottK> RobOakes: #launchpad is probably a better channel for that.
[16:55] <RainCT> RobOakes: Maybe, just ask
[16:57] <RobOakes> I've got a python source package and was able to successfully get it to compile into an unsigned package using the steps in the Python Tutorial.
[16:57] <RobOakes> dpk-buildpackage -us -uc
[16:58] <RobOakes> I'm not sure what options I need to use so that the package will be signed and ready to upload to a PPA.
[17:00] <RainCT> RobOakes: Use "debuild -S -sa" (without the "-sa" if it's an update of a package that's already there) instead of dpkg-buildpackage. That'll take care of the signing, as long as your name and address is in the newest entry in debian/changelog and matches an existing private key on your system
[17:01] <RobOakes> RainCT, is there a way to specify which private key it should use?
[17:01] <RainCT> RobOakes: yes, -k<your email address or key ID>
[17:01] <RobOakes> Okay.  That seems doable.
[17:02] <RobOakes> So the command would look like: debuild -S -sa -k <Key ID>
[17:03] <RainCT> Yes (if it doesn't try removing the space after the "-k"). (But don't leave stuff with other people's name as uploader if you have changed it. You can get your nam into the changelog by updating it with "dch", as long as you've defined the DEBFULLNAME and DEBEMAIL environment variables correctly).
[17:03] <ScottK> RobOakes: No space between the -k and the keyid
[17:07] <RobOakes> Thanks.  I am updating the change log and putting a tes together now.
[17:11] <RobOakes> Since I know absolutely nothing about ssl, can a package be signed using a PGP key rather than an SSH key?
[17:18] <wrapster> is there a way to check the progress of dpkg-buildpackage?
[17:19] <jdong> it's in progress until you get your shell back.
[17:19] <jdong> but no, more information other than that is buildsys dependent
[17:19] <RainCT> RobOakes: Package are signed with PGP keys, not SSH ones.
[17:19] <jdong> cmake is nice enough to have a percentage display. Otherwise, take a good guess :)
[17:19] <wrapster> jdong: hmm
[17:19] <lfaraone> If I have a package that uses the python cdbs rules, and a new upstream release contains more than one setup.py (one tarball contains separate KDE and GTK frontends), how can I have cdbs put each in its own binary package?
[17:42] <RobOakes> Thanks RainCT, does the type of encryption on the PGP key matter
[17:46] <fabrice_sp> RainCT, can you give me advocation powers in REVU?
[18:36] <sbeattie> is there a motu-sru around who can ack or nack the zsync SRU in bug 420931?
[19:26] <slytherin> anyone using moovida here on karmic?
[19:30] <wrapster> i was able to build binutils successfully with a few changes but they were only reflected in the debian/<pkg>/path/to/changes when i dpkg -i the resulting .deb i was not able to find them?
[19:31] <wrapster> how is it possible? can anyone please help?
[19:44] <wrapster> could anyone answer my question pls
[19:51] <joaopinto> wrapster, are you doing the changes prior to the dh_install call ?
[19:54] <wrapster> joaopinto: well this rules file does not have a dh_install cmd at all..
[19:54] <wrapster> guessing its picked up from somewhere
[19:55] <joaopinto> hum, it's cdbs ?
[19:59] <joaopinto> hello masterkernel, not sure you recevied the message that kernelcheck is no longer able to retrieve the latest kernel source
[20:00] <wrapster> joaopinto: so how do i go ahead and resolve it.. ive tried all i know.. nothing works... im a newbie as well...a bad combo
[20:00] <wrapster> :(
[20:00] <masterkernel> joaopinto: i did get it, it's just that with school and all i have no time to create a patch. i'll be working on one in increments in the following month
[20:01] <joaopinto> ok, np :)
[20:01] <wrapster> joaopinto: what can i do now?
[20:03] <c_korn> wrapster: pastebin the debian/rules please
[20:03] <wrapster> c_korn: its a 780lines file
[20:03] <c_korn> what ???
[20:03] <wrapster> i tried doing it but gave it up
[20:03] <wrapster> yeah
[20:03] <c_korn> please pastebin it, now I am interested
[20:04] <wrapster> c_korn: hee hee... ok
[20:04] <wrapster> will let you know once its done
[20:08] <wrapster> c_korn: http://pastie.org/635497
[20:08] <wrapster> c_korn: here you go
[20:09] <wrapster> c_korn: now can you tell me where the heck if i make my changes will it work? and why?
[20:09] <wrapster> not anywhere else?
[20:09] <wrapster> i was making my changed in the build-indep: by creatating another dependency...
[20:10] <c_korn> holy ...
[20:10] <c_korn> $(install_script) debian/binutils.postinst $(d_bin)/DEBIAN/postinst
[20:10] <c_korn> this debian/rules does not make use of debhelper scripts
[20:11] <wrapster> yeah..
[20:12] <wrapster> so how do i understand where to make my changes?
[20:12] <wrapster> im rusty with scripts that use debhelper itself.. in such cases ... thats all :(
[20:14] <wrapster> could i append another dependency to PHONY and define rule for it hoping it will work?
[20:14] <wrapster> what i want to do is essentially to create symlinks
[20:18] <c_korn> wrapster: try to add dh_link in line 391
[20:19] <wrapster> dh_link there and debian/binutils.lists (<source path> <dest path> )
[20:19] <wrapster> is it so?
[20:20] <c_korn> wrapster: it is debian/binutils.links
[20:20] <wrapster> ok... sorry typo
[20:22] <wrapster> 391 as in --> after the :# Remove windres manpages OR in place of it?
[20:22] <wrapster> i mean below : or above it to make it independent
[20:23] <c_korn> wrapster: line 391 is empty. put it there
[20:24] <c_korn> (I am referring to your pastebin)
[20:24] <wrapster> c_korn: thats what i'm looking at 391 is not empty
[20:24] <wrapster> 390:: # Remove windres manpages
[20:25] <wrapster> 391:rm -f $(d_bin)/usr/share/man/man1/windres.1
[20:25] <c_korn> wrapster: http://pastie.org/635497 line 391
[20:25] <c_korn> the line before: touch install-stamp
[20:26] <wrapster> thats 399 even in the pastie link you provided...
[20:26] <wrapster> :)
[20:26] <wrapster> ok will do that..
[20:28] <c_korn> wrapster: http://www.ubuntu-pics.de/bild/26046/screenshot_001_x2BOgO.png
[20:28] <wrapster> wow.. thats interesting..
[20:29] <wrapster> anyway i've done it at that place itself.. thanks for your efforts in making me understand.. now i only hope it works
[20:41] <wrapster> the build was successful but there was no change ...
[20:41] <wrapster> debian/binutils has nothing created in it
[20:55] <LLStarks> is the ubuntu keyserver down?
[21:00] <ryanakca> LLStarks: I seem to recall someone mentioning it was a known issue yesterday. Try using a different one, they all mirror each other.
[21:32] <ryanakca> RainCT: Thanks for signing
[21:33] <RainCT> ryanakca: no problem :)
[22:06] <RoAk> persia: ping
[22:19] <ajmitch> dtchen: thanks, alsa-driver snapshot is working
[22:34] <ScottK> DktrKranz: Is solang a bugfix only update?
[22:35] <DktrKranz> no, but it has an approved FFe
[22:35] <DktrKranz> too late already?
[22:36] <ScottK> DktrKranz: No.  I didn't see an FFe mentioned in the changelog, but if it has one, that's fine.
[22:37] <DktrKranz> mh, I probably forgot to mention, but the listed bug is the FFe
[22:37] <ScottK> Accepted it.  Thanks.
[22:37] <DktrKranz> thanks you you :)
[22:38] <ScottK> No problem.
[22:49]  * sistpoty falls into bed now... gn8 everyone