[13:06] <Cheesehead> Brainstorm Jam begins in four hours
[13:56] <lostson> wish I was gonna be around but got to work
[14:12] <Cheesehead> lostson: We'll miss you.
[14:12] <Cheesehead> Two confirmed gonna-miss-it so far.
[14:13] <Cheesehead> But what do I expect midday of a holiday weekend?
[14:13] <lostson> yeah unfortunately i am on a 12 day run of work and the storm that just ripped through this county didnt help either
[14:14] <Cheesehead> More storms on the way today...
[14:14] <lostson> hopefully not as bad today
[14:16]  * Cheesehead hopes for the largest turnout tomorrow for the IRC Bug Jam at noon CDT
[14:16] <lostson> yeah i wanted to get in on that one bigtime i love doing stuff like that
[14:17] <Cheesehead> You know, if there is interest enough, we can *always* do a second session of these events
[14:17] <Cheesehead> Just propose a time
[14:17] <lostson> thats true
[14:18] <Cheesehead> The way I structure stuff works best with three or more people, since there is a lot of discussion.
[14:20] <Cheesehead> So we need an alternate time, and (ideally) two other participants
[14:27]  * Cheesehead sent an e-mail reminder of the Brainstorm Jam
[14:33] <lostson> just got it
[14:33] <lostson> i will have to read the logs when I get back and catch up tonight after work
[14:47] <lostson> well time to get ready for work hope you all have fun today and get a great turnout!
[14:48] <Cheesehead> lostson: Thanks.
[15:22] <h00k> hi
[15:23] <h00k> I'm on my phone
[15:39] <h00k> Cheesehead, lostson
[15:43] <h00k> hanging out in # ubuntu-locoteams, too
[16:11] <Cheesehead> Brainstorm Triage Jam will begin in this channel at 1700 UTC (1200 CDT). http://loco.ubuntu.com/events/ubuntu-us-wisconsin/1177/detail/
[16:13] <h00k> hiii
[16:13] <h00k> ntop
[16:13] <h00k> bah
[16:13] <Cheesehead> stop ntopping me
[16:13] <h00k> heh
[16:14] <h00k> trying to change topic
[16:14] <h00k> bad idea on mobile
[16:14]  * Cheesehead goes off to load the dishwasher
[16:15] <h00k> Did you see the email I sent?
[16:15] <Cheesehead> The one that said you wouldn't be around?
[16:16] <Cheesehead> The one that said you love your *family* more than a bunch of anonymous internet geeks?
[16:16] <h00k> lol
[16:16] <h00k> yrp!
[16:16] <h00k> yep!
[16:16] <Cheesehead> No. I haven't seen it.
[16:17] <h00k> I
[16:17] <h00k> http://planet.ubuntu.com/
[16:18] <h00k> there we are
[16:18] <h00k> ok. may lose service
[16:18] <h00k> apostle islands :D
[16:19] <h00k> good luck, maybe I'LL be able top attend
[16:24] <Cheesehead> h00k: Thanks. I think we'll hace a good time.
[16:55] <Cheesehead> Brainstorm Triage Jam will begin in this channel in 5 min. http://loco.ubuntu.com/events/ubuntu-us-wisconsin/1177/detail/
[16:56] <Cheesehead> Training session will be in this channel. Non-training triage will be in #ubuntu-brainstorm
[16:56] <yotux> Cheesehead:  Thanks for the info
[17:01] <Cheesehead> Hello, everyone here for the Brainstorm Triage Jam.
[17:01] <Cheesehead> Activity in this channel is logged - you can get the logs at http://irclogs.ubuntu.com/2011/09/03/%23ubuntu-us-wi#t17:00
[17:01] <Cheesehead> Let's see how many participants we have here. Could everyone active in this channel please give a response?
[17:01] <yotux> Here
[17:02] <Cheesehead> Anyone else for the Brainstorm Jam?
[17:02] <crog> I'll come along for the ride
[17:03] <Cheesehead> Welcome abord
[17:03] <Cheesehead> aborad
[17:03] <Cheesehead> ab...you know what i mean
[17:03] <crog> yeah
[17:04] <Cheesehead> Anyone want the long lecure about what Brainstorm is, what it does, and how it helps Ubuntu (dafault =no)
[17:04]  * Cheesehead curses his fumbly fingers
[17:04] <Cheesehead> There are three goals here today:
[17:04] <Cheesehead> 1) Meet new people and have fun
[17:04] <Cheesehead> 2) Learn more about how the various projects/teams/communities work together
[17:04] <Cheesehead> 3) Figure out how the next step for some ideas to improve Ubuntu.
[17:04] <Cheesehead> All abilities are welcome, no experience necessary.
[17:05] <yotux> ok
[17:05] <Cheesehead> yotux: What do you feel your strengths are in Ubuntu?
[17:05] <Cheesehead> (crog, you get the same question next)
[17:06] <yotux> I have send some bug reports,  I try and run alphas,  try and support the corp side of con.
[17:06] <Cheesehead> Wonderful. Crog?
[17:06] <crog> used since about 05 - know my way around package management pretty well
[17:06] <crog> haven't any experience directly with packaging however
[17:07] <Cheesehead> Let's take a look at http://brainstorm.ubuntu.com/idea/26681/
[17:08] <Cheesehead> Give you a moment to read it...
[17:08] <crog> hmmm - I guess I mostly agree w/ Soln 3 -
[17:09] <yotux> I second that
[17:09] <crog> but what I think would really help with this is if a tool could seamlessly manage backups/restores
[17:09] <Cheesehead> Question: Is the problem really a problem at all?
[17:09] <crog> or if there is a way to "try out" a setting first.
[17:10] <crog> Cheesehead: good question
[17:10] <yotux> I think that it is not a problem
[17:10] <yotux> if your are playing in etc files you should already know the dangers
[17:10] <Cheesehead> Perhaps this user hosed an /etc file, and didn't know how to reinstall?
[17:11] <crog> in a typical *nix env - this is setup by an admin for you
[17:11] <Cheesehead> ...the package
[17:11] <yotux> when using the cmd user are always suggested to rename to .bak'
[17:11] <crog> but in a desktop environment - the noob becomes the admin
[17:11] <crog> Whether they have the experience or not.
[17:12] <Cheesehead> If they are new, is it likely they will be playing in /etc?
[17:12] <crog> yotux: yeah - that's the way to do it.  I could envision a gui that does that for you.
[17:12] <crog> Cheesehead: probably no
[17:12] <yotux> when new to a os -- maybe find a mentor before running into cmd?
[17:13] <Cheesehead> If I were in a help forum, I would tell the user to apt-get reinstall the package. That should solve the problem, no?
[17:13] <yotux> Cheesehead:  I don't think etc is the first stop
[17:13] <yotux> Cheesehead:  not
[17:14] <yotux> that command doesn't purge config files does it?
[17:14] <Cheesehead> True, but apt-get purge foo; apt-get install foo should do it.
[17:14] <Cheesehead> Also, to hose an /etc file, wouldn't they need to be abusing sudo?
[17:15] <yotux> Cheesehead: yes
[17:15] <crog> Cheesehead: yes and yes
[17:15] <Cheesehead> This happens a lot in Brainstorm - "somebody else" should write a GUI...
[17:16] <Cheesehead> that replaces a simple command line
[17:16] <crog> Cheesehead: So - we have different ideas, but generally agree this isn't a problem
[17:16] <crog> Cheesehead: there are ways it could be made more noob friendly - but probably not the resources to focus on this right now
[17:16] <Cheesehead> Agreed. I will mark it so a bit later.
[17:17] <crog> Cheesehead: ultimately, what's the goal of our triage?
[17:17] <Cheesehead> Good question...
[17:17] <Cheesehead> If you fellows were noobs, it would be to train you about how Ubuntu works...
[17:17] <Cheesehead> but instead, let me cut-and-paste a better goal:
[17:18] <Cheesehead> HOW YOU ARE HELPING: Some ideas don't belong in Brainstorm. You are helping teach those submitters the correct venue, and teaching them more about Ubuntu.
[17:18] <Cheesehead> You are starting them down the yellow brick road.
[17:18] <Cheesehead> Also, you are contributing to the real ideas that need solutions and comments.
[17:18] <Cheesehead> Finally, you are making the Technical Board's job easier. They shouldn't need to wade through bugs and wishes to find real issues.
[17:18]  * Cheesehead didn't know he could type that fast!
[17:19] <crog> Given this isn't a bug, it's a wish - and "brainstorm" connotes a place to make improvement suggestions - it's probably where I would have thought something like this belonged.
[17:19] <crog> I wouldn't file a bug
[17:19] <crog> I suppose I would try a bit of googling and forums before posting here thought
[17:19] <Cheesehead> I think we agreed it's not a bug...
[17:19] <crog> though
[17:19] <Cheesehead> but it's not really a problem either...
[17:20] <Cheesehead> in this case, the submitter probably can't come up with a valid use case...
[17:20] <Cheesehead> so there's not much for a developer wot work with.
[17:20] <crog> ahhh - good point
[17:20] <yotux> Cheesehead:  To me it came to self accountability
[17:21] <Cheesehead> yotux: Precisely.
[17:21] <Cheesehead> Let's look at a fresh one: http://brainstorm.ubuntu.com/idea/28471/
[17:22] <Cheesehead> One goal of triage is to direct the submitter to the most appropriate venue.
[17:22] <Cheesehead> How are they supposed to know if nobody tells them?
[17:23] <yotux> I think that this would be something to bring up in the art work group?
[17:23] <Cheesehead> Possibly, though they deal with static stuff.
[17:23] <Cheesehead> Fade is more likely a light-dm or compiz issue, I should think.
[17:24] <crog> I guess I'm at a loss with this one...
[17:24] <crog> yeah - I was thinking compiz
[17:24] <yotux> ok
[17:25] <Cheesehead> So, essentailly, 'Go talk to compiz about it'
[17:26] <yotux> Cheesehead: since its already a feature we should not need to create a duplicate feature
[17:26] <Cheesehead> Agreed
[17:26] <yotux> by feature I mean it is something we can already do
[17:27] <Cheesehead> Another reason for them to talk to Compiz, I read this as a refinement of the existing login
[17:27] <Cheesehead> rather than a new feature
[17:27] <yotux> Cheesehead: thanks we are thinking along the same lines
[17:27] <Cheesehead> I must spend a few minutes googling a Compiz point of contact to refer them to...later
[17:28] <Cheesehead> crog, what do you think?
[17:28] <crog> If I didn't know there was a piece of software called "compiz" that handles the visual stuff
[17:28] <crog> And my system didn't already display this behavior
[17:28] <crog> I probalby wouldn't know where to look
[17:28] <crog> So it's back to what you said ont he last one
[17:29] <crog> Its an opportunity to reply and try to educate
[17:29] <yotux> I agree
[17:29] <Cheesehead> Agreed
[17:29] <Cheesehead> http://brainstorm.ubuntu.com/idea/28468/
[17:30] <Cheesehead> I thought this one was interesting
[17:30] <Cheesehead> Streches your brain a bit doesn't it?
[17:30] <crog> I'm not sure I understand - doesn't that require a cell tower or GPS?
[17:31] <crog> Is the person working on a tablet?
[17:31] <Cheesehead> Siderial time merely requires a clock and an ephemeris
[17:32] <Cheesehead> Or algorithms to simulate an ephemeris
[17:32] <Cheesehead> Or...a sundial
[17:33] <yotux> your solution makes sense,  I would say it needs to be updated to work with current software set
[17:33] <crog> I guess I was confusing this (which I don't quite understnd) with a location-based service
[17:34] <yotux> crog:  location base can also you ip addresses
[17:34] <crog> Yeah - you post helps some developer who can pick up the algorithm (already done), and make it work in Unity
[17:35] <yotux> I agress with crog
[17:35] <Cheesehead> Clarification: Sidereal time (solar time) is the time shown by a sundial instead of a clock
[17:35] <yotux> Cheesehead: could / should one refer the submitter to the current package manager of the package?
[17:36] <Cheesehead> Well, would that help the submitter?
[17:36] <yotux> I say yes
[17:36] <Cheesehead> What does the submitter want (in simple terms?)
[17:36] <crog> submitter want's an app
[17:36] <yotux> Cheesehead: he wants a package that exist,  but is not current
[17:37] <crog> current package maintainer may not be insterested in "porting"
[17:37] <Cheesehead> The package is current, just incompatible with his chosen desktop environment
[17:37] <yotux> I am not sure how much unity is be cross ported to XFCE and others
[17:38] <Cheesehead> So, is this an App request, a porting request, or something else?
[17:38] <yotux> I would vote porting
[17:39] <Cheesehead> And is this something the submitter needs to do more legwork on, or is this ready for a developer to tackle?
[17:39] <yotux> Submitter needs to do leg work and possibly make a follow up post
[17:39] <Cheesehead> What kind of legwork?
[17:40] <yotux> I would start by contacting the current package maintainer, see if there is an interest in porting
[17:40] <Cheesehead> That is a good start.
[17:41] <yotux> From there its up to the submitter were he want to take it
[17:41] <Cheesehead> What about extracting the LMT algorithms to a separate lib?
[17:41] <crog> from a dev point of view, that's the most useful
[17:42] <crog> you could incorporate that into other apps, or build your own gui
[17:42] <Cheesehead> I see two approaches, taken together:
[17:42] <yotux> could do this,  but it may be beyond their skill set
[17:42] <Cheesehead> Approach the package maintainer about the posibility of a port or lib-creation
[17:43] <Cheesehead> And approach Unity about the adding the feature if such a port or lib became available
[17:43] <yotux> agreed
[17:44] <Cheesehead> The submitter's role is 100% leadership and cajoling, it seems to me.
[17:45] <yotux> Since it does exist yes I agree
[17:47] <crog> may be off topic - who is the "typical submitter" in brainstorm?
[17:47] <Cheesehead> Great question
[17:47] <Cheesehead> Often a new user.
[17:47] <Cheesehead> But sometimes highly experienced or a developer.
[17:47] <Cheesehead> New users ideas tend toward "create a big new application"
[17:48] <Cheesehead> or "make it more like what I was used to on Win/OSX"
[17:48] <komputes> Hello to all from Montreal
[17:48] <Cheesehead> hey, komputes1
[17:48] <Cheesehead> hey, komputes!
[17:48] <yotux> hello, komputes
[17:48] <Cheesehead> Okay, next one: http://brainstorm.ubuntu.com/idea/28474/
[17:49] <komputes> yotux: sup Nathan
[17:51] <crog> Cheesehead: sorry - it's not loading for me...
[17:51] <Cheesehead> checking...
[17:51] <yotux> Cheesehead:  This is a large and interesting  goal
[17:52] <Cheesehead> works for me. Perhaps the server was briefly busy.
[17:52] <yotux> Cheesehead:   There needs to be allot of legal work for the submitter
[17:53] <Cheesehead> Well, I suspect Canonical and Google would want to hammer out the legal details themselves.
[17:53] <crog> I don' know google docs
[17:53] <yotux> Google, canonical would have to agree to share api resources
[17:53] <Cheesehead> yotux: That's a great comment, though. I hadn't thought of it.
[17:54] <Cheesehead> yotux: Yeah, so there's a contract involved
[17:54] <Cheesehead> Would Google be interested in such a deal?
[17:54] <Cheesehead> What would Google get out of it?
[17:54] <yotux> Google docs is changing API allot,  ubuntu 1 is corp baby (project)
[17:54] <yotux> both services offer storage space for sale
[17:55] <crog> is having them synced without a PC core to the suggestion?
[17:55] <Cheesehead> crog: I read it so.
[17:55] <crog> I'd consider writing some sort of script/app to talk to both services, and put in in cron
[17:55] <Cheesehead> Excellent workaround!
[17:55] <yotux> crog:  they want to have all things synced between servers
[17:56] <yotux> crog:  my read was they don't want to have to sync services with local machine
[17:56] <Cheesehead> Beyond talking to Ubuntu One to convince them to miestone such a feature, is there really anything else the submitter can do?
[17:56] <crog> Ok - so as before - it's hard for a dev to act on this one
[17:57] <yotux> yes agreed
[17:57] <Cheesehead> Since there are some rich comments (legal, API changes, etc),
[17:57] <yotux> I see the only option for submitter is to ask
[17:57] <Cheesehead> I'm tempted to leave this open for a month or so and see what other comments come in
[17:58] <Cheesehead> That's one of the benefits of Brainstorm
[17:59]  * Cheesehead stands up and stretches his brain
[17:59] <Cheesehead> Ah, good. I had a kink in that right frontal lobe.
[17:59] <Cheesehead> Next: http://brainstorm.ubuntu.com/idea/28453/
[18:02] <yotux> This is a OEM type install question
[18:02] <yotux> I have never used this install case but it would fall into that area / Team
[18:03] <Cheesehead> Yes. How does Ubuntu currently handle such?
[18:03] <yotux> When I download the image it installed a lang pack
[18:04] <Cheesehead> This kind of request pops up every year or so
[18:04] <Cheesehead> It's generally a new-user
[18:04] <Cheesehead> 'Make it like it was on Win/OSX'
[18:04] <yotux> Not sure how to configure packages and system with lang pack installed
[18:05] <yotux> It could be refereed to the OEM team but that not our pack.  Submitter needs to ask OEM install team
[18:05] <Cheesehead> Since System76 manages to sell systems with Ubuntu installed, is this really an issue?
[18:05] <yotux> No
[18:05] <Cheesehead> I suspect we don;t know enough about what the user *really* wants
[18:05] <Cheesehead> Is the user really an OEM?
[18:06] <yotux> and if so should he not spend his own resources
[18:06] <crog> Yeah - I was trying to guess what he wanted to do with this.
[18:06] <crog> yotux: that's exactly what I thought
[18:06] <yotux> so ask for more info and make a more informed not an issue
[18:06] <komputes> Cheesehead: I would change the rationale here to, there is no easy way to install Ubuntu OEM (preinstall). Then in the Solution put 1) make OEM image release 2) use a flag on ubiquity to make it run in OEM mode
[18:07] <Cheesehead> Very possible. But still, do we have a use case to justify developer time?
[18:07] <komputes> Cheesehead: currently, I'm being told, that the alternate disk has this option already
[18:07] <Cheesehead> There we go!
[18:08]  * Cheesehead laughs
[18:09] <komputes> Cheesehead: when you boot the CD, press a key to bring up the menu, then I think it's F6 to get the menu which says OEM install
[18:09] <Cheesehead> Man, whenever you're around I *learn things*
[18:09] <yotux> komputes:   its something like that
[18:09] <Cheesehead> You guys are filling my brain!
[18:10] <crog> https://help.ubuntu.com/community/Ubuntu_OEM_Installer_Overview
[18:10] <yotux> I use alt CD allot
[18:10] <yotux> crog:   thanks
[18:10] <Cheesehead> crog: Thanks!
[18:10] <Cheesehead> Next: http://brainstorm.ubuntu.com/idea/28401/
[18:10] <komputes> It's actually F4
[18:11] <Cheesehead> Um, skip the comments. Let's see what you think unvarnished
[18:11] <crog> I guess that's a good reminder that the discussion is helpful - and search may be moreso
[18:11] <Cheesehead> Yes, LOTS of Brainstorm issues are settles by 10 seconds with a search engine.
[18:12] <crog> And I'll never understand all of the *.dll's in windows/system32
[18:12] <komputes> Cheesehead: I marked it implemented and added the comment on how to get er dun
[18:12] <yotux> ok this is not an issue for a non power user
[18:13] <Cheesehead> komputes: Thanks!
[18:13] <Cheesehead> crog: Great point - nobody knows everything! I sure don't know much at all.
[18:14] <Cheesehead> I've just been hanging around a while.
[18:14] <komputes>  nobody knows everything... but collectively...
[18:15] <crog> My point of course is that something as complicated as an OS has a lot of good reasons for why things are the way they are.
[18:15] <Cheesehead> crog: Another great point.
[18:16] <Cheesehead> A lot of new users don't know those reasons. That ties right into this idea.
[18:16] <komputes> Are you guys on a boat? IdleOne says hi.
[18:17] <Cheesehead> Any thoughts on http://brainstorm.ubuntu.com/idea/28401/
[18:17] <Cheesehead> ?
[18:18] <crog> The discussion in that idea has been ongoing
[18:18] <yotux> I don't see that there needs to be a whole rewrite of structure
[18:18] <crog> It's not something anyone's going to want to change
[18:19] <yotux> This could be sent to software center
[18:19] <Cheesehead> Is it really a problem?
[18:19] <yotux> but it we want a list of installed software it show in SC
[18:19] <yotux> It a windows / OSX issue
[18:19] <crog> how do you just close/nuke it?
[18:19] <yotux> our issue I would say no
[18:20] <crog> and still thank Sman789 for the idea/time...
[18:20] <crog> No - it's core to pretty much any Linix distro - and most all of their predecessors
[18:20] <Cheesehead> Well, I read it as the submitter is asking for a kind of Nautilus filter to find application-specific files
[18:20] <crog> Cheesehead: I may not be on the same one anymore...
[18:21] <crog> 28401?
[18:21] <Cheesehead> 28401
[18:21] <crog> Ahhh - this is a feature I find most useful, but hard to get to.
[18:21] <Cheesehead> I read solution #1 as "use a magic wand". A bit unrealistic, and the author even agrees.
[18:22] <yotux> I have used linux for a long time,  not a power user,  the only thing diff is ubuntuy has no root
[18:22] <crog> When you go into synaptic (if you use that) - for installed packages, you can see the details of what's installed, and where.
[18:22] <crog> While I wouldn't suggest changing anything, I think this is the sort of information the submitter is looking for.
[18:22] <Cheesehead> crog: I suspect it's implied that he finds that too cumbersome
[18:23] <Cheesehead> I thought of installing in a chroot, but again that may be too cumbersome for whatever he wants to do
[18:23] <crog> I do too - I shouldn't need to go into my package manager app for that if the database were more accessable
[18:23] <crog> as you say - to something like Nautilus
[18:23] <Cheesehead> Which raises the question: What does he want to do with this feature?
[18:24] <crog> Right - probalby needs a better use case laid out
[18:25] <Cheesehead> Okay, so let's say a fabulous use case shows up. What's his next step?
[18:25] <crog> ...  package his own distro?
[18:25] <crog> <only 1/2 serious>
[18:26] <Cheesehead> Well, if he backs off Solution #1 and is willing to accept, say, a Nautilus plug-in that queries the apt database...
[18:27] <Cheesehead> then how about suggesting such a plug-in to Gnome?
[18:27] <Cheesehead> Alternately...
[18:27] <Cheesehead> a nautilus plug-in may be small enough that he can hack at it himself
[18:27] <crog> agreed
[18:28] <Cheesehead> Since other solutions are possible, how about...
[18:28] <Cheesehead> 1) ask the author to clarify the use case,
[18:28] <Cheesehead> 2) add another solution (Nautilus plug-in)
[18:29] <yotux> I agree,   but I don't understand why he finds the need to be in a /usr/  file place
[18:29] <Cheesehead> Agreed
[18:29] <crog> I still would want more info about what he's trying to accomplish - and what's meant by, "frequently-used folders are so scary"
[18:29] <crog> What's the frequent usage?
[18:29] <yotux> most apps create .foo configs in /home/user
[18:29] <Cheesehead> Seems to go back to usage/use case clarification
[18:30] <yotux> yes,  need more info
[18:30] <Cheesehead> 3) leave it open a month to gauge reacton and other solutions, then send the submitter on his way
[18:30] <Cheesehead> Since nobody is likely to develop it for him.
[18:31] <crog> After reading solution 2 again - maybe it's a "uninstall" vs "purge" question.
[18:31] <crog> Yep - 1,2,3 as Cheesehead suggests.
[18:31] <Cheesehead> OOh, another cut/paste opportunity:
[18:31] <Cheesehead> ANALOGY - Brainstorm is like the Wizard of Oz, not Glinda the Good Witch.
[18:31] <Cheesehead> Glinda had a magic wand, and could do *anything* effortlessly.
[18:31] <Cheesehead> The Wizard didn't have a magic wand, and pointed supplicants along the path of self-development.
[18:32] <Cheesehead> We don't have a magic wand.
[18:32] <Cheesehead> (It's a limited analogy - we don't send supplicants to be slaves of the Wicked Witch.)
[18:32] <Cheesehead> (My apologies to the billions of non-North Americans unfamiliar with the book or movie)
[18:32] <Cheesehead> Next up: http://brainstorm.ubuntu.com/idea/27492/
[18:35] <yotux> cheesehead:  I would say use a group to have access /home folder
[18:35] <yotux> a user can be part of a group and a group can have open access to a limited amount of data
[18:35] <yotux> Please correct if I am wrong
[18:36] <Cheesehead> So, Solution #1.
[18:36] <Cheesehead> That's indeed an effective method.
[18:37] <yotux> Thats the easy way
[18:38] <Cheesehead> Is there really a need for a non-root to backup everybody else's stuff?
[18:38] <yotux> I am not sure howto do the deamon method
[18:38] <yotux> no, not a need
[18:39] <crog> I think you're either on a system where the admin backs up everything for you (i.e. I backup my wife's /home - and I have su/root)
[18:39] <yotux> the question makes it sound like root is in need to make backsup of all data but doesn't want to give root access cause of trust
[18:39] <crog> Or, you have a multi user sytem, where each user backs them selves up.
[18:40] <Cheesehead> So is there a clear use case for this feature?
[18:40] <yotux> solution 2  couldn't data be encrypted before sent over the wire?  ssh / pgp
[18:40] <crog> If trust is the issue, encrypting before sending is the only way.
[18:41] <yotux> use case is clouded slightly
[18:41] <Cheesehead> Encryption is a great point!
[18:41] <crog> or if problem is trust in the backup program...  the answer is open source
[18:41] <yotux> trust to system access is 1st
[18:42] <crog> find a different tool, or read line-by-line the code
[18:42] <crog> or "trust" the community
[18:42] <yotux> solution 2 talks about admin only access data?
[18:43] <yotux> I find that we are taking on two dragons when we started with on problem then solution introduced 2nd
[18:43] <yotux> ask for me details
[18:43] <crog> Yeah - I'm not sure what is being requested
[18:44] <Cheesehead> When the issues metastasize, I go back to the Rationale and the problem statement
[18:45] <Cheesehead> Why would the sysdamin use a backup operator/program that they don't fully trust?
[18:45] <yotux> So if problem is limit sys access then a limited group would work,  let encryption be the users problem
[18:46] <yotux> Cheesehead: Admins will not use services they can't trust
[18:46] <Cheesehead> Is this really a problem?
[18:47] <crog> first line says, "difficult to perform" "without su"
[18:47] <yotux> No,  user educate
[18:47] <crog> but when I think admin/backup/restore/anything - that requires root
[18:47] <crog> and for good reason
[18:48] <crog> yotux: agreed
[18:48] <yotux> would it require su if you are in a group that has 777 access?
[18:48] <Cheesehead> Could this be a user trying to do something, er, un-recommended, and unhappy that the system balks?
[18:49] <yotux> Cheesehead: yes he could be
[18:49] <crog> If I'm on a multi-user system, I don' want anyone except me or the admin who has root to have access to my /home
[18:49] <Cheesehead> crog: I think you nailed it there!
[18:49] <yotux> crog: I agree with you
[18:50] <Cheesehead> Ah, I like this one: http://brainstorm.ubuntu.com/idea/27460/
[18:51] <crog> me too
[18:51] <crog> I've actually read this one before
[18:51] <crog> Yes - it already exists.
[18:51] <crog> should just be made easier to find
[18:52] <Cheesehead> crog: Why?
[18:52] <yotux> This has changed in the last two cycles
[18:53] <yotux> before unity one could click on help -> about
[18:53] <crog> on my android... Settings --> About phone
[18:54] <crog> on an application... Help --> About
[18:54] <Cheesehead> Does anybody run across many help forum requests where the requestor cannot determine their version?
[18:54] <crog> In an OS (Win)... System Information
[18:54] <crog> etc.
[18:55] <crog> I think it's one thing if you need to know 11.04 or Natty
[18:55] <yotux> I am running ubntu 11.10
[18:55] <yotux> type help
[18:55] <crog> but you might be asked - which version?  Which build?
[18:55] <yotux> it tell me welcome to 11.10
[18:55] <crog> Maybe you're right - it's a change - something I'm not used to.
[18:56] <crog> but I had no problem going from gnome to unity
[18:56] <crog> This seems more like a universal expectation to me.
[18:56] <yotux> the info display is diff in unity that is all I am saying
[18:57] <Cheesehead> So in Unity, it's easy?
[18:57] <yotux> when I am on the desktop and click help about it talks about nautilus
[18:57] <yotux> unity it is more hidden
[18:57] <yotux> easier to find apps yes
[18:57] <yotux> type help the manaul comes up
[18:57] <yotux> for me its says welcome to 11.10
[18:58] <Cheesehead> The original problem statement was that it's hard to find basic information about the Ubuntu version installed
[18:58] <Cheesehead> Is that a problem?
[18:58] <Cheesehead> Hello, bigbash ! Joining us?
[18:59] <crog> If it means 2 extra posts in a bug report or forum...
[18:59] <Cheesehead> Well, in the bugs and forums you have read...did it?
[19:00] <crog> Cheesehead: good point
[19:00] <yotux> It not hard unless you want a one click solution
[19:01] <crog> It perhaps is not important when stacked up against other bugs, ideas, etc.
[19:01] <crog> but still a good idea.
[19:01] <Cheesehead> So a wishlist issue?
[19:01] <crog> And more people have voted on it than many others...\
[19:01] <crog> Yes.
[19:02] <Cheesehead> Well, popularity with users does not imply implementation.
[19:02] <crog> wishlist
[19:02] <yotux> Cheesehead:  could it be added to the about button in system settings
[19:02] <yotux> yotux:  thinking out loud
[19:02] <Cheesehead> If I posted an idea "Hamburgers should be free", it would be popular, but unlikely to happen.
[19:03] <Cheesehead> yotux: Great idea!
[19:03] <yotux> I was playing in the new menu for 11.10
[19:03] <yotux> System has about but doesn't ref ubuntu at this time
[19:03] <Cheesehead> One issue that pops up is...
[19:03] <yotux> Its called system info
[19:04] <Cheesehead> the desire to minimize patches...
[19:04] <Cheesehead> from upstream.
[19:04] <Cheesehead> Given a choice, the Desktop team would prefer to build-and-go.
[19:04] <crog> suggestion: upstream allows branding - so it's just a file ubuntu (or other distro) adds
[19:05] <crog> doesn't make sense for most apps... but for system info it might
[19:05] <Cheesehead> True. Then somebody must maintain that branding patch.
[19:05] <Cheesehead> Canonical doesn;t want their engineers maintaining a lot of patches.
[19:05] <Cheesehead> When they could be doing more useful work
[19:06] <Cheesehead> That's one possible reason why it hasn;t already been implemented
[19:06] <yotux> It easy access in system monitor
[19:07] <Cheesehead> The flip side of the argument, though, is that it goes to the polish-and-feel of the distro.
[19:07] <Cheesehead> Yes, I like System Monitor
[19:07] <Cheesehead> Next up: http://brainstorm.ubuntu.com/idea/27441/
[19:09] <crog> so does the last one just stay open?  take a pass? is there a process to dispatch of it?
[19:09] <crog> first - need to state what the problem is we're trying to solve
[19:10] <Cheesehead> We can close it if we want, but that didn't seem the consensus.
[19:11] <Cheesehead> We can recommend to the submitter that they offer to create and maintain such a pach for Nautilus.
[19:11] <yotux> 27441  data control need more info
[19:11] <crog> Cheesehead: 27460 - I'm not suggesting we close it -  just curious what the process is
[19:11] <Cheesehead> Or we can leave it open in the hopes that the Technical Board will look at the issue
[19:11] <crog> Cheesehead: its been open, and not acted on - lots of opinions details
[19:12] <yotux> cloud storage user has limited control
[19:12] <crog> Cheesehead: So I supose that's correct - leave it open for someone to consider
[19:12] <Cheesehead> The TB looks at the top-15-or-so scoring ideas each quarter.
[19:12] <Cheesehead> They winnow them down to 10, and respond or act upon them.
[19:12] <crog> 27441 - need to state the problem
[19:12] <yotux> I have used ubuntu one the admins can purge any data they want
[19:13] <crog> and storage on the cloud is inherently giving up control of data
[19:13] <yotux> crog: we agree
[19:13] <Cheesehead> 2447 - I agree that the problem statement is muddled.
[19:13] <yotux> Here is another issue
[19:14] <crog> encryption solves the security or confidence
[19:14] <yotux> the Music store is in question.  No music player I have ever used has encrypted music or data
[19:14] <Cheesehead> It's not the music store. That's an error.
[19:14] <Cheesehead> Good eyes!
[19:15] <yotux> .wma may have DRM but that is not of use in this case
[19:15] <Cheesehead> Is this really a problem?
[19:16] <crog> it's not a problem with ubuntu 1
[19:16] <crog> it's not a problem - a wishlist/nice to have
[19:16] <Cheesehead> He wants to add ecryptfs support to the Ubuntu One client so he doesn;t need to bather with manually encrypring/decrypting
[19:16] <Cheesehead> That's how I see it. Am I far off there?
[19:17] <yotux> Cheesehead: yes
[19:17] <yotux> The data is secured by his user name and pass
[19:17] <crog> I'd maybe suggest doing the encryption as a client-side plugin
[19:17] <crog> I like DarwnSurvivors ideas on this one too.
[19:18] <Cheesehead> My first thought was scripting the encrypt/decrypt should be scripted locally...
[19:18] <Cheesehead> then the client needn;t care about the datatype
[19:18] <yotux> I agree
[19:18] <crog> You're right the encryting/decrypt shouldn't be difficult for the end user to need to do manual steps on each file they want to upload
[19:19] <Cheesehead> Darwin always has a great perspective!
[19:19] <Cheesehead> So...what should we do with this idea?
[19:20] <Cheesehead> Ask for clarification? Add a solution? Leave it open?
[19:21] <yotux> Leave open+
[19:21] <Cheesehead> (We can do more than one)
[19:22] <crog> Would it be offensive to re-write it in complete English sentences?
[19:22] <yotux> crog: LOL
[19:22] <Cheesehead> Many submitters are not native english speakers
[19:23] <Cheesehead> We made an editorial decision to let grammar slide in favor of the concepts.
[19:23] <crog> absolutely - and no problem that its harder for them.
[19:23] <Cheesehead> I would be *awful* if I tried to write anything in Arabic
[19:23] <crog> I like the idea of choosing concepts over grammer
[19:23] <crog> grammar
[19:23] <yotux> I would rec a two step solution:  recommended user  encrypt and leave open
[19:24] <crog> I 'm suggesting someone post:  "I think you are suggesting ...  Does that sound right?"
[19:24] <Cheesehead> We also let people post in *any* language that Google Translate will recognize. Whatever it takes to be clear.
[19:24] <crog> simply to make it easier for others to be certain their understanding the request
[19:24] <yotux> Cheesehead: Thanks for the info
[19:25] <Cheesehead> crog: Great point on clarification
[19:26] <Cheesehead> The consensus seems to be leave open, clarify, and lean toward user-level encryption.
[19:26] <crog> Yep
[19:26] <Cheesehead> So the Ubuntu One part is kind of irrelevant?
[19:26] <Cheesehead> Could be any online storage?
[19:26] <crog> imo yes.
[19:27] <yotux> yes
[19:27] <crog> but If ubuntu wants to have ubuntu 1 integrated, it could be built in to the client side interface
[19:27] <Cheesehead> Okay, next:
[19:27] <Cheesehead> http://brainstorm.ubuntu.com/idea/27415/
[19:28] <Cheesehead> By the way, THANK YOU for your help and input. It's great to get more perspectives!
[19:28] <Cheesehead> And you are really helping people.
[19:29] <crog> On this one, my first thought is, "meh"
[19:29]  * Cheesehead laughs
[19:30] <Cheesehead> Does this seem like it's really a problem?
[19:30] <crog> I know who I am from the background, icon layout, name, etc
[19:30] <crog> This doesn't help or hinder my usage
[19:31] <Cheesehead> Judging by the votes in Solution #1, perhaps a lot of voters agree with you
[19:31] <yotux> I don't see this as a problem
[19:32] <Cheesehead> User-customization will make a bigger difference than a user-icon?
[19:32] <yotux> The users name is already displayed
[19:32] <Cheesehead> Ah, true. I had forgotten
[19:33] <crog> the rationale says, "this could help more clearly indicate which us is logged in"
[19:33] <yotux> the icon is generic but the login icome is custom I think
[19:33] <yotux> I don't think it would,  I think this is not a problem
[19:33] <yotux> User name is clearly displayed
[19:33] <crog> yotux: agree
[19:34] <yotux> its eye candy not functional
[19:34] <Cheesehead> OK, how about I close this one due to the low vote scores?
[19:35] <yotux> Also the screenshots are from older ubuntus we not longer will be using that framework
[19:35] <crog> Sounds good to me
[19:35] <yotux> Agree
[19:36] <Cheesehead> Oops, one moment please...
[19:38] <Cheesehead> Ah, here we go: http://brainstorm.ubuntu.com/idea/27298/
[19:38] <Cheesehead> Sorry for the delay. Thunderstorm.
[19:41] <crog> I agree with the "problem", but not sure on solutions here
[19:41] <crog> If a process dies in the way described, restarting it probably just means it will die again
[19:41] <yotux> okay if a process that controls the GUI dies doesn't this make it some type of bug
[19:42] <Cheesehead> yotux: Well, yes.
[19:42] <yotux> brainstorm is not the place to report bugs,  if this is the case I would suggest they try and create a bug report
[19:42] <crog> I'm not familiar enough with apport yet, and the other built-in bug reporting
[19:43] <crog> but perhaps this is speaking to a need that they be a little more integrated
[19:43] <yotux> crog:  me either but it could be allot of things
[19:43] <yotux> drives, unity, compiz, etc
[19:43] <crog> clearly the submitter experienced a bug
[19:43] <crog> and is looking for a way for bugs to be less intrusive on the user experience
[19:43] <yotux> crog: I agree
[19:44] <yotux> bugs will always make user unhappy,  we need to address bugs and try and get them fixed
[19:44] <crog> restarting is likely not going to solve anything
[19:44] <Cheesehead> So is this a workaround to some bug the user experiences?
[19:44] <Cheesehead> Or is there a real need to monitor/restart long-lived processes?
[19:45] <crog> but noting that the process died, and doing something about it (instead of just logging in dmesg) might hlep
[19:45] <crog> help
[19:45] <crog> if there is a need to monitor/restart specific daemons, then I'd leave that monitoring to the specific application
[19:46] <Cheesehead> Well, daemons are supposed to be supervised by Upstart, not directly by applications.
[19:46] <yotux> logging could help solve the problem in the end
[19:47] <crog> I guess I mean if you're writing something that you want to keep alive, but not writing it as a daemon
[19:47] <yotux> but logging wil also create more work with more data for devs to fix
[19:47] <Cheesehead> like, say, gdm.
[19:47] <Cheesehead> Example of a long-lived non-daemon
[19:48] <Cheesehead> If the submitter had provided a more specific example, it would be easier to identify if this is a bug workaround.
[19:49] <crog> he's comparing to a Win experience where explorer just restarts
[19:49] <yotux> crog I agree
[19:49] <Cheesehead> crog: I think you're right
[19:50] <crog> but I'd even argue that explorer just restarting doesn't help solve anything
[19:50] <Cheesehead> That takes us back to the initial question: Real need, or bug workaround?
[19:50] <yotux> I would say bug workaround
[19:51] <yotux> Is brainstorm the place for those workarounds?
[19:51] <crog> makes it easier to deal with a bug that occurred if you're not going to actually dig into the root caus
[19:51] <Cheesehead> Not really. The right answer is to fix the bugs so the workarounds are not needed.
[19:51] <Cheesehead> Workarounds introduce their own bugs, too
[19:52] <crog> I think the most useful thing in here is 'offer to restart or log out and report to the developers'
[19:52] <crog> thats why I mentioned apport at the start -
[19:52] <Cheesehead> Well, if X crashes, it already generates an apport report"
[19:53] <Cheesehead> And won;t give you any options - you're back to login screen
[19:53] <crog> So looks like we're thinking it doesn't really belong here
[19:53] <yotux> I would agree
[19:53] <crog> redirect to, "thanks, and if you see this behavior, we recommend..."
[19:54] <Cheesehead> ...enable apport, then reporduce the behavior.
[19:54] <Cheesehead> How is everybody's brain doing?
[19:54] <Cheesehead> Feel like you just swam a mile?
[19:54] <crog> fine... need to help around the house pretty soon here.
[19:55] <Cheesehead> crog, where are you located?
[19:55] <crog> I appreciate hearing the different opinions on these....
[19:55] <crog> Cheesehead: Madison
[19:55] <crog> Cheesehead: Going to try to join tomorrow bug jam too, if I can get away...
[19:55] <Cheesehead> I REALLY appreciated getting your opinions!
[19:56] <Cheesehead> Yeah, the bug jam will work much the same way.
[19:56] <Cheesehead> You guys were GREAT here. Let your families know I really appreciate their sacrifice!
[19:56] <crog> Cheesehead: Where are you?
[19:56] <yotux> Cheesehead:  Thanks for the intro
[19:56] <Cheesehead> Milwaukee
[19:56] <yotux> yotux: Portage
[19:56] <Cheesehead> I hope you liked it, and thanks for coming by!
[19:57] <Cheesehead> Any suggestions on how to improve for next time?
[19:57] <yotux> It was interesting
[19:57] <Cheesehead> There are a lot of possible topics!
[19:57] <Cheesehead> That's what I like about it
[19:57] <crog> we just jumped right in, which I think was great
[19:58] <crog> we made some decisions about wht the next steps should be on some of these
[19:58] <Cheesehead> Good. That's what I was aiming for!
[19:58] <yotux> I would agree with crog the lead in time was great
[19:58] <crog> perhaps a little bit more about the process up front.
[19:58] <Cheesehead> I thought about more lead-in. If we had some newer folks, I had some text prepared.
[19:59] <Cheesehead> But you guys really grabbed the ball and ran.
[19:59] <crog> for example we talked about closing one, but not how it's done.
[19:59] <Cheesehead> I have to close it. I have permissions to do so.
[19:59] <crog> I'm assuming you have a different interface to the website
[19:59] <Cheesehead> A bit different. A few extra tools.
[20:00] <crog> I was thinking just a little more of "lifecycle of an idea in brainstorm"
[20:00] <crog> but didn't really need much background (such as purpose/motivation, etc.)
[20:00] <yotux> crog:  as one joins a team they get more rights
[20:00] <Cheesehead> Wait...I might have that here...
[20:00] <crog> yotux: assumed so - and that makes sense.
[20:00] <Cheesehead> WHAT BRAINSTORM IS: http://brainstorm.ubuntu.com . It's an idea-generation website.
[20:00] <Cheesehead> You bring a specific problem, and users contribute solutions, and vote on the various solutions.
[20:00] <Cheesehead> Very handy for developers, or for users who identify a problem, but don;t know what to do about it.
[20:00] <Cheesehead> Every three months, the Ubuntu Technical Board reviews and responds to the 10 highest scoring ideas of the period.
[20:01] <Cheesehead> WHAT BRAINSTORM IS NOT: It's not a feedback or comment-card like you find in a restaurant
[20:01] <Cheesehead> "The food was nice, but the table was wobbly. And you should serve ice cream"
[20:01] <Cheesehead> That submission doesn't help anybody - it's a bug (wobbly table) and a wish (add ice cream) wrapped up together. That's a forum or blog post.
[20:01] <Cheesehead> We help the user parse out the bug and the wish and submit them separately to the appropriate channels.
[20:01] <Cheesehead> There we go. Just pretend I made you wade through all that up front.
[20:01]  * Cheesehead laughs
[20:01] <crog> got it
[20:01] <crog> well - thanks again- - gotta go....
[20:01] <Cheesehead> Thanks for joining!
[20:01] <Cheesehead> See you tomorrow1
[20:01] <Cheesehead> !
[20:02] <yotux> Cheesehead:: thanks for all you help on this,  hope bug jam goes the same way
[20:02] <Cheesehead> Thanks for all *your* help.
[20:02] <yotux> I have to go myself.  I am consider joining this team.
[20:02] <Cheesehead> Mere formality. You already have.
[20:03] <yotux> okay,  My instrest are bugs and may MOTU
[20:03] <Cheesehead> Well, then. See you tomorrow, same time, same channel!
[20:03] <yotux> but will tackle that tomorrow
[20:03] <yotux> bye
[20:04] <Cheesehead> #EndEvent
[20:04] <Cheesehead>
[20:05] <Cheesehead> Join us in 21 Hours for the Wisconsin Bug Jam! http://loco.ubuntu.com/events/ubuntu-us-wisconsin/1178/detail/
[20:06]  * Cheesehead wanders off for a drink in the atrium
[20:23] <Cheesehead> Brainstorm Jam Logs: http://irclogs.ubuntu.com/2011/09/03/%23ubuntu-us-wi.html#t16:55
[22:43] <h00k> hi friends!
[22:44] <h00k> went well?
[23:03] <Cheesehead> h00k: Seems so.
[23:03] <h00k> s as eet
[23:03] <h00k> sweet
[23:04] <Cheesehead> You can see it was intense, and lasted the whole three hours
[23:04] <h00k> that ud awesome
[23:04] <h00k> is
[23:04] <Cheesehead> parting words were 'hope the bug jam goes the same way'
[23:04] <h00k> on my phone, haven't checked the logs yet
[23:04] <h00k> ! coool


