[05:23] <sakhi> mooning
[05:45] <alkisg> Good morning
[14:39] <sbalneav> Morning all
[14:53] <HedgeMage> hi, sbalneav
[14:57] <sbalneav> Morning HedgeMage
[16:17] <alkisg> !info ltsp-docs lucid
[17:16] <Ahmuck> anybody using ubuntu cloud computing?
[17:29] <sbalneav> Ahmuck: Nope.  Can't.
[17:30] <Ahmuck> sbalneav: can't in edubuntu?
[17:31] <sbalneav> No, I can't no matter what I run.
[17:31] <sbalneav> I work in the Legal industry.
[17:32] <mhall119|work> sbalneav: what does that have to do with cloud computing?
[17:32] <sbalneav> I get called to court by the judge to give a chain-of-custody testimony on some electronic evidence.  Judge says: "So, who had access to this data?"
[17:32] <Ahmuck> *snark*
[17:33] <sbalneav> "Potentially anyone in the cloud" isn't the correct answer.
[17:33] <Ahmuck> that is the problem with the cloud
[17:33] <Ahmuck> no privacy
[17:33] <Ahmuck> i know big corps are pushing "internet only" apps, and cloud computing, because they want control of "all your data", but i can't see this working in the long run
[17:34] <Ahmuck> my situatuion is that i was looking at teaching a class using hugin
[17:34] <Ahmuck> and wondered if there was a way to offload the processes and stitching of hugin into the cloud
[17:34] <mhall119|work> private clouds
[17:34] <mhall119|work> are no different than private servers
[17:38] <sbalneav> Cloud computing, IMHO, is the biggest freaking scam ever.  It's nothing being marketed as something.
[17:38] <mhall119|work> it's something
[17:38] <mhall119|work> it's just not what it's being hyped as being
[17:38] <sbalneav> Yeah?  What is it.
[17:38] <sbalneav> Tell me.
[17:38] <mhall119|work> it's flexible deployment
[17:38] <mhall119|work> and allocation
[17:38] <sbalneav> That's another buzzword
[17:39] <mhall119|work> it's being able to double your available resources in short order
[17:39] <sbalneav> Servers can be flexibly deployed.  And allocated.
[17:39] <sbalneav> How?
[17:39] <mhall119|work> and back it down again when it's not needed
[17:39] <sbalneav> How?
[17:39] <mhall119|work> sbalneav: yes, they can be
[17:39] <mhall119|work> and when there is a software product that does this for you, they call it cloud
[17:39] <sbalneav> What software product?
[17:39] <sbalneav> apt-get install <what>?
[17:40] <mhall119|work> ecalyptus
[17:40] <mhall119|work> eucalyptus
[17:42] <sbalneav> Which requires that I re-write entire apps to handle this Cloud thing.
[17:42] <sbalneav> which is distributed computing
[17:42] <sbalneav> which I studied in university 20 PLUS YEARS AGO.
[17:43] <sbalneav> like I say, it's nothing that hasn't been around since forever.
[17:43] <sbalneav> and it's useless to ANYONE who actually cares about their data.
[17:43] <mhall119|work> sbalneav: not quite distributed computing
[17:43] <mhall119|work> a cloud doesn't appear as one big instance
[17:43] <mhall119|work> it's more like dynamically-managed clustering
[17:44] <sbalneav> Which has been around forever as well.
[17:44] <sbalneav> it's just the latest buzzword for technologies that have been around for ages.
[17:44] <sbalneav> i.e., it's nothing.
[17:45] <sbalneav> Anyway, that's how I see it.  YMMV :)
[17:45] <Ahmuck> mhall119|work: so, would the software cloud do something like hugin?
[17:45] <Ahmuck> ah, apps have to be re-written?
[17:45] <Ahmuck> so in reality, there are prolly few apps that could even leverage the cloud environment?
[17:45] <alkisg> Well, when it reaches the masses as "boot your device and you have everything without installing anything", it'll be something :)
[17:46] <mhall119|work> Ahmuck: I'm not familliar with hugin
[17:46] <alkisg> You could even have "pay per use" programs there. No more extreme licensing fees for something that you use once in a while
[17:46] <sbalneav> mhall119|work: it's a program to paste multiple pictures together into a panorama.
[17:46] <mhall119|work> sbalneav: it's not a new idea, no, it's just something that is now going mainstream
[17:47] <mhall119|work> Ahmuck: in a cloud, you get an OS on each "node", your apps just have to be able to work in a clustered setup
[17:47] <mhall119|work> sbalneav: ah, ok
[17:47] <mhall119|work> Ahmuck: think of Apache clustering
[17:47] <mhall119|work> which has been around for a while
[17:48] <mhall119|work> all that cloud computing lets you do is add and remove nodes from the cluster without having to reconfigure or restart anything
[17:49] <alkisg> And management would be done centrally, so users won't have to install stuff, protect themselves from antivirus, backup etc etc
[17:49] <alkisg> It's a nice idea, I hope it's implemented and marketed properly...
[17:49] <mhall119|work> it's new in it's implementation, not it's design
[17:50] <alkisg> Well selling apps in a different way is a different design
[17:50] <mhall119|work> for example, you can buy a cluster of 5 virtual machines from Amazon to run hugin, and then when it get's featured on Slashdot or Fark, you can tell Amazon to give you 20 or 50 or 100 instances instead
[17:50] <mhall119|work> until the demand dies back down, then you tell Amazon to go back to 5
[17:52] <alkisg> Actually cloud has a lot in common with LTSP ;)
[17:52] <alkisg> (cluster)
[17:52] <Ahmuck> alkisg: how so?
[17:53] <alkisg> People having dumb terminals and connecting to applications servers
[17:53] <Ahmuck> well, that's what i thought
[17:54] <Ahmuck> any chance of offloading office, etc. to the cloud ?
[17:54] <Ahmuck> or anything for that matter, using ltsp server as a passthrough?
[17:54] <Ahmuck> ie, while keeping ltsp as a server for other apps?
[17:54] <mhall119|work> Ahmuck: think of a cloud as a vague collection of individual computers
[17:55] <mhall119|work> they don't act like a single computer, like distributed computing
[17:55] <Ahmuck> agreed
[17:55] <mhall119|work> but the actual number and location of the computers isn't important to you
[17:55] <alkisg> Well I haven't read of any marketing plans, but I guess the future is in server based computing.  Sure, LTSP can do that, and I hope it does...
[17:56] <Ahmuck> that might be a problem for privacy
[17:56] <Ahmuck> though quickbooks now uses google to do the searcing inside of it
[17:56] <alkisg> Not if proper encryption is used
[17:56] <Ahmuck> which i consder monsterarilsy dangerous
[17:56] <alkisg> Why?
[17:56] <Ahmuck> big brother
[17:56] <alkisg> With encryption?
[17:57] <alkisg> If your data is uploaded in an encrypted disk on the cloud, noone could read it without your key
[17:57] <alkisg> But, if the company is untrusted, of course they could fake the encryption :D
[17:57] <Ahmuck> well, my overactive imagination and paranoia kicks in here.  in that i don't believe anything is really encrypted
[17:57] <Ahmuck> only believed to be encrypted
[17:58] <alkisg> Right. Someone should check in depth all of those web space providers...
[17:58] <mhall119|work> the biggest point about cloud computing that is often missed is that your cloud doesn't have to be hosted by a 3rd party
[17:58] <Ahmuck> anywho, i know the plan for computing for the last 10 years has been to move users to "cloud" and web based apps.  i did run across that paper somewhere
[18:01] <Ahmuck> mhall119|work: light bulb just went on
[18:01] <Ahmuck> in other words, one could build a cluster in house to offload to the server
[18:02] <mhall119|work> what do you mean "to offload to the server"?
[18:02] <Ahmuck> ie, what's happening then is ltsp server offloads it's load to the cluster in house
[18:02] <Ahmuck> offload from the server
[18:02] <Ahmuck> "in house"
[18:02] <mhall119|work> uh, not quite
[18:02] <Ahmuck> sorry, i've been irc speaking and im speaking for too long, as a result it breaks my normal conversation up
[18:03] <Ahmuck> no?
[18:03] <mhall119|work> can you cluster LTSP servers?
[18:03] <mhall119|work> or is there always just one?
[18:03] <Ahmuck> ltsp client --> resource hungry app --> ltsp server --> server load --> internal cloud (cluter)
[18:04] <Ahmuck> er, cluster
[18:04] <Ahmuck> iirc, i think you can cluster now, no?
[18:04] <Ahmuck> for me it's just one
[18:04] <mhall119|work> if you can cluster LTSP, then here is how you would use the cloud:
[18:04] <mhall119|work> You have a 20 seat lab
[18:04] <mhall119|work> so you have enough LTSP server instances to manage 20 seats
[18:05] <mhall119|work> suddenly they need 100 seats for a special week long event
[18:05] <mhall119|work> so you expand your cloud with enough LTSP servers to handle 100 seats
[18:05] <mhall119|work> at the end of the week, you shrink your cloud back down again
[18:05] <Ahmuck> k, that makes sence
[18:05] <sbalneav> by what?  Returning the servers to the vendor? :)
[18:05] <mhall119|work> sbalneav: no
[18:06] <mhall119|work> by making those servers available to something else
[18:06] <Ahmuck> i was thinking more along the lines, i have a 20 seat lab which is used for OO.o, firefox, edu apps.
[18:06] <Ahmuck> then i want to teach class2 of hugin, the part where we take each user's set of photos for a gigapan, ie, 180 photos,
[18:06] <mhall119|work> here's where cloud computing is going:
[18:06] <Ahmuck> upload them to the server,
[18:07] <mhall119|work> say you have an idea for a cool new webapp, like hugin
[18:07] <Ahmuck> and then start the control point finding and stitching
[18:07] <mhall119|work> you get some startup funding, and buy yourself a couple of heft servers
[18:07] <Ahmuck> this requires huge memory and processing resources
[18:07] <mhall119|work> you can handle 1000 sessions a day
[18:07] <mhall119|work> suddenly you're the hot new thing, and you're getting 1,000,000 sessions a day
[18:08] <mhall119|work> now, you have a private cloud on servers you manage
[18:08] <Ahmuck> so, offloading this to the another "cluster" to do the work, which can be done with text .pto files would work
[18:08] <mhall119|work> but, in the near future, you can grown that cloud onto Amazon's servers too
[18:08] <Ahmuck> and wouldn't affect the other 10 clients in the other classroom
[18:08] <mhall119|work> Ahmuck: I don't think any cloud offerings currently do that for you
[18:09] <mhall119|work> you'd have to manage the offloading yourself
[18:13] <Ahmuck> mhall119|work: actually your explanation helped out a lot
[18:14] <Ahmuck> Elasticity
[18:14] <Ahmuck> Applications can dynamically use more resources within the cloud when required ensuring users needs are met immediately.
[18:14] <mhall119|work> right
[18:14] <Ahmuck> Bursting
[18:14] <Ahmuck> Overloaded applications running on your private cloud can expand to use resources from the public cloud.
[18:14] <Ahmuck> this was from ubuntu's cloud page
[18:14] <mhall119|work> that's not available yet, last I heard
[18:14] <Ahmuck> which made me wonder if it was possible
[18:14] <mhall119|work> but is coming
[18:15] <Ahmuck> that's what i was looking for
[18:15] <sbalneav> so long as, and this is key here, your application is written using a very specific set of libraries.
[18:15] <mhall119|work> again, though, it doesn't offload them
[18:15] <mhall119|work> it just adds someone else's servers to your cloud
[18:15] <Ahmuck> try putting 10 students into a room doing a monthly journal, etc. and let them upload photos on each page
[18:15] <Ahmuck> it comes to a grinding halt
[18:15] <mhall119|work> sbalneav: you can run a generic Ubuntu Server instance in the cloud
[18:16] <mhall119|work> the only specialization your software needs is the ability to manage a cluster of itself
[18:16] <Ahmuck> using scribus
[18:17] <Ahmuck> hrm, could that mean that a cluster managment plugin could be written that was universel enough that it could be dropped in applications without much trouble?
[18:17] <sbalneav> mhall119|work: So I can create this cloud, and users log into their ltsp server, click on openoffice, and of the 30 machines in the cloud, each of them is only running 1-2 openoffice sessions?
[18:17] <mhall119|work> Ahmuck: if LTSP cna be clustered, and you have some available resources, then cloud computing would let you make a bigger cluster during that class
[18:17] <mhall119|work> sbalneav: I don't know about LTSP specifically, how it does server clustering
[18:18] <mhall119|work> Ahmuck: not really, no
[18:18] <mhall119|work> clustering is pretty implementation-specific
[18:18] <sbalneav> By having multiple ltsp servers, and round-robining entire sessions amongst all the boxes.
[18:18] <sbalneav> but that's clustered LTSP servers
[18:18] <Ahmuck> i recall attempting a bewolf cluster with some 500mhz machines way back in the day
[18:18] <mhall119|work> sbalneav: round robin through DNS?
[18:19] <sbalneav> we're talking about a cloud that I *just* want for one application.  Openoffice.
[18:19] <sbalneav> All my other apps run fine on one box.
[18:19] <mhall119|work> cloud instances run an OS, not individual applications
[18:19] <Ahmuck> clustering software iirc
[18:19] <sbalneav> So they're virtual servers, then.
[18:20] <sbalneav> No different from having a KVM or vmware pool, like I have today.
[18:27] <alkisg> Doesn't cloud also contain software as a service, not only platform as a service?
[18:27] <mhall119|work> sbalneav: correct
[18:28] <mhall119|work> in fact, Eucalyptus uses KVM instances
[18:28] <mhall119|work> all cloud does is give you management tools on top of them
[18:30] <sbalneav> mhall119|work: thank you. Cloud == all the stuff I already have + nice frontend. :)
[18:30] <mhall119|work> sbalneav: yes
[18:30] <sbalneav> And that's my point.  Cloud's nothing but all the stuff we already have, just a shiny new management interface.
[18:31] <alkisg> Well, the web is also just apps & data, which we already had :)
[18:31] <sbalneav> Oh, and people putting up public servers for nothing, so long as you don't mind/don't have legislation against storing customer/student/your data on publicly available machines.
[18:31] <sbalneav> here's my problem with the whole thing:
[18:32] <sbalneav> it's being sold to people as a panacea that will solve all their problems.  Guys like Ahmuck.
[18:32] <Ahmuck> :p
[18:32] <sbalneav> No money? CLOUD No resources? CLOUD better expandability? CLOUD!!!!!!
[18:32] <Ahmuck> heh, the less time i have to figure is the more time i have to take panographs :)
[18:33] <sbalneav> then, when you actually figure it out, it's the same thing we've had all along.
[18:34] <sbalneav> I'd bet $20 Ahmuck's got legislation covering student data that will prevent him from migrating ONE CPU CYCLE off of stuff he controls into the public cloud.
[18:34] <sbalneav> so, he's forced to build his own cloud.
[18:34] <sbalneav> but "his own cloud" doesn't (really) solve any problems for him.
[18:34] <sbalneav> he's still gotta buy machines
[18:34] <sbalneav> still gotta set 'em up
[18:35] <sbalneav> still gotta fix 'em when they break.
[18:35] <alkisg> sbalneav: look after our retirement, some decades later. Dumb terminals. No administration at all. Power on. Select application or site. Power off. No viruses to worry about, no data loss to worry about, no formats etc. It'll happen.
[18:36] <sbalneav> THAT's what I object to.  The marketing that "Cloud computing will revolutionize everything" when cloud computing ISN'T anything revolutionary.
[18:36] <sbalneav> alkisg: No it wont.
[18:36] <alkisg> It isn't. It's just a product, not something for scientific research...
[18:36] <sbalneav> Who's going to pay for all those boxes?
[18:37] <sbalneav> And who's going to guarentee your data's integrity?
[18:37] <alkisg> Companies will emerge which will only have the hardware
[18:37] <sbalneav> backups?
[18:37] <alkisg> Other companies will rent hardware and run software on them
[18:37] <alkisg> Who's backing up your gmail?
[18:37] <sbalneav> Don't have gmail
[18:38] <alkisg> OK, but you do understand what I mean... :)
[18:38] <sbalneav> Sure.
[18:38] <sbalneav> till you lose your gmail.
[18:38] <Ahmuck> sbalneav: i was looking for this: overloaded applications running on your private cloud can expand to use resources from the public cloud, Applications can dynamically use more resources within the cloud when required ensuring users needs are met immediately.
[18:38] <sbalneav> just like those cell phone customers at dangerous.
[18:38] <Ahmuck> those two things
[18:38] <alkisg> If I'm paying, I won't lose it
[18:38] <sbalneav> alkisg: HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
[18:39] <alkisg> Customers always pay. They'll pay less for hardware, and more for software...
[18:39] <sbalneav> just like those cell phone customers were paying?
[18:39] <sbalneav> You're funny.
[18:39] <alkisg> I don't know the story...
[18:39] <alkisg> But why, do you lose your back account data?
[18:39] <alkisg> I wouldn't deposit money on banks then...
[18:40] <sbalneav> Right, but the bank HAS to have my data, I'm not expected to.
[18:40] <sbalneav> Who's responsible for the "cloud"?
[18:40] <Ahmuck> ur taxes
[18:40] <sbalneav> My taxes?
[18:40] <alkisg> Who's responsible for the internet?
[18:40] <sbalneav> My taxes in canada are going to yahoo's cloud servers?
[18:40] <sbalneav> really?
[18:41] <Ahmuck> actually there is a good case here
[18:41] <Ahmuck> UPS has electronic billing
[18:41] <Ahmuck> and if you don't pick up your invoice within a specified time period, they won't let you have it
[18:41] <Ahmuck> which is bunk
[18:41] <sbalneav> and Ahmuck, like I say, I bet there's NO WAY from a legislation point of view you're ALLOWED to put student information on a cloud device, for Student Privacy concerns.
[18:41] <Ahmuck> sbalneav: in some part, international trade agreements
[18:42] <Ahmuck> personal private information
[18:42] <Ahmuck> ie, personal details
[18:43] <Ahmuck> but i doubt it would cover the use of the cloud to do proc and mem intensive things like control point finding and stitching
[18:43] <Ahmuck> sorry, catching up
[18:43] <sbalneav> So if the kid wants to make a hugin wallpaper of himself and his family at the field, and some pedo manages to get ahold of that, and sees what the kid looks like, and snatches him.her...
[18:44] <Ahmuck> there are so many other ways to get photos.  kids are uploading photos of themselves without parent's consent all the time
[18:44] <sbalneav> and you're up in front of the judge/your district IT manager, and he/she says "So what did you do to ensure the privacy opf this kids data"
[18:44] <sbalneav> you say.... What?
[18:44] <Ahmuck> that's why we have a sheet that says you can do this or that
[18:44] <Ahmuck> if they go outside those rules, the responsiblity falls back on them
[18:44] <Ahmuck> same as if they decided to throw a rock in a window
[18:45] <sbalneav> ok, but there's a difference between the kid choosing to upload to facebook, and you, as the responsible admin who's supposed to know better, providing school services which FORCE the kid to upload information to public servers.
[18:45] <Ahmuck> whose going to gain access to that public server?
[18:45] <Ahmuck> encryption iirc, was mentioned
[18:46] <sbalneav> ANYONE ON THE INTERNET
[18:46] <sbalneav> Orly?
[18:46] <sbalneav> what encryption?
[18:46] <sbalneav> Do you know it's safe?
[18:46] <sbalneav> how good is it?
[18:46] <alkisg> How do we know that our bank won't steal our money from us?
[18:47] <sbalneav> Can you stand up, in a court of law, and say YOU KNOW BEYOND A SHADOW OF A DOUBT that NO ONE had access to the data?
[18:47] <Ahmuck> no, but i doubt you could do that with private servers
[18:47] <sbalneav> alkisg: because we get printed statements, and we're supposed to keep track of our finances.
[18:47] <Ahmuck> heh heh, sbalneav the banks did steal money from us.  via a 700 billion dollar bailout
[18:48] <Ahmuck> then they took the homes back
[18:48] <sbalneav> Ahmuck: You can if they're not connected to the internet.
[18:48] <Ahmuck> then they bulldozed some of them
[18:48] <alkisg> So if they print that you withdrew 1000$ with your card, how are you going to prove that you didn't?
[18:48] <Ahmuck> sbalneav: no, some really bright kid gets past security, and you'll find it in the www.  it happens all the time
[18:49] <Ahmuck> there is no such thing a security, only the veil of it
[18:49]  * sbalneav shrugs
[18:49] <sbalneav> Hey, you guys do what you want, not my problem, or my job.
[18:49] <sbalneav> But take it from someone who's BEEN in front of judges for chain of custody matters.
[18:50] <Ahmuck> i don't disagree, i prefer private information on private servers, however, i don't have an issue with offloading mathematical caculations to a server cluster
[18:50] <sbalneav> But I'd suggest checking with your relevant legislation and/or IT executive committee before "clouding" your it operation.
[18:51] <sbalneav> And possibly your personal lawyer :)
[18:51] <mhall119|work> sbalneav: if your point is that putting information on servers you don't control raises privacy and secrecy concerns, then yes, you're right
[18:51] <sbalneav> Right
[18:51] <mhall119|work> if your point is that clouds are more dangerous than existing server setups, I disagree
[18:52] <sbalneav> Never said that.
[18:52] <mhall119|work> then an internal, private cloud is no more dangerous than an internal, private server
[18:52] <sbalneav> Correct.
[18:52] <sbalneav> But then, you don't need a cloud, if you're going to do it all internally
[18:52] <mhall119|work> and your Flickr pictures are just as insecure if they use a standard cluster as they would be if they used a cloud
[18:52] <mhall119|work> sbalneav: clouds can still be useful internally
[18:53] <sbalneav> I disagree.  But I've had enough.  I lose, you all win. :)
[18:53] <mhall119|work> no!
[18:54] <mhall119|work> I have analogies!
[18:54] <mhall119|work> to cars!
[18:54] <mhall119|work> you can't quit now
[18:54] <sbalneav> I've conceded
[18:54] <mhall119|work> dammit
[18:54] <sbalneav> go play in your clouds
[18:54] <sbalneav> I got bugs to fix :)
[18:54]  * mhall119|work wishes he had a cloud
[18:54] <mhall119|work> my server has no VMX
[18:54] <Ahmuck> angels have a higher priorty than bugs :)
[18:55] <Ahmuck> they play in the clouds :)
[18:55] <mhall119|work> but angels don't need fixing
[18:55] <Ahmuck> heh, wonder what angel is playing around in the ubuntu cloud today
[18:55] <Ahmuck> :p
[18:57] <sbalneav> On matters of things you can implement/play with TODAY :p
[18:57] <sbalneav> I (with federico's help) have released the latest sabayon
[18:57] <sbalneav> 2.29.2
[18:57] <sbalneav> I'll have official builds up in my ppa later today.
[18:57] <mhall119|work> congrats!
[18:58] <Ahmuck> i recently used italc from my office and montioring the labs.  interesting feature
[18:58] <sbalneav> gotta get a lucid build there too.
[18:58] <sbalneav> This sabayon has manuals, and will be the first one that, other than a minor patch, basically runs upstream-clean on Ubuntu.
[18:59] <Ahmuck> sbalneav: deserves an award :)
[18:59] <sbalneav> So, if anyone had their 'druthers, what burning bug/issue should I work on next.  I've got some merges left to do, but out of the bugsquad bugs, what's a PITA for people?
[19:00] <mhall119|work> make sabayon run on a cloud
[19:00] <mhall119|work> sorry, couldn't resist
[19:00]  * sbalneav slaps mhall119|work with a trout.
[19:00] <mhall119|work> though making it work with XFCE would be nice, but probably not feasible
[19:01] <mhall119|work> or LXDE
[19:01] <sbalneav> XFCE/LXDE doesn't work with gconf, does it?
[19:01] <sbalneav> it should do SOME stuff for you
[19:01] <sbalneav> if they use xdg menus, they'll pick that up.
[19:02] <sbalneav> and any settings that get made in the home dir should get picked up.
[19:03] <Ahmuck> one of those "overloaded" issues is windows app artrage
[19:04] <Ahmuck> teaching art with it is nice, teaching art with it on underpowerd thin clients, not so nice
[19:05] <mhall119|work> XFCE is changing their configuration settings daemon around
[19:05] <mhall119|work> not sure what they use
[19:05] <sbalneav> "artrage"
[19:05] <sbalneav> ?
[19:05] <mhall119|work> it was xfconf in 9.04
[19:06] <mhall119|work> but I think they were changing again
[19:06] <mhall119|work> maybe to use dconf
[19:07] <alkisg> sbalneav: keep your strength for dbus merging for LTSP ;) You're the only one that can do it!
[19:08] <sbalneav> alkisg: ugh.   :D
[19:10] <sbalneav> Exactly
[19:10] <sbalneav> alkisg: I've made you upstream, when are YOU gonna be a packager slackass :)
[19:10] <sbalneav> I mean, geez :)
[19:10] <sbalneav> Oh, yeah
[19:10] <sbalneav> I forgot
[19:10] <alkisg> Hey, I've packaged more apps than anyone here
[19:11] <alkisg> Many Gb of them
[19:11] <sbalneav> Yeah, but you don't have upload, right?
[19:11] <alkisg> But they all used the same template :P :D
[19:11] <sbalneav> That's the problem, we need more people who can upload.
[19:11] <alkisg> Sure, I'd like to go for MOTU like you one day
[19:11] <sbalneav> alkisg: lets both go through the process together.
[19:11] <sbalneav> then we;ve got 3
[19:11] <sbalneav> hv, you and me.
[19:12] <alkisg> Hmm... sounds good...
[19:12] <Ahmuck> i'd do it *if* i had some direction and training
[19:12] <sbalneav> I'll teach what I know so far, later tonight, if anyone's interested.
[19:13] <alkisg> sbalneav: did you apply somewhere?
[19:13] <alkisg> I.e. put packages in revu?
[19:13] <sbalneav> Not yet, I have to get one more package done before I'm "a shoe-in"
[19:14] <sbalneav> Then I'm gonna submit them all.  ogra and LaserJock have said they'll coach me though the approval process.
[19:14] <sbalneav> I want to get it by end of december if I can
[19:14] <alkisg> Well I imagine it won't be much more trouble for them if they coach me too...
[19:15] <sbalneav> Sure.
[19:15]  * alkisg will be here later on to watch sbalneav's lessons :)
[19:15] <sbalneav> that's what I;m saying, more uploaders we have, the better.
[20:52] <sbalneav> OK, tarballs for sabayon-2.29.2 are out out out!
[20:52] <sbalneav> I'm gonna push a new version, gimme 10
[20:53] <highvoltage> sbalneav: cool. planning on uploading anything to revu soon?
[20:55] <sbalneav> highvoltage: I've got one more merge I want to do.
[20:56] <sbalneav> then I'll blast 3 or 4 things up in one shot, and hit you and ogra up for help
[20:56] <sbalneav> Think I can make motu by end of december?
[20:56] <highvoltage> sbalneav: oh for sure!
[20:57] <highvoltage> sbalneav: oh sorry I thought you meant December 2010 :p
[20:58] <highvoltage> sbalneav: well there's lots of holidays, etc in December, I think there's a chance though.
[21:16] <sbalneav> sabayon_2.29.2-0ubuntu1~ppa3
[21:16] <sbalneav> just uploaded to my ppa
[21:16] <sbalneav> With the exception of 1 *very tiny* patch to change the icon to a gksu sabayon, this one runs on ubuntu with no other modifications
[21:16] <sbalneav> \o/
[21:18]  * alkisg applauses for the new master of the universe (to be)
[21:18] <highvoltage> cool. do you uuencode it or use the new fancy source package format that allows binary diffs?
[21:18] <sbalneav> erm
[21:18] <sbalneav> I use dput :)
[21:19] <sbalneav> is that choice a or b? :)
[21:19] <highvoltage> I meant for the icon patch :)
[21:19] <sbalneav> ah, no
[21:19] <sbalneav> it uses cdbs
[21:19] <sbalneav> for the patch.  it's the .desktop file that gets patched.
[21:19] <highvoltage> ah ok
[21:20] <sbalneav> Sorry, I was less than clear.
[21:24] <highvoltage> np
[21:33] <sbalneav> Oooo
[21:33] <sbalneav> crumb
[21:34] <sbalneav> Rejected:
[21:34] <sbalneav> File sabayon_2.29.2.orig.tar.gz already exists in PPA for Scott Balneaves, but uploaded version has different contents. See more information about this error
[21:34] <sbalneav> +in https://help.launchpad.net/Packaging/UploadErrors.
[21:34] <sbalneav> Files specified in DSC are broken or missing, skipping package unpack verification.
[21:34] <sbalneav> grumble
[21:34] <sbalneav> gotta delete the one from my ppa first...
[21:37] <alkisg> sbalneav: I don't think it'll accept it easily without bumping the version...
[21:39] <sbalneav> Well, we'll try.
[21:40] <sbalneav> Sigh, I bumped the local packaging tarball number.  Shouldn't have done that.
[21:40]  * sbalneav facepalms
[21:41] <sbalneav> eurgh
[21:41] <sbalneav> yeah
[21:41] <highvoltage> just the tarball?
[21:41] <sbalneav> lemme see if I can ping ogra
[21:41] <sbalneav> yeah
[21:41] <sbalneav> I need to ditch the tarball in my ppa
[21:41] <highvoltage> you should probably dch -i and increment it in the actual package source and then rebuild it from there
[21:41] <sbalneav> anyway I can do that?
[21:42] <sbalneav> Well, here's what happened.
[21:42] <highvoltage> I don't know, increasing the version sounds like The Right Thing to do
[21:42] <alkisg> sbalneav: If you don't want to increment the source version, I think it'll be easier if you just give me the package, so I upload it to my ppa, and you copy it from there :P :D
[21:42] <alkisg> Heh
[21:42] <sbalneav> So, since I'm upstream for sabayon now, I've been working on the 2.29.2 version
[21:43] <sbalneav> so, I've been creating 2.29.2 source tarballs.
[21:43] <sbalneav> We've done a release, last step was to update news and read,e
[21:43] <sbalneav> so, we've now got a released tarball.
[21:44] <sbalneav> problem is, released tarball and my previous tarball are ever so slightly different.
[21:44] <sbalneav> and I want to release the package with the official upstream tarball
[21:45] <sbalneav> there's gotta be a way to ditch the existing tarball in my ppa.
[21:45] <highvoltage> sbalneav: so the upstream tarball changed without a change in version number?
[21:46] <sbalneav> well, *I* was producing the upstream tarball, yeah.
[21:46] <sbalneav> I suppose I should call them (when I work on them) 2.29.x-prerelease or something from now on
[21:47] <highvoltage> sounds like a good idea :)
[21:47] <sbalneav> Which is fine for future reference...
[21:47] <sbalneav> How do I fix this? :)
[21:48] <alkisg> Shouldn't that be 2.29.x~prerelease ?
[21:55] <sbalneav> well, whatever I call my "working" tarballs for upstream releases.
[21:55] <highvoltage> alkisg: sbalneav is talking about the upstream package version number, not the package in the ppa's version number
[21:56] <sbalneav> I'll ask later in #launchpad tonight.
[21:56] <highvoltage> alkisg: and upstream can pretty much version just how they want to
[21:56] <alkisg> Ah, so launchpad would accept a "lower" version of the upstream package?
[21:56] <alkisg> *tarball
[21:56] <sbalneav> I'm sure someone there can help me ditch the tarball
[21:56] <alkisg> OK, got it
[21:57] <alkisg> sbalneav: I think also in #ubuntu-motu they may be able to help you...
[21:57] <sbalneav> could try there.
[21:58] <alkisg> But when that happened to me, I just put the package to another ppa of mine, and copied the binaries :D


