[10:29] <smb> lucent, Seems there is a fix for you heading our way through stable. :)
[11:44] <Kano> hi, where is i386 for 36rc8
[12:01] <ogra_ac> Kano, for natty ?
[12:02] <Kano> mainline
[12:03] <ogra_ac> ah, no idea ... for natty it might have ended up in universe ... happens sometimes with a new release
[12:05] <Kano> only amd64 available
[12:06] <ogra_ac> yeah, probably a packaging issue ... might be though that most of the kernel team is on vacation this week
[12:06] <ogra_ac> pre-UDS week is a typical time for that
[12:27] <apw> Kano, it didn't build, upstream bug
[12:27] <Kano> ah
[12:27] <apw> the build log clearly shows the error, there is a subsequent upstream commit
[12:29] <apw> lag, http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D
[12:30] <Kano> so rc9/final will build again
[12:31] <apw> lag, https://wiki.ubuntu.com/Kernel/MainlineBuilds is where they are documented
[12:31] <apw> Kano, yes, likely the daily after it built
[12:31] <apw> someone didn't do their build tests before submitting their patches there
[12:36] <apw> lag, https://edge.launchpad.net/~kernel-ppa/+archive/pre-proposed
[14:45] <jcastro> pgraner: you need to start accepting/declining sessions here or they won't get scheduled: https://blueprints.edge.launchpad.net/sprints/uds-n/+settopics
[14:49] <diwic> jcastro, what's the deadline for me who wants to have a session but has no privileges to authorize them?
[14:50] <jcastro> diwic: we keep scheduling all through UDS depending on room, speaking to the track lead sooner will help
[14:52] <diwic> jcastro, so can I affect the scheduling algorithm by saying I want to attend some sessions (and the scheduler will try to make them non-overlapping), and if so, how?
[14:52] <jcastro> you affect it if you mark yourself as essential when you subscribe to a blueprint
[14:53] <jcastro> if you just subscribe yourself it will do it's best to not overlap, but "essential" is what guarantees it not to happen
[14:53] <jcastro> https://blueprints.edge.launchpad.net/ubuntu/+spec/appdevs-desktop-n-opportunistic-apps-stable-release
[14:53] <jcastro> it's the subscribe thing on the right.
[14:53] <jcastro> red people are essential
[14:54] <diwic> so for how long can this rescheduling appear?
[14:54] <jcastro> what do you mean?
[14:54] <diwic> I mean, if I subscribe to two currently overlapping sessions, will one move?
[14:54] <jcastro> I believe so
[14:55] <jcastro> it's supposed to prevent them from being scheduled in the first place like that
[14:55] <apw> jcastro, when is primary scheduling going to occur (or has it already)
[14:55] <diwic> right, but the scheduling has already begun, and I can still subscribe to blueprints, right?
[14:56] <apw> jcastro, i think pete is on-site today so unlikely to respond
[14:57] <diwic> jcastro, just to take it to the extremes, can I on next monday realize that I want to attend two sessions going in parallel, mark myself, and it will reschedule, confusing all other people currently walking towards that room?
[14:57] <jcastro> apw: it's supposed to have been occuring over the past few weeks, do any of you have power to approve blueprints? Most tracks have one or two assistants
[14:58] <jcastro> diwic: no, that doesn't happen
[14:58] <jcastro> diwic: I recommend subscribing to the ones you want
[14:58] <apw> jcastro, how does one find out who has, i am pretty sure i do not
[14:58] <jcastro> then using your personal schedule to make sure they don't collide
[14:58] <jcastro> apw: it would probably be the people who did it last time
[14:58] <jcastro> apw: let me look
[14:58] <apw> that likely means pgraner and ogasawara
[14:59] <jcastro> apw: yep, you are correct
[14:59] <apw> who are both on-site today
[14:59] <diwic> jcastro, thanks for the answers, I'm just trying to figure out how the system works :-)
[15:00] <apw> i probabally need to get self added to that list, will have to hastle pete when he is back
[15:00] <jcastro> diwic: duct tape and parachute cord.
[15:00] <apw> jcastro, coo advanced
[15:00] <jcastro> apw: he can't add, only people on the techboard unfortunately. If you ping pitti or colin ask them to put you in ~uds-organizers
[15:00] <jcastro> apw: if you have an idea of what pete wants I suggest you ask them and tell them you talked to me
[15:01] <apw> (i was assuming they would need his authorisation)
[15:01] <jcastro> well, if leann is around later today she can just clean up the queue
[15:02] <apw> yeah no idea of their availability later ... i'll see what i can do
[15:02] <smb> She is onsite as well
[15:02] <apw> yep
[15:03] <jcastro> apw: I can approve obvious ones if you'd like
[15:03] <jcastro> like the typical review sessions you always have, etc.
[15:03] <apw> those i think are already done are they not?
[15:03] <jcastro> let me check
[15:04] <JFo> bug handling needs to be scheduled if it isn't already
[15:04] <jcastro> JFo: done!
[15:04] <apw> jcastro, is https://blueprints.edge.launchpad.net/ubuntu/+spec/hardware-kernel-n-config-review approved enough ?
[15:05] <lag> apw: Pseudo-terminal will not be allocated because stdin is not a terminal.
[15:05] <JFo> thanks jcastro :)
[15:05] <jcastro> apw: yep, ok I think I see the problem, the linaro hardware ones are piling up
[15:06]  * apw looks vague
[15:06] <jcastro> apw: ok I will send them both a mail reminding them. When you see pete mention to him that it's probably a good idea to get one other person in the uds team
[15:06] <apw> jcastro, oh is he in charge of hardware-*
[15:06] <apw> jcastro, will do
[15:07] <jcastro> apw: yeah, it's more of 2 UDSes
[15:09] <apw> jcastro, could you shove over https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-process-review and https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-frankenkernel-maintenance, we are going to defiantly need both of those
[15:10] <jcastro> ok
[15:10] <apw> jcastro, i know that doesn't help you with your issues
[15:11] <jcastro> getting them in there does. :)
[15:31] <apw> jcastro, who is handling blueprints which have no track prefix ?
[15:52] <slow-motion> http://paste.ubuntuusers.de/399129/ that is the dmesg and wscan output from my terratec cinergy t2. before maverick it was working. why does it stopped working?
[16:15] <jcastro> apw: they have to have track prefixes or they don't get scheduled at all
[16:26] <apw> jcastro, and is anyone sweeping for them >?
[16:26] <apw> i see a qemu- prefix
[16:27] <jcastro> I have the power to rename some of them
[16:27] <jcastro> but mostly it's up to the person who filed it to fix it
[16:28] <apw> i wonder if we should have a report or script which spams people if they are using a stoopid prefix
[16:28] <jcastro> well, theoretically if you file a blueprint most people check after a while to see if it got scheduled
[17:00] <cking> jcastro, how does one see if a blueprint is scheduled?
[17:02] <jcastro> cking: check the schedule with the track view: http://summit.ubuntu.com/uds-n/track/hardware/
[17:06] <cking> jcastro, hrm, so any idea why my bp is not there?
[17:07] <jcastro> cking: link?
[17:07] <cking> https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-firmware-test-suite-enhancements
[17:07] <cking> back in a mo - kids...
[17:08] <jcastro> cking: ah, it hasn't been approved yet that's why
[17:08] <jcastro> cking: apw, ogasawara, or pgraner needs to accept it
[17:27] <apw> cking, jcastro done
[17:27] <jcastro> ta
[17:28] <jcastro> apw: that's basically it, ensure the sessions are accepted and they'll autoschedule
[17:30] <cking> apw, ta
[17:31] <jcastro> apw: the cron job runs hourly to autoschedule btw, so accepting them won't show up right away. During UDS it will run much quicker.
[17:36] <apw> jcastro, no worries ta
[17:40] <cking> thanks jcastro
[17:46] <cking> sconklin, http://www.youtube.com/watch?v=4YZeX8ti7Io&feature=player_embedded
[17:48] <sconklin> cking: fun!
[17:49] <cking> sconklin, makerbot + lego = fun :-)
[17:50] <sconklin> there's a new model of the makerbot out with a conveyor which dumps completed objects from the build platform, so you can make multiple copies
[17:56] <cking> nice
[18:35] <apw> jcastro, ok there was some confusion on linaro as to what to do, so they have some cleanup todo ... when thats done i should be able to approve the right ones in short order
[18:36] <jcastro> rock and roll
[21:24] <lucent> smb: Yeah, glad to hear it's on the radar. Discussion with Stefan Richter proved out and I found the commit which broke my firewire setup.
[21:26] <smb> lucent, Yep, saw his mail today and also a pull request for Linus for .36
[21:26] <lucent> it's kind of ... I don't get star struck but hey having my first and last name on something being submitted to Linus Torvalds, kind of makes me feeling shy in a hurry
[21:26] <smb> Its the kind of thing that makes the whole thing running. :)
[21:27] <lucent> yes, I see :)
[21:27] <lucent> there's one more regression I want to address soon, in the mct_u232 usb serial module
[21:27] <lucent> do you know who I would begin discussion with about that?
[21:29] <smb> Hm, usb serial may be big GregKH... You could either check in git who normally is the last one signing of that driver or in the MAINTAINERS file (to find mailing lists)
[21:33] <lucent> got it, thanks
[21:36] <smb> So yes, seems to be him and/or<EMAIL_ADDRESS>And a good backing is when you can say you tried one of the mainline (very recent) kernels and its still broken. Did I tell you where to find the mainline kernel. Forgot whom I already told
[21:36] <smb> lucent, ^
[21:37] <lucent> thank you, and yes I have been testing with mainline to do rough bissection
[21:37] <smb> ok, cool :)
[21:38] <lucent> my last question about the kernels is when I build a custom kernel, how do I change the version so that it is unique when I install the resultant deb packaging?
[21:38] <lucent> there were "new" and "old school" methods described on the Ubuntu wiki
[21:38] <lucent> the "new" method does not say how to set my own versioning
[21:38] <lucent> say, "DEB_BUILD_OPTIONS=parallel=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic"
[21:40] <smb> What I usually do is modifying the first line in debian.master/changelog to have an extension like "+debug1" or so
[21:41] <lucent> okay, by modifying the file, and not an environment variable?
[21:42] <smb> right


