[03:10] <kees> any archive admins around to fix busted components on linux-lts-backport-maverick in lucid? most of it is incorrectly in universe.
[03:11] <kees> jdstrand, slangasek: ^^ ?
[03:11] <kees> I should clarify: most of the udebs are in the wrong place...
[03:12] <kees> http://security.ubuntu.com/ubuntu/pool/main/l/linux-lts-backport-maverick/ vs http://security.ubuntu.com/ubuntu/pool/universe/l/linux-lts-backport-maverick/
[04:00] <azop> Is there a WIKI article that goes into detail on extending the installation process?  I need to install some packages during CD installation, but also ask the user for database authenication (this is handled during installation of the package)
[04:19] <slangasek> kees: updated
[04:25] <kees> slangasek: thanks
[05:32] <dupondje> https://launchpad.net/ubuntu/+source/libgphoto2/2.4.11-3 => failed on i386 & armel with  graphviz : Depends: libgvc5 but it is not going to be installed
[05:33] <dupondje> but locally it builds just fine ... maby retry build ?
[06:08] <RAOF> dupondje: Checking, then I'll hit the rebuild button.
[06:11] <dupondje> thx
[07:03] <dupondje> RAOF: fixed i386 it seems, but armel has same issue again :)
[07:03] <RAOF> dupondje: Bah.  So, we need to wait until that dependency chain is fixed.
[07:04] <dupondje> what was wrong exactly ? :)
[07:06] <tkamppeter> RAOF, any news about colord?
[07:07] <RAOF> dupondje: Presumably the archive is inconsistent, waiting for something to be published.
[07:07] <RAOF> tkamppeter: It was successfully syncd yesterday; it's now in Ubuntu.
[07:07] <tkamppeter> RAOF, great, thanks for working on getting it in. I will MIR it then ...
[07:10] <tkamppeter> RAOF, I see the entry in LP now, only it seems to be still waiting in the NEW queue.
[07:11] <tkamppeter> Does anyone know whether one can already post a MIR for a package which is still waiting in NEW?
[07:11] <RAOF> Yes, absolutely.
[07:13] <tkamppeter> RAOF, so I will do the MIR soon ...
[07:14] <tkamppeter> RAOF, I have set bug 741448 to "Fix committed" now.
[07:15] <RAOF> Ta.
[07:15] <RAOF> It shouldn't take long through NEW.
[07:16] <pitti> Good morning
[07:17] <pitti> tkamppeter: hello, pong
[07:18] <tkamppeter> pitti, hi
[07:20] <tkamppeter> pitti, I pinged you yesterday as I have fixed a bug in libjpeg6b which I cannot upload by myself. It is bug 777670. dbdiff is attached. Can you upload it for me? Thanks.
[07:24] <pitti> tkamppeter: hm, how does that affect the linking of other programs?
[07:25] <pitti> sounds like it could affect dependency generation if you build packages against that new libjpeg
[07:26] <pitti> tkamppeter: can you please send this patch as a debian bug as well?
[07:26] <tjaalton> sweet, color management getting in the distro while I'm looking for a decent photo printer :)
[07:27] <tkamppeter> pitti, does Debian use the same LDFLAGS default?
[07:28] <tkamppeter> pitti, if Debian and/or Ubuntu cannot accept the patch, how should we fix HPLIP then?
[07:28] <pitti> I wasn't saying that we cannot accept it, just that I don't understand the impact
[07:29] <pitti> and that it should be done in Debian as well to avoid a divergence of behaviour on such a central package
[07:31] <pitti> tkamppeter: no, we don't have an LDFLAGS delta, just the multiarch build
[08:06] <doko_> seb128, didrocks: https://launchpadlibrarian.net/76875081/buildlog_ubuntu-oneiric-armel.openjdk-6_6b23~pre4-2ubuntu1_FAILEDTOBUILD.txt.gz
[08:06] <doko_> do you already know what's th guilty package?
[08:18] <chrisccoulson> doko_, hmmm, i had some weird failures like that overnight too
[08:19] <chrisccoulson> will take a look
[08:21] <seb128> re
[08:21] <seb128> doko_, no
[08:21] <seb128>  the apt logs don't make it easy to figure what the issue is
[08:21] <seb128>  somebody with access to an armel install needs to run an apt-get install by hand
[08:27] <tkamppeter> pitti, I have committed the fix of bug 780935 to the BZR, can you upload to Debian and Ubuntu? Thanks.
[08:27] <pitti> tkamppeter: is that very urgent?
[08:27] <pitti> tkamppeter: bandwidth sucks here, so if next week is enough, I'll do that then
[08:37] <dupondje> https://launchpad.net/ubuntu/+source/eiciel/0.9.8.1-2 => seems to have failed also due to broken depends. But it builds fine here ... could anyone check and eventually hit the rebuild button :)
[08:39] <tkamppeter> pitti, OK. pitti, you are not at home?
[08:39] <pitti> tkamppeter: no, I'm on the desktop summit in Berlin
[08:39] <tkamppeter> pitti, then we can meet tomorrow. I am in the BoFs of Color Management and Common Printing Dialog.
[08:40] <tkamppeter> pitti, and so also on the Summit some time before and after these meetings and during lunch.
[08:56] <nigelb> Trying to unbork sponsor queue.
[08:57] <nigelb> FYI.
[08:59] <nigelb> ok, so it works locally.
[08:59] <nigelb> *goes* to set cron somewhere accessible.
[09:08] <tkamppeter> pitti, Debian bug is submitted now. You are CCed.
[09:18] <tkamppeter> pitti, Debian bug 637184
[09:30] <nigelb> Hi, can someone in ~ubuntu-dev, please help review and merge https://code.launchpad.net/~nigelbabu/ubuntu-sponsoring/remove-subprocess/+merge/70835
[09:30] <nigelb> Trying to unbork sponsorship overview
[09:31] <nigelb> Laney: around?
[09:31] <Laney> in 30 mins?
[09:31] <nigelb> sure :)
[09:48] <brendand> all of a sudden add-apt-repository is not found in Oneiric
[09:49] <brendand> did this happen to anyone else?
[10:07] <tkamppeter> RAOF, MIR for colord posted as bug 823185
[10:12] <cjwatson> colord binary NEWed
[10:20] <Daviey> Please can an AA promote ipxe, it's causing us upset. (shows in components mismatch, has a valid MIR).  Currently it's causing xen to depwait.
[10:29] <jtaylor> is a MIR planed for underscore and uglifyjs? it would be needed for a new python-sphinx version which has the very useful dh_sphinxdoc debhelper
[10:30] <cjwatson> Daviey: done
[10:32] <Daviey> cjwatson: Thanks!
[10:32] <tkamppeter> cjwatson, thanks for passing through colord, and also for fixing LP for it.
[10:45] <Laney> nigelb: er whoops that took longer than expected
[10:47] <nigelb> Laney: np :)
[10:47] <nigelb> There seems to be deeper problems with the machine anyway.
[10:47] <nigelb> I've got a temporary stop-gap page up
[10:47] <nigelb> http://nigelb.me/sponsoring/
[10:47] <nigelb> and here's the merge https://code.launchpad.net/~nigelbabu/ubuntu-sponsoring/remove-subprocess
[10:49] <Laney> have IS looked at it?
[10:49] <Laney> the machine that is
[10:49] <nigelb> yeah
[10:49] <nigelb> I was working with IS on triaging the problem
[10:49] <nigelb> Still not sure, keeps throwing out OOM errors.
[10:49] <tumbleweed> is it ulmitied?
[10:50] <nigelb> tumbleweed: ulimited?
[10:50] <tumbleweed> yes
[10:50] <nigelb> I don't know what that means.
[10:51] <nigelb> this is the traceback http://pastebin.ubuntu.com/661786/
[10:51] <nigelb> ah, user limited
[10:51] <nigelb> tumbleweed: < Spads> ulimit says unlimited
[10:51] <Spads> nigelb: it's actually strict overcommit
[10:52] <nigelb> Spads: so, is that the cause of the OOM?
[10:52] <Spads> I wouldn't call it the *cause*
[10:53] <tumbleweed> ubuntu-sponsoring is quite a beast, but I'm suprised it's OOMing
[10:53] <Spads> the cause is people using up all the RAM :)
[10:53] <nigelb> heh
[10:53] <Spads> strict overcommit just causes malloc() to error out instead of dragging us down into swap thrashing
[10:53] <nigelb> ah
[10:53] <nigelb> makes sense.
[10:53] <tumbleweed> we could try and improve its memory use
[10:53] <Spads> and it seems that modern apps don't report that situation as gracefully as I'd like
[10:53] <Spads> we're looking to rebalance allocation of resources
[10:53] <nigelb> my merge was to sort of improve it
[10:54] <tumbleweed> python is particularly bad, because it can't free memory easily
[10:54] <nigelb> use a python fucntion instead of using subprocess
[10:54] <Spads> partly to try and identify which apps are consuming how much
[10:54] <Spads> nigelb: yeah, that sounds promising
[10:54] <Spads> if it happens a lot
[10:54] <Spads> who knows
[10:54] <nigelb> I'm trying to run it on my box. I just haven't gotten the cron working
[10:54] <Spads> but if you have test environments, you may want to do some profiling
[10:57] <cjwatson> nigelb: while it's probably a good idea, that isn't in a tight loop or anything so it will make only a negligible difference to resource allocation
[10:57] <Laney> is this supposed to take ages to run?
[10:57] <nigelb> cjwatson: yeah :(
[10:58] <nigelb> Laney: the first time, yes. where ages  = ~ 5 minutes
[10:58] <nigelb> I have a report up on http://nigelb.me/sponsoring/
[11:04] <nigelb> hm, why does something work as my user but not in cron.
[11:05] <cjwatson> locale variables?
[11:05] <cjwatson> or something else in the environment
[11:06] <Laney> I'm getting KEyError from lp.distributions['ubuntu']
[11:06] <nigelb> its a (. /home/nigel/.bashrc && path/to/script)
[11:06] <nigelb> but launchpadlib keeps wanting to authenticate
[11:06] <nigelb> Laney: that's interesting.
[11:08] <cjwatson> presumably for use from cron launchpadlib's credentials will need to be in an unencrypted store rather than (say) gnome-keyring; it has options for this kind of thing
[11:08] <nigelb> indeed, I can see the credentials saved in the lp_data folder
[11:12] <tumbleweed> cjwatson: ubuntu-sponsoring doesn't need credentialed access, IIRC
[11:13] <nigelb> hm, why does it keeping ask me then :|
[11:13] <Laney> it should probably use login_anonymously
[11:13]  * tumbleweed wonders why it doesn't already
[11:23] <tkamppeter> cjwatson, can you also pass argyll (new binary packages), rastertosag-gdi, and cloudprint through NEW?
[11:23]  * cjwatson swaps over libnl and libnl3 source (libnl -> universe, libnl3 -> main)
[11:23] <cjwatson> tkamppeter: when I get a moment, sure
[11:38] <Daviey> cjwatson: Hmm, ipxe is still showing in universe for me?
[11:39] <cjwatson> Daviey: mirroring delay
[11:39] <cjwatson> it's in main on the master archive
[11:40] <Daviey> cjwatson: thanks
[12:32] <Laney> nigelb: tumbleweed: want to look at lp:~laney/ubuntu-sponsoring/anonymous ? small change — seems to work for me
[12:32] <Laney> got distracted by an epic journey that culminated in an NMU to ssmtp on the way to producing that branch :P
[12:33] <nigelb> heh
[12:33] <nigelb> trying it out
[12:35] <tumbleweed> Laney: The only reason I can think of that it would need to be non-anonymous is private security bugs. But those shouldn't be appearing on the sponsorship list anyway, right?
[12:35] <Laney> right
[12:35] <Laney> i doubt it was using any privileged credentials anyway
[12:50] <nigelb> .
[12:50] <nigelb> ~.
[12:50] <tumbleweed> Laney: I'd probably have used __file__ instead of sys.argv, but LGTM
[12:50] <nigelb> Laney: it works
[12:50] <nigelb> btw, something funny
[12:51] <nigelb> ~/laney/ubuntu-sponsoring/anonymous... ubuntu sponsoring anonymous? :P
[12:53] <cjwatson> tkamppeter: it's not grounds for rejection (although it will probably be grounds for stalling the MIR), but please convert cloudprint from python-support to dh_python2, as python-support is deprecated.  http://wiki.debian.org/Python/TransitionToDHPython2
[12:53] <cjwatson> tkamppeter: all three of those belatedly accepted now, anyway
[12:54] <nigelb> tumbleweed: probably easier to just merge Laney's branch than mine :)
[12:56]  * tumbleweed merges them both
[13:17] <cjwatson> mvo: FYI bug 823277 looks fairly urgent
[13:21] <mvo> cjwatson: thanks, I saw it, I have one potential fix in bzr, but need to figure out if its the fix or not, hard to say without a crash file or a backtrace, but I suspect I know what is going on
[13:27] <dupondje> mvo: cjwatson: wasn't that because apt transition ?
[13:32] <mvo> dupondje: the issue in the i386 version should, but this one looks different, I suspect its a divide by zero, but its a bit funny since that code is there since the dawn of time unchanged
[13:33] <Laney> tumbleweed: mine contains nigelb's
[13:33] <Laney> probably as you found
[13:34] <cjwatson> dupondje: random trap crashes aren't due to transitions
[13:34] <cjwatson> (in general)
[13:37] <dupondje> cjwatson: aptitude was crashing here also yesterday for some odd reason, after upgrades it was fixed :)
[13:37] <dupondje> so thats why I tought about this
[13:38] <cjwatson> dupondje: I wuld advise against just chalking things up to transitions unless they are dependency problems
[13:38] <brendand> hi - i really want to use sdptool in one of my scripts, but since the output is progressive, it seems impossible to capture the output to a variable in a bash script
[13:38] <brendand> has anyone here seen anything like that before/know how to deal with it?
[13:39] <cjwatson> normally you need to get the maintainer of the program in question to add an output format that's friendlier to machine parsing
[13:40] <cjwatson> unless I'm misunderstanding you
[13:41] <brendand> cjwatson - maybe that's it
[13:43]  * brendand asks in #bluez
[14:12] <dupondje> https://launchpad.net/ubuntu/+source/eiciel/0.9.8.1-2 => can somebody hit the rebuild button ?
[14:13] <dupondje> thanks :)
[14:13] <barry> dupondje: done
[14:13] <ricotz> mvo, hello, it might be useful to change the Recommends of python-apt from python2.6 to python2.7
[14:14] <barry> btw, are we still in an apt transition?
[14:17] <dupondje> barry: could you kick https://launchpad.net/ubuntu/+source/libgphoto2/2.4.11-3 also ? ;)
[14:17] <barry> dupondje: done
[14:23] <yofel> hey, need some DSO linking help: digikam fails with http://paste.ubuntu.com/661962/ but as you can see on http://paste.ubuntu.com/661963/ it links against "-L/usr/lib -lgphoto2_port -L/usr/lib -lgphoto2 -lgphoto2_port -lm" so... what the hell is wrong?
[14:28] <mvo> ricotz: indeed
[14:29] <ricotz> mvo, perhaps even "python", but anyhow it would prevent pulling in python2.6 ;)
[14:30] <ScottK> Since there will not be a python2.8, python2.7 is pretty safe.
[14:43] <tkamppeter> mterry, hi
[14:43] <mterry> tkamppeter, hello
[14:44] <mvo> ricotz: fixed in bzr
[14:44] <tkamppeter> lcms2 seems to be synced from Debian currently, should I introduce a Ubuntu delta for getting a symbols file?
[14:44] <tkamppeter> mterry, ^^
[14:46] <mterry> tkamppeter, for such things, I usually add a delta and submit the patch back to Debian.  I've never had someone reject a symbols file additions, so usually we can sync later
[14:46] <mvo> barry: do you know about the state of python3 oauth? I was doing some research on what it takes to port software-center to python3 and the dependencies look actually pretty good, but for oauth there seems to be nothing there currently
[14:47] <barry> mvo: hi.  i'm not aware of any py3 oauth work being done.  iirc, the oauth package isn't that big, so maybe that's a port we can take on?
[14:49] <mvo> barry: indeed, I will do some research on this next
[14:49] <barry> mvo: awesome.  let me know if i can help
[14:50] <tkamppeter> mterry, I will add it.
[15:08] <ricotz> mvo, thanks
[15:13] <tkamppeter> mterry, symbols file added to lcms2 now, bug 823180.
[15:13] <mterry> tkamppeter, awesome, thanks.  I marked approved then
[15:14] <barry> mvo: is apt still busted?
[15:17] <mvo> barry: is it?
[15:17] <mvo> barry: what kind of issue do you see?
[15:23] <tkamppeter> mterry, can you have a look at argyll (bug 821883). didrocks rejected it due to its size, and now I am in doubt whether we can continue with adding color management support (argyll delivers the support for calibration devices).
[15:25] <tkamppeter> mterry, I have updated argyll and merged argyll with libicc as they come from the same upstream project. Should we perhaps do as alternative, if we cannot take argyll this cycle, the source package of argyll into main, so that it pulls libicc into main but leave the binary package argyll in Universe (or perhaps in main but not on CD)?
[15:27] <mterry> tkamppeter, I'm not terribly familiar with argyll, but if the profiles can be split out so the size isn't a problem without killing functionality, then that would be good.  But didrocks can help with this, he's doing the argyll MIR
[15:29] <tkamppeter> mterry, problem is also that I do not see any .icc files in argyll.
[15:29] <tkamppeter> mterry, and of the stuff in /usr/bin I do not know what to split out.
[15:33] <barry> mvo: http://pastebin.ubuntu.com/662020/
[15:35] <jml> apt-file seems to be looking in the wrong place for Contents files.
[15:35] <mvo> barry: oh, what mirror are you using? is it maybe lacking behind?
[15:35] <jml> Ignoring source without Contents File:
[15:35] <jml>   http://archive.ubuntu.com/ubuntu/dists/oneiric/main/Contents-amd64.gz
[15:36] <jml> rather than, say, http://archive.ubuntu.com/ubuntu/dists/oneiric/Contents-amd64.gz
[15:36] <barry> mvo: us.  cool, i'm about to head out for lunch, so hopefully it'll catch up by then :)
[15:36] <barry> thanks
[15:41] <tjaalton> cjwatson: I'm preparing an SRU for grub-gfxpayload-lists in natty, is '0.2~natty1' a valid version number for it?
[15:42] <geser> jml: where does Debian put those files? perhaps LP has to adopt to the new location where apt-file expects them
[15:42] <cjwatson> tjaalton: let's get out of the habit of using codenames; we're halfway to the point where they won't sort correctly when we wrap round the alphabet
[15:43] <tjaalton> cjwatson: heh, right. so '0.2.1' would be ok then?
[15:43] <cjwatson> 0.2.1 would be fine, yes
[15:43] <cjwatson> 0.2~natty1 would be rejected due to being lower than the version in the archive anyway :)
[15:44] <tjaalton> yeah I was wondering about that..
[15:45] <cjwatson> geser,jml: yeah, I think Debian may have recently moved to per-component Contents files
[15:45] <cjwatson> fun :-/
[15:46] <debfx> mterry: there is a typo in the libsigsegv2 symbols file which causes gawk to be uninstallable
[15:46] <mterry> debfx, oh man, k.  what's the typo?
[15:46] <debfx> libsigsev2 instead of libsigsegv2
[15:46] <mterry> doh
[15:47] <mterry> I'll fix it
[15:48] <cjwatson> hah, I wondered about that but hadn't looked yet
[15:50] <tjaalton> cjwatson: doesn't this look ok to you?-) http://bazaar.launchpad.net/~tjaalton/ubuntu/natty/grub-gfxpayload-lists/bug-777212/revision/6
[15:50] <tjaalton> hah
[15:51] <Pici> weird.
[15:52] <tjaalton> cjwatson: duh, should've used -proposed
[16:01] <cjwatson> tjaalton: looks good to me
[16:03] <tjaalton> cjwatson: thanks, I'll push the version with natty-proposed to the natty branch, and upload it to the archive
[16:07] <mvo> barry: for when you are back, https://code.launchpad.net/~mvo/+junk/python3-oauth contains my fiddling, python3 oauth/example/server3.py and in a different terminal oauth/example/client3.py work except the last step (but you first need to bzr-buildpackage and install the python3 debs). looks like some craziness with the str/bytes in the hash, I'm not sure yet what the best approch for this is
[16:07] <mvo> but dinner first :)
[16:20] <zyga> mvo, ping me after dinner please
[16:22] <tjaalton> cjwatson: looks like I can't push the branch to the proper place, so I've updated my own branch and uploaded it to natty-proposed
[16:27] <bdmurray> Could I get kerneloops uploaded? http://people.canonical.com/~brian/tmp/kerneloops_0.12+git20090217-1ubuntu14.debdiff
[16:46] <mvo> zyga: its probably going to take a while, best is if you just msg me
[16:47] <zyga> mvo, quick feedback: c-n-f has some patches coming, trunk was in a bad shape, I just created a new branch from the core-dev branch you maintained, created a development team with you and me in the initial set
[16:48] <zyga> mvo, the goal is to get those bugs fixed and landed in trunk, invite more people to the -developers team and move the project
[18:54] <mvo> zyga: wooooh, awsome!
[19:12] <zyga> mvo, :-)
[19:43] <bdmurray> SpamapS: did you sort out how to create an apport package failure?
[19:44] <SpamapS> bdmurray: yes
[19:44] <bdmurray> SpamapS: and the answer is?  I'd like to try one now
[19:45] <SpamapS> bdmurray: Oh I just made a postinst that intentionally crashes.
[19:45] <SpamapS> bdmurray: for iterating it was easier to just  use 'apport-bug pacagename' tho
[19:46] <bdmurray> SpamapS: right I was sure if you were trying to create a ProblemType of Package or just Bug
[19:46] <bdmurray> er wasn't sure
[19:47] <SpamapS> bdmurray: I thought it mattered but it didn't. :)
[19:52] <debfx> could someone please upload a no-change rebuild of gawk to make it installable again
[19:53] <debfx> there was a typo in libsigsegv which has been fixed now
[19:54] <infinity> debfx: Has nothing else built against that broken libsigsegv?
[19:54] <debfx> infinity: nope
[19:56] <debfx> oh, there is one
[19:56] <debfx> gnu-smalltalk
[19:57] <debfx> I'll fix that one
[20:00] <infinity> Alright.  I'll bounce gawk.
[20:00] <infinity> Just double-checked on ftpmaster, and gawk and libgst7 are definitely the only two broken on all 4 arches.
[20:06] <debfx> infinity: thanks
[20:06] <infinity> debfx: NP.
[20:06] <infinity> https://launchpad.net/ubuntu/+source/gawk/1:3.1.8+dfsg-0.1build1
[20:37] <davmor2> tremolux: hey dude, just clocked this on my netbook. https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/823534
[20:38] <davmor2> tremolux: I've added a screenshot for you, display size is 1024x576
[20:44] <lifeless> urgh
[20:44] <lifeless> could someone reland my fix for https://bugs.launchpad.net/ubuntu/+source/apt/+bug/816606
[20:45] <infinity> erk.
[20:54] <infinity> lifeless: Re-applied.
[20:54] <lifeless> infinity: thanks
[21:02] <slangasek> infinity: will you poke mvo to figure out how it got dropped?  maybe he's using a bzr branch not listed in the Vcs-Bzr field?
[21:02] <infinity> slangasek: Yeah, I will.
[21:02] <slangasek> ta
[21:02] <infinity> (Though, I do consider "this isn't in my VCS" to be a copout for not checking changes on a merge)
[21:03] <infinity> But in this case, I suspect it was just him switching between sid and experimental and not really being fully awake.
[21:03] <lifeless> he had the changelog for the change
[21:03] <lifeless> so it wasn't an overwrite.
[21:03] <slangasek> ah
[21:03] <slangasek> infinity: if you're doing the merge *via* the VCS, and the VCS is documented in debian/control, I think it's a perfectly reasonable position :)
[21:03] <lifeless> possibly a mistaken conflict resolution, or even a merge that was confused
[21:04] <infinity> slangasek: The VCS is not the authoritative source, the archive is.  So, I'd be inclined to disagree that people shouldn't at least do a cursory check to see if they match.
[21:05] <infinity> slangasek: But I realise there are forces at work that insist my position should be invalidated.
[21:05] <infinity> slangasek: (Either way, in this case, I'm pretty sure it was just the violent sid->experimental merge that made him drop a few bits on the floor)
[21:19] <jamespage> any archive admins around?  if so please could the NEW binary packages for maven-stapler-plugin and stapler-adjunct-timeline be accepted into oneiric - thanks
[21:26] <slangasek> jamespage: looking
[21:27] <slangasek> jamespage: maven-red-swingline-stapler accepted
[21:28] <jamespage> slangasek: thankyou!
[21:31] <soren> Hm... When I try to get my proxy settings in Chrome or Chromium after upgrading to Oneiric, it gives me the GNOME proxy settings page rather than Chrome's (or Chromium's) own and the proceeds to ignore what I've set in there.. I've no clue where to start debugging that. Any ideas?
[21:43] <seb128> soren, is chromium reading the gconf database and GNOME3 writting to gsettings?
[21:44] <seb128> soren, the second part is not a question but I don't know if chromium try gsettings before gconf
[21:44] <seb128> soren, which is likely to be the issue there
[21:45] <soren> seb128: I'm trying to work out how it decides where to look.
[21:46] <seb128> soren, set the gconf key using gconf-editor and see if it makes it work?
[21:46] <soren> seb128: I see support for both, but it somehow decides which to use.
[21:50] <soren> seb128: Hm... Maybe I'm not setting the right values in gconf.
[21:50] <soren> Or it's ignoring both.
[21:50] <soren> Weird.
[21:51] <soren> seb128: Good suggestion, though. :-/
[21:53] <soren> Is there an equivalent to gconf-editor for gsettings?
[21:57] <Daviey> soren: dconf-editor ?
[21:59] <soren> Daviey: I thought dconf and gsettings where different things?
[22:01] <Daviey> soren: try it, i might be way off base tho.
[22:01] <Daviey> <-- not Desktop :)
[22:01] <soren> Daviey: Hmm...
[22:02] <soren> dconf-editor is from dconf-utils..
[22:02] <Daviey> jah
[22:02] <soren> which depends on a bunch of stuff, including:
[22:02] <soren> dconf-gsettings-backend | gsettings-backend
[22:02] <soren> So there's certainly some connection.
[22:02] <soren> Oh!
[22:03] <Daviey> soren: We are 10meters away, why are we talking on irc?
[22:03] <soren> dconf is a low-level configuration system. Its main purpose is to provide a backend to GSettings on platforms that don't already have configuration storage systems.
[22:03] <soren> Daviey: Shouting would be rude?
[22:03] <Daviey> true.
[22:03] <soren> And futile, I imagine. The sound proofing job on this room is uncanny.
[22:08] <soren> Daviey: I stand corrected.
[22:50] <TheMuso> d/c