[00:06] <TheMuso`> nvm my query above, I misread.
[00:34] <smoser> cjwatson, thanks. I subscribed you to bug 524020 where I tried to describe the problem.  The big thing is that I don't want to face this again in lucid.
[01:02] <jcole> just wanted to say that using yelp to popup help files in html format is extremely useful :)
[01:02] <jcole> (aka gnome-help)
[01:08] <crimsun> bah, I leave for work and stuff explodes.
[01:08] <crimsun> sorry folks, fixing now.
[01:27] <persia> Does anyone have a less ugly way to accomplish `LIB=$i; [ -h "$LIB" ] && LIB=$(ls -l $i | cut -d\  -f11); [ -z "$LIB" ] && LIB=$(ls -l $i | cut -d\  -f12); dpkg -S "$LIB" | cut -d: -f1` without awk?
[01:28]  * persia is using it to try to determine the right package that provides a shared library given a string containing a path to the .so file
[01:29] <jcole> persia: what could 'i' be
[01:29] <jcole> persia: any .so under lib?
[01:30] <persia> jcole: Yep, assuming libfoo-dev is installed.
[01:31] <persia> Unfortunately, cut doesn't seem to have a "show me the last element" function, and I'm not sure of a good way to show symlink info other than ls.
[01:32] <jcole> persia: readlink -f ?
[01:32] <persia> I knew there was something better :)
[01:33] <persia> dpkg -S $(readlink -f $i) | cut -d: -f1 works perfectly.  Thanks!
[01:33] <jcole> persia: also if you delimit by directory slashes ('/') you could use basename to extract the "last" column :)
[01:33] <jcole> persia: no problem
[01:38] <ccheney> hmm why does onboard pull in the x headers?
[01:38] <james_w> lifeless: I have no clue as to whether debcommit uses --author
[01:39] <ccheney> ah i see the bug
[01:39] <ccheney> 524148
[01:42] <jcole> bug 524148
[02:02] <persia> ccheney: Because it's *hard* to use CDLL sanely :)
[02:43] <lifeless> slangasek: do you get nervous on every pam upload?
[03:26] <tlp> sebner, persia: is there a bug report for this pulseaudio regression?
[03:50] <crimsun> tlp: which one? The alsa-lib one is already fixed in 1.0.22-0ubuntu4
[03:51] <crimsun> tlp: the "unable to change volume controls" one is known; I'll be uploading the fix after testing it locally.
[03:56] <tlp> crimsun: I did a dist-upgrade this morning from an earlier set of Lucid packages and my sound broke completely, but the pulseaudio process is running
[03:56] <tlp> I checked alsamixer and nothing seems to be muted
[03:56] <tlp> by broke I mean there is no output, but otherwise everything seems in order
[03:58] <tlp> I need to reboot here, but I'll check out syslog shortly
[04:04] <superm1> crimsun, did something happen to libpulse-dev?  i had a build build against it successfully two days ago, and yesterday it appears to have not?
[04:04] <superm1> the configure test for pulse seems to have failed the next day
[04:04] <superm1> no code changes on my end
[04:07] <superm1> seems to have broken from 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu5 to 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu6, but there is now an ubuntu8, so if I queue another rebuild, should things be fine on ubuntu8?
[04:09] <LaserJock> good grief that's a nasty looking version number
[04:10] <superm1> yeah i have no idea what that really is
[04:10] <LaserJock> looks like at some point we said "screw it, I'm doing changelog entries in the version string" ;-)
[04:10] <superm1> haha
[04:11] <superm1> i should click bug links; https://bugs.edge.launchpad.net/ubuntu/+source/pulseaudio/+bug/523716
[04:11] <superm1> that would appear to be the cause of problems
[04:11] <ubott2> Ubuntu bug 523716 in pulseaudio "pulseaudio version defined as UNKNOWN, which breaks everything with build-dep on libpulse-dev" [High,Fix released]
[04:12] <julio> hola buenas
[04:12] <julio> desde argentina, necesito ayuda
[04:12] <julio> alguien habla castellano?
[04:12] <tlp> glad it's not just me who has trouble parsing that
[04:13] <julio> hay alguien aca?
[04:14] <julio> pero, pero
[04:14] <crimsun> LaserJock: upstream hasn't released from the master branch, and their wishes are for us to use another branch (stable-queue). That version string is slightly modified from git-annotate output; essentially it's "32 changesets have been committed since this last tag (0.9.21), and the hash can be uniquely identified by 8478"
[04:14] <julio> un monton de gente conectada y nadie contesta?
[04:14] <LaserJock> julio: #ubuntu-es?
[04:14] <julio> estan todos durmiendo
[04:14] <julio> ok
[04:15] <julio> #ubuntu-es
[04:15] <LaserJock> crimsun: this is something about DVCS I've noticed now, it is much harder to version snapshot packages nicely
[04:17] <LaserJock> julio: #ubuntu-ar
[04:17] <LaserJock> julio: http://ubuntu-ar.org/argentina/irc
[04:18] <LaserJock> julio: Lo siento, no hablo español. este es el mejor que puedo hacer
[04:19]  * LaserJock crosses fingers that Google didn't just say something dirty ;-)
[04:21] <tlp> Feb 18 21:16:18 maya pulseaudio[16207]: module.c: Failed to load  module "module-esound-protocol-unix" (argument: ""): initialization failed.
[04:21] <tlp> I wonder if that has something to do with it
[04:25] <julio> gracias
[04:26] <tlp> crimsun: can you give me any leads as to what might have changed to cause this problem?
[04:27] <StevenK> LaserJock: Haha
[04:28] <tlp> bah, something did mute ALSA.
[04:28] <tlp> I didn't catch it the first time.
[04:28] <tlp> disregard. Someone said earlier what I reported was a known problem, so I assumed there was a regression.
[04:29] <tlp> I don't understand the relationship between PulseAudio and ALSA well enough to know why that happens, but it happens constantly.
[04:30] <tlp> but I've gotta go launch alsamixer or something to even notice something is muted
[04:33] <crimsun> tlp: ok, I'll repeat. There was a change that broke pulseaudio. alsa-plugins was compiled against this broken pulseaudio. I fixed pulseaudio and alsa-plugins, then realized that alsa-lib was missing a configure variable. That was fixed twice. Now the "can't (un)mute/adjust volume" issue is caused by certain alsa-mixer/paths files not being installed but still being referenced. I'm building and testing the fix to push upstr
[04:34] <tlp> Perhaps it was the former. I don't have any trouble with volume controls in "Sound Preferences"
[04:35] <tlp> I just know from past experience that silent output, a fair percentage of the time, means something got muted at the ALSA level. So I always check that first.
[04:36] <crimsun> alsa itself is fine now; it's the mixer paths that are affecting PA
[04:44] <tlp> okay. thanks for the clarification
[05:13] <persia> deb-substvars has successfully confused me.  debian/substvars contains "cdll:Depends=libx11-6, libxi6", and debian/control contains "Depends: ${cdll:Depends}".  Do I need to do something else to make this just work?  Could anyone recommend an example package that does this right?
[05:22] <StevenK> persia: That should be right
[05:23] <persia> That's what all the documentation says.  Apparently, CDBS adds a special -T which caught me.
[05:23] <StevenK> persia: An example package I can think of is fbreader, but probably Jaunty
[05:23]  * persia is hoping this works this time
[05:24] <persia> Thanks.  If this doesn't work, I'll look there.  That was lpia-magic?
[05:24] <StevenK> Yeah, that was lpia magic that changed Depends with substvars magic
[05:24] <StevenK> Too much magic ...
[05:25] <persia> Indeed.  Now there is no special smoke, and we can all rejoice :)
[05:27]  * cody-somerville rejoices.
[05:38] <pitti> Good morning
[05:38] <pitti> kees: thanks
[05:42] <crimsun> to summarise: sound problems from yesterday all fixed up. Patches pushed upstream where applicable. Sorry for the delay (real life, work, yadda).
[05:49] <persia> crimsun: Surely you're not really using yada!
[05:50] <crimsun> oops, slid that additional 'd' in there
[06:01] <superm1> pitti, re bug 523649, that code snippet that it crashed on has been there a while.  has the behavior of 'assert' changed in python? from what i gather, it's behavior is changes if __debug__ is True, but that's not manually modifiable.  so perhaps that was caused by https://lists.ubuntu.com/archives/lucid-changes/2010-February/005739.html
[06:02] <superm1> which makes me thing that assertion isn't correct in the first place the way it's written
[06:03] <pitti> hi superm1
[06:03] <pitti> superm1: I don't think assert changed recently
[06:04] <superm1> http://docs.python.org/reference/simple_stmts.html#the-assert-statement .  "The current code generator emits no code for an assert statement when optimization is requested at compile time" is what put me on that thought process
[06:05] <superm1> and hi pitti :)
[06:09] <pitti> superm1: do you know whether one of the reported crashes is just a followup of the other one?
[06:10] <pitti> I never saw two crashes at once so far
[06:10] <superm1> pitti, they look like they are caused by one-another to me yes
[06:12] <superm1> the important one is the one that crashed in install.py with the assertion error
[06:12] <superm1> that runtime error will go away when the assertion error is fixed
[06:13] <pitti> superm1: ok, please feel free to invalidate the other one then
[07:54] <pitti> bryceh: oh, CD builds failed because -nouveau is uninstallable (it's still in universe)
[07:57]  * pitti promotes and closes MIR
[08:00] <bryceh> pitti, danke
[08:00] <pitti> bryceh: so the lbm metapackage is sorted out now?
[08:01] <bryceh> pitti, I believe so.
[08:02] <bryceh> pitti, I haven't verified that yet though
[08:02] <pitti> linux-backports-modules-nouveau-lucid-generic | 2.6.32.13.14 |         lucid | amd64, i386
[08:02] <pitti> \o/
[08:02] <pitti> Source: linux-meta
[08:02] <pitti> Depends: linux-backports-modules-nouveau-2.6.32-13-generic
[08:02]  * bryceh nods
[08:02] <pitti> looks fine
[08:02] <bryceh> yeah I pulled the source and checked the changelog and so on and it all looked kosher
[08:02] <pitti> bryceh: want to have the pleasure of closing two work items? :-)
[08:02] <bryceh> on it
[08:03] <pitti> add nouveau lbm metapackage as dependency to xserver-xorg-video-nouveau: TODO
[08:03] <pitti> that sounds easy now
[08:03] <pitti> great, then this should be done
[08:03] <pitti> well done!
[08:03]  * pitti yays for KMS on nvidia
[08:03] <bryceh> it was a good team effort
[08:04] <bryceh> thank god for RAOF and Sarvatt
[08:07] <bryceh> pitti, did you see that we now have apport collecting bugs on X freezes now too?
[08:07] <pitti> bryceh: yes, I saw the WI and the upload
[08:07] <pitti> \o/
[08:07] <pitti> bryceh: craving for more bug reports? :-)
[08:07] <bryceh> heh, heck no
[08:07] <pitti> seriously, I hope this will be a huge help in tracking those down
[08:08] <pitti> right now we can't do much more than just shrugging, I guess
[08:08] <pitti> s/right/until/
[08:08] <bryceh> actually I think it will help because before people would file bugs about freezes but it took a lot of effort to walk the user through collecting this info
[08:10] <bryceh> pitti, hmm it looks like lbm is already listed as a depends for -nouveau?
[08:10] <bryceh> Depends: ${shlibs:Depends},
[08:10] <bryceh>  ${misc:Depends},
[08:10] <bryceh>  ${xserver:Depends},
[08:10] <bryceh>  linux-backports-modules-nouveau-2.6.32-12-generic | linux-backports-modules-nouveau-2.6.32-12-generic-pae | linux-backports-modules-nouveau-2.6.32-12-server
[08:11] <bryceh> do we need anything beyond that?
[08:11] <pitti> bryceh: no, only an (obsolete) ABI version, not the metapackage
[08:11] <bryceh> oh right
[08:13] <bryceh> so it's enough to just Depends on linux-backports-modules-nouveau-lucid-generic ?
[08:14] <pitti> bryceh: I don't see a metapackage for -i386 or -server
[08:14] <pitti> so from my POV yes
[08:14] <slangasek> lifeless: generally only the ones when upstream is rewriting code :)
[08:14] <pitti> bryceh: oh, incidentally this is quite urgent; lbm-n is uninstallable
[08:14] <pitti> bryceh: due to the obsolete abi
[08:15] <pitti> bryceh: if you could change that now, I can trigger a new CD build later today, so that we finally have buildable CDs again (also for testing)
[08:15] <bryceh> doing it now
[08:15] <pitti> bryceh: cheers
[08:15] <bryceh> uploaded
[08:21] <dholbach> good morning
[08:23] <bryceh> pitti, 3 WIs closed
[08:23] <pitti> \o/
[08:24] <pitti> http://people.canonical.com/~pitti/workitems/canonical-desktop-team-lucid-alpha-3.html#bryceharrington
[08:24] <pitti> down to 1 then, go, Bryce, go!
[08:24] <pitti> Close out all -nv bug reports filed before transition as obsolete due to move
[08:24] <pitti> now, that sounds like a fun one :)
[08:24] <bryceh> yep
[08:24] <pitti> "Status: invalid\n nv, we do not love you any more, kthxbye"
[08:27] <tjaalton> we still need it for the really old chips though
[08:28] <pitti> tjaalton: yes, but we still don't love it, I take it :)
[08:28] <tjaalton> pitti: got that right :)
[08:29] <pitti> ok, I think the Xsession.d/ scripts are really streamlined now
[08:29] <bryceh> sweet
[08:29] <pitti> tjaalton: I hope I didn't screw up any git with my xorg upload?
[08:30] <bryceh> pitti, I fixed it
[08:30] <pranith> is the UNR the choice if we want to install on ARM devices?
[08:30] <pitti> bryceh: my ubuntu6 followup as well?
[08:30] <tjaalton> pitti: yeah it's ok
[08:30] <pitti> bryceh: thanks
[08:31] <tjaalton> that one isn't there yet
[08:31] <pitti> I think I'm down to exactly one external program now ("cat"), thanks to dash not having $(< file)
[08:31] <bryceh> pitti, oh no I just did the first one
[08:31] <pitti> sorry for the blunder of the first one
[08:31] <tjaalton> bryceh: probably add -nv back to video-all as well?
[08:31] <pitti> I uploaded that, went to bed, and thought "oh argh"
[08:32] <bryceh> tjaalton, yep
[08:32] <bryceh> tjaalton, pushed
[08:32] <bryceh> pitti, how are we on disk space?
[08:33] <pitti> bryceh: I don't know; we didn't have buildable CDs for several days
[08:33] <pitti> I chopped some langpacks
[08:33] <pitti> but each day there was something else causing uninstallability
[08:33] <smoser> james_w, somehow , in my greatness, i got http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/cloud-init/lucid/annotate/head%3A/.bzr-builddeb/default.conf commited with "native = True"
[08:33] <smoser> and that is wreaking havok
[08:33] <pitti> bryceh: once your -nouveau fix is pushed, I'll trigger a rebuild
[08:34] <smoser> i branched from that, and worked by way to  lp:~cloud-init-dev/cloud-init/lucid
[08:34] <smoser> which i believe is in a "fixed" state.
[08:36] <bryceh> pitti, subject: [ubuntu/lucid] xserver-xorg-video-nouveau
[08:36] <bryceh>         1:0.0.15+git20100128+2630a15-0ubuntu2 (Accepted)
[08:37] <pitti> bryceh: right, it's already built; now just waiting for the next publisher to finish (in 1:20 hours)
[08:40] <apw> anyone seen this on the buildds, this is on arm, /usr/bin/dpkg-deb: line 53: 15639 Segmentation fault      /usr/bin/pkgmaintainermangler $ORIGINAL_ARGUMENTS
[08:41] <apw> that message implies dpkg-deb is a script, which its not on my local installs ...
[08:45] <didrocks> lool: on netbook seed, I see the Germinate workaround about webfav and abrower. I would have thought that we have to list firefox before webfav so that it doesn't download abrowser (and furthemore, if I just try to install abrowser, it tries to install last firefox)
[08:51] <pitti> bryceh: fun that the freeze hook works now -- there's a typo in teh udev rule: "ACTION=="change"
[08:51] <pitti> bryceh: (first " before ACTION)
[08:51] <bryceh> oops
[08:51] <bryceh> how'd that get there?
[09:03] <admiral0_wrk> hi
[09:04] <admiral0_wrk> i'm posting here because it's more relevant than #ubuntu
[09:04] <admiral0_wrk> where is the source for efl interface in netbook remix?
[09:08] <pitti> I was just going to answer, but if you disappear after 60 seconds..
[09:09] <ogra> pitti, yours to slow, really
[09:09] <ogra> *you're
[09:14] <apw> pitti, cjwatson, any suggestions how to debug this:
[09:14] <apw> /usr/bin/dpkg-deb: line 53: 15639 Segmentation fault      /usr/bin/pkgmaintainermangler $ORIGINAL_ARGUMENTS
[09:14] <apw> dh_builddeb: dpkg-deb --build debian/sata-modules-2.6.32-14-versatile-di ../sata-modules-2.6.32-14-versatile-di_2.6.32-14.19_armel.udeb returned exit code 139
[09:15] <apw> seems to only occur on buildds
[09:17] <ogra> apw, buildd hiccup, just give back
[09:19] <apw> why the heck did it have to do it on the build which takes 6 hours ... ie. arm
[09:19]  * primes2h waves tseliot
[09:19] <ogra> apw, because it only does that with very long building packages ...
[09:20] <ogra> apw, aks the kde guys how much fun they have with our armel buildds :)
[09:20] <ogra> *ask even
[09:20] <primes2h> tseliot: Did you read the last comment? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/499445
[09:21] <primes2h> tseliot: I think a SRU could be worthwhile
[09:22] <primes2h> tseliot: That version has just been uploaded in Lucid..
[09:22] <primes2h> tseliot: as I see some days ago
[09:23] <primes2h> tseliot: What do you think?
[09:26] <pitti> apw: urgh, no immediate idea I'm afraid :/
[09:26] <pitti> apw: maintainermangler is just pure shell
[09:26] <apw> yay
[09:27] <ogra> apw, itzs very likely a buildd kernel memory management issue ... and we cant replace the kernels on these machines easily
[09:33] <tseliot> primes2h: yes, I did that upload. We're considering idea of an SRU
[09:35] <primes2h> tseliot: That's really nice. So can I nominate it for Karmic?
[09:36] <tseliot> primes2h: it's something we'll deal with if we decide to file an SRU
[09:37] <primes2h> tseliot: Ok, so I'll patiently wait for it ;-)
[09:37] <primes2h> Thank you.
[09:37] <tseliot> np
[10:11] <davidekholm> Hi. I'm the founder of Jalbum (http://jalbum.net). We've just adopted our web photo album software for Ubuntu and packaged it as a .deb package
[10:11] <davidekholm> Can anyone here give me guidance on how to get Jalbum into "Ubuntu Software Center"
[10:12] <davidekholm> We're true freeware, no crippleware, but Jalbum is only 50% open source - generic code under LGPL but still some core code not opened.
[10:18] <davidekholm> Anyone with input on this?
[10:19] <Tm_T> davidekholm: I think that falls to #ubuntu-motu (:
[10:20] <davidekholm> Ok. I'll post there and see what repsonse I get.
[10:33] <pitti> superm1: would you happen to know an easy workaround for the installer failure?
[10:39] <pitti> superm1: oops -- it just occured to me that it didn't even ask me for partitioning
[10:41] <soren> Is it intentional that onboard pulls in a whole stack of x development packages?
[10:43] <soren> persia: You touched it last :) Any idea?
[10:48] <wgrant> soren: He last touched it to remove those dependencies.
[10:50] <soren> Oh. Heh :)
[10:50]  * soren kicks his mirror around a bit
[11:48] <Phurl> hi all, I have a problem with building a qt app on karmic. https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/524354 do I need to upgrade my qt?
[12:00] <pitti> bryceh: yay, I just got an apport reported freeze bug!
[12:01] <jdub> pitti: thanks for remotely teaching me about the type builtin today :-)
[12:01] <pitti> hey jdub, how are you?
[12:01] <jdub> pitti: lovely - you?
[12:01] <pitti> I'm great, thanks!
[12:02] <pitti> still struggling with boot speed, though
[12:02] <jdub> lucid is rocking along nicely
[12:02] <pitti> yeah, it is, if only plymouth would work :)
[12:02] <jdub> heh
[12:02] <jdub> been having issues with that on my netbook, but not my desktop
[12:03] <pitti> bryceh: except that the GPU dump says "no such file or directory" :(   perhaps it doesn't get along so well with collecting infos after a reboot
[12:09] <chrisccoulson> pitti - how do you get apport to report a freeze?
[12:09] <chrisccoulson> X freezes constantly on my laptop now
[12:09] <pitti> chrisccoulson: it "just happens"
[12:09] <pitti> xserver-xorg-video-intel.2010-02-19_12:55:36.379175.crash
[12:09] <chrisccoulson> pitti - it's magic? ;)
[12:10] <pitti> chrisccoulson: with today's xorg
[12:20] <bryceh> pitti: sweet... did you not have intel_reg_dumper installed maybe?
[12:21] <pitti> indeed I don't
[12:21] <pitti> xserver-xorg-video-intel-dbg, isn't it?
[12:22] <pitti> ah, no, intel-gpu-tools
[12:22]  * pitti -> lunch
[12:23] <nigelb> bryceh: thanks for sponsoring a debdiff I posted a few days back :)
[12:23] <bryceh> nigelb, my pleasure
[12:23] <nigelb> :)
[13:05] <jiboumans> hi gents, we got a question on the ubuntu-server mailing list about nfs v4 for lucid+1. has anyone here given that any thought before? https://lists.ubuntu.com/archives/ubuntu-server/2010-February/003808.html
[13:58] <ttx> Hm, looks like console-setup no longer sets up keyboard on recent ISOs
[14:06] <ttx> bug 524439
[14:26] <pitti> apw, tjaalton: do you happen to know about the status of bug 507148?
[14:27] <pitti> this sounds like it could require a painful backport of the .33 ati driver? (AFAIUI, upstream does not recommend us to use .32, but .33, which will be supported longer)
[14:27] <apw> pitti, i think that one is the one where KMS doesn't work for that board, and it also crashes a bit
[14:28] <apw> if so: then i think we had a few patches for it which might mean nomodeset might work for it
[14:28] <apw> but ... as you say upstream is saying "2.6.32 is crap use .33 we don't care about .32'
[14:28] <apw> its not clear how that gives us any more support really as they won't care about .33 in about 2 weeks either
[14:28] <pitti> apw: hm, I thought they said "we'll support that longer", perhaps they also release something with it?
[14:29] <apw> yeah but htat might just mean, "cause we care about the previous release until the next one" for all i actually know
[14:29] <pitti> ok
[14:30] <apw> pitti, but yes we are getting pressure for ati to be .33 indeed they are actually saying 'drm' at .32 is crap
[14:30] <apw> and that we should be backporting .33 drm en-toto for long term use
[14:30] <hyperair> http://pastebin.com/m58534978 <-- is udev supposed to fork this many times?
[14:30] <pitti> that sounds like fun
[14:30] <apw> i have an action to see how hard that is, then its up to bryceh to chose i suspect
[14:30] <pitti> hyperair: erm, no
[14:32] <hyperair> pitti: okay. this is weird >_>
[14:32]  * hyperair sighs. such a problematic laptop
[14:32] <hyperair> from pulseaudio leaking memory to udev forkbombing to undetected usb devices...
[14:32] <hyperair> i can't possibly think of any machine that is less ubuntu-friendly than this
[14:33] <tjaalton> apw, pitti: f12 already has the .33 drm on top of .32, so it'll end up in rhel6 as well
[14:33] <tjaalton> and at least bits from .34
[14:33] <pitti> what a mess :/
[14:33] <tjaalton> why?
[14:33] <apw> upstream drm seems to have no idea what 'release' means
[14:34] <apw> its not meant to mean 'drop the tip ... NOW'
[14:34] <apw> tjaalton, how do you expect to be able to support a lash up like that for 5 yeas
[14:34] <tjaalton> .32 drm is buggy all over the place
[14:35] <tjaalton> 3y for the desktop
[14:35] <apw> you'd think they would produce some fixes for it though wouldn't you
[14:35] <tjaalton> just pull in what rhel6 has
[14:35] <pitti> I guess going with .33 is entirely out of question?
[14:35] <apw> pitti, the whole of .33?
[14:35] <tjaalton> pitti: no, that's what will likely happen
[14:35] <tjaalton> just the drm of course
[14:35] <pitti> apw: yes
[14:36] <tjaalton> drm is self-contained
[14:36] <pitti> (for having the same kernel version as other distros, and thus sharing patches, etc.)
[14:36] <apw> it would put us out of sync with long term support release
[14:36] <tjaalton> pretty much completely separate from the rest of the kernel
[14:36] <pitti> tjaalton: oh, it's relatively independent of the other kernel bits?
[14:36] <tjaalton> pitti: right
[14:36] <apw> the other distros seem to be going .32 + .33 drm
[14:37] <pitti> if it's sanely possible to pull the drm .33 bits, this would certainly be better than taking all of .33
[14:37] <tjaalton> we also need the nouveau abi bump that'll happen for .34 (and was reverted from the libdrm 2.4.18 I just uploaded)
[14:37]  * pitti remembers a recent LKML post about Linus not being happy about so many recent regressions
[14:37] <apw> pitti, yeah ... i am lookin at it
[14:37] <pitti> apw: May the source be with you!
[14:37] <apw> the nouveau people are even worse
[14:38] <tjaalton> http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-12/drm-upgrayedd.patch?view=log
[14:38] <tjaalton> well, nouveau hasn't even had a release yet
[14:39] <tjaalton> but it should happen after .33 I think
[14:39] <apw> its in .33?
[14:39] <tjaalton> yes
[14:39] <apw> so when .33 releases it will be released
[14:39] <tjaalton> that's why lbm has it no? :)
[14:39] <tjaalton> well I meant the ddx
[14:39] <tjaalton> there has been no tagged releases
[14:39] <tjaalton> so far
[14:43] <apw> so there will be no userspace support for .33 nouveau ?
[14:48] <tjaalton> apw: we have it now, but we need to backport fixes from >= .34 in the future, so having the new abi in lucid is beneficial
[14:49] <apw> what a damn mess
[14:49] <tjaalton> it's still better than status quo
[14:56] <apw> dpeends if you have to try and maintain the kernel that results from the fusion
[15:06] <soren> I'm confused by the locale names I see in Lucid. So, gdm sets my $LANG to da_DK.utf8. It's been da_DK.UTF-8 since almost forever, but now it's changed. /usr/lib/locale/da_DK.utf8 does exist, but "locale-gen $LANG" no longer works, since locale-gen still expects da_DK.UTF-8.
[15:07] <soren> I'm not sure who or what to blame.
[15:09] <BenC> Good morning people of Ubuntu
[15:12] <ion> pitti: Yay for a default keyboard shortcut for launching a term.
[15:12] <soren> BenC: Hey dude.
[15:12] <pitti> ion: :)
[15:17] <dholbach> bah, why does rhythmbox try to index my whole harddisk everytime I start it
[15:18] <dholbach> ok, rather ~, but that's still bad enough
[15:19] <ion> Do you have ~ set as the media library path?
[15:23] <davmor2> guys une doesn't show the install option in favourites
[15:25] <ion> apw: linux-backports-modules-nouveau-lucid-generic is mistyped with ‘noveau’. linux-backports-modules-wireless-lucid-generic-pae depends on linux-backports-modules-2.6.32-13-generic-pae instead of linux-backports-modules-wireless-2.6.32-13-generic-pae.
[15:30] <dholbach> ion: I don't have a media library path set
[15:40] <apw> ion, ta
[15:50] <soren> I wonder if it'd make sense to have the build-essential seed not include recommends.
[15:51] <soren> It would free at least a couple of MB on the ISOs.
[15:51] <soren> (manpages-dev alone eats 3 MB)
[15:53] <soren> brb
[15:53] <Laibsch> Hi
[15:55] <Laibsch> git-buildpackage in lucid currently does not handle dpkg v3 which I guess is a pretty serious thing.  The version in testing and unstable does.  I think there is a minimal patch available that could be backported to the lucid package but I wonder if it isn't better to still try a merge instead.  Opinions?
[15:55]  * Laibsch is afraid we may end up backporting just about everything
[16:02] <superm1> pitti, i think it's a small fix, the pointer that partitioning wasn't being asked is the real problem
[16:08] <kitallis> \//k
[16:14] <persia> soren: We talked about `locale-gen ${foo}.utf8` earlier, and the consensus seemed to be that either vm-builder needed to do something like language-selector to get a complete list of locales (and match against it), or just check for well-formedness, as 1) the complete list of locales is not available locally without extra work, and 2) the set of locales differs by release.
[16:16] <soren> persia: It does seem rather odd that "locale-gen $LANG" doesn't work.
[16:16] <soren> regardless
[16:16] <persia> Why should it work?  There's no guarantee that the relevant langpack is installed in the chroot.
[16:16] <soren> Not in my chroot.
[16:16] <soren> On my own system.
[16:17] <persia> OK.  There's no guarantee that the relevant langpack is installed on your system :)
[16:17] <soren> $ locale-gen $LANG || echo this is weird
[16:17] <soren> this is weird
[16:17] <soren> Well.. it is.
[16:18] <soren> locale-gen expects the charset to be "UTF-8", not "utf8".
[16:18] <persia> soren: You may want to review http://irclogs.ubuntu.com/2010/02/18/#ubuntu-devel.txt from 21:25 for more in-depth discussion.
[16:18] <ogra> well, there is no guarantee that $LANG is sometinh locale-gen can use
[16:18] <soren> I didn't say I wanted a guarantee.
[16:18] <soren> i'm just saying it's odd.
[16:19] <soren> Can't we just all please accept that my life would be easier if everyone else did something differently?
[16:19] <soren> kthxbai
[16:19] <persia> Accepting that is easy.  Now make sure it's everyone's goal :)
[16:20] <pitti> soren: I can't make a lot of sense from this either, FWIW; locales have been .UTF-8 forever, and in lucid libc6 seems to have switched to .utf8
[16:20] <pitti> like "almost, but not quite"
[16:20] <soren> pitti: Exactly.
[16:20] <pitti> I haven't investigated it at all, though
[16:20] <ogra> i know cjwatson has looked at it
[16:20] <pitti> soren: however, locale-gen $LANG does work
[16:21] <soren> It doesn't.
[16:21] <ogra> it doesnt
[16:21] <pitti> it's just that LANG=de_DE.utf8, not .UTF-8 any more
[16:21] <soren> It silently fails.
[16:21] <soren> Check the exit code.
[16:21] <pitti> oh
[16:21] <pitti> ok, that's a bug
[16:21] <soren> ...and try it with UTF-8.
[16:21] <soren> See the difference.
[16:21]  * persia suspects a bug in locale-gen
[16:21] <pitti>         GENERATE=`grep -E "^${1}( |[._@][^[:space:]]* )UTF-8" /usr/share/i18n/SUPPORTED`
[16:22] <pitti> that was me, in ancient times
[16:23] <soren> Oh!
[16:24] <pitti> /usr/share/i18n/SUPPORTED also needs to be updated then, I figure
[16:24] <pitti> but I'm still not sure what the "canonical" form is
[16:24] <pitti> we don't do any migration on upgrade right now
[16:25] <pitti> and I don't even know whether .utf8 was even intentional
[16:25] <soren> We can argue all day long that /[uU][tT][fF]-?8/ are all valid ways to write it, but we've always done it one particular way. It would be nice to at least understand why it changed.
[16:25] <pitti> ack
[16:26]  * pitti will read the IRC link from persia after meeting
[16:27] <soren> ..and for another week, I'm still getting paid to understand this operating system, and not just accept when it changes underneath me. :)
[16:28] <mdeslaur> soren: you know that by saying that you've effectively deferred the investigation for a week, right? :)
[16:28] <soren> mdeslaur: I do now :(
[16:28] <soren> Darn it.
[16:40] <mathiaz> what needs to be done to promote a binary package to main? (puppet-common is currently in universe - while puppet is in main)
[16:41] <mathiaz> puppet-common is already in the component-mismatch list since puppet and puppetmaster (both in main) depend on it
[16:41] <pitti> mathiaz: just poke an archive admin
[16:41]  * pitti looks
[16:42] <pitti> mathiaz: done
[16:42] <mathiaz> pitti: \o/ - thank you!
[16:49] <qense> pitti: there is this comment in /etc/apport/crashdb.conf: "# NOTE this will change Fall '07 when RHT switches to bugzilla 3.x!" Fall '07 has already been a while ago now, is it still valid?
[16:49] <pitti> qense: no, I don't think so; Fedora decided to NIH apport
[16:51] <qense> pitti: ok, then shouldn't this be removed?
[16:53] <qense> (me=afk)
[16:53] <pitti> qense: we could, yes, but it would be a rather pointless conffile change
[16:53] <qense> pitti: ok
[16:53] <pitti> qense: if I'll ever change it for another reason, I'll remove the entire stanza
[16:54] <lool> Would someone be so kind to NEW linux on all arches?
[16:58] <pitti> lool: I'm on it
[16:58] <lool> pitti: Thanks a lot!
[16:58] <lool> That will allow to poke the versatile armel udebs over the weekend
[16:59] <lool> (and will also allow me to give back user-mode-linux, but that's minor)
[17:03] <pitti> l;oall done
[17:03] <pitti> argh, what was that
[17:03] <pitti> lool: all done
[17:03] <pitti> right in time for the publisher
[17:03] <lool> pitti: thanks a lot!
[17:05] <pitti> superm1: my hero!
[17:08] <superm1> :)
[17:16] <geser> ScottK: does this https://bugs.edge.launchpad.net/ubuntu/+source/pysvn/+bug/523863/comments/5 answer your question?
[17:21] <superm1> pitti, after that publishes can you queue up an ubuntu daily-live rebuild?  I'm suspecting it's far more widespread than just your hardware.. the consequences were pushing the partman pages out to "post-install" pages
[17:21] <nigelb> Do we still have time to add apport hooks to packages?
[17:22] <pitti> superm1: sure; I was going to fiddle with the seeds anyway to make it not overflown any more
[17:23] <nigelb> been thinking of creating a rhythmbox hook.  Wondering if its still possible for lucid
[17:49] <smoser> slangasek, the branch linked to bug 524516 has all the needed fixes in it.
[17:49] <smoser> verified that with that build and a new upstart, it runs early and reliably.
[17:50] <smoser> slangasek, how should i proceed there ?
[17:54] <slangasek> smoser: I'm going to take care of fixing upstart today; do you want to wait for that before changing cloud-init, or maybe just have cloud-init add a versioned dep on upstart?
[17:54] <smoser> well, if you're going to get it fixed today, i'm ok to wait.
[17:55] <smoser> if you think i should add a versioned dep, then i'm ok to do that.
[17:58] <ScottK> geser: It does.
[18:00] <slangasek> smoser: so what was the other cloud-init job with the unsatisfiable 'and' condition (and what was the condition)?
[18:01] <smoser> well, it seemed that anything that depended on 'cloud-config and local-filesystems' or 'cloud-config and filesystems' would cause issues.
[18:02] <smoser> err.. wait.
[18:02] <smoser> yeah, thats right.
[18:03] <smoser> cloud-init emits cloud-config, and anything that had those 'start on' listed above would seemingly block boot.
[18:04] <smoser> i changed them to just depend on filesystems, with the implicit assertion that cloud-config would alrady be done at that point.
[18:10] <shtylman_> where is the best place to ask about package dependency conerns/problems?
[18:14] <fabrice_sp> dbus is back in lucid? I thought it would disappear in lucid
[18:15] <smoser> slangasek, please let me know if you need anything from me.
[18:17] <persia> shtylman_: Depends on the package.  Here works, or a team channel for the developers working on that packages, if it's specific.
[18:18] <shtylman_> persia: k
[18:18] <shtylman_> well...my problems started with: http://packages.ubuntu.com/lucid/liblua5.1-sql-mysql-2
[18:18] <shtylman_> which wants 15off version
[18:18] <shtylman_> and other system libraries use the 16 version
[18:19] <shtylman_> so I get some conflicts and executables with two versions in them
[18:19] <shtylman_> and nice warnings like:
[18:19] <shtylman_> /usr/bin/ld: warning: libmysqlclient.so.16, needed by
[18:19] <shtylman_> /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libmysqlpp.so, may
[18:19] <shtylman_> conflict with libmysqlclient.so.15
[18:19] <shtylman_> and I don't seem to be able to remove one or the other without causing a massive removal of other packages....
[18:20] <shtylman_> I dunno if its an actual issue...but I figured I would ask
[18:20] <shtylman_> and get some clarification
[18:22] <fabrice_sp> shtylman, in Debian, this package is using 16 version, so it seems that the ubuntu version needs to be rebuilt
[18:22] <shtylman_> fabrice_sp: do I need to file a bug or something?
[18:23] <shtylman_> cause right now it makes things kinda broken :)
[18:23] <fabrice_sp> shtylman, no bug reported right now, so file one, please :-)
[18:24] <shtylman_> against which package? and how should I describe it? to make it clear and such
[18:25] <fabrice_sp> agains liblua5.1-sql-mysql-2
[18:25] <shtylman_> fabrice_sp: k
[18:25] <fabrice_sp> a lot of pacakges still depends on 15off ,so it seems some transition is on going
[18:26] <fabrice_sp> (or missing)
[18:26] <shtylman_> heh
[18:32] <shtylman_> fabrice_sp: should I subscribe anyone to it? or leave as default
[18:33] <fabrice_sp> subscribe me (fabricesp): you just uncovered a wide issue, so I'll have a look (a rebuild is not enought)
[18:33] <fabrice_sp> shtylman, ^
[18:33] <shtylman_> fabrice_sp: will do... I loe uncovering wide issues :)
[18:34] <fabrice_sp> :-D
[18:44] <slangasek> smoser: ah, right, presumably because cloud-init isn't emitting cloud-config asynchronously :)
[18:44] <slangasek> but yes, an implicit assertion is fine
[21:01] <smoser> slangasek, regarding the FFE bug, please let me knwo if you need anything .
[21:01] <smoser> i have to be leaving, but will check in later.
[21:06] <slangasek> smoser: which FFe bug is this?  I don't see anything in my mailbox suggesting ubuntu-release has been subscribed to a bug
[21:07] <smoser> hm..
[21:07] <smoser> bug 524516
[21:07] <slangasek> oh, 524516, I see it on the webpage
[21:07] <smoser> i was under the impression you'd sponsor that for me? or do i need to get someone else.
[21:07] <smoser> sorry if that was way off base.
[21:08] <slangasek> right - ok, will process that and let you know
[21:08] <slangasek> well, I was saying that I was fixing upstart, which I've just uploaded
[21:31] <jbebel> cjwatson: You'll be interested in fixing 524637. patch supplied.
[21:39] <slangasek> smoser: the branch you've linked from 524516 doesn't correspond to the archive at all
[21:40] <slangasek> smoser: cloud-init is at 0.5.5-0ubuntu2 in the archive; the bzr branch's changelog lists neither of 0.5.5-0ubuntu{1,2}
[22:00] <lamalex> Hi, I'm getting confused on what the procedure is to have a package sync'd from debian into universe
[22:00] <lamalex> Do I still file a needs-packaging bug?
[22:02] <lifeless> requestsync
[22:03] <lamalex> !requestsync
[22:04] <c_korn> !syncrequest | lamalex
[22:05] <lifeless> lamalex: its a command, in ubuntu-dev-tools
[22:05] <lamalex> lifeless: yah, I just saw that
[22:05] <lamalex> thanks
[22:05] <lamalex> lifeless: does this apply for new packages as well?
[22:06] <lifeless> yes, though its a little tricky to get the bug filed
[22:06] <lifeless> I normally upload a stub package to my ppa to make the SPR and then I can file the bug:P
[22:07] <lamalex> hm actually it's already been sync'd. I don't know how I missed it when I was searching the first time
[22:07] <slangasek> lifeless: you don't just file it against Ubuntu, nopackage?
[22:07] <lifeless> slangasek: no
[22:07] <lifeless> slangasek: the other thing I tend to do is waylay an archive admin
[22:08] <slangasek> tsk, queuejumper
[22:08] <lifeless> slangasek: not at all
[22:08] <lifeless> slangasek: I say 'please run the damn queue'
[22:08] <slangasek> we're past DebianImportFreeze
[22:08] <slangasek> so that won't get you much :)
[22:08] <lifeless> slangasek: so I'll queuejump now ;)
[22:10] <ScottK> lamalex: We're past Feature Freeze, so you'd need a feature freeze exception and a good reason.
[22:10] <lamalex> ScottK: doesn't matter anyway
[22:11] <lamalex> it's been sunc(?)
[22:11] <persia> synchronised
[22:11] <lifeless> sunk, but its a false friend
[22:11] <lifeless> synced
[22:12] <lamalex> I'm gonna stick with sunc, it's got nice phenomes
[22:12] <lamalex> very guttural
[22:24] <slangasek> I endorse this participle
[22:29] <slangasek> smoser: "cloud config and local-filesystems and net-device-up IFACE=eth0" - "local-filesystems" should always be after the other two if this package is installed, no?
[22:46] <ev> jbebel: committed and uploaded
[22:46] <ev> 524637, that is
[22:47] <jbebel> ev, excellent, thanks!
[22:47] <ev> sure thing.  Thanks for the patch!
[22:48] <lifeless> james_w: did you file a bug about trial <-> testresources and your port listening resource?
[22:48] <james_w> no
[22:48] <lifeless> I just found the mail you sent me before we spoke
[22:49] <lifeless> I would like it if you filed a bug /somewhere/ - there clearly is a problem
[22:50] <james_w> I sent it after we spoke, when you asked me to send you a mail about it so that you could file the bug at twistedmatrix
[22:50] <slangasek> smoser: oh, ignore me, that's exactly what you fixed, I was reading the diff backwards
[22:50] <james_w> or at least, that's what I understood from our combination
[22:51] <lifeless> james_w: ah! ok. I shall handle
[22:51] <james_w> thanks
[22:51] <james_w> you'll to a better job of the discussion with them than I woul
[22:53] <slangasek> smoser: "start on filesystems" - that's not the documented event that mountall emits, that should be 'filesystem'
[23:04] <YokoZar> What happened to libxtrap6?  Was it obsolete?
[23:22] <smoser> slangasek, where did i have that ?
[23:23] <smoser> slangasek, i'll be back in ~ 1 hour or so.
[23:27] <slangasek> smoser: which?
[23:27] <smoser> ...
[23:27] <smoser> i'll push a fix for that to that branch
[23:27] <smoser> you're right on filesystems
[23:27] <slangasek> smoser: the 'start on filesystems' is in cloud-config-ssh.conf, cloud-disable-ec2-metadata... ok
[23:27] <smoser> right.
[23:27] <smoser> thank you for noticing that.
[23:29] <smoser> ok. slangasek that is pushed now to the lucid branch
[23:29] <smoser> the one linked there.
[23:30] <slangasek> smoser: ok, thanks.  can you clarify for me why the previous changelog entries went away when you rebased to 0.5.6 - was that just a casualty of a revert?
[23:30] <smoser> it was a causualty of .bzr-builddeb
[23:30] <smoser> and being "native"
[23:30] <slangasek> smoser: also, is there an upstream tarball available somewhere for use when uploading this?  Otherwise it just ends up as a native package again.
[23:30] <slangasek> no, I think "being native" is a red herring here
[23:30] <smoser> the 0.5.5 merge was never done in that branch
[23:31] <smoser> so i backed to 0.5.4 and then jumpbed forward, just ditching the merge-upstream for 0.5.5
[23:31] <slangasek> ah
[23:31] <smoser> merge-upstream moaned that it didn't have the tags for the 0.5.6 version
[23:31] <smoser> err 0.5.5
[23:31] <smoser> so it wouldn't let me go to 0.5.6
[23:31] <slangasek> right
[23:32] <smoser> i might have those numbers wrong
[23:32] <smoser> but i just forced it
[23:32] <smoser> sorry
[23:32] <smoser> the upstream tarball should be creatable by bzr-builddeb
[23:32] <smoser> but it is available for download
[23:33] <smoser> http://smoser.brickies.net/
[23:34] <smoser> (bad, i know). i'll put it somehwere more official
[23:34] <smoser> i have to run . i'll check back in in 1 hour.
[23:34] <slangasek> smoser: oh, you have two references to the same bug # in your changelog - can you fix that (I think maybe you wanted to add 524516 as the second one), add a tag for the release, and I'll sponsor?
[23:38] <pyrak> Hey guys, we just launched this new thing on openhatch.org where we're letting people tell the community how to get involved in specific open source projects
[23:38] <pyrak> here's the page for ubuntu: https://openhatch.org/+projects/Ubuntu
[23:40] <pyrak> we'd love to get some feedback on how this kind of thing could be more useful.  like, are there different questions we should be asking?