[08:07] <pfifo> I am, or rather have been trying to get a package updated. The package is SDL-ttf version 2.10. I have contacted upstream and thats not really going anywhere. What can I do to get things moving in ubuntu? It seems there are atleast 3 othrs compiling this package from source given just the info on launchpad. What can I do?
[08:15] <pfifo> any ideas at all? Im honestly at the end of the road and could use direction
[08:16] <SpamapS> pfifo: is there a bug in Launchpad already?
[08:17] <pfifo> yes
[08:17] <pfifo> ill link it one moment
[08:17] <cento> pfifo, give me the exactly name
[08:17] <cento> of the package
[08:18] <SpamapS> pfifo: just type 'bug #xxxxx' and the bot will link it
[08:18] <pfifo> https://bugs.launchpad.net/ubuntu/+source/sdl-ttf2.0/+bug/647759
[08:18] <ubottu> Ubuntu bug 647759 in sdl-ttf2.0 (Ubuntu) "Update to new upstream release" [Undecided,Confirmed]
[08:21] <pfifo> as you can see I am trying to take this into my own hands, it has been effecting me for long enough now and I have experience working around it. I want something done.
[08:24] <pfifo> SpamapS, cento, anything of interest?
[08:25] <cento> try to package yourself
[08:26] <cento> and use a personal ppa
[08:26] <pfifo> wait
[08:27] <pfifo> me providing a ppa will 'resolve' the issue?
[08:27] <cento> if you need NOW this package
[08:28] <cento> you can help, with custom ppa, yourself and other users
=== cento is now known as c3n
[08:30] <pfifo> so basicly your telling me theres no way to fix this?
[08:30] <pfifo> atleast until debian does?
[08:31] <c3n> i tell you i'm a ubuntu user like you, and i think "if a package isn't on my rep, i make it on my ppa" :)
[08:32] <pfifo> well ok, thanks
[08:49] <christitze> i attached a fix as a debdiff to a bug report and now it says that the bug is fixed. but i got an email saying "* State: Failed to build" (for all arch's). so what should i do now? is the bug fixed in the new package or not?
[08:49] <christitze> this is the link: https://launchpad.net/ubuntu/+source/open-vm-tools/2011.03.28-387002-0ubuntu4/+build/2616084
[08:51] <tsimpson> if it failed to build, then not fixed
[08:51] <christitze> okay, then what should i do now?
[08:52] <tsimpson> you may want to look at the build log, fix the error, and update the debdiff
[08:53] <christitze> thanks, i'll see what i can do but i'm a real newbie, this is my first bug fix
[08:53] <tsimpson> it looks like the build failure has nothing to do with your fix, but you get more karma if you fix the new errors it to ;)
[08:54] <tsimpson> though you'll probably want to open a new bug for this error, as it's seems unrelated to the original bug
=== paul__ is now known as Elbrus
[08:56] <christitze> okay thank you. where should i report the bug? or what is causing it?
[08:58] <tsimpson> against the package, something like "open-vm-tools failed to build on i386"
[08:59] <tsimpson> or you can let someone else pick it up if you don't know what the fix is
[09:00] <christitze> i'll report the bug now and post the information i have and someone else can look further into it
=== warp11 is now known as warp10
[15:58] <tumbleweed> aonyx: I don't think moving LDFLAGS to the end is the best option either. In fact, a fair number of these issues were from people using LDFLAGS for linking to libraries rather than changing linker behavior
[15:59] <tumbleweed> aonyx: but there isn't an obvious best way to deal with this package. Both the upstream makefile and debian/rules should probably be changed
[16:16] <aonyx> Ok, so for now should I just add the PAMLIB argument to the makefile?
[16:17] <aonyx> tumbleweed: I mean add the PAMLIB argument to the makefile to debian/rules
[16:22] <tumbleweed> aonyx: sorry, I need to go out, I can probably only look at it again tomorrow. But others around here (jtaylor?) can probably help
[16:23] <tumbleweed> I think my original suggestion was reasonable, but maybe there's no best answer and we should just get the thing uploaded...
[16:27] <aonyx> ok, well I will try hailing jtaylor to see what he thinks.
[16:27] <aonyx> jtaylor: would you mind taking a look at something?
[16:46] <jtaylor> one moment
[16:56] <jtaylor> aonyx: does this package still fail?
[16:56] <jtaylor> ld should link with libc correctly even if you don't tell it to
[16:57] <jtaylor> ah no --shared is used
[16:57] <aonyx> so do you know which package we are referring to?
[16:57] <jtaylor> libpam-encfs I assumed
[16:57] <aonyx> yes
[16:58] <jtaylor> it builds fine in my chroot
[16:58] <aonyx> are you referring to the fix that I pushed?
[16:59] <aonyx> tumbleweed thinks that what I did is not as correct as it could be
[16:59] <jtaylor> no the one from debian
[17:02] <jtaylor> but it still looks wrong, an extra variable LIBS should be added and appended to the ld line
[17:03] <jtaylor> or use PAMLIB
[17:05] <aonyx> ok, sure, that is what tumbleweed was suggesting, was just trying to figure out why it built in your chroot, because it didn't in mine
[17:07] <jtaylor> maybe yours sets --no-undefined
[17:07] <jtaylor> => my chroot is bad ._.
[17:10] <jtaylor> no thats not the reason
[17:16] <jtaylor> brb
=== yofel_ is now known as yofel
[21:33] <Laney> ScottK: I just looked at natty-backports. bug 800501 bug 800224 bug 808126 (this is mine) look good to go for me.
[21:33] <ubottu> Launchpad bug 800501 in natty-backports "Please backport ding-libs from oneiric" [Undecided,Confirmed] https://launchpad.net/bugs/800501
[21:33] <ubottu> Launchpad bug 800224 in natty-backports "Please backport packaging-dev 0.1" [Undecided,Confirmed] https://launchpad.net/bugs/800224
[21:33] <ubottu> Launchpad bug 808126 in natty-backports "Please backport sparkleshare 0.2.2-1ubuntu1 from Oneiric to Natty" [Undecided,New] https://launchpad.net/bugs/808126
[21:37] <broder> Laney: i don't see any reason we couldn't backport openjdk-7, since the version is embedded in the package name
[21:38] <ScottK> Laney: I agree in two of the three cases.
[21:38] <broder> it wouldn't affect rdeps or anything
[21:38] <Laney> the policy should be updated then
[21:38] <Laney> ScottK: ding-libs is a package not in natty if you're referring to that
[21:38] <Laney> actually, i think all of them are
[21:38] <ScottK> Nope.
[21:39] <ScottK> 224
[21:39] <broder> Laney: i had interpreted the policy to refer more to changing things like python-defaults
[21:39] <broder> but ScottK is more authoritative on this than me, so since he's around, i'll defer to him :)
[21:40] <ScottK> Laney: It's on my list to get the backports library policy officially updated.  The de facto policy at the moment is "don't break rdepends".
[21:41] <Laney> I thought runtimes were a hard no
[21:41] <Laney> what's the problem with packaging-dev then?
[21:47] <Laney> bug 802044
[21:47] <ubottu> Launchpad bug 802044 in natty-backports "Please backport nspluginwrapper 1.4.2-0ubuntu2" [Undecided,Confirmed] https://launchpad.net/bugs/802044
[21:48] <Laney> wow. somehow ubuntu learned how to keep my s/pdif off after a reboot
[21:49] <broder> you mean the mac optical port? 'bout time
[21:49] <Laney> yeah
[21:52] <ScottK> Laney: The testing standard for backports is "Builds, installs, and runs." he just said he'd tested it built and installed.
[21:52] <Laney> right. missed that.
[21:53] <Laney> I assume it was just a typo, but yeah I see your point
[22:05] <ScottK> It's the most common omission when people say they want something backported.
[22:06] <ScottK> I understand from jdong_ there have been more than a few cases where stuff builds fine and thing utterly fails to start.
[22:06] <ScottK> OTOH, if it as least starts it generally works ~as well as it did in the later release.
[22:22] <broder> ScottK: you know packaging-dev is a metapackage, right?
[22:22] <ScottK> broder: I forgot about that.
[22:23] <ScottK> It is rather redundant to try and run it.
[22:23] <broder> right
[22:23] <ScottK> I'll go back and approv e it.
[22:24] <ScottK> Done.
[22:25] <jtaylor> as there is just a backport discussion, the zeromq backport is tested, I#m using it since a while in natty
[22:26] <broder> jtaylor: what's the bug #? i'll take a look
[22:27] <jtaylor> broder: 805701
[22:27] <jtaylor> no rdeps
[22:28] <broder> for any of them?
[22:29] <jtaylor> no, pgm is new in oneiric
[22:29] <jtaylor> was bundled in the old zeromq
[22:29] <broder> ok, sounds good. for procedure reasons, can you open a separate bug for each package?
[22:29] <broder> it makes it easier on the archive admins
[22:29] <jtaylor> ok
[22:32] <broder> oh yeah - any DDs around interested in sponsoring a new package in Debian for me?
[22:32] <broder> (http://web.mit.edu/broder/Public/reptyr/)
[22:39] <jtaylor> broder: 80814{1,3,6}
[22:42] <broder> jtaylor: ok, those look good. in the future, please be sure to note that the package "builds/installs/runs" (which you were less than clear about for 808141)
[22:42] <broder> you also didn't reference the PPA in 808141 which would be useful if someone was examining it in isolation
[22:42] <broder> and for doing test builds, we recommend using the backportpackage script from ubuntu-dev-tools
[22:42] <broder> but those are mostly nits
[22:43] <jtaylor> I used backportpackage to do my ppa packages
[22:43] <broder> really? they don't seem to have the right suffix
[22:43] <jtaylor> ah yes I linked my old ppa, I have a new one jtaylor/ipython-dev
[22:45] <broder> whatever - i checked that you did the backport right for the old ppa
[22:45] <jtaylor> only uploaded them there a few days ago, but I used essentially the same package from my personal ppa before
[22:45] <broder> anyway, those 3 should be all set to go
[22:46] <jtaylor> should I still update the description with these details?
[22:48] <broder> don't worry about it - i've already acked it
[22:48] <jtaylor> k thx