[01:17] <dylan-m> Anyone here happen to know if the software-center reviews / ratings feature is going to land for Lucid?
[01:17] <nigelb> dylan-m: It is.  http://www.jonobacon.org/2010/02/23/awesome-ubuntu-software-center-updates/
[01:18] <wgrant> The spec was updated a few days ago in ways which indicate that it has been deferred.
[01:18] <wgrant> And I would hope that it had been deferred, at this point.
[01:18] <nigelb> oh
[01:19] <dylan-m> wgrant, nigelb: Indeed, I suspected that since the rating is using popcon data now :)
[01:19] <dylan-m> Oh well, it was a bit gutsy for one cycle; lots of web infrastructure changes to make!
[01:19] <wgrant> Yes.
[01:19] <wgrant> And they were left far too late, as usual :/
[01:21] <dylan-m> Makes my job easier :P
[01:21] <wgrant> I might also point out that it looks like the Django backend is proprietary, so it's reasonable to complain :)
[01:21] <dylan-m> (well, slightly. The slideshow probably wouldn't be mentioning reviews anyway, but somebody is bound to think it should).
[01:36] <lamont> ScottK: do we want 2.6.6 in a karmic ppa somewhere?
[01:56] <ScottK> lamont: I didn't look to see what's fixed in it.  It seems to me that Postfix is another package we ought to get TB permission to push through -updates.
[01:57] <lamont> building it to toss in my ppa now, feel free to push on the TB - I'll even chime in with a +1
[01:57] <ScottK> OK.
[01:58]  * ScottK piles it on the TODO.
[02:06] <lamont> tree pushing to alioth, package uploaded to ~lamont/+ppa/karmic
[03:16] <lamont> so I realize it's all supposed to be magically intuitive and all that, but why do the window titles in the bottom panel have some random one lighter than the others?
[03:17] <ion> Hm. I don’t have such behavior. Lighter exactly how? The text or the background?
[03:18] <persia> lamont: Does it appear to have any relation to focus?
[03:21] <lamont> persia: yes
[03:22] <ion> Desktops have been highlighting the focused window in the window list one way or another at least since Windows 95. :-P
[03:23] <persia> lamont: In that case, I presume the answer is "To let users know which application they have focused right now"
[03:23] <persia> ion: Depends on which window list.  The one I use doesn't do that (even in lucid)
[03:23] <ScottK> It's funny how many systems insist on helping me solve this confusion that I really almost never seem to have.
[03:25] <lamont> people.debian.org/~lamont/focus.png
[03:25] <lamont> which reminds me that I should fix it so I can actually put things on people.u.c again
[03:27] <lamont> there.  that wasn't hard
[03:29] <lamont> except for the part where I need to do one more thing tomorrow
[03:39] <lamont> persia: intersting.  zombies have taken over
[03:42] <persia> It always ends up that way when the Trioxin containment fails.
[03:43] <lamont> wgrant: bug 543162
[03:44] <lamont> wgrant: you want anything more than the bug has before I stab them?
[03:44] <wgrant> lamont: Let's have a look.
[03:45] <lamont> wgrant: so from that, what we have is lp-buildd with a zombie scan-for-processes child, and no love.
[03:45] <wgrant> lamont: Can you attach the lp-buildd log for the whole build, just in case?
[03:45] <lamont> I'm firmly confident that a restart of lp-buildd will fix that immediate instance of the issue, beyond that, pain
[03:45] <wgrant> Right.
[03:46] <lamont> build-1550990-3166975  build-1569828-3204910 <-- pretty sure one of those just doesn't belong
[03:47] <wgrant> Those are in /home/buildd?
[03:47] <lamont> yeah
[03:47] <wgrant> Sounds like something died a while ago, then...
[03:47] <lamont> wgrant: and I'm gonna skip attaching 450KB of log
[03:48] <Pretto> how can i file a bug about lucid updates messing with .desktop files?
[03:48] <wgrant> Pretto: You mean adding X-Ubuntu-Gettext-Domain at the top of a few of them?
[03:48] <Pretto> wgrant: yes
[03:48] <wgrant> Pretto: That's been fixed for around 18 hours now.
[03:48] <Pretto> wgrant: a lot of them
[03:49] <Pretto> wgrant: ok so :D
[03:50] <persia> Pretto: If you've a case where it's still that way after an update, please let us know, but we believe everything is fixed except gedit/armel
[03:50] <Pretto> persia: updated today afternoon, got a lot of .desktop messes, actually i have a list of them
[03:51] <wgrant> Pretto: Can you pastebin the list?
[03:51] <persia> Pretto: Please put the list at paste.ubuntu.com : if there's something else needs doing, we can do it.
[03:51] <Pretto> wgrant: of course
[03:51] <lamont> builds slapped, building again
[03:51] <wgrant> lamont: Thanks.
[03:52] <persia> lamont: gedit/likewise-open?  Thank you.
[03:53] <lamont> yep
[03:54] <lamont> hrm... getting a screenshot of the crap colors in firefox will be problematic
[03:54] <lamont> well, until I log into the machine from another machine to trigger the screen snapshot
[03:55] <lamont> persia: mind you, there's no guarantee that they won't die in exactly the same way when they finish building this time
[03:56] <persia> Well, I can hope :)
[03:56] <lamont> heh
[03:56]  * lamont wanders off.  g'night
[03:57] <wgrant> Night.
[03:58] <Pretto> wgrant: persia http://paste.ubuntu.com/398581/
[03:58] <persia> Pretto: Which mirror are you using?
[03:59] <Pretto> persia: main server
[03:59] <persia> archive.ubuntu.com?
[03:59] <wgrant> Those have all been fixed on archive.ubuntu.com for almost a day now.
[04:00] <persia> Well, 18 hours, but yeah.
[04:00] <wgrant> Right, something along those lines.
[04:00] <Pretto>  persia yes
[04:00] <wgrant> Pretto: Which version of gnome-panel do you have installed?
[04:01] <persia> Pretto: Please try updating again.
[04:02] <Pretto> wgrant: gnome 2.29.92
[04:02] <wgrant> Pretto: I need the bit at the end as well.
[04:02] <wgrant> -0ubuntuSOMETHING
[04:02] <Pretto> persia: 19.6 mb of updates
[04:02] <wgrant> Pretto: Install them and see if they help.
[04:04] <Pretto> wgrant: gnome 2.29.92-0ubuntu1, but i will update now
[04:05] <Pretto> by the way, i have fixed the .desktop manually
[04:06] <lamont> do-release-upgrade -d
[04:06] <lamont> Checking for a new ubuntu release
[04:06] <lamont> No new release found
[04:06] <lamont> ok.  what did I break underneath myself?
[04:06] <persia> lamont: Are you perhaps already running lucid?
[04:06] <wgrant> Or trying to upgrade Hardy->Lucid?
[04:07] <lamont> hardy->lucid
[04:07] <lamont> is that not yet believed in?
[04:07] <wgrant> Lucid's not in meta-release-lts yet
[04:07] <Pretto> got some parsing errors after update
[04:07] <wgrant> Even as a development release.
[04:08] <lamont> well, given that it works on a different machine, I'm inclined to believe that I'm just being cruel to the underlying host
[04:08] <wgrant> Hm, maybe meta-release* aren't important any more.
[04:08] <lamont> meta-release-lts gets fetched from changelogs.u.c still, yes?
[04:08] <wgrant> Oh, oops, wrong file.
[04:08] <wgrant> Yes.
[04:08] <wgrant> OK, so Lucid is there.
[04:08] <wgrant> So it should just work.
[04:09] <lamont> yeah - blocked port.
[04:10] <Pretto> wgrant: where can i find update log?
[04:10] <wgrant> Pretto: /var/log/dpkg.log might help.
[04:11] <wgrant> Pretto: Which versions of gnome-panel and nautilus do you have now?
[04:12] <Pretto> wgrant: gnome panel Version: 1:2.29.92.1-0ubuntu3
[04:12] <wgrant> Pretto: That's the fixed version of that one.
[04:13] <Pretto> wgrant: but i saw parsing errors on .desktop files, but i cant see it on dpkg log
[04:13] <persia> that would be ~/.xsession-errors
[04:14] <lamont> amusing. running hardy: Prompt=lts --> lucid upgrade.  Prompt=normal --> intrepid upgrade
[04:14] <Pretto> persia: no, i meant inside the xterm windows in the update-manager
[04:14] <lamont> somehow that feels worthy of a bug
[04:14] <persia> lamont: That's intentional.
[04:14] <lamont> srsly?
[04:15] <persia> lamont: Yes.  It looks odd here, but e.g. intrepid -> lucid isn't well tested, and may explode.
[04:15] <persia> lamont: So, "normal" always goes to the next 18-month release.
[04:15] <lamont> persia: not only untested, but expected to explode
[04:15] <persia> No.
[04:16] <persia> It might work.  We don't actually know.
[04:16] <lamont> OTOH, if I'm running d-r-u, I'd want to at least get asked "oh, hey, which of these 2 supported upgrade targets do you want to use"
[04:16] <persia> But we also don't know that it *will* explode.
[04:16] <lamont> otherwise the less-attentive will wind up doing 4 upgrades in the place of 1
[04:16] <persia> lamont: Now that's worth a bug.
[04:16] <wgrant> Well, if you had upgrades set to 'normal', you would have been prompted to upgrade 18 months ago.
[04:17] <ScottK> There won't be two supported upgrades.
[04:17] <ScottK> Intrepid goes out of support ~ the same time Lucid becomes supported
[04:17] <lamont> wgrant: and I might have said 'no'
[04:17] <lamont> ScottK: probably.  there isn't actually any guarantee of that
[04:18] <ScottK> lamont: True, but based on the promised support timeframes.
[04:18] <lamont> and hopefully d-r-u DTRT when intrepid goes *poof* and then someone runs it (notice and use old-releases.u.c)
[04:18] <lamont> we've overdelivered in the past
[04:18] <lamont> not always, and sometimes by < 10 days, but...
[04:20] <persia> I'm fairly certain d-r-u doesn't know about old-releases.u.c : I strongly suspect it needs a patch to Ubuntu.info.in in python-apt
[04:23] <lamont> persia: you lie
[04:24] <lamont> mvo added code for us when, um, hardy came out
[04:24] <lamont> because of the fun manual "fire up another terminal and edit sources.list" step for doing edgy->F->G->hardy
[04:24] <persia> Well, I know python-apt doesn't know about it.  If it's special-cased in do-release-upgrade, that's not entirely bad.
[04:25] <lamont> it's in the tarballs that get downloaded
[04:25] <lamont> d-r-u just parses the metafiles
[04:25] <lamont> afaik
[04:25] <lamont> anyway, bug 543165 filed, targeted at beta-2 just because
[04:26] <persia> Well, d-r-u does a bit more than just parse, but yeah, if it's in the tarfiles, all is good.
[04:26] <Pretto> persia: do you know the command to parse .desktop files? i mean to test all of them
[04:26] <Pretto> something like a rebuild
[04:27] <persia> There's validate-desktop-file for validation.
[04:27] <persia> They are built as part of package build: there is no rebuild tool.
[04:27] <wgrant> desktop-file-validate, actually.
[04:27] <persia> RIght.
[04:29] <persia> Although it doesn't get used that much.  I don't install a bunch of stuff, and have 62 validation errors of one sort or another.
[04:33] <Pretto> too much work, i need to do it file by file
[04:40] <Pretto> persia: it's ok now
[04:41] <Pretto> the parser is oli reporting errors like this
[04:41] <Pretto> only*
[04:41] <Pretto>  key "StartupNotify" in group "Desktop Entry" contains invalid characters, boolean values must be "false" or "true"
[05:05]  * abhinav is away: Abhinav|away
[05:06]  * abhinav is away: breakfast
[05:06] <persia> !away > abhinav
[06:04] <kees> crimsun: sorry, I massively wrecked that changelog english.  :(  It should read "scripts/init-top/framebuffer: create "fbmode" argument to allow forcing a mode via fb /sys interfaces, for framebuffers that do not correctly handle setting mode via module options."
[06:13] <lamont> kees: the new version is english?
[06:13] <lamont> :-D
[06:24] <kees> lamont: heh.
[06:27] <pda-> php5-cli in lucid seems to have lost its readline support.. anybody know anything about this, or know where I should look?
[06:34] <micahg> pda-: you can check with the server team in #ubuntu-server
[06:34] <pda-> ok cheers
[06:56] <pda-> (re php5-cli/readline: I've submitted LP bug #543212)
[07:06] <MTecknology> Is there any reason our default umask is 022 instead of say 0027?
[07:07] <wgrant> MTecknology: https://blueprints.edge.launchpad.net/ubuntu/+spec/umask-to-0002 is relevant, but goes the other way.
[07:08] <MTecknology> wgrant: WTF!?
[07:08] <MTecknology> please for god sake tell me that's not actually going to make it into main...
[07:09] <wgrant> Why not?
[07:09] <wgrant> It has a good rationale.
[07:10] <MTecknology> can that at least be a different default for server installs?
[07:10]  * wgrant is not involved with it at all.
[07:10] <MTecknology> the 022 seems very lax
[07:11] <MTecknology> giving g+rwx seems like it's right next to permission 777 which is -brilliant-
[07:12] <wgrant> But the default group contains only the user.
[07:12] <MTecknology> i suppose, what about the thought of 007?
[07:13] <MTecknology> would that sound reasonablY?
[07:14] <MTecknology> wgrant: thanks for the link
[12:57] <iulian> asac: Hi.  Have you got a couple of minutes to take a look at bug #482890 and say your opinion about it?
[12:59] <iulian> I'm inclined to accept it but I would like to hear your opinion as well.
[13:11] <chrisccoulson> iulian, the current version in the archive doesn't work with 3.6 anyway
[13:12] <chrisccoulson> iulian, we should either sync it or remove it from the archive entirely
[13:13] <chrisccoulson> so i would just accept the sync
[13:56] <iulian> chrisccoulson: OK.
[14:11] <ScottK> iulian: I was going to say ....  Given the plans for Firefox getting continuous updates, I'm more inclined towards removal for such thing.  At some point in the next three years it's sure to be totally broken again.
[14:47] <iulian> ScottK: Hm, alrighty.  Would you like to add a comment saying that?
[14:48] <ScottK> iulian: I didn't put it in the bug, because I really wasn't sure.  You've already given it an ack, so I wouldn't propose that I'd override that.  Feel free to copy/paste into the bug if you think it's worthwhile.
[14:49] <iulian> OK.
[14:51] <chrisccoulson> ScottK - I've been going through the extensions in the archive recently to try and decide what to do with them with the new firefox support model
[14:51] <chrisccoulson> https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/extension-list
[14:51] <chrisccoulson> you're more than welcome to share your opinion on any of those :)
[14:52] <chrisccoulson> but, my preference for most of them is to just remove them
[14:53] <ScottK> chrisccoulson: I don't have expertise to have an opinion on any specific one, generally I think that unless there is some reason to believe they'll be usable for a couple of years of Firefox updates, they should be removed.
[15:02] <chrisccoulson> ScottK - there are some extensions that will be ported to newer Firefox versions in the future, but I think most extensions we have in the archive will break at some point during the life of the release when we roll out a new major firefox version
[15:02] <chrisccoulson> directhex - do you look after beagle?
[15:02] <ScottK> Even the ones that would be ported, the in archive version would still be broken.
[15:03] <directhex> chrisccoulson, to a degree, that degree being "beagle's dead and we can't get it to work against the new gmime"
[15:04] <chrisccoulson> directhex - excellent. if it's dead, would you mind disabling the mozilla extension? (i think it provides one doesn't it?)
[15:04] <Laney> no, it's been ported
[15:04] <Laney> there's just a crash that we haven't/can't debug, so won't upload
[15:05] <directhex> Laney, i guess the moz bit needs porting to ff3.6... i think we should disbale it
[15:05] <Laney> we need to upload to disable evo anyway
[15:05] <chrisccoulson> Laney - the extension will most likely break again during the life of lucid, when new FF versions are introduced...
[15:05] <chrisccoulson> so i'm not sure how we can maintain that
[15:05] <Laney> but the reason we didn't upload isn't because we don't have a reason to, it's because we know it to be crashy :(
[15:05] <chrisccoulson> ah ;)
[15:06] <Laney> it's not even in squeeze atm
[15:08] <Laney> chrisccoulson: I'd advise you to just do it in lucid
[15:09] <Laney> maybe grab from svn and upload that
[15:09] <chrisccoulson> Laney - ok, thanks. i'll do that when i next get the chance
[15:12] <lamont> so... when uxterm is obscured by a terminator window, and then unobscured through a change in workspaces, it does not redraw the obscured portion... which package gets that bug (new to lucid)
[15:19] <persia> lamont: Does this only happen with terminator, or other obstructions as well?
[15:21] <lamont> not xchat, not other uxterms
[15:21] <lamont> not firefox
[15:21] <lamont> bored of checking
[15:22] <lamont> just for the record: PII-233?  slow.
[15:22] <persia> lamont: File against terminator then :)
[15:23] <lamont> terminator maintainer, he say X
[15:23] <lamont> if it's terminator, then it's really libgtk
[15:25] <persia> Perhaps, or perhaps not taking advantage of one of those odd GTK_OPTION_WITH_REALLY_LONG_NAME_THAT_EVERY_APPLICATION_SHOULD_USE_BUT_IS_NOT_DEFAULT_FOR_NO_GOOD_REASON constants
[15:25] <lamont> heh
[15:25] <lamont> kinda like SO_REUSE, eh
[15:26] <lamont> interesting... why did I wind up with grub1 on my upgraded box?  does grub2 not do root-on-lvm-on-raid yet?
[15:26] <persia> I thought it did, but I also thought that there wasn't any automatic grub1->grub2 transition because there are too many corner cases.
[15:26] <asac> iulian: acked too now
[15:27] <lamont> ah.  that may be it - because my PII didn't get it either, and if ever there was a vanila config
[15:28] <persia> SO_REUSE is a short one.  The one that caught my eye recently was gtk_image_menu_item_set_always_show_image (GTK_IMAGE_MENU_ITEM (item_toggle), TRUE)
[15:33] <iulian> asac: Thank you.
[15:56] <lamont> drwxr-xr-x 127 hpojlp lp 8192 2010-03-21 09:55 /etc
[15:56] <lamont> say WUT?
[15:57] <lamont> thanks ubottu
[15:57] <lamont> thanks not
[15:58] <sebner> lamalex: hahaha! xD
[15:58]  * lamont makes a note to see about reproducing that bug
[17:00] <chrisccoulson> would a member of ubuntu-release be able to ACK bug 537900 for me please?
[17:39] <sheldon> hi, i cannot remove some packages from my personal ppa. I recevie this error
[17:39] <sheldon> Unexpected form data
[17:39] <sheldon> Launchpad doesn't understand the form data submitted in this request.
[17:40] <micahg> sheldon: try #launchpad
[17:40] <sheldon> thanks
[17:46] <lamont>  ▒ ┴␊⎼␋°≤ ├␤▒├ ≤⎺┤⎼ ┼␊┬ GRUB 2 ⎽␊├┤⎻ ␋⎽ °┤┼␌├␋⎺┼▒┌ °⎺⎼ ≤⎺┤, ␉␊°⎺⎼␊ ≤⎺┤
[17:46]  * lamont thinks it may be confused
[19:34] <AnAnt> Hello, will an update-alternatives method be provided to change the plymouth theme ?
[20:00] <psusi> can anyone with more knowledge of udev weigh in on the proper fix to this important bug that really needs fixed before lucid ships?  dmraid currently goes into an infinite loop because every time it activates a raid array it deletes the partitions from the underlying disks, which causes another activation
[20:00] <psusi> one way to fix it seems to be to modify the udev rule so that it only activates on add, not change
[20:00] <psusi> another possibility would be to have udev remove the partitions when blkid detects that it is a raid member, rather than having dmraid do it on activation
[20:01] <psusi> and I'm sure there's other ways I have not thought of...
[20:37] <superm1> pitti, i was thinking as an alternative to checking glob(/var/lib/apt/ etc), you could probably instead just check for 'dkms' instead of 'bash'.  most of the drivers enabled via jockey would need DKMS anyhow, so having that on the repository should be a good indicator
[20:45] <jcastro> crimsun: I have a machine that isn't remembering it's volume level in alamixer, I did the alsactl store 0 mention in SoundTroubleshooting, am I looking in the wrong place?
[21:53] <ebroder> Does anybody understand how the openjdk packaging works? I want to try and get a commit from upstream cherry-picked, and I can't figure out how to do it
[21:54] <micahg> if I have a package that FTBFS when it built, but builds fine now, do I need to bump the ubuntu version or can an archive admin respin (It FTBFS on everything except i386)
[21:55] <ebroder> micahg: Whoever uploaded the package has a button they can click to rebuild
[21:55] <wgrant> micahg: Anyone with upload rights can retry it. Which architecture?
[21:55] <wgrant> Er, which package?
[21:55] <micahg> libtunepimp
[21:56] <wgrant> Ah, main. I can't help you there.
[21:56] <micahg> wgrant: that's why I'm in here :)
[21:57] <RAOF> micahg: How's gjs going?  When trying to get a jit-disabled package I found that armel ftbfs even with the jit disabled now, so that's not a winner :(
[21:58] <micahg> RAOF: ok, we'll have to fix it before beta 2 then
[21:58] <micahg> RAOF: I'll see if asac has any quick ideas
[21:59] <micahg> RAOF: can you respin libtunepimp on amd64 for lucid?
[21:59]  * RAOF is also not core-dev
[22:00] <micahg> hmmm
[22:01] <micahg> kubuntu-dev has rights as well if that helps anyone...
[22:04] <cody-somerville> Link?
[22:05] <micahg> cody-somerville: amd64: https://edge.launchpad.net/ubuntu/+source/libtunepimp/0.5.3-7.2ubuntu1/+build/1473412
[22:06] <cody-somerville> micahg, What makes you think a rebuild will fix that issue?
[22:06] <micahg> cody-somerville: I just tried it in pbuilder...I can upload to PPA if you want to see
[22:07] <cody-somerville> Is it a newer version of libtool stuff that makes it build successfully now?
[22:08] <cody-somerville> Anyhow, retried build
[22:09] <micahg> cody-somerville: no idea
[22:09] <micahg> didn't have time to look too much into it
[22:12] <crimsun> jcastro: which release? what is appearing not to remember (e.g., GNOME login? gdm login-ready?)?
[22:22] <micahg> cody-somerville: it built :) can you respin the rest of the arches?
[22:23] <cody-somerville> micahg, aye, done.
[22:23] <micahg> cody-somerville: thank you...that should save some xubuntu people trouble on upgrade :)
[22:52] <jcastro> crimsun: lucid, the "Speaker" slider in alsamixer always reverts to 0
[22:53] <jcastro> crimsun: I can slide it back and then the volume is normal, but it keeps reverting to 0 on reboot/login.
[22:54] <crimsun> jcastro: so the stored gdm volume is 0. Nuke /var/lib/gdm/.pulse*
[23:03] <jcastro> crimsun: ok, anything useful you need from it? It's a regression from karmic so I want to make sure the info goes to the right place
[23:05] <crimsun> jcastro: the files themselves aren't useful; I'll just need to spend time this week working on an upgrade path
[23:05] <crimsun> no idea how that's going to happen, since cansecwest is this week, too
[23:14]  * ebroder sighs
[23:14] <ebroder> Where are the docs on doing merges with bzr again?
[23:16] <xnox> ebroder, wiki.ubuntu.com/DistributedDevelopment
[23:16] <xnox> or something like that
[23:17] <xnox> not sure typing by heart =)
[23:19] <ebroder> Yeah, but I can't find it anywhere in there
[23:20] <ebroder> https://wiki.ubuntu.com/DistributedDevelopment/ClientToolsV1Design is the closest I can find to actually having commands of any the pages /DistributedDevelopment links to, and that one doesn't actually help me
[23:21] <cjwatson> look up a bit
[23:21] <cjwatson> https://wiki.ubuntu.com/DistributedDevelopment/Documentation
[23:22] <cjwatson> which links to https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
[23:22] <ebroder> Aha. That's a very small link on a comparatively long page
[23:27] <ebroder> Hmm...I'm getting http://ubuntu.pastebin.com/HVpFcqri
[23:28] <ebroder> And when I look at debian/control and debian/rules the whole file is just wrapped in conflict markers (i.e. there's nothing detected as common between the two revisions)
[23:28] <cjwatson> 'bzr help remerge' might help
[23:29] <cjwatson> if it works
[23:29] <ebroder> Well...`bzr remerge --merge-type weave` seem to have...done something? Let me look
[23:30] <ebroder> Yeah, it looks like that worked