[00:43] <RAOF> Hm.  Who was kees pointing at me?  I've got the ping, not the context from backscroll.
[00:51] <ScottK> RAOF: http://paste.ubuntu.com/505382/
[00:54] <RAOF> Ah, ok.  Yeah, we don't really use the video group anymore, and *something* needs to handle setting appropriate permissions on the DRI/whatever kernel device.  Sounds like a job for consolekit, to me - give the active seat access to the hardware.
[00:56] <RAOF> I think the nvidia device is world-writable, for that matter, so having the arm drivers use a world-writable node won't be any worse than nvidia :)
[01:22] <penguin42> yeuch
[02:30] <kees> RAOF: the question was about how the graphics devices get their facl for the current user to use it. (e.g. getfacl /dev/dri/card0) for the case where ARM needs a 3d device for some special graphics driver it uses
[02:31] <kees> RAOF: specifically, ogra was trying to sort it out
[02:31] <RAOF> Ah.  I always assumed that it was consolekit that did the magic there; it seemed to be in-scope.
[02:32] <RAOF> Also, I haven't noticed an example of that magic _failing_, so I haven't investigated too closely :)
[02:53] <james_w> maxb: there are no others now I think. I retried all the others after adding the tags manually, as I believe I fixed the bug that was causing the tags to be missing a while ago.
[02:53] <james_w> maxb: if there are more then we can file a new bug
[06:15] <pitti> Good morning
[06:25] <ion> that
[06:37] <pitti> Riddell: current kubuntu desktops are 1 MB oversized; fixed in the seeds, next dailies will be ~ 696 MB
[06:40] <sladen> pitti: when will the next dailies be?
[06:41] <sladen> (I assume you're doing them manually)
[06:41] <pitti> sladen: 0414 UTC every day
[06:41] <pitti> sorry, 0314
[06:41] <pitti> sladen: no, cron jobs are back on
[06:44] <pitti> mr_pouit: is lp:~xubuntu-dev/ubuntu-seeds/xubuntu.maverick still the correct branch for xubuntu seeds? I added some langpacks on Friday, but current CD still doesn't have them
[06:44] <pitti> cjwatson: ^
[06:45] <pitti> (no error on livefs build logs)
[08:40] <dholbach> good morning
[08:45] <ari-tczew> hello
[09:11] <cjwatson> pitti: that's the correct branch, yes
[09:12] <cjwatson> pitti: the language packs seem to be on the Xubuntu alternate CD
[09:12] <cjwatson> pitti: (you only changed ship)
[09:14] <pitti> cjwatson: erk, silly me; thans
[09:14] <pitti> thanks, too
[09:31] <Wubbbi> Hey guys. I have an issue and this issue I have in the hole time of Ubuntu. But now it is realy getting on my nervs. Evolution is the word! I got a screen resolution of 1028x600 ... A Netbook. And Evolution is not going to fit on my screen. There are may parts of it which are going out of my screen thus I can click on some Icons or buttoms. Is it possible to fix it? Nothing helped yet. Even if I get on Fullscreen mode, it still not fits
[09:31] <Wubbbi> . Anyone can confirm it or even help me. I realy have to work with evolution!
[09:32] <micahg> Wubbbi: bug 645753
[09:32] <Wubbbi> micahg: ok thx. Will this be fixed in Ubuntu 10.10?
[09:32] <micahg> Wubbbi: I can't say for sure, but highly unlikely at this point
[09:34] <Wubbbi> micahg: This is bad. Thus I have to deinstall evolution now and I have to work with Thunderbird. This is not a personal atack but it realy sucks because I realy want to use this programm. Well ok. You cant do anything for it
[09:35] <maxb> james_w: There appear to be 31 current NoSuchTag UDD failures, which is a lot more than mentioned in the latest update of bug 494481. I was thinking of going through some of the ones that don't appear to be caused by improper merging by humans, and listing the tags needing adding and a summary of where they appear to have got lost, if that would be useful?
[09:36] <Wubbbi> Ha! LoL! When I'm going to delete Evolution, it wants me to delete 50% of ubuntu ... -_-
[09:38] <directhex> Wubbbi: deleting evolution-data-server will cause that
[09:38] <directhex> Wubbbi: several evolution libraries are hard to remove independently, as they're sued for things like systemwide contacts, calendaring in the gnome clock, stuff like that
[09:38] <Wubbbi> directhex: I know. But what does it bring for me when I cant use evolution. What do I need data-server for?
[09:39] <directhex> Wubbbi: just the evolution client should be removable, though
[09:40] <Wubbbi> hmmm ... ok data-server still exsist -.- ... Well still I'm not that happy ;)
[09:46] <jibel> mvo, I don't understand bug 631426 . I can only think of an unsynced mirror or what else ? This is the last u-m dist-upgrade untriaged bug.
[09:48] <cjwatson> ari-tczew: I uploaded palo to Debian with that patch the other day, BTW
[09:53] <ari-tczew> cjwatson: yes I saw, thanks :)
[10:00] <lucidfox> didrocks, re: "Just uninstall indicator-appmenu and the fallback for all applications indicator will be the systray."
[10:01] <lucidfox> Shouldn't that be indicator-applet?
[10:01] <didrocks> lucidfox: ooupsssss, you're right. Well, indicator-applet-appmenu to be exact
[10:01] <didrocks> lucidfox: do you have the bug # handy?
[10:02] <lucidfox> wait, isn't appmenu the global menu bar?
[10:02] <lucidfox> Liferea uses the messaging indicator, which is removed (IIRC) by uninstalling indicator-messages
[10:03] <lucidfox> bug #540490
[10:03] <didrocks> lucidfox: right, I'm not really awake today it seems, I was waiting for indicator-applet-application and relying on shell completion, but it's indicator-applet for whatever reason… :)
[10:05] <mvo> jibel:  thanks, let me have a look
[10:06] <didrocks> lucidfox: added a comment. Thanks for the notice :)
[10:58] <YokoZar> can I add a multiverse library to ia32-libs?
[11:00] <cjwatson> no
[11:00] <cjwatson> can the multiverse library be given a lib32xxx package instead?
[11:06] <mvo> jibel: I updated the bugreport, I suspect there is something there that always servers zero files
[11:06] <mvo> jibel: that is the only idea I have about this bug at this point
[11:12] <cjwatson> mvo,jibel: do either of you happen to know what's going on with bug 597017 and its vast number of duplicates?  it looks as if some package management frontend is broken, but I don't know which
[11:14] <cjwatson> perhaps jockey?  but it's hard to tell for sure whether that accounts for all of them
[11:17] <cjwatson> and doesn't seem to account for the current master bug, if nothing else
[11:17] <cjwatson> (in which the root user action appears to be "install chromium-browser-inspector"
[11:17] <cjwatson> )
[11:19] <jibel> cjwatson, no, I haven't been able to find a pattern, sometimes it happens while installing only one package.
[11:20] <cjwatson> it's absolutely not a man-db bug, but I have no idea where to reassign it
[11:21] <jibel> cjwatson, I thought of apt-daemon doing some weird async thing, but it seems to happen with apt too.
[11:21] <cjwatson> man-db is just a canary for package management operations being called in some kind of invalid state
[11:21] <mvo> I have to admit that my suspecion was aptdaemon debconf handling as well
[11:21] <cjwatson> (because it's triggered by practically everything and it uses debconf)
[11:21] <mvo> but if it happens with apt too, then …
[11:25] <jibel> e.g reporter of bug  641023 was using apt-get update and simply upgraded dpkg.
[11:27] <cjwatson> 'apt-get update' won't upgrade any package ...
[11:27] <cjwatson> the thing that did the upgrade wasn't apt-get, it was, as the reporter puts it, "the graphical agent"
[11:27] <jibel> cjwatson, fair enough :)
[11:27] <cjwatson> (whatever that is)
[11:27] <cjwatson> presumably update-manager
[11:31] <jibel> bug 578449, sudo aptitude update && sudo aptitude safe-upgrade -y
[11:31] <jibel> but maybe there was a software-center running in the background.
[11:31] <cjwatson> the thing is that if another package management frontend is running then some other lock should clash
[11:33] <cjwatson> except for the specialised use of debconf during initial OS installation, I can't see how the debconf lock should ever be the first one to clash; there should always be something outside it, like the dpkg lock
[11:34] <jibel> cjwatson, right, I tried that scenario but the dpkg lock is preventing to install the package.
[11:35] <cjwatson> though there doesn't seem to be an apt lock as such apart from the acquire lock, so I suppose races are possible, but I don't get the sense that that's what's going on here
[12:05] <Riddell> mvo: could you comment on bug 653838 ?
[12:06] <shadeslayer> mvo: doesnt extras.ubuntu.com have a signing key?
[12:07] <shadeslayer> W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://extras.ubuntu.com maverick Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 16126D3A3E5C1192
[12:08] <ion> shadeslayer: Upgrade.
[12:08] <shadeslayer> hmm
[12:08] <shadeslayer> ion: ok i see a upgrade for ubuntu-keyring, i guess it sorts out the issue
[12:09] <shadeslayer> ion: also.. what does extras.ubuntu hold?
[12:10] <\sh> the new opportunistic dev apps?
[12:10] <cjwatson> shadeslayer: install ubuntu-extras-keyring, actually
[12:10] <shadeslayer> \sh: and who has upload rights to that repo?
[12:10] <cjwatson> you may have to reinstall it
[12:11] <cjwatson> (there was a bug in live CD generation that meant that installations from the RC live CD didn't have the extras key properly installed)
[12:11] <shadeslayer> yeah i think i have that ^
[12:11] <\sh> shadeslayer: there was/is a long discussion on u-d about that topic...there is an application developer board which reviews those pkgs
[12:11] <mvo> Riddell: looking
[12:12] <shadeslayer> hmm.. im subscribed to that list.... i think
[12:12] <doko> quadrispro: any update on xvidcap?
[12:12] <kklimonda> shadeslayer: extras is for distributing applications that are not part of Ubuntu in any way - they can be dropped in outside of our development cycle, packaged by upstream developers and not as strictly checked
[12:12] <Riddell> mvo: I seem to have broken the update-manager build anyway so I guess it needs another upload as it is.  but I don't know why kbluetooth wouldn't get removed for him since it's not in the archive any more (it gets removed when I've done upgrades)
[12:12] <mvo> Riddell: we can force its removal
[12:12] <mvo> Riddell: I did send you a mail about the build btw
[12:12] <\sh> doko: thx for the sun-java  update :)
[12:13] <shadeslayer> kklimonda: does that mean new KDE releases can go into this repo? like KDE 4.5.2 ?
[12:13] <shadeslayer> Riddell: ^
[12:13] <cjwatson> no
[12:13] <\sh> shadeslayer: no
[12:13] <shadeslayer> ok
[12:13] <kklimonda> shadeslayer: no, it's only for things that are not in archive yet.
[12:13] <\sh> shadeslayer: it's all about apps which are not in ubuntu, it's not allowed to update/upgrade already packaged software in ubuntu...
[12:14] <shadeslayer> ohh....
[12:14] <quadrispro> hi doko! back to work few hours ago, I've fixed some stuff on the Debian-side, now I'm about to have a deeper look at xvidcap
[12:14] <kklimonda> shadeslayer: new KDE should probably be.. backported through -backports ;)
[12:14] <shadeslayer> right...
[12:14] <kklimonda> shadeslayer: I'm not sure if its feasible for such big projects
[12:15] <quadrispro> doko, any idea about the reason it fails to build in the archive? I had success to build it in a cowbuilder chroot :-/
[12:15] <\sh> kklimonda: was the workflow not like this: "upload to a special ppa and when ARB acked this pkg they copy it to the extras archive"?
[12:15] <quadrispro> doko, maybe I miss something?
[12:15] <shadeslayer> i agree ... i just thought that extras was for new stuff as well as stuff that cant be put into archives since they dont justify a SRU
[12:16] <kklimonda> \sh: yes, last time I've heard about it that's how it is supposed to work.
[12:16] <shadeslayer> but extras seems to be exclusively for new apps
[12:21] <mvo> Riddell: I commited the fix for the kbluetooth issue
[12:24] <Riddell> mvo: thanks, I'll fix the build and upload
[12:26] <mvo> thanks Riddell
[12:40] <ricotz> YokoZar, hello, what do you think about updating the packaging of ia32-libs for mesa-dri-experimental? like it is done in xorg-edgers ppa
[12:41] <YokoZar> ricotz: do you mean adding libgl1-mesa-dri-experimental to ia32-libs?
[12:41] <ricotz> YokoZar, like this https://launchpad.net/~xorg-edgers/+archive/ppa/+sourcepub/1310260/+listing-archive-extra
[12:42] <ricotz> YokoZar, so creating a new package including the 32bit galliums files for optional install
[12:42] <YokoZar> ricotz: what's in the new pacakge though?
[12:43] <YokoZar> is it just 32 bit libgl1-mesa-dri-experimental?
[12:43] <ricotz> YokoZar, yes
[12:43] <YokoZar> Then why put it in a separate package and not just add it to the list of crap in ia32-libs?
[12:44] <cjwatson> I'd much rather things be in a separate package when possible
[12:44] <ricotz> YokoZar, so applications like googleearth could run with 3d acceleration on nouveau if the experimental packages are installed
[12:47] <YokoZar> ricotz: it would work if it was part of the same package too, no?
[12:51] <cjwatson> seb128: is anyone looking at bug 651254?
[12:52] <YokoZar> ricotz: looking at the package you linked, all it DOES do is add libgl1-mesa-dri-experimental to ia32-libs and then put it in a separate package
[12:53] <seb128> cjwatson, wasn't that fixed with the update which got in after the rc freeze?
[12:54] <ricotz> YokoZar, it is better to use a separate package which depends on lib-mesa-dri-experimental
[12:55] <tumbleweed> cjwatson: bug 651255
[12:55] <ricotz> YokoZar, adding it directly to ia32-lib might mess up the driver search path of xserver
[12:56] <YokoZar> ricotz: you mean if someone has ia32-libs but doesn't have lib-mesa-dri-experimental?
[12:56] <ricotz> YokoZar, so add this would enable apps like googleearh to benefit of the 3d acceleration
[12:56] <ricotz> YokoZar, yes
[12:56] <YokoZar> why would that happen?
[12:56] <ricotz> YokoZar, because it will search first for the gallium libs
[12:56] <YokoZar> I mean, is X searching in /usr/lib32?
[12:57] <ricotz> X is seaching for ../dri/gallium/. first then .../dri/.
[12:58] <cjwatson> seb128: no idea, all I know is the bug's still open
[12:58] <cjwatson> (and on the ubuntu-10.10 milestone list)
[12:59] <seb128> cjwatson, it's fixed, let me close the bug
[13:02] <YokoZar> ricotz: wouldn't it make sense to have ia32-libs-mesa-dri-experimental install by default when someone installs mesa-dri-experimental and one of these 32 bit packages?
[13:02] <YokoZar> (eg wine/google earth?)
[13:02] <YokoZar> I'm trying to figure out how to do that without pulling in ia32-libs on systems that don't have these 32 bit apps
[13:03] <ricotz> YokoZar, this might be not possible
[13:03] <YokoZar> Right.  But if both were always installed together and X was smart enough to only look for ia32-libs-mesa-dri-experimental when the 64 bit version was also installed, we wouldn't have a problem right?
[13:04] <cjwatson> seb128: thanks
[13:05] <ricotz> YokoZar, i think so
[13:06] <ricotz> YokoZar, but since libmesa-dri-experimental is not supported or installed automatically i think users should also install the 32bit libs manually
[13:07] <YokoZar> maybe libmesa-dri-experimental should recommend ia32-libs-mesa-dri-experimental (on 64 bit)
[13:07]  * quadrispro has to leave
[13:08] <ricotz> YokoZar, yes thins might a solution
[13:08] <cjwatson> siretart: performous is failing to build on powerpc because (as far as I can see) libavcodec isn't built with -fPIC.  Would it be OK if I fixed that?
[13:08] <ricotz> YokoZar, or suggest whatever is the lesser depend
[13:09] <YokoZar> ricotz: recommend will get it pulled in by default
[13:09] <YokoZar> ricotz: which is probably what we want here
[13:10] <ricotz> YokoZar, ok
[13:10] <YokoZar> cjwatson: ~multiverse that wants to be in ia32-libs: https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/643884
[13:10]  * YokoZar wonders why libmotif3 is in multiverse
[13:10] <cjwatson> YokoZar: no can do, sorry.  you'll need a separate package.
[13:11] <cjwatson> universe source needs to be free
[13:11] <YokoZar> cjwatson: right I agree
[13:11] <YokoZar> cjwatson: but you had asked earlier if we could make a separate lib32 type package
[13:12] <cjwatson> sure, that's the simplest fix
[13:12] <cjwatson> assuming it works
[13:13] <cjwatson> siretart: hmm, http://bugs.gentoo.org/show_bug.cgi?id=282390 suggests it's more complicated than that though ...
[13:14] <cjwatson> think I might just remove performous on powerpc
[13:18] <Kano> cjwatson: dont you think you should begin running isohybrid on the iso... it is really a very bad sign that u is not ready for hybrid just because of that - every other current distro handles it, do you think you had not enough time? it worked >1.5y ago...
[13:19] <Kano> for fedora, kanotix and about 1 year ago for suse
[13:22] <doko> siretart: ffmpeg powerpc ping
[13:23] <cjwatson> doko: ... you're not debugging the same thing I was just debugging, are you?
[13:23] <cjwatson> (see above)
[13:23] <doko> ahh
[13:24] <cjwatson> I removed performous on powerpc - fiddling around with -fPIC in ffmpeg six days before release didn't fill me with warm fuzzies
[13:24] <doko> cjwatson: was looking at odin pn powerpc
[13:24] <cjwatson> ah
[13:24] <cjwatson> haven't looked at that
[13:24] <doko> ok, should do the same with odin then
[13:25] <cjwatson> similar complaint about an R_PPC_REL24 relocation being out of range?
[13:25] <doko> yes
[13:25] <doko> but but-imaging recommends it. should we remove it anyway?
[13:25] <cjwatson> not sure.  it was an easy decision with performous because it was a leaf game package
[13:25] <cjwatson> making things uninstallable is a harder one
[13:25] <cjwatson> oh, just a recommends?
[13:26] <doko> but [!powerpc] in recommends doesn't work?
[13:26] <doko> yes
[13:26] <doko> recommends
[13:26] <cjwatson> actually I wouldn't even worry about a recommends
[13:26] <cjwatson> package managers will just ignore those if they're missing
[13:27] <doko> ok
[13:28] <jibel> cjwatson, mvo, I can reproduce the man-db error. The problem is with apt-daemon.
[13:29] <cjwatson> jibel: cool, do you know what the problem is?
[13:29] <jibel> here is the recipe:
[13:29] <jibel> launch s-c
[13:29] <cjwatson> is the debconf proxy locking debconf maybe?
[13:30] <jibel> select a package with a debconf prompt: I picked krb5-admin-server
[13:30] <jibel> install but let the debconf dialog opened.
[13:30] <cjwatson> (shouldn't, though, it uses a throwaway db)
[13:31] <jibel> launch a terminal and install another app that trigger man-db
[13:31] <jibel> I installed ntp with apt.
[13:31] <cjwatson> hm, if you leave the debconf dialog opened, surely the dpkg lock should still be helf
[13:31] <cjwatson> held
[13:31] <cjwatson> it shouldn't be possible to proceed without closing the dialog
[13:32] <mvo> *ick* indeed, the dpkg lock should still be held
[13:32] <jibel> what make the problem more difficult to diagnose is that the package installed from s-c doesn't appear in the logs
[13:33] <mvo> jibel: many thanks for the reproduce instruction, let me try to reproduce now
[13:40] <mvo> jibel: hm, so I see packages installed in term.log, is that not the case for you?
[13:42] <mvo> jibel: *cough* I think I got it - dpkg-preconfigure is the problem
[13:42] <jibel> mvo, after you've finished the installation of the first package. It's not caught in the crash file.
[13:42] <mvo> jibel: it does not lock it seems
[13:49]  * pitti can't help but wondering about bug 652631
[13:49] <pitti> bug 642792, sorry
[13:50] <pitti> am I the only one on earth who thinks that a key labelled "printscr" should act as such without Alt?
[13:50] <seb128> pitti, it does?
[13:51] <seb128> the printscreen takes a screenshot of your screen where alt-printscreen should take one of the active dialog
[13:51] <pitti> seb128: yes, and I never noticed it to behave differently
[13:51] <pitti> seb128: erm, alt+printscr has been sysrq for the last two decades or so
[13:51] <seb128> no
[13:51] <seb128> start a lucid desktop and try it
[13:52] <pitti> that sounds like a bug, though
[13:52] <seb128> well it has been this way since warty
[13:52] <pitti> a sysrq certainly shoudn't trigger a screenshot?
[13:52] <pitti> presumably I didn't notice since in the cases where I need it the OS is too broken to do anything else than reboot..
[13:52] <seb128> well we had that working and sysrq working
[13:52] <pitti> seb128: that would mean that the key does two things?
[13:53] <didrocks> yeah, since warty alt+printscr is to take the screenshot of the current window
[13:53] <seb128> I think we had bugs say that sysrq opens the screenshot dialog yes
[13:53] <pitti> wow; one never stops learning
[13:53] <seb128> but from an user perspective you break an handy feature which worked since warty
[13:53] <seb128> you want to take screenshots of dialog most of the time
[13:53] <pitti> so, is that gnome-settings-daemon then?
[13:54] <seb128> not sure which part handles that keybinding
[13:55] <pitti> I don't get an input event on alt+printscr, so perhaps the kernel is intercepting it now
[13:55] <pitti> sorry, xev doesn't show it; I do get an input event
[13:55] <siretart> doko: hi
[13:56] <doko> siretart: see above, some thing for powerpc libavcodec and ffmpeg
[13:57] <didrocks> pitti: that is what is reported and we discussed on Friday. I think the guess of a kernel change comes from there
[13:57] <siretart> from the bug: "As far as I understand it, the ppc problem is not because shared libs have to be pic but because relocations are too "big" when loaded from some libraries (ffplay/ffmpeg seems to work and load the same library)."
[13:57] <siretart> from the gentoo bug
[13:57] <siretart> a similar (toolchain) bug can be seen on ia64, btw
[13:58] <mvo> jibel: I prepare a upload now, many thanks again
[13:58] <siretart> see debian bug #598952
[14:00] <siretart> cjwatson: regarding re-compiling with pic: if you want to do that, I'd suggest to patch the configure script, it has a hardcoded list of architecture that require -fPIC.
[14:00] <cjwatson> siretart: I saw, but I decided to take a different approach for the problem I was working on (performous)
[14:00] <siretart> cjwatson: upstream strongly advises against that because of performace impact
[14:00] <jibel> mvo, thanks to you, that was a quick fix.
[14:01] <cjwatson> siretart: indeed, applications that do not start at all are much faster than ones that do
[14:02] <siretart> cjwatson: does ffplay work for you?
[14:02] <cjwatson> siretart: for me?  I'm not actually using powerpc, I'm hunting down NBS
[14:03] <siretart> according to the gentoo bug, I understand that this doesn't affect all applications. in particular, ffplay/ffmpeg seem to work, but not gst-ffmpeg
[14:03] <cjwatson> AFAIK doko is doing the same
[14:03] <siretart> I see
[14:03] <cjwatson> packages that fail to build tend to have something of an effect on archive consistency
[14:03] <cjwatson> which is important as we approach release
[14:05] <siretart> well, we have a fast workaround (enabling PIC) that has performance impact but unbreaks gst-ffmpeg but also causes performance issues. under these circumstanced, I'd tend to agree to go the quick fix
[14:07] <tkamppeter> pitti, hi
[14:08] <cjwatson> I think we're just removing the powerpc binaries for the packages that fail to build on powerpc, for now
[14:09] <pitti> hello tkamppeter
[14:11] <tkamppeter> pitti, can you have a look at bug 653470, bug 653515, and 653585, there seems to be an interference between the upstartification of CUPS and systems with CJK languages.
[14:11] <tkamppeter> bug 653585
[14:12] <james_w> maxb: oh, not in main, sorry for the confusion. That would be great.
[14:24] <maxb> james_w: np, will do
[14:28] <doko> bdrung: do you work on the audacious plugin build failures?
[14:32] <doko> cjwatson: did you already remove performous-tools on powerpc?
[14:32] <cjwatson> yes
[14:43] <cjwatson> mvo: BTW, did you notice bug 653200?
[15:04] <jibel> pitti, could you publish screen 4.0.3-14ubuntu1.2 (bug 574773) during your next round of sru. The bug number is not in the changelog and is not shown on the pending sru list.
[15:06] <pitti> jibel: ah, doing now; thanks!
[15:06] <jibel> pitti, cool, thank you.
[15:07] <raphink> Keybuk: could you have a look at the new patch on mountall (bug 654545) please?
[15:13] <tkamppeter> pitti, did you see my message?
[15:13] <pitti> tkamppeter: yes, I'll have a look later on
[15:14] <pitti> tkamppeter: I looked at the first dpkg log and didn't see an obvious error message related to cups, so I'll loko at the dups
[15:30] <pitti> tkamppeter: replied with requests for further info
[15:32] <jibel> cjwatson, I've updated bug 653134 with new info. If I replace the grub.cfg from the failed upgrade with the one from a maverick install on the exact same system then ubuntu in wubi boots fine.
[15:32] <jibel> cjwatson, both cfg files are attached to the report.
[15:33] <mvo> cjwatson: re 653200> I'm working on that now
[15:33] <ricotz> siretart, hello, i think there is a problem with a dependency of libswscale-dev which depends on libswscale0 | libswscale-extra-1, libswscale-extra-1 is not available ffmpeg-extra creates libswscale-extra-0
[15:33] <mvo> cjwatson: thanks for the reminder :)
[15:34] <cjwatson> jibel: hm, I'd have said that the one from the install was the broken one
[15:34] <cjwatson> if you had me look at those outside the context of this bug
[15:35] <cjwatson> guess it has something to do with module loading not being available in wubildr
[15:37] <jibel> well, I'm logged in now. I guess it's working
[15:39] <cjwatson> jibel: did you comment out 'insmod gfxterm' by hand?
[15:40] <jibel> cjwatson, yes
[15:40] <cjwatson> oh, that was in the old file
[15:41] <cjwatson> jibel: could you put the old configuration back, apply http://paste.ubuntu.com/505772/ to /usr/share/lupin-support/grub-mkimage, and run 'sudo grub-install /dev/sda' (the /dev/sda bit doesn't matter in the Wubi case)
[15:41] <cjwatson> ?
[15:43] <jibel> okay
[15:44] <cjwatson> having trouble seeing why any of this would *crash* grub, but this is worth a shot ...
[15:44] <cjwatson> (BTW, if that works, then as a control it would be good to unapply that patch and try grub-install again, to make sure that still breaks)
[15:45] <jibel> cjwatson, I also noticed that when you upgrade the files c:\ubuntu\winboot\wubildr and wubildr-bootstrap.cfg are not there but they exist when performing a fresh install.
[15:45] <siretart> ricotz: didn't I already fix that one? if not, yeah, you're totally right
[15:46] <seb128> hum, bug #654395
[15:46] <seb128> does anybody has a clue if that's a plymouth or gdm issue?
[15:47] <ricotz> siretart, seems not to be fixed then ;)
[15:47] <cjwatson> jibel: wubildr-bootstrap.cfg is an artifact
[15:48] <cjwatson> in the "temporary file" sense
[15:48] <seb128> hum, seems similar to bug #532984
[15:49] <cjwatson> jibel: afaik c:\ubuntu\winboot\wubildr is not used after initial installation
[15:49] <seiflotfy> hey guys
[15:49] <seiflotfy> a question
[15:49] <seiflotfy> my partition fials to mount to /home
[15:49] <seiflotfy> its a btrfs
[15:50] <seiflotfy> is there a way to fix t
[15:59] <doko> azeem: opensync ping. you suggested to build barry without the opensync plugin, and to remove any other opensync plugin form maverick. is this still the way to go?
[16:02] <jibel> cjwatson, grub rescue> I think I broke my main grub :/  booting from livecd
[16:03]  * barry wonders who had the gall to name a package after him without a hefty royalty check... :)
[16:29] <jibel> cjwatson, the system is back from the void.  Your patch is working.
[16:30] <jibel> cjwatson, now breaking the system again to make sure that is still breaks.
[16:34] <cjwatson> jibel: sounds promising ...
[16:37] <jibel> cjwatson: \o/ my system is broken again. That works!
[16:37] <cjwatson> hooray!
[16:37] <cjwatson> guesswork for the win.
[16:39] <Haegin> hi, who is the best person to talk to to request a patch being added to the kernel or does that have to happen upstream?
[16:39] <cjwatson> #ubuntu-kernel
[16:39] <cjwatson> (and in general, most patches should go upstream)
[16:40] <Haegin> cjwatson: ta
[19:54] <alex88__> hi, i'm trying netbook edition...i've removed firefox and installed chromium..how can i add it to the launchers on the left?
[19:55] <alex88__> well..with unity
[19:59] <alex88__> mmhh...i've read to run the app and right-click-> keep in launcher..but i haven't that option
[19:59] <alex88__> !netbook
[20:29] <cjwatson> siretart: so, just to confirm, since doko has uploaded a candidate change for this for maverick: are you OK with enabling PIC in ffmpeg on powerpc?
[21:02] <mar> how do I report bug for stopped-clock
[21:03] <mar> i mean clock in my gnome-panel is stuck at 21:38:30 now :)
[21:11] <penguin42> mar: Did you wind it ?
[21:12] <penguin42> mar: Not on this channel; use ubuntu-bug followed by the package name, discussion on #ubuntu-bugs
[21:39] <siretart> cjwatson: well, I don't have powerpc hardware myself, so I need to rely on people that actually use that hardware
[21:40] <siretart> cjwatson: if you say as powerpc user that enabling PIC has more worth than the performance it brings, then sure!
[22:06] <YokoZar> why does apt-get source jasper give me jasper-initramfs but apt-get source libjasper1 give me jasper source package
[22:07] <YokoZar> ah hah...because the jasper binary is in the jasper-initramfs package but not the jasper source package
[22:07] <YokoZar> weird
[22:14] <ScottK> YokoZar: I think that's got to be a bug.  I've seen it before.  I think if you feed it a source package name that's what it should get unless it doesn't exist.
[22:20] <YokoZar> ScottK: at the moment it's preventing me from adding libjasper1 to ia32-libs
[22:20] <ScottK> Interesting.
[22:21] <YokoZar> ScottK: because it gets double parsed essentially
[22:22] <YokoZar> so would we say this is a bug in apt-get or a bug in the binary package that's named for someone else's source package (seems like something we should have a policy about)
[22:23] <ScottK> I think it's a bug in apt-get, or at best a use case that isn't considered by the current design.
[22:24] <ScottK> Try apt-get source kdebase for similar fun.
[22:33] <slangasek> pitti: do you have a standard rune for use of dpkg --path-exclude, --path-include somewhere?
[22:47] <cjwatson> siretart: as I said earlier today, I'm not a powerpc user any more
[22:47] <cjwatson> siretart: doko and I are trying to fix up the archive, in ways that don't necessarily in all cases require actually using the architectures that have problems
[22:48] <cjwatson> YokoZar: use the --only-source option
[22:49] <cjwatson> siretart: so I'm only a "user" in the sense that I care about the fact that some source packages don't build on powerpc due to this; I'm unable to evaluate the performance tradeoff
[23:26] <YokoZar> cjwatson: brilliant, thanks.  (hooray for the switch not in the man page :) )
[23:26] <cjwatson> it is in the man page
[23:26] <cjwatson> http://paste.ubuntu.com/506034/
[23:38] <hallyn> kees: jdstrand: jinkeys
[23:38] <hallyn> kees: jdstrand: i didn't realize i'd be allowed to push to qa-regression-testing
[23:39] <hallyn> uh, so.  yeah, feel free to revert.  i don't know how open it's intended to be
[23:40]  * hallyn had hoped to push to his own branch, and request a merge to get some review...
[23:40] <kees> heh
[23:41] <kees> hallyn: no worries. you must be part of the qa group. :)
[23:43] <SpamapS> hrm.. bzr-buildpackage is killing me at the moment..
[23:43] <SpamapS> bzr: ERROR: [Errno 2] No such file or directory: '/home/clint/pkg/pipemeter/bzr/pipemeter/packaging/debian/emacsen-startup.ex'
[23:43] <SpamapS> file exists
[23:43] <SpamapS> so.. wtf?
[23:43] <SpamapS> not to mention, bzr status does not mention it. :-P
[23:44] <kees> hallyn: I would probably have used optparser instead of the manual argv stuff, but if it works, that's all good.
[23:44] <kees> hallyn: nice to replace a TODO with real code :)
[23:44] <hallyn> SpamapS: so it needs to be in the bzr manifest?
[23:44] <hallyn> kees: yeah, i wanted to, but the python test framework steals my argvs!
[23:45] <kees> hehe
[23:46] <hallyn> kees: maybe my hack will offend jdstrand enough that he'll do it the right way :)
[23:46] <kees> hahah
[23:47] <SpamapS> weird
[23:47] <SpamapS> had to re-add all the .ex files I manually rm'd
[23:48] <hallyn> SpamapS: maybe it would've been happy if you'd "bzr remove"d them?
[23:48] <SpamapS> hallyn: indeed, but usually bzr is just fine and dandy with added files disappearing
[23:49] <hallyn> SpamapS: i've got a bzr bd q too  :)  i've got my own little package which only exists in bzr.  i want to build the package.  but it complains there is no .orig.tgz file.  help?
[23:50] <SpamapS> hallyn: --native would be a sneaky way out of that
[23:50] <hallyn> i'm fine with sneaky
[23:50] <SpamapS> hallyn: its less sneaky if this is something that is only really useful on ubuntu/debian systems. ;)
[23:50] <cjwatson> [BUILDDEB]\nnative = True
[23:51] <cjwatson> in .bzr-builddeb/default.conf
[23:51] <cjwatson> see /usr/share/doc/bzr-builddeb/README.gz
[23:52] <hallyn> cjwatson: i've done that
[23:53] <hallyn> SpamapS: --native doesn't help
[23:53] <cjwatson> ask james_w then
[23:54] <hallyn> maybe i want to use export-upstream
[23:54] <hallyn> cjwatson: ok, thanks.  the README looks helpful1
[23:54] <hallyn> !
[23:55] <SpamapS> hallyn: what do you mean it doesn't help though?
[23:55] <hallyn> whee, it's doin gsomething
[23:55] <SpamapS> hallyn: --native and what cjwatson said are the same thing ;)
[23:55] <SpamapS> except his is permanent
[23:55] <hallyn> SpamapS: it still said make: *** No rule to make target `get-orig-source'.  Stop.
[23:56] <hallyn> SpamapS: the export-upstream was what i needed.  now i'm down to my crap debian/control contents :)
[23:56] <SpamapS> hallyn: yeah, get-orig-source should be skipped with --native tho.. or maybe I'm forgetting something else
[23:57] <hallyn> that'd have been nice, since my export-upstream path is just my bzr pull path :)
[23:58] <hallyn> SpamapS: and it even started out saying "Building using working tree
[23:58] <SpamapS> hallyn: I have a package here that is native.. there's no orig source and it never asks for one.. hmm