[00:11] <bryceh> skaet, you around?
[00:11] <skaet> bryceh, yup
[00:11]  * skaet is going to be around all night documenting bugs... :(
[00:11] <bryceh> skaet, we have a bug preventing people from filing compiz bugs with apport, that I have a fix for
[00:12] <skaet> sweet
[00:12] <bryceh> skaet, I wanted to doublecheck with you for uploading the fix before doing so
[00:12] <bryceh> skaet, it involves an upload of the 'xorg' package, which doesn't require much time from the buildds
[00:13] <bryceh> but since we're deep in freeze just wanted to be sure it's allowable?
[00:13] <skaet> thanks for asking.
[00:13] <bryceh> the bug is https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/710630
[00:14] <skaet> we're likely to go with the images we have, but if we do end up with a spin, this would be a good one to include.
[00:14] <skaet> buildd's aren't too busy.
[00:14] <skaet> bryceh,  go ahead.
[00:15] <skaet> (and thank you! - this is a good one to get fixed)
[00:15] <bryceh> skaet, alright thanks
[00:15] <bryceh> skaet, bdmurray gets the kudos for figuring out the fix :-)
[00:15] <skaet> thanks bdmurray.  :)
[00:16] <bdmurray> no problem
[00:18] <chrisccoulson> skaet, if you're documenting bugs, firefox isn't translated at all in alpha 2 ;)
[00:18] <chrisccoulson> not sure if that's worth documenting
[00:42] <barry> @pilot out
[01:06] <hallyn> well, my last update said it couldn't install xserver-xorg-core bc it'd break applications.  that does NOT bode well for chances of my being online in the morning :)
[01:16] <RAOF> hallyn:  Got any more details?  That *should* now all be fixed (barring nvidia/fglrx)
[01:25] <hallyn> RAOF: no, i haven't dared reboot or log out yet, but /var/log/apt/term.log says
[01:25] <hallyn>  xserver-xorg-core breaks xserver-xorg-video-8
[01:25] <barry> micahg, kklimonda i just resent my messages.  i'm eod, but i'll check the scrollback.  let me know if you do or don't get the messages.
[01:25] <hallyn> followed by
[01:25] <hallyn>  installing xserver-xorg-core would break existing software
[01:26] <micahg> barry: cool, thanks
[01:51] <skaet> chrisccoulson, bug number?  (yeah, its worth documenting)
[02:02] <kklimonda> micahg: barry: hmm, I didn't get it, maybe it's in moderation?
[02:20] <RAOF> hallyn: Do you have the nvidia binary driver installed, or some obscure driver?
[02:35] <barry> kklimonda: i'm seeing some odd errors in my mail.log.  ubuntu.com is 550'ing the message for some reason, though clearly other messages of mine are getting through.  will investigate tomorrow
[02:38] <lifeless> barry: stop spamming :P
[02:39] <barry> lifeless: that's like telling aussies not to say "krikee" :)
[02:54] <hallyn> RAOF: i mean to have the intel i915 driver
[02:54] <hallyn> RAOF: but i see nouveau installed
[02:55] <hallyn> xserver-xorg-video-nouveau
[02:55] <hallyn> haha, i see, they're all installed
[03:00] <hallyn> all right, i'd better risk the reboot now so i know what to expect tomorrow
[04:24] <bogner> I'm wondering about how to package 32 bit versions of libs. Is there documentation about how to make lib32* packages somewhere?
[04:26] <RAOF> bogner: Not that I know of, but it's not terribly difficult.  You _may_ not want to bother; proper dpkg multiarch support is (apparently) being actively worked upon.
[04:29] <bogner> RAOF: well, I need a 32 bit libvlc for something I'm working on, and it's easier to deal with things if I package them up
[04:30] <RAOF> If you need something quick and dirty I'd just cargo-cult from one of the existing lib32* packages; I've touched lib32asound in the past, and it wasn't terrible.
[04:34] <bogner> Yeah, based on lib32ncurses and lib32asound it doesn't look like it's too hard to deal with
[04:34] <RAOF> Basically, throw up a new bulid dir, passing -m32, and you're golden.
[06:24] <hyperair> hmm, what's this "soft freeze"?
[06:25] <kklimonda> hyperair: it's a freeze that is not enforced by LP
[06:25] <hyperair> ah, i see.
[06:25] <bryceh> hyperair, don't upload stuff unless it's a critical bug fix\
[06:25] <hyperair> kklimonda, bryceh: thanks
[06:26] <hyperair> i suppose archive will be unfrozen after alpha 2
[06:26] <kklimonda> yeah
[06:27] <micahg> hyperair: you can upload stuff if it's not in any of the images
[06:28] <micahg> or any build-deps of the images
[07:49] <DktrKranz> kklimonda: packages are processed at a lower pace during freeze, expect more activity when squeeze is released (i.e. after this weekend). And no, you can't download packages from NEW.
[07:55] <pitti> Good morning
[08:01] <didrocks> good morning
[08:31] <dholbach> good morning
[08:40] <dholbach> janimo, thanks for the patch pilot post!
[08:44] <dholbach> diwic, is https://wiki.ubuntu.com/DistributedDevelopment/Documentation also lacking information about bd-do?
[08:44] <dholbach> I think that'd be the best place where we can put it
[08:44] <dholbach> and it should go into the new packaging guide project that was just announced
[08:45] <diwic> dholbach, *reading*
[08:46] <diwic> dholbach, so that might be it, if there was a link from the packaging guide I just didn't make the connection from "Distributed Development" to bzr build-deb
[08:46] <tumbleweed> not sure how useful (does it even work?) bd-do is for non-merge-mode branches
[08:47] <dholbach> diwic, I added a comment to https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/702002
[08:48] <persia> bzr bd-do is the thing that pulls a remote tarball based on watch files or get-orig-source, right?
[08:48] <diwic> persia, and executes a command/shell upon the result
[08:48] <tumbleweed> persia: it's like svn-do, puts you into a temporary directory with upstream source + debian dir
[08:49] <persia> Does it pull the upstream source that matches the source used for the packaging, or the latest upstream source?
[08:49] <tumbleweed> persia: used for packaging :)
[08:50] <tumbleweed> there's an open bug on that not being the policy-compliant way to use get-orig-source. We need to take it up with debian-policy
[08:51] <persia> How does it do that?  get-orig-source is semantically required to get latest upstream, and watch files typically get latest upstream (especially for upstreams that don't store old tarballs around)
[08:51] <persia> I actually agree with the current reading of debian-policy.
[08:51] <persia> Seems easier to grab the version-matched tarball from our mirror network, no?
[08:51] <tumbleweed> persia: well obviously it tries that first
[08:51] <persia> (plus we then happen to have a trusted artifact, rather than a constructed artifact)
[08:51] <tumbleweed> then get-orig-source, then uscan
[08:52] <dholbach> janimo, I just added another comment to the CodeReviews page - thanks for the feedback
[08:52] <persia> Ah, then that makes more sense (but wasn't obvious)
[08:52] <tumbleweed> a fair number of pcakgase (including my own) use get-orig-source like that, because its more useful than getting the latest upstream
[08:52] <persia> I'd prefer if there were two operations: one to get current source, and one to get new upstream, but that's a matter of preference.
[08:52] <janimo> dholbach, you're welcome, I'll cjheck the page
[08:52] <tumbleweed> persia: yeah, that's why it needs to be discussed in debian-policy...
[08:52] <diwic> dholbach, so https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem <- is this documentation for merge-mode branches or not?
[08:53] <persia> tumbleweed, please don't: it would be much prefeable to use another target (lots of folk seem to get get-current-source: )
[08:53] <janimo> dholbach, nice :)
[08:53] <persia> tumbleweed, It was, at length, and the semantics were changed from what you describe to what is currently in policy.
[08:53] <tumbleweed> persia: right, yes, the correct way out of it is probably a new target with these semantics
[08:54] <persia> tumbleweed, There's no policy against adding extra targets, and if enough people add them, it makes sense to add to policy :)
[08:54] <dholbach> diwic, what do you mean by "merge-mode" branches? to me it seems the way to deal with source package branches of packages that have a patch system on top of it
[08:55] <tumbleweed> persia: hah. in this case some coordination between svn, bzr, and any other VCS that needs this, would be great
[08:55] <persia> dholbach, I believe it's ones that don't use pristine-tar, and just have debian/
[08:55] <diwic> dholbach, well, I didn't know of that name either until yesterday, but that's when you have the debian/ in the bzr only, and the upstream source somewhere else
[08:56] <persia> tumbleweed, I tend to focus on the devscripts implementations first, and then expect foo-buildpackage to conform to those semantics.
[08:56] <tumbleweed> re modes: http://jameswestby.net/bzr/builddeb/user_manual/
[08:56] <dholbach> aha
[08:56] <dholbach> barry, james_w and jelmer probably know better about this - I'm afraid I haven't dealt with "merge-mode branches" a lot yet
[08:57] <diwic> tumbleweed, aha, yet another useful link, thanks
[08:59] <diwic> so maybe there is some documentation and I just didn't find it.
[09:00] <dholbach> that sounds like something we can fix :)
[09:02] <diwic> dholbach, maybe links to "Distributed Development" should say "Packaging with bazaar" instead, or both
[09:04] <dholbach> diwic, gotcha - I added all the links to the bug report I mentioned above
[09:04] <persia> diwic, The key to "Distributed Developement" is that it's more than just packaging with bzr: there's lots more components that are intended to make things scale better.  bzr is just a piece of it (although perhaps the most visible piece at the current stage)
[09:16] <dholbach> micahg, do you know what's going on with bug 709216? :)
[09:19] <lag> dholbach: Hey Daniel
[09:19] <dholbach> hi lag
[09:19] <lag> dholbach: Long time no see, how you been?
[09:19] <dholbach> good good - how 'bout you?
[09:19] <lag> Yeah not bad thanks
[09:19] <lag> Do you know which channel would be best for libgpod questions?
[09:20] <lag> Does anyone work on it @Canonical for instance?
[09:21] <dholbach> lag, I guess #ubuntu-desktop
[09:21] <dholbach> but I'm only guessing :)
[09:21] <lag> I'll try them
[14:33] <EtienneG_> kees, regarding the OO.org USN this morning, have there been reports of exploits in the wild?
[15:16] <kees> EtienneG_: no, nothing. heap exploits are virtually unheard of due to glibc's defenses against it, but because of how they work, it's hard to really claim that they're all safe. in practice, I've only seen 1 heap overflow attack in the wild in the last 8 years.
[15:48] <EtienneG_> kees, thanks for the info, and glad to hear that!  :)
[16:03] <jdstrand> kenvandine: hey-- it looks like you sponsored the folks upload. is that to fix something for alpha2 images?
[16:04] <micahg> jdstrand: archive was opened
[16:04] <jdstrand> oh, I see that now
[16:04] <kenvandine> jdstrand, no
[16:04] <kenvandine>  :)
[16:04] <jdstrand> micahg: thanks
[16:04] <jdstrand> kenvandine: yes, nm :)
[16:19] <marjo> ping apw
[17:10] <kirkland_> apw: howdy;  i'm getting a kernel panic coming out of suspend *every time*;  this is new for natty, within the last 2-3 days
[17:11] <apw> marjo, hi
[17:11] <apw> kirkland_, lovely ... get a bug filed please... whats the ooops line
[17:11] <apw> EIP specifically ?
[17:13] <kirkland_> apw: shall i shoot a picture of the screen when it occurs?
[17:13] <apw> kirkland_, definatly and add tyhat to the bug
[17:13] <apw> and subscribe me, and post me the number too :
[17:13] <apw> here :)
[17:14] <kirkland_> apw: submitting bug now
[17:14] <kirkland_> apw: will kill my machine again momentarily
[17:16] <kirkland_> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/712625
[17:16] <kirkland_> apw: brb, killing my machine now
[17:27] <kirkland_> apw: image uploading over crappy conference uplink...
[17:28] <kirkland_> apw: standby;
[17:28] <kirkland_> apw: done
[17:28] <kirkland_> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/712625/+attachment/1827461/+files/IMG_0867.JPG
[18:24] <bdmurray> @pilot in
[18:39] <soren> qlist
[18:39] <soren> whoops :)
[18:39] <jelmer> hey soren, bitlbee user ? :)
[18:48] <soren> jelmer: Busted :)
[18:49] <soren> jelmer: Funny. I was wondering if you'd notice :)
[18:58] <GunnarHj> cjwatson: Hi Colin,
[18:58] <GunnarHj> cjwatson: Considering your comments at https://launchpad.net/bugs/666565, it would be great if you could spare a minute or two to act on the comment I posted earlier today.
[19:04] <jjardon> tkamppeter, Hello I was reading about https://www.linuxfoundation.org/collaborate/workgroups/openprinting/plan-completion-common-printing-dialog and I wonder if there is a bug open in GTK+ bugzilla about this
[19:08] <slangasek> barry: ping
[19:11] <broder> cjwatson: ping? i have a quick question about the automagical ntp stuff if you're still around
[19:19] <ignarps> automagical ntp ?
[19:23] <broder> i'm mostly trying to figure out how our /etc/network/if-up.d/ntpdate script will interact with a network that has a captive portal
[19:27] <barry> slangasek: hi, sorry i was on a different desktop.  what's up?
[19:27] <slangasek> barry: hi, just wondering if you know what the status is of documentation for dh_python2
[19:27] <slangasek> I find "dh_python2 howto" doesn't work well as a google search term :/
[19:27] <barry> slangasek: probably fairly poor ;).  i am planning on spending time on dh_python2 perhaps next week; i'd like to improve the docs
[19:30] <slangasek> ok, cool
[19:30] <kklimonda> barry: did you found out what's wrong with your emai? :)
[19:30] <barry> kklimonda: i have not ;)  i'm going to investigate again later today
[19:30] <slangasek> I ran into this when reviewing some packages of meego components; the original packaging was using python-central, I wanted to suggest dh_python2 instead and couldn't find references
[19:30] <barry> slangasek: for simple packages, it's almost comical how simple it is
[19:30]  * barry looks for an example
[19:30] <slangasek> barry: right - I'm just left with the niggling doubt that I've overlooked something ;)
[19:31] <barry> slangasek: with a good setup.py, a 3 line d/rules is all you need, though you can add a few extra lines for tests or such (i need to fix dh for those)
[19:31] <barry> slangasek: http://bazaar.launchpad.net/~barry/flufl.i18n/i18n.deb/view/head:/debian/rules
[19:31] <barry> slangasek: all you really need are lines 1, 6 and 7
[19:32] <barry> slangasek: and even there, you don't strictly need --buildsystem python_distutils
[19:32] <barry> slangasek: so line 7 can be: "dh $@ --with python2" and you're done
[19:33] <barry> slangasek: (the --buildsystem python_distutils is needed if you have a Makefile though because dh isn't smart enough -- yet -- to recognize setup.py over Makefile)
[19:33] <slangasek> barry: hmm, --buildsystem won't work in this case, the python bindings are a subset of the upstream source which uses autotools.  Will dh_python2 do anything sensible in this case?
[19:34] <barry> slangasek: does "python setup.py install" DTRT?
[19:34] <barry> slangasek: say, in a virtualenv?
[19:34] <slangasek> ENOSETUP.PY
[19:35] <barry> slangasek: ah, then i don't actually know ;).  give it a try and let me know, and i'm happy to help
[19:39] <broder> dh_pysupport would basically go and hunt down any python modules installed anywhere. does dh_python2 not do the same?
[19:39] <barry> broder: i haven't tried it with !setup.py
[19:41] <slangasek> barry: tried it, get a package with /usr/share/pyshared/ContextKit/, /usr/lib/python2.7/dist-packages/ContextKit/, /usr/lib/python2.6/dist-packages/ContextKit/; a Python-Version: 2.6, 2.7 binary control field; a strange dependency on python (>= 2.7.1-0ubuntu2) (!?); and what look to be suitable pycompile invocations in maintainer scripts
[19:41] <slangasek> pycompile+pyclean
[19:42] <slangasek> why does dh_python2 guard its prerm check with 'if which pyclean'?
[19:43] <barry> dunno.  fwiw, i have a branch that adds tests, cleans things up, and adds comments to explain things.  kind of languishing due to lack of time.  however, if you find problems/issues with dh_python2, you can file bugs and subscribe/assign me
[19:44] <slangasek> ok, cheers :)
[19:44] <slangasek> so the minimum python version is annotated in /usr/share/python/debpython/depends.py as "minimum version required for pycompile/pyclean"
[19:44] <slangasek> which means the prerm check for pyclean should be dropped
[19:44] <slangasek> and it should be run unconditionally, because depends aren't supposed to get removed before their rev-deps
[19:45]  * slangasek will file bug
[19:47] <JFo> Anyone know who owns the Bug Watch Updater?
[19:47] <JFo> It seems to be going klepto on fixed bugs
[19:47] <bdmurray> JFo: Launchpad does
[19:48] <JFo> hmmm
[19:48] <JFo> ok, thanks bdmurray
[19:48] <slangasek> JFo: it should only be updating upstream tasks
[19:48] <slangasek> to match the state of the remote bug tracker
[19:48] <JFo> slangasek, bug 185025 is an example
[19:49] <slangasek> JFo: yes; if you follow the link to the upstream bug tracker, is this not the same state?
[19:49] <slangasek> maybe it just figured out how to import bug importances from the Linux tracker
[19:50] <slangasek> or decided how to map them
[19:50] <JFo> hmm
[19:50] <JFo> I think the odd thing is that it has been fixed for 3 years
[19:50] <JFo> and now the importance is being changed
[19:51] <slangasek> yeah - it's no longer unknown, so the updater must've gotten smarter :)
[19:51] <bdmurray> smarter is good
[19:52] <JFo> indeed :)
[20:10] <bryceh> no, a few weeks ago the updater went through and marked a ton of the freedesktop bugs as importance unknown from what it had been
[20:10] <JFo> hmmm
[20:10] <bryceh> my guess is they figured out and fixed whatever caused that, so the importances are getting re-added now
[20:11] <bryceh> you might check if the bugs in question were upstreamed to freedesktop, or to some other tracker
[20:11] <JFo> well, as long as it Does No Harm(tm) I can live with it :)
[20:11] <bryceh> my mail box has been slammed all morning with the updates
[20:11] <JFo> interesting
[20:11] <JFo> I'll keep looking at it
[20:11] <bryceh> yeah, been a simple matter of holding down the 'd' key longer than usual ;-)
[20:12] <JFo> lol
[20:12] <JFo> I am told it is because they fixed this bug https://bugs.launchpad.net/launchpad/+bug/707478
[20:12] <JFo> but that wouldn't explain the previous change
[20:12] <bryceh> bingo
[20:12] <JFo> or actually it would rather
[20:13] <bryceh> yeah comment #9
[20:13] <bryceh> JFo, thanks for digging that out, I was curious :-)
[20:13]  * JFo spoke before reading
[20:13] <JFo> so yeah, I think we may be good now
[20:13] <JFo> :)
[20:14] <JFo> no problem Tim was curious as well
[20:14] <JFo> :)
[20:17] <bdmurray> @pilot out
[20:55] <barry> kklimonda: sending an edited summary now, while watching my postfix logs
[20:56] <barry> kklimonda: 250 OK - should hit the list soon
[21:02] <micahg> barry: got it :)
[21:04] <barry> micahg: \o/
[21:06] <lamont> there will be a brief, rolling blackout in the land of ppa builders.  just fyi
[21:29] <ari-tczew> ogra: archive open, could you again have a look on merges?
[21:39] <ogra> ari-tczew, tomorrow, its nearly 11pm here
[21:39] <ogra> i didnt forget about you ;)
[21:42] <ari-tczew> ogra: okok
[22:01] <kirkland> apw: i backed down to the 2.6.37-11-generic kernel and i can suspend/resume again
[22:01] <kirkland> apw: -12 is b0rked
[22:40] <ari-tczew> barry: any news on pymca?
[22:42] <barry> ari-tczew: yep. https://bugs.launchpad.net/ubuntu/+source/pymca/+bug/712136
[22:42] <barry> see comment #6
[22:43] <ari-tczew> barry: many thanks!
[22:44] <barry> ari-tczew: sure thing! how about giving me a nice endorsement here: https://wiki.ubuntu.com/BarryWarsaw/MyApplication
[22:44] <barry> :)
[22:48] <ari-tczew> barry: I'd like to more sponsor for you to give strong endorsement.
[22:49] <barry> ari-tczew: you'll get sick of me prompting you about it eventually :)
[22:53] <bj0> 4
[22:55] <ari-tczew> barry: ATM I could say only that I've sponsored for you vala transition where were some issues and since these sponsors I have nothing else sponsored and I can't confirm that you don't make the same troubles.
[23:21] <poolie> can anyone comment on https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/712812
[23:35] <poolie> ah, basically just the same as bug 443404
[23:37] <hallyn> silly question - for natty cycle, can i request merges without a lp bug, or is an lp bug always required?
[23:37] <hallyn> well, i guess i'll need a lp bug anyway for sru