=== [ESphynx] is now known as ESphynx
[02:27] <ajmitch> micahg: nice to see that openclipart is still building, 16 hours later... :)
[02:54] <micahg> ajmitch: yeah, it got one of the slower builders
[02:59]  * ajmitch just hopes it won't need to be uploaded again
[02:59] <micahg> ajmitch: nah, should be fine :)
[03:00] <micahg> ajmitch: Finished 5 minutes ago (took 17 hours, 20 minutes, 54.0 seconds)
[03:00] <ajmitch> as long as I don't get the blame ;)
[03:02] <ajmitch> those aren't small packages that it produces
[03:05] <micahg> nope
=== almaisan-away is now known as al-maisan
=== Whoopie_ is now known as Whoopie
=== al-maisan is now known as almaisan-away
[07:05] <dholbach> good morning
[07:55] <Whoopie> Good morning! Could someone of the devs help me fixing this build failure? -> https://launchpadlibrarian.net/98423805/buildlog_ubuntu-precise-armel.sflphone_1.0.2-1ubuntu1_FAILEDTOBUILD.txt.gz
[07:55] <Whoopie> cjwatson sponsored the sflphone package, but it fails on armel and armhf.
[07:56] <Whoopie> I can't find the cause because the build looks the same for i386 and amd64.
[08:01] <Zhenech> o/ Whoopie
[08:01] <Zhenech> Whoopie, my eyes tell me, that it tries to link to stupid things, just don't ask me why :)
[08:01] <Zhenech> does it happen on debian too?
[08:02] <Zhenech> yes it does
[08:04] <Whoopie> Zhenech: hey. It seems as the linking looks the same on all archs.
[08:05] <tumbleweed> Zhenech: the problem appears to be that it's creating libpjsip-armv7l-unknown-linux-gnu.a but trying to link to libpjsip-armv7l-unknown-linux-gnueabi.a
[08:10] <Whoopie> tumbleweed: your eyes are really better then mine. ;-)
[08:11] <tumbleweed> took me a minute to see it
[08:12] <tumbleweed> the correct tuple is the eabi one. So you need to figure out where the other one is coming from
[08:12] <tumbleweed> err correct gnu triplet
[08:16] <Whoopie> tumbleweed: could it be that the gnueabi is derived from the "checking build system type"
[08:16] <Whoopie> ?
[08:17] <tumbleweed> I suggest debugging it under qemu / a qemu-user-static chroot
[08:18] <Whoopie> ok
[08:18] <tumbleweed> pbuilder-dist knows how to create arm chroots
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
[08:53] <Whoopie> tumbleweed: I used this -> https://wiki.ubuntu.com/ARM/RootfsFromScratch
[08:53] <Whoopie> is it also ok?
[09:00] <vibhavp> Do i need to suscribe the review team when submiting debdiffs for precise?
[09:02] <dholbach> vibhavp, 'ubuntu-sponsors'? yes :)
[09:04] <tumbleweed> Whoopie: I remember running into bugs in that but yes, it should work
[09:06] <vibhavp> dholbach: I mean the Ubuntu Review Team
[09:08] <vibhavp> Since we have passed FF
[09:09] <tumbleweed> vibhavp: https://wiki.ubuntu.com/FreezeExceptionProcess
[09:12] <vibhavp> tumbleweed: I sorry I used the word review instead of release
[09:12] <vibhavp> This means, should I suscribe the Ubuntu Release team when submiting a debdiff for precise?
[09:13] <Laney> if you need a freeze exception, yes
=== dholbach_ is now known as dholbach
[09:22] <vibhavp> dholbach: Thanks for uploading my debdiff!
[09:22] <dholbach> vibhavp, I hope you didn't mind I made a few modifications
[09:23] <vibhavp> dholbach: Could you send me the modified debdiff, Ill use it as an example to improve my skills
[09:25] <dholbach> vibhavp, http://launchpadlibrarian.net/98511604/kupfer_0%2Bv206%2Bdfsg-1_0%2Bv206%2Bdfsg-1ubuntu1.diff.gz
[09:34] <Whoopie> tumbleweed: any idea where to start debugging? It seems to be an autotools issue (according to a quick google search).
[09:43] <tumbleweed> Whoopie: I'm no autotools expert, I can't say without looking at it
[10:23] <savvas> hello, does this mir request look ok to you? https://bugs.launchpad.net/ubuntu/+source/libgxps/+bug/965467 - I think I included everything the requirements wiki page suggested
[10:23] <ubottu> Launchpad bug 965467 in libgxps (Ubuntu) "[MIR] Please transfer libgxps 0.2.2-1 (universe) to main" [Undecided,New]
[10:27] <Laney> looks complete, yes. You should speak to the desktop team about whether they want to push it
[10:37] <savvas> hi Laney :) thanks again for sponsoring the package!
[10:37] <Laney> you're quite welcome
[11:45] <Rhonda> hmmm, missed 4 new mixtapes from dholbach, wtf :)
[11:45]  * Rhonda hugs Laney for accepting wesnoth-1.10 :)
[11:45] <dholbach> Rhonda, a shame you weren't there on Saturday in Berlin - it was a great night :)
[11:46] <Laney> \o/
[11:46] <Laney> still in the NEW queue unfortunately
[11:46] <Laney> there are quite a number of steps
[11:46] <Rhonda> dholbach: Well, there was sorta birthday party for my son at Saturday in our house, so …  :)
[11:47] <dholbach> haha, great :)
[11:47] <Rhonda> Laney: what, NEW queue, rmadison -uubuntu wesnoth-1.10 says it's already in?
[11:47] <dholbach> I recorded the session, but it's >1G and not quite up to my usual mixtape standards - but it was a great party nonetheless
[11:47] <Laney> Rhonda: the source yes, but not the binaries
[11:47] <Laney> e.g. https://launchpad.net/ubuntu/oneiric/+queue
[11:48] <Rhonda> hmmm
[11:48] <Laney> never mind, someone will get to it soon
[11:48] <Rhonda> uhm, then my dent about it was too soonish.  %-(
[11:49] <Laney> still technically correct ^o)
[11:49] <Rhonda> Have to push an update soonish anyway, the help file translations are missing. %-/
[11:50] <Rhonda> see http://bugs.debian.org/664164
[11:50] <ubottu> Debian bug 664164 in wesnoth-1.10 "[wesnoth-1.10] Help translations missing" [Normal,Open]
[12:04] <ryanakca> What would be the appropriate version for a no changes rebuild? Current: 2.0.0-1, Rebuild: 2.0.0-1build1 ?
[12:09] <StevenK> ryanakca: That would be fine, yes.
[12:10] <ryanakca> StevenK: Alright, and I'm guessing I need to also Maintainer -> XSBC-Orig-Maintainer ?
[12:11] <StevenK> I'm not sure. I would probably ignore it, just since it's a no-change rebuild.
[12:15] <ryanakca> StevenK: Alright, thanks, debcommitting and pushing :)
[12:23] <Laney> yeah, no need to change that unless you make actual changes
[12:26]  * ryanakca nods, lp-proposed, thanks :)
=== imbrando1 is now known as imbrandon
[13:07] <vibhavp> While preparing a patch (ubuntu delta) , what do I put in the "Uploaders" Section?
[13:11] <vibhavp> /window/window 2
[13:15] <Whoopie> cjwatson: I have attached the debdiff to bug report 913018 (https://bugs.launchpad.net/bugs/913018)
[13:15] <ubottu> Launchpad bug 913018 in sflphone (Ubuntu) "sflphoned crashed with SIGSEGV in std::__detail::_List_node_base::_M_hook() from DBus::DefaultWatch::DefaultWatch" [Medium,Fix released]
[13:16] <Whoopie> cjwatson: sflphone built find for amd64/i386 in my testing PPA and for armel in the qemu chroot.
[13:20] <Whoopie> cjwatson: should I attach the armel build log to the ticket?
[13:21] <cjwatson> don't care
[13:23] <cjwatson> Whoopie: I think it would be a good idea to keep config.guess and config.sub in sync
[13:23] <cjwatson> it is not usually recommended to update them independently
[13:24] <Whoopie> cjwatson: ok.
[13:24] <cjwatson> (I don't think that needs another test build TBH, I'd be happy to apply a diff that just did that)
[13:30] <Whoopie> cjwatson: how to name the patch file then?
[13:30] <cjwatson> "config-guess-sub" or just "config"
[13:30] <cjwatson> not that important :)
[13:46] <vibhavp> */window 2
[13:48] <Whoopie> cjwatson: updated debdiff attached.
[13:51] <cjwatson> Whoopie: thanks, uploaded
[13:51] <cjwatson> (modulo beta freeze)
[13:52] <Whoopie> cjwatson: thank you!
=== al-maisan is now known as almaisan-away
[16:28] <kirkland> is there a PPA I can depend upon to get a package that needs "dh clean --with python2" to build on lucid?
[16:28] <kirkland> a backports ppa or something?
[16:29] <tumbleweed> kirkland: not that I'm aware of
[16:29] <kirkland> tumbleweed: okay, thanks
[16:29] <kirkland> tumbleweed: any known workaround?
[16:30] <tumbleweed> besides pysupport?
[16:30] <tumbleweed> barry: ^
[16:59] <PaoloRotolo> Hi all!
[17:10] <vibhavp> Is it a coincidence the dholbach's nick starts with "dh" ?
[17:26] <hakermania> Hello, World! If you have your application 'sitting in the archive  admin / release team review queue', how do you know whether your package has been accepted or not (what changes in order to realize it)? See bug #964451 last answer :P
[17:26] <ubottu> Launchpad bug 964451 in wallch (Ubuntu) "FFE: Wallch 3.01" [Undecided,Fix committed] https://launchpad.net/bugs/964451
[17:29] <hakermania> I can see that the application has been uploaded (https://launchpad.net/ubuntu/+source/wallch) but I don't know where to search for 'accepted' or similar...
[17:36] <cjwatson> hakermania: you'll get mail when it's accepted
[17:37] <cjwatson> uh, but that *has* been accepted
[17:37] <cjwatson> your error was in not putting "LP: #964451" somewhere in the changelog so that it would auto-close the bug
[17:38] <cjwatson> I've closed the bug now
=== yofel_ is now known as yofel
[17:44] <hakermania> cjwatson, thanks:) But, seriously, was it my bad? Here: http://tinyurl.com/caafqv2 it doesn't say somewhere that the changelog should close the bug the I open... :/
[17:44] <cjwatson> it's not mandatory to auto-close bugs, but if you want them to be auto-closed then that's the only way to do it.
[17:45] <cjwatson> otherwise you should close them following the mail you got when the package was accepted.
[17:45] <hakermania> cjwatson, OK! Thanks again. One last question, do you know whether this accepted application will land in Beta 2?
[17:45] <hakermania> (will be in usc in beta 2)
[17:45] <cjwatson> it's in the archive now and beta 2 hasn't been released yet
[17:45] <cjwatson> so yes
[17:45] <hakermania> cool :)
[18:00] <barry> kirkland: sadly, no
[18:01] <kirkland> barry: okay, thanks, no worries
[18:01] <kirkland> barry: no one should run 10.04 any more anyway :-P
[18:01] <kirkland> bring on the 12.04s!
[18:01] <barry> kirkland: exactly :)
[18:06] <jtaylor> barry: I think I finally have a working scipy patch
[18:06] <jtaylor> see the branch
[18:08] <jtaylor> the changelog still needs work
[18:09] <barry> jtaylor: awesome, let me try building it locally
[18:10] <barry> jtaylor: could you link the branch to bug 960595?
[18:10] <ubottu> Launchpad bug 960595 in python-scipy (Ubuntu) "FFe for python3 scipy packages" [Undecided,New] https://launchpad.net/bugs/960595
[18:13] <jtaylor> it is interesting that the -dbg test brings down the interpreter
[18:13] <jtaylor> but thats the case for the old packages too
[18:13] <jtaylor> so no regression
[18:13] <jtaylor> one non-dbg test fails also no regression
[18:39] <barry> ScottK: i suppose i should file ffe's for all the other flufl.* packages?
[18:40] <ScottK> Yes.
[18:40] <ScottK> Feel free to do it all in one bug.
[18:40] <barry> cool.  i'll file them after you've reviewed and uploaded .password and .bounce (coming soon
[18:43] <barry> jtaylor: in your branch, why did you remove all the -1buildN entries in changelog?
[18:44] <jtaylor> they are just rebuilds not realyl necessary to keep them
[18:44] <jtaylor> at least I have been told that in the past
[18:44] <barry> jtaylor: hmm, it seems to lose information though, which i don't like.  maybe ScottK has an opinion on that?
[18:45] <ScottK> jtaylor: IME, generally you just drop changelog entries when syncing from Debian.  I'd keep them.
[18:45] <barry> jtaylor: also, X-Python-Version: >= 3.1... is that for consistency w/debian?  (ubuntu only cares about >= 3.2)
[18:45] <ScottK> Actually that only matters on Ubuntu.
[18:45] <jtaylor> scipy works with 3.1
[18:46] <ScottK> No, I take that back.
[18:46] <jtaylor> I had the impression that should denote the oldest version supported by the source
[18:46] <ScottK> barry: Explicit is better tahn implicit.
[18:46] <jtaylor> which makes backport situation clear
[18:46] <barry> ScottK: cool, no problem with that then
[18:46] <ScottK> Yeah.
[18:47] <barry> jtaylor: okay, i'm going to comment in the ffe bug, but i approve of the patch with the restoration of the d/changelog entires
[18:47] <barry> *entries
[18:47]  * ScottK just watched the BDFL's Pycon keynote on Youtube, so is feeling particularly Pythonic today.
[18:48] <barry> ScottK: you know how much he hates doing those? :)
[18:48] <ScottK> He mentioned it.
[18:48] <jtaylor> ScottK: keep or remove the +build changelogs?
[18:48] <ScottK> It was a good talk though.  I learned some things.
[18:48] <ScottK> jtaylor: Keep
[18:48] <jtaylor> k
[18:48] <barry> me too!
[18:49] <ScottK> Don't mess with history unless you can sync with Debian.
[18:49] <pabelanger> Any suggestions on bug 965484?  Should redmine be rolled back or a new sync request for ruby-rack?
[18:49] <ubottu> Launchpad bug 965484 in redmine (Ubuntu) " redmine : Depends: ruby-rack (>= 1.4.0) but 1.3.5-1 is to be installed " [High,Triaged] https://launchpad.net/bugs/965484
[18:50] <barry> jtaylor, ScottK https://bugs.launchpad.net/ubuntu/+source/python-scipy/+bug/960595/comments/2
[18:50] <ubottu> Launchpad bug 960595 in python-scipy (Ubuntu) "FFe for python3 scipy packages" [Undecided,New]
[18:50] <ScottK> pabelanger: I'd be inclined to more forward.
[18:51] <pabelanger> ScottK, Ya, if people agree with bumping ruby-rack, I can setup the FFe
[18:53] <ScottK> pabelanger: There are a few other rdepends.  They'll need to be checked for compatibility.  See apt-cache rdepends ruby-rack.
[19:00] <jtaylor> changelog restored
[19:00] <jtaylor> I'll forward the patch to debian then upload
[19:02] <ScottK> barry: Next time you can use the -b option and close the FFe bug when you do the sync.
[19:09] <barry> ScottK: ah crap, i meant to do that. sorry
[19:12] <jtaylor> uploaded, thanks for the review
[19:36] <pabelanger> ScottK, understood
[19:37] <barry> ScottK: i'll now file a blanket ffe for flufl.*[!enum]
[19:43] <barry> ScottK: bug 966521
[19:43] <ubottu> Launchpad bug 966521 in flufl.bounce (Ubuntu) "[FFe] sync flufl.{bounce,password,i18n,lock} from Debian" [Undecided,New] https://launchpad.net/bugs/966521
[19:52] <ScottK> barry: Approved, but you got some of the tasks on the upstream projects and not the Ubuntu packages.
[19:54] <barry> ScottK: fixed, thx
[20:01] <barry> ScottK: i'll sync as they hit lp
[20:01] <ScottK> Sure.  Hopefully they won't be in New very long.
[20:55] <jtaylor> youtube-download is broken precise again it seems... such an app really should not be packaged
[20:57] <jtaylor> good seems non-ffe syncable
[20:59] <micahg> jtaylor: the nature of the beast
[21:00] <micahg> this is where volatile would be nice :)
[21:00] <micahg> eh, I guess an SRU would serve the same purpose
[21:02] <jtaylor> I don't really care that much about it, opera does the same much much more reliable for every site
[21:02] <jtaylor> unfortunatly the flash plugin in opera does not work in my new precise installation and I want to watch the pycon keynot in higher speed :/
=== JanC_ is now known as JanC
[21:53] <jtaylor> hm  just got a mail, scipy powerpc build failed, but it hasn't even started yet according to https://launchpad.net/ubuntu/+source/python-scipy/0.9.0+dfsg1-1ubuntu1/+build/3323364
[21:54] <micahg> if I've got a conf file I forgot to migrate, do I add snippets to move and remove or just remove?
[22:07] <RAOF> micahg: How long has the package been not reading the old conf file?
[22:07] <micahg> RAOF: about 18 hours :)
[22:07] <RAOF> If it's only in Precise, then I'd move-and-remove.
[22:08] <micahg> should I attempt to be smart and remove the new file so the old one can migrate?
[22:08] <RAOF> Oh!  Totally move-and-remove; there's a good chance that even those on precise won't have edited the new conf file!
[22:09] <RAOF> micahg: I think the correct thing to do would be to remove the new conf file and replace it with the migrated old conf iff the new conf hasn't been changed.
[22:10] <micahg> RAOF: so does that mean I can't use the pretty dpkg-maintscript-helper stuff for the first part?
[22:11] <micahg> oh, I can lie :0
[22:11] <RAOF> :)
[22:11] <RAOF> I think you can still use the maintscript helper ;)
[22:11] <micahg> yeah, I just lie about the last-version
[22:12] <RAOF> Hm.  Will that successfully trigger on upgrades?
[22:12] <micahg> I'm going to test it :0
[22:13] <RAOF> (If it gets too hairy it's probably not *terrible* to just unconditionally migrate the old conf file; 18 hours isn't very long.)
[22:13] <micahg> well, I added an rm_conffile statement first, then the mv_conffile statement
[22:18] <micahg> RAOF: nope, my idea just wiped all of it :)
[22:18]  * micahg tries just a move
[22:23] <micahg> yeah, I'll just clobber the new file
[23:28] <broder> jtaylor: you know we have precedent for just SRU'ing new upstream releases of youtube-dl, right?
=== rsalveti` is now known as rsalveti