[08:56] <darkxst> ricotz, hey, gnome-terminal keep eating your cursor?
[08:56] <darkxst> ^mouse cursor?
[11:25] <ricotz> darkxst, hmm, not sure i know what you mean
[11:26] <ricotz> i guess it didn't happen here then
[11:28] <darkxst> ricotz, mouse cursor disappears when you hover over a terminal window (although comes back when you switch tabs in gnome-terminal)
[12:02] <ricotz> darkxst, didnt happen here yet
[12:09] <darkxst> been happening here on/off ever since I uploaded it
[12:09] <darkxst> although maybe I need to reboot more
[12:10] <ricotz> darkxst, yeah, could be caused by a recent update, so an inconistently running system
[12:10] <ricotz> bbl
[12:11] <darkxst> ricotz, I have simulations running 24/7 so its kind a hard to reboot ;(
[15:39] <Perkele-Linux> oi! I've got a question, if i download Ubuntu GNOME 14.04 (Trusty Tahr) Daily Build and try that one out, will I then get the final release automatically thru the apt-get dist-upgrade 17 april ?
[15:43] <mgedmin> yes
[15:44] <Perkele-Linux> mgedmin: *hug*
[22:46] <darkxst> Noskcaj, https://plus.google.com/u/0/photos/111024543668500323770/albums/6001167781549094321/6001167786114950306?cfem=1&pid=6001167786114950306&oid=111024543668500323770
[22:47] <darkxst> Noskcaj, can you fix that today?
[22:47] <darkxst> just drop the ubuntu branding patch, so we get the upstream logo + version
[23:41] <ahoneybun> hey darkxst


 and Qt6 FTBFS
 https://launchpad.net/ubuntu/+source/qt6-base/6.2.2+dfsg-5
 Yikes
 Looks like a GCC issue
 LTO?
 I guess so, but there's only one way to know for sure


[00:22] <cyphermox> tsimonq2: debian-cd is what puts preseeds on the iso
[00:23] <cyphermox> for debugging essentially I use DEBCONF_DEBUG=5 or something akin to that; see https://mraw.org/blog/2012/12/23/d-i_hacking_recipe_3/
[00:23] <cyphermox> then looking at the logs it tells you what question is being aksed and then what response it gets from preseed
[00:25] <cyphermox> for a fully automated install usually you also want "auto priority=critical"  to avoid the first language questions and move right on to following the preseed
[03:08] <tsimonq2> cyphermox: Thanks!


[14:03] <davecheney> m_3: https://launchpad.net/~gophers/+archive/go
[16:14] <davecheney> $GOROOT/src/cmd/go
[16:20] <mattyw> which is the best channel to use for general help using juju-core? this one or #juju? Specifically, I can't seem to get access to any debug-log (the command doesn't exist in juju-core) and my charm which deploys under pyjuju fails to install under juju-core. There's no /var/lib/juju/unit directory on the machine it deployed to for me to be able to find debug logs there
[16:49] <mgz> mattyw: probably in here, though you might have more luck asking on the mailing list over irc this week
[16:52] <mattyw> mgz, the juju dev list?
[16:55] <mgz> mattyw: or the juju list is fine too
[16:58] <mgz> m_3: ^is there anywhere we can point people wanting to debug their py-developed charms on go- currently?
[17:00] <fss> niemeyer: ping
[17:01] <niemeyer> fss: Hi
[17:03] <fss> niemeyer: have you seem my email? (devincachu)
[17:03] <niemeyer> fss: I did, sorry for not getting back yet.. a *lot* happening in the last couple of days
[17:04] <niemeyer> fss: I'll ponder properly on the dates and how could try to help, and will let you know
[17:04] <fss> niemeyer: sure, thank you!
[17:04] <niemeyer> fss: Thanks for inviting!
[17:19] <fss> niemeyer: I hope you'll be able to make it :)
[18:05] <mgz> big swift upload maybe issue, bug 1110607
[18:05] <_mup_> Bug #1110607: Deploying a large charm times out with 'openstack' provider <juju:New> < https://launchpad.net/bugs/1110607 >
[21:46] <m_3> mgz: dunno
[21:46] <m_3> mgz: (re: where peeps should go to debug pycharms in goju)
[21:49] <mgz> m_3: from the mailing list post, seemed mostly getting-started issues with getting any charm running at all with gojuju
[21:52] <m_3> mgz: ack... I'll see if I can get jorge on an askubuntu question
[21:59] <jcastro> mgz: do you have a link to the post?


[01:09] <oripi> hi
[01:09] <bdmurray> oripi: hello
[01:10] <oripi> I want to join the BugSquad in a near future, but I have some questions
[01:10] <bdmurray> okay, I might be able to help with those
[01:10] <oripi> ok, thanks
[01:11] <oripi> I'm french, and my english isn't perfect... is it a big problem ?
[01:11] <oripi> I could have some problems to explain some things
[01:12] <bdmurray> No, I don't think so.  We have lots of members whose native language is not english.
[01:12] <oripi> ok
[01:12] <bdmurray> We ocasionally get some bug reports in French too.
[01:13] <oripi> an other question : When is the next Hugday ?
[01:13] <oripi> on the wiki it says the 8 of april...
[01:13] <bdmurray> I'll fix that it's actually Friday I think
[01:14] <oripi> ok, cool !
[01:14] <oripi> Somebody should fix the date on this page : https://wiki.ubuntu.com/UbuntuBugDay
[01:15] <bdmurray> right, I'm on it
[01:15] <oripi> thanks
[01:16] <bdmurray> okay, fixed thanks for brining that up
[01:17] <oripi> and a last question : I don't have lots of time for doing BugHunting but I want to help, is it possible to do this only 8 to 10 hours per week ?
[01:19] <bdmurray> That'd be great!  We don't have a minimum contribution amount and every bit of help is valuable and welcome.
[01:20] <oripi> ok, thanks a lot for answering my questions.
[01:20] <bdmurray> No problem will we see you on the 25th?
[01:22] <oripi> maybe... I have things to do in the evening, but I'm in holydays during the day, so I think I try to do some things in the morning and afternoon
[01:23] <bdmurray> great! well stop on by anytime
[03:25] <arcticpenguin380> wats Triaged mean?
[03:26] <wolfger> arcticpenguin380: A member of [UbuntuBugControl] believes that the report describes a genuine bug in enough detail that a developer could start working on a fix
[03:26] <arcticpenguin380> thanks
[03:26] <wolfger> that's the official "triaged" definition
[03:27] <arcticpenguin380> ok cya
[03:27] <wolfger> cya
[06:28] <Iulian> G'morning.
[07:53] <raj1> hi
[07:53] <raj1> i cant get fspot working on hardy 64
[07:54] <raj1> who can help
[07:55] <RAOF> raj1: Someone in #ubuntu+1, probably :)
[07:55] <raj1> +1 what is that?
[07:55] <RAOF> Hardy, for another day :)
[07:56] <raj1> i posted in #ubuntu channel but most people seem to be just chatting
[07:56] <raj1> i did file bug report
[07:56] <RAOF> Yeah, #ubuntu is full of noise, not too much signal.  #ubuntu+1 is better, especially since you're using hardy.
[07:56] <raj1> u r a dev arent u ? i have seen u on the forums
[07:56] <raj1> but thanks
[07:57] <raj1> ill go there maybe
[07:57] <raj1> #ubuntu+1 is channel name ?
[07:57] <RAOF> Yes.
[07:57] <RAOF> We like the organisation to remain; this isn't a channel for getting support :)
[07:57] <raj1> ya ok thanks
[07:57] <raj1> this is bug squad isnt it
[07:58] <raj1> maybe in future ill join u :)
[13:05] <pedro_> morning folks
[13:05] <Kirrus> morning pedro_
[13:13] <ogra> silence before the storm in here :)
[13:22] <Kirrus> ogra, announce has been quieter than normal as well
[13:23] <james_w> ubotu was taken offline due to harrasment in #ubuntu-release-party, so may have had something to do with it.
[13:55] <afflux> morning and happy release day :P
[13:56] <james_w> hi afflux, happy release day
[13:57] <pedro_> hey afflux! to you too :-)
[14:12] <secretlondon> james_w the bot was harassed, or other people?
[14:13] <james_w> secretlondon: the bot
[14:13] <secretlondon> thanks
[14:13] <james_w> how are you?
[14:24] <secretlondon> I'm okay
[14:48] <ogra> quiet here
[14:48] <ogra> usually hel breaks loose 1h after release is out
[14:48] <ogra> *hell
[14:50] <pochu> ogra: ubotu doesn't announce new bug reports in this channel anymore ;)
[14:50] <persia> Maybe there aren't so many bugs this time?
[14:51] <persia> pochu: There's still usually plenty of active users whining :)
[14:51] <pochu> :)
[14:51] <mishok13> i found only one bug in hardy -- gnome-desktop-manager is broken
[14:52]  * ogra is scared ... no bugs in hardy  ... we're all jobless !!!
[14:52] <ogra> AAAAHHHH
[14:52]  * ogra runs away screaming
[14:52] <pochu> mishok13: what's gnome-desktop-manager?
[14:53] <james_w> mishok13: there's no package or command of that name.
[14:53] <mishok13> *environment
[14:53] <james_w> ogra: bug #1 still isn't fixed.
[14:53] <mishok13> typo
[14:53] <ubotu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1
[14:53] <ogra> james_w, phew, relief
[14:53]  * ogra stops running
[14:53] <ogra> :)
[14:54] <pochu> mishok13: ah, right
[14:54] <pochu> that's a metapackage though
[14:54] <pochu> but it's uninstallable right now :(
[14:54] <mishok13> yeah, i know
[14:54] <mishok13> i don't care, i use fluxbox anyway
[14:54] <pochu> heh
[14:55] <pochu> that's bug 190950
[14:55] <ubotu> Launchpad bug 190950 in meta-gnome2 "[hardy] gnome-desktop-environment is broken" [Low,Incomplete] https://launchpad.net/bugs/190950
[14:56] <mishok13> yep
[15:01] <mishok13> oh, and another bug I have is 12637, though I didn't have it on gutsy
[15:22] <ivob> Hello! Downloaded 64 bit ubuntu-8.04-server-amd64.iso. Attempted install failed at manual partitioning. Apparently it kind find any free RAID devices when attempting creation of RAID1.
[15:22] <ivob> Do I report this?
[15:22] <ivob> it can't*
[15:35] <blankboy> Failed to fetch
[15:35] <blankboy> http://archive.ubuntu.com/ubuntu/dists/hardy-backports/Release Unable
[15:35] <blankboy> to find expected entry main/debian-installer/binary-i386/Packages in
[15:35] <blankboy> Meta-index file (malformed Release file?)
[15:35] <blankboy> How do i fix that. its stoping me from upgrading.
[15:37] <secretlondon> there are no backports yet
[15:37] <secretlondon> you could comment it out in /apt/sources.list
[15:38] <secretlondon> /etc/apt/sources.list
[15:41] <blankboy> its
[15:41] <blankboy> but it still trys to find it.
[15:42] <blankboy> i had this last time 6 months ago
[15:45] <blankboy> Is the away to ignore errors?
[15:47] <ogra> blankboy, the upgarder should do that automatically
[15:47] <blankboy> Does not...
[15:47] <ogra> you are properly following the upgrade notes ?
[15:48] <blankboy> sudo do-release-upgrade -d yes?
[15:48] <blankboy> Update Manager does the samething
[15:49] <ogra> you pulled the latest update-manager(-core) from gutsy-updates before starting ?
[15:51] <ogra> and -d should be deprecated with the release
[15:53] <secretlondon> after you've changed sources.list you need to run apt-get update
[15:53] <blankboy> 1:0.81.2 update-manager-core yes?
[15:54] <secretlondon> 1:0.87.24
[15:54] <blankboy> hmm
[16:05] <bdmurray> thekorn: hello!
[16:05] <thekorn> hi bdmurray
[16:06] <blankboy> secretlondon: Thanks the server failed to download the lateist updates for gusty
[16:07] <secretlondon> blankboy, so sorted now?
[16:08] <blankboy> I will find that out ones i have installed the 13 updates
[16:08] <secretlondon> ok
[16:08] <blankboy> one the bugs fixed in the updates i am now installing is https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/195419
[16:08] <ubotu> Launchpad bug 195419 in update-manager "feisty->gutsy upgrade does not work with APT::Get::AllowUnauthenticated set" [Undecided,Fix committed]
[16:08] <blankboy> which looks like my bug
[17:41] <smithers> anyone notice the smb issues with Hardy?
[17:42] <smithers> smbmount products retrying with upper case share name
[17:42] <smithers> mount error 6 = No such device or address
[17:42] <iddo> anyone knows if this bug was fixed in hardy final? "maximized window titlebar displayed not right with compiz enabled" https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/99508
[17:42] <smithers> and connect to server on nautilus fails as well
[17:42] <ubotu> Launchpad bug 99508 in compiz "Window titlebar displayed not right with compiz enabled" [Medium,Confirmed]
[18:48] <jarlath> I have a quick question. I've been dealing with a bug. I assigned myself to it and set the status to incomplete while I was getting info from the reporter. Now that all the information seems to be complete, I was going to put the status back to New (since it's not Incomplete now) and unassign myself since I can't take it any further. Is this the right way to deal with things?
[18:59] <greg-g> jarlath: there is a new way to do it now.  First, when you are a bug triager you don't assign yourself to the bug anymore, that is for the person actually working on fixing the bug (writing the patch).  However, when you ask for more information you set the status to "incomplete" and subscribe yourself to the bug.
[18:59] <jarlath> greg-g: okay, thanks. And when the bug is complete?
[19:00] <greg-g> jarlath: when you feel that all relevant information has been provided so that a developer can start working on a patch you set it to "Triaged"
[19:00] <greg-g> more info here: https://wiki.ubuntu.com/Bugs/Status
[19:01] <jarlath> Thanks greg-g. I thought so, but Triaged doesn't appear in the list of statuses. I'll read the link.
[19:02] <greg-g> jarlath: only members of the Bug Control team can set it to triaged
[19:02] <greg-g> jarlath: so you can come in here and ask one of us to do it for you
[19:03] <jarlath> greg-g: Great. I'll do that.
[19:03] <greg-g> jarlath: thanks for the help with bugs!
[19:03] <jarlath> greg-g: my pleasure.
[19:04] <jarlath> I think this can be considered Triaged
[19:04] <jarlath> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/220163
[19:04] <ubotu> Launchpad bug 220163 in linux "Long delay when booting Hardy RC Live CD ..." [Undecided,New]
[19:04] <jarlath> and this:
[19:04] <jarlath> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/219350
[19:04] <ubotu> Launchpad bug 219350 in xorg "[Hardy]Wrong refresh rates shown/selected, nvidia driver" [Undecided,New]
[19:05] <greg-g> jarlath: I'll look in about 8 minutes
[19:05] <jarlath> greg-g: Thanks.
[19:23] <joanhey> Upgrading with update-manager to hardy, give me a error. Anyone could help me?
[19:25] <pjoul> joanhey: what error?
[19:25] <afflux> joanhey: tell us your error and/or put the logs on a pastebin / or launchpad
[19:27] <joanhey> I will translate it to English, so perhaps is not exactly the same message in english
[19:27] <joanhey> Can't calculate upgrade
[19:28] <joanhey> when they go to calculating changes
[19:28] <afflux> that sounds like the same message as in english
[19:28] <afflux> I think we need /var/log/update-manager/apt.log
[19:28] <joanhey> where could i paste you the logs?
[19:29] <afflux> pastebin.com or something like that
[19:29] <joanhey> ok
[19:29] <afflux> err wait
[19:30] <afflux> my path was not correct, the right one is: /var/log/dist-upgrade/apt.log
[19:30] <joanhey> yeah I know
[19:36] <joanhey> The file is to big for pastebin.com, so go http://www.mediaimagins.com/apt.log
[19:42] <afflux> joanhey: okay, looking
[19:44] <afflux> joanhey: I must admit that I'm not an expert for dist-upgrades :)
[19:44] <afflux> anyone else for "can't calculate upgrade"?
[19:45] <pjoul> afflux: try apt-get install libeel2-2
[19:45] <pjoul> or upgrade it manually via synpatic or aptitude
[19:47] <joanhey> It's installed and before ask I reinstall it again, because is installed with the actual version
[19:47] <afflux> joanhey: try what pjoul said
[19:47] <afflux> okay
[19:52] <joanhey> Is like I have broken dependencies, when I want to upgrade. But there aren't broken dependencies. I also made dpkg --configure -a
[19:56] <pjoul> joanhey: you should investigate broken deps with aptitude
[19:56] <pjoul> package libeel2-2
[20:03] <joanhey> in the main.log at the end say: Dist-upgrade failed: 'E: Can't correct the problems, you have maintained packages that are broken
[20:04] <joanhey> How I resolve this problem
[20:05] <albert23> joanhey: Do you have universe enabled?
[20:07] <joanhey> yes
[20:07] <joanhey> libbel2-2 seems to be OK
[20:08] <albert23> joanhey: The problem seems to be libeel2-2 has Breaks: gnome-translate (<= 0.99-0ubuntu1)
[20:09] <albert23> joanhey: which version of gnome-translate do you have installed?
[20:09] <joanhey> 0.99-ubuntu1
[20:11] <albert23> joanhey: so that's a version which applies to the breaks in libeel2-2
[20:11] <albert23> joanhey: You could try to remove gnome-translate and then try to upgrade again
[20:11] <joanhey> ok, I will try
[20:12] <albert23> joanhey: The strange thing is, hardy has a higher version of gnome-translate, which should be able to solve the breaks problem
[20:13] <joanhey> First I will try to remove the mail-notification that depends of libbel2-2, and try. Later I will try with gnome-translate
[20:15] <albert23> joanhey: I don't think that will help. Nautilus also depends on the new libeel2-2
[20:15] <joanhey> ok
[21:19] <joanhey> no way deinstalled gnome-translate and mail-notify and the same error upgrading to hardy
[21:20] <bdmurray> Can you post your sources.list somewhere?
[21:21] <james_w> hi bdmurray
[21:22] <bdmurray> james_w: howdy
[21:27] <greg-g> is 5-a-day add having issues for anyone else?
[22:11] <thekorn> greg-g, 5-a-day add works for me, It's just very slooow
[22:33] <lucent> Is there a running tab on bugs reported for the upgrade to 8.04 LTS from say, 7.10?
[22:34] <lucent> I'm upgrading a Dell laptop I bought with Ubuntu 6.04 LTS pre-installed
[22:34] <lucent> which I had upgraded to 7.10
[22:35] <lucent> possible snafus would be helpful to know before the system reboots ;)
[22:38] <ffm_> Whenever I go to Apps>Sys>NewLogin and then choose "quit" from the gdm menu, I am returned to a blank (white) screen, only seeing my mouse pointer. Would that be an xorg bug?
[22:47] <bdmurray> lucent: it really depends on software you have installed but it should be fine


