[00:00] <ari-tczew> ScottK: could you send MemoMsg to him?
[00:03] <udienz> ScottK: thanks for responding my email at ubuntu-motu-mentors
[08:25] <hakermania> Hello everybody.
[08:27] <hakermania> udienz: Hello, can you send me again the link talking about the patches, please? Thank you.
[10:11] <hakermania> Dos anybody knows what are "*.in" files?
[10:12] <geser> sort of templates
[10:12] <micahcowan> They can be anything, but the most frequent situation are files that are processed by the "configure" script to produce the final file.
[10:13] <micahcowan> configure looks for variables like @VAR@ and replaces them according to whatever settings it has. Makefile.in and config.h.in are typical.
[10:14] <hakermania> Thank you, tomboy's source has a lot of them and I wondered....
[10:14] <micahcowan> Often times, a Makefile.in is itself a generated file (from Makefile.am).
[10:15] <micahcowan> automake turns Makefile.am into Makefile.in (unlike configure, it doesn't just substitute, it adds a lot of material, and processes the user-provided values); then configure turns the Makefile.in into a Makefile, based on the users parameters to the configure script.
[10:50] <tumbleweed> geser: thanks :)
[10:52] <geser> tumbleweed: re CamelCase: I tried to mimic the LP API which also uses CamelCase when I wrote it to not be much more different than using the LP API directly
[10:52] <geser> but as there are not many users of lpapicache (requestsync and ubuntu-build if I didn't miss one) it can be changed
[10:53] <geser> and any ideas how to make it easier usable?
[10:53] <tumbleweed> geser: yeah. requestsync also needs the compatible mail and lp interfaces, which is one reason for some of the oddities
[10:54] <tumbleweed> there's nothing intrinsically wrong with the way it does anything, it's just different, so I looked at it and thought do I want to use this or just do things the normal way?
[10:55] <geser> if you only need to access an object once then there is no big benefit in it
[10:55] <tumbleweed> no, but it has handy functions like canUploadPackage etc for things that are tricky to do in pure launchpadlib
[10:55] <geser> but the old requestsync code fetched e.g. an series or archive object in each function which needed it which made requestsync slow
[10:56] <tumbleweed> I couldn't use things like that, because thye talk lpapicache wrapper clases as arguments, so you need to use lpapicache everywhere
[10:57] <geser> and you already have LP objects or only strings?
[10:57] <tumbleweed> lp objects, probably
[10:59] <geser> this function could be extended to also use lp objects instead of the lpapicache classes if it would help you
[11:01] <geser> or the logic could be moved to an own function and lpapicache uses it
[11:02] <tumbleweed> yeah, I'm sure both would work, but libsupport might be a better home for things like that. Although no point moving them until necessary
[11:04] <geser> I planned to use lpapicache also in other scripts but was hesitant to make them "depend" on u-d-t python modules for no benefit (many scripts can be used stand-alone)
[11:05] <tumbleweed> aah, I hadn't really considered that one
[12:23] <hakermania> Ok, I have a question about patching a system. I followed these rules: https://wiki.ubuntu.com/PackagingGuide/PatchSystems (where it says 'The easiest way'). After I make the patch (I simply edited the README file), the patch went to debian/patches. How to I apply the patch now so as the README file to change as I want to? I tried path -p0 < debian/patches/mypatch.patch but there are a lot of error messages! Or the package is ready fo
[12:25] <ari-tczew> hakermania: which patch system does your package use?
[12:26] <hakermania> what-patch outputs quilt.
[12:26] <ari-tczew> hakermania: did you use command path -p0? patch is correct btw
[12:26] <ari-tczew> but you shouldn't do this
[12:26] <ari-tczew> just add filename to debian/patches/series
[12:26] <cdbs> ScottK: I am sorry for that, if you read the previous upload of mine for the same package, you will understand
[12:27] <cdbs> The same fix worked in the previous upload
[12:27] <cdbs> and here it worked on my (slightly old) natty pbuilder
[12:27] <ari-tczew> cdbs: it's not explanation
[12:27] <cdbs> it appears a recent gcc change caused that FTBFS
[12:27] <ari-tczew> cdbs: how often do you update pbuilder?
[12:28] <cdbs> ari-tczew: around once a week or twice
[12:28] <ari-tczew> cdbs: lol. do it everyday
[12:28] <cdbs> if I had the proper connection :(
[12:28] <ari-tczew> add to cron, maybe will helpful
[12:28] <cdbs> this one frops very frequently, it takes me hours to upload small changes
[12:28] <cdbs> *drops
[12:29] <hakermania> ari-tczew: Ok, the patchs' name was automatically placed into the series file. My question is how do I apply the patch now ? Is the package ready for 'debuild -S' and if somebody try to install it, the patch will automatically take place or what?
[12:29] <hakermania> I mean, how do i test if the patch really works?
[12:29] <cdbs> I will need to consult someone on how to fix it, since a fix which worked a month ago isn't working now, wierd
[12:30] <micahg> cdbs: right, there was a gcc update, doko posted to ubuntu-devel about it
[12:30] <ari-tczew> hakermania: create a second directory, unpack source there and try to patch it. however, I prefer to just build package (binary) from *.dsc.
[12:31] <cdbs> micahg: yes, and it appears I uploaded the same day :(
[12:31] <cdbs> and I didn't get the FTBFS mail, oh its lying in spam
[12:32] <hakermania> ari-tczew: I don't get you :/
[12:32] <cdbs> ScottK: fixing right now, for sure I will do it
[12:33] <ari-tczew> hakermania: you don't need to use 'patch'. builder will apply patches
[12:34] <hakermania> ari-tczew: So I can now for example use 'debuild -b' and test if the DEB package works with the changes of my patch?
[12:36] <tumbleweed> hakermania: if your package uses quilt, quilt push -a will apply all patches, and quilt pop -a will unapply them all
[12:36] <hakermania> tumbleweed: Cool, give me a sec to test these 2.
[12:37] <tumbleweed> hakermania: I recommend spending some time getting familiar with quilt
[12:37]  * ari-tczew is guessing that someone else will be better teacher.
[12:38] <hakermania> ari-tczew: :P
[12:38] <hakermania> tumbleweed: Thx, I'll have an extended seach on the inet for quilt and its uses.
[12:39] <ari-tczew> siretart: ping
[12:44] <cdbs> hakermania: http://wiki.debian.org/UsingQuilt
[12:45] <hakermania> cdbs: Your name has to do with patching, I've heard about it somewhere. Btw thanks for the link :)
[12:45] <cdbs> Its much more than patching :)
[12:45] <cdbs> cdbs is a full build system for packages
[12:46] <tumbleweed> some of us don't like cdbs very much, but this cdbs is ok :P
[12:46] <cdbs> :D
[12:46] <cdbs> dh7 and debhelper were registered, so I had to settle for this
[12:50] <geser> cdbs: passing -l libs with LDFLAGS doesn't work anymore since the ld --no-as-needed change. You have to put them after the object files. In many cases you can use either ..._LDADD or LIBS for it (look into the Makefile which variable could be used for it)
[12:50] <cdbs> geser: I already uploaded that change to my PPA for a test build, will see what happens
[12:51] <cdbs> I have to rely on my PPA for test builds nowadays, until the situation improves, and the weather becomes better
[12:51] <cdbs> My connection is being disrupted by poor weather
[12:52] <hakermania> cdbs: Patches should have extension .patc or .diff?
[12:53] <hakermania> .patch*
[12:53] <cdbs> hakermania: both are okay
[12:53] <cdbs> some have no extensions at all :)
[12:53] <cdbs> .patch is what I prefer personally for a new package
[12:53] <geser> cdbs: I also see in debian/rules for courier on codehosting that it uses LDFLAGS=-lcrypt when calling configure. Please check the build log if configure finds everything it needs.
[12:54] <cdbs> geser: that change applies when it builds the webadmin part, here I am making the change in courier/module.esmtp/Makefile
[12:54] <ari-tczew> hakermania: I suggest to use the same extension as rest of patches in package (in debian/patches/)
[12:54] <hakermania> ari-tczew: Only for typical reasons?
[12:55] <kklimonda> geser: wouldn't it make more sense to prepare an actualy patch for packages that fail due to linking issues and then submit it to debian and upstream? tweaking debian/rules seems really hacky
[12:55] <cdbs> geser: it appears the PPA rejected because I did debuild -sd :( will have to upload a whole 9 MB now
[12:55] <ari-tczew> hakermania: for clear case
[12:56] <hakermania> Ok
[12:56] <geser> cdbs: so you didn't change debian/rules like the changelog entry says?
[12:58] <cdbs> geser: no, I am now modifying upstream makefile in the pending upload, that's a better approach
[12:59] <geser> cdbs: even if the LDFLAGS in debian/rules is not your change, it would be good to check if it's needed (or some feature missing) as using LDFLAGS that way doesn't work anymore
[12:59] <cdbs> hmm, yes, will check that
[12:59] <ari-tczew> geser: how often toolchain will be changing?
[12:59] <cdbs> but that's a debian-specific change, so will have to file a bug there about it first
[13:00] <ari-tczew> we don't have a time for 10x updating patches to fix FTBFS with binutils-gold. it's being annoying
[13:00] <geser> ari-tczew: I hope not anymore for natty, the next change if any I'd expect for natty+1, but better ask doko if you want to know if any other changes are planned for natty
[13:01] <ari-tczew> geser: what's the point to changing toolchain?
[13:02] <geser> as far as I understand the reason for the recent changes is to lessen the needed dependencies as many program (and therefore packages) link to many unneeded libraries making library transitions harder than needed
[13:03] <cdbs> yes, the toolchain changes have benefited a lot in that sense
[13:04] <cdbs> hakermania: (just an FYI in case you don't know) All packages in Debian are synced very frequently to Ubuntu
[13:05] <ari-tczew> cdbs: till DIF
[13:05] <cdbs> ari-tczew: it can be done even after DIF, just that a sync must be requested
[13:05] <ari-tczew> geser: does debian planning to approve similiar toolchain to ours?
[13:05] <cdbs> ari-tczew: yes
[13:05] <cdbs> ari-tczew: after squeeze release
[13:05] <cdbs> its planned for wheezy
[13:05] <ari-tczew> I'm asking due to curiosity about forwarding patches to fix building with binutils-gol
[13:06] <ari-tczew> d
[13:06] <geser> ari-tczew: the ld --no-add-needed (aka no DSO indirect linking) is planned for Wheezy, don't know about the ld --no-as-needed change
[13:07] <geser> doko asked me forward my ld --no-as-needed changes to Debian and user-tag them accordingly
[13:10] <ari-tczew> geser: what does it mean?
[13:11] <geser> user-tagging? it's similar to the tags in LP and allows to search for bugs with a specific tag in the Debian BTS
[13:17] <cdbs> Holy, my package upload to the PPA is failing as it did earlier
[13:18] <cdbs> and I don't have any other way to test-build!
[13:18] <cdbs> bug #687622 is responsible
[13:18] <cdbs> I guess
[13:18] <cdbs> err, bug #687662
[13:51] <hakermania> What's the difference of launchpad bugs and bugzilla ?
[13:54] <kklimonda> hakermania: ugh.. both let you report and triage bugs.. everything else is different
[13:54] <geser> different software for managing bugs
[13:54] <kklimonda> geser: what about my questions wrt patches for link failures? :)
[13:54] <hakermania> But, bugzilla bugs rhen referred by users in lp, are called "upstream"
[13:55] <hakermania> when*
[13:56] <kklimonda> hakermania: different projects use different places for bug reporting. What we call upstream is (among other things) the bug tracking system that the project uses
[13:56] <hakermania> kklimonda: Thx
[13:57] <mr_pouit> kklimonda: (wrt patches for link failures) I agree with that. I find these kind of changes useless (and I had to redo all the work of the previous uploader when I wanted to forward upstream…)
[13:57] <geser> kklimonda: missed it. yes, fixing the build system and forwaring the patch to Debian and upstream is better.
[14:40] <SpamapS> Daviey: meh... 15 month old disagrees with you that I should be in bed. ;)
[16:00] <hakermania> How can i turn off the messages which tell who enters and quits the room?
[16:00] <evaluate> hakermania, depends on your client
[16:00] <hakermania> evaluate: pidgin :/
[16:01] <boulabiar> hakermania, on xchat, settings> hide join/Part messages
[16:01] <evaluate> hakermania, hmm, not sure, I don't use pidgin for IRC. Try #pidgin ?
[16:01] <hakermania> thx
[21:15] <Daviey> SpamapS: That was my guess :)
[21:22] <OwaisL> Hi everyone. How much time does it usually take for REVU to reflect uploads?
[21:23] <OwaisL> I just uploaded a couple of packges in last 30 mins but revu.ubuntuwire.com is not showing them.
[21:41] <OwaisL> Hey, would anyone like to have a look at a package I just uploaded to Motu for inclusion in Natty?
[21:41] <OwaisL> http://revu.ubuntuwire.com/p/gmailwatcher
[22:29] <anoteng> anybody know what this error message from launchpad means (rejected PPA upload): Unhandled exception processing upload: 'NoneType' object has no attribute 'md5'
[22:33] <Bachstelze> anoteng: looks like a bug in LP