[02:03] <Whatsisname> whoops
[08:51] <dholbach> @schedule
[08:51] <Ubugtu> Schedule for Etc/UTC: 18 Jan 21:00: Ubuntu Development Team | 20 Jan 15:00: Xubuntu | 24 Jan 12:00: Edubuntu | 25 Jan 16:00: Ubuntu Development Team | 30 Jan 20:00: Technical Board | 31 Jan 20:00: Edubuntu
[12:57] <dholbach> @schedule
[12:57] <Ubugtu> Schedule for Etc/UTC: 18 Jan 21:00: Ubuntu Development Team | 20 Jan 15:00: Xubuntu | 24 Jan 12:00: Edubuntu | 25 Jan 16:00: Ubuntu Development Team | 30 Jan 20:00: Technical Board | 31 Jan 20:00: Edubuntu
[03:47] <gnomefreak> @schedule new_york
[03:47] <Ubugtu> Schedule for America/New_York: 18 Jan 16:00: Ubuntu Development Team | 20 Jan 10:00: Xubuntu | 24 Jan 07:00: Edubuntu | 25 Jan 11:00: Ubuntu Development Team | 30 Jan 15:00: Technical Board | 31 Jan 15:00: Edubuntu
[04:00] <cypher1> @schedule calcutta
[04:00] <Ubugtu> Schedule for Asia/Calcutta: 19 Jan 02:30: Ubuntu Development Team | 20 Jan 20:30: Xubuntu | 24 Jan 17:30: Edubuntu | 25 Jan 21:30: Ubuntu Development Team | 31 Jan 01:30: Technical Board | 01 Feb 01:30: Edubuntu
[04:00] <dholbach> hello everybody
[04:00] <heno> hello folks!
[04:00] <dsas> hello dholbach (lecture got cancelled :))
[04:00] <rulus> hi
[04:00] <dholbach> this is the bughelper meeting
[04:00] <dholbach> dsas: good you could make it
[04:00] <alex_muntada> hello everybody!
[04:01] <dholbach> I announced the meeting over here: https://lists.ubuntu.com/archives/ubuntu-bugsquad/2007-January/000236.html and I think we can use the list as a rough 'agenda'
[04:01] <dholbach> bughelper is a tool that heno started off (everybody thank him for that) and it'll hopefully make our bug triaging efforts all a bit easier
[04:01] <dholbach> https://wiki.ubuntu.com/BugHelper has some information about it
[04:01] <dholbach> and heno was kind enough to start a tutorial over here: https://wiki.ubuntu.com/BugHelper/Tutorial
[04:02] <dholbach> let's all take a look at it now: please check it out by running something like:  bzr branch http://bazaar.launchpad.net/~bugsquad/bughelper/bughelper.main
[04:02] <gnomefreak> thanks heno :)
[04:02] <heno> I had an itch
[04:03] <dholbach> bughelper has its brain in the ./packages directory
[04:03] <heno> in the form of 668 open ubiquity bugs
[04:03] <dholbach> we recently changed the .info files to an XML format, which is described over here: https://wiki.ubuntu.com/BugHelper/Dev/ClueFiles
[04:03] <heno> thank dholbach for that!
[04:03] <dholbach> which allows us to do queries depending on nested and/or/not statements
[04:03] <dholbach> de rien, I had fun hacking it :)
[04:04] <dholbach> as you can see from your local branch, the packages/ directory doesn't contain that much information yet
[04:04] <dholbach> if you invoke    bughelper    with a source package, it will check all the ubuntu launchpad bugs for that source package (based on the clues in the .info files)
[04:05] <dholbach> daniel@lovegood:~/bughelper.main$ ./bughelper vino
[04:05] <dholbach> http://launchpad.net/bugs/43050 :  Vino crasher bugs
[04:05] <dholbach> daniel@lovegood:~/bughelper.main$
[04:05] <Ubugtu> Malone bug 43050 in vino "vino-server crashes after connect if resolution has been changed via xrandr" [Unknown,Unconfirmed] 
[04:05] <dholbach> that's the result I get for vino
[04:05] <dholbach> bughelper can also search in the attachments of the bugs, if you pass it the   -A   flag
[04:05] <Nafallo> <3
[04:06] <dholbach> with   -a   it searches not just on the first page of the launchpad bug listing (which only contains 75 bugs), but on all the succeeding pages also
[04:06] <seb128> dholbach: I think -a should be the default
[04:06] <seb128> any case where we want to limit to one page
[04:06] <seb128> the "one page" doesn't make any real sense
[04:06] <alex_muntada> I got an error...
[04:06] <alex_muntada> Traceback (most recent call last):
[04:06] <alex_muntada>   File "./bughelper", line 58, in ?
[04:06] <alex_muntada>     main()
[04:06] <alex_muntada>   File "./bughelper", line 34, in main
[04:06] <alex_muntada>     if not utils.package_exists(cl.sourcepackage):
[04:06] <alex_muntada>   File "/home/alexm/ubuntu/bughelper/bughelper.main/bugHelper/utils.py", line 25, in package_exists
[04:06] <alex_muntada>     sources = apt_pkg.GetPkgSrcRecords()
[04:06] <alex_muntada> SystemError: E:You must put some 'source' URIs in your sources.list
[04:06] <heno> that will become obsolete with XML bug data
[04:06] <dholbach> seb128: file a wishlist bug :-)
[04:07] <seb128> dholbach: oki
[04:07] <dholbach> alex_muntada: can you file a bug about that too? we should catch that bug
[04:07] <dsas> alex_muntada: You do not have any deb-src lines in /etc/apt/sources.list. We should catch that.
[04:07] <heno> but I agree with seb128
[04:07] <dholbach> you can also pass a custom bug list URL to the bughelper, with    -l <url>
[04:07] <gnomefreak> this only works with packages in the packages folder right?
[04:07] <alex_muntada> dholbach: sure
[04:07] <dholbach> gnomefreak: bughelper will only issue clues it has in the packages/ folder
[04:08] <alex_muntada> dsas: you're right, thanks!
[04:08] <gnomefreak> k
[04:08] <dholbach> gnomefreak: one of the next steps will be to have 'general clues'
[04:08] <dholbach> gnomefreak: so that totem.info can inherit from gnome.info or something like that
[04:08] <gnomefreak> ok cool
[04:08] <heno> https://bugs.launchpad.net/bughelper/+bug/79151
[04:08] <Ubugtu> Malone bug 79151 in bughelper "support global clues" [Undecided,Confirmed] 
[04:08] <dholbach> thanks heno :)
[04:08] <gnomefreak> ty heno
[04:09] <dholbach> if you examine one of the .info files, you will see that it could be a bit irksome to type in all the XML yourself
[04:09] <dholbach> that's why I added    bugxml -sa <package> <condition> <clue information>    yesterday
[04:09] <dholbach> which will do the work for the simple cases for you
[04:09] <dholbach> that's roughly what bughelper can do for you at the moment
[04:10] <dholbach> I'm very happy with what we've achieved - thanks to all the contributors
[04:10] <dholbach> given that the effort is only around 4 weeks old ;-)
[04:10] <dholbach> are there any questions up until now?
[04:10] <heno> Yeah, bit really rocks to see patches coming in!
[04:10] <heno> *it
[04:11] <dholbach> Any suggestions?
[04:11] <dholbach> Any crazy ideas off the top of your head?
[04:11] <dholbach> Ok, let's move on then
[04:11] <dholbach> The future, of course, looks bright
[04:12] <dholbach> we'll move on to version 0.1 now and only implement tiny bits and pieces and QA it properly
[04:12] <heno> Could bughelper also look in upstream BTSes for dupes?
[04:12] <dholbach> heno: at some stage... why not?
[04:12] <heno> agree about the 0.1 plan
[04:12] <dholbach> we marked a bunch of bugs as 0.1: https://launchpad.net/bughelper/+milestone/0.1
[04:12] <dholbach> and most of them are easy fixes and enhancements, so there's plenty of room to get involved
[04:13] <Nafallo> :-)
[04:13] <dholbach> we want it to live packaged in Ubuntu, but I'd personally recommend: implemeting all the 0.1 bugs, then QA for 2 weeks (and of course add lots of .info clues), then upload to Ubuntu
[04:13] <dholbach> what do you think about that?
[04:14] <heno> cool! universe, I take it
[04:14] <Nafallo> dholbach: sounds good
[04:14] <Nafallo> heno: indeed
[04:14] <dholbach> (if you plan to hack a bit on bughelper yourself, these are the bugs marked as 'bitesize': https://launchpad.net/bughelper/+bugs?field.tag=bitesize - they should be really easy and good to work on, if you want to contribute)
[04:14] <dholbach> ok cool
[04:14] <dholbach> :-)
[04:15] <dholbach> we absolutely need documentation for it
[04:15] <alex_muntada> Just filed https://bugs.launchpad.net/bughelper/+bug/80453
[04:15] <Ubugtu> Malone bug 80453 in bughelper "You must put some 'source' URIs in your sources.list" [Medium,Confirmed] 
[04:15] <dholbach> so if you want to help with that, I'd highly appreciate it
[04:15] <dholbach> alex_muntada: thanks a lot
[04:15] <alex_muntada> :)
[04:15] <seb128> dholbach: I've a question
[04:15] <dholbach> we need wiki docs, manpages and a nice README
[04:15] <dholbach> seb128: fire away
[04:15] <seb128> has anybody talked with launchpad guys about it?
[04:15] <seb128> how does the bughelper query impact on the lp load?
[04:15] <dholbach> seb128: yes, I sent a mail to their list already and matsubara was nice enough to comment on a bug
[04:16] <dholbach> seb128: dsas changed the http user agent to "bughelper <version> ..." so they can track our load on it
[04:16] <seb128> good
[04:16] <seb128> because I don't want to DoS launchpad because many people start doing huge query with it
[04:16] <dholbach> we need documentation on:
[04:16] <dholbach>  * usage of the commands (all flags explained)
[04:17] <dholbach>  * how to add clues
[04:17] <dholbach>  * process docs - how we collaborate
[04:17] <dholbach>  * tiny recipes, that explain how you work with it
[04:17] <dholbach> (anything else you can think of?)
[04:18] <dholbach> can somebody of you imagine contributing to bughelper in any way?
[04:18] <dholbach> be it documentation, code, clue files, bug reports or anything else? :)
[04:19] <dholbach> ok, I see - let's move on then
[04:19] <Nafallo> hehe
[04:19] <dholbach>  * we need people to spread the word (in blogs, mailing lists, etc. :))
[04:19] <Nafallo> I think that will show itself later :-)
[04:19] <alex_muntada> yesterday I started to look at the docbook example that you suggested (kxmame)
[04:20] <dholbach> alex_muntada: ah nice... did it look manageable?
[04:20] <alex_muntada> but it's based on KDE handbooks
[04:20] <alex_muntada> is it fine for bughelper?
[04:20] <dholbach> alex_muntada: the one contained in debian/?
[04:20] <dholbach> alex_muntada: that's used to build a manpage iirc
[04:21] <dholbach> (thanks heno btw for spreading the word already :-))
[04:21] <alex_muntada> dholbach: I'm not sure it was the one on debian, let me check
[04:21] <dholbach> alex_muntada: ah ok, yeah - there might have been others too
[04:21] <dholbach> a last item (apart from general Q&A), I'd like to talk about is the processes we need to work on bughelper
[04:22] <dholbach> I envisioned doing commits to ~bugsquad/bughelper/bughelper.main only after peer review
[04:22] <dholbach> and heno, dsas, Vassilis Pandis and Brian Murray and I have been quite good with that already
[04:22] <Nafallo> does that happen on IRC?
[04:22] <dholbach> so after one review (either in bug reports, mails on the mailing list) a merge and push to bughelper.main should be fine
[04:23] <dholbach> of course this is not suitable for additions and changes to clue files
[04:23] <dholbach> what do you think about that?
[04:23] <dholbach> how did it work for you until now?
[04:23] <dholbach> Nafallo: we did some small discussions about patches yesterday in IRC on #ubungu-bugs, yes
[04:23] <Nafallo> dholbach: nice. so peer review on any suitable forum then ;-)
[04:23] <dholbach> Nafallo: but until now the development happened mostly off-irc, which I think is very good
[04:23] <Nafallo> sounds good :-)
[04:24] <dsas> the process so far has been fine by me. Patches still get pushed quickly and I'd be uncomfortable with my work going in without them.
[04:24] <dsas> them being reviews :)
[04:24] <dholbach> dsas: same for me
[04:24] <dholbach> heno, seb128: what do you think?
[04:24] <seb128> dholbach: review for code changes are good
[04:24] <heno> I'm probably not the best person to be main reviewer
[04:25] <heno> as my python is quite weak
[04:25] <dholbach> heno: but what do you think about the idea?
[04:25] <seb128> dholbach: how are commit access handled?
[04:25] <dholbach> seb128: everybody in ~bugsquad can commit to ~bugsquad/bughelper/bughelper.main
[04:25] <heno> sounds sound
[04:25] <seb128> dholbach: well, I would trust people to not abuse
[04:25] <dholbach> seb128: so we're really lax about commit access, which I think is good (until it should really prove otherwise)
[04:25] <dholbach> me too
[04:26] <alex_muntada> I like the idea too, though my python is also weak
[04:26] <seb128> and that's not a stable app that we need to be careful not to break
[04:26] <seb128> the review is not really required
[04:26] <dholbach> I'll try to only upload to Ubuntu what has really proven to be stable
[04:26] <dholbach> so how should we proceed about changes/additions to clue files?
[04:26] <dholbach> my feeling is that bug reports for that are too heavy
[04:27] <seb128> maybe have a "proposed-clue" directory to bzr somewhere
[04:27] <seb128> have people to commit there
[04:27] <alex_muntada> since I just began to work with bzr and launchpad for devel, I'll ask any of you before committing anything to main branch
[04:27] <seb128> and have somebody in charge of merging interest clues then
[04:27] <heno> could we just send files to the ML?
[04:28] <dholbach> at some stage we should move to another list ;-)
[04:28] <dholbach> but that is imho not now
[04:28] <dsas> maybe people would find it easier to paste an xml file into a bug report rather than having to learn about bzr and LP.
[04:28] <seb128> heno: I don't think flooding the list is a good diea
[04:28] <seb128> idea
[04:28] <alex_muntada> dsas: agreed
[04:28] <dholbach> should we just make a good document on how to commit them directly, forcing them to use   bzr diff | diffstat   before committing?
[04:28] <seb128> dsas: people who don't know about bzr probably don't know enough to determine what clues are interesting
[04:29] <heno> I agree with dsas. committing to bzr can be scary
[04:29] <seb128> I don't want a zillion of clue with are not useful there
[04:29] <Nafallo> I like seb128s idea :-)
[04:29] <seb128> that's like tags
[04:29] <heno> which raises an interesting question:
[04:29] <dsas> seb128: If they're in the bug tracker then a set of bughelper hackers can choose which ones to commit.
[04:29] <seb128> there is people are who tag "package" bugs with the tag "package"
[04:29] <alex_muntada> seb128: but there are more people triaging bugs that could know enough to write clues even if they know nothing about bzr
[04:30] <heno> how do we know which clues are useful?
[04:30] <seb128> the same people are able to add a "package" clue to "package" :p
[04:30] <dholbach> heno: I don't think we can ever know that
[04:30] <dholbach> heno: unless we maintain that package
[04:30] <seb128> I do know what GNOME clues would be useful or not
[04:30] <dholbach> (or take reasonable good care for it)
[04:30] <seb128> that's the frequent crashers or problems sent
[04:30] <dholbach> s/for/of
[04:30] <heno> ok
[04:31] <dholbach> we could also split the branches
[04:31] <dholbach> bughelper and bughelper-data
[04:31] <dholbach> and also package them separately
[04:31] <alex_muntada> dholbach: good idea!
[04:31] <dholbach> we probably wouldn't have to subscribe the bugsquad to bughelper-data, so they wouldn't show up on the list
[04:31] <dholbach> but just people who'd take care of merging them in
[04:32] <alex_muntada> that way we can package them in large groups: bughelper-data-gnome, bughelper-data-kde, bughelper-data-xorg...
[04:32] <dholbach> we can see if that will ever prove necessary
[04:32] <dholbach> seb128, dsas, heno: does that idea make sense?
[04:33] <seb128> yep, makes sense imho
[04:33] <heno> yes, I think one package bughelper-data is enough though
[04:33] <dholbach> although it can be quite hairy to have two separate branches to update
[04:33] <dholbach> dunno if a branch in a branch works
[04:33] <dsas> Makes sense to me.
[04:34] <seb128> dholbach: don't bother, the package is small enough to get frequent updates
[04:34] <heno> are we likely to change the xml file structure much from now on?
[04:34] <seb128> and KDE people will not change GNOME clues anyway
[04:34] <seb128> no need to split
[04:34] <dholbach> seb128: so you'd just work with the bughelper-data package and not with checkouts?
[04:35] <dholbach> heno: maybe add <sourcepackage>
[04:35] <dholbach> heno: that's all I can think about right now
[04:35] <seb128> dholbach: well, we package from bzr
[04:35] <seb128> dholbach: no split to -data-gnome, -data-kde, etc though
[04:35] <dholbach> seb128: ./bughelper/ = one branch
[04:35] <dholbach> seb128: ./bughelper/packages = another branch
[04:35] <persia> Why not provide two binaries from a single source, so as to defer the one/two branches decision?
[04:35] <dholbach> seb128: that's my concern
[04:35] <heno> dholbach: perhaps <wikipage> too
[04:36] <seb128> dholbach: I've no string preference
[04:36] <heno> with triaging tips for that pkg
[04:36] <dholbach> heno: it's no problem to add optional tags
[04:36] <heno> ok
[04:36] <dholbach> ok, let's defer the -data discussion
[04:36] <dholbach> i'll think about it some more and try to figure out something clever
[04:37] <dholbach> for now it should be possible to just change them in .main
[04:37] <dholbach> if you add them yourself, they come in via mail or bug report, no problem
[04:37] <heno> I think your last version is sound
[04:37] <dholbach> heno: what do you mean?
[04:37] <heno> having a separate branch will encourage clue file upoads
[04:38] <heno> because you don't worry so much about breaking the whole thing
[04:38] <dholbach> heno: we'll have the problem of having different branches on the disk, if we work from ~/bzr
[04:38] <heno> seb128: ./bughelper/ = one branch
[04:38] <heno>  seb128: ./bughelper/packages = another branch
[04:38] <dholbach> yeah
[04:38] <dholbach> I'm not sure that works
[04:39] <heno> hm, ok
[04:39] <heno> let's work it out next week
[04:39] <dholbach> we can still figure that out - on the list probably
[04:39] <dholbach> yeah
[04:39] <dsas> can't we just bzr ignore bughelper/packages ?
[04:39] <dholbach> dsas: we need to try that
[04:39] <seb128> brb, trying new GTK
[04:40] <dholbach> we could also set a LOCAL_BUGHELPER_DATA_DIR in ~/.bashrc
[04:40] <dholbach> and use that in addition to /usr/share/bughelper/packages (which the package will install to)
[04:40] <alex_muntada> dholbach: you were right about docbook man page... it was on debian
[04:40] <alex_muntada> dholbach: I'll try to get a man page ready
[04:40] <dholbach> that way we could have   ~/bzr/bughelper/      and     ~/bzr/bughelper-data/
[04:40] <gnomefreak> taking suggestions on packages/clues to add?
[04:41] <dholbach> alex_muntada: thanks a lot - you should be able to reuse README
[04:41] <dholbach> gnomefreak: what do you mean?
[04:41] <dholbach> heno: I think we should start a wiki page on BugHelper/Dev/SplittingOutData or something
[04:42] <heno> yep
[04:42] <dholbach> gnomefreak: if we have people who care about certain packages that's great
[04:42] <dholbach> gnomefreak: so if you want to commit some clues for that, that's VERY cool
[04:42] <gnomefreak> dholbach: once i figure it out i will try
[04:42] <dholbach> ok cool
[04:43] <dholbach> gnomefreak: we'll set up a document for that
[04:43] <gnomefreak> ok ty
[04:43] <dholbach> are there any other questions?
[04:43] <gnomefreak> not from me
[04:43] <dholbach> any concerns from the launchpad folks: matsubara-lunch? :)
[04:44] <heno> has anyone actually found it useful so far?
[04:44] <heno> just curious
[04:44] <dholbach> excellent question :)
[04:44] <dholbach> seb128 and cjwatson have used it to grep through bug attachments afaik
[04:44] <heno> I have, and I think Colin has
[04:44] <dholbach> seb128 told me he found 2 dups that LP didn't find
[04:45] <Nafallo> I found out about it in the beginning of this meeting ;-)
[04:45] <heno> yeah, cjwatson too all my low hanging ubiquity fruit one day :-/
[04:45] <heno> *took
[04:45] <Ubugtu> Malone bug 79151 in bughelper "support global clues" [Medium,Confirmed]  https://launchpad.net/bugs/79151
[04:45] <heno> that's teach me to make open source tools
[04:46] <heno> *that'll
[04:46] <dholbach> :)
[04:46] <dholbach> ok... if you don't have anything you want to bring up now, let's close the meeting and go back to hacking or bug triaging :-)
[04:46] <dholbach> oh, I have something
[04:47] <Nafallo> hmm, translating ;-)
[04:47] <dholbach> if you think that one of the open bugs https://launchpad.net/bughelper/+bugs classifies to be a must 0.1 feature, say so in the bug
[04:47] <Nafallo> dholbach: if don't have anything new for me to make up-to-date? :-)
[04:47] <dholbach> Nafallo: make up-to-date?
[04:47] <Nafallo> dholbach: "new upstream release"
[04:48] <dholbach> translating would be nice... although I think it'd be quite irksome to translate all the clues
[04:48] <alex_muntada> dholbach: I was thinking about taking bug 79222 (docs) but I'd like to know what doc tools should I use, docbook?
[04:48] <Ubugtu> Malone bug 79222 in bughelper "RFE: add documentation to bughelper" [High,Confirmed]  https://launchpad.net/bugs/79222
[04:48] <heno> translated error logs might actually be a problem for bughelper
[04:48] <dholbach> and given that LP Bugs is completely in english, ...
[04:48] <rulus> maybe we can translate the docs though?
[04:48] <dholbach> alex_muntada: those can be plain text files
[04:48] <heno> if the clue has english text but the log has german or swedish
[04:48] <dholbach> rulus: sure, why not
[04:49] <Nafallo> dholbach: oh. I was more suggesting I should go back to translating gajim before the 0.11.1 release :-)
[04:49] <alex_muntada> dholbach: great, far easier to do
[04:49] <dholbach> if you want to translate documents, sure go ahead - we'll add them
[04:49] <dholbach> Nafallo: ah ok
[04:49] <heno> right, but the syslogs can be in any language
[04:49] <dholbach> I don't think there's much use of bughelper being in german/spanish or something
[04:49] <dholbach> heno: we can just filter for that
[04:49] <Nafallo> agreed :-)
[04:49] <heno> ok
[04:49] <dholbach> heno: we just ignore it's another language - it's merely a string :)
[04:50] <dholbach> Ok cool
[04:50] <dholbach> Going Once...
[04:50] <dholbach> Going Twice...
[04:50] <dholbach> Meeting Adjourned
[04:50] <dholbach> i'll add the log to the wiki
[04:50] <dholbach> thanks everybody
[04:50] <heno> Great meting, thanks all!
[04:50] <fernando> thanks dholbach
[04:50] <Nafallo> thanks YOU :-)
[04:51] <Nafallo> s/s//
[04:51] <rulus> thanks for keeping us up to date :)
[04:51] <gnomefreak> ty
[04:51] <dholbach> anytime - bughelper is a great project to work on
[04:51] <seb128> dholbach: thank you ;)
[04:52] <alex_muntada> thanks!
[04:58] <Yawner> I missed the meeting didnt I..
[04:58] <Yawner> back to reading I suppose :(
[05:00] <heno> Yawner: the bughelper meeting?, yes you did. Do you have the log?
[05:01] <Klaidas> @schedule VIlnius
[05:01] <Ubugtu> Schedule for Europe/Vilnius: 18 Jan 23:00: Ubuntu Development Team | 20 Jan 17:00: Xubuntu | 24 Jan 14:00: Edubuntu | 25 Jan 18:00: Ubuntu Development Team | 30 Jan 22:00: Technical Board | 31 Jan 22:00: Edubuntu
[05:02] <Yawner> Yeah I have been sitting in here since yesterday, ill read it back in a sec
[05:03] <alex_muntada> @schedule barcelona
[05:03] <dholbach> let's move to #ubuntu-bugs
[05:03] <dholbach> Yawner: https://wiki.ubuntu.com/BugHelper/Dev/Meetings/20070118
[05:04] <alex_muntada> @schedule madrid
[05:04] <Ubugtu> Schedule for Europe/Madrid: 18 Jan 22:00: Ubuntu Development Team | 20 Jan 16:00: Xubuntu | 24 Jan 13:00: Edubuntu | 25 Jan 17:00: Ubuntu Development Team | 30 Jan 21:00: Technical Board | 31 Jan 21:00: Edubuntu
[05:04] <alex_muntada> @schedule andorra
[05:04] <Ubugtu> Schedule for Europe/Andorra: 18 Jan 22:00: Ubuntu Development Team | 20 Jan 16:00: Xubuntu | 24 Jan 13:00: Edubuntu | 25 Jan 17:00: Ubuntu Development Team | 30 Jan 21:00: Technical Board | 31 Jan 21:00: Edubuntu
[08:26] <Lure> @schedule ljubljana
[08:26] <Ubugtu> Schedule for Europe/Ljubljana: 18 Jan 22:00: Ubuntu Development Team | 20 Jan 16:00: Xubuntu | 24 Jan 13:00: Edubuntu | 25 Jan 17:00: Ubuntu Development Team | 30 Jan 21:00: Technical Board | 31 Jan 21:00: Edubuntu
[09:55] <cjwatson> heno: re earlier, yes, bughelper is now an important part of my workflow
[09:55] <mdz> good evening
[09:55] <cjwatson> need to get round to contributing clue file changes back
[09:55] <heno> cjwatson: cool :)
[09:55] <kylem> g'afternoon mdz.
[09:55] <fabbione> evening
[09:56] <cjwatson> (I haven't updated to the XML bughelper yet)
[09:56] <mdz> did anyone hear from Scott about whether he'll be here?
[09:57] <cjwatson> not I
[09:57] <mdz> who do we have so far?
[09:57] <heno> cjwatson: we should get input on the clue files from maintainers of various large packagers to help people triage better
[09:57] <cjwatson> absolutely
[09:58] <zul> hi
[09:58] <kwwii> evening
[09:58] <bdmurray> hello
[09:58] <dholbach> cjwatson:   bugxml -sa ubiquity <condition> <info>   :-)
[09:59] <mdz> kwwii,bdmurray: welcome!
[09:59] <cjwatson> yep, I just need to switch to it - I have local changes so it's not entirely trivial
[09:59] <mdz> glad to hear you'll be attending the sprint next week
[09:59] <cjwatson> I mentioned to bdmurray that he didn't need to give a report this week, of course
[09:59] <bdmurray> mdz: thanks
[09:59] <mdz> seb128,pitti,Keybuk,mvo,doko,Mithrandir,sfllaw,Riddell,iwj,BenC: ping
[10:00] <Riddell> hi all
[10:00] <iwj> Hello.
[10:00] <kwwii> Riddell mentioned that there was a meeting, and I thought i would pop by even though I really don't have much to say (yet)
[10:00] <kylem> mdz, benc is en route to london
[10:00] <mdz> kylem: ah, yes
[10:00] <doko> pong
[10:00] <sfllaw> mdz: Hello.
[10:00] <mdz> pitti is on holiday iirc
[10:01] <cjwatson> yes
[10:01] <tkamppeter> mdz, pong
[10:01] <dholbach> mvo too
[10:01] <mdz> that leaves seb128 and Mithrandir
[10:01] <cjwatson> all three of them
[10:02] <mdz> cjwatson: three of whom?
[10:02] <cjwatson> calendars
[10:02] <cjwatson> canonicaladmin.com, wiki.c.c, google
[10:02] <mdz> ah
[10:03] <mdz> ok, time to get started
[10:03] <mdz> dholbach: would you start us off?
[10:03] <dholbach> Done
[10:03] <dholbach>  * bug triage
[10:03] <dholbach>  * bughelper action
[10:03] <dholbach>  * bughelper meeting
[10:03] <dholbach>  * art builder fixes
[10:03] <dholbach> 
[10:03] <dholbach> Todo:
[10:03] <dholbach>  * GNOME 2.18.0
[10:03] <dholbach>  * distro sprint
[10:03] <dholbach>  * improve art builder
[10:03] <dholbach>  * bug triage
[10:03] <dholbach> 
[10:04] <mdz> I've added a bughelper agenda item for the sprint
[10:04] <mdz> it would be good to familiarize more folks with it
[10:04] <dholbach> ahh nice
[10:04] <Riddell> dholbach: is that the fin;al gnome 2.18?
[10:04] <dholbach> http://wiki.ubuntu.com/BugHelper/Dev/Meetings - for those of you who didn't make it to the meeting
[10:04] <cjwatson> it has been saving a substantial amount of my time, so definitely
[10:04] <mdz> dholbach: 2.18.0 already?
[10:04] <Mithrandir> pong
[10:04] <cjwatson> http://live.gnome.org/TwoPointSeventeen
[10:04] <dholbach> blush
[10:04] <dholbach> of course not
[10:05] <dholbach> 2.17.90
[10:05] <dholbach> lalala
[10:05] <ogra> g-p-m is still behind upstream :(
[10:05] <cjwatson> beta 1 is tomorrow
[10:05] <mdz> :-)
[10:05] <cjwatson> er, tarballs
[10:05] <mdz> dholbach: ok, thanks
[10:05] <dholbach> (and also done: worked with art people on documentation and examples packages)
[10:05] <mdz> tkamppeter: next?
[10:05] <dholbach> he's editing the wiki :)
[10:06] <cjwatson> hi seb
[10:06] <seb128> hi
[10:06] <mdz> dholbach: also added artwork process to the agenda
[10:06] <seb128> sorry I'm late
[10:06] <tkamppeter> yes, I will paste it in ...
[10:06] <dholbach> mdz: alright
[10:07] <mdz> tkamppeter: if you are not ready yet, we can come back to you later
[10:07] <tkamppeter> Done
[10:07] <tkamppeter>  * Documentation correction on new printer driver package SpliX (Samsung laser printers)
[10:07] <tkamppeter>  * Packaged and submitted printer drivers: epsonepl (Epson EPL "L" series, bug #34647), m2300w (Minolta magicolor W series), pxljr (Vast quality improvement for HP Color LaserJet 35xx/36xx)
[10:07] <tkamppeter>  * Updated foo2zjs printer driver package: Now there is also support for the HP LaserJet M1005 MFP, Konica Minolta magicolor 2490MF and 2530 DL
[10:07] <tkamppeter>  * Updated foomatic-db: Marked more drivers obsolete, removed Foomatic data which already comes with driver packages, so less occurences of the problem described in bug #59324
[10:07] <Ubugtu> Malone bug 34647 in foomatic-db "ijs_server_epsonepl not found" [Medium,Fix committed]  https://launchpad.net/bugs/34647
[10:07] <Ubugtu> Malone bug 59324 in foomatic-db "Cups filters are not bundled with Ubuntu altough the PPD are present" [Medium,In progress]  https://launchpad.net/bugs/59324
[10:07] <tkamppeter>  * Updated gs-esp: Replace static binary by one using the libgs-esp library, saving 4.7 MB on installed system, package splitting to allow installation on X-less server
[10:07] <tkamppeter>  * Answered to bug reports
[10:07] <tkamppeter> To do
[10:07] <tkamppeter>  * Prepare Ubuntu for new FHS standard for printer driver and PPD file directories, to prepare for installation of distribution-independent driver packages (LSB 3.2). See http://lists.freestandards.org/pipermail/printing-architecture/2006/001512.html
[10:08] <cjwatson> tkamppeter: have you been catching up on those extra hours as agreed? I don't have e-mail about when you were doing that
[10:09] <tkamppeter> Yes, I think at least a part of the extra hours I ave done with my last actions.
[10:10] <cjwatson> ok, please do let me know which days were involved though, as requested earlier - it's difficult to keep track otherwise
[10:10] <tkamppeter> OK.
[10:10] <mdz> tkamppeter: yes, please sync up with colin after the meeting
[10:10] <mdz> tkamppeter: thank you
[10:10] <cjwatson> thanks
[10:10] <mdz> seb128: next
[10:10] <seb128> Done:
[10:10] <seb128>  bug triage, bug triage, bug triage
[10:10] <seb128>  compiz update
[10:10] <seb128>  bunch of GNOME updates
[10:10] <seb128>  easy-codec-installation: gstreamer part done (snapshots from CVS uploaded, plugin packages updates to use the new dh_gstscancodecs, libgimme-codec uploaded and accepted, new totem has code to use libgimme-codec)
[10:10] <mdz> seb128: and dholbach already told us about GNOME 2.18.0 next week ;-)
[10:10] <seb128>  tracked font bug from customer
[10:10] <seb128> .
[10:11] <seb128> Next week:
[10:11] <seb128>  Distro Team Sprint
[10:11] <seb128>  GNOME 2.17.90
[10:11] <seb128> oh, dholbach rolling GNOME 2.18.0? ;)
[10:11] <seb128> interesting :p
[10:11] <cjwatson> seb128: how much is left from easy-codec-installation?
[10:11] <iwj> seb128: easy-codec-installation> So what's left ?  Can we test/demo now ?
[10:11] <mdz> he just wanted to see if we were paying attention to his update
[10:12] <dholbach> mdz: you always think the best of me :-)
[10:12] <seb128> cjwatson: libgimme-codec only display a message at the moment
[10:12] <seb128> I've to check if gnome-app-install is ready with iwj or mvo
[10:12] <iwj> seb128: Yep.
[10:12] <Mithrandir> the libgimme-codec binaries need to be accepted as well, they're not yet.
[10:12] <seb128> and make libgimme-codec call it
[10:12] <iwj> Although it hasn't really been tested in-situ.
[10:12] <seb128> "not much" left
[10:12] <iwj> I suggest turning it on ASAP so we can debug it together at the sprint.
[10:12] <mdz> iwj: agreed
[10:13] <seb128> iwj: will do that tomorrow
[10:13] <iwj> Excellent, Friday breakage :-).
[10:13] <seb128> ;)
[10:13] <seb128> friday before travelling
[10:13] <seb128> that's better than friday :p
[10:13] <cjwatson> Mithrandir: they are now
[10:13] <Mithrandir> cjwatson: oh, ok.  Goodie.
[10:14] <mdz> ok
[10:14] <mdz> thanks seb128
[10:14] <mdz> ogra: next?
[10:14] <ogra> * last week:
[10:14] <ogra>  - ltsp-manager -> python-ltsp (backend class) nearly done
[10:14] <ogra>  - more edubuntu-network-auth-server work
[10:14] <ogra>  - edgy-plusone-thinclient-sound waits for pulse promotion and libasound2-plugins split
[10:14] <ogra>  - some edulinux server preparations
[10:14] <ogra> * next week:
[10:14] <ogra>  - finish ltsp-manager spec (python-ltsp and gui)
[10:14] <ogra>  - finish edgy-plusone-thinclient-sound
[10:14] <ogra>  - sprint: edubuntu-on-two-cds, edubuntu-network-auth-server, edubuntu-network-auth-client
[10:14] <ogra> * approved specs:
[10:14] <ogra>  - ltsp-fat-clients -no further work
[10:14] <ogra>  - edubuntu-network-auth-server - slow progress
[10:14] <ogra>  - edubuntu-network-auth-client - not started
[10:14] <ogra>  - edgy-plusone-thinclient-sound - ltsp side implemented, alsa plugins missing
[10:14] <ogra>  - ltsp-management-gui - good progess on python modules
[10:14] <ogra>  - student-control-panel-upgrade - front/backend split done by cbx33
[10:14] <ogra>  - edubuntu-on-two-cds - not started (planned for the sprint)
[10:14] <ogra>  - ltsp-persistent-home - ... sbalneav (planned to talk to pitti)
[10:14] <mdz> ogra: feedback from herd 2?
[10:15] <ogra> not much ... i must admit i wasnt around very constant the last 7 days
[10:15] <ogra> sbalneav is just installing it afaik
[10:15] <mdz> ogra: have you been following the testing on the forums that heno arranged?
[10:15] <ogra> apart from that i was the only tester
[10:16] <heno> there have been some volunteers for edubuntu
[10:16] <ogra> yes, but there wasnt much for herd2 yet ... i expect more with herd3, some ppl expressed interest
[10:16] <cbx33> sorry ogra, i will be installing next....herd3
[10:16] <mdz> ogra: ok, there are at least some threads about edubuntu
[10:16] <cjwatson> you probably want to upgrade ubiquity if you're testing the herd2 live CD anyway
[10:16] <ogra> cbx33, its fine, just go on with SCP
[10:16] <heno> some people said they are happy to test any flavour and we should spread those out
[10:16] <cjwatson> there was an embarrassing little bug that broke it if you had any unpartitioned space on the disk
[10:17] <cbx33> ogra I kinda need it for the book ;)
[10:17] <mdz> ogra: checking that forum should be a regular part of each milestone, to get more feedback
[10:17] <cbx33> am emailing you abotu that now :p
[10:17] <mdz> ogra: do you have an account already?
[10:17] <ogra> there is a big carnival party in essen next month, they want to test edubuntu teher
[10:17] <ogra> mdz, indeed
[10:17] <ogra> (the party is driven by the german LoCo)
[10:18] <mdz> ogra: is that nearby?  will you be there?
[10:19] <ogra> sadly its quite a ride and i'll be in italy by the end of the month as well ... not sure yet, but juliux is there
[10:19] <mdz> ok
[10:19] <mdz> thanks ogra
[10:19] <ogra> he's as good as me in promoting edubntu
[10:19] <mdz> Mithrandir: next?
[10:19] <Mithrandir> network-roaming: gnome network-manager bits done, waiting for knetworkmanager
[10:19] <Mithrandir> changelog-closes-bugs: to be done at sprint
[10:19] <Mithrandir> grub2: given over/to be given over to iwj at the sprint
[10:19] <Mithrandir> misc: lots of archive admin: source NEW is under control, SRUs need a bit more time, working on getting a better process for universe SRUs with the MOTUs
[10:19] <Mithrandir> next week: sprint
[10:19] <mdz> Mithrandir: seeded network-manager?
[10:19] <Mithrandir> mdz: not yet.
[10:19] <mdz> Mithrandir: what remains before that can be done?
[10:20] <Riddell> Mithrandir: knetworkmanager is in
[10:20] <Mithrandir> Riddell: ok, good.
[10:20] <Mithrandir> nothing, then
[10:20] <mdz> Mithrandir: tomorrow is breakage day ;-)
[10:20] <Mithrandir> hooray!
[10:20] <Mithrandir> I'll do it tomorrow morning, then
[10:20] <mdz> Mithrandir: any notable issues with herd 2 which we can aim to improve next time?
[10:21] <Mithrandir> we need another colin to maintain ubiquity since it seems there are a bunch of problems there. :-(
[10:21] <mdz> cjwatson: do you concur?
[10:22] <cjwatson> I'd love another me for all kinds of reasons
[10:22] <mdz> cjwatson: we can get that ball rolling very quickly if necessary
[10:22] <mdz> well, not another you, but someone for ubiquity
[10:22] <Mithrandir> apart from that, it was a decent snapshot, herd 3 is going to be fun, I suspect.
[10:23] <cjwatson> I want to continue working on ubiquity, but I cannot disagree that another pair of hands would be a great help
[10:23] <mdz> cjwatson: please add a note to the sprint agenda to discuss it in person
[10:23] <cjwatson> ok
[10:23] <mdz> Mithrandir: thanks
[10:23] <mdz> doko: next
[10:23] <doko> this week:
[10:23] <doko>  - update to python 2.5; all packages converted/updated/new upstreams
[10:23] <doko>    and built for main, to a large part for universe as well.
[10:23] <doko>    python2.4 will be kept in main for zope2.x and zope3.
[10:23] <doko>  - use hunspell instead of myspell in main (OOo, firefox).
[10:23] <doko>  - other: OOo updates, looking at the fc gcj backport, eclipse
[10:23] <doko>    linux-distro meeting, printing packages reviews, twisted updates,
[10:23] <doko>    sun-java updates.
[10:23] <doko>  - will be offline tomorrow (meet a python upstream guy in Potsdam
[10:23] <doko>    for a packaging/2.5 chat).
[10:23] <doko> next week:
[10:23] <doko>  - distro sprint
[10:24] <cjwatson> mdz: done
[10:24] <mdz> doko: python2.5 seemed to go smoothly. so the -central/-support infrastructure is working well?
[10:24] <cjwatson> doko: tomorrow morning, yes? as agreed earlier
[10:24] <doko> mdz: yes, most problems were hardcoded versions in debian/* and 64bit fixes
[10:25] <doko> cjwatson: yes
[10:25] <doko> will be back around lunch
[10:25] <mdz> doko: good to hear
[10:25] <mdz> doko: does the hunspell change allow us to drop anything from the CD or default install?
[10:25] <mdz> (or language-support)
[10:25] <cjwatson> I've suggested that the next priority for feisty-python-roadmap is debug builds
[10:26] <cjwatson> though that's not as straightforward as it might first appear
[10:26] <doko> yes, libmyspell*; but not yet from main (the dictionaries b-d on libmyspell-dev)
[10:26] <mdz> excellent
[10:26] <doko> cjwatson: yes, that's one thing I have in mind for tomorrow's talk
[10:26] <mdz> doko: let pitti know so that he can update -support
[10:27] <cjwatson> doko: right
[10:27] <doko> mdz: -support update?
[10:27] <mdz> doko: language-support-en depends on myspell dictionaries
[10:27] <mdz> shouldn't that be changed?
[10:28] <doko> mdz: no, hunspell is the next version of myspell; the dictionaries do have the same format
[10:28] <mdz> oh, hunspell uses myspell dictionaries
[10:28] <mdz> ok
[10:28] <mdz> doko: thanks
[10:28] <mdz> iwj: next
[10:29] <iwj> automated-testing-deployment: The meat of the new code is written and needs testing.  Currently blocked on the Xen in feisty.
[10:29] <iwj> gnome-app-install-codecs: The g-a-i part is now deployed (thanks mvo).  AIUI seb is working on the higher layers, and then we can test it.  This tangle will probably need debugging and we should do that at the sprint.
[10:29] <iwj> winmodem-support: Had a good conversation with mjg59 after last week's meeting; no change since then.  I need to acquire an AMR (ac97-based) modem card I think.
[10:29] <iwj> consistent-login-screen: No progress recently.  However I have been invited by mdz to a conference call on the 30th of January about xgl, compiz, and consistent-login-screen.
[10:29] <iwj> also done: gs-esp crash bug (manifested on sparc) for fabbione.  I wish the upstream gs zoo would hurry up and get themselves re-unified.
[10:29] <iwj> also done: started writing down a spec for dpkg triggers; this will fix various O(n^2) performance problems in upgrades, but we have to discuss and agree with Debian so this should start now rather than doing the design work at the feisty+1 UDS.
[10:30] <cjwatson> triggers++
[10:30] <mdz> iwj: what's the issue with Xen?
[10:31] <iwj> Xen> Well, two things: one is that the xen-3.0-utils are uninstallable due to a problem with libvncserver-dev.
[10:31] <iwj> I think I've managed to unblock that now.
[10:31] <iwj> And the other is that the kernel and new hypervisor are still in progress AIUI.
[10:31] <doko> iwj: do we keep gs-esp 8.15 for feisty?
[10:31] <mdz> can it not be deployed on an Edgy host?
[10:31] <tkamppeter> iwj, Mike Sweet has already set up a roadmap about the unification of the GhostScripts, several weeks ago.
[10:32] <iwj> doko: I'm tempted to reprioritise the alternatives to make the default be gs-gpl.
[10:32] <iwj> And keep gs-esp for the moment.
[10:32] <tkamppeter> He wants to close ESP with a last bugfix release 8.15.4 and then he wants to start merging on his Subversion repository.
[10:32] <iwj> tkamppeter: Oh, good.  Do you have some references for that ?  It would be very nice.
[10:32] <iwj> tkamppeter: Excellent.
[10:32] <cjwatson> iwj: kernel> unlikely to reach 2.6.20 thoug
[10:32] <cjwatson> h
[10:33] <mdz> sounds like we should stay with -esp for feisty and plan to switch after
[10:33] <doko> tkamppeter: will you make the gs/gs-x11 split for gs-gpl as well?
[10:33] <tkamppeter> The upstream GS folks have already given write access to me and to mike.
[10:33] <iwj> mdz: we have gs-esp 8.15 but gs-gpl 8.54, so it's not clear that sticking with gs-esp as default is the right thing now.
[10:33] <tkamppeter> Unfortunately, we talked about that only in private mail, so there is nothing on the web about that.
[10:34] <iwj> tkamppeter: Aha.
[10:34] <mdz> iwj: but there are many changes in gs-esp relative to -gpl which would be lost, no?
[10:34] <iwj> mdz: Well, the same changes are often pushed into both trees, generally with the gs-gpl getting them after gs-afpl.
[10:35] <tkamppeter> If you simply use the current GPL GhostScript as default, you will loose a lot of the built-in printer drivers, or you do a patch nightmare as distros did formerly.
[10:35] <iwj> And (cough) not all of the gs-esp changes are always entirely correct.
[10:35] <iwj> tkamppeter: OK.  I'll take your advice.
[10:35] <mdz> ok
[10:35] <mdz> iwj: thanks
[10:35] <mdz> kylem: next
[10:35] <kylem> Done:
[10:35] <kylem>   * dapper-proposed security updates uploaded
[10:35] <kylem>   * Security updates for dapper
[10:35] <kylem>   * Investigated sparc64-ssl-accelerator
[10:35] <kylem> In Progress:
[10:35] <kylem>   * Trying to play catch-up with my bugs folder
[10:36] <kylem>   * More Security updates for edgy & dapper
[10:36] <kylem>   * MODULE_FIRMWARE annotations for feisty
[10:36] <kylem>   * Cataloguing Intel hardware
[10:36] <kylem>   * Sorting out necessities for FeistySprint
[10:36] <kylem> Todo:
[10:36] <kylem>   * Talk to Dave about Niagara MAU
[10:36] <kylem>   * Find fix for mpt fusion RAID devices for dapper
[10:36] <doko> kylem: please fix the atheros driver for the sprint ;)
[10:36] <kylem> doko, should be in the lrm upload ben will do tomorrow.
[10:37] <mdz> kylem: how are kernel bugs being handled at the moment?
[10:37] <iwj> mdz: automated-testing-deployment, edgy> If there's not a working xen in feisty by after the sprint then yes, I'll do that.
[10:37] <mdz> kylem: are bugs reported against 2.6.17 being rechecked with 2.6.20?
[10:37] <mdz> kylem: is there a list of kernel regressions from edgy to current feisty?
[10:38] <kylem> mdz, mostly yes, i mostly just poll through the list of dapper/edgy bugs a few times a day.
[10:38] <mdz> kylem: how is it done? do you add a linux-source-2.6.20 task to the bug and ask the reporter to test?
[10:38] <kylem> mdz, not that i'm aware of, ben's mostly had me focusing on looking after dapper/edgy.
[10:39] <mdz> kylem: it's a rather long list and we ought to be rigorous about tracking progress across kernel versions
[10:39] <kylem> mdz, most of the bugs have already had the -2.6.20 (or .19 in most cases) added, so i just follow up.
[10:39] <kylem> yeah, i have a bookmarks folder high priority bugs (mostly hw feature regressions)
[10:39] <kylem> i've been thinking using a wiki page on wiki.c.c for tracking them instead.
[10:40] <kylem> esp when they come from support
[10:40] <mdz> kylem: either tags or milestone targets would be better than a wiki page
[10:40] <mdz> kylem: maybe a good subject for discussion at the sprint with BjornT, how best to track those
[10:41] <dholbach> kylem: if you have an idea, how automated searches (bughelper) might fit in there, let's talk about that
[10:41] <kylem> mdz, ok. yeah, definitely something we should discuss, there's *a lot* of bugs, it's extremely difficult to stay on top of eerything.
[10:41] <mdz> kylem: ok, thanks
[10:41] <kylem> dholbach, ok
[10:41] <mdz> fabbione: next
[10:41] <fabbione> Done:
[10:41] <fabbione> * -support/-certification: tracked bunch of bugs around.
[10:41] <fabbione> * sparc64-64-bit-apps: fixed glibc sparc64 libpthread linking moved to -updates.
[10:41] <fabbione> * tracked X bugs with seb and simon
[10:41] <fabbione> * sparc64-niagara-ssl-accel: delegation in progress.
[10:41] <fabbione> * integrity-check: to be delegated.
[10:41] <fabbione> Todo:
[10:41] <fabbione> * Oslo
[10:42] <mdz> fabbione: is there a tag where I can see the bugs from certification?
[10:42] <fabbione> (i just got 3 more bugs from certification to look at)
[10:42] <fabbione> mdz: i gave you the url to the team.. we subscribe the team to all bugs
[10:42] <fabbione> i don't think we are using a specific tag for them
[10:43] <mdz> fabbione: I overlooked the URL, I see it now, thanks
[10:43] <Mithrandir> but you also mark all of the bugs private so they're useless for me as an RM.
[10:43] <fabbione> mdz: no problem
[10:43] <mdz> fabbione: only 3 bugs there currently
[10:43] <fabbione> Mithrandir: we do subscribe people that need to know
[10:43] <jbailey> Mithrandir: The bugs need to be private as they might contain customer data.
[10:43] <fabbione> mdz: yes.. opened 10/20 minutes ago.. still to look at them
[10:43] <cjwatson> if they're high priority, it's appropriate for the RM to be aware of them, I think
[10:44] <jbailey> I'm not fussed about people within Canonical. =)
[10:44] <mdz> fabbione: they should only be private if they do/will contain customer data
[10:44] <mdz> certification bugs especially should not be private
[10:44] <Mithrandir> jbailey: I'm just pointing out that private bugs which I don't have access to will not show up on my radar and therefore won't be considered when doing release management.
[10:44] <sfllaw> mdz: What about pre-release hardware?
[10:44] <fabbione> mdz: certification hw is not all public
[10:44] <fabbione> mdz: but i agree that we can make some of them open
[10:45] <sfllaw> jbailey: Are there NDAs involved with certification?
[10:45] <mdz> sfllaw: if the code is public, then surely the bugs can be as well
[10:45] <fabbione> mdz: not if found on some hw...
[10:45] <Mithrandir> I also think that on principle, we should try to make all bugs public.  Of course not those containing confidential customer data, but it's often trivial to anonymise the data anyway.
[10:45] <jbailey> sfllaw: I don't know.  All that's handled before the boxes get here.  I'd be surprised if there wasn't, though.
[10:45] <mdz> I'm not aware of any hardware where it needs to be a secret that we have it
[10:46] <jbailey> sfllaw: Best to refer the question to Maria.
[10:46] <kylem> it's going to come up in the future
[10:46] <sfllaw> mdz: Wasn't that whole SFO thing hush-hush?  I know we were told to keep quiet about it in Montreal.
[10:46] <kylem> but we should probably discuss that seperately
[10:46] <mdz> sfllaw: that's a customer matter.
[10:46] <fabbione> exaclty
[10:46] <sfllaw> kylem: Agreed.
[10:46] <fabbione> let's discuss about it offline
[10:46] <Mithrandir> put it on the Oslo agenda?
[10:47] <mdz> sfllaw: if Ubuntu fails to install on a Dell PC in the certification lab, that bug needs to be public.
[10:47] <fabbione> Mithrandir, cjwatson; one of my tasks is to keep you informed on these bugs and their status.. so don't worry too much
[10:47] <fabbione> Mithrandir: good idea
[10:47] <mdz> the people with the answers we need won't be there
[10:47] <mdz> I'll follow up on this
[10:48] <cjwatson> fabbione: this is pointing out a flaw in the existing process, not worrying
[10:48] <Mithrandir> fabbione: I need to have them show up on my radar.  Having you tell me about them in any way which is not malone means it does not show up on my radar.  I can't keep lists of bugs in different places.
[10:48] <cjwatson> please take it as such
[10:48] <mdz> jbailey: you, Maria, Marc, Fabio...anyone else who should be in that conversation?
[10:49] <mdz> fabbione: thanks for the update
[10:49] <mdz> sfllaw: next
[10:49] <fabbione> cjwatson: yes.. i do understand what you mean.. it was not to tear apart RM request.. but to talk about it next week
[10:49] <sfllaw> Done
[10:49] <sfllaw>  * Interns have started
[10:49] <sfllaw>  * Hug Day
[10:49] <sfllaw>  * SRUs: tzdata, glibc
[10:49] <sfllaw> To do
[10:49] <sfllaw>  * Assign some work to interns
[10:49] <sfllaw>  * Talk about ISO testing with lifeless in Oslo
[10:49] <sfllaw>  * Talk about support escalation with fabionne
[10:49] <sfllaw>  * SRU: gnome-vfs2, gnome-system-tools
[10:49] <sfllaw>  * Bug triage
[10:49] <sfllaw> Bug stats:
[10:49] <sfllaw>  * Open (20919) +48 over last week
[10:49] <sfllaw>  * Critical (23) +3 over last week
[10:49] <sfllaw>  * Unconfirmed (10581) -50 over last week
[10:49] <sfllaw>  * Unassigned (15888) +78 over last week
[10:49] <sfllaw>  * All bugs ever reported (71790) +1290 over last week
[10:50] <seb128> 1290 bugs a week, utch
[10:50] <cjwatson> whoa, I assume that's the result of herd 2
[10:50] <cjwatson> but ouch
[10:50] <sfllaw> I have a funny twitch in my shoulder now.  :)
[10:50] <mdz> now seems like a good time to introduce bdmurray :-)
[10:51] <dholbach> hello bdmurray - please save us! :-)
[10:51] <Riddell> hi bdmurray
[10:51] <ogra> hi bdmurray
[10:51] <sfllaw> bdmurray: Good thing you're on Ubuntu QA.
[10:51] <sfllaw> bdmurray: Welcome again.
[10:51] <mdz> Brian is joining the team at Canonical to help us handle bugs
[10:51] <bdmurray> Thanks, I'm glad there isn't any pressure.
[10:51] <seb128> Rock on!
[10:51] <seb128> bdmurray: welcome on board ;)
[10:51] <kylem> awesome! welcome bdmurray!
[10:51] <dholbach> bdmurray: welcome! :-)
[10:52] <cjwatson> bdmurray: good to have you on board
[10:52] <mdz> he will be at the sprint next week for introductions and training
[10:52] <mdz> he reports to Colin
[10:52] <mdz> and while we're on the subject, I bring your attention to kwwii as well
[10:53] <Riddell> kwwii of bling
[10:53] <mdz> who is joining Scott's team to take responsibility for artwork
[10:53] <mdz> he'll also be at the sprint, though many of you already know him
[10:53] <sfllaw> kwwii: Welcome back!
[10:53] <fabbione> kwwii: sushi dude!
[10:53] <kylem> welcome!
[10:53] <ogra> kwwii, does that mean for edubuntu and and ubuntu as well ?
[10:53] <kwwii> see lot's of you (again) soon
[10:54] <kwwii> ogra: yeah, I guess so, although I am sure I'll find out more soon
[10:54] <ogra> great
[10:54] <seb128> I knew he was a GNOME dude :p
[10:54] <kwwii> lol
[10:54] <kwwii> I installed gnome twice today
[10:54] <ogra> yeah, we all knew it
[10:54] <Mithrandir> kwwii: does this mean I can whine at you about not having any updated artwork yet? :-)  FF is getting closer.
[10:55] <mdz> ok, group hugs can wait until next week.  time to move on
[10:55] <mdz> sfllaw: thanks
[10:55] <mdz> Riddell: next
[10:55] <Riddell> done: most of KDE 3.5.6 packaged, waiting on upstream release to upload
[10:55] <Riddell>       network-roaming: knetworkmanager patched for static config
[10:55] <Riddell>       kubuntu-update-manager: UI done, but blocked on getting embedded konsole to work with forkpty, mvo work on that looking promising
[10:55] <Riddell>       kubuntu-feisty-adept-changes: changes needed for update-manager done but needs testing, thanks to praetor), main/universe notification in (thanks to manchicken)
[10:55] <Riddell> todo:
[10:55] <Riddell>       finish KDE 3.5.6
[10:55] <Riddell>       kubuntu-update-manager main target for oslo
[10:56] <mdz> Riddell: you have a few other specs on your list
[10:57] <mdz> kubuntu-feisty-kde4-plan and kubuntu-feisty-ubiquity are high priority
[10:57] <Riddell> kde4 plan is waiting on the next KDE 4 release, it's expected in january but it's not timetabled
[10:58] <Riddell> ubiquity is waiting to see what will be done in gtk side, partitioner, migration assitant, slideshow
[10:58] <cjwatson> kubuntu-feisty-ubiquity has made decent progress
[10:58] <cjwatson> there's trivial stuff there that could be done in advance of gtk though
[10:58] <cjwatson> hmm, although not really all that much of importance, on a quick review
[10:59] <cjwatson> kwwii: we need to talk next week about ubiquity-slideshow
[10:59] <kwwii> cjwatson: great
[10:59] <mdz> Riddell: ok, plenty of opportunity to talk about it at the sprint
[10:59] <mdz> Riddell: thanks
[10:59] <mdz> heno: next
[11:00] <heno> * bughelper - ducumentation and feature brainstorming
[11:00] <heno> * ubiquity triage - not much this week
[11:00] <heno> * accessibility - gnome-mag got a few upgrades (thanks Daniel!), new espeak and gnome-speech driver released upstream, worked on Karlsruhe presentation
[11:00] <heno> * ISO testing forum - Testing hs continued in the forums after Herd 2. Trying to bring some more structure to it.
[11:00] <heno> * launchpad - Steve requested that we try using the beta UI and give feedback
[11:01] <mdz> heno: not much ubiquity because there weren't many reports, or because you were working on other things?
[11:01] <mdz> if the former, that'd be great news given herd 2
[11:01] <cjwatson> there were quite a few, but practically every new one was the partitioner bug I mentioned
[11:01] <cjwatson> I've been hoovering up most of those with the aid of bughelper
[11:02] <heno> because I was working on other things and cjwatson took all the low hanging fruit :)
[11:02] <heno> so I have to raise my game
[11:02] <cjwatson> I needed to review most of those anyway to ensure that I wasn't missing some other property of that bug
[11:03] <mdz> sounds good
[11:03] <heno> the forum testers did actually run into them quite often
[11:03] <cjwatson> about the only other thing was that the popcon checkbox doesn't actually work
[11:03] <mdz> heno: I added an agenda item for the sprint to talk about how to crunch the forum feedback and filter bugs into launchpad, etc.
[11:03] <heno> mdz: sounds good
[11:04] <mdz> heno: thanks
[11:04] <heno> I'm reading up on text data mining now :)
[11:04] <mdz> heno: maybe send something to distro-team about beta and how we can/should use it
[11:04] <mdz> cjwatson: you're up, and then we're done
[11:04] <heno> bughelper you mean?
[11:04] <cjwatson> setup-console-under-usplash: Investigated kernel font setting code and concluded that the situation is hopeless as far as getting this to work reliably under X/usplash is concerned. Backed out that part of the previous changes. I've scheduled an item for the sprint to thrash out another idea, namely doing it in the initramfs.
[11:04] <mdz> heno: beta
[11:04] <cjwatson> intel-mac-support: Picked up hardware and started work. Making fairly decent progress. Almost ready to test partitioner/bootloader changes and beat on Ubiquity. Need to fix mouseemu, which seems to just block all mouse input.
[11:05] <cjwatson> hoping to find some time somewhere at the sprint to go through the lagging ubiquity work
[11:05] <mdz> heno: is there anything other than "use it"?  under what circumstances?  any caveats?
[11:06] <cjwatson> aside from that, promising recruitment progress on a couple of fronts
[11:06] <mdz> indeed
[11:06] <mdz> cjwatson: anything else?
[11:06] <cjwatson> that's it
[11:06] <mdz> ok, that's a wrap
[11:07] <iwj> Only 6 minutes over.  Well done everyone :-).
[11:07] <doko> ohh, anybody interested in a cocktail session at the sprint?
[11:07] <mdz> look for sprint agenda updates over the next few days
[11:07] <mdz> and I'll see you next week
[11:07] <kwwii> see everyone soon
[11:07] <iwj> doko: Oooh, could do.
[11:07] <kylem> cheers.
[11:07] <dholbach> doko:  :-)
[11:07] <sfllaw> Ta.
[11:07] <iwj> But I'm off to the pub now so talk about it some other time :-).
[11:07] <iwj> Goodnight everyone.
[11:08] <dholbach> night everybody
[11:08] <fabbione> doko: you bet.. but you get to pay for it :P
[11:08] <fabbione> night guys