[00:22] <cnd> I'm trying to push to a ppa, but twice now I've received the following error back in the rejection email:
[00:22] <cnd> Rejected:
[00:22] <cnd> Unhandled exception processing upload: 'NoneType' object has no attribute 'md5'
[00:22] <cnd> any ideas?
[02:25] <kirkland> @pilot out
[04:25] <ScottK> cnd: PPA support is in #launchpad.
[04:25] <cnd> ScottK, ahh, thanks :)
[04:25] <twb> Is rmadison broken for anyone else just now?
[04:25] <twb> nm, it just returned... probably the server is just under load
[06:58] <pitti> Good morning
[06:59] <pitti> GrueMaster: that kernel needs a reupload now (and will presumably get further updates), I'm afraid
[07:00] <avinashhm> hi, i am facing an error with inserting ko's and removing them .. not able to remove them ... more logs @ http://paste.ubuntu.com/541312/ .. any help ???
[07:08] <pitti> SpamapS, james_w: hm, your new WI tracker change makes it crash now
[07:08] <pitti>     report_tools.blueprints_base_url, project.name)
[07:08] <pitti> AttributeError: 'str' object has no attribute 'name'
[07:09] <pitti> SpamapS, james_w: you once call it with a name (strnig) and once with an LP project object
[07:14] <pitti> I committed a fix now
[07:31] <didrocks> good morning
[08:31] <dholbach> good morning!
[08:32] <didrocks> hey dholbach!
[08:32] <dholbach> salut didrocks
[09:09] <raphink> hi there
[09:10] <raphink> how would I go about finding which packages Build-Depend on a given package?
[09:10] <raphink> say I want to find all the packages that Build-Depend on package foo
[09:10] <raphink> I can't seem to achieve this with apt-cache
[09:11] <raphink> and hi dholbach  :-)
[09:12] <didrocks> raphink: you should check build-rdeps in the ubuntu-dev-tools package
[09:12] <dholbach> salut raphink
[09:13] <raphink> thanks didrocks (and hi, too)
[09:13] <didrocks> raphink: it has some grep-dctrl magic IIRC
[09:13] <raphink> alright
[09:13] <raphink> I also just thought that I could grep in Sources.gz on my local mirror :-)
[09:13] <raphink> that might be faster :-)
[09:15] <raphink> thanks for the suggestion didrocks
[09:15] <didrocks> raphink: you're welcome :)
[09:48] <ev> @pilot in
[09:49]  * dholbach hugs ev
[09:52] <ev> :)
[10:37] <pitti> doko: FYI, I'm looking at fixing python-launchpad-integration
[10:38] <pitti> doko: python-indicate is in progress, but has some more dependencies, so it'll take a bit to fix still
[10:38] <pitti> seb128: you're looking at python-ubuntuone? I can take a look at ubuntu-sso-client after lpi
[10:39] <pitti> then there's python-uno and hplip left (which breaks CD builds)
[10:39] <seb128> pitti, I will ask rodrigo to debug libubuntuone
[10:39] <seb128> rebuild is not enough it has gir issues as well
[10:40] <pitti> ok
[10:40] <pitti> python-uno will take more time
[10:40] <pitti> my first attempt to monkey-patch one of the three current OO.o build failures failed :-(
[10:52] <pitti> GrueMaster: oh, the maverick ti-omap kernel is still in the queue; releaseing now
[11:08] <sabdfl> is this the best channel to ask about / report vanishing partition UUID's?
[11:15] <sabdfl> cjwatson: who's the best person to talk to re blkid?
[11:15] <sabdfl> i noticed that i had no swap
[11:16] <sabdfl> there's an entry in fstab for a swap partition, with UUID, and a note when it was created during an upgrade
[11:17] <sabdfl> however, the partition still existed (according to fdisk) but sans UUID
[11:17] <sabdfl> it was an sda5 inside an extended partition
[11:17] <sabdfl> so i deleted it and recreated it as an sda2 primary
[11:17] <sabdfl> but it still seems to have no UUID
[11:17] <sabdfl> any ideas?
[11:20] <pitti> sabdfl: can you pastebin the output of sudo BLKID_DEBUG=0xFFFF blkid -p /dev/sda2 ?
[11:21] <cjwatson> hallyn_: multipath-tools> perhaps you might volunteer? :-)
[11:22] <cjwatson> apw: RAM swap support> not quite sure what you mean ... do you mean compcache/ramzswap when booting the live CD?  that's mostly in initramfs-tools, with a configuration file in casper to enable it
[11:22] <pitti> sabdfl: I created a swap partition here, and I do get an uuid, so it's not trivial to reproduce
[11:27] <cjwatson> seb128: I've added exceptions for libcanberra and gobject-introspection
[11:27] <seb128> cjwatson, thanks
[11:27] <seb128> cjwatson, I hope you feel better today!
[11:28] <cjwatson> doko: on seeing what dh7 is doing: try DH_VERBOSE=1
[11:29] <cjwatson> CarlFK1: installer progress jumping backwards: it's not a symptom of anything other than that we haven't always gardened all the little tedious progress bar bugs :-)
[11:30] <cjwatson> hallyn_: what ssh bug is this?  I normally merge openssh into Ubuntu immediately after uploading it to Debian
[11:31] <cjwatson> sabdfl: Keybuk or pitti probably
[11:32] <cjwatson> seb128: somewhat ... not doing anything too strenuous
[11:32] <cjwatson> sabdfl: or lamont, he maintains util-linux in Debian
[11:34] <rodrigo_> hi
[11:34] <rodrigo_> doko, ping
[11:34] <seb128> rodrigo_, hey ;-)
[11:34] <seb128> doko, better to ping with context I guess
[11:34] <rodrigo_> hi seb128 :)
[11:34] <seb128> other people might be able to reply and doko would know what you want ;-)
[11:35] <rodrigo_> well, I wanted to ask doko about his libu1 submission:
[11:35] <rodrigo_>   * Rebuild to add support for python 2.7.
[11:35] <rodrigo_>  -- Matthias Klose <doko@ubuntu.com>  Fri, 03 Dec 2010 00:04:06 +0000
[11:35] <seb128> rodrigo_, doko has been doing no change uploads for everything using python basically
[11:35] <rodrigo_> I guess that was for fixing the multiple python versions issue we were having
[11:35] <seb128> so they get rebuilt with 2.7
[11:36] <rodrigo_> right, so it's still failing for me, with: configure: error: source directory already configured; run "make distclean" there first
[11:36] <rodrigo_> so I guess I need to upgrade some package?
[11:36] <seb128> rodrigo_, no,it failed in the archive as well
[11:36] <pitti> rodrigo_: sounds like this was a hidden bug all along
[11:36] <rodrigo_> but have already upgraded everything I can think of
[11:36] <pitti> rodrigo_: presumably you do two build trees?
[11:36] <rodrigo_> seb128, ah ok
[11:36] <seb128> rodrigo_, doko probably didn't investigate each upload, he did some hundred uploads
[11:37] <seb128> rodrigo_, that's mostly scripted I guess
[11:37] <pitti> rodrigo_: if you run configure from another directory which has the source, that directory must be clean
[11:37] <pitti> i. e. unconfigured
[11:37] <rodrigo_> pitti, yes, it configures several times, then make for each build tree
[11:37] <rodrigo_> ok, so it's not fixed then
[11:37] <pitti> rodrigo_: that's wong -- the source tree must be clean; then create the build trees, and call configure there, and only there
[11:37] <pitti> not in srcdir
[11:37] <pitti> rodrigo_: I guess it didn't matter as long as we just had one supported python versions
[11:37] <pitti> s/s$//
[11:38] <rodrigo_> right
[11:40] <apw> cjwatson, yeah thats the one thanks
[11:43] <axp2> hi all
[11:47] <doko> rodrigo_: yes, seen, and I submitted bug #684983
[11:48] <rodrigo_> doko, ok, fixing it then
[11:49] <axp2> hey guys, i'm currently working on a bug in software-center, wondering if someone can point me to the right channel to discuss it with someone?
[11:54] <soren> doko: python-greenlet needs a rebuild for python 2.7. Are you doing a mass upload for these rebuilds or should I just go ahead and do it myself?
[11:57] <soren> cjwatson: The dh_apport helper has your name on it.. Would it be ok to subscribe you to a bug about it? Don't know how closely you watch apport bugs (if at all).
[11:59] <ev> axp2: this is seemingly the right place.  Might want to flag down mvo if you have questions.
[12:00] <cjwatson> soren: not at all.  feel free to subscribe me
[12:00] <soren> cjwatson: Ta. done.
[12:01] <soren> doko: Just let me know. I've got it ready to go, since needed it in a ppa.
[12:01] <axp2> ev: thanks. have done that, looks like he's not here atm. will try him again later
[12:03] <doko> soren: please just do it yourself, some are still missing
[12:03] <soren> doko: Alrighty, thanks.
[12:05] <doko> soren: ahh, it doesn't have *any* deps on python, therefore I missed it
[12:05] <soren> doko: Hm.. Yeah.
[12:06] <soren> doko: It only provides a .so, so I suppose it doesn't really need the interpreter, but it still looks odd.
[12:07]  * soren wonders if there are others like it
[12:07] <soren> It b-ds on python-all-dev, though. (Naturally)
[12:07] <doko> soren: would be reason to use dh_python2 to generate these, and then explaining in the debian report, why you did it
[12:08] <soren> doko: Too late, I'm afraid. Already uploaded it 5 minutes ago.
[12:11] <doko> lucas: do you have any recent debian rebuilds of synopsis, obmenu, mirage?
[12:13] <doko> pitti: cdbs question: http://launchpadlibrarian.net/60353084/buildlog_ubuntu-natty-i386.obmenu_1.0-1ubuntu3_FAILEDTOBUILD.txt.gz
[12:14] <doko> the build tries to build for all supported python versions, not just for the default one
[12:15] <mvo> hey axp2
[12:17] <cjwatson> ev: could you please use lp:ubuntu/initramfs-tools?  it would have saved our uploads clashing ...
[12:17]  * cjwatson tries to sort out the history
[12:18] <ev> ah, sorry.  Is there a way of telling whether a package is just imported or people are actively using branches for it?
[12:18] <cjwatson> I'm not sure it matters in this case - you can just use the branch as a default if it's available
[12:19] <lucas> doko: I did a debian (squeeze) rebuild two days ago
[12:19] <cjwatson> ev: hm, your upload contained a .bzr-builddeb file - did you actually build it from a bzr branch and just forget to push?
[12:19] <doko> lucas: could you point me to the build logs? even if these were sucessful?
[12:20] <ev> cjwatson: indeed, I thought the way this usually worked was that the branch was constructed by using the regular uploads
[12:20] <ev> thus why I didn't bzr commit
[12:21] <cjwatson> oh.  it's usually best to commit/push if you can.  never mind, how about I just reconstruct it here since I need to merge anyway?
[12:21] <cjwatson> the importer won't overwrite the branch if there's a commit tagged with the version number of the upload
[12:21] <cjwatson> so you can interleave work in bzr with work not in bzr
[12:21] <lucas> doko: http://blop.info/pub/synopsis_0.12-6_lsqueeze64.buildlog http://blop.info/pub/obmenu_1.0-1_lsqueeze64.buildlog http://blop.info/pub/mirage_0.9.5.1-1_lsqueeze64.buildlog
[12:21] <lucas> doko: (all 3 successful)
[12:23] <doko> lucas: ok, thanks
[12:23] <ev> cjwatson: ahh, that alleviates all of my worry
[12:23] <ev> thanks for clearing that up
[12:25] <cjwatson> ev: np - the importer has beaten me to merging it so I'll just recommit on top
[12:29] <ev> thanks
[12:37] <tkamppeter> Anyone knows whether there is any problem with libxml2 in Natty? See bug 687973.
[12:39] <ScottK> tkamppeter: Are you subscribed to ubuntu-devel-announce?
[12:40] <tkamppeter> ScottK, I do not know.
[12:40] <tkamppeter> ScottK, seems not.
[12:41] <ScottK> tkamppeter: If you read that mailing list, you'd have read a mail from doko warning that we were switching to python2.7 as a default yesterday  and that a few days of problems with Python related packages are to be expected.
[12:41] <ScottK> I suspect that's the source of your current trouble.
[12:41] <doko> ScottK, tkamppeter: commented instead of suspecting.
[12:43] <tkamppeter> ScottK, I have read that, but is libxml2 Python-related?
[12:43] <tkamppeter> ScottK, I have also not done any update after reading that mail.
[12:46] <tkamppeter> ScottK, libxml2 depends only on libc6 and zlib1g, not on anything with Python.
[12:47] <cjwatson> tkamppeter: I suggest reading doko's comment on the bug before commenting further on IRC :-)
[12:51] <tkamppeter> cjwatson, sorry, did not see from doko's message that he meant that he has commented on the bug.
[12:53] <tkamppeter> doko, did gcc change to strikter requirements of command line order recently?
[12:53] <doko> tkamppeter: heh, *now* we come back to the u-d-a question ;)
[12:54] <doko> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000783.html
[12:54] <doko> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-October/000772.html
[12:55] <pitti> doko: obmenu> doesn't seem to be specific to cdbs; I can have a look later on
[12:55] <pitti> distutils.core not found looks weird
[12:55] <doko> pitti: obmenu has another cause, as I found
[12:56] <doko> pitti: but synopsis and mirage do build in debian, and don't try to use all python versions
[12:58] <pitti> doko: not sure what you mean? debian/rules explicitly does for buildver in 2.6 2.7 .., so why shouldn't it build for both?
[12:58] <tkamppeter> doko, thanks.
[12:59] <pitti> doko: ah, no, that seems to be distutils.mk; so is that wrong?
[12:59] <doko> pitti: it seems so, but it doesn't do that in unstable, trying to find out why ...
[13:00] <pitti> doko: ah, ok; I got the source now, and it's not even a python-* library, so building with the current versino should be sufficient
[13:01] <doko> pitti: otoh, I think this one is correct to fail, although I don't know why it doesn't fail in unsable: http://launchpadlibrarian.net/60373280/buildlog_ubuntu-natty-i386.python-opster_1.1-1_FAILEDTOBUILD.txt.gz
[13:04] <doko> pitti: yes, generally all the packages (applications) with a private python lib ftbfs
[13:06] <soren> distutils.core is in the python2.x packages, right?
[13:07] <soren> They are in Maverick, at least.
[13:08] <doko> soren: yes. the package thinks it should build for all supported python versions, and fails for 2.6, because the b-d is just python-dev. this behaviour is not seen in debian. trying to figure out why
[13:08] <soren> And the build log looks like python2.6 doesn't get pulled in.
[13:08] <soren> Ah.
[13:36] <janimo1> out of curiosity is it possible for a package to specify that it should be built with a non-default gcc (4.4 in this case) on the build servers?
[13:38] <seb128> janimo1, yes
[13:39] <seb128> you can set CC=gcc-4.4 or equivalent in the rules
[13:39] <seb128> with an adapted build-depends
[13:39] <janimo1> seb128: and add the explciit build depends
[13:39] <janimo1> aha, ok thank
[13:39] <seb128> but usually you probably want to fix your code to build with the current compiler
[13:39] <janimo1> this may temporarily needed only
[13:39] <janimo1> for ghc6
[13:39] <seb128> ok
[13:40] <seb128> check with doko maybe
[13:40] <janimo1> as it uses itself to build
[13:40] <janimo1> yes
[13:40]  * Laney sees ghc6
[13:40] <Laney> what's the problem?
[13:40] <janimo1> Laney: ARM FTBFS of many haskell packages because -lpthread is not passed, so Setup.hs does not compile
[13:40] <Laney> oh, yes
[13:41] <janimo1> ghc6 itself does not build with such a ghc6
[13:41] <Laney> I've fixed that locally I hope
[13:41] <Laney> -optl-pthread is the secret flag
[13:41] <janimo1> so first it may be fixed using gcc 4.4 which does not exhiobit that
[13:41] <janimo1> Laney: secret flag to be passed where?
[13:41] <Laney> to ghc
[13:41] <janimo1> upstream issue http://hackage.haskell.org/trac/ghc/ticket/4523 I think this is the same
[13:41] <Laney> you can put it in SRC_HC_OPTS in mk/build.mk
 https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000783.html
 https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-October/000772.html