[04:03] <rmk> Is there any circumstance where launchpad will allow downloads during a build?
[04:03] <rmk> In other words, as part of the package build process, files need to be downloaded
[04:03] <SamB> never, ever do that
[04:04] <SamB> those files might not always be there!
[04:04] <StevenK> rmk: No, never.
[04:05] <rmk> https://github.com/spotify/dh-virtualenv is why I was asking.
[05:33] <ScottK> That qualifies as broken by design.
[05:41] <rmk> I disagree.
[05:55] <ScottK> It might have utility for building local packages, but it wouldn't be suitable for either Debian or Ubuntu.


[02:34] <lotuspsychje> good morning
[06:53] <lordievader> Good morning
[07:28] <ducasse> good morning
[11:50] <Deano59> hi :D
[13:20] <Deano59> is there anyway to remove ubuntu and chromium/snap? I have a script that refuses to use snap/chromium because it's installed with a chroot. :(
[13:20] <Deano59> oops, wrong channel. :)
[14:54] <faLUKE> (disclaimer: not intended to be frictious): hello, I'm the only one who thinks that the new widgets (icons, folder, scrollbars etc.) are messy compared to the ones of 18.x version ?
[14:56] <lotuspsychje> faLUKE: maybe its nice, if you grab a screenshot so everyone can see what changes you talk about?
[14:57] <faLUKE> https://www.omgubuntu.co.uk/2019/10/ubuntu-20-04-release-features <--- look at the grey color of the folder. It's bad, imho
[14:58] <faLUKE> also: the corners are not well rounded
[14:58] <faLUKE> the trash icon is messy
[14:58] <lotuspsychje> faLUKE: gnome-tweaks to the rescue anc pick another theme?
[14:59] <faLUKE> the network icon is a mess
[14:59] <faLUKE> lotuspsychje: I could switch to another desktop them, but I wonder WHY this new theme has been set as default
[15:00] <lotuspsychje> evolution
[15:00] <lotuspsychje> changing themes is not so hard?
[15:00] <lotuspsychje> there will we always someone not liking the theme by default
[15:01] <lotuspsychje> lucky, its ubuntu and you have a free choice
[15:01] <faLUKE> lotuspsychje: you are not understanding the point
[15:01] <faLUKE> anyway, I'm going to stop this discussion
[15:01] <lotuspsychje> howso?
[15:05] <coconut> faLUKE, please be nice on us, a theme can never be nice to everyone
[15:06] <coconut> faLUKE, you can change theme in settings, which what was lotuspsychje proposed, but you can also download ubuntu with another desktop environment.


