[00:48] <TheMuso> 5~/c
[01:07] <bdrung> bdmurray: have you played with sponsor-patch?
[01:15] <bdrung> bdmurray: thanks for fixing one TODO. i have added two new TODOs. :)
[03:30] <bdmurray> bdrung: I haven't played with it was looking at the patch / debdiff stuff like we'd talked about
[04:05] <hamish> can anyone recommend an IDE for PostgreSQL on Ubuntu?
[04:45] <hamish> can anyone recommend an IDE for PostgreSQL on Ubuntu?
[06:21] <glick> hey excuse me is there any reason why lucid is using such an old version of mod_wsgi 2.8 when 3.3 is long out?
[06:23] <micahg> glick: it might not have been packaged in time, maverick has 3.2-2
[06:23] <glick> micahg, the maverick repos?
[06:23] <micahg> glick: yes
[06:23] <micahg> bzr diff
[06:23] <micahg> oops
[06:25] <nigelb> heh
[06:26] <glick> is there a tutorial on how to add the maverick repos i did a goog search and cant see anything
[06:27] <nigelb> you probably can't just add and use
[06:27] <glick> oh
[06:27] <glick> is it difficult to make a deb from the source?
[06:30] <nigelb> not really.
[06:30] <nigelb> Get the source and rebuild, I'm trying to figure out how to build it without pbuilder.
[06:31] <nigelb> But it may fail horribly depending on the versions of the depends....
[06:43] <glick> can i just install it via the install script?
[06:43] <glick> do i have to use .deb?
[06:46] <nigelb> you can install it via the script, but then uninstalling would be kinda tough.
[06:47] <nigelb> I wish I had the docs handy here.
[07:25] <pitti> Good morning
[07:37] <\sh> pitti: good morning to you too :)
[07:51] <dholbach> good morning
[07:56] <pitti> hey \sh, how are you?
[07:56] <pitti> dholbach: guten Morgen
[07:56] <dholbach> hey pitti
[07:56] <\sh> pitti: fine :) but fighting with some strange problems regarding glibc, passwd, crypt and ldap ;)
[07:57] <\sh> moins dholbach
[07:57] <dholbach> heya \sh
[07:57] <siretart> einen wunderschoenen guten morgen zusammen! (or english: good morning) :-)
[07:57] <\sh> hey siretart :)
[07:58] <siretart> hi \sh
[07:58] <micahg> hi \sh
[07:58] <\sh> moins micahg :)
[07:59] <\sh> guys, when someone has a solution to this problem I described on http://www.shermann.name/2010/08/openldap-passwd-and-crypt-passwords.html don't hesitate to come up with a solution ;)
[08:12] <micahg> pitti: thanks for enigmail-locales, I almost forgot about it too
[10:26] <bigon> slomo, any reason git file for libgee has been removed from debian? do you think you could put the same pkg as in maverick in experimental?
[10:27] <bigon> s/git/gir
[11:38] <\sh> directhex: the solution you mentioned doesn't work somehow, or I put the attributes in the wrong cn=config schema
[12:13] <directhex> \sh, it's a global i think. should just go somewhere inoffensive in slapd.conf
[12:13] <\sh> directhex: I don't have slapd.conf , using cn=config schema..which means the olcPasswordCryptSaltFormat goes into global cn=config and the olcPasswordHash goes to cn={-1}frontend,cn=config
[12:15] <directhex> erk
[12:15] <directhex> can't help with that kind of config, i'm afraid
[12:38] <\sh> directhex: fixed...the ldap.conf on the client needs a setting in ldap.conf: pam_password exop
[12:38] <\sh> then it works with the passwordhash and passwordcryptsaltsyntax
[12:39] <directhex> \sh, oh, i didn't think about the client config
[12:39] <directhex> \sh, glad you got it working, though
[12:39] <\sh> directhex: me neither :) just had a quick chat with someone on #openldap
[12:39] <\sh> I'll blog about the solution
[12:40] <directhex> \sh, as long as their first response wasn't "you did WHAT? what idiot suggested that?"
[12:41] <\sh> directhex: well...
[14:14] <cjwatson> JFo: Following up on our discussion at the sprint, how did your collation of the kernel bugs associated with GRUB setting gfxpayload=keep go?  Is there a mailing list thread I can catch up on or anything?
[14:15] <JFo> cjwatson, honestly I think I must have let that fall off my radar.
[14:16] <JFo> let me catch up on it and get back with you.
[14:16] <JFo> my sincere apologies for that
[14:17] <JFo> cjwatson, was that on a blueprint somewhere? I found at least one that I was not subscribed to
[14:17] <cjwatson> JFo: foundations-m-grub2-boot-framebuffer
[14:17] <JFo> excellent
[14:17]  * JFo pulls it up
[14:17] <cjwatson> I think we may end up backing it out for beta
[14:17] <JFo> I think so.
[14:17] <cjwatson> but I'd really like to see the kernel side of it make progress anyway so that we can turn it on next release
[14:18] <cjwatson> (and it's easy to flip the switch back and forward for testing)
[14:18] <JFo> certainly
[14:18] <JFo> I'll do some of the legwork now and get back with you so we can plan for UDS at least
[14:19] <cjwatson> thanks
[14:19] <JFo> my pleasure
[14:19] <JFo> I apologize again
[14:25] <penguin42> cjwatson: That 1.4.20.2-1ubuntu1 iscsitarget works great - thanks
[14:25] <cjwatson> cool
[14:26] <cnd> I've heard that dbgsym packages can be generated in ppas now
[14:26] <cnd> if so, anyone know how to do that?
[14:31] <chrisccoulson> cnd - build-depend on pkg-create-dbgsym?
[14:31] <chrisccoulson> not sure how else to do it for PPAs, unless something changed
[14:32] <cnd> chrisccoulson, oh ok
[14:32] <cnd> is that documented somewhere?
[15:11] <cjwatson> chrisccoulson: I have no straightforward way to test this, but do you think that something like http://paste.ubuntu.com/480968/ could fix bug 544139?
[15:13] <cjwatson> robbiew: perhaps bug 605042 should be regarded as a Linaro bug?
[15:13] <cjwatson> doko_: is anything happening with bug 601030?
[15:14] <cjwatson> slangasek: do you know what's happening with bug 553745?
[15:14] <chrisccoulson> cjwatson - yeah, that would probably fix it
[15:15] <cjwatson> chrisccoulson: I might stick it in a PPA or something and see what happens
[15:15] <robbiew> cjwatson: aye
[15:16] <robbiew> cjwatson: removed 605042 from the agenda
[15:16] <cjwatson> ta
[15:19] <pitti> smb: can you please make bug 614426 public? It's referenced by the lbm SRU
[15:21] <smb> pitti, Hm, I don't see much reason to keep it private, but I need to ask support guys
[15:27] <ogra> seb128, would it be possibel to fix bug 607709
[15:38] <seb128> ogra: I don't even understand why things upstream let in the tarball is an issue, we probably have some of those in lot of sources
[15:39] <seb128> ogra: oh sorry I was thinking to an another one
[15:39] <seb128> ogra: well the tarball is the upstream one
[15:40] <seb128> ogra: I've asked to report the bug to upstream, nobody did
[15:40] <seb128> ogra: it will be fixed the day somebody cares enough to do what was suggested there
[15:43] <ogra_cmpc> seb128, ok, i'll care for upstreaming
[15:43] <ogra_cmpc> (oempa4 really needs these files in maverick)
[15:43] <ogra_cmpc> *omap4
[15:44] <seb128> ogra_cmpc, thanks
[15:44] <seb128> ogra_cmpc, upstream might have a reason for not shipping those
[15:44] <seb128> ogra_cmpc, I've also difficulties to understand why those are needed since it builds fine without them
[15:44] <ogra_cmpc> might be, but wuld we be able to ship them in a patch if upstream doesnt make it in time ?
[15:45] <ogra_cmpc> the subsequent omap4 modules and codecs make use of these files apparently
[15:46] <seb128> ogra_cmpc, I'm fine adding those, I just want somebody to talk to upstream to know why they don't ship them
[15:46] <seb128> could be legal reasons, could be an error, could be because the code is buggy
[15:47] <ogra_cmpc> yeah
[15:47] <seb128> ogra_cmpc, thanks for understanding ;-)
[15:47] <ogra_cmpc> thanks for explaining :)
[15:47]  * ogra_cmpc hugs seb128 
[15:47]  * seb128 hugs ogra_cmpc
[15:50] <smb> pitti, Seems we cannot make that bug public and I need to re-upload lbm with a new public bug number for it
[15:57] <Riddell> dyfet: I don't suppose you've got anywhere with the kdebindings issue?
[15:57] <dyfet> Riddell: I am discussing right now with NCommander.  It has become a python-qt4 build issue at the moment
[16:04] <slangasek> cjwatson: 553745> no; my understanding was that although plymouth still has bugs there, the mountall change would render them inert
[16:05] <robbiew> pitti: ping
[16:06] <cjwatson> slangasek: the one that's already happened?  I would have thought it would mainly decrease the incidence
[16:08] <slangasek> cjwatson: well - my expectation was that it decreased it to zero.  But if it's still happening, it should of course be a priority to fix
[16:14] <asac> kees: you did the MIRs for touch stuff already?
[16:15] <asac> that clearly would make my day ;)
[16:15] <kees> asac: I did! at least the three mentioned yesterday
[16:15]  * asac hugs kees
[16:16] <cjwatson> slangasek: the assertion towards the end of the bug is that it's still happening occasionally, yes
[16:16] <cjwatson> slangasek: but there's little detail, so I don't know whether it's the same thing
[16:17]  * kees hugs asac back :)
[16:17] <NCommander> Riddell: its not a python-qt4 issue. Its a cmake file issue. http://paste.ubuntu.com/480989/ - here's the patch that allows pykde4 to build. Smoke still FTBFS
[16:17] <slangasek> cjwatson: <nod>
[16:25] <pitti> robbiew: hello
[16:26] <robbiew> pitti: hi :)
[16:26] <robbiew> pitti: I had a ToDo from last week's release meeting
[16:26] <robbiew> slangasek wanted to know if the SRU tracker could spit out a warning about significant size increases in packages in main
[16:28] <pitti> robbiew: I wrote a script for comparing the package size deltas of two (alternate) isos
[16:28] <pitti> robbiew: do we need that for LTS point releases? then it's already there
[16:28] <robbiew> slangasek: ^?
[16:29] <slangasek> pitti: what I think we want is a warning about size increases of packages *before* we start trying to turn them into ISOs
[16:29] <slangasek> by the time we did that for this round, it was too late
[16:30] <robbiew> how would we define "significant size increase"?
[16:30] <pitti> it shouldn't be too hard to adopt the logics of iso-deb-size-compare to compare *-updates against final
[16:30] <pitti> robbiew: iso-deb-size-compare lists added packages, removed packages, and size differences of > 100 kB
[16:31] <pitti> well, size increases (we don't generally complain about decreases)
[16:31] <slangasek> pitti: hmm, so you reinvented cd-size-analysis on antimony? :)
[16:31] <pitti> but I guess for SRUs we shoudl actually list decreases as well, they are probably a bug
[16:31] <pitti> slangasek: I couldn't get that to work for the life of it
[16:32] <slangasek> pitti: regardless, as I said, this is something I think we need to be aware of in the SRU process, not just when we're to the point of creating ISOs
[16:32] <pitti> right, understood
[16:32] <pitti> it could become part of sru-report
[16:32] <slangasek> robbiew: "significant size increase" - more than 5%, or more than 300k increase across the set of binary packages
[16:32] <slangasek> maybe filtered by seed
[16:34] <pitti> slangasek: I guess for all packages in *-proposed and *-updates should do for now; it's not that many usually
[16:34] <pitti> but we could add the component indeed
[16:34] <pitti> oh, "... in main"
[16:40] <slangasek> robbiew: btw, I'm hesitant to approve this last message to ubuntu-announce...  I'm worried that we're no longer meeting the expectations of this being a "low volume" list
[16:40] <robbiew> slangasek: hmm...fair enough...I'll copy ubuntu-devel
[16:56] <smb> pitti, FWIW I am now done adding new stuff to the sru upload queue
[17:58] <goldins> Hello, I hope this is not off-topic but I'm confused as to whether the issue I'm having with the new openssh (5.5) smartcard support is my fault or ubuntu's fault. The output says "dlopen pkcs11 failed: /usr/lib/pkcs11: cannot read file data: Is a directory" when I run ssh -I pkcs11
[17:59] <goldins> (I'm running maverick)
[18:04] <cjwatson> goldins: one moment
[18:04] <goldins> cjwatson: it's cool, I can wait
[18:05] <cjwatson> goldins: your -I option is certainly wrong - it's meant to be a path to a library
[18:05] <cjwatson> goldins: does http://www.opensc-project.org/opensc/wiki/OpenSSH help?
[18:05] <cjwatson> the syntax has changed from earlier unofficial patches against OpenSSH
[18:06] <cjwatson> if you aren't using OpenSC, presumably you have some other PKCS#11 provider, in which case you need to provide the full path to its .sos
[18:06] <cjwatson> er, .so
[18:06] <goldins> cjwatson: it seems that if I move the directory out of the way and create a link instead to opencryptoki/libopencryptoki.so.0.0.0, I get a different error
[18:07] <cjwatson> you shouldn't move files around there; you should provide a different argument to -I instead
[18:07] <goldins> cjwatson: if that's the case, then ssh without arguments shouldn't say this: [-I pkcs11]  among other things
[18:07] <cjwatson> pkcs11 is a substitution variable there
[18:07] <goldins> I see
[18:07] <cjwatson> just like -p port
[18:07] <cjwatson> you aren't meant to literally type port there
[18:07] <goldins> I suppose :-P
[18:08] <cjwatson> the man page is more helpful
[18:08] <cjwatson>      -I pkcs11
[18:08] <cjwatson>              Specify the PKCS#11 shared library ssh should use to communicate
[18:08] <cjwatson>              with a PKCS#11 token providing the user's private RSA key.
[18:08] <goldins> also, /usr/lib/pkcs11/PKCS11_API.so is a dead link to ../opencryptoki/libopencryptoki.so but I think that's addressed in this bug:
[18:09] <cjwatson> mm, I don't know anything about the specific implementations, only about the OpenSSH end of it
[18:09] <goldins> https://bugs.launchpad.net/ubuntu/+source/opencryptoki/+bug/237392
[18:10] <cjwatson> yeah, that's a bug, it will probably work if you install libopencryptoki-dev
[18:11] <cjwatson> but in the meantime I guess you can just say 'ssh -I ./usr/lib/opencryptoki/libopencryptoki.so.0.0.0'
[18:11] <cjwatson> er, 'ssh -I /usr/lib/opencryptoki/libopencryptoki.so.0.0.0', stray '.'
[18:13] <cjwatson> and you can put the provider path in PKCS11Provider in ~/.ssh/config once it works
[18:17] <goldins> cjwatson: it seems to work with /usr/lib/opensc-pkcs11.so thank you very much
[18:19] <cjwatson> goldins: you're welcome
[18:30] <SpamapS> ugh, why do I always seem to get changelog merging wrong? :-P
[18:30] <slangasek> Riddell: re: qt4-qws - I had a good chat with svuorela yesterday on IRC; the ABI breakage isn't as bad as all that (it really is confined to the GUI components), I'm going to put together a proof-of-concept build that only rebuilds the really-truly-incompatible bits and see what that does for build time
[18:31] <slangasek> SpamapS: because MoM is the only tool that actually helps with this? :)
[18:31] <Riddell> slangasek: you want to talk to alf and asac mostly, it's their package
[18:32] <slangasek> Riddell: well, if I prove that the build overhead is small and I'm arguing to put it in qt4-x11, that impacts *your* package :)
[18:32] <SpamapS> slangasek: bzr needs a "changelog mode"
[18:33] <SpamapS> that treats each block as its own immutable entity
[18:33] <Riddell> slangasek: mm
[18:33] <slangasek> SpamapS: recent bzr merge-package's that I've done seem to have totally mangled the debian/changelog... so maybe it already has one but it's not very good :)
[18:34] <SpamapS> slangasek: we should probably go easy on james_w .. I think he's actually found a way to work 25 hours a day.
[18:35] <james_w> slangasek: please file bugs
[18:35] <james_w> it does indeed have one and we should improve it :-)
[18:36] <slangasek> james_w: next time I reproduce it, I will :)
[18:36] <james_w> thanks
[18:38] <slangasek> james_w: rough description (from memory) of what I was seeing: all the changelog entries were reordered into strict version order, including those that were already present on both branches and listed in the order we wanted them.  Sound familiar at all?
[18:38] <james_w> slangasek: sounds plausible
[18:38] <slangasek> k
[18:41] <tumbleweed> SpamapS: err, changelog merging? merge-changelog debian/changelog ../ubuntu/debian/changelog | sponge debian/changelog <- normally does the trick
[18:49] <SpamapS> tumbleweed: whoa.. thats two commands I don't know anything about. merge-changelog and sponge... will do some reading
[18:49] <tumbleweed> sponge is in moreutils (which is full of awesome), merge-changelog in ubuntu-dev-tools
[18:50] <slangasek> hmm, why has merge-changelog not been submitted to devscripts?
[18:51] <tumbleweed> SpamapS: if you are manually MoMing, I have a script that uses UDD (grab-udd-merge ubuntu-dev-tools branch)
[18:53] <SpamapS> tumbleweed: in this case it was just a superceded version in a merge proposal.. but I've definitely fought with MoM'ing too.
[18:54] <cjwatson> or dpkg-mergechangelogs
[18:54] <cjwatson> would be better to improve that since that's about as central as we're going to get
[18:54] <SpamapS> ah ok, so there is some help available.
[18:55] <cjwatson> might be worth extending dpkg-mergechangelogs to be able to work without a base version
[18:59] <slangasek> cjwatson: y'know, I knew dpkg-mergechangelogs was being created, but I kept failing to find it every time I looked for it... looks like it's finally made it into dpkg-dev, hurray :)
[20:36] <Guest77779> Hallo. Mir ist unter Ubuntu 10 das Tray-Icon für die Lautstärkeregelung entschwunden. Ich schaffe es einfach nicht, dieses wieder dort auftauchen zu lassen. Was muss ich tun?
[20:39] <sistpoty> Guest77779: Stelle Deine Frage bitte in #ubuntu-de, das hier ist der Channel fuer Ubuntu-Entwicklung
[20:40] <Guest77779> Oh, entschuldigung. Dachte, ich befinde mich dort.
[20:40] <Guest77779> Gute Nacht.
[20:40] <sistpoty> kein Problem, gute Nacht
[20:43] <bcurtiswx> Ok, maybe someone can help me here.  I'm trying to get fix a FTBFS in folks.  I get an error of Couldn't find include 'Gee-1.0.gir' (search path: ['.', '/usr/share/gir-1.0', '/usr/share/gir-1.0', '/usr/share/gir-1.0'])
[20:43] <bcurtiswx> which is here: https://edge.launchpad.net/ubuntu/+source/libgee/0.5.2-1ubuntu2
[20:44] <bcurtiswx> in gir1.0-gee-1.0
[20:44] <bcurtiswx> but, when adding that to build-dep in folks it says its a virtual package
[20:45] <bcurtiswx> i already have libgee-dev as a dep, and still get that error
[21:09] <eax> Hi there - Is it possible to try out the new Unity-shell somehow? Not sure if this is the right channel, if not; Sorry!
[21:20] <directhex> eax-afk, try #ubuntu
[21:20] <eax-afk> directhex: Will do, thanks :)
[21:30] <mathiaz> jdstrand: hi!
[21:30] <mathiaz> jdstrand: could you demote migrationtools and traceroute to universe?
[21:31] <mathiaz> jdstrand: they already show up in component-mismatch.txt
[21:32] <jdstrand> mathiaz: sure, but traceroute in universe seems odd...
[21:32] <mathiaz> jdstrand: IIUC tracepath is a better alternative
[21:34] <jdstrand> mathiaz: maybe, but I would never think to type 'tracepath'
[21:34] <jdstrand> mathiaz: regardless of my thoughts, done
[21:34] <mathiaz> jdstrand: thanks!
[21:42] <SpamapS> mathiaz: well at least *something* got demoted. :)
[21:47] <barry> james_w: you don't happen to still be online do you?
[21:48] <james_w> barry: mais oui
[21:49] <barry> james_w: so, i'm seeing something that i don't understand.  i'm working on python-numpy.  we have 1.3-mumble in maverick, squeeze has 1.4-mumble.  i go to a branch of lp:ubuntu/python-numpy and do 'bzr merge-package lp:debian/squeeze/python-numpy'.  the branch now contains numpy 1.4-mumble...
[21:50] <barry> james_w: dch -i and add 1:1.4.1-4ubuntu1 (or ...4ubuntu1ppa0) and change from unstable to maverick.  the bzr bd -S
[21:51] <barry> james_w: this produces both an orig.tar.gz and a debian.tar.gz, but only the debian.tar.gz gets dput'd to my ppa, and ppa rejects it because it can't find the orig.tar.gz.  what gives?
[21:52] <james_w> barry: so, there is an optimisation in packaging that you don't have to provide the .orig.tar.gz if the target already has it
[21:52] <james_w> barry: and there is a convention around version numbers that you start at -1 and work your way up from there
[21:53] <james_w> barry: so dpkg-buildpackage has a heuristic that says "if the debian revision is greater than -1 then the target should already have it" and so omits the .orig.tar.gz
[21:53] <james_w> barry: if you just have Debian then that works great
[21:53] <barry> james_w: ;}
[21:53] <james_w> barry: but once you introduce Ubuntu you hit the case you just have, and it falls down
[21:54] <james_w> barry: so you have to tell dpkg-buildpackage that you want the .orig.tar.gz with -sa
[21:54] <barry> james_w: so: bzr bd -S -- -sa ?
[21:54] <james_w> barry: plus, as you are merging you should get it to include the Debian changes in the .changes, as they are new to Ubuntu.
[21:55] <james_w> barry: to do that, find the last version number in Ubuntu, and pass -v<version> (no space)
[21:55] <james_w> barry: and yes, that is how you would pass it
[21:55] <barry> james_w: i understand all the above except the part about "Debian changes in the .changes"
[21:55] <james_w> barry: ...at least it would be if I didn't anticipate your every need and upload just the other day a version of bzr-builddeb that can automate this
[21:55] <james_w> barry: so it is now spelt "bzr bd -S --package-merge"
[21:56] <james_w> barry: have a look at the source.changes you just uploaded that got rejected
[21:56] <james_w> barry: in the middle there is an extract from the changelog with your "  * Merge from Debian squeeze [etc.]" lines
[21:57] <james_w> barry: now build again with the --package-merge and look, and you will see your lines, but in addition below that lines that come from the Debian uploads that happened since we last merged.
[21:57] <james_w> barry: these extra lines will get mailed around as the changes in this package, which is more correct than the changes in just your merge changelog entry
[21:57] <james_w> make sense?
[21:57] <tumbleweed> barry: the current version of python-numpy in ubuntu has no ubuntu delta. Can we not just sync?
[21:58] <barry> james_w: it does, yes
[21:58] <james_w> excellent
[21:58] <barry> tumbleweed: yes, i think so.  there's an open bug on that, but doko hasn't approved it yet.  or let's say there's still some discussion about it
[21:59] <tumbleweed> oh right, yes I saw that bug
[21:59] <barry> james_w: one more question: after the debian merge, do i still need to bump the version number, i.e. dch -i?
[22:00] <james_w> barry: yes, if I understand you correctly.
[22:00] <tumbleweed> barry: yes
[22:00] <james_w> you mean "after bzr merge-package lp:debian/..." run "dch -i" ?
[22:00] <barry> james_w: yep
[22:00] <james_w> then yes you do
[22:00] <barry> it makes sense, i just needed some confirmation ;)
[22:00] <james_w> we need a changelog entry different from the Debian ones
[22:00] <james_w> barry: feel free to file a bug requesting an option to merge-package to do that for you
[22:01] <barry> james_w: thanks again for the great info.  i'll make sure to update https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
[22:01] <james_w> thanks
[22:01] <barry> james_w: will do, thanks again
[22:01] <james_w> the "--package-merge" is new in maverick, so you might want to note that
[22:02] <ScottK> jcastro: Since you've marked finding a place for DDs to ask for sync requests as done in the spec ....  What's the place?
[22:02] <jcastro> ScottK: -archive, I updated the sync request wiki page too
[22:02] <barry> james_w: nod
[22:03] <jcastro> ScottK: with "If you do not have a Launchpad account you can mail the ubuntu archive mailing list."
[22:03] <jcastro> with a link to the list
[22:03] <ScottK> jcastro: My read of the discussion was some of the archive admins pushed back on that.
[22:03] <ScottK> slangasek: ^^^
[22:03] <jcastro> my read on that was "oh I guess we need to do a better job of telling people that"
[22:03] <jcastro> ScottK: but whatever you guys decide is fine with me
[22:03] <ScottK> jcastro: Unless someone is going to actively deal with sync requests sent to that list, it's going to be a point of frustration.
[22:04] <nigelb> ScottK: Or a script.
[22:04] <ScottK> IIRC my question about who would do that got no response.
[22:04] <ScottK> nigelb: Someone would still have to run such a script.
[22:04] <ScottK> (not to mention write it)
[22:05] <james_w> do people realise that -archive is moderated, with non-subscribers being held for moderation?
[22:05] <james_w> and that no-one would want to subscribe to the list?
[22:05] <nigelb> ok, that's double pain.
[22:05] <nigelb> somone has to moderate *and* process the queue
[22:05] <ScottK> Since one can't assume all DD's keep track of where we are in freezes, they can't just be cargo culted, they have to be reviewed by someone who knows what they are doing.
[22:06] <ScottK> jcastro: I don't think this one is solved.
[22:06] <jcastro> yargh.
[22:07] <jcastro> the lp sync requests end up going in there
[22:07] <jcastro> why is the list moderated?
[22:08] <jcastro> do the archive admins have regular meetings? It would be nice to just solve this
[22:08] <ScottK> Nope.
[22:08] <ScottK> List is moderated like pretty much all Ubuntu lists are moderated.
[22:09] <nigelb> with only LP being white listed I think
[22:09] <slangasek> jcastro: well, my position is that ubuntu-archive is not a list that I want to be subscribed to and would only subscribe to if it was made a policy for archive admins, which it has not yet :)
[22:09] <ScottK> jcastro: I'd suggest any solution that ends up requiring more archive admin work to process these into syncs isn't the right answer.  Where they should land is in something like a sponsor queue.
[22:09] <ScottK> slangasek: +1
[22:11] <jcastro> would it be ok if I just say "hey, you guys are the archive admins, you figure it out, but please do it by X date"
[22:11] <ScottK> jcastro: My response would be "They should file bugs and have them reviewed by sponsors.  Done."
[22:11] <jcastro> right, but this is for people who don't have LP accounts
[22:12] <ScottK> Right, I don't think that's the archive administrator's problem to solve.
[22:12] <jcastro> from what lucas told me there were quite a few people he talked to in Debian that would like to be able to just mail a list
[22:12] <ScottK> Yes.  I understand and agree with the goal.  I just don't think ubuntu-archive is the right list and I don't think the archive admins can/should be the ones to solve it.
[22:13] <jcastro> ok, I think what I'll do is when I return from vacation if the matter isn't solved I'll POSTPONE the item and we can bring it up during the debian session at UDS.
[22:13] <bcurtiswx> hey all, i've fixed a FTBFS with folks.  I've tested the fixes in pbuilder and it works.  What to do next to get the fixes into main?
[22:14] <bcurtiswx> empathy's waiting on LP for this fix
[22:15] <ScottK> jcastro: I don't think it needs to be in the Debian/Ubuntu session.  Ubuntu just needs to solve it.  Have a nice vacation.
[22:16] <jcastro> I'll just shove you all in a room and lock the door until you solve it, heh
[22:17] <sistpoty> bcurtiswx: create a debdiff, add it to a bug (file one if it's not there yet) and subscribe ubuntu-sponsors
[22:18] <bcurtiswx> sistpoty: OK, brb
[22:29] <dupondje> https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/614039 => can somebody set priority on this ? seems like ALOT of people are having this issue
[22:33] <chrisccoulson> dupondje, somebody needs to ask for a proper backtrace (whilst running g-p-m with the --sync option). without that, it's prtty much useless
[22:33] <chrisccoulson> and preferably run it through xtrace too
[22:36] <dupondje> chrisccoulson: what you need exactly ? I have this issue, so can simulate this :)
[22:37] <chrisccoulson> dupondje, please get a backtrace from g-p-m when running it with --sync :)
[22:37] <dupondje> it says it made a coredump, but can't find it :s
[22:38] <chrisccoulson> i suspect it hasn't made a coredump, because we set the core size to zero ;)
[22:40] <dupondje> http://pastebin.ubuntu.com/481151/
[22:40] <dupondje> ok ? :)
[22:41] <chrisccoulson> dupondje, you don't have any debug symbols
[22:41] <chrisccoulson> 1 second, just trying to work out which ones you need
[22:42] <dupondje> libglib2.0-0-dbg ?
[22:42] <chrisccoulson> gnome-power-manager-dbgsym libglib2.0-0-dbg libx11-6-dbg
[22:42] <chrisccoulson> and
[22:42] <dupondje> gnome-power-manager-dbgsym doesn't exist ... :)
[22:43] <chrisccoulson> dupondje, https://wiki.ubuntu.com/DebuggingProgramCrash ;)
[22:43] <chrisccoulson> you also need libxrandr2-dbg (or dbgsym)
[22:45] <dupondje> its comming :D
[22:45] <bcurtiswx> sistpoty: https://bugs.edge.launchpad.net/ubuntu/+source/folks/+bug/621423 done :D
[22:45] <dupondje> http://pastebin.ubuntu.com/481154/
[22:46] <chrisccoulson> dupondje, which driver is this?
[22:46] <dupondje> nouveau
[22:48] <sistpoty> bcurtiswx: looks good from a glimpse, thanks!
[22:48] <bcurtiswx> sistpoty: np, ty :)
[22:51] <dupondje> chrisccoulson: http://pastebin.ubuntu.com/481159/
[22:51] <dupondje> installed gdk2 dbg also :)
[22:51] <dupondje> some additional info now
[23:01] <chrisccoulson> dupondje, if you run gnome-power-manager --verbose, do you see "no XRANDR extension"
[23:01] <chrisccoulson> ?
[23:02] <dupondje> http://paste.ubuntu.com/481166/
[23:02] <dupondje> seems not
[23:02] <dupondje> oh yea
[23:02] <dupondje> TI:00:01:53	TH:0x22950a0	FI:gpm-brightness.c	FN:gpm_brightness_init,928
[23:02] <dupondje>  - no XRANDR extension
[23:07] <chrisccoulson> ok, i can see whats going on
[23:07] <dupondje> great :)
[23:09] <chrisccoulson> not sure if i'll fix it tonight though, i'm in the middle of something else (and it's getting late here)
[23:09] <dupondje> well as long it gets fixed :)
[23:10] <dupondje> I hang around tomorrow, so if you need some more tests/info :)
[23:19] <dupondje> going to sleep now
[23:20] <dupondje> chrisccoulson: thanks for helping :) good to see it fixed in the near future :)