[01:45] <errordeveloper> hi
[01:46] <errordeveloper> i'm getting a problem with ath9k interface
[01:46] <errordeveloper> just update all packages
[01:46] <errordeveloper> and installed 2.6.38-7
[01:46] <errordeveloper> still bloody hangs
[01:47] <errordeveloper> also I changed from NM to wicd
[01:47] <errordeveloper> and it persisted
[01:47] <errordeveloper> (that was the first step I did)
[01:47] <errordeveloper> any ideas .. ?
[01:47] <errordeveloper> may be it's not ath9k driver ..
[01:48] <errordeveloper> i.e. could be something else, hm ..
[01:48] <errordeveloper> well, it sort of hangs quite badly
[01:48] <errordeveloper> and then panics
[01:51] <cnd> ScottK, ok, will do
[01:53] <ScottK> cnd: Keep in mind anything now is for oneric at the earliest.
[01:54] <cnd> ScottK, hmmm... ok
[01:54] <ScottK> errordeveloper: If you are running Natty, you want #ubuntu+1 for help, otherwise #ubuntu.
[01:54] <ScottK> cnd: We're well past feature freeze.
[01:54] <cnd> ScottK: we've been working through FFe's
[01:55] <cnd> they're to highlight some multitouch work
[01:55] <ScottK> You can always ask.
[01:55] <cnd> yeah
[01:55] <cnd> we've got FFe's open for the games
[01:55] <errordeveloper> ScottK: well, it says devel branch on the vt login prompt
[01:55] <cnd> one of them has been approved
[01:55] <cnd> the others are still waiting
[01:55] <ScottK> Frankly I think the touch people should have planned their work better and got this stuff done on time.
[01:55] <ScottK> errordeveloper: #ubuntu+1 then.
[01:55] <errordeveloper> ScottK: tbh, I am having big issue with #ubuntu channel, they just drive me crazy
[01:56] <errordeveloper> ok, shall check +1
[01:56] <errordeveloper> :)
[01:56] <ScottK> errordeveloper: That doesn't make this a support channel.
[01:56] <errordeveloper> ScottK: that wasn't my intention
[01:56] <ScottK> OK
[01:57] <errordeveloper> I wanted to sort of check if anyone here know of ath9k issue or anything related
[01:57] <cnd> ScottK, I understand the sentiment, though I think if you had a peek behind the curtain you might understand why things are the way they are
[01:57] <ScottK> cnd: Then they should have planned less.
[01:57] <errordeveloper> there plenty of commits on linux-wireless
[01:58] <ScottK> We have feature freeze for a reason and I don't think landing large chunks of work afterwards is a great idea.
[01:58] <errordeveloper> oh, by the this devel branch make like ubuntu, ..
[01:58] <errordeveloper> well, I hasn't been a big fun tbh
[01:59] <cnd> ScottK, there are a few outliers
[01:59] <cnd> but by and large, our large code was all landed before FF
[01:59] <errordeveloper> and now seeing where you guys heading, (dropping off gnome) etc
[01:59] <cnd> these are just some games that the community has developed, for example
[01:59] <ScottK> The stuff that didn't seems to be a rather large fraction of the FFe's we're getting, but I could be wrong.  It's not like I'm counting.
[02:00] <ScottK> errordeveloper: Desktop specific development work for Unity would be in #ubuntu-desktop or #ayatana.
[02:02] <errordeveloper> I only said that I like, and that had been a complement to all of you guys  :)
[02:02] <cnd> ScottK, I have no clue how many FFe's you guys get, nor what is considered "reasonable"
[02:02] <cnd> all we can go by is that a wiki page says there's a process
[02:02] <cnd> and we've tried to follow the process to the letter
[02:02] <cnd> if you feel we're unreasonable, then feel free to start denying
[02:03] <cnd> we are ok with that
[02:03] <ScottK> What I've been doing is not approving them.
[02:03] <ohsix> is the multitouch stuff the thing causing the enormous input latency and precision slowdown in natty? my touchpad is going nuts too, random right clicks (even from pressing the left click hard button)
[02:03] <ScottK> If other team members think they're OK, I don't feel a need to block it.
[02:03] <ohsix> multitouch or gestures
[02:03] <cnd> ohsix, we've not seen any bug reports about those issues
[02:03] <ohsix> ok
[02:04] <ohsix> thanks
[02:04] <cnd> there could be something there
[02:04] <ScottK> ohsix: This means you should file one.
[02:04] <cnd> yeah
[02:04] <ohsix> ya i get it ;]
[02:04] <ScottK> (not go away, it's not a problem)
[02:04] <ohsix> there was touchpad slowness during the mav beta too; but it was fixed, by what, i do not know
[02:04] <cnd> though I can't think of what would cause random right clicks
[02:05] <ohsix> well they're not random, but in place of left clicks, probably 30% of them
[02:05] <cnd> ohsix, the new natty kernel has multitouch enabled for some synaptics trackpads
[02:05] <cnd> and it could be causing some issues
[02:05] <ohsix> hm k
[02:05] <cnd> ohsix, do you have a dell mini?
[02:06] <ohsix> i know mine doesn't have any features for multitouch, from messing with it ages ago; i'll have to look into that
[02:06] <cnd> ohsix, then there's near 0% chance it has anything to do with multitouch/gestures
[02:06] <ohsix> nope, compaq cq60, the netbook i do have doesn't have any input problems with respect to the touchpad, neither speed or wrong button events
[02:06] <cnd> (can't be sure it's 0% chance though :)
[02:08] <ohsix> wait a minute  ...
[02:08] <ohsix> if i tap with 2 fingers it reliably delivers a right click
[02:08] <ohsix> and occasionally does it with one fat finger
[02:09] <ohsix> well that explains that
[02:09] <ohsix> first place i looked when i was trying to change the sensitivity or other settings that might be new, was the mouse applet; but it still has the options it's had for ages in the touchpad page
[02:11] <ohsix> all this fancy stuff is great, but i'd like my touchpad disable button to work again some day :D
[02:12] <ohsix> would the component for reporting all these things basically be the kernel?
[02:14] <ohsix> the misclicks seem to be rooted in the fact that my touchpad only reports one point, but there are sensitity/area settings to fake it, by assuming over a certain size is 2 fingers; if i enable 2 finger scrolling i can do the same thing with a fat finger
[02:15] <cnd> ohsix, there are knobs you can configure for these issues
[02:15] <ohsix> xinput list-props has some new things for the acceleration profiles too
[02:15] <cnd> they just aren't exposed by default
[02:15] <ohsix> that might be the slowness
[02:15] <cnd> yeah, xinput list-props
[02:15] <cnd> sometimes the defaults change for those knobs upstream too
[02:15] <cnd> one change in natty is the addition of kinetic scrolling
[02:16] <ohsix> as far as i know it could only ever be faked for this touchpad, the 2 finger stuff shouldn't even be displayed because it takes hairy manual setup, and can change with temperature and humidity D: (fingers get fatter, static settings to emulate stuff don't work reliably)
[02:17] <cnd> ohsix, you can turn off the two finger stuff in the mouse preferences
[02:17] <cnd> so it doesn't do two finger right click or scrolling
[02:17] <ohsix> that's just the thing, ic an disable 2 finger _scrolling_ but the 2 finger click is new, and isn't in there
[02:17] <cnd> oh, I think you're right
[02:18] <cnd> there's no option to enable/disable it in the prefs
[02:18] <ohsix> though i didn't know before a few minutes ago that the misclicks were actually 2 finger clicks in disguise :D (i use my touchpad rather sloppily on occasion)
[02:18] <cnd> heh
[02:18] <ohsix> using the thumb just to deliver a click when you don't need to move the mouse usually registers as 2 fingers
[02:20] <ohsix> theres sensitive area around the hard buttons on t his laptop too, so resting your fingers anywhere near it causes fatfinger right clicks as well
[02:21] <ohsix> one thing xinput doesn't display, or seem to know; is that theres a protocol level flag that says wether a device can do more than one point reliably, i confirmed a while ago that mine can only do one point; seems to me that a default that involves 2 finger anything could be picked properly if that info was there
[02:22] <cnd> ohsix, yeah, there's a protocol flag
[02:23] <cnd> but you wouldn't be getting any multifinger data if that flag wasn't set
[02:23] <cnd> that's my understanding at least
[02:24] <ohsix> it's not getting multifinger info persay; but the driver, last time i looked; would use a contact area number/heuristic to infer if 2 fingers were on the touchpad, to do 2 finger scrolling (as i said, 2 finger click is new)
[02:24] <ohsix> it does the same for palm detection to disable mouse movements for input over a certain area
[02:24] <cnd> ohsix, oh right, I remember that now
[02:24] <ohsix> it sends the click, not the 2 point events
[02:25] <cnd> yeah, so you don't have multifinger, but just a touch size
[02:25] <cnd> there's too many iterations of synaptics hardware :)
[02:25] <cnd> ohsix, I haven't been working on synaptics too much for non-multitouch hardware
[02:26] <cnd> but I haven't heard anyone else complain about how it works
[02:26] <cnd> I'm sure others have
[02:26] <cnd> but it's not reached a noticeable threshold for someone who works in that area of the code
[02:26] <ohsix> alright
[02:27] <ohsix> the reason i was looking back then in the first place, was to try 2 finger scrolling; which _sort of_ worked in a usable manner with the windows drivers, but i found out in the end that it was faked and if i wanted to use it i'd have to deal with it being tempermental
[02:27] <cnd> ohsix, I'm not sure how best to try to make that noticeable though :(
[02:27] <ohsix> and back then there was no checkbox in the mouse applet to just turn on 2 finger scrolling, had to do it with xinput set-prop
[02:27] <cnd> it's not like there's an easy way to say "if your trackpad sucks in just this way too, hit this button"
[02:28] <ohsix> yea :\
[02:29] <ohsix> if xinput knew how many fingers it could report (or does it? and it's implied it does if the prop isn't present indicating how many points?) it could show the ui for the stuff, though 2 finger click and 2 finger scroll still might be desirable if the touchpad or its driver can fake it :\
[02:29] <ohsix> picking 2 finger anything by default for one of the area heuristic touchpads is already annoying me though :P
[02:34] <ohsix> not sure how to file a straight up bug, need to file 2, one is the acceleration profile is wrong for this touchpad, and the other is the 2 finger clicking thing
[02:35] <cnd> ohsix, that sounds good
[02:36] <cnd> ohsix, you should search to see if anyone already has a similar bug report for either issue
[02:36] <ohsix> good idea
[02:37] <ohsix> apport should offer a choice for input problems with "linux" and the default stuff (the one that lets you pick X.org, after you do you can only pick display and stuff, should have input :D)
[02:39] <cnd> yeah
[02:42] <ScottK> slangasek: Does "/usr/bin/ld: cannot find crti.o: No such file or directory" seem like it might be multi-arch related?
[02:42] <ScottK> (libc6-dev is installed)
[02:42] <ohsix> yes
[02:43] <ohsix> crti is one of the startup stubs you need to link executables, not being able to find it cuz of the arch path is likely
[02:43] <ohsix> (though i haven't been following close, afaiu the paths are being changed to arch tuples and such a thing would be moved into one of them)
[02:47] <ohsix> cnd: should i file everything against "linux"? i wanna file one for my touchpad disable key, but i'm not sure what happens after X gets ahold of it and if it's more appropriate
[02:55] <cnd> ohsix, you can file against xserver-xorg-input-synaptics
[02:56] <cnd> it doesn't really belong against the linux package
[02:58] <ohsix> ok
[03:10] <cnd> @pilot out
[06:37] <pitti> Good morning
[06:38]  * slangasek waves
[07:20] <ohsix> where do i read this "Policy 10.2" that i keep seeing mentioned
[07:36] <didrocks> good morning
[07:37] <tkamppeter> pitti, hi
[07:41] <pitti> hey tkamppeter, good morning
[08:15] <tkamppeter> pitti, I have sent you an e-mail. It is an error_log from trying to use the CUPS web interface on a fresh standard installation of Natty. Looks like there is a PAM problem.
[08:16] <pitti> tkamppeter: the PAM libraries moved during the multiarch transition indeed
[08:17] <pitti> tkamppeter: from /lib/security to e. g. /lib/x86_64-linux-gnu/security/
[08:17] <pitti> tkamppeter: does cups assume that they are in /lib/security, for dlopen()ing them? if it only uses libpam, it shouldn't even notice
[08:17] <slangasek> cups probably needs to be restarted after the library is upgraded
[08:18] <slangasek> libpam0g has code to handle this, but I didn't think to bump the version check for the multiarch move
[08:18] <pitti> slangasek: that even happens after a reboot, though
[08:18] <slangasek> oh?
[08:19] <slangasek> is there a bug report about this?
[08:19] <pitti> I can reproduce it as well; http://localhost:631 doesn't accept my password
[08:19] <pitti> slangasek: not sure, I just saw tkamppeter's email about it a few minutes ago
[08:19] <pitti> I'm currently trying a no-change rebuild, just in case it checks pkg-config etc.
[08:20] <slangasek> no, cupsd is linked to libpam, and libpam does the lookups against the path
[08:21] <tkamppeter> pitti, for me tyhe web interface worked yesterday, I am currently updating my system ...
[08:21] <dholbach> good morning
[08:22] <pitti> I don't see a relevant dlopen() either
[08:23] <pitti> hey dholbach, guten Morgen
[08:23] <tkamppeter> pitti, can it be that the guy does not have libpam-modules installed?
[08:24] <dholbach> hey pitti
[08:24] <pitti> tkamppeter: unlikely; it's pretty much impossible to remove it without shredding your system
[08:24] <pitti> tkamppeter: also, I can reproduce it here as well, and I do have it
[08:25] <slangasek> it is possible to have upgraded libpam-modules without upgrading libpam0g
[08:25] <slangasek> I'll fix that
[08:25] <slangasek> and the restart issue
[08:25] <slangasek> but I don't know if either of those explains the bug in question
[08:25] <pitti> I didn't do a partial upgrade
[08:25] <pitti> both are version 1.1.2-2ubuntu4
[08:26] <tkamppeter> pitti, slangasek: The web interface still worked for me with 2ubuntu3.
[08:27] <slangasek> oh, /usr/lib/cups/cgi-bin/admin.cgi is a separate process and is not linked against libpam, hmm
[08:30] <pitti> tkamppeter: ok, it's not just a rebuild; I'll check out admin.cgi later on, when I'm done with my current task
[08:30] <pitti> shouldn't be hard to fix
[08:30] <tkamppeter> pitti, OK.
[08:35] <slangasek> blast, my glib2.0 changes didn't make it to the repo and have been clobbered :(
[08:36] <mr_pouit> yep, robert overwrites everything if it's not in bzr ;D (he did the same to me for some xscreensaver changes ;p)
[08:37] <slangasek> what's sad is that I did all my work in bzr, and just failed to push
[08:37] <lifeless> slangasek: then its on your local disk, yea?
[08:37] <slangasek> yes
[08:37] <slangasek> but it's still a waste of buildd time
[08:37] <slangasek> and it means I currently can't dist-upgrade my multiarch chroot :)
[08:56] <pitti> doko_: is there a command which outputs /usr/lib/python2.5/site-packages/ vs. /usr/lib/python2.6/dist-packages/, so that I do not have to do the version comparison and hardcoding these paths in debian/rules?
[08:56] <tkamppeter> pitti, slangasek, my system update has completed and the CUPS web interface still works for me.
[08:56] <pitti> tkamppeter: even after a reboot, or restarting cups?
[08:57] <slangasek> tkamppeter: ok.  interestingly, I can reproduce the failure here, but I don't understand it at all :)
[08:57] <tkamppeter> pitti, the update included CUPS, so it must have been restarted, but I will restart it again.
[08:57] <doko_> pitti: /usr/share/python{,3}/python.mk
[08:58] <tkamppeter> pitti, browser is Firefox 4.0 final ...
[08:58] <pitti> doko_: ah, thanks
[08:59] <tkamppeter> pitti, CUPS restarted, browser restarted, still works.
[08:59] <pitti> strange
[09:03] <pitti> doko: do I use py_sitename_sh with $(call) as well?
[09:08] <doko> pitti: afaics, yes
[09:14] <pitti> doko: cool, that works; thanks!
[09:25] <debfx> slangasek: oh dear, multiarch makes gcc-3.3 (libstdc++5) ftbfs
[09:25] <debfx> I guess it needs to be patched to search in the new lib dirs
[09:30] <cjwatson> ohsix: google for debian policy manual
[09:30] <ohsix> ah i thought it was a version, not a section in something
[09:33] <debfx> kirkland: are you going to upload newt? kubuntu-d-s fails to install when palette.original isn't registered
[09:34] <jamespage> Morning all
[09:35] <jamespage> Does dlopen() required a fully versioned library name or should it work with 'libpam.so' for example?
[09:37] <Chipzz> jamespage: the latter I think
[09:38] <Chipzz> I see no reason why it shouldn't work
[09:39] <jamespage> Chipzz: Hmmm - thats what I thought
[09:43] <jamespage> don't appear to be getting that behaviour (although it is a little hard to tell as sitting behind a java native access bridge)
[09:49] <cjwatson> 'man dlopen' documents what's supposed to work
[09:49] <cjwatson> (though the last point in its bullet list may need to be updated for multiarch)
[09:59] <jamespage> cjwatson: yeah - I've read that a few times; ldconfig -p contains libpam.so.0 but not libpam.so so I don't think it will work
[10:05] <cjwatson> $ ldconfig -p | grep libpam.so
[10:05] <cjwatson>         libpam.so.0 (libc6) => /lib/i386-linux-gnu/libpam.so.0
[10:05] <cjwatson>         libpam.so (libc6) => /usr/lib/libpam.so
[10:06] <cjwatson> dlopening libpam.so is only going to work if the -dev package is installed; for runtime use, it'll need to be 'libpam.so.0'
[10:14] <jamespage> cjwatson: thanks - could be challenging
[10:14] <jamespage> the Java library that I'm looking at tries to guess without a version number
[10:15] <jamespage> if it can't find it it then searchs a path which is currently not multi-arch compatible - hence it can't file the library.
[10:15] <jamespage> /file/find
[11:01] <mdz> didrocks, can you check into bug 723056 for me? I responded with the requested info but haven't heard back from the person you assigned
[11:06] <didrocks> mdz: looking at it
[11:06] <mdz> didrocks, thanks
[11:06] <didrocks> mdz: yeah, I asked sam to have a look. Will ping him again :)
[11:16] <pitti> ugh, what happened yesterday to grow desktop CDs by 50 MB..
[11:18] <pitti> +eglibc-source 2.13-0ubuntu8
[11:18] <ogra_> fun
[11:18] <pitti> +glibc-doc 2.13-0ubuntu8
[11:18] <ogra_> finally you can build your own libc right after install !
[11:24] <pitti> and we got -dbg, -pic, -prof, and -xen as well
[11:24] <pitti> and -amd64 on i386
[11:28]  * pitti files bug 740124 about it
[11:30] <abhinav-away> pitti, I have pushed a branch for bug-340970 but I did not propose it for merging as I was not able to make it run. the code for checking obsolete packages doesn't seem to be getting triggered. I think this feature wont be merged in this release anyways
[11:31] <abhinav-away> https://code.launchpad.net/~er-abhinav-upadhyay/apport/bug-340970
[11:34] <cjwatson> pitti: it may just be busted priorities
[11:34] <cjwatson> I'll check germinate output
[11:35] <cjwatson> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt certainly has a slew of stuff, suggesting incorrect NEW processing
[11:37] <Riddell> ev: hmm, usb-creator on suse doesn't want to work http://susepaste.org/48914863
[11:38] <pitti> cjwatson: ah, interesting
[11:38] <pitti> cjwatson: the required->optional list is exactly the list of extra packages
[11:38] <cjwatson> yes
[11:38] <cjwatson> fixed
[11:39] <pitti> cool, thanks
[11:42] <ev> Riddell: what happens if you manually spawn /usr/share/usb-creator/usb-creator-helper?
[11:42] <ev> as root
[11:42] <Riddell> ev: ImportError: No module named gobject
[11:42] <Riddell> hmm, possible dependency issue
[11:43] <ev> yeah, it needs gobject for the main loop
[11:46] <Riddell> ev: seems to be working now
[11:46] <ev> yay
[11:52] <bdrung> kenvandine: Breaks & Replaces should be used instead of Conflicts & Replaces if the conflicting package is versioned
[11:54] <bdrung> kenvandine: synaptic fail to find a proper upgrade path for gstreamer-plugins-{good,bad}
[11:57] <Riddell> ev: failed at the last task  http://paste.opensuse.org/79402602
[11:59] <ev> Riddell: make sure you have /usr/lib/syslinux/mbr.bin and /sbin/parted
[12:00] <ev> also, kill any running usb-creator-helper
[12:00] <ev> and run it manually in a shell with sudo /usr/share/usb-creator/usb-creator-helper, which should produce some sort of crash when you hit bootloader installation again
[12:07] <Riddell> ev: I have /usr/sbin/parted
[12:08] <ev> ah, usb-creator assumes it's in /sbin
[12:09] <Riddell> ev: and /usr/share/syslinux/mbr.bin
[12:12] <Riddell> ok trying with those modified in the source
[12:17] <Riddell> ev: well, some progress http://paste.opensuse.org/6716340
[12:18] <Riddell> ev: do you know what package supplies python lsb_release in ubuntu?
[12:18] <ev> lsb-release
[12:18] <Riddell> clever
[12:22] <ev> :)
[12:44] <oubiwann> cjwatson: congrats on multiarch!
[12:46] <cjwatson> oubiwann: congratulations should go to slangasek - he's been driving it
[12:46] <oubiwann> slangasek: congrats!!!
[12:46] <oubiwann> cjwatson: thanks :-) I'd assumed you were still on it, from last year!
[12:48] <cjwatson> only poking at the odd thing from the sidelines
[12:48] <cjwatson> and trying not to get in the way :-)
[12:52] <ogra> cjwatson, fyi, properly preseeding debian-installer/framebuffer=false finally works ... but i needed to actually implement preseeding in jasper through debconf-communicate (nice sideeffect)
[12:52] <ogra> sadly its close to unusable, the terminal is pretty screwed up
[12:53] <cdbs> dholbach: hi, could you re-add me to sponsors? ~bilalakhtar Thanks!
[12:53] <ogra> (i cant see what is selected)
[12:54] <cjwatson> ogra: as I said, it was more to narrow down where the problem was than a serious workaround suggestion
[12:54] <cjwatson> ogra: remind me of the bug number?
[12:54]  * ogra digs
[12:55] <ogra> bug 736111
[12:55] <ogra> cjwatson, well i have preseeding support in jasper now and we want the option to be user switchable on cmdline
[12:55] <ogra> so its not bad to have it that way
[12:56] <cjwatson> I suspect that it is not tty1 that's hardcoded, but /dev/fb0
[12:56] <ogra> bah, but i have no user
[12:56] <ogra> funnily the new hostname is set
[12:57]  * ogra wonders what failed there
[12:58] <OdyX> ScottK: we are next week now; what about FFE'ing the pyside stack ?
[12:59] <cjwatson> ogra: commented.  just to be clear, I don't expect the main installer team to be able to deal with this, other than by offering advice
[13:00] <ogra> cjwatson, well, i'm happy we have a wrokaround for the short term
[13:00] <ogra> i'll try to add the fronend stuff somehow
[13:00] <ScottK> OdyX: Did you file the bugs?
[13:00] <ogra> *front
[13:01] <OdyX> ScottK: Nope. Will do then.
[13:01] <cjwatson> ogra: well ... see my more recent comment :)
[13:02] <ScottK> OdyX: FFe is only needed if there are feature differences between what's in Debian and what we have now.  If not, a regular sync request will do.
[13:02] <ogra> cjwatson, will add some screenshots ... though first i want to find out why i have no user
[13:02] <OdyX> ScottK: thing is I don't know what the status of pyside under armel is (as it is BD-Uninstallable in Debian, waiting on qtwebkit4)
[13:03] <ogra> cjwatson, its also weird that while i have the caption "Installing packages..." the text inside the screen is "Ready when you are" and nothing more ... right afterwards it switches to debconf package removal
[13:03] <ScottK> OdyX: Not a problem.
[13:03] <OdyX> ScottK: would it be possible to get a natty armel build of PySide ?
[13:03] <evdvelde> hi all, how stable will btrfs be in 11.04?
[13:04] <ScottK> OdyX: we'd have to fix apiextractor to build first (symbols issues, IIRC).
[13:05] <OdyX> ScottK: I removed the symbols tracking now (see 0.10.0-4)
[13:05] <ScottK> OK.
[13:05] <OdyX> ScottK: status in Debian is: https://buildd.debian.org/status/package.php?p=qt4-x11%2Cqtwebkit%2Chorizontal-void-line%2Capiextractor%2Cgeneratorrunner%2Cshiboken%2Cpyside&suite=sid&compact=compact
[13:06] <ScottK> I'm familiar with the qtwebkit issues in Debian as my python-qt4 upload is waiting for them to be resovled as well.
[13:06] <cjwatson> ogra: sure, I expect that the dual-debconf-stack code in the installer doesn't deal perfectly with the fallback case to a plain debconf frontend
[13:06] <OdyX> yeah, right.
[13:06] <cjwatson> ogra: some fixing there is no doubt required
[13:06] <ogra> yup
[13:07] <ScottK> OdyX: Let's get apiextractor sync'ed then.  Can you file a sync request for that?
[13:07] <OdyX> filing
[13:08] <OdyX> ScottK: we need the whole chain anyway.
[13:08] <ScottK> OK.
[13:09] <OdyX> ScottK: four sync request mailed
[13:09] <Riddell> ev: what does usb-creator use the lsb-release python module for?  suse doesn't support it
[13:10] <Riddell> it's easy enough to patch but I don't want to break anything
[13:11] <ev> Riddell: to somewhat deal with the incompatible versions of syslinux problem
[13:12] <Riddell> mm, so I should just hard code it to the appropriate version
[13:13] <ev> see http://bugs.launchpad.net/bugs/608382 for the hairy details
[13:13] <ev> I was hoping to solve this with some MBR trickery a la isohybrid, but ran out of time in natty
[13:22] <kirkland> debfx: sure
[13:25] <ogra> cjwatson, bug 740183 for the missing user
[13:27] <kirkland> debfx: done!
[13:29] <psusi> cjwatson: I was trying to fix a bug where users can't install to a dmraid raid10.  I set up a qemu on an emulated 4 disk raid10.  The installer only presends /dev/mapper/foo-0 and -1 as targets, which are actually subsets of the main array, foo.  How does it decide what to show and what not to?
[13:30] <cjwatson> psusi: grab the partman-base source package and look in init.d/parted and parted_devices.c
[13:30] <psusi> hrm... ok
[13:39] <debfx> kirkland: thanks
[13:43] <kirkland> debfx: you got it;  thanks for the approach, that's much nicer
[14:05] <psusi> cjwatson: it looks like this asks parted for a list of all devices, then does some custom filtering on them... shouldn't either parted already avoid returning those devices, or the filtering be based on udev attributes rather than lower level poking about?
[14:09] <cjwatson> psusi: I don't think parted should change, but feel free to submit a branch to improve the filtering
[14:12] <psusi> cjwatson: hrm.. ok...
[14:13] <cjwatson> (if that's what the problem is)
[14:15] <mr_pouit> kirkland: http://lionel.lefolgoc.net/misc/ceci_est_une_aubergine.png (with xfce4-terminal and dialog, and sudo dpkg-reconfigure debconf)
[14:15] <mr_pouit> kirkland: I don't know if that's expected, but if I ever see an aubergine like that, I'll tell you ;-)
[14:16] <mr_pouit> apart from gnome-terminal, all other terms I tried showed this ugly color
[14:17] <ogra> wow, readline is a painful frontend on 80x24
[14:21] <ogra> cjwatson, hmm adding debug doesnt produce /var/log/installer/debug ... weird
[14:22] <cjwatson> ogra: oh, it may just make /var/log/oem-config.log more verbose
[14:22] <ogra> ah, yeah
[14:22] <ogra> i was checking syslog
[14:28] <ogra> cjwatson, k, attachede to the bug
[14:28] <ogra> *attached
[14:29] <ogra> ah
[14:29]  * ogra sees open /dev/tty: No such device or address
[14:29] <ogra> Failed to open terminal.debconf: whiptail output the above errors, giving up!
[14:29] <ogra> but i dont think that should affect the user creation
[14:30] <cjwatson> ogra: does it ask you for a username?
[14:30] <ogra> yes
[14:30] <cjwatson> ok, good
[14:30] <cjwatson> I saw that in the log and wanted to check
[14:30] <ogra> seems all correct from an UI POV
[14:31] <cjwatson> so the problem is just that we need to suppress the dual-debconf-stack stuff when using the debconf frontend
[14:31] <ogra> there seem to be readline realted errors at the very end but nothing around the time it should apply the debconf settings
[14:33] <cjwatson> actually, hmm, it might in fact be that plugininstall is never run for the debconf frontend
[14:33] <cjwatson> that's believable from the code
[14:33] <ogra> ouch
[14:34] <cjwatson> not desperately ouch, it should be easy to correct
[14:35] <ogra> weird is that every other bit seems to have run
[14:35] <ogra> i.e. as i said, i have a proper new hostname
[14:37] <bcurtiswx> slangasek,  http://paste.ubuntu.com/583809/ http://paste.ubuntu.com/583810/
[14:37] <bcurtiswx> left is errors, right is build deps.  Said you might know about recent issues with building
[14:38] <cjwatson> ogra: sure, anything that's not in install plugins should have worked
[14:38] <cjwatson> that's not weird
[14:39] <ogra> ah, i thought plugininstall applies everything
[14:40] <cjwatson> well, hostname actually *is* in plugininstall - but maybe I'm missing something, I don't think that angle is worth pursuing for the moment
[14:45] <sforshee> is there any key code that userspace interprets as "rotate display orientation" ?
[14:45] <ion> Heh. Apport adds to my bug reports: UpgradeStatus: Upgraded to natty on 2009-06-11 (649 days ago)
[14:45] <sforshee> I haven't found anything that looks appropriate
[14:52] <Riddell> siretart: what's the crack with libav?  ffmpeg forked?
[15:01] <Riddell> siretart: is there really not ment to be any sources in libav-extra?
[15:03] <bjf> pitti, dapper kernels look like they got fully tested so can go to -updates  (no rush on this)
[15:16] <siretart> Riddell: indeed, I'm replacing ffmpeg with libav, that's on purpose
[15:16] <siretart> Riddell: and yes, libav now builds a 'libav-source' package, on which libav-extra build depends
[15:16] <siretart> Riddell: this makes updates to the -extra packages easier
[15:17] <Riddell> siretart: so ffmpeg and ffmpeg-extra source should be removed?
[15:17] <siretart> Riddell: yes, they should
[15:18] <siretart> with libav going to main and libav-extra to multiverse
[15:18] <siretart> exactly like ffmpeg/ffmpeg-extra
[15:20] <Riddell> siretart: why is libav-extra in multiverse?
[15:20] <siretart> because of its build dependencies
[15:20] <Riddell> siretart: groovy, accepted
[15:21] <siretart> \o/ - thanks a lot
[15:24] <pitti> hey bjf
[15:24] <pitti> bjf: yup, will move them ASAP
[15:25] <bjf> pitty, thanks
[15:38] <tkamppeter> pitti, any news about PAM?
[15:38] <pitti> tkamppeter: just finished my previous task, catching up
[15:39] <Riddell> tjaalton: what are you expecting to happen with bug 735602 ?
[15:40] <ogra> oh, cool
[15:40] <tjaalton> Riddell: asked for feedback on debian-x@
[15:40] <tjaalton> upstream said to fix some bugs
[15:40]  * ogra smells working touchscreen calibration
[15:40] <Riddell> tjaalton: there doesn't seem to be any archive admin tasks so I'll unsubscribe ubuntu-archive
[15:40] <tjaalton> ogra: yeah, you should test it :)
[15:41] <tjaalton> Riddell: yeah
[15:41] <pitti> kees, jdstrand: publishing dapper kernel to -u/-s: linux-source-2.6.15 linux-backports-modules-2.6.15  linux-meta
[15:41] <ogra> tjaalton, if i find the time i will
[15:42] <ogra> i dont even know if my touchscreen works at all in natty, havent tested it since upgrading
[15:44] <micahg> smoser: you're still listed as a pilot BTW
[15:44] <micahg> @pilot in
[15:50]  * dholbach hugs micahg
[15:51]  * micahg hugs dholbach 
[15:52] <cyphermox> hi, could someone please do a no-change rebuild of udev, libgudev seems to have the old paths for the libgobject-2.0.la file, which would now be in a different path (since it was rebuilt for multiarch support)
[15:52] <micahg> cyphermox: whichever .la file is providing that needs to be emptied
[15:53] <bjf> pitti, there is now a linux-meta-ec2-2.6.32.315.16 in our ppa ready for -proposed
[15:53] <micahg> cyphermox: err, dependency_libs needs to be emptied
[15:53] <kees> pitti: 10-4, thanks
[15:54] <cyphermox> micahg, heh, whatever works. there's probably a reason why it's not empty though. I'd think udev was looked at early on when cleaning up la files / dependency_libs
[15:54] <pitti> kees: "10-4"? perhaps you mean 10-3.94? :-)
[15:54] <kees> pitti: sorry, using tencodes. :) http://en.wikipedia.org/wiki/Ten-code
[15:54] <Riddell> sladen: what are you expecting ubuntu-archive to do with bug 736502 ?
[15:55] <pitti> kees: clearly too 1337 for me ;)
[15:56] <kees> pitti: heh, nah, just a north americanism. 10-4 just means "affirmative"
[15:58] <pitti> kees: but it was sooo close to 10-3.96 :)
[15:58] <pitti> erm, 3.94
[15:59] <mdeslaur> slangasek: so, I'm a bit concerned that we'll be shipping a lot of stuff in natty that FTBFS because of multiarch, which will complicate things for security updates
[15:59] <mdeslaur> slangasek: is there a plan for a rebuild test and fixing all the FTBFS before release?
[16:00] <sladen> Riddell: meh.  ubuntu-archive -> ubuntu-release.  Can you unsub -release
[16:09] <ogra> cjwatson, ok, seems if i run minicom with TERM=vt100 the dislog frontend is ok (i get a cursor) just doesnt seem to work with xterm or linux
[16:09] <micahg> cyphermox: it's probably liborbit2-dev, so take a look at what I did for gtkglext or look at clean-la.mk in gnome-pkg-tools
[16:09] <pitti> bjf: there's also an l-b-m linux-backports-modules-2.6.32
[16:09] <pitti> bjf: and linux-backports-modules-2.6.35; shoudl they wait, or go as well?
[16:09] <ogra> *dialog
[16:10] <seb128> micahg, slangasek cleaned the orbit .la yesterday
[16:10] <seb128> micahg, what issue do you have?
[16:10] <bjf> pitti, looking
[16:10] <bjf> pitti, yes, those should go out as well, thanks for catching that
[16:11] <micahg> seb128: cyphermox was having an issue with something
[16:11] <cyphermox> seb128, nm ftbfs because libgudev still have /usr/lib/ as a path to the gobject .la file
[16:11] <seb128> that's the bug elmo filed that we were discussing on #ubuntu-desktop before
[16:11] <seb128> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/740224
[16:11] <pitti> bjf: /me pats http://people.canonical.com/~ubuntu-archive/pending-sru.html#kernelppa :)
[16:11] <micahg> oh, the problem is in udev then :_)
[16:12] <cyphermox> seb128, weird, no change here, jsut rebuilding and it's fine on amd64
[16:12]  * micahg thought the problem was udev building, not nm...
[16:12] <seb128> check with slangasek
[16:12] <cyphermox> micahg, sorry, I wasn't clear enough, my bad :)
[16:12] <seb128> the uploads he did yesterday clean the .la dependencies
[16:13] <pitti> bjf: ok, so all PPA packages should be in -proposed now
[16:14] <bjf> pitti, many thanks
[16:23] <cjwatson> seb128: can we make sure that we get bug 736159 released before beta?  it looks like it's affecting boot performance regression analysis
[16:23] <pitti> dpm: FYI, disabling natty langpack cron job and requesting full export for Friday, for beta-1
[16:24] <dpm> ok, thanks pitti
[16:34] <shadeslayer> dholbach: any particular reason i don't see you in #gsoc ? :D ( they're explaining why orgs didn't make it this year )
[16:35] <dholbach> shadeslayer, I just joined - I thought that it was obvious enough (417 orgs applying, 175 accepted, 25 more accepted than last time, 50 new ones)
[16:37] <shadeslayer> dholbach: well ...a explanation ( even if it's of 2 lines ) would be great :)
[16:37] <shadeslayer> so that we can improve next year ( if it happens again )
[16:38]  * dholbach nods
[16:39] <shadeslayer> dholbach: i think you need to be in #gsoc-rejects too
[16:40] <dholbach> thanks shadeslayer
[17:02] <slangasek> mdeslaur: FTBFS> yes, my understanding is that doko is planning to snapshot the archive soon for a rebuild test
[17:03] <mdeslaur> slangasek: ok, thanks
[17:03]  * doko is just waiting for slangasek to tell that multilib is in a somehow buildable state
[17:04] <slangasek> cyphermox: udev> blast, I missed that because my search was only against the .la files that were themselves in /usr/lib (!).  Did someone else get this for you, or does udev still need a rebuild?
[17:06] <elmo> slangasek: http://paste.ubuntu.com/583877/ is the patch I'm testing
[17:06] <elmo> fwiw
[17:06] <elmo> it mimics the gnome-pkg-tools clean-la.mk a little closer
[17:07] <elmo> although the $(wildcard ...) stuff didn't  work for me
[17:14] <slangasek> ScottK: hi, sorry, apparently I missed a comment from you earlier that I'm catching now in scrollback.  ld cannot find crti.o - that's definitely multiarch related, is this bug #737887 or are you running into this in another context?
[17:15] <slangasek> debfx: gcc-3.3 will need patched, yes
[17:16] <slangasek> jamespage: it's 100% wrong for java to dlopen('libpam.so') instead of 'libpam.so.0'.  If the ABI changes, all bets are off for what symbols you'll find - and the soname of libpam has never changed on Linux!
[17:17] <slangasek> kirkland: fyi, bug #740124 might have had to do with your new'ing of eglibc?
[17:20] <slangasek> bcurtiswx: telepathy-glib> thanks, definitely looks like a multiarch issue; though I thought I was very careful not to move the gir files around, so I'm going to have to dig to understand this
[17:21] <bcurtiswx> slangasek, OK, thx :)
[17:21] <slangasek> bcurtiswx: can you confirm the GLib typeinterface is still where it was before the upgrade?
[17:21] <bcurtiswx> slangasek, i performed a build on the current natty release, and it fails at that point as well
[17:22] <bcurtiswx> slangasek, so that would make me think it was once there
[17:23] <slangasek> doko: oh, yes, aside from a few bumps with glib right now, things are good - shall I ping you for the rebuild once this is settled?
[17:23] <seb128> bcurtiswx, dpkg -L gir1.2-glib-2.0 | grep GLib
[17:24] <slangasek> elmo: yes, the gratuitous $(wildcard) stuff evaluates the wildcard when the rule is invoked so doesn't pick up on any files created during the running of that rule.  BTW, I see that the second chunk is redundant, obviously find debian/tmp/usr/lib finds stuff in subdirs too
[17:24] <bcurtiswx> slangasek, bcurtis@weather:~$ dpkg -L gir1.2-glib-2.0 | grep GLib     /usr/lib/girepository-1.0/GLib-2.0.typelib
[17:25] <seb128> slangasek, ^ so yeah seems it's still at the same location
[17:25] <slangasek> bcurtiswx, seb128 yep, digging deeper
[17:25] <elmo> slangasek: ah, I see
[17:26] <elmo> so - hey, udd says natty is at 165-0ubuntu2 - what am I missing?
[17:26] <elmo> sorry, natty udev
[17:26] <slangasek> http://package-import.ubuntu.com/status/udev.html#2011-03-15%2021:02:25.173640 :(
[17:26] <seb128> elmo, the import job is likely not working for some reason
[17:27] <seb128> some reason being what slangasek just indicated ;-)
[17:27] <slangasek> elmo: there's a separate maintained bzr branch for udev at lp:~ubuntu-core-dev/ubuntu/natty/udev/ubuntu, it seems
[17:27] <slangasek> (which is the one I touched when multiarching libudev)
[17:27] <elmo> slangasek: ok
[17:27] <slangasek> pitti: how did cups shake out?
[17:28] <pitti> slangasek: still in my queue, sorry; had some other long tasks to work on before
[17:28] <pitti> but I'll get to it asap
[17:28] <slangasek> pitti: no hurry - just wondering if there's anything there I should be adding to my tasklist this morning :)
[17:29] <pitti> slangasek: not yet, I think; I might need to come back to you with some questions, but right now this looks both well-defined and reproducible
[17:29] <slangasek> ok
[17:40] <bambee> http://paste.ubuntu.com/583892/  <--- update-alternatives issue with console-setup
[17:41] <bambee> (I can be wrong)
[17:45] <elmo> hmm wow, I hope that MP didn't just spam ubuntu-core-dev
[17:45] <elmo> I have a horrible feeling it did
[17:45] <elmo> (this UDD thing is a little rough around the edges)
[17:47] <elmo> slangasek: anyway, there's a branch up on the bug, that fixes the unnecessary second loop thing.  I realise it's beyond trivial for you to fix yourself, I was mostly just experimenting with UDD, so feel free to ignore that
[17:47] <slangasek> it shouldn't spam core-dev, fwiw :)
[17:48] <slangasek> thanks, I'll have a look at the branch
[17:51] <slangasek> bcurtiswx, seb128: ok, very strange, I'm not able to reproduce this vapigen failure in an up-to-date chroot; it's not a clean chroot right now, but I wonder what could interfere
[17:52]  * slangasek tries again with a fresh build
[17:52] <bcurtiswx> slangasek, i will try again after another update if you can't reproduce, to see if it's fixed on my end
[17:54] <mdz> anyone else get a long string of these with the latest software-center update?
[17:54] <mdz> 2011-03-22 17:53:11,282 - softwarecenter.db.update - WARNING - The file: '/usr/share/app-install/desktop/kde4___kbruch.desktop' could not be read correctly. The application associated with this file will not be included in the software catalog. Please consider raising a bug report for this issue with the maintainer of that application
[17:54] <mdz> I seemed to get one for every .desktop file on my system
[17:57] <kirkland> slangasek: yes, that was me;  you asked me to set priority: required, did you not?
[17:57] <slangasek> kirkland: only for multiarch-support - apparently the priority: required got set for all the binary packages
[17:57] <kirkland> slangasek: arg, fail
[17:57] <slangasek> kirkland: so whatever button you pushed seems to have been the wrong one :-)
[17:58]  * kirkland should have just let you handle that part
[18:01] <bcurtiswx> gotta head out for a bit, bbl
[18:01] <doko> slangasek: please do, maybe away for a while tonight
[18:06] <cjwatson> kirkland: see bambee's query above?
[18:06] <kirkland> bambee: dpkg -l console-setup
[18:07] <bambee> kirkland: 1.57ubuntu17
[18:07] <kirkland> bambee: upgrade to 1.57ubuntu17 and that should solve your problem
[18:08] <cjwatson> blink
[18:08] <bambee> the problem occurs when I upgrade to this version :)
[18:08] <kirkland> bambee: hmm
[18:09] <kirkland> bambee: one second
[18:09] <bambee> ok
[18:09] <debfx> kirkland, bambee: I'll fix it shortly
[18:09] <kirkland> bambee: oh, it's newt
[18:10] <kirkland> bambee: dpkg -l newt
[18:10] <cyphermox> mdz, I did get one line like that today
[18:10] <mdz> cyphermox, I got a *lot*
[18:10] <kirkland> bambee: dpkg -l libnewt0.52
[18:10] <bambee> kirkland: not installed
[18:10] <bambee> ohh
[18:10] <kirkland> bambee: newt >= 0.52.11-2ubuntu7
[18:10] <debfx> kirkland: it's a copy'n'paste error: update-alternatives --set newt-palette /etc/console-setup/vtrgb.vga
[18:11] <kirkland> debfx: doh
[18:11] <bambee> kirkland:  0.52.11-2ubuntu7
[18:11] <kirkland> debfx: okay, you'll upload the fix to kubuntu?
[18:11] <kirkland> bambee: okay, debfx is on it
[18:11] <debfx> kirkland: yep
[18:11] <kirkland> bambee: thanks for the report
[18:11] <bambee> yw :)
[18:11] <kirkland> debfx: thanks for handling the kubuntu side
[18:14] <slangasek> bcurtiswx, seb128: ok, this telepathy-glib build failure is definitely unreproducible for me in a clean, up-to-date chroot.  if you can still reproduce it after update, let me know; for the moment I'm assuming it's resolved itself
[18:14] <cyphermox> mdz, I only see it for gnome-do here... but I also don't have kbruch installed (which was your example)
[18:14] <seb128> slangasek, ok, I didn't try myself yet since I'm not uptodate, will do in a bit and let you know, thanks for have a look to it
[18:16] <mdz> cyphermox,
[18:16] <mdz> perseus:[/var/log/apt] sudo grep -c '^2011-03-22.*softwarecenter.db.update - WARNING' term.log
[18:16] <mdz> 4780
[18:16] <cyphermox> yikes
[18:17] <cyphermox> seems I do have kbruch installed on one of my systems too, after all
[18:17] <mdz> I doubt I have *that* many buggy .desktop files :-)
[18:17] <cyphermox> yeah
[18:17] <cyphermox> maybe specific to the version of softwarecenter you were upgrading from?
[18:21] <mdz> cyphermox, I can reproduce by running update-software-center manually
[18:22] <mdz> it's a catch-all exception handler
[18:22] <slangasek> cjwatson, mvo: are there any changes in the default debconf stack in Ubuntu that would explain use of /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm on the desktop? (Bug #740334)
[18:24] <cjwatson> slangasek: aptdaemon uses passthrough
[18:26] <slangasek> cjwatson: ok, that explains that side of it at least, thanks.  Have you seen anything to suggest there are bugs on the debconf side of this?
[18:27]  * slangasek starts poking at pam-auth-update itself
[18:27] <slangasek> oh, except there are no p-a-u line numbers anywhere in that output
[18:27] <cjwatson> nothing springs to mind; that looks like something chatting on the debconf pipe when it shouldn't be ...
[18:28] <slangasek> hmm
[18:28] <cjwatson> it's hard to tell for sure.  I don't suppose it's possible to rerun with DEBCONF_DEBUG=developer?
[18:28] <slangasek> I'll ask the submitter for that, thanks
[18:28] <cjwatson> may be tricky if it's going through some pile of layers
[18:28] <cjwatson> I guess find out what package manager they're using, in the first instance
[18:28] <mdz> cyphermox, bug 740372
[18:29] <slangasek> elmo: udev uploaded, thanks!
[18:32] <slangasek> cjwatson: fwiw, none of the code in p-a-u has changed this cycle, but the latest upload bumps the compat version number to force service restarting for the module path change - so this is the first time this cycle pam is asking debconf questions, and it seems to have triggered 3 bug reports so far
[18:33] <cjwatson> slangasek: yeah, I think the problem is much higher up the stack than debconf though
[18:34] <slangasek> sure
[18:34] <cjwatson> that slew of debconf errors is just debconf's ugly way of saying "help, I was expecting a reply to a command and the frontend went away"
[18:34] <slangasek> ah :)
[18:34] <pitti> directhex, hyperair, Laney: https://launchpad.net/ubuntu/+spec/packageselection-desktop-n-application-selection has an item "[ubuntu-cli-mono-dev] Clean up deps on appindicator extensions so that we use the pure sound menu for 11.04" -- do you know what's going on with that? TBH I don't understand it at all
[18:34] <pitti> seb128, kenvandine: CC: ^
[18:34] <cjwatson> or actually, in this case, "the thing on the other side of passthrough went away"
[18:36] <directhex> pitti: i guess it's asking that we drop building support for appindicator, to remove that dependency, leaving only the mpris stuff?
[18:36] <directhex> pitti: this is hyperair's domain
[18:36] <pitti> directhex: ah, thanks
[18:37] <directhex> that's how i understand it anyway
[18:37] <directhex> i could be wildly incorrect
[18:37] <pitti> hyperair: that is marked for beta -- do you think that's still happening, or should we rather postpone this? (which might be safer at this point)
[18:38] <pitti> directhex: that's what kenvandine seemed to remember as well, anyway, so I guess that's what it means
[18:38] <directhex> pitti: seems like another conditional --disable, which is no big deal to implement, but it's part of hyperair's workflow and i won't stomp on it
[18:43] <EtienneG> hello everyone.  Per https://bugs.launchpad.net/ubuntu/+source/udev/+bug/659258, the Infiniband udev rules have been dropped from udev-152 (and hence from Ubuntu post-lucid).  Perhaps this was intentional, I am not sure, the upstream changelog is silent on the subject.  Anybody knows what happened there?
[18:44] <directhex> i'm curious about who would be using IB on ubuntu
[18:44] <EtienneG> directhex, well, I know at least one place that does
[18:44] <EtienneG> although, sadly, I cannot share whom and for what :(
[18:45] <Laney> i thought appind was a part of bce?
[18:45] <micahg> slangasek: chromium's dev channel failed to build with the newer libgcrypt build: http://launchpadlibrarian.net/66991055/buildlog_ubuntu-natty-amd64.chromium-browser_11.0.696.16~r78799-0ubuntu1~ucd~dev1_FAILEDTOBUILD.txt.gz, the daily channel was built with 1.4.6-4 and it worked
[18:46] <directhex> Laney: is it? http://bit.ly/bb8RWS
[18:46] <Laney> dunno, thought so. can't surf - on phone
[18:46] <Laney> maybe it got moved to mainline
[18:47] <slangasek> micahg: looking, but I don't think anything in the multiarch patch should have caused a change in the fPIC option used to build gcrypt; is this reproducible if you rebuild gcrypt without multiarch?
[18:50] <micahg> slangasek: I don't think so, the other builds with gcrypt w/out multiarch worked
[18:50] <slangasek> micahg: where do you have another copy of gcrypt that's built with the current toolchain but without multiarch?
[18:51] <micahg> slangasek: this build of a slightly newer version of chromium with the 1.4.6-4 (pre-multiarch version)  https://launchpad.net/~chromium-daily/+archive/ppa/+buildjob/2335823/+files/buildlog_ubuntu-natty-amd64.chromium-browser_12.0.711.0%7Esvn20110322r78963-0ubuntu1%7Eucd1_BUILDING.txt.gz
[18:52] <slangasek> 1.4.6-4 was not built with the current toolchain, that's why I asked if it's reproducible /if you rebuild gcrypt/
[18:52] <doko> TheMuso, mterry: how should we handle dbus-c++ and libconfig maintenance?
[18:53] <micahg> slangasek: ah, I saw it was uploaded yesterday, so I guess everything changed again yesterday?
[18:53] <micahg> slangasek: sorry, ignore that
[18:54] <micahg> slangasek: I can do a test rebuild with the old libcrypt against the new toolchain and see what happens
[18:54] <slangasek> micahg: that would be great, thanks
[18:54] <mterry> doko, is it still orphaned?
[18:56] <doko> mterry: dbus-c++: yes
[18:57] <mterry> doko, isn't that the sort of thing that's bad for main?  No one wants to take it?  I'd feel better if it was at least maintained in Ubuntu by someone...
[18:57] <doko> mterry: yes, I didn't ping you alone ;)
[18:59] <doko> mterry: ahh, I see, somebody updated to a new snapshot in unstable
[19:00] <mdz> cyphermox, it's because I don't have apt-xapian-index installed
[19:00] <mterry> doko, oh neat, that's a good start
[19:05] <mterry> doko, so what mir is this blocking again?
[19:05]  * mterry has short term memory
[19:06] <mterry> ah, libffado
[19:06] <cyphermox> mdz, ok
[19:07] <mterry> I guess I'm curious what results TheMuso has got from the pkg-multimedia/ubuntu-audio teams
[19:09] <ari-tczew> slangasek: IIRC you handle with new palette colours, right?
[19:09] <slangasek> ari-tczew: no
[19:09] <micahg> mterry: there was an offer to co-maintain dbus-c++ using CDBS outside of pkg-multimedia
[19:09] <slangasek> ari-tczew: I think you're looking for kirkland
[19:09] <ari-tczew> slangasek: ah, thanks
[19:10] <slangasek> micahg: so thinking about it, I'm guessing the problem is that chromium is meant to be looking for the .so, not for the .a, so it probably is a multiarch problem after all; digging deeper
[19:10] <ari-tczew> kirkland: could you look on this issue? http://paste.ubuntu.com/583934/
[19:10] <mterry> micahg, interesting.  an offer that was followed up on?
[19:10] <micahg> mterry: let me see if I have any more info
[19:11] <micahg> mterry: no response after that on the ML, idk about private e-mails
[19:12]  * micahg gets link to thread
[19:12] <micahg> mterry: http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2011-March/017057.html
[19:14] <kirkland> ari-tczew: hi there, debfx is uploading a fix for this
[19:14] <pitti> doko: pcsc-lite dependencies fixed, thanks for spotting
[19:14] <kirkland> ari-tczew: he's fixing this in kubuntu-settings
[19:14] <mterry> huh
[19:14] <kirkland> ari-tczew: thanks for bringing that up
[19:15] <doko> pitti: just desperately trying to keep the archive in a buildable state ;p
[19:16] <pitti> a great thing to have at any time!
[19:18] <micahg> slangasek: should I skip the chromium rebuild or start it anyways
[19:18] <slangasek> micahg: skip it, I think I know what's going on here now
[19:18] <micahg> slangasek: awesome, thanks
[19:29] <ari-tczew> kirkland: ok. thanks debfx
[19:34] <cdbs> requestsync --lp is failing. Using the latest daily build. Anyone else with a similar problem?
[19:34] <Laney> what error?
[19:35] <cdbs> Laney: no error, it just hangs
[19:35] <cdbs> and if I do Ctrl+C, I get to know that it is in lazr.restfulclient's _browser_and_retry function
[19:36] <cdbs> and is sleep()ing for some time
[19:37]  * cdbs works-around by using syncpackage
[19:37] <Laney> a better workaround would be to use mail mode
[19:38] <Laney> sounds like a bug in python-launchpadlib or lp though
[19:40] <slangasek> micahg: sorry, it's taking longer than it should to get a fixed libgcrypt11-dev; I'm about to start stabbing cdbs
[19:40] <slangasek> cdbs: no, not you
[19:40] <cdbs> Laney: hmm, this is a faster way anyway
[19:41] <cdbs> slangasek: heh, I understood already
[19:41] <bcurtiswx> back
[19:42] <slangasek> oh, figured it out
[19:42] <slangasek> and I should stab myself, not cdbs
[19:43] <micahg> cdbs: syncpackage isn't a workaround, why not downgrade to the stable version as a workaround
[19:44] <micahg> slangasek: thanks
[19:44] <cdbs> micahg: Why isn't syncpackage a workaround?
[19:44] <cdbs> Its way better sometimes
[19:45] <chrisccoulson> doko, i'm trying to get webkit support working in swt-gtk, but i'm seeing a crash that i'm a bit stuck with. what seems to be happening is a pointer that gets returned from webkit_get_default_session gets truncated to 32 bits (i'm on a 64-bit machine) before being passed to the JVM. i took a look at the assembler for the native call in the JNI, and i see this: http://paste.ubuntu.com/583951/
[19:45] <chrisccoulson> there seems to be a rogue cltq after returning from webkit, but i don't know why :/
[19:45] <ari-tczew> anybody noticed that console (terminal) can't remember used commands?
[19:45] <chrisccoulson> ^^micahg - you will have the same issue with eclipse ;)
[19:46] <chrisccoulson> doko - i'm not sure if you're the right person to ask, but it seems to be toolchain and java related ;)
[19:46] <slangasek> micahg: ok, -4ubuntu2 uploading.  Sorry, I saw that libgcrypt-dev wasn't quite right when I was doing the conversion, but didn't recognize all the implications at the time - things should build fine against it, now that libgcrypt.so is in the compiler's default path
[19:47] <slangasek> micahg: if you still have problems, at this point it'll be something that needs fixing on the chromium side
[19:47] <micahg> cdbs: syncpackage does the upload, requestsync requests a sync
[19:47] <cdbs> micahg: so, you use syncpackage to upload instead of depending on AAs
[19:48] <micahg> slangasek: ok, thanks quick fix!
[19:48] <cdbs> micahg: and, if I had the upload rights, then there's no advantage of using requestsync
[19:48] <micahg> cdbs: the use of syncpackage is discouraged, someone else will have to explain why
[19:49] <micahg> cdbs: there's a note in the manpage about it
[19:49] <cdbs> I did hear of people exclaiming that, but I never got to know about what it was
[19:49]  * cdbs mans syncpackage
[19:49] <cdbs> ah, got the warning
[19:50] <slangasek> doko: ^ with the latest udev and libgcrypt11 uploads, all the multiarch build breakage that I'm aware of today is resolved (not counting the toolchain issues you and I discussed), so this is probably a fine time for a snapshot rebuild
[19:50] <mvo> slangasek: could it be the ""  gdm: reloading...FAILED! (1)" that makes the script fail ? and that in turn kill one side of the debconf communication?
[19:50] <doko> slangasek: ok, thanks, still cleaning up component mismatches
[19:51] <mvo> slangasek: I have seen a similar report a while ago
[19:51] <fta> slangasek, thanks for the fix, good i don't have to workaround it in chromium
[19:52] <slangasek> mvo: shouldn't be; we're not outputting any differently on our fds in the failure case than the success case, the only thing that a non-null "failed" set does is trigger another debconf question
[19:54] <doko> chrisccoulson: probably, is this targeted for natty?
[19:54] <mvo> slangasek: ok
[19:55] <slangasek> mvo: now, it's possible that the reload command *itself*, that we're calling to try to restart gdm, is failing and outputting something wrongly - but we are redirecting 2>&1 when calling that, too
[19:57] <chrisccoulson> doko, it's not targetted yet. it's part of a bigger chunk of work to drop xulrunner from main
[19:58] <pitti> in a sense it is targetted to natty, as we can't keep the old xulrunner-1.9.2 in main
[20:26] <RoAkSoAx> pitti: around?
[20:26] <pitti> RoAkSoAx: yes (but kinda busy)
[20:27] <RoAkSoAx> pitti: no worries, when you have the time could you please take a look at bug #738757
[20:27] <RoAkSoAx> pitti: as this affects pm-utils either directly/indirectly
[20:28] <pitti> RoAkSoAx: opened tab, will reply in the bug (but probably only tomorrow morning)
[20:30] <RoAkSoAx> pitti: sure, whenever you have the time is fine. Thank you!
[20:30] <RoAkSoAx> pitti: it affects powernap indrectly but it is not really necessary for until next release cycle
[20:31] <jelmer> doko, hi
[20:31] <doko> jelmer, want to write a MIR? ;)
[20:32] <jelmer> doko: I'm a bit puzzled about bug 713038
[20:32] <jelmer> doko: MIR.. is the issue that subunit isn't in main but bzr is?
[20:32] <doko> jelmer: yes
[20:34] <jelmer> doko: Ah, whoops. I'll prepare a patch to get rid of that build dependency.
[20:35] <jelmer> doko: thanks
[20:35] <pitti> jelmer: (FWIW, subunit doesn't sound bad to have in main, as long as it's properly maintained in Debian)
[20:36] <pitti> slangasek: ah, so the auth log actually has entries for the cups auth fail
[20:36] <pitti> cupsd: PAM unable to dlopen(pam_unix.so): /lib/security/pam_unix.so: cannot open shared object file: No such file or directory
[20:36] <pitti> which is quite understandable :)
[20:36] <slangasek> pitti: ok, so where does that path come from?
[20:36] <pitti> good question
[20:36] <slangasek> does cups have an embedded copy of libpam somewhere?!
[20:37] <pitti> pam-start() seems to work, but pam_authenticate() returns PAM_MODULE_UNKNOWN
[20:37] <pitti> #    include <security/pam_appl.h>
[20:37] <slangasek> pitti: this is from the cupsd daemon process?
[20:37] <pitti> slangasek: yes; I run through it with a debugger now, to ensure
[20:37] <slangasek> pitti: ldd, lsof  | grep pam ?
[20:38] <pitti> cupsd     22259       root  mem       REG                8,2    51712    1045403 /lib/x86_64-linux-gnu/libpam.so.0.82.3
[20:38] <pitti> slangasek: I'll isolate the code and produce a standalone test case for now
[20:38]  * slangasek scrunches his nose
[20:38] <slangasek> pitti: thanks
[20:39] <slangasek> pitti: there aren't any hard-coded /lib/security paths in /etc/pam.d/* on this system, are there?
[20:40] <pitti> grep lib /etc/pam.d/* -> nothing
[20:40] <pitti> slangasek: su and friends obviously work
[20:40] <slangasek> right
[20:40] <pitti> /etc/pam.d/cups just has the three standard @includes
[20:40] <pitti> same as su has (su has more stuff, though)
[20:40] <slangasek> does su generate any errors in the log?  It's /possible/ that the errors are spurious
[20:40] <pitti> but su works fine
[20:41] <pitti> slangasek: no, already tested that
[20:41] <slangasek> but in fact, pam should be trying the multiarch path first
[20:41] <slangasek> ok
[20:41] <pitti> that's debian/patches-applied/lib_security_multiarch_compat, I suppose
[20:51] <slangasek> pitti: it is indeed
[20:58] <pitti> so, the same code in a standalone binary works just fine
[21:09] <Laney> pitti: yeah I don't know about that WI; appindicator is in a separate universe package and was never a dep/recommend of banshee AFAIR
[21:09] <Laney> I'd just make the WI go away
[21:09] <pitti> Laney: ok, thanks for the heads-up
[21:10] <Laney> maybe it was from a time when soundmenu was in bce
[21:12] <slangasek> pitti: does apparmor know about /lib/$arch/security?
[21:12] <pitti> ooooh, good point
[21:12] <slangasek> courtesy of jjohansen
[21:12] <pitti> [51445.388937] type=1400 audit(1300827302.687:49): apparmor="DENIED" operation="file_mmap" parent=1 profile="/usr/sbin/cupsd" name="/lib/x86_64-linux-gnu/security/pam_deny.so" pid=22259 comm="cupsd" requested_mask="m" denied_mask="m" fsuid=0 ouid=0
[21:13] <slangasek> jjohansen: good catch :)
[21:13] <jjohansen> jdstrand: ^
[21:13] <pitti> jjohansen: thanks so much, that saved a lot of trouble
[21:13]  * pitti stops nemiver and updates the AA profile
[21:13]  * jjohansen points slangasek at aa-notify its has saved me a few times
[21:14] <pitti> slangasek: that's in /etc/apparmor.d/abstractions/authentication
[21:14] <pitti> jdstrand: ^ mind if I upload apparmor to update ^ for the multiarch pam libs?
[21:15] <slangasek> pitti: should the kde abstraction be updated preemptively?  also, the base abstraction has now-broken gconv refs
[21:16] <slangasek> looking for other things that need updating
[21:17] <slangasek> /lib/tls/i686/{cmov,nosegneg}/lib*.so* -- that's also wrong now, needs to be /lib/i386-linux-gnu/tls/[...]
[21:19] <pitti> slangasek: kde> you mean for /usr/lib/*/{qt3,qt4,kde3,...}/... ?
[21:19] <slangasek> pitti: and /etc/apparmor.d/abstractions/nameservice also needs to be extended, as does /etc/apparmor.d/abstractions/kerberosclient
[21:19] <slangasek> pitti: yes, precisely
[21:20] <slangasek> similar issue in /etc/apparmor.d/abstractions/gnome, for the gtk/pango/gdk modules
[21:21] <jdstrand> pitti: no, but you might want to coordinate with sbeattie. I think he is planning an upload, but probably not today. We made a few changes (last week?), but apparently that was only for the beginning of the multiarch changes
[21:21] <pitti> jdstrand: hm, and the new patch 0004-lp736870.patch doesn't seem to be in bzr; forgot to bzr add?
[21:21] <jdstrand> slangasek: are you up to date? I specifically made changes for gconv
[21:22] <pitti>   /usr/lib/*-linux-gnu/gconv/*.so          mr,
[21:22] <pitti>   /usr/lib/*-linux-gnu/gconv/gconv-modules mr,
[21:22] <slangasek> jdstrand: sorry, I'm actually looking at maverick at the moment because it was closer to hand
[21:22] <pitti> is that the fixed one already?
[21:22] <slangasek> jdstrand: if you've already started multiarch handling, I guess I should look somewhere more recent
[21:22] <jdstrand> pitti: that is the one I fixed lst week, yes
[21:22] <pitti> jdstrand: mind to bzr add/push?
[21:22] <jdstrand> pitti: let me see...
[21:23] <slangasek> jdstrand: is this syncing with Debian?  *-linux-gnu matches all of our archs obviously, but won't cover all of Debian's
[21:23] <jdstrand> pitti: added/pushed
[21:24] <jdstrand> slangasek: apparmor is not in Debian. I did the best I could by looking at what I could find in Ubuntu at that moment
[21:24] <jdstrand> pitti: fyi, r1419
[21:24] <pitti> jdstrand: got it, thanks
[21:25] <pitti> slangasek: http://bazaar.launchpad.net/~ubuntu-core-dev/apparmor/master/view/head:/debian/patches/0004-lp736870.patch
[21:25] <slangasek> jdstrand: ok; the above ramblings cover everything I see in the maverick one that need updating for multiarch, at least
[21:26] <pitti> so that's missing pam, kde, gnome
[21:26] <pitti> and kerberosclient
[21:27] <slangasek> so we still need to fix /lib/tls (libc6-xen), kde, gnome, kerberosclient
[21:27] <slangasek> + pam of course :)
[21:27] <slangasek> pitti: are you taking it from here?
[21:27] <pitti> slangasek: yes, thanks for the guidance
[21:28] <pitti> slangasek: already confirmed that cupsd is happy with the updated profile
[21:28] <jdstrand> slangasek: we'd (upstream apparmor) like to have the Debian archs too, but that isn't as important atm (feel free to file a bug against apparmor and we can add those later)
[21:28] <slangasek> pitti: y/w - wouldn't have gotten there if I hadn't grumbled on a back channel where jjohansen heard me, heh ;)
[21:29] <slangasek> jdstrand: file bug in LP or elsewhere?
[21:29] <pitti> slangasek: bug 736870
[21:29] <jdstrand> slangasek: yes, LP
[21:30] <jdstrand> or reuse that one :)
[21:30] <pitti> ah, for the non-linux ones; that might be a separate thing
[21:31] <jdstrand> pitti, slangasek: keep in mind that gnome and kde already #include <abstractions/base> so may not need fixing
[21:31] <pitti> jdstrand: hm, weird; if I do "quilt push -a" in a clean checkout, it fails on 0002-lp727478.patch
[21:31]  * jdstrand raises eyebrows
[21:31] <slangasek> jdstrand: they do, they have non-multiarched paths for /usr/lib/$this_lib_module_dir/**
[21:32] <jdstrand> slangasek: ok
[21:32] <pitti> jdstrand: e. g. /usr/lib{,32,64}/pango/**
[21:32]  * jdstrand nods
[21:32] <pitti> jdstrand: debian/rules patch does the same..
[21:32] <jdstrand> pitti: are you using UDD? cause it might not have imported..
[21:33] <pitti> jdstrand: no, I'm using the Vcs-Bzr: branch
[21:33] <jdstrand> hmm
[21:33]  * jdstrand goes to look
[21:36] <bcurtiswx> slangasek, has the tp-glib issue been resolved?
[21:37] <slangasek> jdstrand: oh, and on armel the path is /lib/arm-linux-gnueabi/, so doesn't match your glob at all
[21:37] <slangasek> bcurtiswx: I have not been able to reproduce the failure in an up-to-date build environment
[21:38] <slangasek> jdstrand: bug #740510 for the !linux stuff
[21:38] <pitti> so, getting a bit late; I'm off to bed
[21:38] <slangasek> pitti: can you fix the *-linux-gnu globs to *-linux-gnu* while you're in there?
[21:38] <slangasek> oh, n/m
[21:38]  * slangasek takes the baton :)
[21:38] <pitti> slangasek: yes, just made a note in the other bug about that
[21:39] <pitti> slangasek: but currently blocked on the invalid patches; I guess I let jdstrand sort out the patches, and can continue on that tomorrow morning (unless Jamie or you beat me to it :) )
[21:39] <slangasek> I'll try my best to beat you to it ;)
[21:42] <jdstrand> pitti: fixed
[21:42] <jdstrand> slangasek: ^
[21:42] <jdstrand> as in the bum commit in the Vcs
[21:43] <slangasek> jdstrand: thanks
[21:49] <speakman> Hi devel folks. Is there any way to measure what's causing "/usr/bin/X" to be extremely CPU intensive sometimes?
[22:03] <slangasek> jdstrand: fix pushed to bzr.  You said this should be coordinated with sbeattie ?
[22:03] <slangasek> bcurtiswx: so are you still seeing problems with telepathy-glib in an up-to-date env?
[22:03] <bcurtiswx> slangasek, it's weird, my local build fails there, but when i use pbuilder it doesn't
[22:04] <sbeattie> slangasek: looking at your patch now.
[22:04] <slangasek> bcurtiswx: I think you have some old packages installed locally
[22:04] <slangasek> bcurtiswx: possibly an old version of gobject-introspection
[22:04] <bcurtiswx> slangasek, yeah could be. thx for your help tho :)
[22:04] <slangasek> bcurtiswx: no problem
[22:05] <slangasek> micahg: how does chromium look?
[22:06] <micahg> slangasek: idk, we'll know tomorrow when the dailies are built
[22:06] <micahg> slangasek: unless you want me to rebuild it now?
[22:06] <slangasek> micahg: ah, I think you should trigger a rebuild now, not wait another day
[22:07] <micahg> slangasek: will do
[22:10] <micahg> slangasek: ok, we should know in 3-4 hours
[22:10] <slangasek> ok :)
[22:15] <slangasek> YokoZar: ping :)
[22:17] <sbeattie> slangasek: +1 from me on your patch
[22:17] <slangasek> sbeattie: ta.  should I push to the archive now, or do you have other changes you want to go in with it soon?
[22:18] <sbeattie> slangasek: go ahead and push; I have other changes, but I won't get to them until tomorrow.
[22:18] <slangasek> ok, uploading'
[22:19] <slangasek> thanks for the review :)
[22:19] <jdstrand> sbeattie: yes, thanks for looking at it :)
[22:19] <sbeattie> slangasek: no problem.
[22:32] <RAOF> I've just had a debconf question pop up for the new libpam0g upgrade (the “what services would you like to restart” question) having run update-manager.  Is that intentional or expected?
[22:32] <slangasek> RAOF: the services have to be restarted for the pam upgrade due to multiarch; whether the question is meant to show depends on how you ran your upgrade and how you have debconf configured
[22:33] <RAOF> I ran the upgrade through update-manager (and it was a partial upgrade).  I've not changed the default debconf proirties.
[22:36] <slangasek> RAOF: it's meant to not be shown when running through update-manager
[22:37] <slangasek> well, wait
[22:37] <slangasek> RAOF: what services did it prompt you about?
[22:37] <slangasek> if you have non-default services installed on your desktop, it will still prompt
[22:37] <RAOF> Hm, it's entirely possible that I do.  I can't remember the list now.
[22:39] <micahg> @pilot out
[22:39] <slangasek> RAOF: you may be able to get the list with: echo 'get libpam0g/restart-services' |  debconf-communicate libpam0g
[22:40] <RAOF> squid gdm cups cron atd
[22:40] <RAOF> There it is.  Squid.
[22:40] <slangasek> right
[22:40] <slangasek> so: yes, expected behavior :)
[22:40] <RAOF> Um, squid?  Why does that use pam?
[22:41] <slangasek> ask lifeless :)
[23:05] <YokoZar> slangasek: hey
[23:12] <ScottK> slangasek: It was another context.  I was trying to package a new pymilter release and got that error trying to test build last night.
[23:25] <RAOF> slangasek: Oh, incidentally?  Rockin' multi-arch!  Yay!
[23:39] <cleary> hi folks - I'm interested in getting some information on the live desktop development tools. Currently I'm building/deploying ubuntu based livecd for desktop use - the tools I'm using for the cleanroom mastering process are adapted from sidux/aptosid (pyfll)
[23:40] <cleary> I'm wondering if the ubuntu team have freely available tools that I can look at using instead though? Currently it's quite a lot of work to maintain concurrency between the aptosid/debian changes and ubuntu new release changes
[23:43] <cleary> I'm even just interested in talking with someone involved - regardless of how the tools are licensed
[23:43] <cleary> if this isn't the right channel to be making this request, please point me to the correct one
[23:53] <RAOF> cleary: This is the right channel to ask, although it's skirting the edges of on-topic.
[23:55] <cleary> RAOF: I figured as much - I've struggled in the past to get any sort of traction on this type of enquiry though, hence doing it solo
[23:56] <cleary> I think there's potentially some value for canonical (curiousity sake if nothing else), I work for a large australian winery - currently deploying this setup on ~150 or so desktops
[23:57] <cleary> I'm sure I don't have to be doing it so tough though as far as tools go, but I have not been able to make headway
[23:58] <cleary> in so far as talking to the right people in the ubuntu/canonical ecosystem
[23:59] <poolie> hi scottk, can you please explain more on bug 739909?
[23:59] <poolie> did it crash or just not do anything?
[23:59] <ScottK> poolie: --> #br.
[23:59] <RAOF> cleary: Colin Watson could be one of the people to ask, as would Martin Pitt.
[23:59] <ScottK> err #bzr