[09:29] <Riddell> hi clivejo
[09:29] <clivejo> morning
[09:41] <yofel> clivejo: moin, the removal in that last log you posted was a package install failure
[09:43] <yofel> uhm, that's very wrong actually o.O
[10:52] <yofel> hm... I'm kind of starting to like ruby...
[10:52]  * yofel feels like he just said something crazy
[10:59]  * lordievader stares at yofel wide-eyed
[11:05]  * clivejo checks yofel's temperature
[11:06] <clivejo> I think you're ill
[11:06] <sitter> yofel: http://paste.ubuntu.com/14025920/
[11:06] <sitter> https://speakerdeck.com/erniemiller/thats-not-very-ruby-of-you?slide=26 *cough*
[11:06] <yofel> XD
[11:07] <sitter> full sample for general enjoyment http://paste.ubuntu.com/14025930/
[11:09] <yofel> alias print puts, wth?
[11:10] <yofel> this is just..
[11:11] <clivejo> mad?
[11:11] <clivejo> crazy?
[11:11] <yofel> lets say, misdirected mindset
[11:11] <sitter> it's for when you want your print to behave incorrectly
[11:11] <sitter> a print that appends newlines is no real print IMO :P
[11:13] <clivejo> is that how you have to define an object in ruby?
[11:13] <yofel> clivejo: no, that's how you define a ruby object to look and work as a python one
[11:14] <yofel> just in case you ever want to write a language to behave like a different language
[11:14] <clivejo> O_O
[11:15] <yofel> sitter: does this look reasonable or did I do something very wrong? https://git.launchpad.net/~kubuntu-packagers/+git/kubuntu-automation/tree/git-push-all
[11:15] <yofel> (haven't actually tested the push part yet)
[11:20]  * sgclark is very scared
[11:26]  * yofel originally wanted to rewrite that 500-line spaghetti code called ppa-build-status and was looking at ruby so he might be able to use the CI parsers.
[11:26] <yofel> as usual I ended up writing something else
[11:31] <sgclark> hehe
[11:36] <santa_> yofel: still using the stuff in automation-ng?
[11:37] <yofel> santa_: no, I gave up on that for now after git-clone-all didn't do anything useful to me due to too much hardcoding of os.getcwd()
[11:38] <yofel> right now I'm trying to patch the old stuff into shape so we can get stuff done while we deprecate it
[11:39] <santa_> yofel: ok, so parallelizing git-clone-all sounds like an interesting thing to do?
[11:40] <yofel> possibly, at least with moszumanska being as slow as it is
[11:40] <santa_> k
[11:40] <yofel> requires git stdout/stderr redirection though to properly show errros
[11:41] <BluesKaj> 'Morning all
[11:41] <yofel> hey
[11:43] <BluesKaj> Hey yofel
[11:48] <sitter> yofel: doesn't look too bad
[11:49] <BluesKaj> kate isn't launching after unstalling the packages from the frameworks/build_status ppa yesterday ..installed kwrite and it works ok
[11:50] <sgclark> the build status that is still red?
[11:50] <BluesKaj> dbus-launch opens kate , but that's a pita
[11:51] <sgclark> well if it is kf5 in staging-frameworks, it is not done,
[11:51] <sgclark> and I am about to hop on a plane so it won't be done soon unless someone else steps up to help
[11:52] <yofel> It's building actually, except nmqt
[11:53] <sgclark> well yes of course, I have retry running. but have to pack up soon
[11:54] <BluesKaj> sgclark, np, it works fine otherwise and yes it's the Staging Frameworks ppa
[11:57] <BluesKaj> I'm feeling adventurous these days, maybe it's the winter boredom setting in and a I need a little excitement :-)
[11:58] <sgclark> lol
[12:20] <Riddell> sitter: "Build step 'Console output (build log) parsing' changed build result to UNSTABLE" gets done if there's any KCI-W detected by kci?
[12:21] <sitter> Riddell: yup
[12:29] <yofel> kdelibs4support - 5.17.0-0ubuntu1~ubuntu16.04~ppa1	i386	logfile	Dependency wait: kdesignerplugin (>= 5.16.0~)
[12:30] <yofel> wait, why does that say >= 5.16, should be >= 5.17
[12:32] <yofel> oh great, another script with now busted epoch handling
[12:32] <sgclark> eh what?
[12:32] <yofel> looks like I did a bad job at looking for those :(
[12:32] <sgclark> oh
[12:35] <yofel> oh wait, that has a different array o.O
[12:36] <sitter> O.o
[12:36] <yofel> static package list files overload -.-
[12:37] <sitter> I always did love those static lists
[12:38] <sgclark> haha
[12:38] <sgclark> anyway, can someone make a tester call when the last bits finish please, I am heading back home now.
[12:39] <yofel> sgclark: you uploaded the new network-manager somewhere?
[12:39] <sgclark> ahh crud. nevermind. no.
[12:40] <yofel> ok, our epoch handling sucks
[12:41] <yofel> that needs redesign on paper before I touch it any more
[12:42] <sitter> yofel: couldn't you simply switch all version mangling with the python debian lib thingy's version class?
[12:43] <yofel> not if that lib still deletes comments from files, otherwise that's probably good idea
[12:44] <sitter> well. no more or less than wrap-and-sort already does, seeing as that also uses the lib IIRC
[12:44] <yofel> good point
[12:50] <yofel> OTOH, the actual control file editing isn't the problem really. The tracking of what package has what epoch is a PITA
[12:50] <sitter> yofel: you don't need to track that though
[12:51] <sitter> it already shoudl be there
[12:51] <sitter> so all you need to do is not touch it
[12:51] <yofel> Doing a git-clone-all before starting to work and extracting the information from there is more reasonable than using 2 JSON arrays and a dozen text files
[12:51] <sitter> if there is an epoch already you preserve it and if there isn't you won't add one
[12:51] <sitter> also yeah, using life data is of course the
[12:51] <yofel> yes, I think that's what my old code did. The current one does.. magic
[12:51] <sitter> best way :)
[12:51] <yofel> very static magic
[13:33] <Yossarianuk> does this mean that the wily backport will go straight to plasma5.5.1 (due to bugs in 5.5)?
[13:33] <Yossarianuk> https://www.kde.org/announcements/plasma-5.5.1.php
[13:35] <yofel> well yeah, considering we didn't even start yet we'll start with what's available when we do
[13:37] <Yossarianuk> good stuff - 5.4.3 is serving me well anyway...
[13:38] <Yossarianuk> I assume that 16.04 will have plasma 5.5.x ?
[13:43] <yofel> yes
[13:45] <yofel> sgclark, clivejo: As a warning: I just removed the git push logic from staging-upload and ubuntu-archive-upload, that's now an extra script called git-push-all so remember to run that
[13:45] <yofel> that a) finally allows you to mess up while generating the packages, b) shortens the time that CI has to be paused a lot
[14:59] <Riddell> Plasma 5.6 meeting in #plasma in a minute!
[15:01]  * yofel watches
[15:02] <clivejo> has to go out soon, but Ill read it later :)
[15:05]  * clivejo going to dry the puppy
[15:15]  * yofel has the punch line of the meeting now: "Terminology is important"
[15:16] <bshah> :-D


