[02:55] <c2tarun> can anyone please help me with this error
[02:55] <c2tarun> http://paste.ubuntu.com/572898/
[03:00] <artfwo> c2tarun, are you upgrading a package here?
[03:01] <c2tarun> artfwo: fixing FTBFS
[03:02] <artfwo> well, the patch fails to apply here
[03:03] <c2tarun> artfwo: that is something I dont understand :( I just created a patch refreshed it and poped it and now whn I am building I am getting this error. :(
[03:04] <artfwo> could you show your patch as well?
[03:04] <c2tarun> artfwo: let me tell you few things then may be you understand, the package I am fixing has no patches, I added 3.0 (quilt) to debian/source/format and then I added a new patch by quilt new <patch name> and then the usual steps
[03:05] <c2tarun> artfwo: here is the patch http://paste.ubuntu.com/572900/
[03:06]  * artfwo is looking
[03:19] <artfwo> c2tarun, weird the patch fails to apply indeed
[03:20] <c2tarun> artfwo: why so? i used 3.0 quilt so I didnt made any changes to rules and control file. do you think its right?
[03:20] <artfwo> that's certainly not right
[03:22] <c2tarun> artfwo: so here is the error :( ok, i'll try to read again an make changes to rules and control file
[03:23] <c2tarun> artfwo: thanks for you time
[03:23] <artfwo> I'm not done with the problem yet :)
[03:24] <c2tarun> artfwo: is there anything else :)
[03:26] <artfwo> c2tarun, I cannot figure out what's happening
[03:26] <artfwo> I just tried to patch chaplin.c (simply add a comment to the beginning of the file) and managed to build the package
[03:27] <artfwo> but if I create a patch against makefile, if breaks up
[03:27] <c2tarun> artfwo: oh i think I got this, make file ha no write priviledges except root
[03:27] <c2tarun> wait let me try again
[03:30] <c2tarun> artfwo: sorry I was wrong chaplin.c file is also the same privileges as Makefile :(
[03:30] <artfwo> privileges shouldn't normally be a problem
[03:30] <c2tarun> artfwo: yup :|
[03:31] <Bachstelze> it works fine when I patch the makefile in maverick
[03:31] <Bachstelze> trying in a natty chroot
[03:32] <c2tarun> artfwo: hey on this page its written that we dont have to make any changes to rules and control file in case of 3.0 quilt http://pkg-perl.alioth.debian.org/howto/quilt.html#integrating_with_the_package_build_process please take a look
[03:33] <artfwo> c2tarun, that's right
[03:33] <c2tarun> artfwo: ok so I did right :) there is some other problem if Bachstelze faces the same than something wrong with package
[03:35] <artfwo> c2tarun, I think I found the solution
[03:35] <c2tarun> artfwo: grt... what is it?
[03:35] <artfwo> quilt pop -a
[03:35] <artfwo> while quilt push; do quilt refresh -p ab; done
[03:35] <c2tarun> do you mean executing
[03:35] <c2tarun> quilt refresh -p ab
[03:36] <artfwo> no
[03:36] <artfwo> I mean executing the whole line "while quilt push; do quilt refresh -p ab; done"
[03:36] <c2tarun> artfwo: just like that, on terminal?
[03:36] <artfwo> yes
[03:37] <c2tarun> artfwo: what will it do?
[03:38] <c2tarun> artfwo: its not working, I executed the line and then poped the patch, then I tried to build the source package and hunk failed
[03:38] <artfwo> it will refresh the patches and make them ignore context lines
[03:38] <artfwo> c2tarun, you should execute the command AFTER you've popped the patch
[03:38] <artfwo> and then don't pop your patch again
[03:38] <c2tarun> artfwo: ok wait
[03:39] <artfwo> but just run debuild -S
[03:39] <artfwo> there's a quilt faq on debian wiki. read about your problem here: http://wiki.debian.org/Projects/DebSrc3.0#Iconvertedmypackagebutitfailstobuildorfailstounpackonallbuildds
[03:41] <c2tarun> artfwo: actually what is happneing, the script is refreshing the patch and applying it, after we apply the patch manually its building properly, the problem is occuring if we pop the patch and then try to build the source package
[03:41] <artfwo> but why are you popping the patch when building source package?
[03:42] <c2tarun> because debuild automatically applies it, so it should work both ways, patch pushed and poped.
[03:43] <c2tarun> artfwo: and earlier also if you push the patch then source package was building properly, so I dont find anything new after that script :(
[03:43] <artfwo> oh
[03:43] <artfwo> did you look at the original diff.gz by the way?
[03:44] <c2tarun> artfwo: nope, why?
[03:44] <artfwo> it has its own patch for the makefile
[03:44] <c2tarun> artfwo: can you please tell me how to look at diff.gz?
[03:45] <Bachstelze> ah ah
[03:45] <Bachstelze> that's probably why
[03:45] <artfwo> c2tarun, I usually look at them with midnight commander (package: mc)
[03:45] <Bachstelze> I got the source with apt-get source, so it already applied the .diff.gz
[03:46] <artfwo> c2tarun, perhaps it would be easier to fix the FTBFS by editing diff.gz
[03:47] <c2tarun> artfwo: never done that :( let me try once.
[03:47] <artfwo> c2tarun, I've just opened http://qa.ubuntuwire.com/ftbfs/ and I don't see chaplin there
[03:48] <c2tarun> artfwo: check this http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[03:49] <artfwo> another ftbfs tracker?
[03:49] <c2tarun> artfwo: yup
[03:50] <artfwo> didn't know about this one :)
[03:50] <Bachstelze> yeah, that's it
[03:50] <Bachstelze> (and that, my friend, is why patching source files in .diff.gz is Evil™)
[03:51] <c2tarun> Bachstelze: hmm... any suggestions on what should I do?
[03:52] <Bachstelze> how did you get the source?
[03:53] <c2tarun> Bachstelze: pulled it from natty archive.
[03:53] <Bachstelze> how? just downloaded the .tar.gz and uncompressed it with tar xzf?
[03:53] <c2tarun> Bachstelze: pull-lp-source chaplin
[03:54] <Bachstelze> hmm
[03:55] <Bachstelze> it seems to do tha tsame thing as apt-get source, so you did have a copy with .diff.gz applied
[03:55] <Bachstelze> the same thing*
[03:55] <c2tarun> Bachstelze: yup
[03:55] <Bachstelze> just a sec, I'm waiting for my natty chroot to upgrade
[03:55] <c2tarun> Bachstelze: sure.
[04:03] <artfwo> I don't think it's reasonable to use quilt together with diff.gz here
[04:03] <Bachstelze> indded
[04:03] <Bachstelze> but at least it should work
[04:03] <artfwo> the patch is exactly one-line
[04:03] <Bachstelze> so if it doesn't, something else is wrong
[04:03] <Bachstelze> one thing at a time :)
[04:04] <artfwo> yes, but I think it will be okay, if c2tarun edits diff.gz by adding +LIBS= to the existing Makefile patch
[04:04] <artfwo> it will make things easier for sponsoring, etc.
[04:05] <Bachstelze> no, that would be even dirtier, ultimately, it would be best to get rid of patching in .diff.gz
[04:05] <Bachstelze> and put everything in quilt
[04:05] <artfwo> then c2tarun's job is to move everything from diff.gz to debian/patches :)
[04:06] <Bachstelze> yes, but as I said, one thing at a time :)
[04:07] <Bachstelze> well, it works fine here in natty too
[04:09] <c2tarun> artfwo Bachstelze: sorry I am not getting what you are exactly saying, the patch in diff.gz is the one line updated in Makefile precisely line number 7?
[04:10] <c2tarun> what I am seeing in the source code folder is the second line, it means first line is updated by second. but I guess since this change is not due to any patch in quilt, should I first make a patch that make the change in diff.gz and then my binutils patch?
[04:12] <artfwo> c2tarun, unpack your diff.gz and open it in a text editor - you'll get it.
[04:12] <artfwo> or just open it with midnight commander
[04:12] <Bachstelze> or zless :)
[04:13] <c2tarun> I opened it in vi and i got it :)
[04:14] <c2tarun> what I am not understanding is what do you mean by move everything to patches?
[04:15] <artfwo> c2tarun, your diff.gz contains patches to Makefile and chaplin.c
[04:15] <artfwo> that's considered bad practice
[04:15] <Bachstelze> right now, .diff.gz modifies some source files
[04:15] <c2tarun> artfwo: ya
[04:15] <Bachstelze> that's wrong
[04:16] <Bachstelze> ^
[04:16] <c2tarun> so i should get the orig tarball, make patches for the changes in diff.gz and then pack it?
[04:17] <artfwo> like Bachstelze said, one thing at a time :)
[04:18] <c2tarun> artfwo: one thing at time means like one patch for the change in diff.gz and other for my change?
[04:18] <artfwo> yes
[04:18] <Bachstelze> and also that first we're trying to figure out why yours doesn't apply
[04:18] <Bachstelze> then we can move on to the others
[04:19] <c2tarun> Bachstelze: i guess mine and patch in diff.gz are changing the same line, I followed the quilt so it failed.
[04:19] <Bachstelze> no
[04:19] <Bachstelze> as fat as quilt is concerned, .diff.gz does not even exist
[04:19] <c2tarun> Bachstelze: then?
[04:20] <Bachstelze> quilt comes after .diff.gz has been applied
[04:20] <c2tarun> hmm....'
[04:22] <Bachstelze> c2tarun: how are you building your package?
[04:22] <c2tarun> Bachstelze: debuild -S
[04:23] <Bachstelze> not the source package, the binary
[04:23] <c2tarun> debuild -b
[04:23] <c2tarun> Bachstelze: but source is failing first why go for the binary?
[04:24] <Bachstelze> yeah, never mind :p
[04:27] <Bachstelze> hmm, what's this .pc dir it creates
[04:27] <Bachstelze> ?
[04:27] <Bachstelze> first time I see it
[04:27] <c2tarun> quilt uses it
[04:32] <Bachstelze> I mean
[04:32] <Bachstelze> .pc should be removed when it's not needed, so it shouldn't be there anymore when you run debuild -S
[04:33] <Bachstelze> first time I see it when I run a debuild
[04:33] <Bachstelze> is what I meant
[04:33] <Bachstelze> normally it's always removed before
[04:34] <Bachstelze> maybe the fact that you have source file spatched in .diff.gz is confusing quilt, I guess you should remove those first
[04:34] <c2tarun> well its gets removed automatically I guess, I never removed it in any packages
[04:34] <Bachstelze> me neither
[04:34] <Bachstelze> that's wwy I wonder why it's stil here now
[04:35] <c2tarun> Bachstelze: you created any new patch?
[04:35] <Bachstelze> same as yours
[04:36] <c2tarun> hmm... will it be right if I untar fresh orig.tar and copy debian into it, then I create two patches, first one will fix the change in diff.gz and other one will fix mine (or just one patch with appropriate changes)
[04:37] <Bachstelze> that should work, yes
[04:37] <artfwo> perhaps, dpkg-source has a conflict of 1.0 format and 3.0 format, when packing the package?
[04:37] <Bachstelze> you should do a separate quilt patch for the Makefile and chaplin.c thouhg
[04:38] <c2tarun> Bachstelze: why so? I mean one patch can handle everything
[04:38] <Bachstelze> it's bad practice to put unrelated changes in the same patch
[04:39] <Bachstelze> because what if one of them becomes irrelevant, but the other is still needed?
[04:39] <c2tarun> ok I'll do that :)
[04:45] <Bachstelze> I think it's the fact that the same file is patched both in .diff.gz and in quilt
[04:45] <Bachstelze> that is making dpkg-source fail
[04:49] <c2tarun> Bachstelze: I always struggle in what to write in changelog :( can you please help me a bit, I created two patches one is for chaplin.c and other is for Makefile
[04:52] <Bachstelze> something like "Converted changes in Makefile and chaplin.c from .diff.ge to quilt patches."
[04:53] <c2tarun> Bachstelze: I changed the Makefile in such a way that it includes the change in diff.gz and FTBFS bug simultaneously
[04:53] <c2tarun> Bachstelze: in a single patch :(
[04:53] <Bachstelze> it's best to make separate, they are probably unrelated
[04:55] <c2tarun> Bachstelze: but both the patch will change the same line, do you still think it is necessary to separate them?
[04:55] <Bachstelze> yes
[04:56] <Bachstelze> that's exactly what quilt is for
[04:56] <c2tarun> ok, i'll do it
[04:56] <Bachstelze> since the parches are nicely ordered on a stack, you are sure of the order they will be  applied in
[04:56] <Bachstelze> so no problem editing the same line several times
[05:05] <udienz> tumbleweed, around?
[05:11] <c2tarun> Bachstelze: I changed as you directed, can you please take a look at bug 725645
[05:11] <c2tarun> Bachstelze: I mean take a look at upload I made in that bug
[05:12] <udienz> c2tarun, which log contain ftbfs?
[05:13] <c2tarun> udienz: sorry I didn't uploaded that log, wait i'll upload
[05:13] <udienz> c2tarun, it's better when you write short log that contain error's in bug
[05:14] <c2tarun> udienz: sorry, I'll keep in mind from next time :(
[05:14] <c2tarun> udienz: I uploaded it.
[05:15] <udienz> c2tarun, but if an error in other place you can put links at bug. usually i do it when fixing ftbfs
[05:15] <c2tarun> udienz: If you are looking at it than I should'nt subscribe ubuntu-sponsors?
[05:15] <udienz> c2tarun, np
[05:15] <Bachstelze> c2tarun: it'as also beter to attach a debdiff rather than your .debian.tar.gz
[05:16] <udienz> c2tarun, no, please subscribe ubuntu-sponsors. because i'm not ubuntu-motu right now
[05:16] <c2tarun> udienz: sure,
[05:16] <c2tarun> Bachstelze: I thought to do so but since I changed the diff.gz it was weird. but I'll do it :) wait
[05:16] <Bachstelze> it seems to build fine
[05:17] <c2tarun> Bachstelze: done :) debdiff is uploaded
[05:19] <udienz> c2tarun, take a look at bug 715625, i reported eggcups in lp. i attched an error and debdiff. so other developer can checked very fast
[05:20] <c2tarun> ubottu: wow :) no comments uploaded directly :) cool I'll also post an error log and debdiff from next time
[05:20] <c2tarun> udienz: opps ^^
[05:22] <udienz> c2tarun, seems like it was caused by binutils-gold
[05:22] <udienz> chaplin
[05:22] <c2tarun> udienz: yup and hey I didn't made an entry for updating standards-version in debian/control file in changelog. :(
[05:23] <udienz> c2tarun, i change standrs version because eggcups come from ubuntu
[05:23] <udienz> and not from debian
[05:23] <micahg> c2tarun: standards shouldn't be bumped on packages we import from Debian
[05:23] <c2tarun> udienz: chaplin is also not in debian.
[05:25] <micahg> c2tarun: it originally came from Debian
[05:25] <c2tarun> micahg: but I think now its not in debian :( because rmadison didn't display anything on debian call
[05:26] <micahg> right
[05:26]  * micahg is checking why it was dropped
[05:26] <udienz> c2tarun, right. chaplin isn't in debian yet
[05:26] <micahg> udienz: no, it was originally from Debian 5 years ago
[05:27] <micahg> er, almost 7 actually
[05:27]  * c2tarun wow 7... that time I never heard about linux :(
[05:27] <udienz> micahg, ah.. ok..
[05:27] <c2tarun> micahg: so I shouldn't change the standards-version?
[05:27] <Bachstelze> c2tarun: you should change the version to 1.10-0.2
[05:28] <Bachstelze> not 1build2
[05:28] <micahg> no, it should be 1.10-0.1ubuntu2
[05:28] <micahg> *1.10-0.1ubuntu1
[05:28] <Bachstelze> buildX is added when a package is rebuilt without having been modified
[05:29]  * micahg can't find the removal note either
[05:29] <micahg> c2tarun: no, you can
[05:29] <udienz> http://snapshot.debian.org/package/chaplin/ give me 404
[05:29] <micahg> it's like all traces of its very existence in Debian has been removed
[05:30] <c2tarun> ls
[05:30] <c2tarun> oops , sorry
[05:30] <Bachstelze> the package builds fine, in any case
[05:31] <Bachstelze> but if the package is not in debian anymore, maybe you could take the liberty of fixing all the lintian warnings
[05:33] <c2tarun> Bachstelze: lintian warnings? where are they?
[05:34] <udienz> lintian -I in-file-with.changes
[05:34] <Bachstelze> c2tarun: http://paste.ubuntu.com/572935/
[05:34] <Bachstelze> last one is "normal"
[05:35] <c2tarun> Bachstelze: I am very sorry, I dont know why the first two lintian warnings are there, can you please give me any hint?
[05:36] <Bachstelze> c2tarun: http://lintian.debian.org/tags.html
[05:43] <c2tarun> how can i get the debhelper compatibility version?
[05:43] <artfwo> c2tarun, it's in debian/compat
[05:44] <c2tarun> artfwo: actually its not there :) I got the lintian warning and I have to put in there
[05:45] <artfwo> c2tarun, are you still working on chaplin?
[05:45] <c2tarun> artfwo: yup
[05:45] <artfwo> I have a freshly unpacked source here, and debian/compat is there
[05:46] <artfwo> chaplin-1.10$ cat debian/compat
[05:46] <artfwo> 4
[05:46] <Bachstelze> yes
[05:46] <Bachstelze> and the warning tells you that it's deprecated
[05:46] <Bachstelze> latest is 8
[05:47] <c2tarun> Bachstelze: ok, so I'll update it to 8 and is there anything wrong with this syntax "Depends: ${shlibs:Depends}, ${misc:Depends}"
[05:48] <artfwo> that's right syntax
[05:48] <artfwo> original package didn't have {misc:Depends}
[05:48] <c2tarun> artfwo: what do you mean? I am not getting
[05:49] <artfwo> what does lintian say to you?
[05:49] <c2tarun> artfwo: W: chaplin source: debhelper-but-no-misc-depends chaplin
[05:49] <artfwo> there
[05:50] <artfwo> you don't have ${misc:Depends} in debian/control
[05:50] <artfwo> it's all described in http://lintian.debian.org/tags/debhelper-but-no-misc-depends.html
[05:51] <artfwo> c2tarun, also make sure to read debhelper manpage, before you bump debian/compat to 8
[05:52] <artfwo> it describes all the compability levels in detail
[05:53] <micahg> can someone makes sure the package still works before putting all this work into it?
[05:55] <udienz> micahg, is fixing ftbfs allowed now?
[05:55] <micahg> udienz: yes
[05:56] <c2tarun> artfwo: I am not sure that this package satisfies the compatibility level of more than 4. What should I do?
[06:00] <artfwo> c2tarun, I'd suppose you should set debian/compat to the maximum possible value, but CHECK with debhelper(7) first, that all is okay
[06:06] <udienz> micahg, what is rpath? (i see your comments in gkamus @revu)
[06:10] <c2tarun>  I think maximum possible value is 4 :/ I made some changes and uploaded a new debdiff on bug 725645 Can you please take a look
[06:14] <artfwo> c2tarun, looks good
[06:14] <artfwo> I see you've bumped Standards-Version to 3.9.1
[06:14] <artfwo> but why do you think maximum value for debian/compat is 4?
[06:17] <micahg> udienz: it's where the executable hard codes a path to a library
[06:20] <jmarsden> artfwo: man chrpath   # for a utility to let you see rpaths and mess with them after the fact.
[06:21] <jmarsden> oops, that was udienz ^^
[06:27] <udienz> micahg, jmarsden, thanks. i change gkamus library location into /usr/lib rather than /usr/share/gkamus in d/rules
[06:50] <c2tarun> artfwo: honestly I am not actually getting this facts about debhelper, I tried to increase the version and on each increase I was getting more lintian warning :(
[06:52] <artfwo> a good chance to fix 'em all, eh? :)
[06:52] <artfwo> ask specific questions about your warnings, and we will try to help ;)
[06:54] <c2tarun> artfwo: this warning I got while building source package W: chaplin source: dh-clean-k-is-deprecated
[06:55] <artfwo> that's pretty obvious one
[06:55] <artfwo> http://lintian.debian.org/tags/dh-clean-k-is-deprecated.html
[06:55] <artfwo> replace it with dh_prep and you're set
[06:56] <artfwo> (and don't forget to document every change in debian/changelog)
[06:56] <c2tarun> sure
[07:03] <c2tarun> artfwo: I got this warning W: chaplin: copyright-without-copyright-notice how can I get the copyright info?
[07:03] <artfwo> c2tarun, have you read http://lintian.debian.org/tags/copyright-without-copyright-notice.html ?
[07:04] <c2tarun> artfwo: yup, but I dont knw how to get unicode C symbol and other informations?
[07:04] <artfwo> you don't need the unicode symbol at all
[07:05] <c2tarun> artfwo: and YYYY-YYYY information?
[07:05] <artfwo> Copyright 2004 Firstname Lastname <address@example.com> will be sufficient for lintian
[07:05] <artfwo> woah
[07:05] <c2tarun> BTW what is 2004?
[07:06] <artfwo> year 2004
[07:06] <jmarsden> A year :)
[07:06] <c2tarun> I mean year of what :)
[07:06] <jmarsden> The year the thing was copyrighted :)
[07:07] <jmarsden> AD, Anno Domini, or CE is assumed :)
[07:07] <artfwo> c2tarun, I picked the date from chaplin.c
[07:07] <artfwo> but you can contact the upstream author to be sure
[07:11] <c2tarun> artfwo: what about binary-without-manpages? What can I do?
[07:12] <artfwo> c2tarun, a) ignore the warning or b) write a manpage
[07:12] <c2tarun> artfwo: I'll choose a) :) and after this there is no other warning
[07:19] <c2tarun> artfwo: I uploaded a new debdiff can you please take a look bug 725645
[07:20] <artfwo> c2tarun, looks good to me
[07:21] <c2tarun> artfwo: can you sponsor?
[07:21] <artfwo> I cannot, I'm not even a MOTU yet :)
[07:36] <c2tarun> !dpatch
[07:38] <c2tarun> which patching system is better? quilt or dpatch?
[07:39] <artfwo> c2tarun, dpatch is considered deprecated to my knowledge
[07:40] <c2tarun> artfwo: if any package is using it, should we convert it to quilt?
[07:40] <artfwo> generally, yes
[07:41] <c2tarun> ok
[07:41] <artfwo> but if you're working on an existing package, try to keep difference to a minimum
[07:42] <c2tarun> its weird there are two folder inside debian, one is patched and other is patches. patched contains pa .h.patch file with information of which file to patch and patches is somewhat similar to quilt's debian/patches
[07:42] <artfwo> which package it is?
[07:43] <c2tarun> ivtv-utils
[07:45] <artfwo> well, this package is maintained in debian and doesn't have an ubuntu version
[07:45] <c2tarun> yup, I got this from one ftbfs tracker.
[07:45] <c2tarun> artfwo: it failed to build natty machine
[07:45] <artfwo> I'd keep the patch as tiny as possible then
[07:47] <c2tarun> hmm.. since it is maintained it debian we cannot change it to quilt? I have to learn using dpatch?
[07:47] <artfwo> we can, but this will be a sponsored upload
[07:48] <artfwo> it is easier for a sponsor to work with simple patch, rather than a fully converted package
[07:48] <artfwo> you can also patch the package in debian
[07:48] <c2tarun> artfwo: what if debian released a new version. our different patch system may create problem for autosync
[07:48] <artfwo> right
[07:49] <c2tarun> artfwo: so I'll read dpatch manual first :0
[07:49] <c2tarun> :)
[08:16] <c2tarun> artfwo: can you please look at this error http://paste.ubuntu.com/572968/
[08:17] <artfwo> looking
[08:18] <artfwo> why do you think it fails to build? :)
[08:18] <c2tarun> in line 27 -lm should be at the end
[08:18] <c2tarun> artfwo: ^^
[08:18] <artfwo> in fact, the error is in lines 29-30
[08:19] <artfwo> -lm is only an instruction to link with libm
[08:19] <artfwo> it can be anywhere in the linker command line
[08:20] <c2tarun> artfwo: thats the prob :( I am not able to find where it is
[08:20] <artfwo> you cannot locate the function 'log'?
[08:20] <c2tarun> artfwo: nope :) I cannot locate the Makefile in which I have to make change to remove this error
[08:22] <artfwo> but what are you going to do once you find the Makefile?
[08:23] <c2tarun> artfwo: the error is because ivtv-pcm-tester.c is using log function from libm library. its linker is -lm. I just have to move linker to the end of the line and it will compile
[08:24] <artfwo> your makefile is test/Makefile
[08:25] <artfwo> but it already includes LDFLAGS=-lm
[08:25] <c2tarun> but where is this LDFLAGS is used :( that will the place where I have to make change
[08:26] <artfwo> well, make uses it automatically
[08:26] <c2tarun> what? than how can I solve this error?
[08:27] <artfwo> don't know, let's try to figure out :)
[08:27] <c2tarun> sure :)
[08:27] <artfwo> Did you successfully compile utils/ivtv-ctl.c?
[08:28] <artfwo> it throws almost the same error on my system
[08:28] <artfwo> ivtv-utils-1.4.1/utils/ivtv-ctl.c:192: undefined reference to `ceilf'
[08:28] <artfwo> collect2: ld returned 1 exit status
[08:28] <c2tarun> artfwo: yup, I moved -lm to the end in utils/Makefile line number 23
[08:29] <artfwo> so you may as well create a simular rule in test/Makefile
[08:30] <artfwo> something like:
[08:30] <artfwo> ivtv-pcm-tester: ivtv-pcm-tester.o
[08:30] <artfwo>     $(CXX)  -lm -o $@ $^
[08:31] <c2tarun> artfwo: hey can you please tell me what is @ and ^ here?
[08:32] <artfwo> c2tarun, http://tldp.org/LDP/abs/html/internalvariables.html#APPREF2
[08:32]  * c2tarun reading
[08:33] <artfwo> sorry, missed your last line :)
[08:33] <artfwo> I'm affected by bug 60527
[08:38] <artfwo> c2tarun, this makefile just worked for me http://paste.ubuntu.com/572977/
[08:38] <artfwo> but I still don't understand why LDFLAGS have been ignored
[08:39] <c2tarun> artfwo: cool :) shall I use it?
[08:39] <artfwo> of course, but I think it's not the best solution
[08:39] <c2tarun> artfwo: why so?
[08:40] <artfwo> LDFLAGS=-lm is present in the Makefile, but it's ignored at the linking stage
[08:40] <artfwo> something surely is wrong
[08:41] <udienz> it must be LIBS to adding library linker
[08:41] <artfwo> udienz, I tried to build it with LIBS, it also failed
[08:42] <udienz> artfwo, is the package have configure.in? some package declaring LIBS/LDFLAGS,etc in configure.in
[08:42] <artfwo> udienz, no it only uses handwritten Makefiles
[08:42] <c2tarun> artfwo: what do you mean LIBS not working?
[08:43] <c2tarun> artfwo: I mean after using LIBS did you remove LDFLAGS?
[08:43] <udienz> artfwo, which package?
[08:43] <artfwo> udienz, ivtv-utils
[08:43] <artfwo> c2tarun, right
[08:43] <c2tarun> artfwo: why?
[08:43]  * udienz looking ivtv-utils
[08:44] <artfwo> c2tarun, it's a convention to enumerate libraries like -lm in $LIBS
[08:45] <c2tarun> artfwo: this makefile is working http://paste.ubuntu.com/572982/
[08:45] <c2tarun> artfwo: in this I commented LDFLAGS, how come yours not working?
[08:45] <artfwo> of course, since you explicitly put $LIBS in the end of your linking rule
[08:46] <c2tarun> artfwo: well we have to do that isnt it? without using LIBS how can it compile? :/
[08:46] <artfwo> forget about LIBS :)
[08:47] <artfwo> your program isn't using autotools, so LIBS is irrevelant here
[08:47] <c2tarun> artfwo: autotools? :( what are they?
[08:47] <artfwo> c2tarun, autoconf, automake, libtool, etc.
[08:48] <c2tarun> artfwo: so what final Makefile do you suggest?
[08:48] <c2tarun> artfwo: the one with LIBS or one with LDFLAGS?
[08:48] <udienz> artfwo, $(CXX) -lm -o $@ $^ it must be $(CXX) -o $@ $^ $(LIBS)
[08:48] <artfwo> LIBS is not commonly used with Makefiles
[08:48] <udienz> or $(CXX) -o $@ $^ -lm
[08:49] <artfwo> http://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
[08:49] <c2tarun> udienz: that is the first error, fix it and you'll get other one, that is our problem
[08:49] <udienz> c2tarun, what an error then?
[08:50] <c2tarun> udienz: you are right, go on fix your first error. U'll get another one on building
[08:54] <c2tarun> artfwo: I'll stick with your makefile than, but what about the problem that why LDFLAGS is ignored?
[08:56] <c2tarun> udienz: you found other error?
[08:59] <udienz> c2tarun, not yet, i'll uploading it into my ppa
[09:01] <udienz> c2tarun, http://paste.ubuntu.com/572984/
[09:03] <c2tarun> udienz: why u changed all lines of utils/Makefile?
[09:04] <udienz> c2tarun, because a library must placed after object
[09:04] <c2tarun> udienz: your patch is really good, I think you should file a bug and upload this patch.
[09:07]  * c2tarun dpatch really is annoying :( quilt is really good. all the compiles I did after applying the patch are recorded in patch ^_^
[09:08] <azeem> hrm?
[09:10] <udienz> c2tarun, feel free to take. but o still got an errors. seems like we must adding LIBS into Makefile
[09:10] <udienz> c2tarun, to make/edit dpatch you can use edit-patch in ubuntu-dev-tools package
[09:11] <c2tarun> udienz: what error is still there?
[09:11] <udienz> c2tarun, http://launchpadlibrarian.net/65227773/buildlog_ubuntu-natty-amd64.ivtv-utils_1.4.1-1ubuntu1_FAILEDTOBUILD.txt.gz
[09:14] <c2tarun> udienz: you are getting the same error which I was talking about, here this makefile fixes your error http://paste.ubuntu.com/572982/ but I am not sure about the variable naming convention.
[09:16] <udienz> c2tarun, very good. do you tested? and building is fine?
[09:16] <c2tarun> udienz: yup its working :)
[09:17] <c2tarun> I just have to make the whole patch again, can you believe whole application is of 800KB and my patch alone is of 3.0+ MB :/
[09:17] <udienz> c2tarun, great!
[09:18] <udienz> c2tarun, maybe you make a mistake during make a patch
[09:18] <c2tarun> udienz: I just compiled countless times inside the patch :(
[10:53] <nonix4> Is it a bug for a program to be setuid-root when it does not need that? For example rephrase drops privs after mlock(for less than 64k) and setreuid at beginning.
[11:39] <ari-tczew> what do you think about upgrading QA stuff in FFe?
[11:39] <ari-tczew> Standards-Versions, debhelper, lintian errors etc.
[11:40] <c_korn> what tool executes get-orig-source ?
[11:43] <azeem> c_korn: it is supposed to be run manually I believe
[11:44] <azeem> or possibly as part of some meta-building tool
[11:44] <c_korn> ok
[11:44] <c_korn> thanks
[11:58] <c2tarun> !ftbfs
[13:27] <c2tarun> Whats the difference between a Makefile and Makefile.in?
[13:29] <Ampelbein> c2tarun: Makefile.am and Makefile.in are processed by automake and configure to create the Makefile
[13:30] <c2tarun> Ampelbein: Makefiles are created automatically?
[13:30] <Ampelbein> c2tarun: depending on the buildsystem used, they can be.
[13:31] <c2tarun> Ampelbein: where can I know more about makefiles?
[13:32] <Ampelbein> c2tarun: http://www.gnu.org/software/hello/manual/automake/Autotools-Introduction.html for a general introduction to the autotools
[14:24] <ari-tczew> bdrung_, tumbleweed: around?
[14:24]  * tumbleweed is
[14:25] <ari-tczew> tumbleweed: I'd like to request new script for ubuntu-dev-tools and I have it done. Which branch should be merge proposed?
[14:26] <tumbleweed> lp:ubuntu-dev-tools
[14:26] <ari-tczew> OK.
[14:26] <tumbleweed> it needs a manpage, entry in debian/copyright, and a line in debian/control, and setup.py
[14:31] <ari-tczew> tumbleweed: what do you think, name for script 'switch-to-3.0-source-format' is OK?
[14:33] <ari-tczew> 'switch-3.0-source-format *
[14:34] <tumbleweed> is that a complex enough task to need a script?
[14:34] <tumbleweed> the name's a bit long, but I don't have any better suggestions. switch might also be the wrong word
[14:35] <ari-tczew> tumbleweed: small script, but would be nice to have, always any automation
[14:36] <ari-tczew> tumbleweed: convert is better than switch ?
[14:37] <tumbleweed> yeah a bit
[14:38] <ari-tczew> tumbleweed: maybe convert-3.0-quilt ?
[14:38] <tumbleweed> that's a better length
[14:42] <ari-tczew> tumbleweed: do I need to add myself to d/copyright?
[14:42] <geser> why not get that script into devscripts? It doesn't sound Ubuntu-specific
[14:43] <ari-tczew> geser: because I'd like to get it into ubuntu-dev-tools
[14:43] <geser> that shouldn't be a reason
[14:44] <ari-tczew> as everything
[14:46] <tumbleweed> ari-tczew: geser has a good point
[14:46] <geser> especially as bdrung is working on restructuring u-d-t (https://lists.ubuntu.com/archives/ubuntu-devel/2011-January/032357.html)
[14:47] <geser> adding new scripts to u-d-t which are better placed in devscripts won't help him finish this target
[14:50] <ari-tczew> geser, tumbleweed: can I use git for send my patch?
[14:55] <ari-tczew> debian bug 599777 roxx
[15:11] <ari-tczew> requestsync failed. http://pastebin.ubuntu.com/573084/
[15:12] <ari-tczew> geser: ^^
[15:13] <geser> ari-tczew: LP oops'ed, I will forward it there
[15:13] <geser> ari-tczew: and requestsync also needs porting to the new python-launchpadlib (as you can see in your paste it tries to file it on staging), IIRC someone is working on it
[15:14] <ari-tczew> ahs
[15:14] <c2tarun> ari-tczew: ping
[15:14] <ari-tczew> c2tarun: pong
[15:15] <c2tarun> ari-tczew: hello :) I need to ask something about your comment on bug 725645
[15:16] <ari-tczew> tumbleweed: sometimes I have to deal with branches which has got UNRELEASED target in d/changelog. sponsor-patch shows warning that it's impossible to upload. is it a way to get changes UNRELEASED to natty via sponsor-patch?
[15:16] <ari-tczew> c2tarun: just ask
[15:17] <c2tarun> ari-tczew: you said to check whether package is removed from debian and ubuntu, can you please tell me how to check that?
[15:18] <tumbleweed> c2tarun: you can see the package's state in Debian on it's pts page: packages.qa.debian.org/chaplin
[15:18] <tumbleweed> rmadison is also useful
[15:18] <tumbleweed> ari-tczew: yes, sponsor-patch could call dch -r
[15:19] <tumbleweed> geser: err yes, that someone is me, but the heat this weekend hasn't been very condusive to work
[15:19] <c2tarun> tumbleweed: if a patch is removed by debian should we remove it from ubuntu as well?
[15:20] <ari-tczew> if package has been removed from debian, automatic patch as well...
[15:20] <tumbleweed> c2tarun: chaplin has never been in Debian.
[15:21] <tumbleweed> it actually came from debian-multimedia
[15:21] <c2tarun> tumbleweed: micahg said that it was in debian 5-6 years ago
[15:22] <tumbleweed> c2tarun: http://debian-multimedia.org/dists/unstable/main/binary-amd64/package/chaplin.php
[15:22] <tumbleweed> debian-multimedia is not Debian
[15:23] <micahg> ah, that's why I couldn't find it :)
[15:23] <tumbleweed> micahg: the uploader was the giveaway :)
[15:24]  * micahg obviously doesn't know enough about debian multimedia
[15:24] <micahg> tumbleweed: can we sync from there?
[15:24] <ari-tczew> micahg: nope
[15:24] <ari-tczew> micahg: ftbfs
[15:24] <tumbleweed> micahg: I doubt we can automatically, I've actually never done it myself
[15:25] <tumbleweed> but we do have quite a few packages from there
[15:25] <tumbleweed> (anyone who used Debian on the desktop a few years ago will know about debian-multimedia.org, but I think these days most things one needs are in the main archive)
[15:25] <ari-tczew> c2tarun: so you can't change anything unnecessary. just patch directly Makefile as I suggested on bug comment and send it to maintainer
[15:26] <c2tarun> ari-tczew: unnecessary changes means?
[15:26] <ari-tczew> c2tarun: all apart from fix FTBFS
[15:27] <ari-tczew> c2tarun: It's just resync on Debian multimedia.
[15:27] <c2tarun> ari-tczew: hmm.... I was suggested that since the package is not in debian, we should try to fix all lintian errors
[15:27] <ari-tczew>  *build1 is just no-change rebuild
[15:27] <ari-tczew> c2tarun: it is in debian multimedia
[15:27] <ari-tczew> and it has got maintainer
[15:28] <c2tarun> ari-tczew: ok, so I should just make a patch to fix FTBFS and send it to maintainer?
[15:29] <ari-tczew> c2tarun: That's right.
[15:29] <ari-tczew> c2tarun: don't change patch system as well
[15:29] <c2tarun> ari-tczew: actually there was no patch system. only few changes in diff.gz
[15:30] <ari-tczew> c2tarun: You introduced 3.0 source format in your debdiff.
[15:31] <c2tarun> ari-tczew: yup, just because there was no patch system, to create a patch I have to follow any system, so I used 3.0 quilt
[15:33] <ari-tczew> c2tarun: I understand.
[15:35] <c2tarun> ari-tczew: so at least I have to follow a patch? :( and little bit about LIBS, I dont understand why can't I use LIBS?
[15:36] <ari-tczew> c2tarun: Because it's wrong. Just move -ldvdread.
[15:36] <ari-tczew> do it
[15:38] <c2tarun> ari-tczew: but I need a patch for changes in chaplin.c and Makefile already mentioned in diff.gz otherwise my FTBFS patch for Makefile will fail.
[15:38] <ari-tczew> c2tarun: no
[15:38] <ari-tczew> c2tarun: get last source files from debian multimedia
[15:39] <ari-tczew> c2tarun: dget http://debian-multimedia.org/pool/main/c/chaplin/chaplin_1.10-0.2.dsc
[15:39] <ari-tczew> c2tarun: dpkg-source -x *0.2.dsc
[15:39] <ari-tczew> c2tarun: go to packaged directory
[15:40] <ari-tczew> dch -i
[15:40] <ari-tczew> write what did you change
[15:40] <ari-tczew> save
[15:40] <ari-tczew> run update-maintainer
[15:40] <ari-tczew> edit Makefile and move -ldvdread at the end
[15:40] <ari-tczew> that's all
[15:41] <c2tarun> ari-tczew: no patches for changing Makefile, should I change Makefile directly?
[15:42] <ari-tczew> c2tarun: yes
[15:42] <c2tarun> ari-tczew: ok, than this will work. Ok. after compiling I should just create the debdiff and send it to maintainer?
[15:44] <ari-tczew> c2tarun: yes
[15:44] <c2tarun> ari-tczew: ok, i'll do.
[15:50] <c2tarun> ari-tczew: here is the debdiff file, can you please take a look http://paste.ubuntu.com/573089/
[15:52] <ari-tczew> c2tarun: beautiful. However, I'm not sure whether in debug it's needed. without debug, buils fine
[15:53] <c2tarun> ari-tczew: so what should I do now?
[15:54] <ari-tczew> c2tarun: I think that it won't hurt if debug is changes as well, I'll upload it. Please send patch to Christian. You can encourage him to upgrade QA stuff which you did first time, so Standards-Version, debhelper 8, DEP5 for d/copyright etc.
[15:55] <c2tarun> ari-tczew: sorry but I dont understand what do you mean by debug?
[15:55] <ari-tczew> c2tarun: look into your debdiff
[15:55] <ari-tczew> and you will get know
[15:57] <c2tarun> ari-tczew: got it :)
[15:58] <c2tarun> ari-tczew: by sending patch to Christian, what patch do you mean exactly?
[15:58] <ari-tczew> c2tarun: changes on Makefile. just copy it from debdiff.
[16:08] <ari-tczew> c2tarun: delete old debdiff on the bug and attach correct
[16:09] <c2tarun> ari-tczew: ok, sure
[16:11] <c2tarun> ari-tczew: done :)
[16:13] <ari-tczew> c2tarun: Thanks, Will do later.
[16:18] <c2tarun> there is package name kic in ftbfs tracker list, how should I check its existence in debian and whether I should work on it?
[16:21] <c2tarun> can anyone please help me with this error http://paste.ubuntu.com/573099/
[16:46] <bdrung_> ari-tczew: if sponsor-patch complains about the series, you can go into the edit mode and set the series
[16:49] <ari-tczew> c2tarun: try to play with -lX11
[16:50] <c2tarun> ari-tczew: tried a lot :( the problem is Makefile is being generated during building, so any changes made by me is lost on next build.
[17:05] <c2tarun> ari-tczew: tried a lot :( the problem is Makefile is being generated during building, so any changes made by me is lost on next build.
[17:06] <ari-tczew> c2tarun: why did you wrote the same again?
[17:06] <c2tarun> ari-tczew: sorry :( I got disconnected for sometime, I thought I missed your reply.
[17:07] <ari-tczew> c2tarun: If I don't reply it doesn't mean that I missed.
[17:07] <c2tarun> ari-tczew: no I thought that may be you replied when I was disconnected :P
[17:11] <ari-tczew> c2tarun: Try to call LIBS with -lX11 in d/rules.
[17:13] <c2tarun> ari-tczew: nope, not working, same set of errors
[17:13] <ari-tczew> c2tarun: so leave it
[17:13] <c2tarun> ari-tczew: leave it means? leave the package or leave the change in rules?
[17:14] <ari-tczew> c2tarun: leave the package
[17:14] <c2tarun> ari-tczew: ok
[17:15] <c2tarun> ari-tczew: can you please suggest me some ftbfs packages to work on?
[17:16] <ari-tczew> c2tarun: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[17:16] <ari-tczew> a wide range of choices
[17:27] <ari-tczew> c2tarun: btw. you can open a bug on BTS against kic, related to FTBFS with binutils-gold/ no-add-needed.
[17:31] <c2tarun> ari-tczew: ok, i'll do that
[17:36] <geser> c2tarun: for that FTBFS you have to find the library which provides those symbols
[17:37] <c2tarun> geser: in the case of kic I think the library is -lX11 problem is I dont where to make changes?
[17:40] <geser> one moment, looking
[17:43] <geser> c2tarun: the problem is the "-L" without any path
[17:44] <geser> I'm not fully sure but I guess the -lX11 gets treated as the argument for -L
[17:45] <c2tarun> geser: the line in the error is from a makefile that is being created on buildtime :( I dont know where to make changes to -L
[17:46] <geser> you have to go backwards: Makefile gets created from Makefile.in, so look there first
[17:47] <geser> as this gets passed through $(LIBS) figure out who sets it
[17:47] <geser> as Makefile.in doesn't hardcode it, it comes from configure/configure.in
[17:47] <c2tarun> geser: I looked, all I was able to figure out is there is file configure which is creating all the Makefiles :(
[17:51] <geser> unfortunately I don't have time currently to look at configure/configure.in and seeing what's broken
[17:53] <c2tarun> geser: np, meanwhile I am working on another package, just ping me if you get time :) thanks
[18:31] <fabrice_sp> ScottK, Hi. I was going to upload boost-mpi-source1.42_1.42.0-4ubuntu2 (to fix uninstallability of libs), and was thinking aobut adding the non-versioned dev packages that has been dropped from boost-defaults (libboost-mpi-dev, libboost-mpi-python-dev and libboost-graph-parallel-dev). What do you think about it?
[18:32] <ScottK> fabrice_sp: As long as you can make it work so those binaries land in Universe, I think it's a great idea.
[18:34] <fabrice_sp> ScottK, ok. Thanks!
[19:17] <ari-tczew> wgrant: where can I find last rebuild test?
[19:27] <c2tarun> I run rmadison on a package for debian an got hppa. What is it?
[19:29] <Ampelbein> c2tarun: a processor architecture like i386 or amd64
[19:38] <c2tarun> why some linkers in libraries start from L not l? I mean like -Llib I googled this and first time google failed to give any result :/
[19:39] <Bachstelze> c2tarun: -L<dir> means that ld will search for libraries in the given dir
[19:39] <Bachstelze> -l<lib> means it will lik the given lib
[19:39] <Bachstelze> totally different
[19:39] <Bachstelze> link*
[19:41] <c2tarun> Bachstelze: g++ -o atom4 atom4.o interface.o obj/event.o obj/textui.o -Lproglib/lib -Llib -L/usr/X11R6/lib -lt++ -lpanel -lncurses -lX11 -lXpm -latom4 -lxatom4  this line was giving an undefined reference error. Why?
[19:43] <Bachstelze> c2tarun: for statrters, the -L flags should be before -o
[19:44] <Bachstelze> and if it still gives undefined reference, probably the -l flags are in the wrong order
[19:46] <c_korn> what package contains debug symbols of /lib64/ld-linux-x86-64.so.2 ?
[19:54] <Ampelbein> c_korn: usually the -dbgsym or -dbg version of the package the file is in.
[20:07] <ari-tczew> c2tarun: please use DEP3 tags in patches
[20:08] <c2tarun> ari-tczew: what are DEP3 tags?
[20:09] <ari-tczew> c2tarun: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#Patch%20Tagging%20Guidelines
[20:09] <ari-tczew> !dep3
[20:09] <ari-tczew> !ftbfs
[20:09] <jmarsden> http://dep.debian.net/deps/dep3/
[20:10] <ari-tczew> why this silly bot doesn't know that pretty easy things
[20:10] <jmarsden> ari-tczew: You can propose new factoids if you think they will be useful -- do so, instead of complaining :)
[20:10] <ari-tczew> or rather essential
[20:11] <ari-tczew> jmarsden: last time when I talked about !ftbfs someone told me that it doesn't need to be handled by bot o_O
[20:11] <ari-tczew> everything should be easy for new contributors
[20:11] <ari-tczew> don't make mountains for their start
[20:12] <ari-tczew> but what I know...
[20:12] <jmarsden> Yes, I'd write a factoid and submit it and see what happens... I forget exactly where to do that for the ubottu bots though.
[20:15] <c2tarun> ok, the guide was good, can you please tell me a example of any patch on any bug on LP that follows dep3? this will help me a lot
[20:17] <c2tarun> sorry got disconnected again :( any examples?
[20:22] <ari-tczew> damn, {{{ }}} doesn't work on new wiki anymore
[20:22] <ari-tczew> anyone has got other solutions for {{{ ?
[20:24] <jmarsden> Which wiki?  https://wiki.ubuntu.com ?
[20:24] <ari-tczew> jmarsden: yes
[20:25] <jmarsden> That would be nuts, they'd have to fix up hundreds of existing wiki pages that use it...
[20:25] <ari-tczew> jmarsden: have you got something to replace it?
[20:26] <jmarsden> https://wiki.ubuntu.com/HelpOnMoinWikiSyntax?action=show&redirect=SyntaxReference#Verbatim%20Display  says it should still work.
[20:32] <ari-tczew> jmarsden: heh, it's hard to preview changes if edit mode bases on old wiki ubu theme.
[20:32] <ari-tczew> absurd
[20:33] <jmarsden> I think the old wiki -> new wiki transition is... still somewhat in progress :)
[22:45] <verwilst> hello
[22:45] <verwilst> i'm messing up my ppa's, anyone care to help :)
[22:46] <Ampelbein> verwilst: just ask ;-)
[22:46] <verwilst> i wanted to rename my ppa, but since that doesn't work, i wanted to delete and create a new one with another name but with the same packages :)
[22:46] <verwilst> Ampelbein, i was :)
[22:46] <verwilst> so now i have 2 deleted ppa's..
[22:46] <verwilst> ( i also deleted the one i wanted to keep :P )
[22:46] <verwilst> with the new name :)
[22:47] <verwilst> i created another ppa then, but trying to reupload my packages now results in 'Package has already been uploaded to ppa on ppa.launchpad.net'
[22:48] <Ampelbein> verwilst:  that's the dput error I guess?
[22:49] <verwilst> yes, sorry
[22:49] <Ampelbein> verwilst: just remove the .upload file and try again
[22:49] <Ampelbein> or use dput -f
[22:50] <verwilst> heh :)
[22:50] <verwilst> thanks :) i thought it was a server message
[22:50] <verwilst> also, is there a way to really get rid of the old ppa's?
[22:50] <verwilst> they're greyed out now
[22:50] <verwilst> i want em totally gone :d
[22:51] <Ampelbein> verwilst: I don't think so, you could ask in #launchpad if there is a way.
[22:57] <verwilst> Ampelbein, thanks, asking there
[22:57] <verwilst> "make: dh_autotools-dev_restoreconfig: Command not found" .. hm, a new tool in debian sid?
[22:57] <verwilst> which is not in lucid?
[22:59] <Ampelbein> verwilst: yes, maverick has it
[22:59] <verwilst> i commented it out and the dsc built successfully, no idea what i broke though :P
[23:00] <Ampelbein> verwilst: something about config.sub and .guess
[23:01] <Ampelbein> verwilst: but I don't really know what it does
[23:01] <verwilst> Ampelbein, so nothing too serious then
[23:02] <Ampelbein> verwilst: nah, maybe you will break the buildfarm by uploading, but nothing big ;-)
[23:02] <verwilst> :)
[23:03] <verwilst> we'll soon find out ;)
[23:05] <lesliev> hi people! I am following daniel holbach's package building tutorials and have a question or two
[23:05] <lesliev> in his tutorial you build with: debuild -S -sa       -- why build a source only package?
[23:05] <lifeless> because binary uploads are rejected in Ubuntu
[23:05] <lifeless> they cannot be audited
[23:06] <Ampelbein> lesliev: because the building of the binary package is done on the launchpad buildfarm
[23:06] <lifeless> and thus cannot be trusted
[23:06] <lesliev> oh so you will always build source packages and the build farm will take care of making binaries?
[23:06] <Ampelbein> yes
[23:07] <lesliev> ok thanks
[23:07] <verwilst> isn't there some bugreport i can vote on to enable reactivating/renaming ppa's? :)
[23:07] <lesliev> once I have run debuild  I often want to change something and run debuild again
[23:08] <lesliev> will it just replace the files it has created?
[23:08] <Ampelbein> lesliev: yes, the "clean:" rule in debian/rules  takes care of "resetting" the work directory to a clean state
[23:09] <lesliev> great. once I am done, I run pbuilder to make the actual deb. it makes a bunch more files too. is everything I need actually in the deb?
[23:10] <Ampelbein> yes, it should be. the deb-file is the actual package and is what is being downloaded if you run "apt-get install foo".
[23:11] <lesliev> except what I built is a source package
[23:11] <lesliev> what is the .dsc file for?
[23:11] <Ampelbein> no, a source package never results in a .deb file
[23:12] <Ampelbein> but if you use pbuilder it will build a binary package that you can install locally. you just can't use it to distribute via launchpad.
[23:12] <lesliev> after pbuilder has run I have this in the results directory:
[23:12] <lesliev> ed_1.5-0ubuntu1.debian.tar.gz  ed_1.5-0ubuntu1_i386.changes  ed_1.5.orig.tar.gz
[23:12] <lesliev> ed_1.5-0ubuntu1.dsc            ed_1.5-0ubuntu1_i386.deb
[23:13] <lifeless> verwilst: you're welcome to file one.
[23:13] <StevenK> lesliev: The .dsc ties the orig and the debian diff together
[23:13] <Ampelbein> dsc = debian source control, it describes what orig.tar.gz and diff belong together
[23:14] <lesliev> aha. so what gets uploaded after pbuilder has run?
[23:15] <StevenK> lesliev: The .changes files
[23:15] <StevenK> Well, not exactly
[23:15] <StevenK> Since that .changes contains a binary, and you can't upload a source+binary .changes file
[23:18] <verwilst> # Missing build dependencies: autotools-dev (>= 20100122.1)
[23:18] <verwilst> damned
[23:18] <verwilst> should i backport autotools as well in my ppa?
[23:19] <Ampelbein> verwilst: you can try copy+rebuild from the maverick repo
[23:19] <verwilst> Ampelbein, autotools you mean right?
[23:19] <verwilst> will do :)
[23:19] <Ampelbein> yes
[23:20] <lesliev> StevenK, does that mean I'd need to get pbuilder to build a source only .changes?
[23:20] <arand> lesliev: m. owens made a good overview once: http://doctormo.org/2010/04/19/deb-package-contents/
[23:21] <lesliev> great, thanks
[23:22] <StevenK> lesliev: pbuilder probably already made one for you in the directory you started the build from
[23:22] <StevenK> <source package>_<version>_source.changes or so
[23:22] <lesliev> ed_1.5-0ubuntu1_source.changes
[23:22] <StevenK> Yes, that. :-)
[23:23] <lesliev> but surely you'd need to upload more than that to the build farm?
[23:23] <lesliev> I'll read that url
[23:24] <StevenK> lesliev: If you point dput at the source.changes, it will parse the file and upload the other files it needs ot.
[23:24] <StevenK> s/ot.$/to./
[23:32] <verwilst> autotools-dev only built an i386 version.. hm
[23:32] <StevenK> Likely because it's architecture independant
[23:32] <verwilst> ah ok, so it will work on amd64 as well
[23:33] <verwilst> i was expecting 'all' or sth thing :)
[23:33] <verwilst> then*
[23:34] <StevenK> The .deb itself will be named autotools-dev_<version>_all.deb
[23:35] <verwilst> cool
[23:35] <verwilst> backporting is fun
[23:35] <verwilst> :)
[23:36] <verwilst> Missing build dependencies: autotools-dev (>= 20100122.1) hm :(
[23:36] <verwilst> it doesnt take the current ppa into consideration?
[23:36] <verwilst> that dep is in the same ppa
[23:36] <StevenK> It does, as long as it's published
[23:37] <verwilst> https://launchpad.net/~verwilst/+archive/zabbix/+packages
[23:38] <verwilst> ah, the amd64 one is building i think
[23:39] <StevenK> Yeah, you needed to wait some time for autotools-dev to build and publish before uploading zabbix
[23:40] <verwilst> my mistake :)
[23:40] <verwilst> and my php5.3.5 backport from natty is done as well, jaj!
[23:50] <lesliev> StevenK, I really like how you anchored that regex with a $ there :-)
[23:51] <StevenK> Heh