[00:00] <Bachstelze> I haven't looked at all of them but that's probably why we hase so many FTBFSs
[00:00] <Bachstelze> packages that used to build fine but don't with the new toolchain
[00:00] <Bachstelze> have*
[00:01] <Bachstelze> awesome, it works
[00:02] <Bachstelze> I guess I should forward it to Debian since we haven't diverted
[00:02] <Bachstelze> not sure they'll accept it, though, it works fine for them apparently
[00:23] <ari-tczew> Bachstelze: lucas__ page shows packages which have been built fine in the past. now if you'd build on natty toolchain, result is fail
[00:23] <ari-tczew> so you're right
[00:23] <ari-tczew> how to deal SRU with backports?
[00:23] <ari-tczew> which version shall I choice?
[00:24] <ari-tczew> (0.6-0ubuntu2~maverick1) maverick-backports -> (0.6-0ubuntu2.1) maverick-proposed is OK?
[00:26] <ebroder> ari-tczew: I don't understand the question. Are you asking about making an SRU from a backport, or making a backport from an SRU?
[00:26] <ari-tczew> ebroder: this second
[00:26] <ari-tczew> ebroder: no, stop
[00:26] <ari-tczew> wrong
[00:27] <ari-tczew> ebroder: clementine is backported package. I want to push a SRU
[00:27] <ari-tczew> for maverick
[00:27] <ebroder> backports are separate from the SRU process, and we usually don't use backports as the basis for an SRU because SRUs should have minimal patches
[00:27] <ebroder> If the backport is buggy, then fix it in the dev release and get a new backport
[00:29] <ari-tczew> ebroder: lol, I have minimal patch for SRU
[00:29] <Bachstelze> debian 608011
[00:29] <ebroder> ari-tczew: I'm afraid you're still not making sense to me
[00:29] <Bachstelze> do we wait to see if they apply it, or create an ubuntu1 for now?
[00:30] <ari-tczew> ebroder: imagine (theory) that dev release has a big upgrade and you want to backport it. not always it's possible then we should get minimal patches.
[00:30] <ari-tczew> Bachstelze: you can wait a couple of days since we have devel distro.
[00:31] <Bachstelze> ok
[00:31] <Bachstelze> I'll create a bug on P and link it
[00:31] <Bachstelze> LP*
[00:31] <ebroder> ari-tczew: There is always a minimal patch to fix a bug. It may be a big patch, but it should still be minimal. It may be the same as the difference between two releases, but it should still be minimal
[00:32] <ari-tczew> Bachstelze: however, in bugtitle 'in ubuntu natty' is not 100% cool. better is use bugtitle like 'sendmail: FTBFS with binutils-gold and linking in gcc 4.5'
[00:32] <ari-tczew> Bachstelze: and please attach in Debian mail only patch to fix bug. no full debdiff
[00:32] <ari-tczew> Bachstelze: or maybe if you want prepare NMU, you should follow with Debian policy
[00:34] <ari-tczew> ebroder: in clementine case backport is possible way, but in my last sentence I gave only an example
[00:34] <Laney> that is not really NMUable
[00:35] <Laney> and it should be severity wishlist or minor
[00:35] <ari-tczew> ebroder: should do I open a new bug?
[00:36] <ari-tczew> (for backport)
[00:38] <ari-tczew> ebroder: if you want to writer YES, I tell that this is bureaucracy
[00:38] <ari-tczew> write*
[00:38] <ebroder> ari-tczew: I still can't understand what it is you're trying to do
[00:38] <ari-tczew> ebroder: ...
[00:39] <ari-tczew> ebroder: I _ want _ to _ fix _ a _ bug _ in _ backported _ package _ called _ clementine _ which _ exist _ in _ maverick-backports
[00:39] <ebroder> Thank you! That's what I was trying to figure out
[00:39] <ebroder> Ask for a new backport
[00:40] <ari-tczew> ebroder: what do you mean ask? open bug? open question on LP?
[00:40] <ebroder> Open a backport bug
[00:41] <ari-tczew> this is a joke
[00:42] <ari-tczew>  /usr/bin/ranlib: libclementine_lib.a: No space left on device
[00:42] <ari-tczew> I have 2GB free on part
[00:50] <Bachstelze> wvdial: same thing
[00:51] <Bachstelze> yay for easy karma \o/
[00:52] <Bachstelze> actually that's not going to give me much karma if everything must be forwarded to debian, eh
[00:56] <Bachstelze> ari-tczew: is it cool to say in the body of the message that the bug can be seen on Natty?
[00:57] <Laney> Bachstelze: getting stuff fixed in Debian gives you more karm
[00:57] <ari-tczew> if current binaries built fine, no
[00:57] <Laney> at least in my eyes
[00:57] <ari-tczew> Bachstelze: don't worry about numbers
[00:57] <Bachstelze> that was a joke ;)
[00:58] <Bachstelze> ari-tczew: so what exactly should I put then?
[00:59] <ari-tczew> Bachstelze: in mail forwarding to BTS?
[00:59] <Bachstelze> yeah
[00:59] <Laney> you can say that you found this problem when building for Ubuntu, and that the fix is in the attached patch
[00:59] <Laney> and politely ask them to apply it
[01:04] <ari-tczew> Bachstelze: http://paste.ubuntu.com/547622/
[01:08] <Bachstelze> ari-tczew: thanks
[01:10] <ari-tczew> Bachstelze: You're welcome.
[01:11] <ari-tczew> ebroder: saying gentle, I'm don't respecting rules and I'm trying to backport package using one bug.
[01:11] <ari-tczew> s/don't/not
[02:56] <Bachstelze> another one down
[02:56] <Bachstelze> guess I'll get some sleep, 'night folks
[03:01] <Bachstelze> bug 694398 if nyone is interested to sponsor it
[06:11] <udienz> [ftbfs] one down.. bug 694413
[06:16] <micahg> udienz: could you also upstream your patch to debian 554370 with teh appropriate tags: https://wiki.ubuntu.com/Debian/Usertagging
[06:18]  * micahg goes to test build firestarter, thanks for the patch udienz
[06:19] <udienz> micahg, Thanks! I think it's better when this patch is done reviewed by ubuntu-sponsors
[06:20] <micahg> udienz: yeah, oops, I spoke too soon, it should be a patch, not applied directly to source
[06:21] <micahg> I'll comment in the bug
[07:04] <udienz> micahg, Done, i have submitted again. and already tested via natty pbuilder
[07:08] <micahg> udienz: usually we just use the next number available for patches unless it needs to be at the end (like autoreconf)
[08:22] <udienz> micahg, soorry for delay reply. i will uploaded again and renaming it
[08:23] <micahg> udienz: it's ok, I've made the cahnges and added the patch name to the changelog
[08:23] <micahg> I'm testing it now
[08:31] <micahg> udienz: I'll upload in several hours, I don't like to upload right before bed
[08:31] <udienz> micahg, ok no problem
[08:31] <micahg> udienz: thank you for the patch
[08:32] <udienz> micahg, :) thanks for reviewing
[12:22] <dnivra> is this the channel where i can ask for packaging support?
[12:23] <ari-tczew> dnivra: yes. also exist #ubuntu-packaging
[12:24] <dnivra> ari-tczew: #ubuntu-packaging it is then. thanks!
[15:33] <ari-tczew> ScottK: I encourage you to consider about approve some devs from community, like micahg or ebroder
[15:33] <ari-tczew> and clean up 'pending approval' from bots ;)
[15:44] <micahg> apachelogger: sorry about the firefox installer override being dropped, I'll add it back
[15:44] <apachelogger> micahg: thanks :)
[15:44] <micahg> are LDFLAGS fixes ok as a patch as opposed to being overridden in debian/rules?
[15:53] <geser> LDFLAGS fixes?
[15:53] <micahg> geser: LDFLAGS additions
[15:53] <geser> like?
[15:54] <micahg> bug 694413
[15:55] <geser> I didn't try the patch out, but it most likely won't work
[15:55] <micahg> geser: it builds fine
[15:55] <geser> I'm surprised
[15:55] <geser> and LIBS would be a better place to add additional libraries instead of LDFLAGS
[15:56]  * Bachstelze nods
[15:56] <Bachstelze> -l* flags belong in LIBS, not LDFLAGS
[15:56] <micahg> ah, ok
[15:57] <Bachstelze> and yes, this is very ugly
[15:57] <Bachstelze> normally you would modify configure so that it puts the libs in the variables passed to MAkefile.in
[15:58] <geser> and another small issue: if the package needs to link with -lX11 -lXext -ldl the matching -dev packages should be listed in Build-Depends (for X11 and Xext)
[15:58] <micahg> could one of you comment on the patch then explaining why another way is better?
[15:59] <micahg> geser: that's another good point
[16:02] <micahg> ok, nm, I'll aggregate the comments here, thanks guys
[16:47] <paissad> hello, i see there are many tools to maintain a personal repository for .deb packages, (ftp-archive, apt-move, dpkg-scanpackages, mini-dinstall) ... what do you advice me ?
[16:49] <Nafallo> ppa on launchpad :-)
[16:49] <paissad> Nafallo, i do use it aleady
[16:49] <paissad> Nafallo, i ask this question for testing purpose
[16:50] <Nafallo> fair enough. I'd just set up a testing ppa though... *shrugs*
[16:50] <Nafallo> sorry for not being helpful.
[16:53] <crouk> Hi all
[16:53] <crouk> im new here
[16:54] <crouk> could someone help me with some question about MOTUs??
[16:54] <Nafallo> !ask | crouk
[16:55] <crouk> nice thanks! :)
[16:55] <Nafallo> ;-)
[16:55] <crouk> just getting involved on PyGtk and RubyGtk development
[16:56] <crouk> I just finish a new .deb package
[16:56] <crouk> and i don't know how to upload in the universe repository or just someone who do it for me
[16:57] <crouk> If the package is ok, sure...
[16:57] <Bachstelze> crouk: how "new" are we talking?
[16:58] <crouk> well, is 4 month old
[16:58] <crouk> is a MP3 tagger
[16:58] <crouk> do it with Ruby-gnome2 +glade
[16:59] <crouk> i do it a *.deb and I use it only in my comuter
[17:00] <crouk> I checked the MOTUs web and I don't know is this kind of contribution should we checked by another MOTU
[17:00] <crouk> or i can just register and contribute with them
[17:00] <Bachstelze> crouk: if it's a really new package, as opposed to a newer verison of an existing package, the best way is to submit it to Debian
[17:01] <Bachstelze> and then let it sync in Ubuntu automagically
[17:02] <crouk> OK. And how do I submit it to Debian?
[17:04] <Bachstelze> http://www.debian.org/doc/maint-guide/
[17:13] <crouk> nice :)
[17:13] <crouk> im reading the dupload doc now
[17:13] <crouk> so just upload the package with dupload and the Debian community will check it?
[17:14] <Bachstelze> no
[17:14] <Bachstelze> you can't use dupload because you are not a DD
[17:15] <Bachstelze> so you need to get a sponsor for your package
[17:16] <Bachstelze> this explains it: http://wiki.debian.org/DebianMentorsFaq
[17:30] <Bachstelze> hmm, wouldn't it be better to just create ubuntu1 revisions for all the packages that FTBFS with LD_ERROR than flooding Debian with patches that are mostly not relevant to them?
[17:31] <Bachstelze> I have the feeling that most of them won't be applied, so we'll find ourselves with one week before FF and a lot of patches to apply
[17:32] <azeem_> what's the reason for that LD_ERROR?
[17:32] <Bachstelze> azeem_: the new toolchain in Natty is much less tolerant of bad practice
[17:32] <Bachstelze> generally the packages put -l* flags in LDFLAGS instead of LIBS
[17:32] <azeem_> won't Debian have that toolchain at some point as well?
[17:33] <micahg> Bachstelze: wheezy will probably be similar, so they should be sent to Debian but with wishlist prioirty ATM
[17:54] <crouk> Bachstelze: thanks. Im reading now about to get sponsored
[18:31] <tumbleweed> bdrung: test_update_maintainer: You should probably unpatch os.path.isfile (ubuntutools.update_maintainer.os.path is os.path). I also see some trailing whitespace.
[19:05] <ebroder> ari-tczew: Oh, sorry - missed that you were looking at bug #694504
[19:06] <ebroder> I'll reset the status back to where you had it
[19:06] <ari-tczew> ebroder: what's the sense if you acked it?
[19:07] <ari-tczew> please learn to set in progress and assign to you if you're looking
[19:07] <micahg> ari-tczew: please unsubscribe -sponsors if you take a bug ;)
[19:07] <ari-tczew> micahg: this is the second thing
[19:07] <ebroder> micahg: I'm pretty sure this was my fault - I think I was looking at it before ari-tczew was
[19:08] <ebroder> Because it was unassigned when I pulled it up
[19:08] <micahg> I set to in progress, assign to me, and unsubscribe sponsors
[19:08] <ebroder> ari-tczew: Sorry. I sometimes forget when I'm looking at tickets that I think will be fast
[19:11] <ari-tczew> ebroder: officiousness is worse than fascism
[19:11] <ari-tczew> just anecdote
[19:26] <ari-tczew> ebroder: btw. if you are bored, I can find activity for you
[19:26] <DktrKranz> ari-tczew: wrt your gnome-user-share mail, I just replied to it
[19:27] <ari-tczew> DktrKranz: yes I know. unfortunately my pbuilder doesn't know about it :(
[19:28] <ari-tczew> (now I know)
[19:28] <DktrKranz> I think pbuilder ignores it
[19:33] <ari-tczew> perhaps
[19:34] <sebner> ari-tczew: I'm really surprised to see a polish guy saying that officiousness is worse than fascism
[19:34] <ari-tczew> sebner: why?
[19:35] <ari-tczew> this is quote is very popular in Poland
[19:35] <sebner> this surprises me even more
[19:35] <sebner> if you think about your past ..
[19:35] <ari-tczew> sebner: have you got problem with Poland?
[19:36] <sebner> ari-tczew: not really, just wondering if you forgot what happened 70 years ago
[19:38] <ari-tczew> sebner: hmm. I'm really interested what do you mean. maybe in your country is another history.
[19:39] <sebner> ari-tczew: not really, I'm from Austria ;)
[19:39] <sebner> ari-tczew: officiousness was a result of the fascism at that time imho
[19:39] <sebner> but we are quite OT
[19:41] <ari-tczew> aha
[19:45] <Bachstelze> # wc -l debian/patches/01-wsdl-stubs.patch
[19:45] <Bachstelze> 339162 debian/patches/01-wsdl-stubs.patch
[19:45] <Bachstelze> wow
[19:45] <Bachstelze> that's a big patch
[20:12]  * kklimonda doesn't know any Polish quotes about officiousness and fascism, and if there are any he doesn't agree with them.
[20:50] <ari-tczew> micahg: I'd like to not close bugs by you if fixed is not yet available. I mean bug 694118
[20:50] <micahg> ari-tczew: I closed the maverick task since it was invalid
[20:50] <ari-tczew> micahg: it confuses new users
[20:51] <ari-tczew> which clementine has got
[20:51] <micahg> ari-tczew: yes, but that task is for the maverick archive, not backports
[20:51] <ari-tczew> micahg: omg please open your eyes and see that there is no only policies and procedures
[20:52] <ari-tczew> micahg: what about launchpad bug janitor?
[20:52] <ari-tczew> doesn't close this bug after backport?
[20:52] <micahg> ari-tczew: no
[20:52] <ari-tczew> micahg: are you sure?
[20:52] <micahg> ari-tczew: I think the new helper might close backport bugs, but a bug task is only for an SRU, not a backport
[20:54] <ari-tczew> micahg: I'm out of words to describe this stiffness and bureaucracy
[20:55] <micahg> ari-tczew: it's a different workflow for SRU bugs and backports
[20:55] <ari-tczew> micahg: say it to newbies
[20:55] <ari-tczew> I know that you're master and for you everything is clear, but not for everyone
[20:55] <ari-tczew> I don't want scary new users
[20:56] <ari-tczew> and you don't help in this case
[20:56] <ari-tczew> I want to tell gtfo
[20:56] <micahg> ari-tczew: you can file a bug against launchpad to have the release tasks target different pockets if you like
[20:56] <micahg> ari-tczew: the way to do that is with a note in the description, not using a release task
[20:57] <tumbleweed> ari-tczew: I think the best thing to do in these cases is to close the task with a clear comment saying "backport tracked in LP: #foo, we don't use tasks to track backports"
[20:57] <ari-tczew> tumbleweed: tell this one to micahg
[20:57] <tumbleweed> micahg is presumably listening :P
[20:57]  * Bachstelze cries
[20:57] <ari-tczew> tumbleweed: reading
[20:57] <micahg> ari-tczew: I closed it with a comment about adding an appropriate backports task/bug
[20:58] <Bachstelze> spent all afternoon fixing linking errors in eucalyptus
[20:58] <Bachstelze> and now there's also some java errors that make the build fail
[20:58] <ari-tczew> Bachstelze: unfortunately, life is brutal
[20:59] <ari-tczew> micahg: you could include also new tracking bug number
[20:59] <ari-tczew> flow of information is very important
[21:00]  * ari-tczew doesn't know how that master couldn't consider about it
[21:00] <Bachstelze> !pastebin
[21:00] <Bachstelze> !pastebinit
[21:01] <micahg> ari-tczew: sorry, I didn't connect the two, I could've given bug #
[21:01] <ari-tczew> micahg: bravo!!!1111!
[21:01] <micahg> !msgthebot | Bachstelze
[21:01] <micahg> ari-tczew: would you like me to do that now?
[21:02] <ari-tczew> micahg: pleased, yes
[21:04] <micahg> ari-tczew: done
[21:08] <ari-tczew> micahg: thanks, now you can send delation to CC
[21:08] <micahg> ari-tczew: ?
[21:09] <ari-tczew> micahg: Questionable behavior from an Ubuntu member
[21:09] <ari-tczew> hehehe
[22:04] <akoskm> hi
[22:09] <akoskm> If I copy my *.so files to the /usr/lib/jni and then run the ldconfig in that directory, and after adding a configuration file to /etc/ld.so.conf.d/, specifying the path to /usr/lib/jni, If I start a java application the jvm should include the /usr/lib/jni path to not just the /usr/lib, isn't?
[22:11] <Bachstelze> akoskm: you should run ldconfig /after/ adding a file in /etc/ld.so.conf.d/
[22:12] <akoskm> Bachstelze, oh. that would be all? and doing by this way It will include the /usr/lib/jni too?
[22:13] <Bachstelze> not sure about Java, but that's how it would work in C
[22:13] <akoskm> okay, I'll try this out. thank you.
[22:13] <ebroder> akoskm: It seems a little weird to me that you'd have to change the linker configuration to enable Java's plugin system
[22:15] <akoskm> ebroder, why? I have no experience around packaging, if there any other ways to include the native libraries installed by my package let me know.
[22:16] <ebroder> akoskm: I don't know. But I would expect that you're just using the wrong directory or something
[22:16] <ebroder> I don't really know anything about Java. But have you looked at the Debian Java policy to see if it talks at all about JNI?
[22:17] <akoskm> yes
[22:18] <ebroder> akoskm: Looking for a random package that uses JNI, it looks like libswt3.2-gtk-jni just drops files in /usr/lib/jni
[22:18]  * ebroder shrugs. I probably don't know what I'm talking about
[23:34] <bdrung> tumbleweed: fixed. thanks.
[23:34] <bdrung> tumbleweed: there was only one trailing whitespace line, correct?
[23:40] <tumbleweed> yeah, that's all I saw
[23:40] <tumbleweed> bdrung: I posted a pyflakes tester
[23:40] <bdrung> tumbleweed: thanks for your pylint tester
[23:40] <bdrung> tumbleweed: pyflakes?
[23:40] <tumbleweed> err pylint
[23:41] <bdrung> tumbleweed: can you remove the items that are default values from the pylint config file?
[23:41] <tumbleweed> I was just saying I was alcoholically impaired in another channel, let me repeat that here :)
[23:41] <tumbleweed> probably, I should actually investigate that
[23:41] <bdrung> tumbleweed: and maybe it's better to disable unwanted test than enable wanted ones.
[23:42] <bdrung> tumbleweed: besides that it looks good
[23:42] <tumbleweed> that's just the config file I wrote, I didn't disable any tests
[23:42] <tumbleweed> s/I/it/
[23:44] <tumbleweed> bdrung: err "del ubuntutools.control.os.path.isfile" is that right?
[23:44] <tumbleweed> shouldn't be a save that value and restore it
[23:44] <bdrung> tumbleweed: replacing pylint.conf with an empty files thrown more errors
[23:44] <ebroder> tumbleweed, bdrung: Have you guys looked at python-mox? It's a better way for replacing built-in functions like that
[23:44] <ebroder> (I haven't actually looked at the tests yet, but I assume that's what you're doing)
[23:44] <bdrung> tumbleweed: "del ubuntutools.control.os.path.isfile" is what i learned from you
[23:45] <bdrung> tumbleweed: why should i save the function link?
[23:45] <tumbleweed> bdrung: aah, I added open to the module, I didn't replace teh open builtin
[23:46] <tumbleweed> ebroder: yeah, I wasn't doing anything *that* fancy, so I didn't look for libraries to help
[23:46] <bdrung> ebroder: it's the first time i hear about python-mox. link to doc?
[23:46] <ebroder> bdrung: http://code.google.com/p/pymox/wiki/MoxRecipes
[23:46] <ebroder> bdrung: Look at the "Mock a module-level function in a different module" example, for instance - that's the idiom I've used most frequently
[23:48] <bdrung> ebroder: merge proposals are welcome ;)
[23:49] <ebroder> bdrung: Afraid I don't have time for that at the moment; just wanted to make sure you guys were aware of Mox before you started duplicating what it does
[23:50] <bdrung> ebroder: i will consider using it the next time i work on a python test
[23:50]  * bdrung is setting a bookmark
[23:52] <ebroder> bdrung: Oh, and on the subject of testing tools, there's also https://github.com/mockfs/mockfs, which isn't packaged and which I've never used, but is probably also useful for faking out filesystem-based tests
[23:52] <ebroder> (docs at http://mockfs.github.com/)
[23:53] <tumbleweed> nice
[23:53] <ebroder> Although it looks like it only stubs out functions in os and os.path instead of, say, open, which makes it less useful
[23:53] <bdrung> ebroder: do you have a real world example for mox?
[23:53] <tumbleweed> oh, that's a bit less useful, yes
[23:54] <tumbleweed> it has an open-like function you could patch in, though
[23:57] <bdrung> ebroder: how to use StubOutWithMock on "open"?
[23:57] <ebroder> bdrung: You should be able to do StubOutWithMock(__builtins__, 'open'), I think
[23:58] <ebroder> http://pastebin.com/1DJZDxbs
[23:59] <bdrung> ebroder: self._mox.StubOutWithMock(__builtins__, "open") fails: AttributeError: 'dict' object has no attribute 'open'