[00:00] <TheMuso> Apteryx: I think that rule is somewhat obsolete, and its not used by anybody I know who packages pulse for Ubuntu, myself being one of them.
[00:00] <TheMuso> Apteryx: So I wouldn't worry about it.
[00:00] <Apteryx> TheMuso... so shouldn't it be cleaned out?
[00:00] <Apteryx> :)
[00:01] <TheMuso> Apteryx: Debian may still use it, so we leave it there to make sure the delta between Ubuntu and Debian is minimal.
[00:02] <Apteryx> TheMuso, ok.
[00:02] <Apteryx> TheMuse so in order to remove obsolete patches, I just delete them from the source folder?
[00:02] <Apteryx> (I was commenting them in the series file, but they were applied anyway)
[00:02] <TheMuso> Apteryx: Yes, and remove them from the series file in debian/patches.
[00:04] <Apteryx> I'd still like to get the big picture about what is going on during build process... pbuilder calls the rule file as a makefile... and then all the job gets done from there (and included *.mk) ?
[00:04] <TheMuso> Yes, cdbs does a lot of the heavy lifting for us.
[00:05] <Apteryx> Is the rule file cdbs tailored? Or it could be used without it also?
[00:06] <Apteryx> Ok, just reread the cdbs part and the ./debian/rules file seem to be cdbs specific ;)
[00:07] <Apteryx> Still think the rpmbuild system was easier to figure out, though :D
[00:08] <Apteryx> TheMuso thanks for helping :)
[00:09] <TheMuso> Apteryx: np, and cdbs doens't have to be used, but the rules file would be bigger as a consequence.
[00:09] <TheMuso> Having said that, it may be much the same size if the new debhelper 7 system was used.
[00:09] <TheMuso> Rpm only having one spec file for everything seems ilogical to me.
[00:09] <TheMuso> illogical
[00:10] <Apteryx> TheMuso for a newbie like me it was simpler, everything labeled and put in the same place ;)
[00:11] <Apteryx> TheMuso, also everytime I start pbuilder it seems to reinstall the dependencies... I've seen a bit about pbuilder sessions to save the chroot state, but did not really understand how to do that.
[00:11] <TheMuso> I don't know much about pbuilder, I don't use it. I use sbuld instead.
[00:12] <TheMuso> sbuild
[00:12] <Apteryx> TheMuso, would you recommend it over pbuilder?
[00:17] <LaserJock> Apteryx: sbuild usually takes more hard drive space, but it can be faster and in some way simpler to use
[00:19] <Apteryx> LaserJock, ok.
[00:19] <Apteryx> Other more general question: is it possible to build also x86_64 packages from a 32 bits host?
[00:21] <LaserJock> I'm not positive but I don't think so. You can go the other way around, x86_64 can build i386 too
[00:28] <TheMuso> The only way it could be done is if you were to set up a cross-compiler.
[00:28] <TheMuso> But I am still not 100% sure about that, given the different number of registers...
[00:30] <Apteryx> TheMuso, I've deleted the 0096-lp533877-handle-digmic.patch in /debian/patches and also in the /debian/patches/series file... and it still fails with: "Patch 0096-lp533877-handle-digmic.patch does not apply (enforce with -f)
[00:30] <Apteryx> don't know where its coming from to haunt me ;)
[00:31] <TheMuso> Apteryx: Do you have any patches applied in your current working tree? TO be sure, look in the .pc directory.
[00:33] <Apteryx> TheMuso, no, not that I can see. (Would this be in the pbuilder building tree or already present?)
[00:33] <TheMuso> Apteryx: Oh right, you are getting that when you test build...
[00:33] <Apteryx> TheMuso, yes.
[00:34] <TheMuso> Apteryx: How are you running pbuilder?
[00:34] <Apteryx> TheMuso... you just rang the bell ;)
[00:34] <Apteryx> TheMuso, pbuild --build pulseaudio... .dsc
[00:34] <Apteryx> ;)
[00:35] <TheMuso> ok.
[00:35] <Apteryx> I guess the .dsc needs to be refreshed first?
[00:35] <TheMuso> It seems the patch is still in your source package for some reason.
[00:35] <TheMuso> Why I don't know.
[00:35] <TheMuso> Yes.
[00:35] <TheMuso> That would help.
[00:35] <Apteryx> I'll try that.
[00:35] <Apteryx> Thanks.
[00:38] <RAOF> If you installed an amd64 kernel you could easily build x86_64 packages in a chroot (such as provided by sbuild or pbuilder).  There be dragons lurking in that area, though, particularly if you're using proprietary drivers.
[00:40] <Apteryx> RAOF, ok. I don't see why would proprietary drivers affect the builds? (If these builds don't depend on them)
=== vddlogger is now known as parislogger
[00:40] <RAOF> Apteryx: Oh, no.  Proprietary drivers won't affect the builds; they just might not work properly if you're using a 32bit userspace with 64bit kernel.
[00:40] <RAOF> So the *builds* would work, but 3D, X, etc might not :)
[00:43] <Apteryx> RAOF, ok. Never attempted to run 3D in a chroot anyway. Anything is possible in a chroot?
[00:44] <Apteryx> (with /sys and such bindings) ?
[00:44] <RAOF> Everything except the kernel.  You'll need to be running the 64bit kernel.
[00:44] <Apteryx> Ok. Thanks :)
=== dendro-afk is now known as dendrobates
[01:11] <Apteryx> TheMuso, any flags that I should set for sbuild? It says "no distribution defined".
=== mwhudson_ is now known as mwhudson
[01:12] <Apteryx> My command right now looks like this: sbuild -As -p successful  pulseaudio_0.99.3-0ubuntu1.dsc
[01:12] <TheMuso> Apteryx: You need to use the -d flag. man sbuild for more info.
[01:13] <Apteryx> TheMuso, I recall there was a command to return distribution name, but forgot it... Any idea what it is?
[01:14] <RAOF> You can also set the default distribution in ~/.sbuildrc
[01:15] <Apteryx> TheMuso, found it, it's `lsb_release -cs`
[01:17] <Apteryx> RAOF, cool
[01:24] <Apteryx> anyone knows a good tuto about getting start with sbuild? Now it tells me I don't have chroots defined in /etc/schroot/schroot.conf
[01:25] <Apteryx> This might be enough to get me started: https://wiki.ubuntu.com/DebootstrapChroot
[01:29] <RAOF> Apteryx: mk-sbuild
[01:30] <RAOF> Apteryx: There's a wiki page on sbuild, but really all you need to know is mk-sbuild (unless you're doing freaky stuff)
[01:33] <Apteryx> RAOF, ok ;)
[02:52] <Apteryx> Hello, the debuild manpage seems incomplete. What exactly do the -S, -a, and -s flag do?
[02:52] <Apteryx> My command is debuild -S -sa
[02:52] <Apteryx> I guess one of these is to sign the packages
[02:52] <Apteryx> -s maybe
[02:54] <Apteryx> Oh... these are dpkg-buildpackage flags!
[02:55] <Apteryx> the manual of dpkg-buildpackage does not explain the -sa flag either :S
[02:57] <RAOF> You sometimes have to traverse the stack there ☹ - dpkg/debuild pass the unrecognised flags down to their tools
[02:57] <RAOF> -sa is “include .orig.tar.gz”, so it's probably a dpkg-source flag.
[02:58] <Apteryx> RAOF, ok!
[02:58] <RAOF> Bah, no of course.
[02:59] <RAOF> It's actually a dpkg-genchanges flag.  It sticks the .orig.tar.* in the _changes_ file1
[03:00] <Apteryx> ok. It's listed in the dpkg-source manual too!
[03:00] <Apteryx> It says "use the .tar file to generate the diff"
[03:01] <Apteryx> Hehe, so we don't really know which uses it ;)
[03:28] <Apteryx> RAOF, if I run sbuild with the '--purge-deps successful' shouldn't the dependencies be preserved in chroot as long as the build does not succeed?
[03:29] <RAOF> Apteryx: But you'll be using a throwaway overlay chroot, which will likely have been cleaned up.
[03:30] <Apteryx> my exact command is: sbuild -As -p successful --purge-deps successful -d natty-i386 ../pulseaudio_0.99.3-0ubuntu1.dsc
[03:31] <Apteryx> What do I have to tell it if I want it to preserve my dependencies while I test a build that fails?
[03:34] <Apteryx> Cause right now it's downloading & installing 214 dependencies everytime... not exactly productive xD
[03:35] <Apteryx> On fedora, mock at least cached the packages (though it reinstalled it).
[03:38] <Apteryx> sbuild also says: "Not cleaning session: cloned chroot in use" when my build fails
[03:41] <RAOF> Apteryx: Oh!
[03:41] <RAOF> Apteryx: Yeah, right.  You want to do something about that ;)
[03:42] <RAOF> There are a couple of options; you can edit /etc/schroot/sbuild/fstab and bind-mount /var/cache/apt/archives, and your existing apt cache will be available in the chroot.  Or you could do what I do, which is to run squid-deb-proxy and add an /etc/apt/apt.conf.d/ snippet setting that proxy.
[03:51] <Apteryx> So I've added this line: /var/cache/apt/archives /var/cache/apt/archives none rw,rbind 0 0
[03:52] <Apteryx> We'll see if it helps ;)
[03:52]  * micahg uses apt-cacher-ng
[04:15] <pitti> Good morning
[04:15] <pitti> mdke: oh sure, will have a look
[04:16] <Apteryx> RAOF, sorry to bother yet again. Still having issues with sbuild ;)
[04:17] <RAOF> Apteryx: Ah, you'll need to do something slightly special with your fstab?
[04:18] <Apteryx> yeah it's still downloading :(
[04:18] <Apteryx> but I have a new issue with gpg
[04:18] <Apteryx> Do I have to do something special for the fstab to be read?
[04:18] <Apteryx> logout / login or something?
[04:19] <RAOF> Bah, no, sorry.
[04:19] <RAOF> I was forgetting the context that schroot's fstab is interpreted in.
[04:19] <Apteryx> what do you mean?
[04:19] <Apteryx> I thought it should have worked
[04:19] <RAOF> I was thinking of my local-packages thingy, which *does* need special handling.
[04:19] <RAOF> Yeah, I think it should work.
[04:20] <Apteryx> i used "rbind" instead of bind, because /sys was already mounted with that
[04:21] <RAOF> Yeah, sorry, I think that what you've done should work.
[04:21] <RAOF> What was your problem again?
[04:22] <Apteryx> 1st problem is dependency being redownloaded at every sbuild try
[04:23] <Apteryx> 2nd problem is gpgv issue: http://pastebin.com/qAyTBsfG
[04:30] <Apteryx> man... loosing patience. time to sleep ;)
[04:30] <Apteryx> RAOF, thanks for all the hints! I'm sure I'll get over it tomorrow.
[05:31] <micahg> pitti: hi, good morning, would you mind if we pushed back the final langpack push for maverick till the end  of the month?
[05:31] <pitti> micahg: sounds fine to me; I'll just follow your plan there
[05:32] <micahg> pitti: thanks, I'll keep you updated as soon as I have a new timeline
[05:46] <RAOF> Oh, dear.  qt4-x11 has a different API on arm.  Joy!
[05:47] <pitti> RAOF: trying to create .symbols files?
[05:47] <pitti> since natty or so, the symbols files are different on all architectures
[05:47] <RAOF> pitti: No, trying to work out whether a bunch of doko_ 's FTBFS filed against mesa are actually a problem in mesa.
[05:49] <RAOF> This is bug #840679, by the way.  qt4-x11 broke API and ABI on arm in 4:4.7.3-4ubuntu1
[05:49] <ubottu> Launchpad bug 840679 in qt4-x11 (Ubuntu Oneiric) "conflicting types in GLES2/gl2.h and GL/glext.h" [High,Confirmed] https://launchpad.net/bugs/840679
[05:50] <micahg> RAOF: here's a little writeup that janimo did for the Ubuntu Developer week about it if it helps any: https://wiki.ubuntu.com/ARM/FTBFS
[05:52] <RAOF> micahg: Ah, good.  That's known, and I'll re-assign any further ftbfs bugs misfiled against mesa to you :)
[05:53] <micahg> heh, I still haven't successfully fixed any of those yet :)
[05:53] <RAOF> They're non-trivial.
[05:53] <RAOF> The whole fixed-function pipeline that a lot of the old GL-using programs will be using is *gone* in GLES2.
[05:54] <RAOF> You get to rewrite things as vertex programs!
[05:54] <micahg> sounds like fun...
[06:03] <didrocks> good morning
[06:41] <mdke> pitti: great, thanks
[07:05] <doko_> RAOF, it might be wrong; I found in another report that Qt is ported to GLES, but e.g. vtk is not ...
[07:05] <doko_> maybe rsalveti does know a bit more
[07:06] <RAOF> doko_: Yeah; micahg pointed me at https://wiki.ubuntu.com/ARM/FTBFS which you'll notice has a section "OpenGL and Qt"
[07:06] <RAOF> :)
[07:06] <RAOF> Basically, anything on arm which directly or indirectly includes that Qt header and which uses, directly or indirectly OpenGL is going to blow up in roughly the same way.
[07:07] <dholbach> good morning
[07:08] <RAOF> I think that anything that's currently *built* and uses that bit of Qt as well as GL will either fail to load with conflicting symbols, or, even better, not work in an even less obvious fashion, like not drawing properly.
=== Quintasan_ is now known as Quintasan
=== SolidLiq is now known as solid_liq
[09:17] <diwic> Could I have a core dev upload pulseaudio for me? PulseAudio as of this morning fails to start due to bug #841649
[09:17] <ubottu> Launchpad bug 841649 in pulseaudio (Ubuntu) "Module "module-jackdbus-detect" should be loaded once at most" [Critical,Fix committed] https://launchpad.net/bugs/841649
[09:17] <diwic> and the fixed stuff is already in lp:~ubuntu-audio-dev/pulseaudio/ubuntu.oneiric
[10:17]  * pitti fixes usb-creator
[10:20] <diwic> pitti, IIRC I submitted a merge proposal for that a day or two ago
[10:21] <pitti> diwic: oh, for the set_cursor() call?
[10:21] <diwic> yes
[10:21] <diwic> None -> False
[10:21] <pitti> diwic: sorry, didn't check for this before, it was an one-minute thing to just fix
[10:22] <diwic> better fix twice than not at all :-)
[10:25] <dupondje> Somebody knows if the primary group really needs to be the same as the username ?
[10:25] <dupondje> cause if its not the case, it seems to break alot of things
[10:32] <cjwatson> dupondje: anything that breaks if it isn't is a bug
[10:32] <cjwatson> it's a lazy assumption
[10:33] <cjwatson> for instance, the Canonical data centre machines are set up such that the primary group is not the same as the username
[10:33] <dupondje> well I changed my default group to 'users' instead of my own group that got created. And that caused to break adding printers/ network connections / etc
[10:34] <dupondje> it just shows I don't have permissions to do those actions
[10:34] <dupondje> all grayed out
[10:34] <cjwatson> sure, I'm not saying it's bound to work, I'm saying that you should file bugs about such things and that people should not be rejecting them
[10:34] <cjwatson> and you can quote me on that
[10:34] <dupondje> hehe ok
[10:34] <dupondje> well just needed to know if it was a requirement to be on your own group :)
[10:35] <dupondje> seems not, so there are some bugs then :D
=== MacSlow is now known as MacSlow|lunch
[10:53] <debfx> cjwatson: have you got my mail about the kubuntu packageset I sent 2 weeks ago?
[10:57] <cjwatson> debfx: oh, yeah, sorry, I'll have a look at it now
[11:02] <debfx> thanks
[11:15] <doko_> I like this one ...
[11:15] <doko_> checking for 64 bit compilation flags... let's see what happens
[11:15] <doko_> checking for 64 bit CFLAGS... -m64 -fPIC
[11:15] <doko_> checking for 64 bit FCFLAGS... -m64 -fPIC
[11:15] <doko_> checking for 64 bit CXXFLAGS... -m64 -fPIC
[11:15] <doko_> checking size of void*... 8
[11:15] <doko_> checking to see if we got 64 bits... oh yes
[11:16] <doko_> [...]
[11:16] <doko_> checking for dummy main to link with Fortran libraries... unknown
[11:16] <doko_> configure: error: in `/home/packages/tmp/u/elmerfem-6.1.0.svn.5272.dfsg/eio':
[11:16] <doko_> configure: error: linking to Fortran libraries from C fails
=== chrisccoulson_ is now known as chrisccoulson
[11:33] <cjwatson> micahg: re the gnash/armel build failure, what do you think is the right thing to do?  Just disable the OpenGL renderer on armel?  I see upstream has a GLES renderer, but it's not in our package yet
=== _jmp__ is now known as _jmp_
=== axp2_ is now known as axp2
[11:57]  * doko_ cries ...
[11:57] <doko_> # Homemade configure file for the ERESI project
[11:57] <doko_> yes, homemade ...
[12:24] <jamespage> doko_: just got an OK on #ubuntu-release for those two FFE's (bug 837979 and bug 837990)
[12:24] <ubottu> Launchpad bug 837979 in maven-plugin-tools (Ubuntu) "[FFE] Sync maven-plugin-tools 2.8-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/837979
[12:24] <ubottu> Launchpad bug 837990 in jtidy (Ubuntu) "[FFE] Sync jtidy 7+svn20110807-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/837990
[13:22] <Apteryx> 'morning ;)
[13:27] <chrisccoulson> doko_, gcc has started crashing when building firefox - https://launchpadlibrarian.net/79032680/buildlog_ubuntu-oneiric-i386.firefox_7.0%7Eb4%2Bbuild2%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz
[13:27] <chrisccoulson> every mozilla build has started failing on oneiric today
[13:27] <chrisccoulson> on i386
[13:38] <doko_> chrisccoulson, looking
[13:38] <chrisccoulson> doko_, thanks
[13:39] <chrisccoulson> i'll start a build on osageorange in a moment. i guess that anything useful from that build has probably long gone now hasn't it?
[14:02] <doko_> ls -l /scratch/packages/tmp/insighttoolkit-3.20.0/obj-arm-linux-gnueabi/Wrapping/WrapITK/Modules/IntensityFilters/wrap_itkMaskImageFilterPython.cxx
[14:02] <doko_> -rw-r--r-- 1 doko doko 25294455 Sep  5 14:46 /scratch/packages/tmp/insighttoolkit-3.20.0/obj-arm-linux-gnueabi/Wrapping/WrapITK/Modules/IntensityFilters/wrap_itkMaskImageFilterPython.cxx
[14:03] <doko_> 30MB sources are actually better than the 300MB sources generated by ghc ...
[14:21] <soren> doko_: Wow. Just... wow.
[14:22]  * tumbleweed hopes doko enjoys insighttoolkit :P
[14:23]  * doko_ passes tumbleweed paraview
[14:25]  * tumbleweed hides
=== dpm is now known as dpm__
[14:29] <Apteryx> Hello :) I'm currently stuck in the process of building an Ubuntu Natty pulseaudio 0.99.3 package.
=== dpm_ is now known as dpm
[14:31] <Apteryx> It used to go further, but now it fails on doing "debuild -S -sa". Result shown here: http://pastebin.com/UaAbGtzk
[14:37] <cjwatson> Apteryx: so remove pulseaudio_0.99.3-0ubuntu1_i386.build from your tree - that almost certainly shouldn't be in the source package anyway
[14:37] <cjwatson> maybe you ran pbuilder in the wrong directory at some point or something
[14:38] <diwic> Apteryx, you might be better off starting with the daily packaging I made at lp:~ubuntu-audio-dev/pulseaudio/packaging.upstream.master
[14:38] <diwic> Apteryx, IIRC that's for both Oneiric and Natty
[14:39] <diwic> Apteryx, in case you get stuck starting with the Oneiric packaging
[14:39] <diwic> of 0.99.3 that is
[14:41] <Apteryx> cjwatson, I tried deleting all those already, keeping only source tree and .orig.tar.gz
[14:41] <Apteryx> I saw somewhere I should run distclean, but this program is not installed on ubuntu.
[14:41] <Apteryx> diwic, you're building this daily?
[14:42] <Apteryx> diwic, so this is the latest latest I can get?
[14:42] <cjwatson> Apteryx: well, the error message says otherwise, so I would check if I were you
[14:43] <cjwatson> I expect that meant 'make distclean' - but that typically only removes files the build system knows about, which I wouldn't expect to include pulseaudio_0.99.3-0ubuntu1_i386.build
[14:43] <diwic> Apteryx, it broke down a few days ago (I should ping someone in launchpad about that) but other than that it should be okay
[14:43] <diwic> Apteryx, it does not include my jack detection patches though
[14:43] <diwic> since they are not yet upstream
[14:44] <diwic> Apteryx, https://launchpad.net/~ubuntu-audio-dev/+archive/pulse-testing
[14:45] <diwic> Apteryx, oh, actually it's only the Oneiric ones that are down, so you can take the Natty version there and you'll have the latest (maybe lag a day or two compared to upstream)
[14:46] <Apteryx> diwic, why does the version says 1:0.98 ? shouldn't it be 1:0.99.3 ?
[14:47] <diwic> Apteryx, because it's taken from git master and as such does not have a fixed number
[14:47] <diwic> Apteryx, you might also be interested in http://pulseaudio.org/wiki/Notes/0.99
[14:52] <Apteryx> diwic, thanks. My goal was primarily to test latest pulseaudio so I'll give your ppa a shot first.
[15:26] <doko_> ScottK: zope packages shouldn't stay partially converted to dh_python2, you know this calls for trouble
[15:26] <ScottK> doko_: I agree.
[15:27] <ScottK> I didn't say that an FFe shouldn't be given, but "It's Universe, so FF doesn't apply" is wrong.
[15:27] <doko_> well, you could have told the former too ;)
[15:29] <ScottK> Sure, but at the time all I had was the one bug mail to look at.
=== Ursinha is now known as Ursinha-lunch
[15:44] <AnAnt> Hello
[15:45] <AnAnt> where do I request for a package to be added in Canonical's partner repository ?
[15:50] <roadmr> hey folks! Gdk.color_parse used to return a tuple (Boolean,Gdk.Color) but at some point last week it started returning just the Gdk.Color. Anyone got any idea which package update caused this?
=== eyes_ is now known as EesIsServer
=== EesIsServer is now known as EyesIsServer
[15:54] <cjwatson> AnAnt: um, normally only the relevant commercial partner would request that
[15:54] <AnAnt> cjwatson: oh
[15:54] <AnAnt> cjwatson: ok, here's the problem, Google's googleearch package sucks !
[15:55] <AnAnt> cjwatson: they ship Qt libraries with the package (and for some wierd reason the package depends on alien !!!)
[15:55] <AnAnt> the problem with the shipped Qt libraries, is that the non-latin support (for ex. arabic) is not working properly
[15:56] <AnAnt> in old versions of googleearth, it was possible to remove those shipped Qt libs, and use system's Qt libs, and the problem would be fixed
[15:56] <AnAnt> but in new versions, some symbol errors happen, and hence googleearth crashes
=== beuno is now known as beuno-lunch
[15:57] <cjwatson> AnAnt: I'm having trouble seeing what this has to do with partner, since there's no googleearth package in partner
[15:58] <AnAnt> cjwatson: oh, I was hoping that if Canonical maintains the package (like it does with skype), that this would be fixed
[15:59] <cjwatson> Google would need to use (IIRC) http://www.canonical.com/partners/isv
[16:00] <cjwatson> I guess you could ask Brian Thomason but I have no idea whether this is something we can initiate
[16:00] <cjwatson> why not make sure the googleearth-package installer package in multiverse works propery?
[16:00] <cjwatson> *properly
[16:06] <AnAnt> cjwatson: ok, will try that
=== njpatel_ is now known as njpatel
[16:24] <micahg> cjwatson: now that we have the libav fix for gnash, I can merge the git snapshot from Debian, maybe that will help
[16:25] <cjwatson> micahg: if you think that's a better idea than a targeted fix, sure ...
[16:27] <micahg> cjwatson: well, we generally take the latest gnash anyways, I'll make sure there are no crazy packaging changes and get an FFe if there are feature changes upstream, anyways, gnash is something that should actually be SRUd regularly due to flash changing
[16:28] <cjwatson> true
[16:47] <victorp> cjwatson, quick question
[16:49] <victorp> cjwatson, nevermind got an answer in another channel ;)
[16:51] <jjardon> hello, anyone with problem loading the datetime preferences from the control center?
[16:53] <doko> jamespage, still online?
[16:59] <cjwatson> victorp: ok
=== beuno-lunch is now known as beuno
=== parislogger is now known as transitlogger
[17:15] <roadmr> sorry for the dumb question, who should I put as reviewer on a FFe merge request? (ubuntu-release perhaps?)
[17:19] <jamespage> doko: yep
[17:19] <micahg> roadmr: you need a bug  for the FFe and you can link it to the merge proposal
[17:20] <doko> jamespage, who did approve the FFe's? I can't see anything in the bug reports
[17:21] <jamespage> "iulian: jamespage: Looks good, please go ahead and get them in."
[17:25] <doko> jamespage, hmm, which report?
[17:28] <iulian> doko: That was on -release. I should've added a comment to the report, sorry for the confusion caused.
[17:28] <cjwatson> roadmr: as micahg says; for the merge request itself, please don't make ubuntu-release the reviewer; ubuntu-sponsors is usual
[17:29] <doko> jamespage, iulian: ahh, ok. just didn't see it
[17:31] <doko> looking at gauche, the 23rd scheme implementation ...
=== Ursinha-lunch is now known as Ursinha
[17:33] <roadmr> cjwatson, micahg : thanks!! putting ubuntu-sponsors as reviewer then
[18:15] <hyperair> can someone from ubuntu-sru please ack https://bugs.launchpad.net/unity/+bug/816632 please?
[18:15] <ubottu> Launchpad bug 816632 in unity (Ubuntu) "Memory leak in IndicatorObjectEntryProxyRemote::GetPixbuf" [Undecided,Fix committed]
[18:16] <hyperair> i posted that patch slightly over a month ago, and it's just gotten ignored.
[18:16] <doko> jamespage, synced
[18:16] <doko> jamespage, could you review https://code.launchpad.net/~xranby/ubuntu/oneiric/libxerces2-java/lp834068 ?
[18:16] <hyperair> i completely forgot about it until some update from natty-proposed came and overrode my unity package and it suddenly started leaking again.
[18:17] <jamespage> doko: already have - LGTM
[18:17] <jamespage> (see MP comments)
[18:18] <jamespage> doko: did you sync all four packages?
[18:18]  * jamespage goes to look
[18:19] <hyperair> er actually i really meant core-dev earlier, not ubuntu-sru.
[18:22] <doko> jamespage, yes
[19:01] <AnAnt> cjwatson: googleearth-package has same problem
[19:02] <AnAnt> cjwatson: btw,  I think it can make use of multiarch
[19:02] <cjwatson> don't confuse me for somebody who cares about googleearth :-)  I was just trying to advise on partner
[19:02] <cjwatson> I expect it could, yes
[19:06] <micahg> cjwatson: I take it we're not going to make the openssl transition complete for oneiric then, are efforts best spent elsewhere then?
[19:14] <cjwatson> micahg: the point of openssl098 wasn't giving up on the openssl transition, it was more that I'm aware that libssl is quite likely to be linked into third-party binaries
[19:14] <cjwatson> so it's more worth a compat package than usual, IMO
[19:16] <micahg> cjwatson: ok, thanks
=== smb` is now known as smb
=== yofel_ is now known as yofel
=== nxvl_ is now known as nxvl
[20:08] <AnAnt> LP 833791
[20:08] <ubottu> Launchpad bug 833791 in texinfo (Ubuntu) "Please merge texinfo 4.13a.dfsg.1-8 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/833791
[20:08] <AnAnt> just changed status to confirmed
=== andreas__ is now known as ahasenack
=== OdyX` is now known as OdyX
[21:15] <Seq> Does anybody know where empathy keeps it's account credentials? It seems to forget all of my accounts at every login, but they are in .mission-control/accounts/accounts.cfg, so it must also track them elsewhere?
[21:17] <Seq> Also, I have a plain-text keyring (I use auto login), but my keyring keeps re-encrypting itself. I'mm clear the passphrase with seahorse and confirm the login.keyring is plain ascii text. Time will pass and I reboot, and my login.keyring is encrypted again. Does anybody know how to fix this?
[22:30] <tmus> Is there a known issue with fglrx in Oneiric lately? I just upgraded my natty laptop to Oneiric, and fglrx just won't load properly - I constantly end up with radeon loaded
[23:18] <Sarvatt> tmus: theres a problem with the blacklist not getting used if you have cryptsetup installed (which puts the drm modules end up in the initrd) leading to radeon/nouveau loading too early, you can get around it by adding your own blacklist in /etc/modprobe.d/ and update-initramfs -u after
=== smb` is now known as smb