[00:02] <MTecknology> I'm calling a meeting
[00:02] <MTecknology> Everyone, say hi
[00:02]  * MTecknology says hi
[00:02] <MTecknology> meeting concluded
[00:03] <MTecknology> sorry, it's just been so idle in here
[10:05]  * persia looks about, wondering if it's this week or next week, as the wiki page hasn't been updated.
[10:17] <persia> RIght.  Next week then.
[10:20] <MaWaLe> sorry for asking : next week at what time?
[10:21] <leoquant> @schedule
[10:21] <leoquant> ?
[10:21] <leoquant> @ schedule
[10:21] <MaWaLe> leoquant: not updated !!!
[10:21] <leoquant> :P
[10:24] <persia> MaWaLe, I'm guessing 10:00, but I'm not sure.
[10:25] <MaWaLe> thx persia & leoquant
[11:15] <elky> persia, oh crap. sorry :(
[11:35] <persia> elky, It's the nature of things, and two of us wouldn't have been enough anyway.
[11:36] <elky> persia, lifeless was kind of around, but even that would have done us no good without yet another
[11:37] <persia> Right.  I suspect that there were four of us around, but without our feerless leader to organise us, we're less than coordinated.
[14:59] <kirkland> o/^
[14:59]  * mathiaz waves
[14:59] <sommer> yo
[14:59] <ScottK> o/
[15:00] <cjwatson> Hmm. Did the server meeting move?
[15:00] <mathiaz> allright - let's get started.
[15:00] <soren> o/
[15:00] <persia> Isn't it 15:00 UTC?  Isn't this the TB meeting?
[15:00] <cjwatson> I was expecting a Technical Board meeting here now
[15:00] <mathiaz> cjwatson: hm
[15:00] <cjwatson> there has been some timezone confusion due to the US moving to DST earlier than Europe
[15:01] <persia> Yes, some parts of the world chose to adjust their clocks, but that's just those parts of the world.
[15:01] <cjwatson> the Fridge calendar says 3pm TB 4pm server team, which I assume is either UTC or my local timezone (currently identical)
[15:01] <mathiaz> last week I checked and the TB meeting had been moved to 14:00 UTC on the calendar
[15:01] <mdz> is there a conflict?
[15:01] <persia> Fridge calendar should be UTC.
[15:01] <cjwatson> that was an error due to Google Calendar having no idea whatsoever about DST
[15:01] <cjwatson> it was fixed earlier today
[15:01] <mdz> persia: what time is your meeting usually?
[15:02] <persia> mdz, Not my meeting.  I'm here for the TB meeting.
[15:02] <ScottK> mathiaz: How about if we move to #uubntu-server
[15:02] <mathiaz> yes - let's move to #ubuntu-server
[15:02] <kirkland> ScottK: +1
[15:02] <mdz> persia: sorry, I see
[15:02] <mdz> #startmeeting
[15:02] <MootBot> Meeting started at 10:02. The chair is mdz.
[15:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:03] <mdz> Keybuk: here?
[15:03] <Keybuk> present
[15:03] <mdz> sabdfl will not be attending
[15:03] <mdz> [TOPIC] SRU guidelines for Landscape (robbiew)
[15:03] <MootBot> New Topic:  SRU guidelines for Landscape (robbiew)
[15:04] <mdz> cjwatson: thanks for drafting a resolution for us
[15:04] <cjwatson> I believe it is just awaiting your feedback now
[15:04] <cjwatson> have you had a chance to read it?
[15:04] <mdz> I have only just scanned it prior to the meeting, I'm afraid, having been traveling all last week
[15:05] <mdz> I think it is fine
[15:05] <mdz> the rationale strikes a good balance, sufficiently explicit without being cumbersome
[15:05] <mdz> we will want to iterate on it further if and when we need to apply this to other cases
[15:06] <cjwatson> be it resolved, then? if so, I'll take an action to send out mail about it and update the SRU documentation
[15:06] <mdz> but I am prepared to support it as is for the current case
[15:06] <mdz> [VOTE] cjwatson's proposed resolution regarding Landscape<EMAIL_ADDRESS>[15:06] <MootBot> Please vote on:  cjwatson's proposed resolution regarding Landscape<EMAIL_ADDRESS>[15:06] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[15:06] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[15:06] <mdz> +1
[15:06] <MootBot> +1 received from mdz. 1 for, 0 against. 0 have abstained. Count is now 1
[15:06] <cjwatson> +1
[15:06] <MootBot> +1 received from cjwatson. 2 for, 0 against. 0 have abstained. Count is now 2
[15:06] <Keybuk> +1
[15:06] <MootBot> +1 received from Keybuk. 3 for, 0 against. 0 have abstained. Count is now 3
[15:06] <cjwatson> sabdfl said +1 in private mail
[15:06] <mdz> [ENDVOTE]
[15:06] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[15:07] <mdz> [ACTION] cjwatson to document and announce Landscape resolution
[15:07] <MootBot> ACTION received:  cjwatson to document and announce Landscape resolution
[15:07] <mdz> [TOPIC] Upload permission for Romain Francoise for emacs-snapshot
[15:07] <MootBot> New Topic:  Upload permission for Romain Francoise for emacs-snapshot
[15:08] <mdz> I'm not aware of any change here; jono is on holiday today and I don't have an update from him
[15:08] <mdz> though I understand that the TB voted to do something similar for mdke recently
[15:08] <mdz> so maybe it is worth revisiting?
[15:09] <mdz> cjwatson,Keybuk: any thoughts?
[15:10] <Keybuk> mdz: I still don't think he's shown anything necessary to meet the requirements
[15:10] <dholbach> mdz: I could ask him to follow https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage now that we have a process for it?
[15:10] <cjwatson> Is there a recent refresher of status from the candidate?
[15:10] <cjwatson> (as in, last few months)
[15:10] <Keybuk> in particular, the developer concerned does not seem to be actively pursuing the application
[15:10] <Keybuk> which was turned in by somebody else and not by then
[15:10] <cjwatson> I know this has been on our table for some time
[15:10] <mdz> dholbach: can you confirm whether or not they are actually still interested?
[15:10] <mdz> IIRC the request was made by someone else on their behalf
[15:11] <persia> dholbach, I'll take that one, given your status for the next two days.
[15:11] <dholbach> persia: that's probably a good idea
[15:11] <Keybuk> if I were to review the criteria
[15:11] <Keybuk> based on the current application
[15:11] <dholbach> mdz: I informed Romain when were discussing the process and he thanked us for looking into it - I'd take that as a "yes"
[15:11] <Keybuk> it would a very solid -1
[15:12] <dholbach> in any case I feel that the process with the list of requirements clearly depicts the way ahead
[15:12] <mdz> Keybuk: how so?
[15:12] <Keybuk> # have sufficient technical knowledge of the package(s) in question from documented work in the package through sponsorship, work in other distributions, or work upstream.
[15:13] <Keybuk> he has had one, single, upload sponsored
[15:13] <Keybuk> in other distributions, ie. Debian, he is not a maintainer of emacs or emacs-snapshot
[15:13] <Keybuk> and I couldn't see any work from him upstream
[15:13] <Keybuk> # have an understanding that such an access grant does not permit sole-maintainership, but rather the right to participate in the maintenance of the package as part of a team.
[15:13] <Keybuk> since he has not been involved in his own application, I am unconvinced from him of any understanding of what it implies
[15:13] <Keybuk> # have an understanding of the broad strokes of the release schedule, relevant freezes that would affect the package in question, and appropriate means by which to handle any exceptions.
[15:13] <Keybuk> since he has no other activity in Ubuntu, I do not believe he has demonstrated this
[15:13] <Keybuk> # need to show advocation and support of existing developers indicating that previous work on the package demonstrated that unsupervised upload is warranted.
[15:14] <cjwatson> 15:13 <Keybuk> he has had one, single, upload sponsored
[15:14] <Keybuk> the only sponsored upload he did was uploaded by siretart, who hasn't spoken about him fwict
[15:14] <cjwatson> I think I would have to dispute the facts there
[15:14] <Keybuk> # need to have documented previous concern for the packages in question in Ubuntu, including previous uploads, effective bug management, and similar previous work.
[15:14] <Keybuk> none that I can see
[15:14] <Keybuk> # need to show a history of effective collaboration with other developers in Ubuntu.
[15:14] <Keybuk> none that I can see
[15:14] <cjwatson> 'aptitude changelog emacs-snapshot' shows a long series of uploads from him
[15:14] <Keybuk> cjwatson: those are syncs from debian, no?
[15:15] <cjwatson> emacs-snapshot is not in Debian
[15:15] <cjwatson> so they may be syncs from somewhere, but it isn't Debian
[15:15] <Keybuk> the only upload I can see where he was sponsored by the usual procedure was 13 Oct 2008 of 1:20081013-1 into intrepid
[15:15] <cjwatson> at least I think it is enough to demonstrate technical knowledge of the package in question
[15:15] <mdz> Keybuk: he has maintained emacs-related packages in Debian, and is a Debian maintainer in good standing afaik
[15:16] <mdz><EMAIL_ADDRESS>[15:16] <MootBot> LINK received<EMAIL_ADDRESS>[15:16] <Keybuk> http://qa.debian.org/developer.php?login=rfrancoise&comaint=yes
[15:16] <MootBot> LINK received:  http://qa.debian.org/developer.php?login=rfrancoise&comaint=yes
[15:16] <cjwatson> Keybuk: I'm not necessarily disputing your other points, but your general point of "doesn't seem to work on the package" doesn't stand up to detailed examination
[15:17] <Keybuk> cjwatson: I didn't say he hasn't worked on the package
[15:17] <Keybuk> I've said he hasn't met our criteria
[15:17] <mdz> he is listed as a maintainer of GNU emacs upstream
[15:17] <cjwatson> he has 155 uploads of this package listed in the changelog
[15:17] <Keybuk> cjwatson: none of which have been made to Ubuntu
[15:17] <Keybuk> unless Soyuz is lying to me
[15:17] <cjwatson> I think the intent of:
[15:17] <cjwatson> 15:12 <Keybuk> # have sufficient technical knowledge of the package(s) in question from documented work in the package through sponsorship, work in other distributions, or work upstream.
[15:17] <persia> The log of bug #252328 may be interesting in this context
[15:18] <cjwatson> is to indicate work done on the package *somewhere*, wherever it may be
[15:18] <cjwatson> Keybuk: Soyuz lies about changelogs. It's a known bug
[15:18] <cjwatson> and a fairly high-priority one
[15:18] <Keybuk> cjwatson: I'm reading the publishing history
[15:19] <Keybuk> https://edge.launchpad.net/ubuntu/+source/emacs-snapshot/+publishinghistory
[15:19] <Keybuk> there have been no uploads in jaunty
[15:19] <cjwatson> Soyuz is just not a reliable means to determine this sort of information
[15:19] <cjwatson> unfortunately
[15:19] <Keybuk> I disagree
[15:19] <Keybuk> Soyuz knows perfectly well what is published where
[15:19] <Keybuk> and when
[15:19] <cjwatson> I agree that there have been no uploads in Jaunty
[15:19] <Keybuk> this is not an area that it is deficient in
[15:19] <cjwatson> but Soyuz is very little use at telling you who was responsible for particular uploads
[15:20] <Keybuk> cjwatson: the changelogs and uploads are signed by siretart
[15:20] <Keybuk> except for the top-most one
[15:20] <cjwatson> it appears to me that Romain is maintaining the package in the ubuntu-elisp PPA
[15:20] <cjwatson> and occasionally asking for sponsorship of snapshots from siretart
[15:21] <Keybuk> then I would like to see siretart speaking on his behalf
[15:21] <mdz> he did
[15:21] <cjwatson> I concur
[15:21] <Keybuk> and, most pointledly, I'd like to see some kind of interest from Romain himself in his own application
[15:21] <mdz> dholbach just addressed that
[15:21] <persia> So shall I tell Romain that he should follow the new process, and restart the application?
[15:22] <mdz> persia: I think that would be a good way to get things moving again.  he could review the criteria and provide us with information about how he meets hem
[15:22] <mdz> s/hem$/them/
[15:22] <mdz> rather than us dredging launchpad etc.
[15:23] <mdz> [ACTION] persia to request a new application based on the now-established PerPackage criteria
[15:23] <MootBot> ACTION received:  persia to request a new application based on the now-established PerPackage criteria
[15:23] <persia> That seems reasonable.  I'll do that, and bring it back to the TB once he has addressed the specific criteria.
[15:23] <mdz> [TOPIC] codecs in ffmpeg (Reinhard Tartler)
[15:23] <MootBot> New Topic:  codecs in ffmpeg (Reinhard Tartler)
[15:23] <mdz> this is with jono at the moment
[15:24] <mdz> he's getting advice to help formulate a policy
[15:24] <mdz> I haven't caught up with him on it in the past 2 weeks due to travel and his holiday
[15:24] <mdz> so, nothing to report
[15:24] <mdz> [TOPIC] Governance changes in the context of Archive Reorganisation
[15:24] <MootBot> New Topic:  Governance changes in the context of Archive Reorganisation
[15:24] <mdz> cjwatson?
[15:25] <cjwatson> I updated http://wiki.ubuntu.com/ArchiveReorganisation to account for the changes we discussed in Berlin (i.e. splitting the work into two parts and considering permissions first, so that we can move ahead with that while we figure out how to solve problems with the component changes)
[15:25] <mdz> I believe this was said to be blocked on finalizing the design
[15:25] <cjwatson> ArchiveReorganisation/Permissions now contains the work I expect to be possible in the near term
[15:25] <cjwatson> I have a call with dholbach and jono on Thursday to discuss it
[15:26] <cjwatson> it does involve some Launchpad changes still, but I've discussed those with Muharem and Julian and they're in progress
[15:26] <mdz> cjwatson: is that a discussion call, or a decision-making call?
[15:26] <mdz> i.e. what do we need to do in order to move forward?
[15:28] <cjwatson> the next thing we need to do is determine what we're doing with social structures that rely on the split between core and MOTU
[15:28] <mdz> and that's the purpose of the Thursday discussion?
[15:29] <cjwatson> yes, and to thrash out expected timeline and the bits that still need planning from the community team
[15:29] <mdz> ok
[15:29] <mdz> anything else on this topic?
[15:29] <cjwatson> not for the present
[15:29] <mdz> [ACTION] cjwatson to discuss latest ArchiveReorganisation plan with jono and dholbach and agree a plan for governance changes
[15:29] <MootBot> ACTION received:  cjwatson to discuss latest ArchiveReorganisation plan with jono and dholbach and agree a plan for governance changes
[15:30] <mdz> [TOPIC] AOB
[15:30] <MootBot> New Topic:  AOB
[15:30] <Keybuk> meeting time wrt to DST
[15:30] <persia> I'd like to raise the question of meeting times and DST, given the start of the meting.
[15:30] <mdz> right
[15:30] <Keybuk> usually the meeting time is in GMT, shall we stick to this?
[15:30] <mdz> my expectation is that the meeting time remains the same until/unless we change it through explicit discussion
[15:30]  * siretart turns up
[15:31] <persia> "the same" meaning GMT or UTC?
[15:31] <mdz> this was apparently foiled by Google Calendar
[15:31] <mdz> persia: "the same" UTC time
[15:31] <cjwatson> mdz: remains the same in UTC, or in your/our timezone?
[15:31] <cjwatson> ok
[15:31] <cjwatson> UTC is the one true global meeting timezone
[15:31] <mdz> the fridge calendar is set to no-DST
[15:32] <mdz> and so is the calendar where the event is
[15:32] <mdz> so I don't know why it changed
[15:32] <mdz> Google Calendar popped up and asked me if I wanted to change my time zone to GMT (which of course it already was)
[15:33] <mdz> I am open to moving the meeting once BST starts, or not, it doesn't matter too much to me
[15:33] <mdz> any issues with that?
[15:33] <Keybuk> other meetings nearby seem to be in a mix of US time, GMT and UTC
[15:33] <Keybuk> it surprised me that the server team meeting moved an hour earlier
[15:34] <cjwatson> they were previously immediately after us, IIRC
[15:34] <cjwatson> so I imagine that they suffered the same problem
[15:34] <cjwatson> but perhaps have more US residents
[15:34] <mdz> the server team meeting is now at different times on dendrobates' calendar and the fridge
[15:34] <mdz> because they were separate events rather than invites
[15:34] <Keybuk> note that Google Calendar has severely confused itself
[15:34] <Keybuk> mdz moved this week's meeting back to 1500UTC
[15:35] <Keybuk> in two weeks time it's at 1400UTC
[15:35] <Keybuk> but in four weeks time, it's at 1500 BST because that's when the time warp ends and Google goes back to its usual service
[15:35] <mdz> Keybuk: or is it? once BST starts it might move
[15:35] <Keybuk> mdz: I'm looking at the raw iCal feed
[15:35] <Keybuk> which gives UTC times
[15:35] <persia> Note that it's still a different time for some of us, who may either not have DST, or have it on the other direction.
[15:36] <mdz> Keybuk: what do we need to do in order to make it sane?
[15:36] <Keybuk> and this is consistent with Google Calendar's past behaviour
[15:36] <Keybuk> mdz: use something that's not Google Calendar
[15:36] <Keybuk> sadly
[15:36] <Keybuk> it appears to simply be a bug in their software
[15:36] <mdz> I mean in the short term
[15:36] <mdz> how do we fix the calendar to implement what we just agreed?
[15:36] <Keybuk> you can't store UTC meetings in google calendar fwict
[15:36] <mdz> sounds like we may need to move one meeting
[15:36] <mathiaz> we've moved the server team meeting back one hour because I based my judgement on google calendar
[15:36] <Keybuk> if you drag the meeting back an hour for four weeks, it'll fix it for the next 6 months
[15:37] <mdz> ok, let's do that then
[15:37] <mdz> any other business?
[15:37] <Keybuk> so to confirm, next TB meeting will be at 1400 UTC, and 1400 UTC thereafter?
[15:37] <Keybuk> ie. we're actually rescheduling it <g>
[15:37] <Keybuk> (it's currently 1500 UTC)
[15:38] <mdz> done
[15:38] <mdz> no, I've put it at 1500 UTC
[15:38] <Keybuk> for the next meeting?
[15:38] <Keybuk> and the one after that at 1400 UTC?
[15:38] <mdz> wait, BST starts when?
[15:38] <Keybuk> 0200 29/03
[15:39] <Keybuk> so between the TB meeting in two weeks time and the TB meeting in four weeks time
[15:39] <mdz> so I've moved it on 24 March to 1500
[15:39] <mdz> on 7 April, it currently shows 1500 as well
[15:40] <mdz> but who knows what that will actually be once google is finished with it
[15:40] <mdz> Keybuk: do you think we need to move it or not?
[15:40] <cjwatson> you just have to monitor week-by-week
[15:40] <cjwatson> in the real world it's the only sane way to keep meetings at the intended times across DST changes
[15:40] <Keybuk> mdz: if we leave it as it is, the meeting in four weeks time will be at 1500 London time
[15:40] <Keybuk> (BST)
[15:41] <mdz> ok
[15:41] <mdz> so we'll hold the meeting at the same time in 2 weeks, and after DST, I'll look at it and see if it needs to be changed
[15:42] <mdz> anything else?
[15:42] <mdz> thanks, all
[15:42] <mdz> #endmeeting
[15:42] <MootBot> Meeting finished at 10:42.
[17:00] <smb_tp_> Time for the weekly kernel-team meeting
[17:00] <lieb> tis
[17:00] <smb_tp_> #startmeeting
[17:00] <smb_tp_> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[17:00] <smb_tp_> The above link points to today's agenda.
[17:00] <MootBot> Meeting started at 12:00. The chair is smb_tp_.
[17:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:00] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting
[17:00] <manjo> waves
[17:00]  * rtg waves
[17:01]  * cking waves
[17:01] <smb_tp_> [TOPIC] New Starters
[17:01] <MootBot> New Topic:  New Starters
[17:01] <sconklin> hi
[17:01]  * ikepanhc waves
[17:01] <cooloney> hi
[17:01] <smb_tp_> We have two new people that joined us last and this week: Brad Figg (bradF) and Bryan Wu (cooloney). Welcome to both of you (again)!
[17:01] <cooloney> waves
[17:01] <cooloney> hello guys
[17:01] <smb_tp_> Ok, that being said...
[17:01]  * BradFigg waves
[17:01] <smb_tp_> [TOPIC] Security & bugfix kernels
[17:01] <MootBot> New Topic:  Security & bugfix kernels
[17:02] <smb_tp_> Me
[17:02]  * apw looks about 10% here
[17:02] <smb_tp_> There are uploads planned to -proposed for Hardy and Intrepid. I summarized the current changeset for those uploads below.
[17:02] <smb_tp_> == Hardy (proposed) ==
[17:02] <smb_tp_> [kernel]
[17:02] <smb_tp_> • rt: Updated PREEMPT_RT support to rt27
[17:02] <smb_tp_> • fix apparmor memory leak on deleted file ops
[17:02] <smb_tp_> • KVM: MMU: Add locking around kvm_mmu_slot_remove_write_access()
[17:02] <smb_tp_> • serial: 8250: fix shared interrupts issues with SMP and RT kernels
[17:02] <smb_tp_> • 8250.c: port.lock is irq-safe
[17:02] <smb_tp_> • ACPI: Clear WAK_STS on resume
[17:02] <smb_tp_> [LBM]
[17:02] <smb_tp_> • [R] SAUCE: compat-wireless: Fix module load for crypto modules
[17:02] <smb_tp_> The one marked with [R] was reported as regression
[17:02] <apw> smb_tp_, nice summary
[17:03] <smb_tp_> This I would prepare soon to be uploaded
[17:03] <rtg> smb_tp_: are you ready for an Intrepid LBM update? I'vve pushed with the latest compat-wireless
[17:03] <smb_tp_> == Intrepid ==
[17:03] <smb_tp_> [kernel]
[17:03] <smb_tp_> • SAUCE: ACPI: EC: Limit workaround for ASUS notebooks even more
[17:03] <smb_tp_> • [R] SAUCE: report rfkill changes event if interface is down
[17:03] <smb_tp_> • [R] SAUCE: floppy: Provide a PnP device table in the module.
[17:03] <smb_tp_> • fix apparmor memory leak on deleted file ops
[17:03] <smb_tp_> • KVM: MMU: Add locking around kvm_mmu_slot_remove_write_access()
[17:03] <smb_tp_> [LBM]
[17:03] <smb_tp_> • scripts: Fix typo in prepare-compat-wireless.sh
[17:03] <smb_tp_> • Update MUNGE script for latest wireless-testing/compat-wireless
[17:03] <smb_tp_> • Update compat-wireless to master-2009-03-04
[17:03] <smb_tp_> rtg, Yep, noticed it
[17:03] <smb_tp_> There will possibly be a few more for intrepid
[17:03] <smb_tp_> which just get SRUed today
[17:04] <rtg> smb_tp_: I tried both iwl 3945 and 4965, they seemed to work well.
[17:04] <smb_tp_> Sound promising but as with that screen black regression (which I am also fixing by reverting the
[17:05] <smb_tp_> acpi changes, you never know until the whole bunch of hw has been tried outside
[17:06] <smb_tp_> So we will revert the change for acpi integers for Intrepid to be on the safe side with binary gfx drivers
[17:06] <smb_tp_> I think that would be all from me
[17:06] <smb_tp_> There are two minor bullets on the agenda
[17:07] <smb_tp_> * Archiving the Hardy/Intrepid OEM LPIA trees
[17:07] <rtg> smb_tp_: don't we have to wait until after the kernel sprint in Lexington?
[17:07] <sconklin> this will be deferred until after the sprint
[17:07] <smb_tp_> apw, You added that?
[17:08] <apw> smb_tp_, that was a direct copy from the previous week and
[17:08] <apw> and had its discussion then, can be ignored for now
[17:08] <smb_tp_> Ok, so we defer that until then, sconklin would that be an action for you?
[17:08] <apw> we will discuss that at the sprint i am sure
[17:08] <sconklin> my action, but not for a month
[17:09] <smb_tp_> Ok, I'll just add it so it is not forgotten
[17:09] <smb_tp_> [ACTION] sconklin bring up archiving of Hardy/Intrepid OEM LPIA trees after the sprint
[17:09] <MootBot> ACTION received:  sconklin bring up archiving of Hardy/Intrepid OEM LPIA trees after the sprint
[17:10] <smb_tp_> There was also the thing of movin Jaunty LPIA into distro kernel
[17:10] <smb_tp_> I believe that happened... right?
[17:10] <sconklin> I thought so, too
[17:10] <rtg> smb_tp_: done, but the use of it is deferred until the OEM has tested
[17:10] <rtg> OEM team*
[17:10] <smb_tp_> Ok. Fine with me
[17:11] <smb_tp_> apw, Anything else for stable kernels I forgot?
[17:11] <sconklin> I'll take an action to coordinate testing by the OEM team for both hardy and jaunty lpia
[17:11] <apw> sou
[17:11] <apw> sounds like its all there... handy summaries both
[17:11] <smb_tp_> [ACTION] sconklin coordinate testing by the OEM team for Hardy and Jaunty lpia
[17:11] <MootBot> ACTION received:  sconklin coordinate testing by the OEM team for Hardy and Jaunty lpia
[17:11] <smb_tp_> [TOPIC] Jaunty Status
[17:11] <MootBot> New Topic:  Jaunty Status
[17:12] <smb_tp_> * Jaunty Alpha 6
[17:12] <smb_tp_> rtg, Its comming, right :)
[17:12] <rtg> smb_tp_: I'm uploading a kernel this morning with ARM updates
[17:12] <apw> i assume the kernel basically closes today
[17:12] <rtg> its got the Freescale patches, and yes, this is about it before A6
[17:13] <rtg> I might get some Radeon patches in later today
[17:13] <rtg> smb_tp_: thats it from me
[17:13] <smb_tp_> Ok
[17:13] <smb_tp_> * Suspend/Resume
[17:14] <smb_tp_> apw, You wanted to do some updates how we stand?
[17:14] <apw> i have been working some on the test scripts which have been pushed
[17:14] <apw> to the checkbox repo ready to go
[17:14] <apw> we should be doing another call-for-testing for A6, i assume
[17:14] <apw> ogasawara_ will handle that as normal
[17:14] <ogasawara_> apw:  yep
[17:15] <smb_tp_> ok, so
[17:15] <apw> assuming the checkbox changes get uploaded today (and they are meant to before A6)
[17:15] <smb_tp_> [ACTION] ogasawara_ handle another call for testing for A6
[17:15] <MootBot> ACTION received:  ogasawara_ handle another call for testing for A6
[17:15] <apw> then the defautl checkbox will include it, so desktop would have the test suite already installed
[17:15] <cking> apw, are we seeing any new issues, or just more of the same?
[17:15] <manjo> apw, mark was doing some work on checkbox this week
[17:15] <apw> we may want to check that and update instructions if so
[17:15] <apw> cking, almost everything coming in is generall brokenness all different
[17:15] <apw> most are still not diagnosed with any specificity
[17:16] <apw> there are some 116 reports and thats a huge heap to do anything senesible with
[17:16] <apw> there is a fix for the pm-utils going in which helps with the suspend/resume
[17:16] <apw> marking your network disabled
[17:16] <apw> on the positive side
[17:17] <apw> nothing else of interest that i can think of
[17:17] <smb_tp_> ok thanks
[17:17] <smb_tp_> * Vanilla Kernel Builds
[17:18] <apw> nothing much there, one new kernel this week.  lots of use of them reported
[17:18] <smb_tp_> We now have a page that links vanilla build versions to Ubuntu versions
[17:18] <apw> yes, ogasawara_'s page has been sucked into the 'official' kernel user
[17:19] <apw> http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html
[17:19] <MootBot> LINK received:  http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html
[17:19] <apw> that is updated regularly and should include new Karmic kernels when they appear
[17:19] <ogasawara_> I'll redirect my existing page to the official one
[17:20] <smb_tp_> Ok, so I think thats all on that
[17:20] <apw> yep
[17:20] <smb_tp_> [TOPIC] ARM Tree
[17:20] <MootBot> New Topic:  ARM Tree
[17:20] <smb_tp_> amitk, Whats up
[17:21] <amitk> just finished uploading patches to enable the freescale SoC
[17:21] <amitk> imx51
[17:21] <amitk> that should be it as far as ARM features for Jaunty our concerned
[17:22] <amitk> s/our/are
[17:22] <rtg> we'vev also added mv78xx0 for Marvell buildds
[17:22] <amitk> rtg: though that isn't too useful w/o two VFP related patches
[17:22] <amitk> to fix PREEMPT and floating-point issues
[17:23] <rtg> amitk: bradF has 'em, we'll get them applied
[17:23] <amitk> I believe BradFigg is onto it
[17:23] <BradFigg> amitk: right
[17:23] <smb_tp_> Ok, anything else to note?
[17:24] <amitk> nothing else
[17:24] <amitk> thanks
[17:24] <smb_tp_> ok, thanks
[17:24] <smb_tp_> [TOPIC] LPIA Tree
[17:24] <MootBot> New Topic:  LPIA Tree
[17:24] <sconklin> Me
[17:24] <smb_tp_> sconklin yeah
[17:25] <sconklin> lpia is integrated into jaunty, and intrepid (I think). Hardy has a lpia branch.
[17:25] <sconklin> oem folks will test hardy and jaunty, since those are where they will work from
[17:26] <cking> are we deferring the hardy LPIA lrm until the sprint?
[17:26] <sconklin> I'm keeping the distro tree lpia branch up to date (more or less) with what's in the netbook oem trees, and at the sprint we'll chage over to the distro tree
[17:26] <lool> Kinf of lpia related, apw: NCommander tested your kernel with that jax10 patch; it works fine in both cases, but selects a different DMA mode with your patch; I've asked for stress testing both drivers and see how they perform
[17:26] <sconklin> lrm and lum are also being looked at by the oem folsk for testing, I think. We'll finalize that at sprint
[17:27] <apw> lool ok... let us know the outcome
[17:27] <sconklin> Unfortunately, there is at least one development project which has a schedule that precludes moving it to the hardy distro tree at the sprint, we'll deal with it later.
[17:27]  * cking nods
[17:27] <sconklin> So we won't be able to entirely retire and archive the netbook repo
[17:27] <sconklin> that's all I have
[17:28] <smb_tp_> Alright, thanks
[17:28] <smb_tp_> [TOPIC] Incomming Bugs
[17:28] <MootBot> New Topic:  Incomming Bugs
[17:28] <apw> ogasawara_, is up
[17:28] <ogasawara_> just a few to mention . . .
[17:28] <ogasawara_> bug 328440
[17:28] <ogasawara_> ^^ regression-potential
[17:28] <ogasawara_> bug 322621
[17:29] <ogasawara_> ^^ noted as Critical for Hardy
[17:29] <apw> appears to be fixed?
[17:29] <smb_tp_> I believe we are waiting on some feedback there
[17:29] <ogasawara_> apw: for jaunty
[17:29] <apw> silly ubbottu
[17:29] <ogasawara_> bug 339743
[17:29] <ogasawara_> bug 336652
[17:30] <ogasawara_> smb_tp_: that's it for now
[17:30] <apw> the popen() one is possibly ok as we run audit and you can only hit it with a debian kerenl on your ubuntu system
[17:30] <smb_tp_> Ok, thanks. apw and me will have a look at those
[17:30] <apw> the poor performance is a hardware specific problem with asus or somethign h/w
[17:31] <apw> which we have some of in house it seeems
[17:31] <apw> smb_tp_, ack
[17:31] <apw> ogasawara_, how is the incoming regressions looking?
[17:31] <smb_tp_> [ACTION] apw and smb look through the bugs ogasawara_ mentioned
[17:31] <MootBot> ACTION received:  apw and smb look through the bugs ogasawara_ mentioned
[17:31] <apw> the list is growing very quick all of a sudden
[17:31] <apw> is this a real increase or a change in the way we track?
[17:31] <ogasawara_> apw: I added regression-potential to the weekly bug list, which explains the slight increase in #'s
[17:32] <apw> it feels like we are picking up about 5 regressions a week
[17:32] <ogasawara_> apw: I haven't seen a large amount of growth in regressions, but I suspect that'll change as we approach final release and get more testers/bug reporters
[17:33] <apw> ogasawara_, will you be sprinting?
[17:33] <ogasawara_> apw: yes
[17:33] <apw> then perhaps we can have some time to think about how we track etc
[17:33] <ogasawara_> sbeattie: what's your feel for the incoming linux regressions?  I try to keep track of your regression tracking page
[17:34] <smb_tp_> ogasawara_, Right, we possible could improve the layout a bit and perhaps split that lists
[17:34] <apw> for instance i wonder if we could have a 'just linux' version of his pages ...
[17:34] <smb_tp_> But the sprint is a good place to sit together
[17:34] <apw> ack
[17:34] <ogasawara_> apw: I usually sort sbeattie's list
[17:34] <ogasawara_> apw: to at least group linux bugs
[17:35] <smb_tp_> [ACTION] apw, ogasawara_ and smb_tp discuss regression lists at the sprint
[17:35] <MootBot> ACTION received:  apw, ogasawara_ and smb_tp discuss regression lists at the sprint
[17:35] <apw> some how you find thigns may be all we need
[17:36] <smb_tp_> Ok, sounds like all for that...
[17:36] <smb_tp_> Then there are some leftovers
[17:36] <smb_tp_> [TOPIC] Open Action Items
[17:36] <MootBot> New Topic:  Open Action Items
[17:36] <smb_tp_> • last week
[17:36] <smb_tp_> ∘ unknown, add marker to calendar to show end of outside change acceptance
[17:37] <smb_tp_> Anyone volunteering for that?
[17:37] <apw> this was idea of putting in a marker two days before a milestone
[17:37] <smb_tp_> right
[17:37] <apw> to say that the kernel froze then, to encourage contributions to make it sooner
[17:37] <amitk> i thought pgraner had access to that calendar, not us
[17:37] <apw> i think we may be able to add things
[17:38] <smb_tp_> me too I think
[17:38] <smb_tp_> oops
[17:38] <apw> perhaps its something we add as me go along, not sure
[17:38] <smb_tp_> So
[17:38] <pgraner> amitk: I know for sure rtg does
[17:38] <apw> perhaps we can discuss at sprint if we are not sure its a good thing
[17:38] <smb_tp_> [ACTION] smb add marker to calendar to show kernel freezes
[17:38] <MootBot> ACTION received:  smb add marker to calendar to show kernel freezes
[17:38] <smb_tp_> ∘ pgraner, sconklin, awe to discuss OEM testing of lpia trees
[17:38] <smb_tp_> I think that was going on at the sprint
[17:39] <smb_tp_> ∘ sconklin to create wiki page showing lpia source structure and repos for various releases
[17:39] <smb_tp_> • outstanding from previous week
[17:39] <smb_tp_> sconklin ?
[17:39] <amitk> smb_tp_: I added something before beta freeze
[17:39] <awe> smb_tp: correct; we've talked a bit and I'm going to do some testing, however we're waiting for the sprint to switchover
[17:39] <sconklin> nothing done, may defer until after sprint?
[17:40] <smb_tp_> Ok, I just leave it on the agenda
[17:40] <sconklin> or I'll do the distro side and then we can have that at the sprint
[17:40] <smb_tp_> As it is better to handle for you
[17:41] <smb_tp_> This is just the nag round, so we do not drop things
[17:41] <smb_tp_> ∘ apw to confirm the ack requirements for jaunty
[17:41] <apw> not done that yet.  i am assuming one ack right now, but needing that ack for jaunty
[17:41] <apw> rtg, is that fair to say
[17:41] <smb_tp_> Me thinks we grab all available beings at the sprint as well and then document it
[17:42] <apw> and i think we will have a session at the sprint any how on it all
[17:42] <apw> ack
[17:42] <smb_tp_> Ok, that were all remaining ones
[17:42]  * rtg is distracted. Is what fair to say?
[17:42] <smb_tp_> [TOPIC] Open Discussion
[17:42] <MootBot> New Topic:  Open Discussion
[17:42] <apw> that we now require acks, at least one for jaunty for commits
[17:42] <rtg> apw: correct
[17:43] <rtg> or rather, for the most part that is true.
[17:43] <smb_tp_> There seems to be always a "mostly" :)
[17:43] <smb_tp_> rtg, Which would be the exceptions then?
[17:44] <rtg> well, the ARM stuff hasn't required an ACK, unless you count me pushing as an ACK
[17:44] <cooloney> apw, what kind of ack we need
[17:44] <apw> rtg yeah i would, thats amit plus you
[17:44] <amitk> apw: I shouldn't be counted
[17:44] <rtg> but apw is right, after A6 we should start an SRU ACK process for all Jaunty patches.
[17:45] <cking> indeed
[17:45] <apw> cooloney, now that jaunty is past ff, i am assuming i need acks
[17:45] <smb_tp_> cooloney, We will discuss that process on the sprint as well
[17:45] <cooloney> smb_tp_,  apw, thanks
[17:45]  * cking wonders if there will be enough time at the sprint. the agenda could be tight
[17:46] <smb_tp_> cking, There are beer time sessions ;-)
[17:46] <rtg> cking: we could stay the weekend :)
[17:46] <amitk> cooloney: basically every patch now needs to be sent to the mailing list, acked by two (one?) members of the canonical kernel team before they are added to the Jaunty git tree.
[17:46] <smb_tp_> Right, back to open discussion
[17:46] <cooloney> amitk, thanks got it, i assume we need upstream acks, -:))
[17:47] <smb_tp_> Anyone has something to bring up?
[17:47] <RumbleRed> Bluetooth compatibility fix.
[17:47] <apw> nothing i can think of
[17:47] <RumbleRed> The thing I posted to the mailing list.
[17:47] <smb_tp_> RumbleRed, right, I am looking at it
[17:47] <smb_tp_> Normally we wait until it has made its way to linus tree
[17:48] <cooloney> amitk, could you double check with pgraner about the arm boards?
[17:48] <amitk> yes
[17:48] <cooloney> amitk, thanks
[17:49] <smb_tp_> RumbleRed, But I look at getting it tested before. But possible not with the next proposed upload
[17:50] <smb_tp_> Anything else?
[17:51] <smb_tp_> So I would wrap it up here. Thanks all
[17:51] <manjo> cya
[17:51] <smb_tp_> #endmeeting
[17:51] <MootBot> Meeting finished at 12:51.
[17:51]  * rtg bows out
[17:51] <cooloney> thanks a lot
[17:51]  * apw wanders off into the weeds, hits some quick sand ...


[02:41] <jgor> :\
[03:37] <mhall119_> highvoltage: no filter yet, but loco.u.c got hit by the spam too, so it's already been requested
[08:14] <alkisg> Good morning
[13:02] <highvoltage> good morning AlanBell
[13:02] <highvoltage> oops, that was aimed at alkisg, who's no longer with us
[13:02] <highvoltage> (on IRC, at least)
[15:01] <AlanBell> morning highvoltage
[15:04] <highvoltage> AlanBell: how are things?
[15:06] <AlanBell> not bad at all
[15:06] <AlanBell> as it happens I will be doing a little edubuntu demo next week
[15:55] <highvoltage> ooh, cool!


[06:49] <YoBoY> bonjour
[08:11] <locodir-user> hello all
[08:13] <locodir-user> anybody?
[16:29] <huats> hello everyone
[16:29] <czajkowski> huats: aloha