[13:41] <janimo1> Laney: but that owuld mean changing every package
[13:41] <doko> janimo1: ^^^
[13:41] <Laney> that patch too
[13:41] <janimo1> ?
[13:42] <Laney> no
[13:42] <Laney> fix it in ghc, add that patch
[13:42] <Laney> then you can remove those changes on the next upload
[13:42] <janimo1> Laney: indeed ghc6 is the one needs fixing
[13:42] <Laney> (the pthread ones)
[13:42] <doko> but even then, haskell had a lot of build failures in maverick
[13:43] <Laney> on armel?
[13:43] <Laney> it's not fully supported, only a stage one compiler unfortunately
[13:43] <doko> yes
[13:43] <janimo1> doko:  I know the cause, gcc 4.5 is more strict it is ok
[13:43] <Laney> ...
[13:43] <janimo1> hence ghc6 needs to be patched
[13:43] <janimo1> permanently
[13:44] <janimo1> Laney: what I ws thinking is fix ghc6 - maybe using a 4.4 gcc to build itself
[13:44] <Laney> i don't think it's necessary
[13:44] <janimo1> and then remove that change (gcc 4.4 dep) but leave the pthreaf fix
[13:44] <Laney> let me do this upload
[13:44] <janimo1> ok I was about to try the build
[13:44] <janimo1> as part of a caonfigure step ghc6 calss ghc6
[13:44] <janimo1> which on armel FTBFS for me
[13:44] <doko> janimo1: no, we made some changes in the linking behaviour, so if ghc drops something, then please add it, and use --no-as-needed for this particular link
[13:44] <Laney> yes you can pass -optl-pthread there
[13:44] <Laney> edit theh configure script
[13:44] <doko> janimo1: no, gcc-4.4 is not an option
[13:45] <janimo1> doko: yes, I know , I said ghc6 needs to be changed, ghc upstream agrees and knows about the issue
[13:45] <doko> ok
[13:45] <janimo1> doko: 4.4 as a temporary oncshot build in case the self bootstrap needs it
[13:45] <doko> sure
[13:46] <Laney> i'll upload now
[13:46] <janimo1> Laney: I got FTBFS on ghc6 ./configure since it calls the existing ghc6 which doesn ot pass the proper flags
[13:46] <janimo1> Laney: ok, fingers crossed
[13:46] <janimo1> :)
[13:46] <Laney> janimo1: you can fix that in the configure script
[13:46] <Laney> i did test build ;)
[13:46] <janimo1> Laney: ok, have you seen the patch in the issue abobe?
[13:46] <janimo1> Laney:  is it the same probelm you fixe
[13:46] <Laney> yes, that's the real fix
[13:46] <janimo1> d?
[13:46] <janimo1> but sligtly differently?
[13:47] <Laney> but ghc ftbfs because of the original problem so you have to add the explicit links to get it to build
[13:47] <Laney> because it build-depends on itself which is obviously already broken
[13:47] <janimo1> BD on itslef ins not broken imo
[13:47] <janimo1> gcc bd on itself
[13:47] <Laney> not inherently, in this case
[13:47] <Laney> it's why you get ftbfs
[13:48] <janimo1> Laney: ok, will wait for your upload to build and hope it solved the issues then
[13:48] <janimo1> but the real fix is needed right? You mean there needs to be a new upload anyway with that?
[13:49] <Laney> you need to add the configure fix to get ghc built correctly
[13:49] <Laney> you need to add the explicit linking to hack the broken archive ghc into functioning so that you can build the new fixed one
[13:50] <janimo1> Laney: I see, that's what I thought was one of the two solutions (the other being GCC=4.4)
[13:50] <janimo1> figuring there may be more than one call to ghc6 while bootstrapping and instrad of hunting them all down, just build it with a known good gcc
[13:51] <janimo1> but since your change fixes it as well it is fine :)
[13:52] <janimo1> Laney: you are the de facto ubuntu gch maintainer? I don;t mind then if you add the 'real fix' as well as part of one of your uploads
[13:52] <Laney> i am adding both
[13:52] <janimo1> great :)
[13:53] <hallyn_> cjwatson: ssh bug - i was looking at bug 686671
[13:53] <hallyn_> cjwatson: as for multipath-tools, yes - i wantted to make sure noone else was interested, and otherwise i volunteer
[14:01] <sabdfl> pitti: http://pastebin.ubuntu.com/541455/
[14:03] <doko> seb128: is an evolution upload planned, just wanting to do a rebuild
[14:04] <seb128> doko, if we do a rebuild we will probably want to get some fixes in as well yes
[14:04] <seb128> doko, is that for the python transition?
[14:04] <doko> yes
[14:05] <seb128> doko, ok, don't bother about it, we will do an upload
[14:05] <doko> I'll just skip it, if you upload it
[14:05] <seb128> we have some pending fixes to do so we can as well make the upload useful
[14:06] <doko> seb128: anything else on this list: http://paste.ubuntu.com/541459/
[14:07] <seb128> doko, linbindicate is being worked by kenvandine
[14:07] <seb128> that's python-indicate as well
[14:07] <seb128> doko, rodrigo is doing libubuntuone
[14:08] <seb128> doko, let xchat-gnome we need to update it as well for the as needed
[14:08] <seb128> doko, eog and gedit you can drop as well
[14:08] <seb128> that's all I see
[14:09] <kenvandine> seb128, i am going to talk to tedg about uploading dbusmenu from before the gdbus port now... i have it all ready and it will fix the build issues
[14:09] <seb128> kenvandine, ok great
[14:09] <kenvandine> he didn't want to because of breaking the api twice...
[14:09] <doko> ok
[14:09] <kenvandine> but that is better than this
[14:10] <seb128> kenvandine, right, seems a safe way to go for it
[14:14] <pitti> sabdfl: ugh, "180388658839 bytes by 612718282101927924 read() call(s)
[14:14] <pitti> sabdfl: I hope that's a bug due to long ints :) (but I'm on amd64 as well and don't get that)
[14:14] <pitti> sabdfl: how did you create that swap partition? I think you said you just created it from scratch, right?
[14:15] <brendand> i'm working on the testability of update manager
[14:15] <brendand> i'm trying to work out a criteria for 'success' of an update action
[14:19] <seb128> brendand, you might want to talk to mvo
[14:19] <seb128> mvo, ^
[14:19] <pitti> sabdfl: (currently busy fixing gdm); would you mind filing a bug about it, add that pastebin, and create a snapshot of that partition's first MB? sudo dd if=/dev/sda2 of=/tmp/swap.dump bs=1M count=1
[14:19] <pitti> sabdfl: that image should help us to reproduce the bug and fix blkid
[14:20] <pitti> sabdfl: I used mkswap on a spare partition and that worked, so please describe how you created it
[14:21] <mvo> brendand: hey, well that the updates installed without a problem I guess :) what exactly do you need? a way to figure that from the windows being presented?
[14:23] <brendand> more looking at the internal state of the update manager
[14:23] <brendand> i've added a signal which is sent out when the update is done
[14:23] <brendand> with a success value
[14:24] <brendand> at the moment this is derived from whether the network mgr is connected
[14:24] <brendand> somehow i don't think is a comprehensive definition of success
[14:24] <brendand> what does a failed update look like?
[14:24] <brendand> i guess an empty update list isn't it
[14:24] <brendand> because the repositories could be empty
[14:26] <mvo> brendand: hold on a sec, I check what the best approach might be
[14:27] <pitti> ok, so it's not gdm
[14:29] <seb128> pitti, it's some xorg script failing?
[14:29] <seb128> like X11 scripts?
[14:29] <pitti> seb128: I don't think so; startx works fine
[14:29] <seb128> (just guessing)
[14:29] <pitti> seb128: my current best candidate is dbus
[14:30] <seb128> oh, keybuk patched that yesterday
[14:30] <pitti> seb128: give me some more minutes to bisect the packages that I upgraded this morning
[14:30] <seb128> that = dbus
[14:31] <sabdfl> pitti: i created this partition today with fdisk
[14:31] <pitti> sabdfl: right, but did you mkswap it?
[14:31] <sabdfl> deleted the old extended and logical partition (2 and 5) and added a new primary, 2
[14:31] <mvo> brendand: there is a action-done signal that is emited, you could use that, its ok if that is natty, right? I can add a signal to the dbus iface that emits done and a success/filure state
[14:32] <sabdfl> pitti: i didn't do mkswap, just fdisk with setting the type to 82
[14:32] <pitti> sabdfl: ah
[14:32] <sabdfl> why would it need mkswap to get a uuid?
[14:32] <pitti> sabdfl: that'll just create a partition with random garbage in it; you need to manually create a file system
[14:32] <brendand> i'm catching the action-done
[14:32] <pitti> sabdfl: (btw, gparted or the disk utility in system -> admin are much more comfortable)
[14:32] <brendand> couldn't see that it provided any success information
[14:32] <pitti> sabdfl: sudo mkswap /dev/sda2
[14:32] <brendand> i've added the signal
[14:33] <sabdfl> ok. somehow, in various upgrades, the uuid went titsup, because the original problem was that the UUID in fstab wasn't being found, and blkid had no idea of the UUID for the partition
[14:33] <brendand> just need to sort out the logic of success/failure
[14:33] <mvo> brendand: ok, hold on a minute and I will commit something
[14:33] <pitti> sabdfl: right, I read that; but I'm afraid due to the repartitioning the original data is now gone :/
[14:33] <pitti> sabdfl: well, unless you can recreate it exactly as it was before
[14:34] <pitti> and you didn't write anything to the new partition yet
[14:35] <sabdfl> pitti: ok, mkswap created a uuid, and updating the fstab then made everything work
[14:35] <sabdfl> thanks
[14:36] <pitti> sabdfl: ah, good
[14:36] <sabdfl> i should have called out before removing the problematic partition
[14:36] <pitti> sabdfl: there are some cases where old (i. e. hardy or so) blkids would still have identified as swap, but newer ones didn't
[14:37] <pitti> sabdfl: how old was that old swap partition?
[14:37] <cjwatson> hallyn_: OK, I'll get that forwarded upstream for starters
[14:37] <pitti> sabdfl: a few years ago, mkswap and various mkfs.* were pretty sloppy and didn't properly zero out the first blocks
[14:37] <pitti> sabdfl: so if you e. .g first created an ext4 and then a vfat on top of that, the first blocks had signatures for _both_ file systems
[14:38] <pitti> sabdfl: in the past, blkid made a random choice, and now it just says "erm, dunno"
[14:38] <pitti> (for safety)
[14:38] <pitti> sabdfl: but that's the only known case to me
[14:40] <doko> soren, pitti: I think I found the cause for the failure: python2.7-dev and python2.7 are installed, and python2.6 is still pulled in by a library depending on libpython2.6. and both cdbs and debhelper use pyversions -vr / -i, and are not looking at the build-depends, here the python-dev, or python-all-dev package
[14:40] <cjwatson> sabdfl: I used to hear of issues which implied that software somewhere had run mkswap without preserving the swap UUID, which would leave any other OS on the same system that was trying to use that swap partition by UUID without swap.  The Ubuntu installer has preserved the UUID since feisty.  I've never been able to track down what the other problems might have been (we usually only hear about the problem some arbitrarily ...
[14:41] <cjwatson> ... long period of time after the fact).
[14:41] <cjwatson> haven't heard much of such issues for a while though ...
[14:41] <cjwatson> that may not be the same as what you're reporting though
[14:42] <brendand> mko: thanks
[14:48] <mvo> brendand: please check my latest commit 1994
[14:49] <mvo> brendand: it adds a new boolean "success"
[14:54] <soren> cjwatson: I'm not entirely sure of the details, but I swear at some point, every time I hibernated, my swap partition would get a new UUID.
[14:54] <cjwatson> soren: it's possible.  is that still happening?
[14:55] <soren> cjwatson: I remember which laptop it was, and I stopped using that one while Breezy was still The New Thing[tm].
[14:55] <ogra> i think swap encryption also calls mkswap on boot, no ?
[14:55] <soren> cjwatson: Not that I've noticed, no.
[14:55] <cjwatson> I have a vague memory that at one point cryptsetup was fouling things up.
[14:55] <soren> Hm... I don't remember if I used encrypted swap on that one.
[14:56] <soren> I don't recall seeing it since then, though, so it's probably solved.
[14:59] <james_w> pitti, sorry for the bug, here's a good fix: https://code.launchpad.net/~james-w/launchpad-work-items-tracker/multi-project/+merge/43221
[15:01] <cjwatson> hallyn_: actually, it's already fixed in upstream / Debian experimental / natty
[15:01] <pitti> james_w: thanks! merged
[15:01] <cjwatson> I'll close it
[15:01] <james_w> pitti, thank you
[15:01] <james_w> pitti, sorry again
[15:01] <pitti> james_w: no problem at all; stuff just happens :)
[15:02] <pitti> james_w: it's not like this was gdm not working any more or so *cough*
[15:02] <kirkland> pitti: james_w: are you talking about whatever reason I can't login to my desktop?
[15:02] <james_w> heh :-)
[15:02] <pitti> kirkland: yep, I just hunted that down, see bug 654578
[15:02] <james_w> kirkland, I'm not, no
[15:02] <pitti> itz mterry bug
[15:02] <kirkland> pitti: cool;  is there a workaround at the moment?
[15:02] <pitti> kirkland: (I also updated /topic for that)
[15:02] <kirkland> pitti: thanks, i'm trying to figure out how to read the topic in irssi :-)
[15:03] <pitti> kirkland: sudo rm -r /etc/X11/Xsession.d/52libcanberra-gtk3-module_add-to-gtk-modules/
[15:03]  * mterry fixing now
[15:03] <pitti> kirkland: that's actually the proper fix :)
[15:04] <kirkland> pitti: coolio;  trying now ...
[15:05] <kirkland> pitti: worked ;-)  thanks
[15:05]  * pitti adds that to the bug description
[15:05] <kirkland> pitti: i was deathly afraid that it was an ecryptfs problem at first
[15:07] <pitti> kirkland: wb :)
[15:08] <kirkland> pitti: :-)
[15:09] <kirkland> pitti: much as I like w3m/irssi/sup-mail running in byobu, this is way better :-P
[15:09] <pitti> hehe
[15:09] <smoser> pitti, general question... i do a verify of -proposed, like in bug 651370
[15:10] <smoser> should i add 'verification-done' and remove the '-needed' ?
[15:10] <pitti> smoser: please do; thanks!
[15:10] <kirkland> pitti: also, i forgot how dependent I am on networkmanager, as I was trying to molest iwconfig/ifconfig into getting me on my wireless from the command line :-D
[15:10] <pitti> kirkland: right; I think last time I tried that it took me a while to figure out
[15:10] <mterry> fix uploaded
[15:10] <sabdfl> pitti: i *think* that partition was created with mid-cycle lucid
[15:11] <pitti> kirkland: it's actually much easier if you put that into /etc/network/interfaces and let ifup do it for you
[15:11] <kirkland> pitti: yeah, i spent 5 minutes and then grabbed an ethernet cable!
[15:11] <pitti> kirkland: way to go :)
[15:11] <pitti> mterry: cheers
[15:11] <kirkland> pitti: good idea;  i'll use that next time
[15:12] <cjwatson> kirkland: there's cnetworkmanager in natty ...
[15:12] <cjwatson> and maverick come to that
[15:13] <smoser> pitti, thanks. i just wasn't clear if i was supposed to do that, or just comment that i did and then have someone on the SRU team do the tag change.
[15:13] <kirkland> cjwatson: interesting;  never heard of it
[15:14] <kirkland> RoAkSoAx: hey, looks like testdrive is broken in natty, presumably python 2.7 issues
[15:14] <kirkland> RoAkSoAx: can you take a look?
[15:14] <pitti> smoser: if you do it youself, you save me 10 seconds
[15:15] <smoser> great. sorry for wasting more than that asking you :)
[15:15] <czajkowski> ev: just did a clean install of lucid and came across this when it had finshed, ever seen this happen http://twitpic.com/3ecx13
[15:27] <hallyn_> kirkland: nmcli works
[15:27] <hallyn_> I was even able to join a vpn with it
[15:27] <kirkland> hallyn_: hrm, didn't know about that one either
[15:27] <hallyn_> (which i had defined through the nm-applet before)
[15:28] <hallyn_> i think it's only become really useful in natty
[15:28] <apw> cjwatson, i was thinking about the grub background thing ... i wonder if just having a small 'purple background' as the image would work ... ie the plymouth screen with no text etc
[15:31] <rodrigo_> doko, seems I fixed it, so submitting the package, so take a look at it if you want later one
[15:31] <rodrigo_> later on
[15:33] <doko> rodrigo_: which one?
[15:33] <rodrigo_> doko, oh, sorry, the libu1 issue
[15:34] <doko> rodrigo_: uploaded?
[15:35] <rodrigo_> doko, doing it now
[15:35] <rodrigo_> doko, I have the code in a branch, do you want to look at it now?
[15:37] <doko> rodrigo_: sure
[15:38] <rodrigo_> doko, http://pastebin.com/aLL3cw8d
[15:41] <cjwatson> apw: it's possible, but I'd rather start off making it as close to the plymouth image as possible
[15:41] <cjwatson> apw: it would certainly make scaling issues go away, but on the other hand it's not clear whether it meets the mandate I've been given
[15:41] <doko> rodrigo_: mkdir build seems to be missing
[15:43] <rodrigo_> hmm
[15:43] <rodrigo_> ok, it worked ok without it, but I guess it indeed needs to be added
[15:44] <doko> rodrigo_: maybe you should remove it clean?
[15:44] <rodrigo_> yeah
[15:45] <doko> make sure that it does build twice in a row, and doesn't include generated files in the diff
[16:06] <SpamapS> pitti: re wi tracker.. I tested it extensively on my machine (ran through collect on two different cfg files) is it a python version thing?
[16:07] <pitti> SpamapS: it's all good now
[16:07] <geser> doko: is it planned to do a no-change rebuild of packages build-depending on python-dev now the default python version changed? (or did it already happen?)
[16:07] <SpamapS> pitti: what was ths issue?
[16:08] <pitti> SpamapS: it passed once a string and once an lp project object
[16:08] <SpamapS> pitti: also, I'm not getting any emails even though I am subscribed to the ML
[16:09] <cdbs> doko: It appears package miro didn't build against python2.7 in its rebuild. A test build with the proper build-dep and proper pyversions set to 2.7 worked fine. Are you working on it or should I upload the change? I have test-built it successfully
[16:09] <doko> geser: already done, I have one more batch. Here are our current issues: https://launchpad.net/ubuntu/+bugs?field.tag=python27
[16:09] <SpamapS> pitti: in fact, the mailing list just isn't getting messages
[16:09] <pitti> SpamapS: right, not sure why; seems lillypilly can't send there
[16:09] <doko> cdbs: please upload
[16:10] <SpamapS> pitti: thats weird.
[16:10] <SpamapS> pitti: is it subscriber only?
[16:10] <pitti> SpamapS: presumably
[16:10] <geser> doko: is vim in this second batch? vim has no dependency on libpython2.6 anymore as it dlopen() it (but vim has a build-dependency on python-dev)
[16:10] <pitti> but I'm getting my own mails just fine
[16:11] <doko> geser: no, please upload
[16:12] <ev> czajkowski: sorry, was on a call.  Yes, that's entirely harmless and is documented in the 10.10 release notes.
[16:13] <doko> geser: please coordinate with barry on the bug list
[16:14] <cdbs> doko: done, thanks!
[16:15] <czajkowski> ev: that's rather annoying :(
[16:15] <czajkowski> ev: thanks though
[16:16]  * doko is cursing quit build logs
[16:16] <doko> even quiet
[16:17] <sveinse> Anyone knows if emacs has a different font redering system than rest of gnome? My fonts become larger in the emacs editor than the rest of gnome. Even emacs' font picker displays the font differently then inside the editor.
[16:25] <RoAkSoAx> kirkland: will do. Will upgrade to Natty and work on it!
[16:32] <kirkland> cjwatson: hey question for you ... i was thinking about sending ssh-import-id to the upstream openssh devel list (and make the import URL configurable) ... what do you think?
[16:34] <achiang> cjwatson: i have seen that before too
[16:34] <achiang> oh, i guess it's a known issue
[16:37] <cjwatson> kirkland: go ahead
[16:38] <cjwatson> kirkland: I would much rather this sort of thing went upstream in general anyway
[16:38] <doko> rodrigo_: should I upload something?
[16:38] <kirkland> cjwatson: agreed, thanks.
[16:38] <rodrigo_> doko, no, already uploaded
[16:38] <rodrigo_> doko, with the 'mkdir build' thing you mentioned
[16:40] <doko> rodrigo_: thanks
[16:40] <rodrigo_> doko, you're welcome :)
[16:43] <nmarques> anyone can gimme some help with libindicate building ?
[16:47] <seb128> nmarques, hey, what are you trying to do?
[16:50] <james_w> SpamapS, https://code.launchpad.net/~james-w/launchpad-work-items-tracker/blueprints-api/+merge/43240 if you have a few minutes please
[16:51] <doko> rodrigo_: http://launchpadlibrarian.net/60384209/buildlog_ubuntu-natty-i386.libubuntuone_0.3.8-0ubuntu4_FAILEDTOBUILD.txt.gz
[16:51] <rodrigo_> doko, yes, saw it
[16:51] <doko> seb128: is there any doc/announcment how this kind of thing has to be fixed?
[16:53] <SpamapS> james_w: so one other thing I didn't mention yesterday was that this was a bit slower than the page scraping method...
[16:53] <james_w> SpamapS, really? It's faster for me
[16:54] <SpamapS> james_w: it may have been a temporary issue
[16:54] <james_w> SpamapS, I'll run another test with the real data and see
[16:55] <james_w> in theory it does an order of magnitude fewer round trips, and avoids downloading all the superfluous stuff that you get in the HTML page
[16:55] <james_w> plus I would have thought less regex matching would cut a further couple of percent
[16:56] <doko> mterry: +build2 for a sourceful change in seed doesn't seem to be correct
[16:56] <seb128> doko, rodrigo_: you need to b-d on the gir you use
[16:57] <mterry> doko, I agree.  build1 was just a rebuild, but I accidentally left build2 on when I made a change.  Is such a mistake worth a new upload?
[16:57] <rodrigo_> seb128, it doesn't use atk gir
[16:57] <seb128> rodrigo_, well then one of the gir you use does and doesn't depend on it
[16:58] <SpamapS> james_w: right, I was surprised too.. my thought was just that the API code might not be optimized yet
[16:58] <rodrigo_> yay, gtk I guess
[16:58] <nmarques> seb128, just a bit please... need to care for something real quick
[16:58] <james_w> SpamapS, the API usage code I wrote, or the Launchpad API?
[16:58] <james_w> SpamapS, I'd agree either way though :-)
[16:58] <doko> mterry: I don't know if it will be autosynced, sorry
[16:59] <seb128> rodrigo_, well it does
[16:59] <seb128> rodrigo_, but seems you don't db on gir1.0-gtk...
[16:59] <rodrigo_> yes
[16:59] <mterry> doko, well it still has an ubuntu suffix, so I doubt it will get autosynced
[17:00] <seb128> rodrigo_, yes?
[17:00] <SpamapS> james_w: the LP API
[17:00] <rodrigo_> yes, I don't db on gir-gtk :)
[17:00] <doko> seb128: osm-gps-map, this seems to be included in the package itself, but the .gitignore ignores it
[17:00] <cjwatson> mterry: indeed it won't
[17:00] <cjwatson> +build1 was wrong in the first place
[17:00] <mterry> cjwatson, oh really?  We just bump ubuntu for no-changes?
[17:00] <cjwatson> that should just have been -0ubuntu2 ... the only value in "build" is to change the version in a way that doesn't involve adding an "ubuntu" substring to the version
[17:00] <james_w> SpamapS, it's certainly not great, but the code organisation means that it should generally be <= the time taken to get the HTML page
[17:01] <mterry> cjwatson, noted
[17:01] <seb128> doko, I guess that was for someone else?
[17:01] <james_w> SpamapS, though the blueprint code is rather neglected, so maybe that's not true here
[17:01] <seb128> rodrigo_, ok, that's your bug ;-)
[17:01] <doko> seb128: no, but if somebody else can help ...
[17:01] <seb128> doko, I've no clue about osm
[17:02] <SpamapS> james_w: my observation was just on the first 10 bp's .. but it seemed consistent yesterday. I will give it a look again later.
[17:06] <geser> barry: any reason I should wait with getting bug 688149 sponsored? (no-change rebuild with python 2.7)
[17:07] <barry> geser: nope.  i can't do it for you though (yet ;).  ping doko
[17:09] <doko> cjwatson: I'd like to upload a "hack": in python2.6, add a dependency on python2.6-dev. this works around the current build failures when a package b-d's on python-dev, but python2.6 is pulled in via libpython2.6, and the package tries to build with python2.6 and cannot find the python2.6-dev headers. as a temporary change until packages are rebuilt.
[17:10] <doko> barry: ^^^
[17:10] <cjwatson> ew.  um, not sure what that will do to CD builds
[17:10] <cjwatson> I'm a bit concerned that that means people upgrading through natty will all end up with python2.6-dev installed
[17:11] <cjwatson> how many such failures are there?
[17:11] <doko> cjwatson: it won't make them worse. this problem will settle, when we don't have that many deps on libpython2.6 anymore
[17:11] <doko> ~50
[17:12] <geser> cjwatson: as you sponsored vim for me in the past, have you got a minute to sponsor bug 688149? or should I ask someone else or add it to the sponsoring queue?
[17:12] <cjwatson> geser: I can do it now
[17:12] <geser> thanks
[17:12] <cjwatson> doko: it will certainly make the upgrade situation worse, won't it?
[17:12] <doko> cjwatson: how?
[17:12] <cjwatson> 17:10 <cjwatson> I'm a bit concerned that that means people upgrading through natty will all end up with python2.6-dev installed
[17:13] <doko> cjwatson: it will help the ugprade. I'll revert that in a week or so.
[17:13] <cjwatson> it won't help the upgrade for people running non-development systems upgrading through natty
[17:13] <nmarques> seb128, I'm trying to build libindicate, but it breaks, by not finding a file (bindings/mono/indicate/indicate-api.raw.pre) on the mono bindings. I'm wondering if I could get a pointer in the right direction to overcome it
[17:13] <cjwatson> of course you might make the argument that there shouldn't be so many of those
[17:14] <cjwatson> if it's strictly time-bounded, I guess I don't mind so much, but you will very likely get annoyed bug reports
[17:14] <doko> yes, known. the alternative would be to add b-d's for all these packages
[17:15] <cjwatson> which you'd then have to revert again later, I suppose?
[17:15] <doko> cjwatson: I'll add it on libpython2.6. this way less people are affected
[17:16] <doko> yes, reverting these 50
[17:16] <cr3> cjwatson: preseed question for you, if you happen to have a moment: might you happen to know, or point me to someone who does, how server environments preseed the network interface on servers which might have several interfaces, so eth[0-9]+ might not always point to the same physical device and therefore diffrent mac addresses which might not be configured on the dhcp server
[17:16] <seb128> nmarques, try talking to kenvandine
[17:16] <seb128> or ted
[17:17] <nmarques> seb128, thx... I think I might have got some advancements here :)
[17:17] <cjwatson> cr3: sorry, I don't know exactly.  it's entirely possible it just doesn't work all that well right now.
[17:17] <cjwatson> cr3: there's a bug somewhere for allowing mac preseeding
[17:17] <cr3> cjwatson: early_command is run immediately after getting an ip address, right?
[17:18] <cjwatson> more or less
[17:18] <cr3> cjwatson: a possible solution might be to configure the dhcp server differently too, preseeding might not necessarily where to fix the problem
[17:19] <cjwatson> certainly after, in the case of netboot installs
[17:43] <nmarques> seb128, you know if Ted's around on IRC and where I can poke him ?
[17:43] <seb128> nmarques, he's usually on #ayatana when he's online
[17:44] <seb128> he left less than hour ago but he should be back later on
[17:44] <seb128> ben maybe kenvandine can help you
[17:44] <nmarques> will ask, thx for your help :) most appreciated
[17:44] <kenvandine> hey ben
[17:44] <kenvandine> whoops
[17:45] <kenvandine> nmarques, what can i help with?
[17:46] <nmarques> kenvandine, just a simple question... I'm trying to build libindicate... I've patched it with 2 minor patches to fix some stuff (python include paths)... my question though is if any of it's dependencies requires 'special' patching... as it's being a bit of unstable process for me... sometimes it builds, others it just complains that it doesn't find a file in the mono bindings
[17:47] <kenvandine> nmarques, well i am about to upload libindicate
[17:47] <kenvandine> with a bunch of GI related fixes
[17:47] <kenvandine> been blocked on dbusmenu
[17:47] <nmarques> kenvandine, I'll wait for the new release :)
[17:47] <kenvandine> :)
[17:48] <kenvandine> are you building on natty?
[17:48] <kenvandine> also, you need to be careful to not set deb options to do parallel builds
[17:49] <kenvandine> it breaks building the mono bindings sometimes
[17:49] <nmarques> kenvandine, unfortunatly no, but parallel builds are on
[17:49] <kenvandine> yeah, that won't work
[17:49] <kenvandine> sharing violations
[17:49] <kenvandine> never figured out exactly why
[17:49] <nmarques> kenvandine, the strange part if that if I order it to rebuild without clearing the build root
[17:49] <kenvandine> that is probably your only problem then
[17:49] <nmarques> kenvandine, it builds... but it's a wildcard
[17:50] <kenvandine> yeah
[17:50] <nmarques> kenvandine, that will sort my issue then... nevertheless I'll wait for the new release :)
[17:50] <kenvandine> it is one process reading a file that gets regenerated or something
[17:50] <nmarques> ;)
[17:50] <nmarques> yeap on bindings/mono/indicate
[17:50] <kenvandine> exactly
[17:51] <kenvandine> the other fixes i am uploading is for multiple python versions and GI changes in natty
[17:51] <kenvandine> not a new version
[17:52] <nmarques> kenvandine, I'll pick it up ;)
[18:14] <kenvandine> anyone around that can promote a couple packages to main that have had approved MIRs?  they are blocking one of the indicators i need to get rebuilt
[18:19] <doko> kenvandine: which ones?
[18:33] <doko> kenvandine: commented, MIR for ofone is missing
[18:33] <doko> ofono
[18:34] <cyphermox> doko, what about ofono?
[18:35] <doko> see bug #686034
[18:36] <cyphermox> ah
[18:36] <cyphermox> I'd just need someone to finish reviewing my ofono merge.
[18:36] <cyphermox> micahg, ping ^
[18:37] <cyphermox> micahg, it would be really cool if you could take another look :)
[18:37] <micahg> cyphermox: can't do it right now, but can tonight, was I the original reviewer?
[18:37] <cyphermox> yea
[18:37] <cyphermox> to me, it's fine for tonight. not sure if others are more in a rush for e.g. the geoclue MIR
[18:38] <micahg> cyphermox: I can't seem to find it, do you have a link handy?
[18:38] <cyphermox> oh, also missing a MIR for ofono?
[18:38] <cyphermox> huh, sure, hold on
[18:39] <cyphermox> micahg, https://code.edge.launchpad.net/~mathieu-tl/ubuntu/natty/ofono/merge-683302
[18:40] <micahg> cyphermox: oh indeed, I do have a mail for it, I apologize
[18:40] <cyphermox> micahg, don't worry about it
[18:42] <micahg> cyphermox: I think they're more interested in teh MIR for ofono ATM, but I'll review the merge again tonight
[18:44] <micahg> kenvandine: ^^ so do you need this merge done today, or will it take time to prepare the ofono MIR
[18:44] <kenvandine> ugh... geoclue needs ofono?
[18:44] <kenvandine> sorry... don't know how we missed that
[18:45] <Darxus> The unity plugin for compiz is only in natty, right?  Is it included in alpha1?  Mark Shuttleworth asked me to try it.  I'm a little confused about why, but....
[18:45] <kenvandine> i'll do the mir right now, we need it pretty quickly... it will break the desktop
[18:45] <kenvandine> Darxus, it is in alpha1
[18:46] <Darxus> kenvandine: Thanks.
[18:46] <cyphermox> kenvandine, why does geoclue require ofono?
[18:47] <cyphermox> ah, nevermind, I didn't read everything :)
[18:47] <micahg> cyphermox: I still don't see the override in teh diff since the package switched to CDBS
[18:48] <micahg> unless the diff is broke
[18:48] <cyphermox> micahg, huh, weird, I triple checked it.
[18:55] <kirkland> hey desktop guys ... i'm running stock natty/unity ... i'd like to "speed up" the transition between applications when using alt-tab
[18:56] <kirkland> it seems too "slow" for me, with the fade in/out effect
[19:01] <Darxus> Is it known that the natty alpha 1 image doesn't fit on (some?) blank CDs?
[19:01] <kenvandine> Darxus, yes
[19:02] <Darxus> Yeah, just found that on the alpha1 page, sorry.
[19:02] <Darxus> Is there a natty testing specific irc channel?
[19:05] <Darxus> kirkland: Do you know which unity backend you're using, clutter or compiz?  I've read the switch to compiz is partially to increase speed, but I don't know which is default in natty at this point.
[19:06] <kirkland> Darxus: not sure;  how do i tell?
[19:06] <kenvandine> Darxus, only the compiz based unity is in natty
[19:06] <kenvandine> the mutter based isn't
[19:07] <kenvandine> Darxus, and not just for speed, better hardware coverage too
[19:07] <Darxus> kenvandine: I did say "partially" :)
[19:07] <kenvandine> it will work well on a much broader range of video cards
[19:07] <kenvandine> :)
[19:07] <Darxus> The unity vs. gnome shell drama is fascinating.
[19:07] <kenvandine> so if you see unity on natty, you are using compiz
[19:08] <ScottK> pitti or cjwatson: Would you please rescore kdegraphics (just affects armel) - I need that one built so I can test another FTBFS fix.
[19:11] <kirkland> kenvandine: okay, i'm using unity + compiz ... how do i speed up alt-tab?
[19:11] <kirkland> kenvandine: i don't think it's hw accel related ... just looks like a config tweak
[19:12] <kirkland> kenvandine: things want to fade in an out slowly/smoothly, while I want them to fade instantly, so I can keep working :-)
[19:12] <kenvandine> yeah, i agree with that
[19:12] <kenvandine> in ccsm, you can adjust the speed of the application switch
[19:12] <kenvandine> +er
[19:12] <kenvandine> alt-tab was slow...
[19:17] <kirkland> kenvandine: okay, thanks, i'll install that
[19:23] <Darxus> Before I ask Mark Shuttleworth, andybody want to try to interpret what he's asking me to do here?  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/688171
[19:23] <Darxus> There is no unity plugin for compiz on maverick, which is what I reported the bug for.
[19:24] <Darxus> Does he want me to try installing natty, switching to a gnome desktop, enabling compiz, and then enabling the unity plugin for compiz?
[19:28] <Darxus> I'm guessing he just missed the fact that I'm running maverick?
[19:35] <stgraber> Darxus: yes, sabdfl probably didn't notice you were running 10.10.
[19:40] <ScottK> Nevermind on rescoring.  It's up soon anyway.
[19:42] <Darxus> stgraber: Thanks.  I ended up replying based on that belief.
[19:59] <ScottK> cjwatson: It seems that scribus is in the Kubuntu package set.  I'm not sure that's appropriate as Kubuntu doesn't ship it and it's a Qt3 application (we don't have any of those left in Kubuntu).  I'm not sure what brought it in, but I think that might merit some reconsideration.
[20:15] <mrenouf|work> CDBS python packaging question: I'm getting "unsupported Python system: python-support (select either pysupport or pycentral)"
[20:15] <mrenouf|work> I'm setting DEB_PYTHON_SYSTEM="python-support"
[20:15] <mrenouf|work> I've also tryied pysupport
[20:32] <boscowitch> hi i wanted to ask if there is a way to let remotly build my  binary deb packet for almost all ubuntu versions currently used (or the last 2)
[20:33] <boscowitch> or if have have to maintain lokal schroot with all the os versions ?
[20:34] <boscowitch> (i don't use ubuntu anymore so i'm not really up to date with ubuntu development)
[20:35] <Sarvatt> doko: so apparently debian is patching out some of the Requires: in libsm libxt and libxmuu and -lX11/-lICE is getting dropped in a ton of places because of it, am I right in thinking we could get an insane amount of ftbs fixes by reverting those 3 patches? :)
[20:36] <Sarvatt> in sm.pc xt.pc and xmuu.pc I mean
[20:42] <james_w> SpamapS, you are right, it is a little slower (~10%), I'm going to look at why
[20:49] <SpamapS> james_w: damn, I was hoping I was wrong
[20:49] <CarlFK> http://dpaste.de/5FQJ/  "python-uno : Depends: python (< 2.7) but 2.7.1-0ubuntu1 is to be installed"
[20:50] <CarlFK> guessing this is part of python 26->27 that is still being worked on?
[20:51] <james_w> SpamapS, could I get you to make a config change to activate yesterday's branch?
[20:52] <SpamapS> james_w: yeah, what do you need?
[20:52] <SpamapS> CarlFK: yeah, is there a debian/pyversions file with '2.6' only in it?
[20:54] <james_w> SpamapS, extra_projects = ['linaro', 'linaro-multimedia-wg', 'linaro-graphics-wg', 'linaro-toolchain', linaro-kernel', 'linaro-pm-wg', 'linaro-infrastructure', 'linaro-project-management', 'linaro-landing-team-ste'] please
[20:57] <SpamapS> james_w: for natty.cfg ?
[20:57] <CarlFK> SpamapS: how would I check?  (i don't have a working natty box)
[20:57] <CarlFK> SpamapS: I do have the busybox shell of the installer
[21:04] <SpamapS> james_w: ???
[21:30] <james_w> SpamapS, sorry, had a network outage. Yes please
[21:38] <SpamapS> james_w: done
[21:39] <cjwatson> ScottK: have you checked germinate output?
[21:40] <cjwatson> ScottK: I don't really want to be the central bottleneck for seed debugging - I think most of the resources are available to debug it, and if not I'd like to know so that I can make sure they are
[21:41] <cjwatson> Sarvatt: that sounds as though it would be incorrect - objects should only be linked against libX11 if they actually use libX11 symbols directly, not merely via libsm/libxt/libxmuu
[21:41] <cjwatson> Sarvatt: it might fix things temporarily but at the cost of losing out on the leaner-and-meaner linkage
[21:42] <cjwatson> CarlFK: don't expect daily CDs to work at all for some days while this transition is sorted out
[21:42] <cjwatson> CarlFK: the installer is definitely not the right environment to debug that kind of thing from :)
[21:43] <CarlFK> cjwatson: figured as much.  wasn't sure if it was worth reporting.  guessing I should wait a few days.
[21:44] <RAOF> cjwatson: I'm looking at those packages; libxmu uses libXt symbols in #defines in its headers, libXt uses libX11 symbols in #defines in its headers, so adding the Requires: for those are correct IIUC.
[21:44] <CarlFK> will there be a "we think we are done, report any problems" event?
[21:46] <ScottK> cjwatson: I'll investigate it further and see if I can figure it out.
[21:47] <james_w> thanks SpamapS
[21:57] <cjwatson> CarlFK: the best way to tell is to watch for desktop CDs actually starting building again. :-)
[21:57] <cjwatson> RAOF: ah, well that sounds reasonable yes ...
[21:58] <cjwatson> (but I'd say the right answer is to argue that with Debian rather than to just revert it, right?)
[22:01] <doko> Sarvatt, cjwatson: is this now pressing? just would like to avoid to look at this this week
[22:01] <RAOF> cjwatson: Yes; I'm updating the patches in debian now :)
[22:01] <Sarvatt> doko: getting fixed up in debian, no worries
[22:02] <doko> ok, thanks
[22:02] <Sarvatt> ran into this when trying to upstream this crapload of --no-add-needed fixes in X apps
[23:15] <hallyn_> i'm looking at grub2/debian/patches - there's no debian/source and a bunch of diffs - what is the proper way to apply all the patches and create a new one on top?  I.e. what format is this?  I've done dpatch and quilt, but dunno what this is...
[23:16] <hallyn_> Daviey: zul: ^
[23:16] <hallyn_> help? :)
[23:18] <hallyn_> I guess fakeroot debian/rules apply-patches works
[23:21] <hallyn_> oh, cdbs-edit-patch?