[02:25] <poningru> anyone around?
[02:25] <poningru> I need help with a main inclusion report
[02:25] <poningru> https://wiki.ubuntu.com/MainInclusionReportiSCSI?highlight=(iscsi)
[02:25] <poningru> I wanted to know what to put for the security portion of the thing
[02:25] <poningru> and the other stuff...
[02:26] <somerville32> Did you not use the MIR Template? It has clues.
[02:26] <poningru> OH?
[02:26] <poningru> I did not see one
[02:26] <poningru> I had to use other ones
[02:26] <somerville32> For security, look for CVE reports and security-related bug reports
[02:27] <poningru> ooh found the template
[02:27] <poningru> thanks
[02:27] <somerville32> np
[02:29] <poningru> somerville32: another question... if the security vuln is patched already...
[02:29] <poningru> should I still include it?
[02:29] <poningru> http://www.debian.org/security/2007/dsa-1314
[02:30] <Fujitsu> Yes.
[02:30] <poningru> k thanks
[02:42] <slangasek> yes, because the idea is to show the security history and how the incidents were handled
[02:55] <bddebian> lamont: Are you actually around by any chance?
[03:21] <mgunes> Hobbsee, while you are at it, could you post to (some of) those "how to upgrade packages the right way" etc. threads as well?
[03:21] <Hobbsee> mgunes: got links?
[03:21]  * Hobbsee isn't browsing the forums currently
[03:21] <mgunes> sure
[03:22] <mgunes> Hobbsee: http://ubuntuforums.org/showthread.php?t=640547 , http://ubuntuforums.org/showthread.php?t=641445
[04:40] <lamont> bddebian: sup
[04:40] <lamont> ?
[04:41] <bddebian> lamont: Ah, I already sent it but I had debhelperized xdelta
[04:44] <lamont> bddebian: cool
[04:44] <lamont> so it's in my email?
[04:45] <bddebian> lamont: I cc'd the bug.  I can dump it on mentors or something if you prefer.  I was going to fix a couple of the other bugs but I keep getting in trouble for that :)
[04:45] <lamont> ah, ok.
[04:45] <lamont> that'll work
[04:45] <lamont> heh.  separate diffs for the other bugs wouldn't necessarily be complained about.
[04:49] <bddebian> lamont: OK, I'll look
[04:52] <Hobbsee> hrm.
[04:52]  * Hobbsee wonders why the latest kernel does not appear to recognise her wifi hardware switch being turned back on again
[04:54] <Hobbsee> ah, goody.  someone blogged about the @ubuntu.com spam
[04:54] <Hobbsee> elmo: fix it plz :)
[05:05] <lamont> bddebian: having them intermingled would be sad
[05:06] <lamont> bddebian: likewise, having the diff in the form of a git-format-patch would be the total win... :_)
[05:07] <bddebian> Hmm, never done a git-format-patch
[05:07]  * lamont mutters something about needing to assemble a proper debian/copyright file for nmap 4.50
[05:07] <lamont> bddebian: if you git clone, and then make the change, and then say 'git-format-patch' with some simple args, you get an mbox full of patches that you can then git-email
[05:08] <bddebian> Ah
[05:08] <lamont> OTOH, that invovles learning git a bit...
[05:08] <lamont> er.   git-send-email :-)
[05:11] <bddebian> Damn, give a guy an inch, he wants a mile ;-P
[05:12] <lamont> LOL
[05:13] <lamont> alternatively, one could send the name of a branch and a repo to pull from :-)  I think that's only 3/4 of a mile. :0)
[05:13] <bddebian> heh
[05:21] <lamont> bddebian: I'll read the diff in the morning once I'm awake. thanks much
[05:21] <Hobbsee> wow, 685 for hppa.  that's going down a fair bit
[05:22] <Hobbsee> (builds)
[05:22] <bddebian> lamont: NP, let me know if it's way off or broken in any way :-)
[05:23]  * Fujitsu thought it was at around 1600 just two days ago.
[05:23] <Hobbsee> well, this number may be wront
[05:24] <Fujitsu> No, it seems to be right.
[05:24] <Fujitsu> I guess a lot have failed or depwaited quickly.
[05:25] <lamont> Hobbsee: it's been busy building packages since the kde/toolchain guys got done doing all those uploads. :0)
[05:25] <Hobbsee> lamont: heh
[05:25] <Fujitsu> Ahh, it's that buildd depwait-detection failure bug.
[05:25] <Hobbsee> lamont: i have whinged about htat
[05:25] <Fujitsu> Bits of GTK and co apparently got uninstallable.
[05:25] <Hobbsee> Fujitsu: on amd64?
[05:26] <Fujitsu> Hobbsee: hppa.
[05:26] <lamont> Fujitsu: once it gets done getting through the whole pile (and needs build gets to single or double digits), I'll have someone give back everything in failed.
[05:26] <Fujitsu> So hundreds of builds would have failed quickly.
[05:26] <lamont> it's so much nicer to do that with SQL than the UI
[05:26] <Hobbsee> yeah, true
[05:26] <Hobbsee> hehe
[05:26] <Fujitsu> lamont: We'll hopefully have a mass give-back over * soon.
[05:26] <lamont> well, it'd be nice if they stalled another couple days... maybe we can have that for christmas
[05:27] <Fujitsu> But Soyuz probably won't be able to do it after tomorrow. Just to be annoying.
[05:27]  * Hobbsee glares at the paper, forecasting the weather
[05:27]  * Hobbsee is going to shoot something, if the weather writes off her next car too, with another hail storm.
[05:27] <Fujitsu> How's it looking?
[05:28] <Fujitsu> Hahahahaha.
[05:28] <Hobbsee> http://www.smh.com.au/articles/2007/12/17/1197740183604.html
[05:28] <lamont> Hobbsee: does that mean that your postal meter is approaching 100%
[05:28] <lamont> ?
[05:28] <Hobbsee> lamont: hrm?
[05:28] <Hobbsee> lamont: i dont understand
[05:28] <lamont> iz a "going postal" reference
[05:28] <Hobbsee> ahhh
[05:28] <Hobbsee> not really - nowhere to go
[05:29] <lamont> when the postal meter hits 100%, well...   people go postal...
[05:29] <slangasek> I thought when the postal meter hit 100%, you added another stamp
[05:29] <lamont> in 1995 I worked for a team where the team homepage had a postal meter calibrated in %
[05:30] <lamont> those were somewhat different times though, back when HP had a gun range here in Ft Collins.
[05:30] <lamont> before they got all scared of guns and such and closed the range.
[05:31]  * Fujitsu shoots lamont.
[05:31]  * lamont hugs his kevlar jacket
[05:31]  * lamont returns fire.
[05:31] <Fujitsu> Damn.
[05:32] <slangasek> hugging your kevlar jacket sounds like a good way to lose a hand
[05:32]  * Hobbsee lobs bombs in lamont's general direction.
[05:32] <lamont> tragic to have a drive-by shooting in an ubuntu channel... Does that fit with the CoC?
[05:32] <slangasek> when the shrapnel starts flying
[05:32] <Hobbsee> lamont: it doesn't explicitly forbid it.
[05:32] <lamont> Hobbsee: "Once you have tac nukes, everything looks like a small city."
[05:32]  * Hobbsee defenestrates slangasek
[05:32] <Hobbsee> lamont: yeah, that's it
[05:33]  * lamont debates the various merits of more self-defense bombing, or simply going to bed.
[05:33]  * Hobbsee blows up the bed, to make the decision easier.
[05:34]  * lamont sighs.  my wife was there.
[05:34] <lamont> Hobbsee: now you're really in trouble.
[05:34] <Hobbsee> i removed the wife first.
[05:34]  * Hobbsee is always truble.
[05:34] <lamont> still, it's her favorite bed _ever_.
[05:34] <Hobbsee> er, trouble.
[05:34] <Hobbsee> this was long known
[05:35] <lamont> maybe you should have left her there... iz irish redhead. :-)
[05:35] <lamont> "College co-ed destroys fellow developers bed, angers wife."
[05:37] <lamont> yeah. bedtime.
[05:37] <lamont> g'night
[05:37] <Hobbsee> guess you'll have to find her another one then.
[05:37] <bddebian> Gnight lamont
[06:08]  * sladen quickly hides his bed
[06:46] <warp10> Hi all!
[06:52] <poolie> hi
[06:52] <poolie> i have a source package, i'd like to get PPA to build it on Hardy as well as Gutsy
[06:52] <poolie> help?
[06:53] <lifeless> upload it twice
[06:54] <lifeless> set the target via the changelog, so you have to build the source twice too
[06:54] <poolie> hey, what a surprise
[06:54] <poolie> :)
[06:54] <poolie> it seems like that'll produce two source packages with the same name...
[06:54] <poolie> should i add a version suffix for the distro?
[06:54] <poolie> or just let it happen?
[06:55] <lifeless> it will produce two source packages with the same name, and each will go in a separate archive
[06:55] <lifeless> which is the same as e.g. building bzr 1.0 for two dapper and gutsy
[06:56] <poolie> ok
[06:56] <lifeless> look at the current bzr packages, they do this and are done 'right'
[06:57] <poolie> ok
[06:57] <poolie> so, practically
[06:57] <poolie> i need a different directory and a different source tree on my local disk for each distro to stop the source packages clashing
[07:01] <Fujitsu> lifeless: Note that they'll have to have different versions, as I mentioned in #launchpad.
[07:08] <mekius> Hi, working on gOS and for some reason our latest ISO just locks up while trying to load the squashfs.  Is there anyway to debug why this would happen?
[07:41] <dholbach> good morning
[07:43] <ion_> Hola
[07:44] <dholbach> heya ion_
[07:44] <ion_> What’s up?
[07:44] <dholbach> I'm waiting for coffee :))
[08:02]  * \sh transmits dholbach some coffee from the company coffee machine through the fibre wires
[08:03] <ion_> The Internet is like a series of tubes.
[08:03] <dholbach> letter chute! :)
[08:10] <dholbach> what do we need to do to get scrollkeeper out of main? is anything still using it?
[08:11] <Burgundavia> dholbach: make rarian work, I suspect
[08:12] <dholbach> no, rarian is a scrollkeeper replacement
[08:12] <dholbach> rarian-compat even Provides: scrollkeeper
[08:13] <dholbach> so we should be able to move it to Universe soon, if there's no good reason
[08:14] <Burgundavia> probably best to do it now, before the next alpha
[08:28] <dholbach> cjwatson, Riddell, StevenK, mjg59, sladen, bryce, Mithrandir (bluetooth team), siretart, ajmitch, slangasek, imbrandon, asac, keescook+soren (server team), ogra, gpocentek, calc, lool: can you take a look at  http://people.ubuntu.com/~dholbach/sponsoring  please?
[08:31] <Mithrandir> dholbach: sir, yes, sir.
[08:31] <dholbach> ROCK
[08:32] <siretart> oh, only one for me :)
[08:32] <dholbach> siretart: we can fix that :)
[08:32] <StevenK> dholbach: ... I told you I know nothing about powernowd ...
[08:32] <siretart> dholbach: heh
[08:32] <dholbach> StevenK: there are a lot of people who have never touched any of the packages they were assigned before too
[08:33] <StevenK> dholbach: Yes, but I don't want mjg59 to kill me.
[08:33] <Mithrandir> StevenK: he won't.
[08:33] <dholbach> StevenK: one of them is a bashism
[08:33] <dholbach> StevenK: and with the other one you could just ask mjg59 if he's d'accord or if he can take a look at it
[08:33] <dholbach> it's fine to re-assign to somebody else
[08:34] <StevenK> Bug 163709 has geser's fingerprints all over it
[08:34] <ubotu> Launchpad bug 163709 in wmclock "Please merge wmclock <IP_ADDRESS>-5ubuntu3 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/163709
[08:34] <StevenK> geser: Since you've dealt with the guy, I'll unsubscribe me and subscribe you?
[08:35] <dholbach> StevenK: I picked somebody of canonical staff to make sure it gets in, in this case it was you to make sure that it gets in (it's fine if you consult others before that)
[08:36] <Mithrandir> evand: about https://bugs.edge.launchpad.net/ubuntu/+source/libbtctl/+bug/176180 ; did you test nautilus-sendto + sending to a bluetooth device without the patch applied?
[08:36] <ubotu> Launchpad bug 176180 in libbtctl "Please sync libbtctl 0.9.0-2  (main) from Debian unstable (main)." [Undecided,New]
[08:38] <slangasek> dholbach: the only one you have listed on there for me is one for which /I'm/ awaiting sponsorship ;)
[08:38] <dholbach> slangasek: oh... hehe :)
[08:38] <dholbach> slangasek: I'll make sure to ping keybuk later on
[08:38] <dholbach> Excusez-moi Monsieur Langasek
[08:39] <slangasek> no worries
[08:39] <dholbach> hey seb128!
[08:39] <seb128> hello dholbach
[08:44] <seb128> is archive.ubuntu.com being slow for everybody today?
[08:46] <dholbach> seb128: it was ok for me some minutes ago
[08:47] <seb128> dholbach: weird, it's downloading at something like 17kbs here today
[09:19] <bryce> dholbach: I looked at the x11 one earlier today but we think it's going to be handled soon by debian anyway.  I just now sponsored the smplayer one.  For the merge, I'll look at it tomorrow, it's starting to get late here
[09:22] <dholbach> bryce: rock on
[09:22] <dholbach> bryce: sleep tight then :)
[09:51] <geser> StevenK: I can take over bug #163709. Can you look at bug #176411? (you did the last merge)
[09:51] <ubotu> Launchpad bug 163709 in wmclock "Please merge wmclock <IP_ADDRESS>-5ubuntu3 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/163709
[09:51] <ubotu> Launchpad bug 176411 in texlive-bin "[Sync request] Sync texlive-bin (2007.dfsg.1-2) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/176411
[09:54] <StevenK> geser: You have a deal
[10:13] <ion_> The 50-50-90 rule: anytime you have a 50-50 chance, there’s a 90% probability you’ll fail.
[10:21] <geser> Mithrandir: please give-back: tex-guy. Thanks.
[10:23]  * dholbach hugs super-geser
[10:23]  * geser hugs back dholbach
[10:24] <Mithrandir> geser: given-back
[10:31]  * Mithrandir wonders why pulseaudio needs 8% CPU on a GHz-class machine to play sound.
[11:12] <cVsup> i would like know how execute command in preseed file?
[11:25] <cjwatson> cVsup: use preseed/early_command or preseed/late_command. Have you read the examples in the installation guide?
[11:25] <cVsup> yes
[11:26] <cVsup> d-i preseed/late_command chroot /target script.sh
[11:26] <cVsup> correct?
[11:27] <ildella> hi all
[11:27] <cVsup> cjwatson, any idea?
[11:28] <ildella> I am getting crazy this morning cause Eclipse just stopped starting up due to some mysterious jvm frame problem...
[11:28] <ildella> found this bug: https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/174759/
[11:28] <ubotu> Launchpad bug 174759 in eclipse "eclipse crashes " [Undecided,New]
[11:28] <cjwatson> cVsup: fine provided that script.sh actually exists on the default path inside /target
[11:28] <Fujitsu> ildella: This isn't a support channel.
[11:28] <ildella> oh
[11:28] <ildella> sorry
[11:29] <ildella> what channel can I use?
[11:29] <cVsup> yes
[11:29] <cjwatson> cVsup: (and is executable)
[11:29] <cVsup> cjwatson, d-i preseed/late_command string
[11:29] <cVsup> need string?
[11:29] <cjwatson> cVsup: are you actually encountering a problem? if so, I need error messages (and #ubuntu-installer would be better)
[11:30] <Riddell> evand: have you seen this bug? https://bugs.edge.launchpad.net/ubuntu/+source/parted/+bug/107326
[11:30] <ubotu> Launchpad bug 107326 in parted "non working gpt labels" [Undecided,Confirmed]
[11:30] <cVsup> cjwatson, i need change usplash.conf for resolve problem white screen
[11:30] <cVsup> with
[11:31] <Riddell> enrico: seems the ept build failure was a bashism, https://bugs.launchpad.net/ubuntu/+source/libept/+bug/177033
[11:31] <ubotu> Launchpad bug 177033 in libept "FTBFS: ept/runtest fails with recent dash version" [Undecided,Fix released]
[11:32] <cjwatson> cVsup: messing around with a separate script.sh seems overkill when you could just put the shell commands you need directly in the preseed/late_command string
[11:32] <cjwatson> Riddell: evand's off this week
[11:32] <enrico> Riddell: oh, I see.  So I can find the fix in the ubuntu patch, right?
[11:32] <enrico> good opportunity to have a look at that
[11:32] <cjwatson> Riddell: IIRC the gptsync patch to parted was still needed even with the grub change
[11:33] <cjwatson> and yes, it violates the standard, but so does Apple
[11:34] <cjwatson> I think the suggestion to conditionalise it on <2TB is probably about right
[11:35] <Riddell> enrico: yes it is, or just on that bug report
[11:35] <cjwatson> or maybe just conditionalise it on is-a-Mac
[11:35] <cjwatson> (unfortunate but there you go)
[11:36] <cjwatson> that's fiddly as hell to work out, though, argh
[11:36] <tjaalton> what's the status of python-brlapi?
[11:37] <tjaalton> gnome-orca depends on it, but it's not available
[11:39] <Riddell> interesting, thanks cjwatson
[11:40]  * Hobbsee waves
[11:41]  * Mithrandir tickles Hobbsee, then levitates off the ground, out of her reach.
[11:41] <tjaalton> oh, brltty 3.9-5u1 is in NEW
[11:41]  * Hobbsee pops Mithrandir with a pin
[11:41] <Hobbsee> hrm, we're making progress
[11:42] <Hobbsee> hardy has been alive for 6 minutes, and hasn't frozen yet
[11:43] <seb128> Hobbsee: hardy frozen yet?
[11:43] <Hobbsee> seb128: soft freeze, i believe.
[11:43] <Hobbsee> i've been at work
[11:44] <seb128> Hobbsee: do you use compiz? try disabling the animation thing there
[11:44] <Hobbsee> seb128: yes.
[11:44] <Hobbsee> seb128: ahh, is animation what's being blamed
[11:44] <Hobbsee> seb128: they say they've fixed some crashes, and it seems stabler now
[11:44] <Hobbsee> usually, my compiz would have hardlocked by now.
[11:44] <seb128> well, that's what is freezing on my laptop installation
[11:45] <seb128> when I ssh to the box compiz is eating cpu
[11:45] <tjaalton> could someone shove the new brltty out of NEW, because I can't build a livecd due to gnome-orca being uninstallable
[11:45] <seb128> anyway mvo adviced not using animation and compiz didn't hang since
[11:45] <tjaalton> and I need to test a fix for livecd-rootfs
[11:45] <Hobbsee> seb128: gotcha.  will try it, if i find it hardlocks again
[11:46] <seb128> tjaalton: looking
[11:47] <juliank> Hi everyone. I wrote a small script to create an Ubuntu USB Stick, with persistent support (incl. partitioning the usb stick). Something like this would be cool to have on the disk: http://jak-linux.org/tmp/iso2usb.sh  - But it's not finished yet.
[11:48] <tjaalton> seb128: thanks
[11:48] <Fujitsu> seb128: Can you magic-SysRq+K out of it?
[11:48] <seb128> juliank: hi, you should rather mail the ubuntu-devel list to describe the idea, etc
[11:48] <tjaalton> also, openoffice build-depends on libflute-1.3-jfree-java, which is in universe
[11:48] <seb128> Fujitsu: didn't try
[11:48] <seb128> Fujitsu: I can ssh and restart compiz
[11:49] <Fujitsu> seb128: Aha, so it's similar to what I get.
[11:49] <cjwatson> mjg59: bug 107326; you don't fancy nicking the minimalist dmidecode implementation out of libdebian-installer/src/system/subarch-x86-linux.c and conditionalising gptsync vs. pmbr on that, do you?
[11:49] <ubotu> Launchpad bug 107326 in parted "non working gpt labels" [Undecided,Confirmed] https://launchpad.net/bugs/107326
[11:50] <mjg59> cjwatson: Wurgh. It'd be a miserable layering violation in the parted code.
[11:51] <mjg59> cjwatson: I'd be happy to make it x86/non-x86 dependent
[11:51] <mjg59> We're not going to support installs on x86 EFI for ages, so it's not really an issue there
[11:52] <cjwatson> mjg59: err, the people in the bugs are talking about x86 I'm pretty sure
[11:52] <mjg59> cjwatson: Oh, ah, hrm.
[11:52] <cjwatson> mjg59: we don't have to support installs on them - the boot drive can be MBR and you can have a separate GPT RAID
[11:52] <cjwatson> say
[11:52] <cjwatson> then I don't think you need EFI
[11:53] <cjwatson> I think pulling disks out of Macs and repartitioning them on other systems is honestly vanishingly rare
[11:53] <mjg59> Yes
[11:53] <cjwatson> and yeah, it's a layering violation, but in exactly the place where we've been screwed by differing EFI implementations
[11:54] <mjg59> I'm intruiged by why it's going wrong. I suspect we'd be better off if the kernel preferred GPT tables to EFI ones.
[11:54] <cjwatson> there's a comment in libparted about why that was changed
[11:55] <mjg59> s/EFI/MBR/
[11:55] <cjwatson> it's a reasonable point that there is no way to generate a sane legacy MBR for a >2TB disk, so we shouldn't
[11:55] <mjg59> Yes, that's probably fair
[11:55] <cjwatson> so if you'd rather that that be the condition, that doesn't seem too bad to do in parted
[11:56] <mjg59> Though in that case, we'd still need to add support for it creating logical partitions in the mbr
[11:56] <cjwatson> urgh, true
[11:56] <mjg59> Which we probably should do anyway
[11:57] <cjwatson> the Apple test seems like an easier stopgap to plug the data loss
[11:59] <mjg59> Yeah. Hrm.
[12:00] <mjg59> cjwatson: Anyway. DMI information is exported via sysfs on 2.6.24
[12:00] <mjg59> So just read, strcmp and get on with it
[12:00] <cjwatson> oh, that's good
[12:04] <cjwatson> I've added this to the gutsy release notes for the time being
[12:04] <cjwatson> (on the wiki at any rate)
[12:41] <Lure> dholbach: have closed bug 172755 (sponsoring asigned to imbrandon)
[12:41] <ubotu> Launchpad bug 172755 in tripod "Rebuild for libgpod2 -> libgpod3 transition" [Low,Fix released] https://launchpad.net/bugs/172755
[12:42] <dholbach> Lure: great
[12:42]  * imbrandon looks up
[13:01] <pgquiles> cjwatson: ping
[13:01] <cjwatson> pgquiles: pong
[13:03] <pgquiles> cjwatson: regarding bug 107326, I think what happens on Macs is a lot less important than what happens on every other machine. Surely Macs account for a very small percentage of Ubuntu installations. This bug should be fixed soon, Hardy should have a fixed GNU Parted.
[13:03] <ubotu> Launchpad bug 107326 in parted "non working gpt labels" [Undecided,Confirmed] https://launchpad.net/bugs/107326
[13:04] <cjwatson> pgquiles: my comments on the bug were not remotely intended to indicate that the bug should not be fixed. I was discussing it with mjg59 here earlier.
[13:04] <cjwatson> pgquiles: it is perfectly possible to keep both working
[13:04] <pgquiles> cjwatson: I didn't mean you meant it should not be fixed :-)
[13:04] <cjwatson> you rather implied it
[13:05] <mjg59> pgquiles: I strongly suspect that the number of users running Ubuntu on Macs is greater than those running it on systems with 2TB+ filesystems.
[13:05] <pgquiles> cjwatson: I'm sorry, I'm not a native English speaker O:-)
[13:05] <mjg59> But yes, you're right. It will be fixed. We're determining the best way of doing so.
[13:05] <pgquiles> mjg59: I wouldn't be so sure, specially for ubuntu-server and specially for the next 5 years given that Hardy is LTS
[13:06] <cjwatson> pgquiles: there is no need to persuade us about the importance of the bug
[13:06] <pgquiles> the bug was present in edgy, feisty and is in gutsy
[13:06] <cjwatson> pgquiles: I had simply missed it
[13:06] <pgquiles> cjwatson: I was not trying to tell you off, we are all humans :-)
[13:07] <cjwatson> I have set its priority and targeted it to hardy
[13:07] <pgquiles> great, thank you
[13:07] <cjwatson> I find it implausible that the bug was present in edgy, at least in the same form
[13:07] <cjwatson> the gptsync patch to parted was introduced in feisty
[13:08] <mjg59> Tch. What do I file a bug against in order to request package removal?
[13:08] <StevenK> mjg59: The package itself
[13:08] <seb128> mjg59: the corresponding package and subscribe ubuntu-archive to the bug
[13:09] <mjg59> Ok
[13:09] <StevenK> mjg59: And then poke someone here
[13:09] <seb128> StevenK: that's not the right way ;-)
[13:09] <StevenK> Last part completly optional. :-)
[13:09]  * StevenK pokes seb128 about gimp
[13:09] <pgquiles> cjwatson: you are right, the gpt patch in edgy is a different one. My bad.
[13:12] <seb128> StevenK: well, I would not do it this way but I'm not approving srus neither, better to ask pitti what he thinks about it when he'll be around
[13:13] <StevenK> It seemed the simplest way without going insane
[13:14] <StevenK> steven@liquified:~/ubuntu/fftw-cruft% version-bump -u
[13:14] <StevenK> Ubuntu mode enabled - new version prefix ubuntu1
[13:14] <StevenK> Hah
[13:17] <mjg59> slangasek: #177154 (from our earlier conversation)
[13:18] <siretart> mjg59: thanks for CCing me
[13:19] <mjg59> siretart: No problem
[13:20] <cjwatson> slangasek: ubiquity uploaded per your earlier request
[13:24] <persia> mjg59: Usually one tries to eliminate all the rdepends first.  In this case, it looks like about 20.  Should these all be migrating to rely on wodim?
[13:25] <mjg59> persia: cdrecord is in multiverse. There's nothing interesting that actually neesd it
[13:25] <mjg59> persia: And when it comes to copyright infringement, then we remove first and ask questions later
[13:26] <StevenK> Gar, didn't siretart try really hard to get cdrecord into multiverse?
[13:26] <Mithrandir> he did
[13:27] <persia> mjg59: No, but a lot of things that don't really need it have a dependency due to never having been transitioned to an alternative.
[13:27] <StevenK> I think I questioned him at the time
[13:27] <Mithrandir> we could castrate cdrtools to not build mkisofs
[13:27] <mjg59> persia: Unless those things are in multiverse, it's not an issue
[13:28] <siretart> StevenK: there are negotiations ongoing atm. joerg has just been sent an email, and I'm curious to read his answer
[13:28] <Mithrandir> siretart: would be so kind as to make cdrtools not build mkisofs for the time being?
[13:28] <StevenK> I'm not. cdrecord can get out and stay out, as far as I'm concerned.
[13:28] <cjwatson> is there good reason to believe that these negotiations will be more fruitful than endless previous negotiations with Joerg?
[13:29] <cjwatson> it's not as if this is a new problem
[13:29] <persia> mjg59: Actually, about half are in universe (in violation of universe ! depends on multiverse) according to debcheck.  I agree with remove-first-ask-questions-later, just was curious if you had thought about transition, so as to try to get it completed.
[13:29] <mjg59> persia: I was under the impression that there was supposed to be some sort of transition package
[13:29] <siretart> cjwatson: I do have reasons to beleive so, mainly because this time, the negotations are kept in private
[13:29] <persia> mjg59: The transition package was removed when cdrecord was added to multiverse (see parallel thread in this channel)
[13:30] <cjwatson> mjg59: there was. siretart intentionally removed it
[13:30] <siretart> Mithrandir: sure. could you elobarate a bit why?
[13:30] <mjg59> persia: Well, that was an error :)
[13:30] <cjwatson> siretart: I believe there have been attempts at private negotiation in the past, too
[13:30] <mjg59> Well, we've made some progress
[13:31] <Mithrandir> siretart: see bug 177154.
[13:31] <ubotu> Launchpad bug 177154 in cdrtools "cdrtools is undistributable" [Undecided,New] https://launchpad.net/bugs/177154
[13:31] <Mithrandir> siretart: so unless mjg59 is wrong in his bug report (which I haven't checked, but I have no reason to believe he is wrong), we should either kill off mkisofs from cdrtools for the time being or remove the package.
[13:33] <siretart> Mithrandir: tbh, I think since joerg has now waited for matthews answer so long (he has bugging me the last 2 weeks weekly on irc), we should give him some time to answer before we kill cdrtools (again)
[13:33] <StevenK> Personally, not that my opinion matters much, I remain unconvinced we need cdrtools at all.
[13:33] <siretart> unless there are compelling reason to do so at once
[13:49] <Mithrandir> siretart: it doesn't seem like Joerg has any interest in contributing constructively to the discussion.
[13:51] <siretart> Mithrandir: I'm currently having a query with him, and I have another impression
[13:51] <Mithrandir> his comment in the bug report is "you don't understand the GPL, go away"
[13:52] <mjg59> siretart: I should emphasise that the only way to deal with the mkisofs issue is to license the libraries and build system under a GPL-compatible license (optionally along with the CDDL)
[13:52] <lamont> where is bddebian when I want to grumble at him
[13:53] <mjg59> siretart: Either that, or we need to hear from every mkisofs and libhfs_iso copyright holder
[13:57] <siretart> mjg59: he seriously doesn't understand the GPL this way, but argues in corner cases that apply at least to german and US law, and states that since all contributers are either germans or US citizens, this would apply here
[13:58] <mjg59> siretart: Except for the Swedish ones
[13:58] <cjwatson> siretart: and the British ones
[13:58] <StevenK> So, he's on crack, as usual
[13:59] <siretart> it's really hard to discuss this over channel boarders
[13:59] <siretart> StevenK: so having a different opinion qualifies as being on crack?
[13:59] <cjwatson> oh, maybe not British, the cdrtools package no longer has Steve's JTE patch
[13:59] <siretart> shall I invite him?
[13:59] <cjwatson> ./mkisofs/mkisofs.c:30:/* APPLE_HYB James Pearson<EMAIL_ADDRESS>22/2/2000 */
[14:00] <cjwatson> so unless he was visiting from another country ...
[14:00] <siretart> heh
[14:01] <mjg59> schily: Hi
[14:03] <schily> mjg59 hi I have to complete my slides for a cdrtools talk....
[14:04] <mjg59> schily: No problem. There's no urgency about anything.
[14:06]  * Hobbsee whinges at BenC
[14:06] <Hobbsee> lamont: there you go
[14:06]  * lamont larts Hobbsee
[14:07] <lamont> we don't whinge or even whine at BenC
[14:07]  * Hobbsee larts lamont back, and sets his house on fire
[14:07] <Hobbsee> lamont: my wifi doesn't work on the new kernel :(
[14:08] <bddebian> Hey folks
[14:08] <BenC> Hobbsee: which chip?
[14:08] <Hobbsee> BenC: intel 3945
[14:08] <BenC> Hobbsee: make sure to install matching lum to get the firmware
[14:08] <bddebian> lamont: Uh oh, what did I break?
[14:09] <Hobbsee> BenC: alreayd got it.  it's loaded.  syslog says that the kill switch is on, though.
[14:09] <BenC> Hobbsee: hit the kill switch then :)
[14:09] <Hobbsee> BenC: duh.  done that.  no change.
[14:09] <Hobbsee> BenC: it was giving me a kill switch message even when it hadn't been touched from when it loaded gutsy, where it was on.
[14:09] <Hobbsee> BenC: i'm not *that* stupid :)
[14:10] <BenC> Hobbsee: hmm, definitely file a bug then
[14:10] <Hobbsee> BenC: any idea on how i can debug it further?
[14:10] <BenC> I know iwl3945 has been working for myself and rtg
[14:11] <BenC> Hobbsee: not sure...rtg is the man to talk to
[14:11] <Hobbsee> BenC: ok, thanks.
[14:13] <Hobbsee> BenC: i guess i'm asking...is there any way to force the kill switch on/off?
[14:13] <BenC> Hobbsee: modinfo iwl3945 and see if there is
[14:15] <Hobbsee> BenC: apparently not.  darn.
[14:21] <bddebian> lamont: A little too much debhelper for you?
[14:23] <Hobbsee> BenC: any idea when rtg would be around?
[14:23] <lamont> bddebian: 3 fixes. one diff.
[14:23] <lamont> *thwap*
[14:24] <bddebian> ?
[14:24] <lamont> and you added a build-dep on autocrap???  I fixed that
[14:24] <BenC> Hobbsee: very soon
[14:24] <lamont> 1) switch to debhelper.  2) standards version.  3) lintian errors
[14:24] <lamont> admittedly, they cascade enough that taking them out of order is bad
[14:25] <lamont> bddebian: eventually, I gave up and called it one commit.
[14:25] <lamont> plus one for me to drop the auto* build-deps, and then merge it into my mess.
[14:27] <lamont> anyway, thanks
[14:28] <Hobbsee> hrm.  it's so nice that something apart from network mangler is spamming the syslog.
[14:29] <lamont> Hobbsee: network mangler doesn't spam my syslog.
[14:29] <lamont> oh right.  I purged it.  I remember now
[14:30] <Hobbsee> heh
[14:30] <Hobbsee> no, i'ts pulseaudio doing it now
[14:30] <bddebian> lamont: Ah, sorry.  You were autoreconf'ing so how did you drop the autotools stuff?
[14:30]  * lamont needs to add a crowbar patch to network mangler so that he can have it installed and dormant until he kicks it manually to do one round of network config
[14:30] <lamont> bddebian: separate target (autofiles) in debian/rules, and drop the build-depends
[14:31] <lamont> and about to drop the autofiles from source control
[14:31] <lamont> the generated autofiles, that is.
[14:31] <bddebian> lamont: Ah, OK
[14:31] <lamont> running auto* on each and every buildd is (1) wasteful and (2) frequently gets you the wrong result (as autocrap changes radically from version to version)
[14:32] <lamont> having said that, xdelta was using automake 1.4 (ew)
[14:33] <bddebian> lamont: Maybe I'm not understanding.  Weren't you doing that before?  Or not because you had the seperate target?
[14:33] <lamont> hrm...
[14:33]  * lamont doesn't remember
[14:33] <lamont> I'd made changes in my tree
[14:33] <lamont> I've been treating xdelta with benevolent neglect for quite some time.
[14:34] <seb128_> re
[14:34] <bddebian> lamont: OK.  Well I'll make sure I only send a patch at a time next time, sorry
[14:34] <seb128_> I had to reboot due network issue
[14:34] <bddebian> wb seb128_
[14:35] <bddebian> lamont: Oh, and one other thing.  I'm a little concerned about using dh_makeshlibs because I think it might be ignoring the libesio?
[14:35] <lamont> bddebian: 'twas only grumbling.  thank you very much for fixing things for debhe,per
[14:35] <bddebian> NP
[14:36]  * lamont will look into that
[14:45] <lamont> bddebian: that's right... now I remember the issue:
[14:45] <lamont> gcc -Wall -g -O2 -o .libs/edsiotest edsiotest.o  ./.libs/libedsio.so
[14:45] <lamont> edsiotest.o: In function `test6':
[14:45] <lamont>  /build/lamont/xdelta-1.1.3/libedsio/edsiotest.c:194: undefined reference to `g_log'
[14:45] <jikkejo> hello
[14:46] <bddebian> lamont: Ugh :(
[14:47] <lamont> something is dropping the glib stuff.  for the suck.
[14:50] <jikkejo> i found a problem with ubuntu 7.10 with ipw2100 wireless card and wpa_supplicant. It's impossible to configure the wireless card. I'm newbie, but it's impossible for me!
[14:50] <persia> jikkejo: This isn't really a support channel.  If you need help, try #ubuntu or #ubuntu-xx where xx is a country code.  If you have a bug, try #ubuntu-bugs.
[14:51] <jikkejo> oh sorry
[14:52] <jikkejo> but i want report a problem for developers
[14:53] <lamont> if you want to play with it, please start with 'git clone git://git.debian.org/~lamont/xdelta.git'
[14:53] <lamont> bddebian: ^^
[14:54] <lamont> jikkejo: that's where the bug tracking system on launchpad.net comes in handy....
[14:54] <lamont> since reporting bugs here gives no assurance that the right developers actually find out abiout it
[14:54] <jikkejo> lamont: ok sorry but i'm new!
[14:55] <bddebian> lamont: OK
[14:55] <lamont> jikkejo: no worries
[14:55] <lamont> bddebian: that's the current state of it... (and you'll want a git-core >= 1.5 or life sucks)
[14:55] <lamont> you can still checkout and such, but the user interface is not user-friendly
[14:56] <lamont> 1.5 was a serious overhaul of the UI
[15:03] <LongPointyStick> grumble.
[15:04] <LongPointyStick> so, the software and hardware rf_kill's are disabled...yet, there's still no flash of wifi
[15:07] <lamont> LongPointyStick: afraid it's gonna go "boom"?  or are you compensating?
[15:07]  * lamont ducks
[15:10] <Riddell> siretart: ping ping, libxine1 doesn't install unless you have universe enabled
[15:10] <Riddell> siretart: can you tell me what needs promoted?
[15:10] <bddebian> lamont: How would you feel about a new upstream release? :)
[15:10] <lamont> is there one?
[15:11] <lamont> bddebian: I said _NEGLECT_. :-)
[15:11] <bddebian> Aye, xdelta3.0t
[15:11] <siretart> checking
[15:11] <lamont> ah, that'd be the xdelta3 package
[15:11] <lamont> this is xdelta1
[15:11] <bddebian> Oh
[15:11] <bddebian> hrm
[15:11] <lamont> which leads directly to the neglect angle.
[15:14] <poningru_> soren, ping
[15:14] <soren> poningru_: Yes?
[15:14] <siretart> Riddell: libxine1-bin. that one contains now the shared object everything links against
[15:14] <poningru_> w00t
[15:14] <poningru_> soren, can I discuss iscsi stuff with you?
[15:14] <soren> poningru_: Sure thing.
[15:14] <poningru_> I want to help with that
[15:14] <poningru_> I started up the MIR
[15:14] <bddebian> lamont: Ah, there is a 1.1.4 though also it appears
[15:15] <soren> poningru_: Ah, that's very helpful. Thanks!
[15:15] <poningru_> soren, but have never done anything similar before
[15:15] <poningru_> so wondering if I was doing it right
[15:15] <soren> poningru_: It's quite simple, really. Fill in the blanks by looking up CVE's and stuff from Debian's bts and Launchpad.
[15:15] <poningru_> also I want to work on the ramdisk implementation
[15:16] <soren> poningru_: That would be nice. Do you happen to have hardware to test with?
[15:16] <soren> poningru_: ...because I don't.
[15:16] <poningru_> https://wiki.ubuntu.com/MainInclusionReportiSCSI
[15:16] <poningru_> oh you dont need hardware
[15:16] <poningru_> iscsi just goes over normal stuff
[15:16] <poningru_> as in tcp/ip
[15:17] <siretart> Riddell: can you promote libxine1-bin?
[15:17] <soren> poningru_: Yes, but it's kind of nice to have something to connect to in the other end, isn't it?
[15:18] <poningru_> yeah you can setup openfiler for that kinda stuff
[15:18] <poningru_> really easy to setup
[15:18] <soren> poningru_: I know there's iscsitarget, too, but I'd like to test with what our users are likely to see in the wild.
[15:18] <poningru_> soren, my thoughts exactly thats why I went with openfiler
[15:18] <Riddell> siretart: done
[15:18] <soren> poningru_: I'm not familiar with openfiler, I'm afraid.
[15:18] <siretart> Riddell: thanks a lot!
[15:19] <poningru_> http://www.openfiler.com/
[15:19] <siretart> Riddell: xine-lib is currently in debian NEW, so the next upload will be a sync request :)
[15:19] <poningru_> it has a virtual image
[15:19] <poningru_> and you can just connect internally
[15:20] <soren> poningru_: And this is what people use, you think?
[15:20] <poningru_> yeah atleast my uni uses that
[15:20] <soren> poningru_: Not dedicated boxes from Dell, Intel or whoever?
[15:20] <soren> poningru_: That's not a lot of empirical data..
[15:21] <poningru_> I know :P
[15:21] <poningru_> yeah I dont have a dedicated box  like that...
[15:21] <poningru_> hardware implementation of iSCSI is... weird and expensive
[15:22] <soren> Ok. I'm working on getting my hands on one. It'll be at least a few days before I'll need a target anyway.
[15:22] <soren> poningru_: I know. That's why I don't have one yet.
[15:22] <poningru_> ooh cool
[15:22] <soren> :)
[15:23] <poningru_> but I dont think there is that much difference in target implementation
[15:23] <poningru_> as in its not like the web
[15:24] <soren> Sure.. I'm just a bit reluctant to put stuff out in the wild saying: "Here' this stuff works and is really good", and as soon as anyone uses it with something other than iscsitarget (which I'm guessing is what openfiler uses), it breaks in weird ways.
[15:25] <soren> Of course, I could just rely on other people testing it, but experience tells me that the more expensive the hardware, the less inclined people are to test it.
[15:26] <poningru_> I'true
[15:26] <soren> ..since if it's expensive, it's probably a really important part of the infrastructure, so you can't affort to have it offline for even a short amount of time to test random stuff.
[15:26] <poningru_> well... connecting to stuff shouldnt take it down... atleast I hope
[15:30] <poningru_> soren, but yeah I'll test stuff out with enterprise target thing
[15:32] <soren> poningru_: Sounds lovely!
[15:32] <soren> poningru_: So you want to do the initramfs hooks?
[15:37] <poningru_> yeah
[15:39] <poningru_> when does that need to be done?
[15:39] <poningru_> can you give me a deadline?
[15:40] <soren> Tomorrow's fine.
[15:40] <soren> :)
[15:40] <poningru_> :p
[15:41] <soren> It's not particularly urgent. Hang on, I'll check the schedule.
[15:42] <soren> Well, it's too late for alpha 2 anyway. Alpha 3 is January 10th.
[15:43] <poningru_> I hmm
[15:43] <poningru_> Jan 5th sound good?
[15:43] <mario_> siretart: poke?
[15:44]  * siretart dislikes this virtual tennis
[15:44] <soren> poningru_: That might work.
[15:44] <poningru_> sweet
[15:45] <pygi> siretart: you have time?
[15:45] <pygi> 5 minutes
[15:46] <siretart> what's up?
[15:47] <pygi> schily: poke? :)
[16:01] <Riddell> mvo: were you able to recreate bug 156320 ?
[16:01] <ubotu> Launchpad bug 156320 in update-manager "[kde] copy XAUTHORITY may fail and crashes the upgrader (was: Upgrade tool crashed when upgrading 7.04 -> 7.10)" [Medium,Confirmed] https://launchpad.net/bugs/156320
[16:06]  * lamont sighs about nmap 4.50 lacking an assembled list of copyright holders adds that to his list of things to do over christmas break
[16:06] <mvo> Riddell: I don't think so, but let me re-check
[16:09] <Riddell> mvo: you confirmed it
[16:12] <mvo> Riddell: *cough* right. I think I confirmed it because there is no check if the environment that XAUTHORITY points to actually exists prior to the shutil.copy I think
[16:53]  * mvo grumbles about the dpkg-divert handling in slocate
[16:54] <Mithrandir> mvo: or lack thereof, I suspect?
[16:54] <mvo> Mithrandir: heh :) yeah, its pretty fragile and breaks (depending on the order of install/upgrade) on gutsy->hardy upgrades
[16:57] <lamont> mvo: suckage
[18:00] <slangasek> cjwatson: thanks for the ubiquity upload
[18:01] <slangasek> mjg59: ah, #177154 is looking interesting already...
[18:09] <mjg59> slangasek: Only the best for you
[20:46]  * lamont heads officewards
[21:05] <soren> Hm.... What's the purpose of the device nodes in /lib/udev/devices ?
[21:08] <torkel> soren: In case you have no more left in /dev ?
[21:08] <torkel> :-)
[21:08] <soren> torkel: Possibly :)
[21:10] <cjwatson> the ones in /lib/udev/devices are copied in at boot as a quick way to seed the /dev tmpfs
[21:10] <cjwatson> /etc/init.d/udev
[21:11] <cjwatson> I assume it's just less code that way or something
[21:19] <soren> cjwatson: Ah, right. Thanks.