[00:40] <persia> ivoks, Without a doubt, indeed.
[00:47]  * Laney is in MCO
[00:48] <stgraber> Laney: waiting for the cab ?
[00:48] <Laney> shuttle bus
[00:48] <Laney> anyone around?
[00:48] <stgraber> a few arriving at the hotel already
[00:48] <stgraber> *arrived
[00:49] <Laney> cool
[00:49] <Laney> am rather wiped though: It's 1am for me and I've been travelling since 8am
[00:50] <stgraber> heh
[00:51] <stgraber> I arrived here on Thursday, flying from Montreal, so same timezone and only a 3 hours direct flight. The weather is quite different tough :)
[00:51] <Laney> I look forward to enjoying it when I do some exploring tomorrow :)
[00:59] <RoAkSoAx> stgraber: what's the temperature?
[01:02] <ScottK> "warm"
[01:02] <ScottK> Not Peru Amazon basin warm, but warm enough.
[01:03] <stgraber> RoAkSoAx: a bit under 25C which is a good 20C more than my usual end-of-October weather ;)
[01:04] <RoAkSoAx> stgraber: its cold for me :) I'm 27 right now
[01:04] <RoAkSoAx> :)
[01:05] <stgraber> RoAkSoAx: but it's not raining here ;)
[01:06] <RoAkSoAx> stgraber: i really hope it stays like that the whole week
[01:06] <RoAkSoAx> it's a PITA when it rains
[01:11] <persia> Whenever I've been in Florida, it has rained every day, at 14 local time, for 20-45 minutes, depending on the number of clouds.
[01:11] <kklimonda_> :)
[01:13] <stgraber> persia: I was out at that time today, it didn't ;) must only happen when you are around
[04:39] <lfaraone> Package python-keyczar is in Squeeze, but FTBFS on Maverick and Natty. The tests don't seem to be run, because when built for sid / squeeze a "build/lib" directory AND a "build/lib.linux-x86_64-2.6" directory is created, but in natty only "build/lib.linux-x86_64-2.6" is created. (the tests point to "build/lib")
[04:40] <lfaraone> Should the tests portion of the build process be amended, or is there something odd with Ubuntu's distutils? Full logs from all three builds are at http://pastebin.com/TCdJGi5Z
[04:41] <ScottK> lfaraone: Does it FTBFS even with python2.7 supported?
[04:41] <ScottK> When I've seen such things before it was because of only having a single version supported.
[04:42] <ScottK> In Debian the tests would run out of sequence, but only not fail because python2.5 had created the things that the python2.6 tests needed to run.
[04:42] <ScottK> It's likely something to do with build sequence.
[04:42] <ScottK> Ubuntu's distutils is no odder than Debian's.
[04:44] <lfaraone> ScottK: pyversions is "2.4-"
[04:45] <ScottK> Right, but in Ubuntu the default python is a lower version that the alternate and in debian it's the reverse.
[04:45] <ScottK> So I suspect the test suite is run in a different place in the build.
[04:45] <lfaraone> ScottK: the test suite is run in a overridden debhelper rule.
[04:45] <lfaraone> ScottK: 2.4-
[04:45] <lfaraone> ~
[04:45] <lfaraone> ScottK: er, http://pastebin.com/6M7J5fCi
[04:46] <lfaraone> ScottK: in the Ubuntu builds, build/lib doesn't exist.
[04:47] <ScottK> I also have a vague recollection of distutils defaults changing in 2.6
[04:47] <ScottK> Since Debian runs it both for 2.5 and 2.6 is still exists.
[04:47] <ScottK> Since Ubuntu runs it for 2.6 and 2.7 you only get the new location.
[04:48] <lfaraone> ScottK: ugh, that'd make the rules file complicated.
[04:49] <crimsun> complicated is probably manageable.  At least you don't munge configuration files in debian/rules.
[04:49] <lfaraone> ScottK: so if version to test is <2.6, use build/lib, otherwise use the newfangled bin/lib.$OS-$ARCH-$PYVERSION mechanism, I guess.
[04:49] <lfaraone> crimsun: er?
[04:50] <ScottK> lfaraone: Something like that.
[05:20] <lfaraone> ScottK: okay. so now the tests run in both Debian and Ubuntu. They fail in Ubuntu, of course, because our version of pycrypto is too old. Pycrypto's in Main, I'm somewhat frightened to touch it.
[05:21] <ScottK> There's a merge pending for that, IIRC
[05:29] <lfaraone> ScottK: ah, there is, bug #662883
[11:08] <ari-tczew> how I should set status for bzr merge review for non showing up on sponsors overview? e.g. https://code.launchpad.net/~funkyhat/ubuntu/maverick/gnome-system-tools/fix-630615/+merge/34632
[11:21] <tumbleweed> ari-tczew: rejected. When that isn't an option, you can use work-in-progress
[12:39] <ari-tczew> can we get mass-auto-sync of new packages from Debian?
[13:00] <ari-tczew> siretart: did you test build before uploading xine-lib?
[13:11] <geser> ari-tczew: you need to bribe archive admins for that as they need to review them before they enter
[13:12] <geser> if you don't want to wait till it happens and need a new package now, you can requestsync it
[13:13] <ari-tczew> geser: aha, even if I have chmod +x universe/multiverse, do I need use requestsync for new package?
[13:14] <geser> you can syncpackage it too (with the same reservations about usage of syncpackage)
[13:16] <tumbleweed> but new packages need archive-admin review, no matter how they arrive, so there's no good reason not to requestsync
[13:21] <ari-tczew> tumbleweed: do you mean rather 'no good reason against requestsync' ?
[13:26] <tumbleweed> ari-tczew: yes, 'against using requestsync'
[13:55] <ScottK> tumbleweed: They will get sync'ed eventually without someone having to waste time on a bug, so unless it's really important, using requestsync at this stage wastes people's time.
[13:55] <ScottK> I think that's a good reason not to.
[14:52] <ari-tczew> ScottK: so, what's the conclusion? which way is good to quickly get new packages from unstable?
[15:12]  * micahg uses a PPA if something is needed quickly
[15:16] <ari-tczew> micahg: for official repos....
[15:16]  * ari-tczew facepalms
[15:18] <micahg> ari-tczew: it all depends on why you need the package quickly, for me it's personal use generally, so PPA or pbuilder works
[15:19] <ari-tczew> micahg: I don't play with PPA. In some cases, packages are FTBFS or not installable due to non existing packages. Then I'd like to sync it.
[15:29] <micahg> ari-tczew: ah, this early, if it's only blocking a few non-critical packages, I'd suggest watching the natty-changes list for the package and then give back the FTBFS packages when it's sync'd
[15:35] <micahg> ari-tczew: also, I think there might be a bug in soyuz since DEP_WAIT packages should fail differently than other FTBFS
[15:41] <xteejx> Hi all
[15:42] <xteejx> I'm trying to fix the ftbfs for alpine, not sure where to add -lkrb5
[15:42] <xteejx> It uses cdbs
[15:51] <ari-tczew> xteejx: if it add fixes FTBFS, what's the problem?
[15:51] <xteejx> huh?
[15:51] <xteejx> I'm trying to fix the ftbfs by adding -lkrb5, but I don't know where to add it
[15:54] <coolbhavi> xteejx, either in rules file or configure.ac or makefile.am depending on situation
[15:54] <coolbhavi> :)
[15:54] <xteejx> I'll have a look at those, hopefully find something :) Thank you
[15:55] <coolbhavi> :)
[15:56] <ari-tczew> xteejx: debian/rules, add it to LDLFAGS
[15:56] <ari-tczew> LDFLAGS*
[15:56] <xteejx> I tried that, it wouldn't work
[15:56] <xteejx> I thought the preferred way was to change the source and upstream it?
[16:00] <tumbleweed> xteejx: the preferred way is the simplest way. But yes, please upstream a patch if possible.
[16:00] <xteejx> So if I _can_ do it with d/rules, I can but tell debian?
[16:00] <micahg> tumbleweed: if you have a chance today, could you please comment on my MOTU application since you sponsored most of my uploads?
[16:01] <tumbleweed> micahg: yes, on my todo list for today
[16:01] <micahg> tumbleweed: awesome, thank you
[16:02] <tumbleweed> xteejx: sure
[16:02] <xteejx> http://paste.ubuntu.com/519276/ is the d/rules file, I tried...
[16:03] <xteejx> LDFLAGS="-Wl,-z,-lkrb5,defs,--as-needed" --with-krb5  << but it wouldn#'t work
[16:03] <xteejx> i.e. adding -lkrb5
[16:04] <ari-tczew> xteejx: buildlog?
[16:04] <tumbleweed> xteejx: that's adding -lkrb5 to the -Wl list (ld options), which probably isn't what you want
[16:05] <xteejx> Is that th first bit it does that I s
[16:05] <xteejx> Hmm
[16:05] <xteejx> Oops
[16:05] <xteejx> I don't see this one being simple :(
[16:06] <xteejx> *simple-ish
[16:08] <xteejx> http://paste.ubuntu.com/519278/ line 30, I could add -lkrb5 at the end right, since that's where make gets called??
[18:53] <siretart> ari-tczew: I did, but not in a minimal chroot, I obviously had some additional packages in my vm
[18:55] <ari-tczew> siretart: Odd. Suggest use pbuilder-dist.
[19:02] <ari-tczew> siretart: do you will fix this FTBFS?
[19:34] <siretart> I can look at it later tonight or tomorrow. I'll first try to not install the offending pluing and see if gxine/xine-ui are still usable
[20:10] <lfaraone> If I just need to do a no-change-rebuild to a package with "ubuntu1" in the version part, should I make it "ubuntu1build1" or "ubuntu2"?
[20:11] <tumbleweed> I'd say ubuntu2
[20:12] <lfaraone> Okay. If a package builds binary Python modules, and it was last built in Maverick, it'll need a rebuild for natty to get the 2.7 modules built, right?
[20:12] <tumbleweed> yes, but be aware that python-support doesn't work in natty atm
[20:12] <tumbleweed> (it doesn't have 2.7 added, and it needs it)
[20:13] <lfaraone> tumbleweed: pycentral?
[20:13] <tumbleweed> should be fine
[20:14] <tumbleweed> AFIAIK: the differentiation for build1 and ubuntu1 is for the purposes of auto-syncing, so once we have a delta, we don't need to be clear that it's only a rebuild in the version number
[20:23] <lfaraone> tumbleweed: hmm. would you mind doing a no-change rebuild of python-crypto? I just realized it's in main, so I can't upload it. (should I put up a bzr branch, debdiff? I thought it might be too trivial)
[20:24] <tumbleweed> lfaraone: I'm not a core dev :)
[20:24] <geser> python-crypto? doesn't it have a pending merge bug?
[20:24] <tumbleweed> yeah, my merge bug
[20:24] <lfaraone> geser: yes.
[20:24] <lfaraone> geser: so, alternatively, we can merge it.
[20:25] <lfaraone> from my reading of bug #662883 further discussion was in order.
[20:26] <tumbleweed> lfaraone: we moved the discussion to another bug, it just needs a core-dev to sponsor th emerge
[20:26] <lfaraone> ah, okay then :)
[20:26] <tumbleweed> unfortunatly the merge brought up policy issues...
[20:29] <lfaraone> mk. well, python-crypto is blocking python-keyczar which is blocking a new unnamed package I'm working on. So I want to see what I can do to get this fixed.
[20:29] <highvoltage> tumbleweed: what!? you're not a core-dev yet!? :p
[20:31]  * lfaraone was suprised. 
[20:31] <tumbleweed> highvoltage: lol
[20:32] <AlanBell> I am trying to set up pbuilder to test a packaging recipe, it is failing but I don't really understand why. The end of the output from sudo pbuilder build is http://paste.ubuntu.com/519378/
[20:33] <AlanBell> I have been following the guide here https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted and my recipe is at https://code.edge.launchpad.net/~alanbell/+recipe/daily-dash-of-dasher
[20:34] <directhex> does it have a configure? e.g. do you need to run autogen.sh?
[20:35] <AlanBell> it has a configure
[20:35] <AlanBell> no, I lied
[20:35] <AlanBell> it has a configure.ac and autogen.sh
[20:35] <AlanBell> http://bazaar.launchpad.net/~vcs-imports/dasher/master/files
[21:22] <directhex> AlanBell: then you need to run autogen.sh, not configure. autogen will make the configure exist
[21:23] <AlanBell> hmm, ok, so the packaging is wrong for that source then?
[21:23] <AlanBell> how did it successfully build the other day on Lucid?
[21:24] <directhex> AlanBell: are you doing daily builds?
[21:24] <AlanBell> trying to
[21:24] <Laney> i don't understand what that recipe says
[21:24] <directhex> and a tarball was fine?
[21:24] <Laney> why do you get an error relating to cdbs?
[21:24] <Laney> that sounds like a missing build depend
[21:24] <Laney> dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 5.0.0) cdbs gnome-pkg-tools (>= 0.6) intltool (>= 0.40.1) libexpat1-dev libglib2.0-dev (>= 2.16.0) libgtk2.0-dev (>= 2.12.0) libx11-dev libxtst-dev libgnomeui-dev libgnome-speech-dev libbonobo2-dev liborbit2-dev libatspi-dev libatk1.0-dev libgconf2-dev gnome-doc-utils (>= 0.9.0) scrollkeeper
[21:24]  * Laney is rather confused
[21:25]  * AlanBell is very confused
[21:26] <Laney> might be a bug, try #launchpad
[21:26] <Laney> never done any recipe stuff, sorry
[21:26] <Laney> but it sounds like a problem with that system rather than a packaging issue
[21:29] <AlanBell> oh, interesting, thanks
[21:30] <AlanBell> I literally took the /debian directory from the package in Maverick and put that in bzr and the recipe takes the gnome git tree and adds the packaging and builds it
[21:33] <Laney> why doesn't it install the build deps?
[21:33] <AlanBell> well, not sure that it is recipes that is wrong
[21:33] <Laney> it at least gets them from somewhere
[21:34] <AlanBell> maybe it has moved to automake since the version in maverick
[21:35] <AlanBell> ah, looks like it has
[21:35] <tumbleweed> it's also normal for packages to have configure in the release tarballs but not in the VCS
[21:36] <tumbleweed> so your daily build rules might need to be different
[21:36] <AlanBell> hmm, ok
[21:36] <AlanBell> a few extra wrinkles in the recipe then
[21:38] <AlanBell> so does that go in the recipe or the packaging?
[21:38] <directhex> tumbleweed: that was my point, but i think AlanBell didn't notice it
[21:38] <directhex> 21:24 <directhex> AlanBell: are you doing daily builds?
[21:38] <directhex> 21:24 <directhex> and a tarball was fine?
[21:39] <tumbleweed> directhex: yes, that's why I broughte it up again :)
[21:40] <AlanBell> well it wasn't a tarball that was fine it was a daily build that was fine https://code.edge.launchpad.net/~alanbell/+recipe/daily-dash-of-dasher/+build/5289
[21:40] <AlanBell> I haven't tried a tarball
[21:43] <AlanBell> so it seems from here https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted#Packaging that it needs to run autoreconf -i somewhere. In the receipe? somewhere in the debian stuff?
[21:44] <tumbleweed> in debian/rules before configure is called (sorry I don't know enough CDBS to tell you how to do that)
[21:46] <directhex> yeah, i don't really support cdbs
[21:47] <AlanBell> gah, can't even see where configure is being called http://bazaar.launchpad.net/~alanbell/dasher/debian/annotate/head:/rules
[21:47] <tumbleweed> AlanBell: welcome to cdbs :)
[21:50] <tumbleweed> aah, it's in the documentation, that's rare: "To add pre-configure actions" - http://build-common.alioth.debian.org/cdbs-doc.html
[21:54] <AlanBell> should it include /usr/share/cdbs/1/class/autotools.mk
[21:55] <tumbleweed> I think gnome implicitly includes that
[21:56] <AlanBell> ok, so at the end of the rules I add
[21:56] <AlanBell> makebuilddir/dasher:: autoreconf -i
[21:57] <AlanBell> or should it be autogen.sh?
[21:59] <tumbleweed> probably autogen.sh (if there is one) because that's what upstream would run before producing a tarball
[21:59] <tumbleweed> you will probably need some extra build-deps
[22:43]  * AlanBell is still befuddled
[22:43] <AlanBell> http://paste.ubuntu.com/519417/ <- failing locally in pbuilder
[22:44] <AlanBell> https://code.edge.launchpad.net/~alanbell/+recipe/daily-dash-of-dasher but in launchpad it builds on Lucid, but fails on Maverick
[22:46] <tumbleweed> AlanBell: it's still building on lucid: https://code.edge.launchpad.net/~alanbell/+archive/ppa/+build/2016909 - only the source package build worked (so far)
[22:47] <AlanBell> oh ok
[22:47] <tumbleweed> AlanBell: does the "gnome-common" package contain what you need? (I'm shooting in the dark here)
[22:48] <AlanBell> no idea
[22:48] <Laney> have a look at what test produces that error message
[22:49] <AlanBell> which error message?
[22:50] <AlanBell> ok, so one thing it says in the pbuilder output is "You need to install gnome-common from the GNOME CVS"
[22:50] <AlanBell> so I could add that as a build dependency I guess
[22:51] <tumbleweed> AlanBell: that comes from the autogen.sh, read that and find out how to get what it needs (gnome-autogen.sh)
[22:51] <AlanBell> really not sure why this isn't all just as easy as it sounds in the instructions!
[22:52] <tumbleweed> the instructions do at least mention this
[22:53] <tumbleweed> (well the fact that autotools packages don't tend to include generated code in $VCS)
[22:53] <AlanBell> "If your software for example is in Ubuntu or Debian, you are sorted out"
[22:53] <AlanBell> not quite the case!
[22:54] <tumbleweed> you won't have to re-invent the wheel though, just a couple of small changes :)
[22:55] <Laney> can't the recipe call autogen?
[22:56] <AlanBell> that would seem to me to be the right place to do it
[22:56] <tumbleweed> Laney: he's doing that, he just needs a build-dep on gnome-common (I think)
[22:56] <AlanBell> nope, not in the recipe
[22:56] <tumbleweed> oh, the recipe
[22:56] <Laney> i mean modifying the recipe instead of rules
[22:57] <tumbleweed> it looks like gnome-common isn't one of the standard recipe build-deps (recipes don't have user-specifyable build-deps)
[23:14] <AlanBell> http://paste.ubuntu.com/519426/ new set of errors to ponder
[23:15] <AlanBell> it wants a bunch of .m4 files moved about
[23:17] <AlanBell> and on launchpad totally different looking problem http://launchpadlibrarian.net/58157176/buildlog.txt.gz with build dependencies not satisfied
[23:21] <sivang> hi all
[23:22] <sivang> can anybody please send me the links for how to package python programs properly through distutils?
[23:26] <lfaraone> ScottK: so I proposed a change to the way the tests are run in python-keyczar, and the maintainer feels that it's not warranted. is there a good reason why http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601259#33 is a bad idea? (I feel that it is, but can't put it into words exactly)
[23:28] <lfaraone> ScottK: I mean, it's conceivable that at some point in the future the python module might put different files into different lib dirs, so you want to run the tests against that specific lib directory, right?
[23:34] <lfaraone> .