[17:09] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3818 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[20:18] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3818 Pending binary packages
[20:38] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3818 Diff missing
[21:18] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3818 Generating diffs
[21:19] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3818 Successfully built


[00:02] <bluemirsabre> glxgears seems to be running pretty well, though I don't know how it would normally run for me on nouveau
[00:06] <bluemirsabre> actually, moving my mouse sporadically makes glxgears slow down
[00:06] <bluemirsabre> from 80 fps to 30
[00:07] <bluemirsabre> brb, going to test glxgears in saucy without mir
[00:08] <jjfrv8> Unit193, just installed r970 and have been poking it like you've described. Sorry to report no issues so far. :)
[00:08] <jjfrv8> Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller
[00:22] <Unit193> jjfrv8: Dang, well thanks for trying at least.  Results to the pad?
[00:22] <jjfrv8> Doing it now.
[00:25] <jjfrv8> Ooops. Spoke to soon. Logged out and got stobing background. Logged back in and Xorg crashed.
[00:25] <jjfrv8> *strobing
[00:51] <Unit193> jjfrv8: How'd it compare to open source Xorg drivers without mir?  (glxgears)
[00:53] <jjfrv8> How do I get there? Can I just reboot and pick my other Saucy image from grub? Or do I need to make it fall back somewhow?
[00:55] <Unit193> As long as you don't have a OEM driver, sure.
[00:55] <Unit193> If it's not a bother, that is.
[00:55] <jjfrv8> np
[01:01] <jjfrv8> Unit193, 60 fps
[01:02] <Unit193> Hrm, that's greatly less than the XMir one.
[01:02] <jjfrv8> for sure!
[01:04] <Unit193> 0_o
[01:06]  * Unit193 is very confused.
[02:06] <bluesabre> only the proprietary drivers seem to be able to sync correctly
[02:06] <bluesabre> perfect 60fps with nvidia
[06:16] <Unit193> Minor weird thing, but topic: change the wiki link to http://ubottu.com/y/xubmap and change https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule to http://ubottu.com/y/saucysch ?
[07:17] <elfy> I'll not make the meeting this afternoon, for what it's worth - I still have the same issues with xmir - no updates for it recently. I'll not use it in the state it's in.
[07:18] <Unit193> Same here, it's almost usable on the netbook, but not even close on anything else.
[07:18] <Unit193> You can see all my testing data on the pad and wikipage.
[07:19] <elfy> well it is usable - but I'll not put up with it not keeping up with me in normal use - typing is fine - it's just the refresh of pages annoying me
[07:19] <smartboyhw> I won't gamble on it for 13.10 either....
[07:22] <Unit193> I'd personally count that as almost usable or less if it's not keeping up even.
[07:24] <elfy> it might be usable Unit193 but if we send xubuntu out like it then I'll stop using it
[07:26] <elfy> I'm not willing to go backwards so that someone somewhere can say "ooh look see people are using mir"
[07:29] <Unit193> I just didn't know how to basically say that without coming off as "If I don't get my way..." style.  I can always remove mir (before I put it live of course), and I honestly gave it a shot.
[07:32] <elfy> well yea - I'm not saying that
[07:32] <Unit193> I know.
[07:33] <elfy> as long as people know I'm not being petulant :)
[07:33] <elfy> anyway - work calls - shall read logs later
[07:33] <Unit193> Adios.
[07:33] <Unit193> Same.
[09:58] <knome> lderan, does that only have versionId -> 13.10, or could one get the codename out of it as well?
[10:00] <lderan> at the moment it just scans the html and replaces .versionId
[10:00] <lderan> oh yeah
[10:00] <lderan> can do codename too
[10:00] <lderan> tho it comes up with ubuntu for the distro name :(
[10:01] <knome> i don't think the distro name is a problem
[10:01] <lderan> cool
[10:01] <knome> that's specific to the slideshow, but not version
[10:01] <knome> so there's no reason to try to get it dynamically
[10:02] <knome> it's always Xubuntu in the Xubuntu slideshow
[10:02] <lderan> true
[10:02] <lderan> shall add the version name to it this evening
[10:02] <knome> cool
[10:02] <knome> shall test that out after that then
[10:02] <knome> but looking at the code, i have no doubts it wouldn't work
[10:04] <lderan> thank you
[10:04] <lderan> aye not much has been added :P
[10:07] <knome> linked the bug to your branch
[10:16] <lderan> ah cool thanks
[13:41] <texadactyl> My 1st time at an xchat mtg.  Do you folks use audio?
[13:41] <OvenWerks> no
[13:41] <smartboyhw> no
[13:42] <texadactyl> Now that's a change from corporate USA!  (-:
[13:42] <OvenWerks> Many of us use a commandline irc client on a remote server :)
[13:42] <smartboyhw> OvenWerks, eh, I use XChat here...
[13:42]  * smartboyhw hates CLI IRC clients
[13:42] <texadactyl> me too
[13:42] <texadactyl> Xchat on Saussy
[13:42] <OvenWerks> xchat is a good client.
[13:43] <texadactyl> Xubuntu on Saussy has become my regular machine
[13:43] <OvenWerks> irssi on screen lets me use the same running client on more than one machine at a time.
[13:43] <smartboyhw> texadactyl, it's Saucy
[13:43] <smartboyhw> Not Saussy...
[13:44] <texadactyl> I failed spelling
[13:44] <texadactyl> (:
[13:44]  * OvenWerks did too
[13:44]  * smartboyhw normally doesn't
[13:44] <OvenWerks> that would be my guess
[13:45] <texadactyl> Would love to get XMir to initialize.  Lightdm always falls back to X
[13:45] <OvenWerks> That pretty much depends on your graphics chip
[13:46] <texadactyl> Intel Mini-ITX Cedar View (GMA3650)
[13:46] <OvenWerks> if xMIR doesn't know what to do with your chip it falls back to X
[13:46] <texadactyl> yEP
[13:46] <texadactyl> Never fails that test
[13:46] <texadactyl> Very stable, faster than 13.04
[13:46] <OvenWerks> my personal opinion is no MIR till after 14.04
[13:47] <texadactyl> Let ubie be the pioneer?
[13:47] <OvenWerks> yes
[13:47] <texadactyl> (:
[13:48] <smartboyhw> OvenWerks, same from me too
[13:49] <OvenWerks> There has been a lot of changes in the multi-media production SW and so up grading to 13.10 or 14.04 is going to be very worth while. a buggy MIR could really hurt people who rely on US for everyday work
[13:49] <texadactyl> Good point about everyday stability
[13:50] <OvenWerks> It is one thing to have a desktop that runs office and a browser, but another to try and test US entire SW suite
[13:51] <texadactyl> Unfortunately, at the moment, there are no easy options for "Try XMir" and "Stop trying XMir".
[13:51] <smartboyhw> OvenWerks, don't forget, this is not a US channel and texadactyl may not know what is US:P
[13:51] <texadactyl> It would not be a difficult utility to develop, though.
[13:52] <OvenWerks> sorry.
[13:52] <texadactyl> I do know what "US:P" is and my skin is very thick!  (-:
[13:52] <lderan> texadactyl: something that makes it fallback to x mmm you could propose that to the mir people
[13:53] <texadactyl> I think that its a LightDM utility
[13:53] <texadactyl> switch between the two
[13:54] <texadactyl> BTW, werks, I've spent 1/2 of my adult life out of the US
[13:54] <lderan> US:P according to google is the U.S. Pharmacopeial Convention
[13:54] <texadactyl> lol
[13:54] <smartboyhw> texadactyl, US != United States of America (at least in OvenWerks and my terms)
[13:54] <OvenWerks> US in this case = ubuntustudio which relies on xubuntu
[13:54] <smartboyhw> !ubuntustudio
[13:55] <smartboyhw> (Sorry for OT)
[13:55] <texadactyl> Ah
[13:55] <texadactyl> At hacker sites, US:P means something else
[13:56] <OvenWerks> there is some people who try to help both. Any work we do for xubuntu helps studio.
[13:57] <smartboyhw> texadactyl, well when I am saying US:P I mean they don't know what is "US" :P
[14:48]  * GridCube is here for the meeting \o
[14:48] <smartboyhw> o/ (as an audience)
[14:48] <texadactyl> Len, Mir could be safely released if LightDM was changed slightly to decide whether or not to launch Mir based on a lightdm.conf (new) parameter (switch).  By default, it should probably be off.
[14:49] <texadactyl> So, if you want to experiment with Mir, edit the file (turn on switch) and reboot.
[14:50] <texadactyl> At the moment, the Xubuntu LightDM seems to be predisposed to unconditionally attempt Mir
[14:50] <texadactyl> Seems like an easy and low-risk change to me
[14:50] <micahg> should that depend on which env you select in the greeter?
[14:50] <micahg> *shouldn't
[14:51] <micahg> maybe not
[14:51] <micahg> well, the issue is the greeter is sitting on top of whatever display server already
[14:52] <texadactyl> Decision is long before greeter
[14:53] <texadactyl> Check out the /var/log/lightdm/ logs
[14:54] <micahg> sure, but the greeter is the first chance a user has to select env :)
[14:54] <texadactyl> E.g. in my case, if there was such a switch, I'd try it once, see that LightDM falls back, and then set the config switch back to default (off).
[14:54] <micahg> aside from grub boot (which isn't visible in most cases anymore
[14:54] <texadactyl> after grub and before greeter
[14:55] <texadactyl> LightDM is an upstart
[14:56] <GridCube> Meeting time?
[14:56] <micahg> upstart is system interaction, not user, but yeah, there could be a switch somewhere in the upstart layer
[14:56] <skellat> Rounding up bugs
[14:56] <smartboyhw> texadactyl, you mean, an upstart job?
[14:56]  * smartboyhw calls for Dear knome
[14:56] <texadactyl> yes
[14:56] <tvoss_> hey all :)
[14:56] <texadactyl> Do a ps ax.....you'll see that lightdm is soon after cron in process id value
[14:57] <jono> for those who don't know him, tvoss_ is technical architect for Mir :-)
[14:57] <tvoss_> smartboyhw, hey there :)
[14:57] <tvoss_> o/
[14:57] <smartboyhw> tvoss_, :)
[14:57] <smartboyhw> Nice to meet you again:P
[14:58] <texadactyl> Meeting time, rubber time?  (:
[14:58] <tvoss_> smartboyhw, yup
[14:59] <GridCube> :) ohai!
[15:00] <lderan> Hello
[15:01] <olli> hi everybody
[15:01] <tvoss_> hey
[15:01] <smartboyhw> Welcome Mir team:P
[15:01]  * smartboyhw is just an audience anyway
[15:01] <micahg> knome: ping?
[15:02] <texadactyl> He's grey
[15:02] <smartboyhw> Is pleia2 attending?
[15:02] <smartboyhw> texadactyl, that's why we need to get him here;P
[15:02] <micahg> please note this meeting is just a checkpoint meeting to make sure we're on track for a decision next week and to make sure we're communicating effectively with the Mir team about outstanding issues
[15:02] <GridCube> smartboyhw: pleia2 has excused herself, she is not feeling well
[15:02] <smartboyhw> GridCube, :(
[15:03] <smartboyhw> The decision is NEXT WEEK...
[15:03] <GridCube> true
[15:03] <micahg> for Xubuntu, probably
[15:03] <smartboyhw> micahg, is next meeting next Thursday?
[15:03] <micahg> yeah
[15:03] <smartboyhw> Because I have to remind you guys, it's 12.04.3 release day
[15:03] <micahg> smartboyhw: that's great, I think we forgot about that...
[15:03] <knome> allö!
[15:03] <micahg> knome: are we releasing 12.04.3?
[15:03] <knome> i'm sorry i've a few minutes late
[15:04] <knome> micahg, we should, we even did one SRU bug procedure..
[15:04] <micahg> smartboyhw: I don't think that being a release day will impact our need for a decision though
[15:04] <smartboyhw> micahg, sure:)
[15:04] <knome> #startmeeting Xubuntu community meeting
[15:04] <meetingology> Meeting started Thu Aug 15 15:04:52 2013 UTC.  The chair is knome. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:04] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[15:04] <micahg> knome: do we have images/testers?
[15:04] <smartboyhw> micahg, I will test for you guys:)
[15:05] <GridCube> :)
[15:05] <micahg> knome: we're still oversized I think, I should fix that
[15:05] <knome> micahg, yes, we'll have testers
[15:05] <knome> micahg, but we also need the SRU uploaded
[15:05] <skellat> micahg: And that SRU kinda needs to be done eventually
[15:05] <knome> (it's the docs)
[15:05] <micahg> knome: SRU won't be in 12.04.3
[15:05] <knome> micahg, aha?
[15:05]  * smartboyhw thinks we should get the main topic back on track so the Mir team doesn't get confused:P
[15:05] <knome> micahg, then i don't know why we're releasing.
[15:06] <knome> #topic Items carried on
[15:06] <micahg> knome: updated kernel?
[15:06] <micahg> knome: let's discuss later
[15:06]  * knome shrugs
[15:06] <tvoss_> smartboyhw, no worries, all good on this end :)
[15:06] <knome> #action bluesabre to create a basic user-profile-image app
[15:06] <meetingology> ACTION: bluesabre to create a basic user-profile-image app
[15:07] <knome> #action team to write lightdm greeter testcase
[15:07] <meetingology> ACTION: team to write lightdm greeter testcase
[15:07] <knome> #nick team
[15:07] <knome> #action skellat to prepare blog article discussing updating & upgrading for users and why it is okay to do so
[15:07] <meetingology> ACTION: skellat to prepare blog article discussing updating & upgrading for users and why it is okay to do so
[15:08] <knome> i think those are the open items
[15:08] <knome> #topic Team updates
[15:08] <knome> apart from Mir testing, what's up?
[15:08] <knome> (please use #info)
[15:09] <skellat> #info skellat prepared an SRU bug for the revised documentation for 12.04
[15:09] <knome> micahg, can we discuss why we can't get that uploaded and in the SRU?
[15:09] <GridCube> #info Desktop of the week will choose and propose the first desktop for tomorrow, we hope it gets its proper place in the main site and social networks
[15:09] <micahg> knome: week before image release is too late for an SRU
[15:10] <micahg> it takes 7 days to get through -proposed
[15:10] <knome> micahg, it is a documentation update, and the bug has been ready for ages
[15:10] <lderan> #info adding in the ability for the installation slideshow to automatically use the version number, and soon the version name
[15:10] <micahg> knome: right, but needs to be uploaded
[15:10] <skellat> #info Unit193 and GridCube both made waves in media relative to the experimental XMir image
[15:10] <knome> micahg, sure. but there has been enough time to do that.
[15:11] <micahg> knome: right, but as no one has done it, it doesn't go in
[15:11] <smartboyhw> #info 12.04.3 is next week...
[15:11] <micahg> we can have it in updates a week from Monday hopefully, i'll try to upload this weekend
[15:12] <skellat> #info skellat will be presenting UbuCon at Ohio Linux Fest 2013 and intends to represent Xubuntu whilst there
[15:12] <knome> micahg, is it a given that it takes a week, or can we make it happen faster by poking the right people?
[15:13] <micahg> knome: it would need to be in already to get on the image
[15:13] <knome> GridCube, we'll have to see how to incorporate the gallery to the website. selecting is fine this week, but can we postpone release to next week, say mon/tue?
[15:13] <micahg> we lost track of the release schedule unfortunately, so we weren't ready
[15:14] <GridCube> knome: ill inform the team then
[15:14] <knome> GridCube, thanks
[15:14] <micahg> if I would've remembered, i would've uploaded already
[15:14] <knome> micahg, we didn't - we just didn't have uploaders handy. we need to do something for that
[15:14] <knome> micahg, if i can sort the rest of the bureaucracy and social things out, can you upload today?
[15:14] <GridCube> #action: GridCube to inform the desktop of the week team that the site will be ready next week, we should prepare a few options for the upcoming weeks
[15:14] <meetingology> ACTION: : GridCube to inform the desktop of the week team that the site will be ready next week, we should prepare a few options for the upcoming weeks
[15:15] <skellat> Requests were made to multiple SRU vanguards as per procedure
[15:15] <micahg> knome: sure
[15:15] <knome> micahg, thanks
[15:15] <knome> #action knome to make sure the docs hit the 12.04.3 SRU
[15:15] <meetingology> ACTION: knome to make sure the docs hit the 12.04.3 SRU
[15:15] <micahg> skellat: SRU people can't do anything until it's uploaded
[15:15] <knome> #action micahg to upload docs SRU
[15:15] <meetingology> ACTION: micahg to upload docs SRU
[15:15] <micahg> if someone would've just reminded me 12.04.3 is coming I would've done it
[15:15] <knome> sure
[15:15] <skellat> micahg: Acknowledged.
[15:15] <micahg> I didn't realize we were up against a dealine
[15:16]  * smartboyhw has, but too late:P
[15:16] <knome> yeah, ACK
[15:16] <lderan> GridCube: when & how are we deciding on the desktop? a mini meeting at some point?
[15:16] <knome> #topic Announcements
[15:16] <knome> i had one but i forgot...
[15:16] <smartboyhw> knome, :O
[15:16]  * knome shrugs
[15:16] <knome> anybody else+
[15:16] <knome> ?
[15:16] <skellat> Anybody who has Xubuntu stuff they would like to have given away at Ohio Linux Fest...please let me know
[15:17] <knome> skellat, when is that?
[15:17] <skellat> September 13th will be UbuCon
[15:17] <knome> skellat, and, you should probably ask pleia2 if she has any excess
[15:17] <skellat> Understood
[15:17] <knome> skellat, or if we could make unixstickers.com send you some
[15:17] <skellat> Cool
[15:18] <knome> (they usually share revenue, but since we can't take money, they'll send us free swag now and then)
[15:18] <GridCube> lderan: probably trhough the mails
[15:18] <skellat> Anybody who is within the team and is able to make it to UbuCon is more than welcome to join us.  UbuCon will be free to attend on the 13th of September.  There will be standing recognition at the start of the day for all Ubuntu Member folks in attendance.
[15:18] <knome> nice
[15:18] <knome> have fun there skellat :)
[15:19] <GridCube> lderan: not all the people in the desktop of the week can joing irc at the same time
[15:19] <lderan> GridCube: sounds good to me
[15:19] <knome> lderan, GridCube, can we discuss this at the end of the meeting?
[15:19] <GridCube> sure, sorry
[15:19] <knome> #topic New and emerging items
[15:20] <knome> #subtopic Mir: Feedback and discussion, roadmapping the last week before decisions
[15:20] <knome> Unit193, skellat, people: floor's yours
[15:20] <skellat> I have some relevant bugs to lay out for the purposes of today's discussion
[15:20] <skellat> LP Bug #1102757
[15:20] <skellat> LP Bug #1196239
[15:21] <skellat> LP Bug #1195811
[15:21] <skellat> LP Bug #1193222
[15:21] <skellat> LP Bug #1109963
[15:21] <skellat> LP Bug #1102760
[15:22]  * tvoss_ waits a little :)
[15:22] <skellat> First off, I want to thank tvoss_ for joining us today.
[15:22] <tvoss_> skellat, thanks for having me here :)
[15:22] <GridCube> :) yes, thank you tvoss_
[15:22] <skellat> The bugs mentioned above look like the most major ones we need to worry about.
[15:22] <skellat> Our goal in considering XMir/Mir overall is to address whether or not this represents an overall regression.
[15:23] <tvoss_> skellat, sure, want me to quickly walk through them and relate them to the team's roadmap/current work?
[15:23] <skellat> Will XMir/Mir present an experience to the user that markedly differs from that in 13.04, 12.10, and 12.04.
[15:23] <skellat> tvoss_: Hold on just a moment
[15:23] <tvoss_> skellat, sure :)
[15:24] <skellat> We also have a request made via Jono Bacon to hold off on making our decision as some code is expected to land on August 22nd to address multi-monitor support and composite bypass.
[15:24] <skellat> Before we get too far along, I would hand over to tvoss_ to address the Mir crew's roadmap/current work.
[15:25] <knome> very well :) tvoss_: welcome!
[15:25] <skellat> tvoss_: The floor is yours
[15:26] <tvoss_> skellat, thanks :) so first off: thanks for testing Mir, and for putting together the iso. For the bugs that skellat layed out here: multi-monitor and composite bypass are features that the team is actively working upon
[15:27] <tvoss_> for composite bypass, that would be 1109963, for multi-monitor work 1102760 and 1196239
[15:27] <jono> (btw, I created https://wiki.ubuntu.com/Mir/GPUTesting for tracking testing for different GPUs)
[15:27] <knome> tvoss_, jono pointed out that the deadline for those is August 22, is this still the target?
[15:27] <tvoss_> knome, yup, the team is committed to land those features by that date
[15:28] <olli> knome, we target landing on 8/22
[15:28] <olli> but reality might have us +/-1d
[15:28] <tvoss_> olli, true, thanks
[15:29] <knome> tvoss_, olli: if you could keep us informed on that, would be great; aug 22 is set as our decision date, and if everything else seems to work for us we might want to postpone that a *few* days (not a week)
[15:29] <tvoss_> knome, sure, we will make sure you are up to date. I would think a post to your ml is okay?
[15:29] <olli> knome, our goal is to have the features available (and backed by a larger call for testing) with enough time to Feature Freeze on 8/29
[15:29] <jono> knome, we will definitely keep you informed
[15:30] <knome> tvoss_, definitely. if you send me your email i can add it to auto-approved if you aren't subscribed (olli as well)
[15:30] <skellat> A small preference would be to avoid having to make the decision during the UDS timeframe
[15:31] <tvoss_> knome, thanks
[15:31] <tvoss_> skellat, noted down
[15:32] <olli> tvoss_, shall we talk about the list of bugs skellat posted earlier
[15:32] <tvoss_> olli, yeah, just looking at them again, filtering out the multi-monitor and bypass bugs/features
[15:32] <olli> fyi: we consider MultiMonitor and composite bypass as major feature deliveries, whereas missing dpms is a bug at this stage
[15:33] <olli> using dpms as an example
[15:34] <tvoss_> yeah, for #1102757: vt switching is working now with XMir from the archive and I *think* the bug is fixed, too. Will check with the team tomorrow and update the status
[15:34] <jono> skellat, why not make the decision in the UDS timeframe? isn't that what UDS is for? :-)
[15:35] <smartboyhw> jono, I think the problem is that Xubuntu needs to make the FF
[15:35] <tvoss_> olli, skellat for the dpms bug: Mir is capable of switching off the screen, we need to wire that up to the X side of things
[15:35] <smartboyhw> Which is on 29th
[15:35] <smartboyhw> FF = Feature Freeze
[15:35] <skellat> jono: I'll come to that in a moment but we need to let the folks from the Mir crew continue
[15:35] <jono> smartboyhw, ahh I see, too close to FF
[15:35] <jono> np
[15:35]  * GridCube wonders if canonical would'nt just disregard the problems with ff in this matter
[15:35] <jono> agreed about making the decision earlier :-)
[15:36] <skellat> GridCube, that would be jumping ahead to another question.  But since we've disposed of LP Bug #1102757 let us let the Mir crew continue.
[15:36] <tvoss_> skellat, finally: https://bugs.launchpad.net/mir/+bug/1195811 is being worked upon, too. It turns out to be an issue in the kernel (as per the comment stream on the bug) and we are making progress on it
[15:37] <skellat> tvoss_: For that we had bluesabre experience it in testing Wednesday night directly
[15:38] <tvoss_> skellat, ah, with XMir?
[15:38] <skellat> Yes
[15:38] <skellat> Any coordination with the Kernel crew on resolving that issue?
[15:38] <tvoss_> skellat, mlankhorst is looking into it, he is pretty familiar with the nouveau and kernel drm bits
[15:38] <skellat> Okay
[15:38] <texadactyl> tvoss, I'd like to see a Mir on/off switch in lightdm.conf so that folks choose whether to try Mir or go straight to X
[15:39] <olli> texadactyl, that's in place
[15:40] <tvoss_> texadactyl, yeah. so you can disable Mir bei either apt-get removing unity-system-compositor or by commenting out type=unity in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf
[15:40] <smartboyhw> I think he wants a GUI one....
[15:40] <tvoss_> texadactyl, that's what I use to do benchmarking for example
[15:40] <texadactyl> dont need a gui
[15:40] <smartboyhw> texadactyl, heh, say it earlier and I would've told you that:)
[15:40] <texadactyl> Which parameter tag for lightdm.conf?
[15:41] <GridCube> GUIs are always good
[15:41] <texadactyl> Sure but a parameter is enough
[15:41] <GridCube> yes
[15:42] <smartboyhw> texadactyl, in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf
[15:42] <smartboyhw> Comment out type=unity if you don't want Mir
[15:42] <tvoss_> texadactyl, so are you happy with commenting out type=unity in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf?
[15:42] <texadactyl> I was hoping for a flag type of parameter in /etc/lightdm.conf
[15:42] <texadactyl> but ok
[15:42] <skellat> Okay, if we can come back to LP Bug #1196239...I was wondering if the Mir crew could explain that issue a little further if possible.
[15:42] <GridCube> shouldnt it be type=mir?
[15:43] <smartboyhw> GridCube, no:P
[15:43] <GridCube> type=unity makes no much sense to me
[15:43] <texadactyl> No, "unity" is correct
[15:43] <tvoss_> skellat, looking again
[15:43] <GridCube> its not unity we want to disable its mir...
[15:43] <smartboyhw> GridCube, because XMir needs the Unity System Compositor to work
[15:43] <smartboyhw> That's why...
[15:44] <texadactyl> unity-system-compositor is the executable that does the detection of graphics card
[15:44] <texadactyl> In my case, it gives up    )-:
[15:44] <GridCube> then, it should be the whole of that
[15:44] <tvoss_> GridCube, in that case: just apt-get remove unity-system-compositor
[15:45] <texadactyl> But we want folks who are able to try it
[15:45] <texadactyl> Blowing up is ok
[15:45] <texadactyl> (:
[15:45] <texadactyl> Its part of the experience, yes?
[15:45] <skellat> Okay, I think that line of discussion needs to be parked for the moment.  We can come back to it but we need to handle this last bug issue.
[15:45] <GridCube> well no, thats not either, if its a setting, like to test no mir, then i would think its "use-mir=false" or something like that, but again im not a programmer and you know more
[15:45] <texadactyl> agreed, cube
[15:45] <tvoss_> skellat, so for the resolution bug: as mentioned on the comment stream, that is part of multi-monitor work. Mir is taking over display detection and configuration in the system-compositor scenario
[15:45] <texadactyl> put it in lightdm.conf
[15:46] <skellat> tvoss_: Okay, so that is folded into the whole matter.
[15:46] <tvoss_> skellat, right, and X's xrandr is wired up to Mir in the XMir scenario
[15:47] <tvoss_> skellat, that wasn't the case when the bug was filed but will be enabled by multi-monitor support
[15:47] <skellat> tvoss_: A tricky set of legacies developed over 25 years that have had to be untangled in a very short amount of time, then?
[15:48] <skellat> Now, to get back to the question from jono about avoiding UDS for making a decision.
[15:48] <tvoss_> skellat, yes, but xrandr is straightforward enough to be able to wire it up to mir and its client side api
[15:49] <skellat> The main reason we need to avoid UDS is because UDS-1308 falls around Feature Freeze.  Due to the varying schedules of our team, it must be remembered that last UDS we de-coupled from it to have the "Three Nights of Xubuntu" outside the UDS schedule so we could get maximum participation.
[15:49] <skellat> For a decision this major we want to ensure we have it done somewhat before Feature Freeze and so that our uploader developers are also able to fully chime in.
[15:50] <skellat> They have complicated schedules and their participation is essential.
[15:50] <skellat> There has already been mailing list discussion about how to handle announcing during the UDS time period whatever decision we make but nothing final has come of that yet.
[15:50] <jono> skellat, as I said, I now understand your point
[15:51] <jono> I forgot FF was the same few days as UDS
[15:51] <jono> agreed in making a decision earlier
[15:51] <knome> jono, generally, from my POV, it is really weird that vUDS is literally ending up on the day of FF
[15:51] <jono> knome, well, UDS is designed to plan the next three months of work
[15:52] <knome> this makes it prone for developers to announce new things that "need" to be in the release really close to the deadlines
[15:52] <knome> sure. then why not schedule it after the FF, if it has no connection with that?
[15:52] <knome> everybody is busy before FF anyway
[15:52] <knome> just saying, for future considerations
[15:52] <jono> knome, well, that issue is not an issue with UDS timing but with the devs ;-)
[15:52] <knome> well, it is
[15:52] <jono> devs should not be announcing things that have to be in with a day's notice :-)
[15:53] <knome> no, but devs are the ones that are attending UDS
[15:53] <micahg> devs shouldn't be wasting time with days of meetings before FF
[15:53] <jono> knome, I guess I don't understand the problem with UDS timing here
[15:53] <skellat> Okay
[15:53] <knome> and if that's right before FF, it's bad scheduling
[15:53] <jono> oh I see
[15:53] <jono> so the issue is devs focusing on UDS and not release?
[15:53] <micahg> right
[15:53] <jono> gotcha
[15:53] <jono> agreed
[15:53] <jono> we will try to prevent that in future
[15:53] <jono> fair point
[15:54] <xequence> why not have a UDS right after release, as usual?
[15:54] <knome> (and the other point is that we've seen late announcements before, and from my POV, vUDS days before FF sounds a bad idea regarding that)
[15:54] <xequence> and the next one 3 months after that
[15:54] <smartboyhw> +1
[15:54] <jono> np
[15:54] <knome> or, announcing features that *will* land before FF, but basically makes everybody fix and tweak a lot of things
[15:55] <knome> jono, if you see where i'm coming from?
[15:55] <jono> knome, yup
[15:55] <skellat> Right now I want to thank the Mir crew representatives for joining us and for all the hard work they've put into the monumental task they're undertaking.  Before we go into any questions, the last question I want to be put to the Mir crew is whether or not the somewhat general Feature Freeze exception for Touch announced by Steve Langasek would also allow continuing effort to be put in indirectly to land further refinements to desktop display
[15:55] <jono> I agree in making UDS after FF
[15:55] <knome> jono, great, thanks.
[15:56] <jono> knome, will check the release schedule more rigorously in future when picking dates :-)
[15:56] <xequence> oct, jan, april, july (I suppose July is not a good month for UDS)
[15:56] <knome> jono, great
[15:56] <smartboyhw> jono, will that be in effect for this UDS?
[15:56] <jono> smartboyhw, I am not changing the dates of the UDS in two weeks, no
[15:56] <jono> but the following one we will assess the release schedule more closely
[15:56] <knome> thanks olli and tvoss_!
[15:57] <knome> (and jono)
[15:57] <knome> if nobody has anything else regarding mir, let's move on
[15:57] <jono> thanks, folks
[15:57] <GridCube> :)
[15:57] <tvoss_> knome and all, thanks for the invitation and thanks for your feedback :)
[15:57] <olli> skellat, re FFe: we target to not use an FFe for Mir/Xmir
[15:57] <skellat> olli: Excellent.
[15:57] <olli> for features specifically
[15:58] <skellat> Thank you for joining us gentlemen.
[15:58] <knome> tvoss_, olli: no problem! if it fits your schedule, i'm sure people won't mind you being around next week at the same time and place
[15:58] <olli> we acknowledge that by 8/29 there will probably be bugs lingering
[15:58] <smartboyhw> olli, if it's just bugfixes you don't need an FFe anyway:P
[15:58] <olli> which we hope to squash well before Final Freeze
[15:58] <tvoss_> knome, yup, I will be around
[15:58] <knome> tvoss_, cheers!
[15:59] <knome> olli, if you PM me your email address, i can add it to auto-approve on our developer mailing list
[15:59] <knome> #subtopic Proposal for more structured handling of Xubuntu bugs
[15:59] <knome> skellat, want to postpone?
[15:59] <olli> knome, thx, will be here
[15:59] <knome> skellat, or want to go ahead?
[15:59] <skellat> knome: Carry over
[15:59] <knome> oki
[15:59] <knome> #subtopic Inclusion of Xfce 4.11 components in Xubuntu 13.10
[15:59] <knome> i'm quite tight on time, but...
[15:59] <knome> i would think we should cherry-pick some components
[16:00] <micahg> that needs input from mr_pouit and I don't see him around
[16:00] <knome> Noskcaj has been packaging some already
[16:00] <knome> i'll get ahold of mr_pouit
[16:00] <knome> basically, what i'm thinking is:
[16:00] <knome> xfce 4.12 won't be released before 13.10 FF
[16:00] <knome> it's not clear if it's released before 14.04 FF
[16:01] <knome> the 4.11 components have things that we've been preparing for some time already, and it would be quite sad to not have them in the LTS
[16:01] <micahg> well, if it were just the first issue and not the second, I'd happily take them now
[16:01] <knome> and since they are ready now, i don't see any reason not to include them now (also to have a larger testing base)
[16:02] <micahg> it's the second that concerns me, so that why I'd rather have mr_pouit's input
[16:02] <knome> not being ready for 14.04?
[16:02] <micahg> yeah
[16:02] <micahg> we have to worry about the LTS -> LTS upgrades both ways
[16:02] <knome> i mean, i'd still want *some* 4.11 stuff in 14.04 anyway
[16:03] <knome> to name a specific feature, i would like the display-dialog in 13.10
[16:03] <knome> there's also a patch that allows gtk3 indicators work on a gtk2 panel
[16:03] <knome> it's not clear if it's ever going to be included in xfce itself, but it's something we might want to consider, as ochosi said
[16:03] <micahg> patches we can cherry pick if needed
[16:04] <micahg> as for the feature stuff, if mr_pouit signs off, I'll do my best to get stuff in by FF
[16:04] <knome> i *know* it brings a delta, and i *know* it's more maintaining, but realistically, it's something we want more than the xfce team needs
[16:06] <knome> so, anyway...
[16:06] <knome> #action knome to contact mr_pouit about including xfce 4.11 stuff in 13.10
[16:06] <meetingology> ACTION: knome to contact mr_pouit about including xfce 4.11 stuff in 13.10
[16:06] <micahg> well, GTK3 indicators on GTK2 panel would mean dropping a lot of the GTK 2 indicator stack, so that's a big win
[16:07] <knome> definitely, and would mean we could lose some maintaining from that side
[16:07] <micahg> and get the messages indicator back ;)
[16:07] <knome> yup
[16:08] <knome> let's discuss this throughout the week more
[16:08] <knome> #subtopic Schedule next meeting
[16:08] <knome> #info Next meeting is August 22, 15UTC.
[16:08] <knome> #endmeeting
[16:08] <meetingology> Meeting ended Thu Aug 15 16:08:38 2013 UTC.
[16:08] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/xubuntu-devel/2013/xubuntu-devel.2013-08-15-15.04.moin.txt
[16:08] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/xubuntu-devel/2013/xubuntu-devel.2013-08-15-15.04.html
[16:08] <knome> thanks everybodu!
[16:08] <knome> s/u/y/
[16:08] <smartboyhw> knome, :)
[16:08] <knome> i'll update the logs later today
[16:12] <knome> ok, i'm off for now.
[16:12] <knome> see you later
[16:13] <knome> (i'll try to handle the SRU stuff later)
[17:16] <elfy> knome: just so you are aware - the lightdm greeter testcase hasn't been written yet because of the bug in it - when that's dealt with I can do the testcase - will take no time at all
[18:07] <Unit193> tvoss_: One question I didn't see asked, and couldn't make the meeting.  Where does virtual support stand?
[18:12] <tvoss_> Unit193, on the list, but bypass and multi-monitor have a higher priority. I will cross-check with the team though
[18:18] <Unit193> Of course, but last I saw was a comment "We don't need this for 13.10" :/
[19:32] <OvenWerks> cub: in #xubuntu-devel "< texadactyl> Len, Mir could be safely released if LightDM was changed  slightly to decide whether or not to launch Mir based on a  lightdm.conf (new) parameter (switch).  By default, it  should probably be off.
[19:32] <OvenWerks> cub: in #xubuntu-devel "< texadactyl> Len, Mir could be safely released if LightDM was changed  slightly to decide whether or not to launch Mir based on a  lightdm.conf (new) parameter (switch).  By default, it  should probably be off.
[19:32] <OvenWerks> cub: in #xubuntu-devel "< texadactyl> Len, Mir could be safely released if LightDM was changed  slightly to decide whether or not to launch Mir based on a  lightdm.conf (new) parameter (switch).  By default, it  should probably be off.
[19:52] <OvenWerks> Ack! my mouse is being bad sorry for the noise.
[20:05] <lderan> knome, http://pastebin.com/raw.php?i=UPtAVFg1 this now produces this http://lderan.co.uk/welcome.png :P
[20:11] <lderan> and its now on my lp branch
[20:12] <Unit193> grep VERSION= /etc/os-release  is more "pretty"
[20:15] <lderan> python doesn't have the ability to grep things as far as I know, would have to scan the file manually
[20:18] <lderan> distro, version, release = platform.linux_distribution() isn't too bad :P
[20:18] <Unit193> lderan: Sure, it's the way to get the output so you can see it, also just my opinion. :P
[20:21] <knome> lderan, ahh... instead of "raring", i thought the interesting string would have been "Raring Ringtail"
[20:22] <lderan> can get it from the /etc/os-release, its just raring in /etc/lsb-release
[20:23] <knome> yeah, that's pretty useless in user-facing stuff
[20:23] <lderan> okay
[20:23] <Unit193> And the version number changes for point releases.
[20:25] <knome> Unit193, but that's a non-problem
[20:25] <Unit193> knome: I was thinking handy, actually.
[20:25] <knome> Unit193, at least from my POV, but sure, you could strip off the first 5 chars :P
[20:25] <knome> mhm
[20:27] <knome> upgrading system
[20:28] <knome> and when i say that, i mean updating packages :P
[20:29] <Unit193> apt-get dist-upgrade, the best way!
[20:29] <knome> that
[20:29] <Unit193> I have 3.10.7 in queue, maybe should reboot. ;P
[20:32] <lderan> so to be sure i get it to output the right stuff, "Raring Ringtail" & "13.04"? would "13.04, Raring Ringtail" be of any use?
[20:33] <knome> i'd just make them use separately
[20:33] <knome> *available for use
[20:34] <lderan> sure thing
[20:34] <knome> i don't think we should worry about the formatting itself, people can figure that out
[20:47] <micahg> distro  info would be the canonical way to get latest stable now
[20:48] <knome> hmm?
[20:48] <Unit193> `distro-info` doesn't get it from the currently running system, though.
[20:48] <micahg> check out the distro-info package
[20:48] <micahg> no
[20:49] <Noskcaj> micahg, Can you try and fix the indicator plugin patch? i have zero knowledge of C
[20:49] <knome> micahg, the point *is* to get the version from the current system
[20:49] <micahg> Noskcaj: yes, was already on my list
[20:49] <Noskcaj> micahg, thanks
[20:49] <knome> micahg, we're showing that information in the installer slideshow, so it's better not tell you lies about your system ;)
[20:49] <ochosi> hey micahg
[20:50] <micahg> knome: ah, slideshow should have a version variable (if not, that's a feature request)
[20:50] <Noskcaj> knome, On the topic of the slideshow, can someone add an OEM slideshow? I made on for 13.04, but no-one merged it
[20:50] <micahg> ochosi: yes, gtk-theme-config still on my list
[20:50] <knome> micahg, it is a feature request, and we're working on right now :)
[20:50] <knome> Noskcaj, how does one get to xubuntu oem installation?
[20:50] <ochosi> micahg: hehe
[20:51] <Noskcaj> knome, select the option when you first load the installer
[20:51] <ochosi> micahg: i (also) wanted to say that i'm currently locally testing the gtk3-panel-wrapper for the indicator-plugin
[20:51] <Noskcaj> so far only ubuntu has an OEM slideshow
[20:51] <micahg> knome: if it's build time, lsb_release -cs or lsb_release -rs with a build dependency on lsb-release
[20:52] <micahg> or if lsb-release is in the live env
[20:52] <micahg> ochosi: ok
[20:53] <knome> micahg, don't tell me! lderan is on it, and i think he's finding a python way to do that
[20:53] <micahg> ah, yeah, there's a python way as well
[20:53] <micahg> idr offhand
[20:53] <ochosi> micahg: not sure who would take the final call but it sounded like you would be approving the delta (if it works)
[20:53] <knome> micahg, there's an implementation that gets the version number already, just adding the codename here :)
[20:54] <lderan> yeah at the moment it just returns "raring"
[20:54] <micahg> distro info can provide more info
[20:55] <micahg> and it has a python module
[20:55] <knome> micahg, but if it's not installed by default in all flavors, it's no good
[20:55] <micahg> could be part of the installer seed :)
[20:56] <micahg> it's smal
[20:56] <micahg> small even, under 10k
[20:56] <knome> i know, but if we can do it with whatever we have now, why bother?
[20:56] <micahg> *if* :)
[20:56] <knome> and even if it's small, it's still more load to the ISOs, and nobody wants that
[20:56] <knome> i'm pretty sure we can.
[20:58] <lderan> the info is in /etc/os-release, if we can access it from the installer slideshow bit
[21:00] <Unit193> It would then also show you the running system, not sure how it'd be done with distro-info, personally.  I've used that in another script, though.
[21:01] <ochosi> micahg: i've successfully installed the gtk3-panel and wrapper and indicator-plugin for gtk3, but it still tries to load gtk2 indicators, any idea where/how those are linked? (already uninstalled the two gtk2 indicator packages)
[21:06] <micahg> xfce4-indicator-plugin?
[21:06] <ochosi> yea, i guess
[21:06] <ochosi> right now i get: (wrapper-2.0:23584): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported
[21:07] <ochosi> so i assumed it tries to load gtk2 indicators
[21:07] <micahg> well, that's the whole problem withgtk2 panel, gtk3 indicators
[21:08] <ochosi> well right, but supposedly the wrapper-2 fixes that
[21:08] <ochosi> i've had gtk2 plugins in a gtk3 panel woring
[21:08] <ochosi> working
[21:09] <ochosi> so i doN't think the other way round is a problem
[21:09] <ochosi> anyhoo, guess i gotta sleep now, i'll try again on the weekend..
[21:09] <Unit193> Good night.
[21:13] <lderan> doesn't look like distro-info provides the current version name, can list them and tell which are lts and which is the newest tho.
[21:26] <micahg> lderan: get the current the way you were and use distro info to give you it in whatever form you wat
[21:26] <micahg> *want
[21:27] <lderan> aye
[21:30] <lderan> sounds good to me
[21:36] <Unit193> Ah, I see.
[22:02] <bluesabre> dang, so much backlog
[22:02] <Unit193> bluesabre: Haaaave fun.
[22:02] <bluesabre> skellat: I would like to point out that the nouveau drivers themselves do not do vsync.  With nouveau and no xmir, I was getting 120 FPS
[22:02] <bluesabre> with nouveau + xmir, it was 30-80
[22:03] <bluesabre> nvidia-310 or 315 = 60
[22:03] <Unit193> bluesabre: I got less than half as well, on the other lappy.
[22:03] <bluesabre> fun stuff
[22:04] <bluesabre> so definitely a performance hit for gl
[22:04] <bluesabre> knome: +1 for the display dialog, it would probably be beneficial for the sound indicator as well
[22:04] <micahg> bluesabre: do I have a new catfish to upload yet?
[22:04] <bluesabre> ochosi: if you get a chance, could you check if the sound indicator works in saucy with the gtk3 panel?
[22:05] <knome> indicators in general, if we pulled the gtk3-indicators-in-gtk2-patch
[22:05] <knome> gtk2-panel-*
[22:05] <bluesabre> micahg: I'll have it available this weekend, been tied up like crazy lately
[22:05] <micahg> bluesabre: same here
[22:05] <knome> bluesabre, TMI
[22:05] <bluesabre> lol
[22:06] <bluesabre> micahg: I also have mugshot available, going to do a 0.2 release this weekend, then I'll need a friendly uploader if we still want it in saucy :)
[22:06] <micahg> bluesabre: I'm guessing we're not having half the fun knome is
[22:06] <bluesabre> it seems that way :D
[22:06] <micahg> bluesabre: what is mugshot?
[22:07] <knome> micahg, read/think sean's comment *literally*
[22:07] <micahg> knome: I know :), I just carried the reference forward
[22:07] <bluesabre> micahg: user profile pic/details app (since lightdm now supports user profile images)
[22:07] <bluesabre> http://www.smdavis.us/2013/07/27/mugshot-quick-and-easy-user-config/
[22:07] <knome> micahg, oki, gotcha ;)
[22:08] <bluesabre> we've had some testing across xubuntu-devel ML
[22:08] <micahg> bluesabre: any reason that can't go in Debian?
[22:08] <bluesabre> no reason, but I'll have to find a debian sponsor (I'll work on that this weekend too)
[22:09] <micahg> I can upload that with gtk-theme-config to mentors
[22:10] <bluesabre> cool
[22:10] <bluesabre> I'll ping you about that when I get 0.2 out then :)
[22:10] <micahg> ok
[22:10] <Noskcaj> If that get's sponsored in time for saucy, i will be shocked. i have 10 packages in mentors that know one has touched
[22:11] <knome> Noskcaj, have you seeked out for mentors or just uploaded them there?
[22:11] <Noskcaj> knome, I've searched for mentors, including th xfce team
[22:12] <Unit193> Only problem I had was someone taking over an expired bug, had to work that out first.  I didn't really use mentors with the one I got through.
[22:16] <GridCube> :) im gonna test xmir i386
[22:16] <GridCube> brb
[22:16] <Unit193> Poor guy.
[22:17] <bluesabre> :D
[22:18]  * skellat is still putting the finishing touches on downgrading his netbook to 12.04
[22:23] <GridXmir> :( typing lag
[22:24] <Unit193> ...Really?  What version was the iso?  `file xubuntuxmir.iso` will tell you.  That was supposed to be fixed.
[22:24] <Unit193> Also, if you use the open source drivers, can you compare the output of glxgears to it?
[22:24] <Unit193> (And pad the info?)
[22:24] <GridXmir> i tried glxgears just before, and now im installing them
[22:25] <GridXmir> it was 60fps with nvidia drivers
[22:25] <Unit193> nVidia drivers have a big advantage, yep.
[22:25] <GridXmir> hahaha it says 863fps
[22:25] <GridXmir> 7578 frames in 5.0 seconds = 1515.160 FPS
[22:25] <GridXmir> +
[22:25] <Unit193> Lies and slander, me thinks.
[22:26] <lderan> :P
[22:27] <Unit193> Mine went from 30 to 19. :D
[22:27] <GridXmir> dual monitors works worst than last time
[22:27] <GridXmir> typing lag is gone now
[22:32] <GridXmir> same as last time i cannot accept the TOC of the msfonts
[22:32] <GridXmir> it wont accept the enter key on OK
[22:33] <GridXmir> well it did
[22:37] <GridXmir> lots of  tearing in html5 video in youtube,
[22:40] <GridXmir> ok what files should i fetch while in xmir?
[22:40] <GridXmir> i really want leave now this session
[22:41] <knome> GridXmir, aren't the instructions on Unit193's website?
[22:41] <GridXmir> yeah it says give report i dont know what to report
[22:41] <Unit193> http://pad.ubuntu.com/xubuntu-mir
[22:42] <OvenWerks> Unit193: what are the possibilities of setting RL3 to xMir and leaving RL2 on X?
[22:43] <OvenWerks> (RL = run level
[22:43] <Unit193> OvenWerks: Lightdm is what's starting it, I don't see how that'd work?
[22:44] <OvenWerks> run lightdm with two different config files?
[22:44] <OvenWerks> can lightdm take the name of config on cl?
[22:45] <Unit193> 1.  Simply remove unity-system-compositor and/or the xorg-xmir package.  2. Comment it out in the lightdm xmir config file.
[22:45] <Unit193> -c, --config=FILE                   Use configuration file
[22:45] <OvenWerks> I was thinking for testing without reboot...
[22:45] <Unit193> Ah, if you install everything, I'd *think* you can just sudo service lightdm restart, no?
[22:46] <OvenWerks> That maight be easier
[22:46] <OvenWerks> Thanks for the tip.
[22:46] <Unit193> Sure.
[22:47] <OvenWerks> It is just that even if xMir is not default, if it is installed and can be tested easily, there is more likely to be useful bug reports
[22:52] <Unit193> OvenWerks: IMHO, it's easier to leave it uninstalled, that way all people have to do is install u-s-c and that'll pull in everything needed, don't have to enable or anything.
[23:21] <OvenWerks> Unit193: Most of the time I want a known stable system, once in a while I am willing to do some testing. I do not want to find out part way through a project how xmir doesn't work..
[23:22] <OvenWerks> in the end it will probably end up two partitions though.
[23:23] <Unit193> OvenWerks: I get that, I wasn't interested in installing saucy, then installing mir, and turns it would have been a very bad idea for me. :P


[07:02] <sunweaver> Hi all!
[07:02] <sunweaver> I wonder how the Ubuntu build daemons handle alternative build dependencies.
[08:41] <cjwatson> sunweaver: Equivalent to sbuild --resolve-alternatives
[08:49] <sunweaver> cjwatson: thanks
[09:20] <caribou> Hello, any member of the SRU team around today ?
[09:20] <caribou> There is a dependency issue b/w  kdump-tools (in -updates) and kexec-tools (-proposed) which makes the installation of the linux-crashdump meta-package to fail
[09:21] <caribou> (xenial)
[10:30] <rbasak> caribou: does the kexec-tools in proposed need updating with a Breaks?
[10:30] <rbasak> Oh, I see more discussion in #ubuntu-release
[10:31] <caribou> rbasak: no, it's been handled by sil2100 in #ubuntu-release
[10:37] <sil2100> The binary-dependencies seem to be in place since otherwise the package would install correctly, it's just that the new dependency is not intentional and has been missed
[10:38] <sil2100> We need to get the kexec-tools package tested and released I guess
[10:38] <sil2100> But maybe there's some better way?
[13:44] <coreycb> hello sru team, please could we get a review of the uploads for heat bug 1761629?
[13:57] <rbasak> coreycb: looks like that's still blocked by the previous heat SRU.
[14:00] <awe_> AlexKaluzhny, I'll be joining the call a few minutes late today
[16:06] <ddstreet> sil2100 rbalint lp #1774120 is your preference to remove the changes to the ebtables.init script, and restrict the fix/workaround to only the ebtables.prerm script, and in that to 1) ignore the invoke-rc.d for ebtables.init, and also 2) ignore 'upgrade-failed' for ebtables versions less than the current version for each release (i.e. hardcode version check in prerm)?
[16:08] <ddstreet> if so, do you know if there is a way to override the #ERROR_HANDLER# that debhelper injects, or should i just remove the #DEBHELPER# and insert the equivalent check (but ignoring errors)


[11:59] <Scary_Guy> use /fset and search for freenode.  I recommend the SASL auto login for security.
[12:07] <cmaloney> morning
[12:50] <mechpilotace> good mornin
[14:26] <_stink_> yo
[14:27] <mechpilotace> whats good
[14:33] <cmaloney> I'm awake
[14:33] <cmaloney> jury is still out on that one
[14:43] <mechpilotace> lmao, i hear that