[06:18] <philipballew> Anyone willing to send a post card  to America I can use an a talk on Ubuntu in a month?  http://philipballew.wordpress.com/2013/04/03/showcase-the-diversity-of-the-ubuntu-community/
[15:52] <autowiz03> 안녕하세요~~
[20:26] <Guest4454> heey
[20:34] <Guest4454> anyone there?
[21:28] <autowiz03> hi~
[21:28] <philipballew> autowiz03, hello
[22:17] <Guest4454> heey
[22:17] <Guest4454> eey
[22:44] <Guest4454> eey
[22:47] <Guest4454> wow its so packed in here...
[23:59] <razGon_Web> 홍콩에 있는 IP로 부터 원격접속 허용할거냐고 묻는데. 거부하는데도 계속 뜨네요.


[00:00] <bschaefer> RAOF, though whats strange is:
[00:00] <bschaefer> http://paste.ubuntu.com/6038461/
[00:00] <bschaefer> it has a XMIR-1 display added in?
[00:00] <bschaefer> but not connected...
[00:02] <bschaefer> annd yeah changing the res sends me back to lightdm
[00:05] <bschaefer> RAOF, if you're interested in the stacktrace in my Xorg.0.log:
[00:05] <bschaefer> http://paste.ubuntu.com/6038469/
[00:08] <RAOF> Ta.
[00:11] <RAOF> bschaefer: And, as usual, you can't get a proper trace out of that, can you?
[00:11] <RAOF> bschaefer: OH! Did you get an apport crash report out of that?
[00:13] <bschaefer> hmm
[00:13] <bschaefer> RAOF, im not sure, I usually don't use apport :)
[00:13]  * bschaefer checks
[00:13] <RAOF> Because you can post-process that locally to get a symbolic backtrace, using apport-retrace.
[00:14] <bschaefer> let me see if I can get a real backtrace...
[00:14] <bschaefer> as that one is pretty useless :)
[00:16] <bschaefer> RAOF, hmm I don't seem to have a *.crash file from today ... besides the hud service...
[00:17] <RAOF> Delete any existing Xorg crash file, and then crash it again :)
[00:17] <bschaefer> alright!
[00:30] <bschaefer> RAOF, cool got a *.crash file, now to run it through apport...
[00:31] <bschaefer> it doesn't crash very often though
[00:31] <RAOF> Oh, it doesn't dependably crash when you change resolution?
[00:31] <bschaefer> most the time it was changing the res, but lots of graphic problems
[00:31] <bschaefer> nope!
[00:31] <bschaefer> ill upload an image of what it looks like...but it looks baaad
[00:31] <bschaefer> finally got a crash though
[00:37] <bschaefer> RAOF, http://i.imgur.com/dKiZNKY.jpg
[00:37] <bschaefer> when it does work
[00:37] <RAOF> 404'd!
[00:37] <bschaefer> :(
[00:38]  * bschaefer tries a different site?
[00:38] <bschaefer> RAOF, or possibly this: http://imgur.com/dKiZNKY
[00:39] <RAOF> Whee!
[00:39] <bschaefer> strange, o well but yeah, I think I saw similar rendering issue with other testers?
[00:40] <bschaefer> but things are rendering fine when I don't force the res
[00:47] <bschaefer> :(
[00:47] <bschaefer> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
[00:51] <RAOF> :(
[00:52] <RAOF> bschaefer: There'll be a shiny new -ati to test in qa-testing2 shortly.
[00:53] <bschaefer> sweet, I can give that run
[00:53]  * bschaefer attempts the apport-retrace again...for the hell of it
[01:03] <bschaefer> RAOF, i've also just realized I pulled the packages directly from qa-testing2, instead of adding that ppa...
[01:03] <bschaefer> which im guessing means it can't find the correct packages for the sandbox...
[01:03]  * bschaefer adds pps
[01:03] <bschaefer> ppa*
[01:12] <RAOF> bschaefer: That would be correct, yes.
[01:13] <RAOF> bschaefer: You're looking for xserver-xorg-video-radeon 7.2.0-0ubuntu3+xmirMM4
[01:14] <bschaefer> RAOF, the new one?
[01:14]  * bschaefer just added the ppa, and is redoing the apport-retrace
[01:14] <RAOF> Yeah. That's the one to test next.
[01:15] <bschaefer> cool, ill test it out after this (hopefully) new retrace attempt
[01:15] <bschaefer> hopefully successful*
[01:23] <bschaefer> RAOF, stracktrace: http://paste.ubuntu.com/6038660/
[01:24] <bschaefer>         pid = -1222160384
[01:24] <bschaefer> doesn't like good :)
[01:25] <RAOF> src_obj = {pitch = 1280, width =<PHONE_NUMBER>, height =<PHONE_NUMBER>, bpp = -1237450752, domain =<PHONE_NUMBER>, bo = 0xb8560c28, tiling_flags =<PHONE_NUMBER>, surface = 0xb63a06d6 <RADEONEXASetSharedPixmapBacking+70>}
[01:25] <bschaefer> yeah I just saw that as well
[01:25] <bschaefer> same with dest_obj
[01:25] <bschaefer> dst_obj*
[01:25] <RAOF> I believe that's fixed in MM4
[01:26] <bschaefer> sweet, let me give that a run
[01:29]  * bschaefer reboots
[01:37] <bschaefer> RAOF, just to double check, just asserting that that crash ins't happening?
[01:37] <bschaefer> after ~3 attempts no crash, but still have to reboot after the screen goes crazy :)
[01:37] <RAOF> Hm.
[01:37] <RAOF> Screen going crazy is not expected. :
[01:37] <RAOF> :/
[01:37] <bschaefer> RAOF, I could also be forcing the res in an odd way
[01:37]  * bschaefer paste bin commands
[01:38] <bschaefer> RAOF, http://paste.ubuntu.com/6038680/
[01:39] <RAOF> Ok.
[01:39] <RAOF> Huh.
[01:39] <bschaefer> used: cvt 1280 720 to get the modeline
[01:39] <RAOF> Why do you need --newmode?
[01:39] <RAOF> That won't work :)
[01:39] <bschaefer> RAOF, excellent, I just quickly looked up how to change the res using xrandr...
[01:40] <bschaefer> RAOF, I should just have to do:
[01:40] <RAOF> “xrandr -q” should list the valid modes, then you can just xrandr --output XMIR-0 --mode $EXISTING_MODE
[01:40] <bschaefer> xrandr --output XMIR-0 --mode 1024x768?
[01:41] <bschaefer> alright, ill give that a try then
[01:44] <bschaefer> RAOF, :( screen still went crazy....
[01:44] <RAOF> Hm.
[01:44]  * bschaefer checks logs for anything
[01:44] <bschaefer> nothingis crashing though
[01:44] <RAOF> Got dmesg / Xorg log?
[01:46] <bschaefer> RAOF, hmm let me past the xorg log/dmesg but Its hard to read them with such a small screen :)
[01:47] <RAOF> You should be able to just use pastebinit, right?
[01:47] <bschaefer> yeah I can: http://paste.ubuntu.com/6038693/
[01:48]  * bschaefer likes to be able to attempt to read them
[01:50] <bschaefer> dmesg: http://paste.ubuntu.com/6038696/
[01:50]  * bschaefer looks at the kern log
[01:54] <RAOF> Ah. You haven't tried to change the mode yet?
[01:54] <bschaefer> RAOF, ?
[01:55] <RAOF> bschaefer: The xorg log doesn't seem to contain an attempt to change the mode from the default.
[01:55] <bschaefer> RAOF, hmm I wonder if I grabed the wrong one?
[01:55] <RAOF> Mayhap.
[01:55] <bschaefer> i used Xorg.0.log.old...assuming it was the last one
[01:56]  * bschaefer attempts the mode change again looking at the current time...
[02:02] <bschaefer> RAOF, hmm my Xorg has the correct time, but I don
[02:02] <bschaefer> dont see it trying to set it...
[02:04] <RAOF> That is odd.
[02:04] <bschaefer> i have a bunch of extra bytes at the end of the file though...
[02:05] <duflu> RAOF: Those little horizontal lines with intel+XMir+bypass, they seem to be on damage rect boundaries... ?
[02:05] <RAOF> duflu: Not really, no?
[02:05] <bschaefer> RAOF, which when I try to open it in gedit says there an encoding error...I wonder if it was failing to get logged to...
[02:06] <bschaefer> lots of: \00
[02:06] <RAOF> bschaefer: Hm, maybe?
[02:06]  * bschaefer has no clue how that would happen
[02:06] <bschaefer> RAOF, should I try turning all the debugging messages back on?
[02:07] <bschaefer> and try to get some logs from the kern.log?
[02:07] <RAOF> Hm, maye?
[02:07] <bschaefer> wouldn't hurt at this point at lease...
[02:11] <bschaefer> RAOF, would setting the drm.debug thing even work for this?
[02:12]  * bschaefer also forgot the path to it...and does't have the log saved
[02:13]  * bschaefer found it..
[02:13] <bschaefer> well wouldnt hurt
[02:21] <bschaefer> RAOF, yay the Xorg log is showing it now...
[02:21] <RAOF> Woot!
[02:21] <bschaefer> http://paste.ubuntu.com/6038776/
[02:22] <bschaefer> but no errors in it...
[02:23] <bschaefer> at lease that I see :)
[02:26]  * bschaefer wonders if its having a problem cause one monitor is still the 640x480 res
[02:27] <bschaefer> as things are mirrored atm
[02:31] <RAOF> Hrm.  Ok, that looks pretty standard.
[02:32]  * RAOF wonders if he can trigger this on his radeon.
[02:33] <bschaefer> I wonder if its cause im setting a mirror monitor to a res that is not supported by the other
[02:33] <bschaefer> the only one that overlaps is 640x480
[02:35] <bschaefer> RAOF, well im going to head off for the night and eat some dinner, hopefully its reproducible else where :)
[02:36] <RAOF> Yeah.
[02:36] <RAOF> Have nice dinner!
[02:36] <bschaefer> thanks!  Reproducible locally!
[02:49] <kgunn> RAOF: did anyone tell you?....nouvea w/ latest drivers from qa-testing2 will boot to usable unity single screen
[02:50] <RAOF> kgunn: But not more than one screen?
[02:50] <kgunn> RAOF: nope....but gagnon tried with standalone X and it wasn't happy
[02:50] <kgunn> i'm convinced nouveau is just a mess
[02:50] <kgunn> before we stirred the pot
[03:35] <duflu> robert_ancell: I only heard underwater mumbles half the time :/
[03:36] <robert_ancell> duflu, awesome
[03:36] <robert_ancell> :)
[03:43] <duflu> robert_ancell: So which should I expect to be landing first? bypass or timerless?
[03:43] <robert_ancell> duflu, probably bypass
[03:44] <duflu> OK, removing one of the timerless branches then
[03:44] <robert_ancell> duflu, does that make it easier to land timerless?
[03:44] <duflu> Yes
[04:28] <tvoss__> good morning
[04:31] <tvoss__> RAOF, ping
[04:31] <RAOF> tvoss__: Pong.
[04:35] <robert_ancell> bbiab
[04:36] <tvoss__> kgunn, ping
[04:38] <kgunn> tvoss__: pong
[05:17] <mlankhorst> morning
[05:23] <RAOF> mlankhorst: Speak of the devil!
[05:27]  * robert_ancell -> dinner etc, will be back later
[05:29] <duflu> Oh multi-monitor is so much less annoying when none of them are analog VGA
[05:32] <RAOF> Yeah, I'm trying to rid the world of VGA interfaces.
[05:33] <duflu> Especially when my oldest monitor misdetects the VGA signal most of the time
[05:34] <RAOF> You know, it'd be much easier to debug bypass if my radeon card didn't work perfectly with it.
[05:45] <duflu> RAOF: Good to hear, kinda. I'm working on a setup to try radeon+saucy here too
[05:47] <duflu> Oh, new saucy wallpapers?!
[05:48] <duflu> Ahem, wallpapers for saucy
[05:48] <RAOF> To the multi-monitor-bypass-testotron!
[05:48] <RAOF> Heh.
[05:52] <duflu> RAOF: Do you have a solid indication it is bypassing on radeon? Like performance?
[05:53] <duflu> ... lack or mouse lag?
[05:53] <RAOF> Ok. As long as you don't mind waiting a couple of frames for all your rendering to appear, multimonitor+bypass on Intel wors.
[05:53] <RAOF> *works.\
[05:53] <duflu> RAOF: Yeah that was true without bypass too, but I think the out-of-order-ness is worse with bypass
[05:53] <RAOF> Oh, no.
[05:53] <RAOF> This isn't out of orderness.
[05:54] <RAOF> And I'm *not* seeing the same out-of-order problems. At least at the moment.
[05:54] <RAOF> I'm talking about the rendering "teleporting in" in horizontal lines.
[05:55] <duflu> RAOF: Yeah saw that (less so) with intel bypass single monitor too
[05:55] <RAOF> Right.
[05:55] <duflu> Annoyingly, only on the XMir surface
[05:55] <mlankhorst> RAOF: did you fix ati? :P
[05:57] <RAOF> mlankhorst: By setting the window pixmap of all the children of the root window that share the root window's pixmap.
[05:57] <RAOF> I presume by "fix ati" you're talking about mode changing here?
[05:57] <mlankhorst> ytes
[05:57] <RAOF> Yeah.
[05:57] <RAOF> Did nouveau work with modechanges? I'd expect it to suffer the same problem.
[05:58] <duflu> brb
[05:59] <mlankhorst> RAOF: did you upload a version bump to mir so it's easier to test? :p
[06:00] <RAOF> No; I'll do so now.
[06:03]  * mlankhorst slowly wakes up
[06:22] <RAOF> mlankhorst: Got any idea what might cause this: http://ubuntuone.com/08RzJfgwUfZd1LigIS16Mh particularly fun brand of misrendering?
[06:25] <mlankhorst> RAOF: forgetting to flush maybe?
[06:26] <RAOF> That thought occurred
[06:27] <mlankhorst> try damaging the whole screen and see what happens..
[06:27] <mlankhorst> hm compiz already should, though
[06:29] <duflu> mlankhorst: I tried that. No change
[06:30] <mlankhorst> duflu: might be a driver bug or something :P
[06:30] <RAOF> I suspect it might be a cache-coherency problem that ickle warned me about.
[06:31] <duflu> Does intel need/use the "dirty/clips" feature of DRM? I thought it was only vmware that did
[06:31] <RAOF> fbc might interact with that?
[06:31] <mlankhorst> oh is it intel?
[06:32] <RAOF> Yad
[06:32] <duflu> Yes
[06:32] <RAOF> Yah
[06:32] <mlankhorst> yeah probably something like that
[06:32] <duflu> RAOF: What was the cache coherency warning?
[06:33] <duflu> brb
[06:34] <RAOF> mlankhorst: xserver MM16 awaits your attention
[06:34] <mlankhorst> what do you want me to test?
[06:35] <RAOF> nouveau MM
[06:35] <RAOF> If that didn't work before.
[06:36] <RAOF> duflu: I forget the details, but I half-remember that there was special cache invalidation magic needed when doing things to the framebuffer that mesa doesn't do?
[06:36] <duflu> RAOF: AFAICT, we're not doing anything Mesa doesn't do. I keep searching the Mesa sorce
[06:36] <duflu> But I'm probably wrong
[06:37] <RAOF> We'll, we're calling drmModeAddFB and drmModePageFlip, which mesa doesn't do :)
[06:37] <duflu> RAOF: Oh just SetCrtc?
[06:37] <RAOF> Mesa doesn't do that, either.
[06:37] <duflu> RAOF: ??
[06:38] <RAOF> Mesa doesn't do any of the modesettingy stuff; it leaves that for X to do.
[06:38] <RAOF> And X leaves that for the DDX to do.
[06:38] <RAOF> Except we don't let the DDX do what it was doing, and we do our own thing.
[06:38] <duflu> RAOF: So we need to copy some magic from DDX into Mir?
[06:39] <RAOF> Maybe
[06:39] <duflu> The old DDX
[06:39]  * duflu now has new source to examine
[06:39] <duflu> BTW, my experiment to get saucy on radeon has now failed
[06:39] <duflu> The machine fails to boot for new unknown reasons
[06:40] <mlankhorst> RAOF: hm could you MIR libjsoncpp? :P
[06:40] <mlankhorst> build-dep for llvm-toolchain
[06:40] <RAOF> mlankhorst: I can't promote it myself; is there a MIR already filed?
[06:41] <mlankhorst> it hm don't know if there is, but it was always a build-dep for llvm, but llvm-toolchain-3.3 had some package modifications to use an external copy
[06:45] <RAOF> How did llvm build before if it always build-depended on a package not in main?
[06:45] <mlankhorst> it had an internal copy :P
[06:45] <RAOF> Heh
[06:46] <mlankhorst> I suppose I could make a MIR for it, but I feel it's a bit of overkill
[06:47] <mlankhorst> bah it moved llvm-toolchain-3.3 back to universe
[06:51] <tvoss> duflu, one thing I noticed yesterday: we never "release" the BufferObject for the scanout bo
[06:52] <duflu> tvoss: I thought  there was a devious and non-obvious path where it was released. Will check again. It's certainly different to the default front_buffer as far as GBM is concerned
[06:54] <tvoss> duflu, as I understand it, the buffer object is never released until destruction
[06:55] <duflu> tvoss: Oh. Yes we do delete it correctly. And the "release" call would be erroneous (and crash from memory) on the bypass buf. Because that applies to gbm surface-specific bo's
[06:56] <tvoss> duflu, might be good to have a different type to wrap the buffer object, then. But that's for later
[06:56] <duflu> tvoss: You're only meant to gbm_surface_release_buffer on things which come from gbm_surface_lock_front_buffer
[06:56] <tvoss> duflu, one other thing: if a bypass buffer is provided, we never eglswap
[06:56] <duflu> tvoss: Correct! Bypass means no GL-anything!
[06:56] <tvoss> duflu, ack
[06:56] <tvoss> duflu, if only that was documented somewhere ;)
[06:57] <duflu> tvoss: Fair point. But it's interesting when you realise you can composite without any GL
[06:57] <RAOF> Well, we're not actually compositing anything.
[06:57] <duflu> True
[06:57] <duflu> Kinda
[07:03] <RAOF> If we used overlays then we *could* be compositing and bypass at the same time.
[07:04] <duflu> ... it opens up doors like Mir supporting non-GL platforms in a limited fashion
[07:05]  * tvoss points out that we have a weird cache invalidation thingy to fix first
[07:05] <duflu> RAOF: Already with the hardware cursor (works over bypass)
[07:18] <duflu> BTW, I think I observed a noticeable improvement with timerless on radeon with dual monitors. I think...
[07:30] <sil2100> Hi everyone
[07:31] <duflu> sil2100, morning
[07:32] <sil2100> Did all the branches needed for bypass and multimonitor get merged into trunks already?
[07:33] <sil2100> Of mir and unity-system-compositor?
[07:33] <duflu> sil2100: Not yet. Happening now
[07:33] <tvoss> sil2100, I will keep you posted as merges are happening
[07:33] <tvoss> sil2100, makes sense?
[07:33] <sil2100> duflu: can you poke me when that's done? And which components have changes that need releasing? Since I'd like to get it out today
[07:33] <sil2100> tvoss: thanks!
[07:51] <duflu> sil2100: Yep
[07:52] <hikiko> hi, question: what's the drm interface version? is it the library version or something else?
[07:53] <duflu> hikiko: I was wondering that myself. Seems unrelated to anything. And I was told that it doesn't get updated at all
[07:53] <hikiko> and it causes a bug in nested mir
[07:53] <mlankhorst> hikiko: no it's checking if dri2 is supported or not
[07:53] <mlankhorst> that's all
[07:55] <hikiko> so, if I want to fix the bug on nested mir (which is: I don't have permission to set the drmInterfaceVersion to the device I want to use - which is usable) I have to find another way to check if dri2 is supported?
[07:56] <mlankhorst> just assume it's supported tbh
[07:57] <mlankhorst> did you try killing that check entirely?
[07:57] <hikiko> yes and it works fine
[07:57] <hikiko> if there's no other part of mir that uses it
[07:57] <hikiko> then I ll just do an mp
[08:00] <hikiko> mlankhorst, duflu could you review it? https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830
[08:00] <hikiko> (i just removed the check)
[08:01] <duflu> Will do
[08:01] <hikiko> thanks!
[08:02] <duflu> hikiko: Could that explain the strange DRM open failures some nvidia users get?
[08:03] <mlankhorst> duflu: that's.. more complicated
[08:04] <mlankhorst> but link a bug?
[08:04] <duflu> mlankhorst: bug 1206633
[08:04] <hikiko> that's the error I was getting too
[08:04] <hikiko> but I don't know if that change solves it (I have an intel)
[08:06] <mlankhorst> some calls require DRM_MASTER, but meh
[08:07] <duflu> Which we have, maybe not soon enough?
[08:08] <mlankhorst> probably not then
[08:08] <alan_g> \o/ bypass has landed
[08:08] <hikiko> :D
[08:08] <mlankhorst> and there can only be 1 master
[08:08] <mlankhorst> this is legacy from dri1 :/
[08:11] <mlankhorst> duflu: it's complicated, there used to be a race between xorg-server, lightdm and plymouth, where lightdm could not detect plymouth..
[08:12]  * duflu ducks
[08:12] <mlankhorst> I think if you start xorg-server before opening the drm fd in mir, you get the same kind of symptoms for a race..
[08:13] <duflu> alan_g: I'm fixing timerless now. I don't care what the variables are called. *count/no/num ... pick one and I'll change them all
[08:14] <duflu> hikiko: You got the same exception with errno==0 ?
[08:15] <alan_g> duflu: I'm not blocking on the names - and *_sequence_number is a mouthful
[08:15] <hikiko> no, with errno = 13 or so let me see
[08:15] <duflu> hikiko: Different bug. But it exists :)
[08:15] <hikiko> a yes the Success
[08:15] <hikiko> let me run it one more time
[08:15] <hikiko> :P
[08:15] <duflu> hikiko, Success or errno 13?
[08:18] <alan_g> duflu: *seq_no?
[08:18] <hikiko> I got the 13
[08:18] <hikiko> Permission denied
[08:18] <hikiko> but I think that at some point I got the success as well :S while debugging
[08:19] <hikiko> if I leave the check I get the 13
[08:19] <duflu> alan_g: That's the one option I disliked. It is actually a count or frame number without gaps (on at least one or more monitors). So I think count/no/num is better
[08:19] <mlankhorst> hikiko: can you do lsof /dev/dri/*
[08:19] <hikiko> it doesnt return anything
[08:20] <hikiko> plymouthd  189 root   12u   CHR  226,0      0t0 8971 /dev/dri/card0
[08:20] <hikiko> Xorg      1988 root  mem    CHR  226,0          8971 /dev/dri/card0
[08:20] <hikiko> Xorg      1988 root   10u   CHR  226,0      0t0 8971 /dev/dri/card0
[08:20] <hikiko> Xorg      1988 root   42u   CHR  226,0      0t0 8971 /dev/dri/card0
[08:20] <hikiko> mir_demo_ 8375 root  mem    CHR  226,0          8971 /dev/dri/card0
[08:20] <hikiko> mir_demo_ 8375 root    9u   CHR  226,0      0t0 8971 /dev/dri/card0
[08:20] <hikiko> mir_demo_ 8375 root   10u   CHR  226,0      0t0 8971 /dev/dri/card0
[08:20] <hikiko> ouch
[08:20] <hikiko> sorry
[08:20] <hikiko> ://
[08:20] <hikiko> it was huge
[08:21] <alan_g> duflu: sync_counter?
[08:21] <mlankhorst> hikiko: yeah you still had some stuff open, can only run 1 at the same time
[08:21] <duflu> alan_g: I think frame number is more self explanatory
[08:21] <hikiko> mlankhorst, it seems that I have plymouth running after all :)
[08:21] <mlankhorst> indeed!
[08:24] <alan_g> duflu: ok [current|local|global]_frame_number
[08:25] <duflu> tvoss: Do you want timerless done before we declare MM feature complete?
[08:25] <duflu> It's not really critical
[08:26] <tvoss> duflu, let's get it in if it does not break us
[08:26] <duflu> tvoss: Still working on fixing it tho
[08:26] <hikiko> mlankhorst, what do you mean I can only run one at time? only one can use the drm device at a specific time? (which means that I can't set the version to a device that is used although I can use the device?)
[08:26] <tvoss> duflu, don't block on it
[08:27] <hikiko> I dont know if what I wrote makes sense :p
[08:27] <mlankhorst> hikiko: there can only be 1 master
[08:27] <hikiko> and when you set the version you have to be the master?
[08:27] <mlankhorst> yes
[08:27] <mlankhorst> and if nobody has the device opened, you automatically become master
[08:27] <duflu> In that case, sil2100, bypass and MM are fully landed in lp:mir. There is no new version/tag yet. Usually robert_ancell does that
[08:27] <hikiko> then ok it's normal that only nested mir has the error
[08:28] <robert_ancell> yeah, I tag on mondays
[08:28] <hikiko> because in my case I am not and I don't want to become the master
[08:28] <robert_ancell> duflu, you haven't landed MM right?
[08:28] <duflu> robert_ancell: I said lp:mir where it landed weeks ago
[08:28] <robert_ancell> oh, right
[08:29] <mlankhorst> hikiko: yeah if you get the fd from someone else, presumably you're already authenticated. it's a silly concept :P
[08:29] <duflu> sil2100: But ask RAOF when the XMir parts are landing...
[08:30] <alan_g> hikiko: ( mlankhorst ) the fd should come from the hosting Mir session
[08:30] <duflu> alan_g: Actually I just noticed freezing the count doesn't always freeze rendering. It probably should. So fixing...
[08:31] <sil2100> duflu: ok, anything else needs landing? Anything in u-s-c?
[08:31] <duflu> robert_ancell, ^
[08:31] <hikiko> alan_g, the host uses the drm device and then I create a drm device to create the gbm device and allocate a gbm buffer (because gbm depends on drm) but it's the host that renders on the screen and is the master
[08:31] <robert_ancell> sil2100, lp:unity-system-compositor and lp:lightdm are all up to date
[08:31] <hikiko> so while my device can be used I dont have the permission (since I am not a master) to set the version
[08:32] <alan_g> hikiko: you can get a pre-authorised from mir_connection_drm_auth_magic()
[08:32] <hikiko> yes
[08:32] <hikiko> but I don't want to do this
[08:32] <hikiko> because I need to see on the screen
[08:33] <hikiko> (host mir does the rendering/vt etc)
[08:34] <hikiko> what does mir_connection_drm_auth_magic() do exactly?
[08:34] <mlankhorst> hikiko: authenticate
[08:34] <mlankhorst> which involves guessing a 32-bit integer iirc
[08:35] <hikiko> yes, in nested mir I only authenticate when I need to use the display
[08:36] <hikiko> and I guess that's correct, because if nested mir is the master then the host mir won't render anymore
[08:36] <hikiko> and I will see a freeze
[08:36] <hikiko> isnt it?
[08:36] <mlankhorst> authenticate != master
[08:37] <hikiko> then authentication doesn't solve the problem with the interface version
[08:37] <RAOF> mlankhorst: Did you get to test MM+nouveau?
[08:37] <hikiko> the initial problem was that I couldnt call the drmSetInterfaceVersion without being the master
[08:38] <alan_g> the host remains master, but gives the nested the fd it needs. The host sets the interface version nested
[08:38] <alan_g> nested doesn't need to
[08:38] <mlankhorst> RAOF: i was busy with llvm and tjaalton's stuff :P
[08:38] <RAOF> mlankhorst: Yeah, thought so.
[08:39] <hikiko> alan_g, the problem is that in drm helpers we call the setInterface when we open the drm device
[08:39] <hikiko> which is before authentication anyway
[08:39] <hikiko> and we use that code to check if the device we already opened
[08:39] <hikiko> is "usable"
[08:39] <hikiko> sorruy meeting brb
[08:40] <mlankhorst> hikiko: even authentication is not enough, requires master
[08:41] <mlankhorst> an authed client is something like glxgears, it can't touch the output mode or anything, but it can render and allocate buffers
[08:41] <hikiko> currently I do: open_drm_device
[08:41] <hikiko> amd then authentication
[08:41] <alan_g> mlankhorst: that's what I understand hikiko needs for nested. It is "just" an auth client
[08:42] <mlankhorst> indeed
[08:42] <mlankhorst> but drmSetVersion requires master :P
[08:42] <mlankhorst> so just kill it
[08:42] <alan_g> hikiko: don't do that - just get the fd from the master
[08:42] <hikiko> yes :)
[08:42] <hikiko> that's what I did
[08:43] <mlankhorst> ok so erm nouveau mm testing..
[08:43] <hikiko> alan_g, I cant get the fd from the master
[08:44] <hikiko> the master must use it's own gbm device
[08:44] <hikiko> because it might have other clients instead of mir on mir
[08:44] <RAOF> hikiko: Aren't you getting the drm fd from the PlatformPackage?
[08:45] <hikiko> PlatformIPCPackage?
[08:46] <RAOF> MirPlatformPackage, from mir_connection_get_platform
[08:46] <hikiko> no because I don't get the platform
[08:46] <hikiko> I create a native platform
[08:46] <hikiko> that has it's own buffers
[08:46] <hikiko> I don't use mir buffers
[08:47] <RAOF> And you can't get the platform first?
[08:47] <RAOF> Because mir_connection_get_platform will give you a fully armed and operation drm fd that you can create a gbm_device from.
[08:47] <RAOF> And then allocate buffers to your heart's content.
[08:47] <alan_g> RAOF: that's exactly what we want
[08:48] <hikiko> yes but the design we did was to have a native platform etc alan_g
[08:49] <alan_g> hikiko: What has that to do with this?
[08:51] <alan_g> The native platform needs an FD. mir_connection_get_platform (I had the wrong function before) gets that FD
[08:51] <mlankhorst> RAOF: single monitor works :P
[08:52] <tvoss> RAOF, what changes in Mir do you need landed for mm?
[08:52] <RAOF> tvoss: NOne
[08:52] <hikiko> yes just checking the MirPlatformPackage struct alan_g
[08:52] <mlankhorst> hm didn't crash on hotplug
[08:53] <RAOF> mlankhorst: And is displaying roughly correctly?
[08:53] <hikiko> RAOF, will this platform package give me the drm device of the host mir?
[08:53] <mlankhorst> RAOF: it would seem so
[08:53] <RAOF> mlankhorst: SHIP IT!
[08:53] <hikiko> because this is not what I want
[08:53] <RAOF> hikiko: No, it won't give you the same drm fd that the host mir has open.
[08:54] <mlankhorst> RAOF: overlapping screen works correctly too
[08:54] <RAOF> hikiko: It will give you a drm fd that you can use for your own rendering/buffer allocation/etc.
[08:54] <mlankhorst> as does a hole between the screens :P
[08:54] <RAOF> OOoh, thorough!
[08:54] <hikiko> RAOF, also will it be the master?
[08:54] <RAOF> hikiko: No, but it will be authenticated.
[08:54] <mlankhorst> RAOF: well those would be the main usecases anyway..
[08:55] <hikiko> cool then :)
[08:55] <RAOF> mlankhorst: And then it doesn't notice hotunplug? :)
[08:55] <mlankhorst> RAOF: no idea, I tried disabling both screens for fun, didn't work as intended :P
[08:56] <mlankhorst> main screen turn on
[08:56] <RAOF> :)
[08:56] <hikiko> +question how is this fd allocated? if we call the open_drm_device in gbm_display_helpers we have the same problem :)
[08:56] <hikiko> I think that just removing the check is the best
[08:57] <mlankhorst> RAOF: so it seems the case of 0 monitors doesn't work correctly :p
[08:57] <mlankhorst> when doing xrandr --output XMIR-* --off for all outputs
[08:58] <alan_g> hikiko: if gbm_display_helpers doesn't do what you need don't use it
[08:58] <RAOF> mlankhorst: I'm a bit surprised that doesn't work, but that's an edge case I'm happy to fix in post :
[08:58] <RAOF> :)
[08:58] <alan_g> hikiko: or give it the function you do need
[08:58] <duflu> I'm sure someone logged a bug for that yesterday
[08:59] <mlankhorst> looks like xorg didn't crash either :O
[09:00] <hikiko> alan_g, I ll just write a second open_drm_device that doesnt have the check of this branch: https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830 then and use it
[09:00] <mlankhorst> oh right didn't test normal shutdown yet
[09:00] <mlankhorst> gasp, no crash
[09:00] <alan_g> hikiko: ack
[09:01] <mlankhorst> now the same, but with valgrind >:O
[09:01] <RAOF> mlankhorst: My code laughs at your petty memory-correctness tools!
[09:02] <mlankhorst> or does it? DUN DUN DUUN
[09:02] <RAOF> hikiko: It's still not clear to me why you need to open_drm_device at all?
[09:04] <mlankhorst> RAOF: haha i broke things, lets see if the panda has some debug output on serial console :P
[09:04] <hikiko> RAOF, I wont use mir buffers
[09:04] <hikiko> I will use native buffers
[09:04] <hikiko> gbm and android
[09:04] <mlankhorst> RAOF: bahaha
[09:04] <mlankhorst> [  292.862839] nouveau E[  PGRAPH][0000:01:00.0] DATA_ERROR [XY_OUT_OF_BOUNDS] ch 3 [0x003fb4e000 unity-system-co[1120]] subc 2 class 0x9039 mthd 0x0300 data 0x00100000
[09:04] <hikiko> so in order to allocate a gbm buffer I need a gbm device which needs a drm device
[09:05] <mlankhorst> RAOF: seems to happen a few times during resizing
[09:05] <RAOF> hikiko: Yeah, but you *get* a drm device for free from the hosting Mir.
[09:05] <hikiko> RAOF, the problem is this check here:
[09:05] <hikiko> https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830
[09:05] <mlankhorst> RAOF: so har har har har har, I win :D
[09:06] <hikiko> which is inside open_drm_device
[09:06] <hikiko> so before you authenticate
[09:06] <hikiko> you have to drmSet..
[09:06] <RAOF> hikiko: Yeah, but you don't need to call open_drm_device at all.
[09:07]  * duflu doesn't understand what mlankhorst wins
[09:07] <hikiko> that's what I asked you, if I call the mir_connection..
[09:07] <hikiko> it wont call the open_drm_device at some point?
[09:07] <RAOF> All that open_drm_device does is get a drm fd; and you get the correct, pre-authenticated drm fd from mir_connection_get_platform
[09:07] <RAOF> hikiko: No, not on the nested server side.
[09:07] <hikiko> in any server's side
[09:07] <hikiko> the 2nd drm device allocated
[09:07] <RAOF> It *will* call get_authenticated_fd on the host's side.
[09:08] <hikiko> will have the problem
[09:08] <hikiko> yes
[09:08] <mlankhorst> duflu: RAOF may have won on memory validation, but he definitely LOST on gpu validation ;)
[09:08] <hikiko> then ok you ll get the bug in the host racarr|desert
[09:08] <RAOF> But you can get as many authenticated fds as you want.
[09:08] <hikiko> sorry
[09:08] <hikiko> RAOF,
[09:08] <hikiko> RAOF, I know the prob is that you cant run drmSetInterfaceVersion
[09:08] <hikiko> without being the drm_master
[09:09] <RAOF> Right. But the host Mir *is* drm master.
[09:09] <hikiko> since that is called before the drm authentication
[09:09] <hikiko> question:
[09:09] <RAOF> And the host Mir opens the fd for you, and then gives the fd over IPC.
[09:09] <hikiko> drm master is mir or a device?
[09:10] <RAOF> drm master is a state that a drm fd can be in. It basically means you get to modeset.
[09:10] <RAOF> (Among other things)
[09:10] <hikiko> when you call SetDrmMaster you pass an fd?
[09:10] <hikiko> let me check
[09:11] <RAOF> I'm not sure why you're caring about drm master?
[09:11] <RAOF> The nested compositor is not going to have access to a drm master fd, nor does it need one.
[09:11] <hikiko> RAOF,
[09:11] <hikiko> host mir starts
[09:12] <hikiko> it opens fd0
[09:12] <hikiko> it automatically becomes the master because it s the first device isnt it?
[09:12] <hikiko> and then you call setInterfaceVersion
[09:13] <hikiko> then opens fd1
[09:13] <hikiko> it's not the master
[09:13] <hikiko> you have to call setDrmMaster if you want it to be the master
[09:13] <hikiko> but before that
[09:13] <hikiko> in open_drm_device
[09:13] <hikiko> you call setInterfaceVersion
[09:13] <hikiko> for which you have no permission
[09:14] <hikiko> because you are not the master
[09:14] <hikiko> thats the problem
[09:14] <alan_g> hikiko: didn't we already solve that?
 alan_g, I ll just write a second open_drm_device that doesnt have the check of this branch: https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830 then and use it
[09:14] <hikiko> alan_g, yes but RAOF asked which is the problem
[09:15] <tvoss> hikiko, I don't think we should call setInterfaceVersion in the nested compositor then
[09:15] <mlankhorst> which is what I said :P
[09:15] <hikiko> tvoss, that's what mlankhorst said and initially I did this MP because I thought that for the reason I wrote we dont wont it on mir as well
[09:16] <hikiko> https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830
[09:16] <tvoss> hikiko, we want it on the outer-most mir
[09:16] <hikiko> but ok I ll just remove it from the nested mur
[09:16] <RAOF> alan_g, hikiko: The second open_drm_device should be: { MirPlatformPackage *pkg; mir_connection_get_platform(conn, &pkg); return pkg->fds[0]; }
[09:16] <hikiko> ok then I ll just use another function in my branch
[09:16] <alan_g> hikiko: go for it!
[09:17] <hikiko> no RAOF because this way we ll get the device that the  host uses for rendering and we ll see nothing ... anyway :) I am going to do the change as alan_g says and then we improve it if there's something better :)
[09:18] <duflu> sil2100: Got what you need? AFAIK the LP-based projects are fully landed at least
[09:18] <RAOF> hikiko: That is how *all* (non-software) Mir clients work!
[09:18] <RAOF> hikiko: That *will* allow you to render and allocate buffers correctly.
[09:18] <alan_g> hikiko: we get an fd that allows us to allocate and use buffers - which is what we need
[09:18] <sil2100> duflu: I think all is in now, had a talk with RAOF and I think it should all go smoothly
[09:19] <hikiko> alan_g, RAOF then maybe better to give it a try
[09:27] <duflu> Hah. Don't google saucy wallpapers
[09:32] <RAOF> duflu: bypass is busted on intel; xmir is just exposing the bustedness by drawing enough to fill caches.
[09:32] <duflu> RAOF: I don't understand that statement entirely
[09:33] <RAOF> I'm talking with ickle in #intel-gfx; the horizontal bar corruption we see is stale cachelines.
[09:34] <RAOF> This is why you see it more on multihead than single-head; you're less likely to overfill the cache there.
[09:34] <duflu> RAOF: OK. What is "overfilling" and how is it avoided?
[09:35] <RAOF> Intel-specific stuff.
[09:35] <duflu> RAOF: Anything I can do for it in DRM userland?
[09:35] <RAOF> We need to disable caching for scanout buffers, and then periodically call kgem_busy
[09:36] <duflu> Sounds hackish
[09:36] <RAOF> Yeah.
[09:36] <duflu> That reminds me, I must improve the examples/ to help with that
[09:37] <tvoss> RAOF, is there an example where that is done?
[09:37] <RAOF> tvoss: grep xf86-video-intel for is_scanout; it's fairly widely distributed.
[09:38] <tvoss> RAOF, ack
[09:38] <tvoss> RAOF, where do we need to call kgem_busy? on the client or server-side?
[09:38] <RAOF> Really, server side.
[09:40] <RAOF> Since xmir is the only thing that reliably exposes this at the moment we could get away with doing it in xmir, but Unity8 will hit the same problems later.
[09:40] <tvoss> RAOF, indeed
[09:45] <tvoss> RAOF, is there a trigger that tells us when we should call kgem_busy?
[09:45] <RAOF> Don't know
[09:45] <tvoss> RAOF, ack
[09:45] <RAOF> Although probably when submitting a batch buffer
[09:45] <tvoss> duflu, do you file a bug?
[09:45] <tvoss> RAOF, reading through the numerous commits mentioning kgem_busy right now
[09:46] <duflu> tvoss: I don't think we have one yet. Because it never affected any PPA most people were testing, let alone trunk
[09:46] <tvoss> duflu, ack
[09:46] <tvoss> duflu, might make sense to note it down in a bug, though
[09:47] <RAOF> Actually, we might not have to fix it in the server; fixing it in XMir *and* ensuring that Mesa does the right thing (which it should do) should fix it for both.
[09:47] <RAOF> Which is significantly more tractable.
[09:47] <tvoss> RAOF, indeed, we keep it driver specific with that, don't we?
[09:47] <RAOF> Yes.
[09:47] <tvoss> RAOF, otherwise the server would make _interesting_ assumptions
[09:48]  * duflu votes for driver-specific hacks in driver-specific packages
[09:48] <RAOF> Eh, we'd just need to have a DDX layer for Mir ;)
[09:48] <duflu> :)
[09:48] <RAOF> We'd have a intel-gbm platform, and a nouveau-gbm platform, and…
[09:48] <duflu> Eek
[10:08] <duflu> tvoss, RAOF: Any objections to me logging off? I may yet cook dinner
[10:08] <RAOF> duflu: None from my end?
[10:11] <duflu> RAOF: On my desktop forcing two hardware surfaces to be placed on corresponding outputs (1920x1200) isn't enough to hit corruption/cache issues... !? But that's raring
[10:12] <RAOF> duflu: What card?
[10:12] <tvoss> duflu, feel free. Will call you in case of emergencies
[10:12] <tvoss> ;)
[10:12] <duflu> RAOF: HD2000 (i7-2600)
[10:14] <duflu> RAOF: Also lp:~vanvugt/mir/eglapp-place-output
[10:55] <RAOF> mlankhorst: Oh, where is your current xf86-video-nouveauL?
[10:57] <hikiko> alan_g, if you have a moment could you review this: https://code.launchpad.net/~hikiko/mir/mir.init-native-gbm/+merge/182864 ?
[10:57] <alan_g> hikiko: sure
[10:58] <alan_g> hikiko: there are some MPs you can review too. ;)
[10:58] <hikiko> I am going to pull them alan_g :)
[11:07] <mlankhorst> RAOF: ..?
[11:07] <RAOF> mlankhorst: Yours is the last upload to qa-testing2; I want to prepare that for the archive.
[11:08] <mlankhorst> RAOF: oh didn't upload to github
[11:08] <mlankhorst> just apt-get source it
[11:08] <RAOF> Yeah, that's what I decided to do ;)
[11:08] <mlankhorst> RAOF: can you include xserver-xorg-video-nouveau 1.0.9 too?
[11:08] <RAOF> Sure.
[11:21] <hikiko> alan_g, how can I run the mir tests?
[11:21] <alan_g> hikiko: how long have you been on the project?!
[11:22] <alan_g> hikiko: https://code.launchpad.net/~hikiko/mir/mir.init-native-gbm/+merge/182864/comments/414597
[11:45] <tvoss_> RAOF, mlankhorst sent you some packages for testing purposes
[11:45] <mlankhorst> yeah he should have them
[11:46] <tvoss_> mlankhorst, on nouveau with usc running, could you try to run sudo glmark2-es2-mir?
[11:46] <mlankhorst> sec, let me plug in a more.. stable card
[11:46] <tvoss_> mlankhorst, ack :)
[11:52]  * alan_g suddenly realises that we don't run the test suite for clang or android/armhf targets in CI
[12:05] <mlankhorst> mir should really have -dbg packages
[12:06] <mlankhorst> and usc too
[12:07] <RAOF> No, not really.
[12:07] <RAOF> Use the dbgsym packages.
[12:07] <RAOF> *Debian* should have -dbgsym packages
[12:07] <RAOF> Rather than manually constructing -dbg packages, like _animals_!
[12:08] <mlankhorst> RAOF: in the ppa?
[12:08] <RAOF> IIRC we've turned dbgsym packages on for the PPA.
[12:08] <RAOF> Dear Xserver: your intermittently failing test suite is adorable.
[12:09] <mlankhorst> RAOF: tell me where to find them, then :P
[12:09] <kgunn> RAOF: remember i told you there would be new ways for X to annoy you
[12:09] <RAOF> mlankhorst: I think you need to add the main/debug component to sources.
[12:09] <RAOF> mlankhorst: Enjoy your shiny new nouveau 1.0.9
[12:10] <mlankhorst> ah
[12:10] <mlankhorst> do all ppa's have that?
[12:10] <RAOF> Only those that have dbgsym packages enabled, sadly.
[12:10] <RAOF> Probably for space reasons?
[12:10] <RAOF> I don't know.
[12:10] <mlankhorst> probably
[12:11] <RAOF> But PPAs are space-limited *anyway*
[12:11] <RAOF> We should totally build dbgsym packages *everywhere*
[12:11] <mlankhorst> except we don't
[12:11] <RAOF> should implies don't :)
[12:11] <RAOF> Anyway, sleepy time!
[12:12] <mlankhorst> nn
[12:17] <tvoss_> RAOF, good night and get well soon
[12:22] <mlankhorst> interesting, I'm hitting a bug in vblanking somewhere
[12:22] <mlankhorst> probably
[12:23] <tvoss_> mlankhorst, with my testing packages
[12:26] <mlankhorst> I'm not sure what's causing it yet, but it seems some event is not being sent, ever ;P
[12:27] <tvoss_> mlankhorst, interesting
[12:33] <mlankhorst> hm might be a hang, bah
[12:36] <mlankhorst> ok other card
[12:37] <tvoss_> mlankhorst, ;)
[12:37] <mlankhorst> >:(
[12:38] <mlankhorst> there seems to be a memory corruption affecting all cards, but I don't know how
[13:09] <kgunn> hikiko: ping
[13:14] <hikiko> kgunn, hi
[13:21] <mlankhorst> wow..
[13:24] <tvoss_> mlankhorst, ?
[13:26] <mlankhorst> I may have found my nouveau issue, lets find out..
[13:29] <mlankhorst> hm no, still no closer :/
[13:54] <mlankhorst> tvoss_: do you have a normal glmark too? :P
[13:54] <tvoss_> mlankhorst, normal as in? :)
[13:54] <mlankhorst> x11
[13:54] <tvoss_> mlankhorst, it installs the usual x glmark2 as well
[13:54] <tvoss_> mlankhorst, should be part of the package
[13:56] <mlankhorst> tvoss_: not really, only contains glmark2-mir
[13:56] <mlankhorst> and glmark-es2-mir
[13:56] <tvoss_> mlankhorst, okay, recompiling packages
[13:56] <tvoss_> mlankhorst, thanks for testing :) found the issue btw
[13:57] <mlankhorst> hehe np :P
[13:58] <mlankhorst> btw does it matter if xorg runs in usc or not?
[13:58] <mlankhorst> as opposed to not running at all
[13:58] <sil2100> tvoss_, kgunn: hi guys, can you confirm if everything landed as needed (in -proposed at least)?
[13:58] <tvoss_> sil2100, ack
[13:59] <sil2100> tvoss_, kgunn: related to mir and the two features
[13:59] <mlankhorst> oh btw mesa 9.2 landed now
[13:59] <tvoss_> mlankhorst, wow, you love living on the edge, don't you? :)
[13:59] <tvoss_> mlankhorst, in archive or in proposed?
[13:59] <mlankhorst> tvoss_: proposed
[13:59] <mlankhorst> and now main it seems :P
[14:00] <tvoss_> mlankhorst, ack
[14:01] <mlankhorst> so right in time for feature freeze this time
[14:02] <kgunn> sil2100: yes
[14:02] <mlankhorst> tvoss_: hey last release we landed 9.1 right before final freeze
[14:10] <kgunn> hikiko: i just realized i'm on the hook for a uds session
[14:11] <hikiko> :)
[14:11] <hikiko> no problem kgunn
[14:12] <mlankhorst> unfortunately I cna't make any session this week, g2g :/
[14:15] <kgunn> hikiko: oh...wait...i was wrong...top of the hour....we're still on
[14:38] <jono> tvoss_, hey
[14:38] <jono> so the composite bypass lands today?
[14:44] <tvoss_> jono, yup
[14:55] <smartboyhw> tvoss_, is Mir now already in ubuntu-desktop meta packaage?
[14:55] <tvoss_> smartboyhw, not sure, need to check :)
[14:55] <tvoss_> jono, http://samohtv.wordpress.com/2013/08/29/mir-xmir-performance-in-13-10/
[14:55] <smartboyhw> :)
[14:55] <jono> tvoss_, does that include MM?
[14:55] <tvoss_> jono, the post? no: that's only addressing bypass
[14:56] <tvoss_> jono, I think we need some fixes for mm before we want to blog about it
[14:56] <jono> tvoss_, no I mean is MM in the archive?
[14:56] <jono> as part of FF?
[14:56] <tvoss_> jono, yeah
[14:56] <jono> ahhh awesome
[15:53] <olli> smartboyhw, no, it will need to be in main first before being pulled in as default
[16:29] <ricmm> tvoss_: ping
[16:29] <tvoss_> ricmm, pong
[16:30] <ricmm> tvoss_: where does Mir stand re: resizing/moving surfaces?
[16:30] <tvoss_> ricmm, we don't have it right now
[16:30] <ricmm> is there a plan for this? short-term I mean
[16:31] <tvoss_> ricmm, not really, would be great if we can live a week without it
[16:32] <ricmm> not sure how possible that is going to be with the OSK
[16:32] <ricmm> we will try today, but not sure
[23:33] <arsson> latest updates makes my cursor freeze in lightdm with nouveau?
[23:40] <RAOF> arsson: Updates from where?
[23:54] <arsson> RAOF: basic no ppa
[23:58] <RAOF> arsson: :(
[23:58] <RAOF> arsson: And you're presumably using unity-system-compositor+XMir? Does VT switching away and then back unfreeze the cursor?
[23:59] <robert_ancell> RAOF, lp:~robert-ancell/mir/drop-focus-on-vt-switch seems to work with test clients and drops focus when you VT switch away from them. It has a graphics lock-up as described in the MP, but you can work around it
[23:59] <robert_ancell> It should be good enough to start the XMir side of things
[23:59] <RAOF> robert_ancell: Sweet!
[23:59] <arsson> i went VT and removed u-s-c and now everything is workin


[12:05] <kwwii> night all
[12:05] <kwwii> sleep well
[02:04] <bddebian> Hello
[02:41] <jeroenvrp> https://launchpad.net/distros/ubuntu/+bug/49779
[02:41] <Ubugtu> Malone bug 49779 in Ubuntu "Keyboard locks up" [Untriaged,Unconfirmed]
[03:00] <DaSkreech> google Earth is Qt?
[03:35] <linuxmonkey> DaSkreech: yes it is
[03:36] <DaSkreech> Scwheet
[03:36] <linuxmonkey> a programmer told me its been qt since it started, even the winblows version is qt
[03:40] <DaSkreech> :-)
[03:40] <DaSkreech> Cmon KDE4!
[03:43] <bddebian> heh
[03:44] <DaSkreech> Later
[05:15] <Hobbsee> hey all
[05:16] <freeflying|away> hi Hobbsee
[05:16] <Hobbsee> hey freeflying|away :)
[05:45] <nixternal> Hobbsee: well hell there ;)
[05:45] <nixternal> gahah
[05:45] <nixternal> hello i mean
[05:45] <Hobbsee> hehe hi nixternal
[08:32] <Hobbsee> anyone else feel like joining us?
[08:33] <freeflying|away> Hobbsee: ?
[08:33] <Hobbsee> freeflying|away: teamspeak - testing for the conference - see -motu
[08:38] <nixternal> Hobbsee: HELLO!!!
[08:39] <Hobbsee> hey nixternal!
[08:45] <nixternal> Hobbsee: http://www.tehbisnatch.org/2006/06/14/api-simplicity-and-design/
[08:45] <nixternal> since you were working on kopete ^^
[08:46] <Hobbsee> nixternal: great :)
[08:47] <nixternal> im a blog whore
[08:47] <nixternal> thx to akregator
[08:47] <Hobbsee> hehe
[09:24] <nixternal`zzz> g'nite all
[09:25] <Hobbsee> night nixternal`zzz
[09:59] <fabo> nobody wants to advocate kvpnc ?
[09:59] <Hobbsee> fabo: most people arent awake yet
[10:00] <fabo> i'll ping later so :)
[10:01] <Hobbsee> fabo: you'd be after Riddell or raphink
[10:02] <Riddell-awa> moi?
[10:02] <Hobbsee> morning Riddell-awa
[10:03] <Riddell-awa> and what a grey London style morning it is
[10:03] <Hobbsee> Riddell-awa: well, we're testing out teamspeak, if you were wanting to come and join us...
[10:03] <Hobbsee> and take your mind off they grey London morning
[10:03] <Riddell-awa> still at least I got awoken by a nice Scandinavian person brining me breakfast in my cabin bed
[10:03] <Hobbsee> hehe nice
[10:05] <mornfall> ...
[10:05] <Hobbsee> hey mornfall
[10:05] <mornfall> hi
[10:06] <mornfall> Opeth -- Godhead's Lament
[10:06] <fabo> Riddell-awa: oui toi :)
[10:07] <fabo> mais il faut 2 sponsor ;)
[10:08] <mornfall> brb, strawberries
[10:20] <Riddell-awa> anyone tried the KDE 3.5.3 archive today?
[10:20] <Hobbsee> Riddell-awa: er...which one
[10:20] <Riddell-awa> the one on kubuntu.org
[10:21] <Hobbsee> Riddell-awa: i got some upgrades from it earlier, yeah
[10:21] <Riddell-awa> Hobbsee: so nothing broke?
[10:21] <Hobbsee> Riddell-awa: dont know, havent restarted X yet
[12:04] <seaLne> @time spain
[12:05] <seaLne> @time madrid
[12:05] <Ubugtu> Current time in Europe/Madrid: June 15 2006, 12:05:49
[01:19] <kane_> hi ... anyone here who can tell me how ${shlibs:Depends} works ?
[01:20] <Hobbsee> kane_: heya - it seems to mean that if you have package-dev as a build-dep, package will be automatically installed as a dep.
[01:20] <\sh> insanekane: man dh_makeshlibs
[01:20] <Hobbsee> that works too
[01:20] <Hobbsee> hey \sh
[01:20] <\sh> insanekane: man dh_shlibdeps
[01:21] <\sh> his program is merely a wrapper around dpkg-shlibdeps(1) that calls it once for each
[01:21] <\sh>        package listed in the control file, passing it a list of ELF executables and shared
[01:21] <\sh>        libraries it has found.
[01:21] <insanekane> ok thanks ...
[01:21] <insanekane> \sh: if you don't mind and also, if you are free ... could you explain how I would add a new binary package to an already multi-binary source package ?
[01:22] <insanekane> do i just add something to the control file, and then add a <packagename>.install ?
[01:22] <insanekane> and in the .install, i mention which files i want to be in the package ?
[01:23] <insanekane> \sh: basically, i want to split a package into 2 so that i don't have to pull in libgtk, libatk, pango, etc ...
[01:32] <insanekane> cool, i was right ... that was all that was needed
[01:34] <mornfall> kdesu is my nightmare
[01:34] <mornfall> now i have a bug that when adept is ran through kdesu, the links in about dialog don't work
[01:34] <mornfall> bwaha
[01:34] <mornfall> next version of adept should run as user and only run dpkg as root
[01:35] <\sh> mornfall: that would be a great improvement for adept :)
[01:36] <mornfall> well, the idea is that this will eventually happen
[01:36] <mornfall> but kdesu makes me think that it's a 2.3 or so material
[01:38] <Hobbsee> mornfall: i'm assuming not, but is it possible to force adept not to give a kdesu prompt to login, for a user?
[01:38] <mornfall> Hobbsee: run it as /usr/bin/adept
[01:39] <Hobbsee> without logging into the GUI as root that is, which is effectively what they're asking for
[01:39] <mornfall> Hobbsee: (that should avoid .desktop file)
[01:39] <Hobbsee> mornfall: yeah, but does that give it root privs?
[01:39] <mornfall> no
[01:39] <Hobbsee> that's what i thought
[01:39] <mornfall> it will work as a browser only
[01:39] <mornfall> obviously
[01:39] <Hobbsee> silly user - he cant have it both ways
[01:39] <mornfall> if it could work as root without password
[01:39] <mornfall> well
[01:39] <mornfall> it would be a slight security problem ;)
[01:39] <Hobbsee> yeah, exactly
[01:39] <Hobbsee> :P
[01:39] <Hobbsee> just a slight one, yes.
[01:40] <mornfall> basically, it would have to be setuid, in which case kdelibs will just refuse to work
[01:40] <mornfall> so no go
[01:40] <Hobbsee> that's what i thought, yeah.
[01:40] <Hobbsee> thought the user was wanting to have his cake and eat it to
[01:41] <mornfall> the idea is that in some version, it will only prompt for a password for the actual download+install phase
[01:41] <Hobbsee> nice
[01:42] <mornfall> probably using the same xembed trick as kcontrol... or maybe having the root-running part completely non-gui
[01:49] <insanekane> has edgy development begun ?
[01:50] <Hobbsee> insanekane: sorta
[01:54] <apokryphos> mornfall: great interview, I really enjoyed reading it 8)
[01:54] <mornfall> :)
[01:55] <insanekane> Hobbsee: is there a channel to ask about packaging questions ?
[01:56] <Hobbsee> insanekane: #ubuntu-motu
[01:56] <insanekane> Hobbsee: thanks
[01:56] <Hobbsee> insanekane: if it's kde specific, then here
[01:56] <insanekane> not really
[01:58] <mornfall> The Gathering -- Saturnine
[02:00] <mornfall> The Gathering -- Analog Park
[03:07] <jjesse> did Riddell leave already for paris?
[03:10] <apachelogger> jjesse: considering he is away for about 15 hours, probably
[03:49] <bddebian> Hello
[03:50] <mornfall> jjesse: he mentioned something like that
[07:31] <Tonio_> hey all
[07:31] <jjesse> hiya Tonio_
[07:31] <jjesse> not many around today :)
[07:32] <Tonio_> https://wiki.kubuntu.org/KubuntuXGL
[07:32] <Tonio_> jjesse: am I wrong or is everyone confused with xgl and compiz
[07:33] <Tonio_> I don't see the point between xgl and kde....
[07:33] <DaSkreech> Hmm?
[07:34] <DaSkreech> What do you want to know?
[07:35] <Tonio_> I see verywhere that xgl is uncompatible with kde....
[07:35] <Tonio_> I don't see the point
[07:35] <jjesse> Tonio_: to be honest i've never tried either
[07:35] <Tonio_> DaSkreech: don't they generally speak of compiz ?
[07:35] <jjesse> currently right now i don't have the opportunity to run kubuntu as my primary box, i just run it in a virtual machine
[07:35] <jjesse> so i don't know if i can even run either in VMWare
[07:35] <Tonio_> jjesse: ah ok
[07:35] <jjesse> its one of those things i'd like to.... but
[07:36] <DaSkreech> Tonio_: Yes compixz is currently the important thing
[07:36] <DaSkreech> Which is a hack/rewrite/based off Metacity
[07:36] <Tonio_> DaSkreech: the problem is that even kubuntu specs on that point reffer to xgl, so that I'm quite confused on that point
[07:36] <DaSkreech> So there is some issue with it and KDE
[07:37] <Tonio_> DaSkreech: between compiz and kde, I know that the kde-window decorator component simply doesn't work
[07:37] <DaSkreech> Yeah The compositing server is irrelevant
[07:37] <Tonio_> but technically kde and xgl have no link between them, so that I don't understand the point
[07:38] <DaSkreech> For most times you see people gushing about XGl they mean compiz
[07:41] <Tonio_> DaSkreech: yes but on a spec.........
[07:46] <DaSkreech> Tonio_: Link?
[07:47] <Tonio_> da
[07:47] <Tonio_> DaSkreech: https://wiki.kubuntu.org/KubuntuXGL
[08:28] <DaSkreech> That's kind of misleading
[08:43] <jpatrick> kmon: hey
[09:33] <neoncode> Has the kubuntu usplash just been updated? Adept updater just downloaded an updated version of that package.
[10:05] <marseillai_> jpatrick: i've saw that you've made a package of kitten (now rename strigi) do you have also package the kde3gui or only the search tool ? and i think developer would be happy to have or see this packages.
[10:06] <jpatrick> I'm packaging Kitten, Dolphin, *
[10:07] <jpatrick> CLenuce
[10:07] <marseillai_> clucene ;)
[10:07] <jpatrick> oh ok
[10:07] <jpatrick> marseillai_: got my last exam, tomorrow, tell me what you want packaged then
[10:08] <marseillai_> jpatrick: i think that vandenoever on #kat would be happy to talk with you about this. he his developer of kitten(strigi) and work really hard
[10:08] <marseillai_> oki let you work ....
[10:08] <jpatrick> ok I'm in
[10:08] <jpatrick> introduce me, introduce me :)
[10:09] <jpatrick> marseillai_: ^
[10:10] <jpatrick> Too late
[10:34] <jpatrick> bed time
[10:53] <nixternal`afk> how bad is this update going to be? is it going to destroy my ati drivers and setup now? if i reboot will i still have rendering enabled...im scared here ;)
[10:54] <nixternal`afk> here goes a reboot..if im not back in 3 minutes you know it was bad ;)
[10:59] <nixternal> whew..everything worked...will there be a kernel upgrade from -23-k7 to -25-k7
[11:27] <DaSkreech> What happened ?
[11:27] <DaSkreech> Was there a KDE update?
[11:32] <nixternal> DaSkreech: yes...a bunch of updates from what i seen...xorg and kernel was the big ones
[11:33] <DaSkreech> Man :-( I Hate updating my kernel
[11:33] <DaSkreech> nixternal: So what are the changes?
[11:35] <nixternal> i seen libgnomeprint, xserver-xorg-fglrx, xserver-xorg-glx, linux-2.6.15-25.usplash, and a few others that i can't remember
[11:37] <DaSkreech> Really?
[11:37] <DaSkreech> U have nearly every single KDE app upgraded
[11:38] <DaSkreech> I Have ..
[11:47] <toma> ok, ive had it
[11:48] <toma> im going to patch konqueror to always show the favorite menu bar
[11:49] <Tonio_> DaSkreech: that happens with everypatch to kdebase, since it generates lots of deb files
[11:50] <Tonio_> so I assume that's just a little patch or kdebase
[11:50] <DaSkreech> Kate?
[11:50] <Lure> DaSkreech: kde 3.5.3 got update only (I think)
[11:51] <Lure> DaSkreech: or it may be kdm security patch
[11:52] <DaSkreech> decides against updating the kernel
[11:52] <DaSkreech> Wait
[11:52] <DaSkreech> ..
[11:52] <DaSkreech> naw I'll update :-)
[12:03] <insanekane> is there some way to affect the startup environment of all my users without touching /etc/environment ?
[12:04] <insanekane> (and also override the settings in /etc/environment)