[01:02] <lamont> it'd really be nice to be able to read the PDFs my bank sends me without booting windows.
[01:02] <lamont> (write password, null read password)
[01:02]  * lamont wonders which package to file that bug against
[01:05] <Keybuk> evince
[01:07] <Amaranth> Really? I thought it'd be poppler
[01:14] <Keybuk> well, poppler perhaps
[01:14] <Keybuk> I usually start at the top and let them worry about it ;-)
[01:14] <Keybuk> though I think poppler is now libpdf or something
[01:15] <ScottK> lamont: I think okular will handle those.
[01:16] <achiang> lamont: send me your bank statements, i'll read them to you. ;)
[01:20] <RAOF> evince in Maverick grew the ability to read my bank statements, which was nice :)
[01:34] <lamont> ScottK: I'd prefer not to install the world of kde just to see it.. I'd rather libpdf got smart enough to open null-password files
[01:34] <lamont> achiang: heh
[01:35] <ScottK> lamont: It should be somewhat less than the whole world these days.  Isn't that still better than having to use Windows.
[01:35] <ScottK> lamont: It's just kdelibs and the base runtime.  None of the workspace components needed.
[01:36] <lamont> 9 upgraded, 64 newly installed, 0 to remove and 221 not upgraded.
[01:36] <lamont> Need to get 56.0MB of archives.
[01:36] <lamont> which tells me it's time for a dist-upgrade
[01:37] <lamont> I'd be happy enough to just know which packages I need to downgrade to hardy-versions, since I think libpdf or whatever just didn't believe in passwords back then, or something like that
[01:38] <lamont> Keybuk: so is libpdf the right place to file the bug?
[01:39] <Keybuk> errr
[01:39] <Keybuk> I really don't know
[01:39] <Keybuk> I find that application authors are much more helpful if you misfile a bug on them, than library authors
[01:39] <Keybuk> a bug filed on a library tends to stay there ;-)
[01:40] <lamont> ah, good point
[01:40] <lamont> though epdfview (libpoppler based) has the same issue.
[01:40] <lamont> I'll toss it at evince
[03:14] <dugger5688> I'm looking to create an indicator applet, anyone know a good tutorial?
[03:26] <kklimonda> dugger5688: I don't think there is a good (or any) tutorial, you should just read source of applications that use it
[03:34] <dugger5688> kklimonda: That's what I ended up doing, thanks.
[03:37] <mgunes> dugger5688, these might be of help: https://wiki.ubuntu.com/MeetingLogs/devweek1001/AppsOnThePannel , https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Technical%20Resources
[03:43] <persia> ajmitch, Hey.  Do you have a bit of time to talk about ARB/-extras and how this affects the support team?
[03:45] <pwnguin> woa
[03:45] <pwnguin> another dugger
[03:47] <ajmitch> persia: alright
[03:48] <persia> ajmitch, So, if I'm reading stuff correctly, if there is a bug, there is an expectation that the author will fix it, and arbitrary developers won't be able to upload changes.  Is that correct?
[03:49] <ajmitch> at the moment I'm unclear on the permissions surrounding extras.u.c
[03:49] <wgrant> It's the ~a-r-b PPA.
[03:49] <persia> Right now !extras is an alias to !repos, which doesn't mention extras.u.c at all, and I think we'd do well to advise the support teams of what level of support we can offer, and how they can request it, etc.
[03:49] <ajmitch> wgrant: right, I wasn't sure if that PPA was just a staging area or if extras was being exposed as another pocket
[03:50] <wgrant> ajmitch: It's synced from the PPA and resigned.
[03:50] <persia> pocket copy from the PPA to somewhere else or not isn't really important: mirror implementation detail :)
[03:50] <wgrant> This makes the set of extremely dangerous Launchpad users quite a lot larger :(
[03:51] <persia> How so?  Isn't the ~a-r-b PPA restricted to ~a-r-b members?  That's only four new people to trust.
[03:51] <persia> (although they are subject to less peer-review than usual)
[03:51] <ajmitch> persia: to be honest, I was expecting to have a little bit of time to discuss implementation specifics on the list before the process was announced :)
[03:52] <wgrant> persia: ~a-r-b isn't just the ARB.
[03:52] <wgrant> It has a few others as well.
[03:52]  * persia digs at LP
[03:52] <ajmitch> https://edge.launchpad.net/~app-review-board/+members
[03:54] <persia> Right, so untrusted folk are tremolux, wendar, jono, and fagan, with special danger from tremolux, and jono, and expanded permissions for mvo.
[03:54] <persia> Given that mvo basically controls how we install software anyway, I'm not sure that it's really expanded permission there.
[03:55] <persia> So just tremolux, wendar, jono.
[03:56] <persia> Anyway, that's a separate can of worms than the one I wanted to review today :)
[03:56] <ajmitch> ideally it'd be owned by the TB
[03:56] <ajmitch> right, the issue was of bugfixes
[03:56] <ion> Couldn’t there have just been an “extras” component alongside main, restricted, universe and multiverse, with a similar process to them (with -proposed and all) etc?
[03:56] <persia> So if it is the ~a-r-b PPA, then I'm fairly confident that ~ubuntu-dev can't support it.
[03:57] <persia> ion, No, for complicated reasons having to do with Release and Packages files.
[03:57] <ajmitch> why I was wondering if it was a separate pocket was whether the packages will even show in launchpad to be able to file bugs against them
[03:57] <persia> wgrant, Do you know if Malone will allow bugs to be filed?
[03:57]  * freeflying 
[04:03] <persia> ajmitch, Whilst we wait, I was thinking we might adjust !extras to be "extras.ubuntu.com contains new software made available after the formal release.  This software is unsupported by the Ubuntu team, but the original authors offer some support."
[04:03] <persia> Does that wording seem acceptable to you?
[04:03] <ajmitch> that seems reasonable
[04:04] <persia> OK.  I'll request that change, and let the meme seep through the various channels by which the support team collect information :)
[04:05] <persia> Err, rather "extras.ubuntu.com is an additional !repo that contains..."
[04:06] <TheMuso> g/c
[04:06] <ScottK> persia: It's not just unsupported.  It's not part of Ubuntu.
[04:06] <persia> ScottK, You have better alternative text?
[04:08] <kklimonda> repo's url is misleading :/
[04:08] <wgrant> I don't understand why it's under ubuntu.com
[04:08]  * ajmitch would love to stay & discuss that, but has a bus to catch in 5 minutes :P
[04:08] <ScottK>  "extras.ubuntu.com is an external repository for new software made available after the Ubuntu release.  This repository is not part of the Ubuntu distribution and the software is completely unsupported by the Ubuntu team, but the original authors may offer some support."
[04:08] <wgrant> persia: To LP it's just another PPA.
[04:08] <wgrant> persia: It's not like partner.
[04:08] <ScottK> persia: ^^^
[04:08] <persia> wgrant, So no bugs.  Thanks.
[04:08] <persia> ajmitch, Does ScottK's suggestion also work for you?
[04:09] <ScottK> persia: But you can make a project with the same name that can get bugs.
[04:09] <kklimonda> ScottK: Is "completely" really necessary?
[04:09] <ScottK> persia: See ~kubuntu-ppa and /kubuntu-ppa for an example.
[04:09] <ScottK> kklimonda: Yes.
[04:09] <persia> ScottK, Right, but not using the recommended bug reporting mechanisms (e.g. ubuntu-bug, apport, etc.)
[04:09] <wgrant> kklimonda: Universe is also unsupported.
[04:09] <ScottK> persia: Of course not.  Those are recommended for Ubuntu and this is not part of Ubuntu.
[04:09] <kklimonda> ScottK: I mean, are people going to get confused if we leave this word out.
[04:09] <wgrant> kklimonda: So it needs to be made clear that extras are even less supported.
[04:09] <persia> wgrant, For some value of "unsupported"
[04:10]  * persia will be filing a blueprint about that any day now
[04:10] <wgrant> persia: Yes, but it's billed as unsupported.
[04:10] <persia> I know.  I just wish that it wasn't, or that what was billed as "supported" had a well-defined support group.
[04:10] <ScottK> kklimonda: Here's what is said about Universe in sources.list: software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu team.
[04:10] <ScottK> This is less supported than that.
[04:11] <persia> Considerably.  Lots of folk support lots of parts of universe.
[04:11] <kklimonda> ScottK: whoa, I haven't seen that :)
[04:11] <persia> Some folk release flavours based on healthy chunks of universe.
[04:11] <wgrant> Who decided it would go under extras.ubuntu.com?
[04:11] <wgrant> That's asking for trouble.
[04:11] <persia> wgrant, opaque
[04:11] <ScottK> wgrant: Probably rickspencer3.
[04:11] <wgrant> Yay.
[04:11] <ScottK> wgrant: It's all been pointed out multiple times, but they are doing it anyway.
[04:11] <wgrant> I know.
[04:12] <wgrant> I just hoped that some new knowledge might have come to light.
[04:12] <persia> All the more reason to ensure the support team understands: we can best avoid confusion by prepping the first line to give good answers.
[04:12] <ScottK> I don't think there's much actual knowledge involved.
[04:13] <wgrant> As well as giving an incorrect image, it also grants unvetted people access to my machine.
[04:13] <wgrant> Previously it would need someone who had been interrogated by the DMB.
[04:13] <persia> Only four of them, and in a way that can be avoided.
[04:14] <wgrant> There are members on the ARB who are not ~ubuntu-dev.
[04:14] <persia> Right.  jono, wendar, fagan, and tremolux
[04:14] <dmb> i don't interrogate anyone :(
[04:14] <persia> dmb, But we, on the DMB, do.  Capitalisation is important.
[04:14] <ScottK> dmb: You are a dmd, but not the DMB.
[04:14] <dmb> :)
[04:15] <persia> ajmitch, So, can I use ScottK's version, or do you want me to proceed with mine?  (I like ScottK's better)
[04:17] <kklimonda> ScottK: do you know whether there have been arguments for not doing it through -backports? Is it to make it easier for.. random developers to get their software into Ubuntu?
[04:17]  * persia would also accept a nod from stgraber, mvo, or statik
[04:17] <kklimonda> I just don't quite understand how does it help us to deliver good software..
[04:17] <ScottK> kklimonda: It's all been discussed.  They've decided to do it the way they are doing it.  The community input is not particularly relevant.
[04:17] <ScottK> kklimonda: It doesn't.
[04:18] <ScottK> It lets Canonical make a marketing point about Ubuntu being great for app developers.  The technical reality doesn't seem to be particularly important.
[04:18] <wgrant> ScottK: It's not been discussed.
[04:18] <wgrant> Discussion was not allowed.
[04:18] <wgrant> Or was ignored.
[04:19] <ScottK> wgrant: No.  It was discussed at UDS-M.
[04:19]  * persia didn't want to bring up all the potential things about extras.ubuntu.com: just to set some expectations for the support team
[04:19] <kklimonda> I'm not fond of entire "opportunistic development" idea and now this..
[04:19] <ScottK> It was "too hard".  Implementing a whole new pocket was easier.
[04:22] <ScottK> kklimonda: I think opportunistic development is a great thing to support since a LOT of that kind of work goes on inside companies, but that doesn't translate at all into the arb stuff.
[04:23] <persia> A lot of that work goes on outside companies too, resulting in nifty cool things.
[04:30] <stgraber> persia: I'm fine with both yours and ScottK's versions. The "external" bit is going to be quite unclear for a lot of people I'm guessing as it's going to be on .ubuntu.com but I don't really have any better suggestion.
[04:30] <stgraber> (sorry, took me a while to read the backlog)
[04:31] <ScottK> stgraber: I'd like it better if it were on canonical.com (it would be clearer), but not much we can do about that.
[04:31] <wgrant> Maybe we can get it fixed for Natty.
[04:32] <kklimonda> ScottK: persia: but those cool things created outside of companies are often buggy or.. really simple. I haven't seen anything cool myself other than various scripts which are more of hacks -- in a good way -- then applications. Or maybe I'm just afraid that we'll create environment for tinkerers.. which isn't actually that bad.. but I feel like it misses the spot, especially when people blog
[04:32] <kklimonda> about new indicators which are against guidelines created by Canonical designers. But then I may be prejudiced - "opportunistic" has a really negative meaning in Polish.
[04:33] <ScottK> kklimonda: When it's good, it's about it being easy to solve a small local problem.  We should be in favor of that.
[04:33] <ScottK> Converting that into applications that are suitable for general use is a lot of work.
[04:33] <ScottK> Nominally it's an order of magnitude harder (See Fred Brooks, The Mythical Man-Month).
[04:34] <ScottK> That's where the confusion is.
[04:34] <jono> persia, I am not on the ARB, to be clear
[04:35] <wgrant> jono: Hm, but you're in ~a-r-b...
[04:35] <ScottK> jono: But you're on the LP team, so you have whatever accesses it has.
[04:35] <stgraber> ScottK: well, canonical.com would feel weird too as it's not a canonical-only archive as partner is for example, but I'd certainly like to see that evolve into something more like the archive, where the ARB would act as archive admin (looking at the queue, accepting new packages, ...) and having the other ubuntu-dev be able to upload updates as usual. That'd also mean that bug could be reported as for any other packages (ideally, LP would m
[04:35] <kklimonda> ScottK: every time I see this title I read it "The Mythical Man-Moth" ;)
[04:36] <wgrant> stgraber: You got cut off.
[04:36] <wgrant> stgraber: But that sounds like -backports.
[04:36] <highvoltage> jono: ah, it says that you are on https://launchpad.net/~app-review-board/+members but I guess it's just because you're meant to administer it then?
[04:36] <jono> highvoltage, yep
[04:36] <ScottK> stgraber: Unfortunately many of the things one needs to know to be do archive admin work aren't in what they ask for for ARB members.
[04:37] <jono> I just set up the team, that's all
[04:37] <jono> I am not eligible to assess apps
[04:37] <ScottK> jono: But the secuirty footprint is the same is if you were.
[04:37] <wgrant> I don't too much care about the ARB making bad decisions.
[04:37] <YokoZar> ScottK: I want to eliminate the spring package duplication  (spring-engine needs to be a dummy that installs spring).  Can I just upload a new spring package providing the dummy or do I need to first file a task to remove spring-engine?
[04:37] <jono> ScottK, security footprint?
[04:37] <stgraber> wgrant: "(ideally, LP would make it clear that it's on "extra" and not supported in any way)" I guess that's the missing part ;)
[04:37] <ScottK> YokoZar: Go ahead and then file a bug asking for removal of the old source.
[04:37] <wgrant> I care about the fact that compromise of their browser results in compromise of every Ubuntu machine on the planet.
[04:38] <ScottK> jono: If someone gets your LP cookie, they can do the same stuff any arb member can do.
[04:38] <jono> ScottK, is this something you are seriously worried about? I think I can maintain my security :-)
[04:38] <wgrant> jono: I don't think anyone can. I have had LP admin cookies on multiple occasions.
[04:38] <wgrant> People make mistakes.
[04:38] <ScottK> jono: Security is about minimizing risk and removing it where it's not necessary.
[04:39] <wgrant> The fewer people can make fatally large ones, the better.
[04:39] <jono> ScottK, right, but what is the worst that could happen? they can post to the group - there is no upload access from the arb group
[04:39] <wgrant> jono: Er...
[04:39] <wgrant> jono: They own the PPA.
[04:40] <wgrant> http://extras.ubuntu.com/ubuntu/dists/maverick/Release
[04:40] <jono> erk, wise point :-)
[04:40] <jono> lol
[04:40] <wgrant> extras.ubuntu.com is that PPA, resigned.
[04:40] <jono> what would you recommend I do to mitigate the security risk?
[04:40] <jono> leave the team?
[04:40] <wgrant> I don't know.
[04:40] <ScottK> Turn over the team to the tech board, probably.
[04:40] <wgrant> It needs to be discussed with people.
[04:40] <jono> well I am happy to take appropriate steps
[04:40] <wgrant> And not just rushed through without consulting anybody.
[04:40] <wgrant> srsly.
[04:40] <jono> ScottK, seems entirely reasonable
[04:41] <jono> maybe I can hand it to the TB and they can discuss appropriate actions
[04:41] <ScottK> If any of them get compromised, we're already screwed, so this doesn't make it worse.
[04:42] <jono> ScottK, if you have a better suggestion I am happy to hear it
[04:42] <highvoltage> jono: the whole ARB thing is a serious blow to the quality of ubuntu process, stgraber's suggestion makes a lot of sense
[04:42] <ScottK> No, I think that's the best thing, but I'd discuss it with them first.
[04:42] <jono> highvoltage, what was stgraber's suggestion?
[04:42] <wgrant> highvoltage: Who needs input from the development community? Silly.
[04:43] <jono> wow, it is frosty in here
[04:43] <highvoltage> jono: scroll up a bit to the part about 23:37 < stgraber> ScottK: well, canonical.com would feel weird too as it's not a canonical-only archive as partner is for example, but I'd certainly like to see that evolve into something more
[04:43] <jono> remember this process is experimental and we are going to discuss this at UDS
[04:43] <jono> and if required adjust and refine where required
[04:43] <persia> jono, If you don't want to be on the team, there's a way to be owner of the team, and not a member, but still admin.  I don't know the details of setting that up, but it's why I can't upload to most of main.
[04:43] <jono> I was merely asked to put together the process, which I did
[04:43] <highvoltage> jono: what is more frosty? good feeback from people who care? or canonical saying they're going to implement something really bad and they don't care what anyone has to say about it?
[04:43] <persia> jono, This doesn't make the risk much lower, but a little bit.
[04:43] <jono> persia, ahhh thanks for the input, I will investigate this
[04:44] <jono> highvoltage, I was referring to the general tone in here, it just feels rather frosty
[04:44]  * highvoltage hands jono a cup of hot chocolate
[04:44] <jono> lol, thanks :-)
[04:45] <persia> jono, Note that you still need to preserve your keys: I'm not core-dev, but my LP credentials are at least as useful to an attacker as any core-devs.  Yours will soon become considerable (getting your LP password means having root on millions of machines)
[04:45] <ScottK> jono: The whole ARB thing does seem to have been implemented in a manner that was pretty impervious to community feedback.
[04:45] <jono> I am not denying that things can be improved in the process, absolutely, and we should have a throrough assessment at UDS
[04:45] <jono> ScottK, I disagree
[04:45] <ScottK> I'm not suprised.
[04:45] <jono> ScottK, I believe that community feedback has been accomodated, but the outcome is not what you would prefer
[04:45] <persia> So, can we dispute specific technical issues?
[04:45] <jono> ScottK, I am fully aware of your unhappiness and concern with the ARB
[04:46] <wgrant> So we are opening up new holes on people's machines... before we do the assessement.
[04:46] <ScottK> jono: I'm not the only one.
[04:46] <wgrant> Awesomeness.
[04:46] <persia> There's been some process issues, but I think we'd do better to fix it than to go over what happened badly so far.
[04:46] <jono> ScottK, agreed, but there are also others who welcome the process
[04:46] <jono> persia, I think UDS is the perfect venue to bring all concerns
[04:46] <jono> persia, agreed
[04:46] <persia> jono, I think it's important not to conflate people who want it to be clearer and easier to add apps post-release with people who like a specific process.
[04:46] <ScottK> jono: Why?  Last UDS it wasn't so perfect.  Why will this one be different?
[04:47] <jono> persia, agreed
[04:47] <ScottK> jono: I agree with the goal, I just think this is a very poor way to achieve it.
[04:47] <jono> ScottK, because we can try the process, assess it's success, and review it at UDS
[04:47] <jono> ScottK, I know this, we have already discussed this
[04:47] <jono> I am not wanting to deafen you, but I am not sure why we should have the conversation again
[04:47] <ScottK> Absent appropriate technical underpinnings, the process can't succeed.
[04:47] <jono> I think we are clear on each other's points
[04:48] <ScottK> Certainly.
[04:48] <jono> ScottK, I think your feedback and a solid review at UDS will be very valuable
[04:48] <ScottK> We'll see.
[04:48] <jono> and as I made clear in the discussions, my sole resonsibility was to put together an assessment board, I am not qualified to provide input on the technical implementation
[04:49] <wgrant> Forcing feedback to occur after it's all already implemented seems a little odd.
[04:49] <ScottK> I'm aware of that.
[04:49] <jono> if you disagree with the governance, then that is up to me, but it sounds like your primary concern is the technical approach
[04:49] <ScottK> jono: Don't get confused with me being upset about the structure as a whole and me blaming it all on you, I don't.  I know what you were trying to do.
[04:49] <jono> personally I think the sandboxing approach you mentioned on the phone, ScottK, makes great sense
[04:50] <ScottK> It's the only way.
[04:50] <highvoltage> ScottK: jono doesn't seem to understand the problems (or doesn't want to)
[04:50] <jono> ScottK, I know, and I respect your honestly and balance
[04:50] <jono> highvoltage, what don't I understand?
[04:50] <ScottK> highvoltage: I think it's mostly just not in the part of the initiative that's his problem.
[04:50] <jono> ScottK, yeah, again, with the caveat that I am not the best qualified on the technical approach, I agree that a sandbox seems the best approach and safe
[04:50] <ScottK> jono: My biggest problem with the process is that absent that appropriate technical basis, it's horribly premature.
[04:50] <persia> jono, I think folks have issues with both, on three points: 1) that the technical critiques and alternate model discussed at UDS (and afterwards) did not appear to be considered, 2) That the body of approvers is not restricted to the already trusted ~ubuntu-dev, and 3) That the process development was relatively opaque, even to members of the new board.
[04:51] <highvoltage> jono: 23:47 < jono> ScottK, I believe that community feedback has been accomodated, but the outcome is not what you would prefer
[04:51] <highvoltage> jono: that sentence tells me that you haven't really been listening
[04:51] <jono> persia, on the latter point, I was entirely guilty
[04:51] <persia> jono, I don't claim this is the place and time to discuss it, but I think it's important to separate the concerns in order to avoid pointless arguments blocking real progress.
[04:51] <jono> the process was developed in the open (wiki, with the TB etc), but I did a terrible job of involving ubuntu-devel
[04:52] <jono> highvoltage, how does this infer that I have not been listening?
[04:52] <jono> highvoltage, just because the eventuall decision was not in line with some opinion on ubuntu-devel does not mean I wasnt listening
[04:52] <persia> jono, Always feel free to lean on me if you're unsure how to involve development folks in something.  I can't promise people will like it, but I can promise you'll get feedback and discussion.
[04:52] <jono> highvoltage, also, as I have made clear, I am not involved in the technical implementation
[04:53] <jono> highvoltage, and I apologized fully about not involving ubuntu-devel enough
[04:53] <highvoltage> jono: because you think that it's just about prefered outcome. it's not, it's that people care about ubuntu and want to make it better, and this process isn't doing that
[04:53] <jono> highvoltage, hence, I believe I did listen in the area of *my* responsibility, but you should not judge me based on the responsibility of the technical process
[04:53] <highvoltage> jono: yay plausable deniability.
[04:53] <jono> persia, I always respect and value your opinions and experience, thanks for the offer
[04:53] <persia> highvoltage, Don't kill the messenger: jono didn't have choice about some large parts of this (as I interpret backscroll)
[04:54] <jono> persia, again, I really could have done a better job with the process development
[04:54] <highvoltage> persia: ok
[04:54] <highvoltage> jono: sorry if I come across too hard
[04:54] <jono> highvoltage, no worries, pal - I am sorry you are frustrated :-(
[04:54] <persia> highvoltage, Not that I'm telling you not to raise the points, just not to pin it all on one person :)
[04:54] <wgrant> Where are we to give feedback?
[04:54] <jono> highvoltage, yeah, I think your points are better attributed to those who built the technical implementation
[04:55] <wgrant> The ARB doesn't know why it happened like this.
[04:55] <jono> wgrant, what kind of feedback? technical process?
[04:55] <wgrant> jono: Technical issues, process issues...
[04:55] <jono> wgrant, feel free to provide process issues to me
[04:55] <jono> technical issues, Rick Spencer is probably a good person to talk to
[04:55] <wgrant> Discussion on the ML was limited to being told that it was all set in stone.
[04:55] <persia> jono, I suspect that those answers are likely some of the issue: I suspect people would like to hear "The CC" and "The TB".
[04:56] <wgrant> Do the CC or TB have power any more?
[04:56] <jono> wgrant, well, that is not 100% true, nothing was set in stone, but I agree that a largely completed draft was presented to ubuntu-devel as a whole, and I have said, that was a mistake on my part
[04:56] <persia> Some, in some areas, depending.
[04:57] <wgrant> As I see it, Platform will come along and push things, and the relevant governance body might wave them through.
[04:57] <jono> wgrant, why do you assume that?
[04:57] <jono> neither the CC or TB is pushed to approve anything
[04:57] <jono> I can 100% guarentee this
[04:57] <jono> and I would whole-heartedly push back if Canonical tried to force the hand of the CC or TB
[04:58] <wgrant> It was apparently accepted without any discussion with people not directly related to its implementation.
[04:58] <ScottK> jono: That's true, but they are busy people.  They evaluate what is put in front of them.  The analysis of alternatives given to the TB didn't even include using the existing backport pocket as an option that was consdiered.
[04:58] <persia> jono, CC is fairly independent, but also fairly inactive, which is OK, but lots of stuff gets directed to you, rather than to CC, which complicates the picture.  No offense to you, but it weakens the perception of CC as point of contact and point of decision.
[04:58] <jono> wgrant, the TB evaluated the process and made a series of suggestions which were merged in, they then approved the process based on the changes
[04:59] <jono> wgrant, and I have already apologized for not including ubuntu-devel in the discussion, not sure what else you want me to do, I can't change history :-)
[04:59] <persia> Most of TB is privy to data that may not be widely exposed, and under (mild) restrictions: they are unlikely to disagree with certain classes of initiative (many of which are good in the first place).
[04:59] <jono> wgrant, I can assure you I will not make the same mistake again
[05:00] <jono> ScottK, I agree, but I am not sure it is scalable to present alternatives with every proposal to the TB - I do though have faith that if the TB felt an approach had a better technical alternative, they would pick up on it
[05:00] <wgrant> I am disappointed that we have a new, opaque, extremely security-sensitive process.
[05:00] <persia> I firmly believe that the CC and TB are able to control the project if they choose to do so.  I'm not sure that such a choice has always been made in the past.  I'm not convinced that waiting for complaints is not a useful way for the boards to operate, as long as people are making complaints.
[05:00] <wgrant> And we *cannot* fix it.
[05:00] <jono> persia, well things often come to me, but if it affects the charter that the CC are responsible for, I send it to the CC
[05:01] <jono> the CC never ask me to make decisions
[05:01] <jono> but indeed many come to me before the CC, and then I move it to the CC if it needs their attention
[05:01] <persia> jono, I know.  I see that.  Doesn't change the perceptions I hear from folks not as familiar with our governance structures as you and I :)
[05:01] <jono> persia, maybe we need to improve that perception, what do you think we could do to improve it?
[05:01] <ScottK> jono: The wiki page specifically described alternatives that were considered and didn't include the one that to many of us made the most sense.  That's really, in some sense, cooking the books.  I don't blame the tech board a bit.  They can't evaluate information they don't have.
[05:02] <persia> jono, To be clear, I'm not critiquing you.  I think you are a valuable member of our community, an important leader, and do your job well.  That doesn't mean I don't think there are areas for improvement, here and there.
[05:02] <jono> wgrant, i am sorry for your frustration, but we did discuss reviewing the process at UDS, and I think you should express your feedback strongly then
[05:02] <wgrant> jono: ... after the process is implemented.
[05:02] <jono> ScottK, the process I put together didnt outline alternatives
[05:02] <persia> jono, I think that it makes sense to sit down and review all our governance structures, who reports to whom, how, what accountability groups have, what responsibilities groups have, etc.  And make sure it's all in one document somewhere, and point folks there.
[05:03] <persia> jono, I'm hoping the track you lead at UDS will let us start on some of that.
[05:03] <jono> persia, it might be good for us to draw a governance map of how everything fits together and socialize it as a whole
[05:03] <jono> persia, good idea
[05:03] <jono> sorry guys, but I need to run
[05:03] <persia> Have a good night.
[05:04] <wgrant> Night jono.
[05:04] <jono> sorry for the frustration, I hope we can alleviate it soon - again, please feel free to provide feedback to me on the process
[05:04] <jono> biab
[05:05] <ScottK> jono: I know you're just the process guy, but until the technical elements are defined it's impossible to get the process right.
[05:06] <persia> The converse is also true to some degree.  The two are best considered in concert.
[05:06] <jono> ScottK, I am positive we can get the process right
[05:06] <jono> ScottK, I think if you can recommend a strong proposal for a better alternative at UDS, that could be awesome
[05:07] <jono> in my mind, if there is a clearly better technical implementation that does not require significant resources to implement, then it would be bonkers not to consider it
[05:07] <persia> Did anyone ever document the backport-based process we reviewed at UDS last time?
[05:07] <jono> ScottK, maybe you, wgrant and persia could put together a proposal ready for UDS?
[05:08]  * persia would want to see Laney and stefanlsd involved as well, as they were part of the group that argued that process last time.
[05:08] <persia> jono, Anyway, you have somewhere else to be (noted above).  Go.  Come back.
[05:08] <jono> persia, totally
[05:09] <wgrant> We could also unterminate the mailing list discussion, so we can get additional viewpoints...
[05:09] <ScottK> jono: Unless rickspencer3 indicates he's open to do it a different way, I think it would be a waste of time.
[05:09] <jono> I think having a prepared proposal could be awesome for the discussion
[05:09] <jono> ScottK, I know rickspencer3 would be open to better technical solutions that meet the goal
[05:09] <persia> And to follow-up on what initiated this discussion (and thanks to stgraber for the approval)
[05:09] <persia> !extras
[05:09] <ScottK> jono: There precious little evidence of that in the actions to date.
[05:09] <wgrant> persia: Looks reasonable.
[05:09] <jono> ScottK, I think that is a bit harsh
[05:10] <persia> Lets start from the assumption that things can be sorted, and approach our governance bodies if they can't.
[05:10] <ScottK> jono: What changed based on the developer feedback to your call for arb members?
[05:10] <jono> ScottK, rickspencer3 is very open and flexible to the best solution; I don't believe it is "his way or the highway"
[05:10] <persia> Complaining at folks because of corporate affiliation doesn't help maintain our community.
[05:10] <jono> persia, entirely agree
[05:10] <ScottK> That may be, but so far the entire evolution has been remarkably insensitive to outside feedback.
[05:11] <jono> ScottK, as persia says, if you feel there is corruption here, you should raise it with the CC/TB
[05:11] <ScottK> jono: It's not corruption, it's just how Ubuntu works.
[05:12] <jono> ScottK, no it isn't - no one has the right to force their will on people, but people do hav ethe right to be passionate
[05:12] <jono> it sounds like you have a concern that rickspencer3 is forcing his will on people, and if you have evidence to suggest this, it would not be unreasonable to raise this with the CC/TB
[05:13] <ScottK> jono: What's the community process for deciding what apps go in the default Ubunt install?
[05:13] <jono> ScottK, what kind of apps?
[05:13] <ScottK> There isn't one.  Canonical managers basically decide and that's what happens unless there is overwhelming community feedback to the contrary.
[05:13] <nixternal> hey snookies!
[05:13] <highvoltage> ScottK: you file a RFP! :D
[05:14] <maco> so while there's people who know how things work awake and online and such.... if there's a blueprint from four years ago that was never implemented, is it valid to bring it up again for natty?
[05:14] <jono> ScottK, right, but if you are arguing this is the Ubuntu way, why are you complaining if rickspencer3 pushes something through?
[05:14]  * nixternal can't even read what the hell is gooin on in here
[05:14] <ajmitch> nixternal: spirited discussions
[05:14] <ScottK> jono: I didn't say I like it.
[05:14] <jono> ScottK, then change it
[05:14] <highvoltage> maco: yes. that's why blueprints are not deleted
[05:14] <nixternal> ajmitch: i am quite drunk, do is o.....bah
[05:14] <ScottK> But as nixternal pointed out on another channel, I've not drunk sufficiently tonight, so I'll see you all later.
[05:14]  * ajmitch was just catching up on scrollback
[05:15] <maco> ajmitch: i read the first 2/3 of it and gave up
[05:15] <nixternal> i need to be hanging out with jono right now. white castle style!
[05:15] <jono> ScottK, ok
[05:15] <jono> nixternal, let's roll!
[05:15] <ajmitch> nixternal: heh
[05:15] <maco> nixternal: what, you want sliders?
[05:15] <nixternal> hell now!
[05:15] <nixternal> no!
[05:15] <jono> anyway, I best leg it, I need to tidy the house in a sec
[05:15] <nixternal> no sliders; i was out drinking and fighting witht he tea baggers tonight. much fun
[05:15] <ajmitch> jono: I'd just wished we'd had a bit of time to discuss organisational issues before you announced the process, but that's past now
[05:16] <jono> ajmitch, yeah, I apologized for that :-(
[05:16] <nixternal> jono: fyi, we need to talk. have a conference coming up and would like you to be here. next april actually
[05:16]  * ajmitch is still hoping to get some responses back from others on the arb list
[05:16] <jono> nixternal, sweet, let's talk soon
[05:17] <jono> right, I am off, laters all!
[05:17] <nixternal> later
[05:18] <maco> highvoltage: so how would you suggest i bring up this blueprint again? its one requesting a font manager in the default install, which says to me it goes in the default packages session, whenever teh heck that is at uds, but somehow need to make 2 blueprints fit one session or something....
[05:19] <highvoltage> maco: I can't tell you how to best match your blueprints to sessions, but you can add it to the UDS by clicking on "Propose for sprint"
[05:19] <maco> mmk
[05:19] <persia> You probably want to review and clean up the spec to be accurate for natty.
[05:21] <maco> the current spec wiki page for it is a bit funny in the use case section, because as akk pointed out, it looks like the one name that is used for 3 separate use cases is really someone with an inflated idea of their own skill level writing pseudononymousely
[05:22] <persia> Lots of times use cases are things-the-author-wants-to-be-able-to-do
[05:23] <persia> Way-back-when when the other Jane managed a nice spreadsheet for us to review, everyone would look at all the blueprints, and add their own use cases.  We just have too many now.
[05:23] <highvoltage> persia: which may still be valid though
[05:23] <persia> highvoltage, They almost certainly are valid, although perhaps in need of stylistic help.
[05:23]  * highvoltage remembers other Jane's spreadsheet
[05:23] <ajmitch> culling a few blueprints might be useful one day
[05:24] <ajmitch> certain people want to remove blueprints altogether :)
[05:24] <ScottK> maco: Why would we need a font manager when everyone will love the new Ubuntu font?
[05:24] <persia> I'm in favour of either removing blueprints (and adding spec pages to certain bugs) or revamping with mpt's mockups of a total project management system.
[05:25] <persia> ScottK, Because I can't use that font here.  Neither can at least half the population of the world.  Next LTS maybe.
[05:25] <ajmitch> persia: either way, it's an area that sorely needs some love
[05:25] <persia> ajmitch, Totally.
[06:29] <ScottK> jono: re your severed fifth post: Maverick is 10.10, not 10.04.
[06:31] <jono> ScottK, wow, I am an idiot, thanks for the note
[06:31] <jono> fixing now
[06:32] <ScottK> No problem.  Stuff happens.
[06:32] <jono> :-)
[06:40] <pitti> Good morning
[06:40] <pitti> kees: I liked mdeslaur's suggestion to go back to what lucid had, so that it's configurable
[06:41] <pitti> kees: personally I don't want any timeout; I need it so often during the day, and it's quite a long one
[06:41] <pitti> kees: ideally it would be forgotten on suspend
[06:44] <wgrant> Speaking of credentials timing out... is anybody else finding that maverick's seahorse-agent isn't prompting to reuse GPG passphrases?
[06:44] <wgrant> It just does it silently without asking for confirmation :(
[06:48] <jono> morning pitti
[07:12] <wgrant> '/
[09:21] <smb> pitti, Hi Martin, I am (once again) trying to get forward in the task of getting the Lucid proposed kernel to updates. There are a few more verifications done by now. But there are also 5 (including the one already marked) that sound like verification failed. All ALSA quirks which seem to have no effect.
[09:22] <pitti> smb: as long as they just don't fix the bugs, but don't introduce regressions, it's fine; we can just keep them open
[09:22] <pitti> or rather, reopen them after moving to -updates (since that autocloses bugs)
[09:23] <smb> Would this require an additional upload with the bug numbers manually removed? All or at least most of the patches are coming through upstream stable
[09:23] <smb> Ah ok, answers the question
[09:24] <smb> I'd prefer that because generating a new upload is time consuming
[09:25] <smb> pitti, I would set the verification failed tags then and I would write mail to Daniel and David to make them aware. Do you want to be on cc?
[09:25] <pitti> smb: that's fine, I'm already sub'ed to the bugs
[09:26] <pitti> (and we should keep the communication there)
[09:26] <pitti> smb: if you mail them, perhaps CC: the bugs?
[09:26] <smb> Hm, sounds reasonable to document it better
[09:26] <smb> good iddea
[09:26] <smb> will do so
[09:27] <smb> pitti, Just want to avoid you getting scared by lots of bug verifications getting failed
[09:27] <smb> All things seem to be related to the same sort of quirk
[09:28] <smb> And people were able to have to module config parameter to make things working
[11:21] <pitti> tseliot: how does plymouth get told which theme to use? I. e. ubuntu-logo by default?
[11:33] <tseliot> pitti: let me check
[11:34] <pitti> tseliot: the docs talk about a plymouth-set-default-theme program, but we don't seem to ship it
[11:35] <tseliot> pitti: it's set as an alternative
[11:35] <cjwatson> alternatives
[11:35] <tseliot> default.plymouth
[11:35] <pitti> ah, thanks
[11:35] <tseliot> pitti: type: update-alternatives --display default.plymouth
[11:36] <pitti> tseliot: thanks a lot!
[11:36] <tseliot> np
[11:36] <pitti> ah, plymouth-x11 is nice for testing a theme
[11:37] <tseliot> yes, it makes it easier
[11:37] <tseliot> it's what I used when I developed the ubuntu-logo theme
[11:37] <pitti> I see it twice even :)
[11:37] <pitti> a large and a small one; not sure why
[11:37] <pitti> but *shrug*
[11:38] <tseliot> yes, two windows
[11:38] <tseliot> I'm not sure as to why
[11:39] <pitti> tseliot: do you know a way to temporarily override the theme for development? I. e. have it point to ~/devel/my-plymouth-theme?
[11:39] <pitti> or do I just change default.plymouth for that?
[11:40] <tseliot> pitti: you can install a new alternative manually that points to your .plymouth file
[11:40] <pitti> right
[11:40] <pitti> I thought about something like plymouthd --theme=.., but it doesn't seem to exist
[11:41] <pitti> but that's not a biggie, thanks
[11:41] <persia> It was something more like that for lucid, but has since been improved
[11:42] <tseliot> try with: update-alternatives --install /lib/plymouth/themes/default.plymouth default.plymouth /lib/plymouth/themes/$YOUR_THEME/$YOUR_THEME.plymouth 500
[11:42] <tseliot> pitti: ^
[11:42] <pitti> tseliot: right, I'll just temporarily change default.plymouth
[11:42] <tseliot> well, the path depends on when you put your theme
[11:43] <tseliot> pitti: are you working on a new theme?
[11:43] <pitti> tseliot: yes
[11:43] <tseliot> pitti: for ubuntu or some other project (no need for further details in the latter case)?
[11:44] <pitti> an OEM project
[11:44] <tseliot> I suspected that ;)
[11:45] <pitti> don't worry, I won't replace maverick's ubuntu-logo theme with my recent vacation photos :)
[11:45] <ogra> oh, why ?
[11:45] <ogra> are they that bad ?
[11:46] <pitti> no, but everyone would instantly jump on their bike and go tenting
[11:46] <pitti> who fixes maverick then?
[11:46] <ogra> lol
[11:47] <tseliot> hehe
[11:52] <pitti> martin
[11:52] <pitti> bl4tch;
[11:52] <pitti> sudo killall  plymouthd
[11:52] <pitti> bl4tch;
[11:52] <pitti> sudo plymouth --quit
[11:52] <pitti> sudo plymouth --quit
[11:52] <pitti> sudo plymouth --quit
[11:52] <pitti> sudo plymouth --quit
[11:52] <pitti> bl4tch;
[11:53] <Laney> err
[11:59] <soren> pitti: I think you're using the wrong keyboard.
[12:02] <ogra> pitti, and a new sudo password would be good as well now
[12:13] <tseliot> lol
[13:07] <pitti> tseliot: ah, the two-screens are intended to test a two monitor setup (http://brej.org/blog/?p=158)
[13:16] <CountDown> I'm developing a python app targeted to the Ubuntu desktop. Is there a way to configure distutils to add an application launcher menu item to the Ubuntu Applications menu? I'll eventually create a .deb to do this properly, but I"m wondering if there's a distutils way of doing this.
[13:17] <persia> CountDown, Install your .desktop to /usr/share/applications/ : you may also find #ubuntu-app-devel to be a more targeted channel for that class of question.
[13:17] <CountDown> persia: Thanks for both suggestions!
[13:17]  * persia suspects it's in the "Files" section of setup.py or something
[13:18] <CountDown> I know there's a scripts section of setup.py, but I don't see how to specify the path of each script. They seem to go to /usr/local/bin by default.
[13:31] <tseliot> pitti: ah, it makes sense
[13:43] <doko> tkamppeter: hi, is it ok to demote these binary packages for maverick? foomatic-db-gutenprint ijsgutenprint ijsgutenprint-ppds hpijs-ppds
[14:00] <smoser> so, given binary package name and release, is there a way to retrive the source package? the info is in Packages.gz, but is there a way I can do it without all of that ?
[14:01] <smoser> i didn't see anything in rmadison that would allow me to do that.
[14:01] <pitti> smoser: apt-get source packagename?
[14:01] <smoser> yeah, but for anothe rrelease.
[14:01] <pitti> ah, unfortunately the /releasename syntax only works for apt-get install for some reason
[14:01] <smoser> release other than that i'm running.
[14:01]  * pitti looks at mvo
[14:02] <pitti> smoser: what still works is apt-get source packagename=<version>
[14:02] <Chipzz> pitti: can the same version be in 2 different pockets
[14:02] <Chipzz> ?
[14:02] <smoser> so i'd just have to add all repositories to apt for that other release and query that way.
[14:02] <pitti> Chipzz: yes
[14:02] <Chipzz> pitti: like updates and security?
[14:02] <pitti> yes, if it gets copied there (not uploaded)
[14:03] <pitti> we regularly copy -security to -updates, and -proposed to -updates
[14:03] <smoser> (which would be downloading the Packages.gz).  i was just hoping there was some api-ish way to translate.
[14:03] <Chipzz> pitti: but I guess that wouldn't actually matter, since they would be copied :P
[14:03] <pitti> smoser: you could write a small shell wrapper around apt-cache madison, parsing out the pocket, grepping the version number, and apt-get source'ing that
[14:04] <cjwatson> I'm sure it can be done with launchpadlib
[14:04] <smoser> i looked and didn't see any notion of binary package
[14:04] <smoser> there is a source package object
[14:06] <smoser> (i now noticed i was looking at 'Beta' so i will look again at 1.0 an dev)
[14:27] <geser> smoser: unfortunately there is no link from binary_package_publishing_history to the matching SPPH in the LP API
[14:27] <geser> so you have to figure out the source package name for a binary package by other means
[14:28] <smoser> geser, thanks.
[14:32] <geser> smoser: see also bug 597041
[14:32] <smoser> geser, thank you.
[14:34] <smoser> well, it looks like i coudl screen scrape
[14:34] <smoser> https://bugs.launchpad.net/soyuz/+bug/53171
[14:39] <ScottK> smoser: grep-dctrl is probably better.  I'm pretty sure you can get it using that.
[14:40] <smoser> i dont have any control files to grep
[14:40] <smoser> but maybe i'm missing something
[14:45] <doko> slomo: https://launchpad.net/ubuntu/+source/gst-plugins-bad-multiverse0.10/0.10.20-1  are these build failures expected?
[14:52] <slomo> doko: no, something broken in xvid... didrocks debugged it a bit
[14:53] <didrocks> yeah, but I hadn't the time to finish looking at it… it's because of xvid not exporting a thread symbol (running two configure during build, first one set pthread to on, not the second one…)
[15:22] <hallyn> is there a way to see the full changelog of a lp bug?  (i.e. when ppl were subscribed and states and priorities were set)?
[15:23] <nigelb> yep
[15:23] <JFo> hallyn, yes, but the how of it escapes me right now
[15:23] <nigelb> hallyn: on the bottom
[15:23] <hallyn> doh, thanks
[15:23] <JFo> ah, that would be why it escaped me
[15:23] <JFo> :)
[15:45] <nigelb> hallyn: did you upload the debdiff to -proposed?
[15:55] <hallyn> nigelb: i don't think i perms to do that?
[15:55] <nigelb> hallyn: In that case you need to attach a debdiff (or branch) and subscribe sponsors
[15:55] <nigelb> now the step is upload => review => accepted to proposed and testing
[15:55] <hallyn> oh, i thought -sru was in place of -sponsors
[15:56] <nigelb> hallyn: it used to be, but now you upload first and then get sru ack
[15:56] <hallyn> nigelb: until now i've always gotten things sponsored through bzr, never yet with a debdiff
[15:57] <hallyn> so all i do is subscribe sponsors?  (debdiff is pointed to from description)
[15:57] <nigelb> hallyn: hey, brz is fine too!
[15:58] <nigelb> Yep, subscribe sponsors, once its uploaded to proposed, then subscribe -sru (or I think sponsors will do it)
[16:00] <hallyn> nigelb: but, bzr is how i started...
[16:00] <hallyn> or did i pick the wrong group to subscribe to that merge proposal?
[16:01] <nigelb> hallyn: ok, I might be blind :p
[16:01] <nigelb> lemme look at that again
[16:02] <hallyn> nigelb: hm, i never hit 'link to a bug report', maybe that makes a diff?
[16:02] <nigelb> hallyn: I think so.  Did you close from changelog?
[16:03] <nigelb> Like have a (lp: #12345) in changelog
[16:03] <hallyn> nigelb: er, well, i did, but that was in revision 7 of 8
[16:05] <nigelb> hallyn: I see the merge proposal, I guess LP doesn't like it automatically until you click or you do --fixes
[16:05] <nigelb> hallyn: so, the reviewer needs to be changed to ubuntu-sponsors :)
[16:07] <hallyn> nigelb: doh, you know i explicitly remember not expanding the details section, bc i had just seen an email saying the default was changed to, i thought, ubuntu-sponsors.  appraently i misunderstood
[16:07] <hallyn> reviewer changed, thanks
[16:08] <nigelb> great :)
[16:08] <nigelb> hallyn: I would encourage you to poke somone you know who can upload :D
[16:16] <hallyn> nigelb: well do, thanks much!
[16:25] <lamont> so is there a sane reason that gutenprint does "-j 16" on a single core machine?
[16:31] <doko> lamont: cusing build failures?
[16:34] <lamont> doko: I'm cussing that it sets of my monitoring alarms, and is only fractionally different than the buildd just plain dying
[16:34] <doko> lamont, tkamppeter: ok, fixing this
[16:34] <lamont> that massively parallel is going to run much slower than with less parallelism unless you have more than 1 core
[16:34] <lamont> thanks
[16:34] <lamont> 2*NCPU is a perfectly good number for -j
[16:38] <doko> lamont: no, the buildd admin should set the correct value in DEB_BUILD_OPTIONS ;)
[16:47] <lamont> doko: there is no DEB_BUILD_OPTIONS
[16:47] <lamont> this is a buildd
[16:47] <lamont> not a manual operation
[16:48] <doko> lamont: adam once did configure the buildds this way
[16:48] <lamont> it's quite possibly still there then
[16:48] <lamont> that'd be in launchpad-buildd somewhere
[16:51]  * lamont freshens his source tree
[17:14] <pitti> tseliot: (reviewing nvidia) oh, dpkg-trigger also needs --by-package in maintainer scripts?
[17:15] <tseliot> pitti: yes, otherwise it will complain :/
[17:16] <tseliot> pitti: I'm doing the same in fglrx plus some additional work so that fglrx doesn't break with 2.6.36 kernels
[17:16] <pitti> tseliot: ok, thank you
[17:19] <tseliot> np
[17:20] <pitti> cjwatson: (reviewing sysvinit) I don't quite understand why we both make /lib/init/rw a symlink, and then do "for omitdir in /var/run/sendsigs.omit.d /lib/init/rw/sendsigs.omit.d" in the init script; won't that include them twice?
[17:20] <pitti> cjwatson: I don't think it will actually do something wrong, but it seems redundant?
[17:21] <pitti> cjwatson: ah, that's the "just in case" part in changelog?
[17:23] <cjwatson> indeed
[17:23] <cjwatson> pitti: if nothing else, there is one case where it's absolutely needed
[17:23] <cjwatson> pitti: between installing the package and the next reboot :-)
[17:23] <cjwatson> since umountroot comes after sendsigs
[17:24] <pitti> ah, ok
[17:24] <pitti> it could check whether it's a symlink
[17:24] <pitti> but, nitpicking
[17:25] <pitti> TTFN, have a nice weekend everyone!
[17:25] <mvo> you too pitti
[17:31] <cjwatson> hmm, messy ibus-client-clutter build failure
[17:31] <cjwatson> looks like it's upset that /usr/lib/libgdk_pixbuf-2.0.la no longer exists
[17:31] <cjwatson> I wonder if it's just a matter of rebuilding clutter-imcontext
[17:32] <tseliot> cjwatson: can you approve fglrx, please? here's the debdiff: http://pastebin.ubuntu.com/499822/
[17:33] <cjwatson> tseliot: is this the version in the queue?  if so I can review it from there
[17:33] <tseliot> cjwatson: yes, it's the same version
[17:33] <cjwatson> if you give it slightly more than three minutes from upload so that LP catches up :)
[17:34] <tseliot> cjwatson: sorry, I tried to catch you before you're off for the weekend (and before I am too) ;)
[17:39] <cjwatson> tseliot: accepted
[17:40] <tseliot> cjwatson: thanks a lot
[17:44] <tseliot> have a nice weekend everyone
[17:58] <cjwatson> DktrKranz: any opinion on bug 646995?  you're one of the "recent" uploaders
[18:04] <DktrKranz> cjwatson: I agree with you. No uploads since months in Debian already, and IIRC I processed removals for some player rdeps because of the same problems stage currently has.
[18:40] <brutimus> Hi folks.  I just installed the Maverick beta and noticed the installer still tells me about fspot like it's a default app.  A quick search through the installer team's bugs didn't lead me to anything related.
[20:28] <jcastro> ScottK: can you make the specs foundations-n-blah instead of foundations-natty-blah
[20:28] <ScottK> Sure.
[20:28] <jcastro> (I can fix the backport one now since I'm in there)
[20:28] <ScottK> That's the only one I did so far.
[20:28] <jcastro> ok
[20:28] <jcastro> on it
[20:28] <ScottK> Thanks.
[20:29] <ScottK> It would be nice to get some guidance out about the new track structure so people can understand how it's supposed to work.
[20:29] <jcastro> there are appear to be tracks, but also other stuff
[20:29] <ScottK> Right, so one is left a bit uncertain.
[20:29] <jcastro> http://uds.ubuntu.com/tracks/
[20:29] <sladen> or even better, make the 'n' at the front
[20:29] <jcastro> yeah
[20:30] <jcastro> I don't forsee people doing ubuntutheproject-n-whatever
[20:30] <ScottK> Yeah.  I saw that.  Now I'm up from blissfully ignorant to horribly confused.
[20:30] <sladen> so all the specs you need are *together* rather than interminged with the last 3 conferences' worth
[20:30] <sladen> conference-track-what
[20:30] <jcastro> sladen: they're not together
[20:30] <sladen> logical
[20:30] <jcastro> https://blueprints.edge.launchpad.net/sprints/uds-n
[20:31] <sladen> jcastro: yes, that's the problem they're not together.  And that gets carried over to Gobby
[20:31] <jcastro> they look together to me, per track
[20:31] <sladen> jcastro: gobby, gobby, gobby
[20:31] <sladen> jcastro: four conferences' worth of specs all, intermingled
[20:32] <jcastro> but they clean out gobby every UDS
[20:32] <sladen> (!)
[20:32] <sladen> if it crashes ;-)
[20:32] <ScottK> sladen: Last UDS they didn't even manage to have one conference worth of specs in there.
[20:33] <sladen> given that the intent of UDS is to "plan the next cycle", it makes sense for this to go at the front
[20:33] <jcastro> Let's just try to stick to $track-$letter-$title like we always do
[20:33] <sladen> and then to be broken out into tracks
[20:33] <jcastro> keeping in mind someone will always break from it /anyway/
[20:33] <sladen> and then the tracks to be broken out into sessions
[20:34] <jcastro> you don't even need the n in there at all, all the blueprints are targetted towards the right UDS
[20:34] <jcastro> it's people just like to put the animal in the title so they can remember that that's specifically for that cycle
[20:35] <sladen> jcastro: if (eutopia) we get a web page that links to IRC+Wiki+Gobby+everything directly then there won't be any need for people to /think/ and therefore not chance for them to screw up by inventing their own names
[20:35] <jcastro> well, in the schedule there's a link to the icecast stream and the blueprint
[20:36] <sladen> https://bugs.launchpad.net/summit/+bug/579164
[20:36] <jcastro> in my utopia the blueprint page is just an etherpad document. :)
[20:36] <sladen> even better---anything that is a direct link from an auto-generated pre-agreed schema is user-proof
[20:37] <sladen> my current intention (despite an invite otherwise) is to sit this UDS out and do it remotely, so I have interest in perfecting this
[20:38] <jcastro> patches to summit are always gladly accepted
[20:38] <jcastro> keeping in mind we never really designed summit
[20:38] <jcastro> it just is
[20:39] <sladen> mmm, patches...  I have this highlighter bar patch that shows the current position in the timetable (regardless of timezone), ... dating from 2 years ago
[20:40] <jcastro> oh, one of those marcus baine lines?
[20:40] <jcastro> I would kill for that feature. Daviey does a good job reviewing merge proposals if you want to do it
[20:42] <sladen> Daviey: jcastro: http://www.paul.sladen.org/ubuntu/remember-to-rename-this-to-YYYY-mm-dd.diff  (I know it says 'jaunty' in it but...)
[20:45] <sladen> Daviey: above adds a slowly-moving 'timebar' which shows the exact position in the timetable at any time during the conference, regardless of the user's timezone
[20:46] <Daviey> sladen: awesome.... do you fancy making a bzr branch, and proposing a merge?
[20:46] <sladen> Daviey: however, at that time (2008) it wasn't possible to know the timezone of the conference as that wasn't recorded anyway, everything being in localtime
[20:46] <Daviey> sladen: lp:summit
[20:51] <sladen> Daviey: are you happy if I just merge the patch---can you test it?
[20:51] <sladen> Daviey: when the source was first released I spent a while day attempting to install a local copy, and failed
[20:52] <sladen> w/while/whole/
[20:52] <Daviey> sladen: Yeah... i think it should be easier to setup locally now
[20:52] <Daviey> sladen: if you want a pointer, give one of us a ping
[20:55] <sladen> Daviey: what happened to the history?  my previous tree contains only revno1 and revno2, the latter of which is keybuk adding the licence
[20:55] <Laney> cjwatson: Is there anything special I can attach to an os-prober bug to help you? It's not detecting my W7 partition
[20:55] <Daviey> sladen: I think you have the non-free version :/
[20:56] <Daviey> sladen: lp:summit is the devel trunk
[20:56] <sladen> Daviey: this new tree has no common history with that trunk
[20:56] <Daviey> sladen: Yeah... i think you have the version which is "pre opensourced"
[20:57] <sladen> Daviey: no, I have a GPLv3 one (I was the one who get it opened)
[20:58] <Daviey> sladen: Ok.. i don't know.. I really do think you have the version which was redacted.. and later released.
[20:58] <Daviey> other than i don't know
[20:59] <sladen> Daviey: ah, this makes more sense.  What I have is the GPLv3 of schedule.  Not the whole of summit
[20:59] <Daviey> ahh
[21:00] <sladen> Daviey: perhaps it builds/installs more easily with the rest of it ;-)
[21:00] <Daviey> lol
[21:02] <sladen> jcastro: right, after that slight diversion.  Naming.  I know that in the US people write dates in a non-standard order, but is there any reason to (continue to) apply a similar system to the spec naming scheme?
[21:04] <sladen> jcastro: if the heriachy of the conference is  ubuntu->release->tracks->sessions  it makes sense (to me at least) to have that heriachy carried over to the names
[21:05] <sladen> jcastro: I can see the argument if people are intended to stay within one track, but not everyone does that
[21:05] <sladen> jcastro: and with the intentional room-reshuffling there's an intent away from that
[21:06] <jcastro> yeah but the blueprint already has fields for the release, and "ubuntu" is already a given
[21:06] <jcastro> so why clutter every title with the obvious "ubuntu-10.04" or whatever?
[21:14] <sladen> jcastro: I would have no objection to dropping components in order from left-to-right
[21:14] <sladen> jcastro: at the moment it would be equivalent to dropping components 1 and 3, which (hopefully) highlights the current illogical naming
[21:16] <sladen> jcastro: if the release needs to be there for globally unique naming in the global wiki/spec databases, then it might make sense to re-add the release, to the left-hand-side
[21:18] <cjwatson> brutimus: it's been filed on ubiquity-slideshow-ubuntu
[21:19] <brutimus> thanks for the info, cjwatson
[21:19] <tkamppeter> doko, hi
[21:19] <cjwatson> Laney: it's all shell, so putting 'set -x' at the top of relevant scripts and capturing stdout/stderr would be valuable
[21:19] <doko> tkamppeter: see email
[21:20] <Laney> cjwatson: Thanks. I think it may turn out to be PEBCAK though…
[21:20] <Laney> I think the partition has been somehow wiped
[21:21] <tkamppeter> doko, it is about the demotion of the unseeded binary packages. The scenario is as follows. User has only main active as package source. H manually installed ijsgutenprint and foomatic-db-gutenprint and set up a print queue with it. In Maverick we demote these packages. What happens if this user updates to Maverick.
[21:21] <tkamppeter> ?
[21:22] <doko> tkamppeter: I don't know, I didn't test
[21:22] <ScottK> tkamppeter: They get a warning that the packages are no longer supported, IIRC.
[21:23] <tkamppeter> ScottK, but the update of libgutenprint will work (libgutenprint is used by ijsgutenprint)?
[21:24] <tkamppeter> doko, mentioned case is rare as the packages were never seeded and so seeding them now would be absolutely wrong.
[21:26] <Daviey> sladen / jcastro: the lack of a convention is hurting us... We can't process the blueprints to assign them to a track
[21:28] <ScottK> Daviey: I think it's not very clear what will go in what track anyway since they are all different.
[21:29] <sistpoty> tkamppeter: from an apt perspective, these packages will be left on the system as is (i.e. in the state of the last installed version)
[21:29] <Daviey> ScottK: yeah.. kinda odd track names
[21:29] <Daviey> ScottK: Where does the server stuff go?! :)
[21:29] <ScottK> Daviey: It's all cloud now.
[21:30] <ScottK> (thus sort of reinforcing my recent lack of motivation to work on server stuff.
[21:30] <ScottK> )
[21:30] <Daviey> ScottK: Yeah... I wonder if we'll still have a server release in 12.04
[21:31] <ScottK> Eventually I figure someone will decide you need packages to do stuff in your cloud, but who knows when that will come.
[21:33] <jcastro> Daviey: you mean for the automatic scheduling?
[21:33] <jcastro> people can still drag and drop on the schedule
[21:33] <Daviey> jcastro: yeah... but the colours?
[21:34] <Daviey> jcastro: The css'ing colour is based on auto detecting the track.. based on names
[21:34] <jcastro> I dunno man, I didn't rename all the tracks and the colors, I'll bring it up with jono before he pushes out his "go schedule stuff" email and address it then
[21:35] <jcastro> Daviey: that's jorgesque for "It can wait until monday"
[21:35] <jcastro> <-- EOD, have a good weekend folks
[21:37] <Daviey> jcastro: heh
[21:37] <Daviey> have a good weekend
[21:37] <Daviey> (slacker)
[21:38] <ogra_ac> heh
[21:39] <tkamppeter> tahmks, sistpoty, doko, I think you can demote these four packages.
[21:39] <doko> cool, thanks
[21:39] <sistpoty> tkamppeter: I don't know how update-manager deals with that situation though
[22:34] <avi_> does anyone know how to make an interface in glade that accepts user text input?
[23:18] <GeniousAtWork> The Torque update in Maverick destroyed anything located in server_name so none of the nodes can find the server. This is very bad and ive sent an email in re.
[23:19] <GeniousAtWork> to domibel
[23:20] <GeniousAtWork> For the release of maverick, either see to it that this is fixed or backported to the previous version.
[23:21] <GeniousAtWork> Or, well reconfiguring 2000 nodes is possibly not so nice.
[23:25] <GeniousAtWork> "aptitude changelog torque-mom"