ompaulogra, night ;-)00:00
stgraberompaul: ogra is a bot, he doesn't need to sleep.00:02
ompaulstgraber, he just needs to smoke and organise flash hugs ;-)00:02
ograno i pushed my cmpc release candidate yesterday ... i feel useless now00:02
stgraberompaul: yeah :)00:02
stgraberogra: go to #ltsp, lots of work there :)00:02
ograyeah, on my list :)00:03
=== ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 06 Aug 20:00 UTC: Maryland LoCo IRC | 07 Aug 12:00 UTC: Ubuntu Mobile Team | 07 Aug 14:00 UTC: Ubuntu Java Team | 08 Aug 00:00 UTC: Americas Board | 08 Aug 04:00 UTC: Ubuntu MOTU | 14 Aug 12:00 UTC: Ubuntu Mobile Team
=== t is now known as tomaw__
=== tomaw__ is now known as t
=== ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 06 Aug 20:00 UTC: Maryland LoCo IRC | 07 Aug 12:00 UTC: Ubuntu Mobile Team | 07 Aug 14:00 UTC: Ubuntu Java Team | 08 Aug 00:00 UTC: Americas Board | 08 Aug 04:00 UTC: Ubuntu MOTU | 08 Aug 15:00 UTC: Ubuntu Release
=== ApOgEE- is now known as apogee-x
=== Rafik_ is now known as Rafik
=== dholbach__ is now known as dholbach
=== thekorn_ is now known as thekorn
=== doko_ is now known as doko
pedro_hello everybody!17:58
* pedro_ hugs nxvl18:00
pedro_nxvl: nice MOTU video ;-)18:00
nxvlpedro_: thanks18:00
henowelcome everyone!18:00
MootBotMeeting started at 12:04. The chair is heno.18:00
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]18:00
heno[TOPIC]: Post Hardy.1 SRU verifications - help needed18:01
MootBotNew Topic: : Post Hardy.1 SRU verifications - help needed18:01
henoThere are quite a few SRUs in need of verification in both main and universe18:01
henohttp://people.ubuntu.com/~sbeattie/sru_todo.html and http://people.ubuntu.com/~ubuntu-archive/pending-sru.html18:02
MootBotLINK received:  http://people.ubuntu.com/~sbeattie/sru_todo.html and http://people.ubuntu.com/~ubuntu-archive/pending-sru.html18:02
sbeattieand that's after a number have already gone through.18:03
henoI actually think we should question whether all these are SRU-worthy18:03
henowhether they really meet the serious breakage or regression criteria18:03
LaserJockwell, it's not really the QA teams decision exactly18:04
LaserJockbut perhaps we can do some sort analysis to help the SRU teams decide better18:04
henoBut we have a voice in that18:04
DktrKranzheno, SRU policy changed a bit, even small patches can become a SRU nowadays (as per wiki.u.c/SRU page)18:04
henowe should encourage thouse guidelines to be followed18:04
LaserJockI personally think QA efforts might be most useful in poking people in these situations18:05
LaserJockgetting 2 + votes should not be difficult18:05
henoright. I'll ask around a bit and report back18:06
henoin the meantime it would be great to have help in checking these18:06
sbeattieSome of the ones, particularly update-manager, have ppc specific issues (the move from being a supported platform to ports)18:06
LaserJockyou should have at least the original reporter and sponsor18:06
persiaI think that a QA voice in SRU would certainly help: both SRU teams seem overburdened by the current processes (from an external perspective)18:06
henoI suspect it mostly comes from work that just missed the Hardy.1 deadline18:07
pedro_sbeattie: is that bug marked as hw specific ?18:07
persiaMaybe, but lots of people doing SRU weren't paying attention to Hardy.118:07
ScottKHardy.1 is not relevant to Universe.18:08
sbeattiepedro_: they're not, I was wondering actually whether to.18:08
ScottKpersia: I agree about overburdening.  I was not able to keep good situational awareness on what I should pay attention to and be effective.  One reason why I quit motu-sru.18:09
henoScottK: true, and many of them pre-date .118:09
LaserJockI'll blog a "QA wants you!" today for the SRU verifications18:09
sbeattiepedro_: or to have a specific ppc tag.18:09
henoLaserJock: great!18:09
henoLaserJock: could you mail the devel list as well?18:09
LaserJockheno: will do18:10
henomoving on18:10
DktrKranzin the past, MOTUs wrote mails on ubuntu-motu about -proposed updates to be tested, I don't think they were useful, but gave a little more attention to the SRU process.18:10
henoI'm going to switch topics 2 and 3, which seems to make sense here18:10
heno[TOPIC]: Introducing Tom Berger (intellectronica) - Launchpad Bugs contact18:11
MootBotNew Topic: : Introducing Tom Berger (intellectronica) - Launchpad Bugs contact18:11
intellectronicahi everyone18:11
henointellectronica: are you here?18:11
arahey intellectronica18:11
tuxmaniacintellectronica: nice nick :-)18:11
davmor2hello :)18:11
LaserJockintellectronica: hi18:11
cr3intellectronica: hey dude! welcome to our world :)18:11
henoTom accepted my invitation on short notice, thanks!18:11
sbeattieintellectronica: welcome!18:11
intellectronicatuxmaniac: cheers. bonus points if you know where it's from ;)18:11
pedro_hey intellectronica welcome ;-)18:11
henoHe's a developer on the LP bugs team18:12
intellectronicathanks, everyone, for the warm welcome18:12
henointellectronica: care to expand a bit on that?18:12
cr3He's also worked on Blueprints which are really cool!18:12
intellectronicastarting this month, a major part of my role as part of the launchpad team, and in particular as part of the malone team, would be to work with ubuntu and the qa team to make sure that launchpad serves their needs and that questions and requests are easy to communicate18:13
henogreat, which brings us to:18:14
persiaWonderful news indeed!18:14
intellectronicathat means that in many cases i will be working directly on parts of launchpad that concern your work, but more importantly, it means that i am always available for you18:14
heno[TOPIC]: LaunchpadBugsFeaturePriorities - call for input.18:14
MootBotNew Topic: : LaunchpadBugsFeaturePriorities - call for input.18:14
henosee https://wiki.ubuntu.com/QATeam/LaunchpadBugsFeaturePriorities18:15
henothanks to everyone who has provided feedback so far18:15
henointellectronica: note the two additional items18:15
henowe also separated out the HWDB stuff as there is a dedicated person working on that18:16
LaserJockintellectronica: awesome! thanks18:16
intellectronicaheno: noted, though both are quite general, and are indeed on the general list of things we want to achieve in the coming period18:16
henointellectronica: have the general lists been published?18:17
ScottKintellectronica: Current performance is a real killer.18:17
henoor are there plans to?18:17
cr3the hwdb stuff is being worked on with abel and I understand that bjorn is open to discussions on this topic18:17
intellectronicaspecifically, regarding speed, please feel free to bug me if you feel that something isn't fast enough. more often than not we wouldn't notice until it actually times out18:17
ScottKintellectronica: Generally LP web U/I is so slow it's practically unusable.18:18
henowe probably work with bugs differently than most projects, often opening hundreds in a day18:18
henowhich is why performance is such an issue18:18
intellectronicaScottK: i guess that's more true for ubuntu, which has very big sets of bugs to work with18:18
LaserJockintellectronica: more true for Ubuntu than for what?18:19
intellectronicaScottK: again, the best way for you to help us remedy this is by pointing out specific cases (even if there are many of them)18:19
intellectronicaLaserJock: more true for ubuntu than for smaller projects18:19
henoLaserJock: smaller projects that use LP18:19
LaserJockoh, I see18:19
* LaserJock was confused for a sec18:19
pedro_intellectronica: there's an always reproducible timeout when you select "Show bugs that are not known to affect upstream" is that known?18:19
ScottKintellectronica: I don't know of any cases that aren't. When it takes the database 4 seconds just to find the data for a single page, it's far to slow.18:19
henoand for people who look at few bugs, whereas QA people tend to look at lots18:20
intellectronicapedro_: it is known and a fix is being worked on18:20
pedro_intellectronica: great, thanks!18:20
* ScottK decides to go back to $WORK before he gets some momentum on the topic and makes intellectronica feel unwelcom.18:20
pedro_regarding the speed i don't have issues with that18:21
henoIt may be that APIs+Leonov will help many people here18:21
pedro_bugzilla takes more time to load anyways18:21
pedro_and lp its way better to show pages with hundreds of bugs on it than bugzilla18:21
pedro_but that's just me maybe18:21
henoa web app will always be slower than a real one18:21
pedro_yes yes yes18:22
pedro_but indeed having some more tweaks there would be great18:22
henoany other comments on the list other than speed?18:22
intellectronicaactually, i think that in this cases the slowness usually comes from the database. there are efforts to move to a better scalable architecture, but in the meantime, the best we can do is look at specific cases under the microscope and try to optimize them18:22
davmor2Work fine for me :)18:23
araI think that the tag policy should be prioritize18:23
araright now it is only pri 13 of the list18:23
ScottKTags are a lost cause.18:23
cr3intellectronica: I really like how landscape designed their backend to scale across multiple databases instead of relying on one single database18:23
arabut they are extremely helpful when used correctly18:23
ara(or sort of)18:24
LaserJockbroadly, I think it's valuable to try to help people to create/make higher quality bug reports18:24
henoara: ok, noted18:24
intellectronicacr3: yes, we're learning and adopting a lot from how landscape is doing things18:24
henooh ara: you also have to suggest something that should have its priority decreased ;)18:25
henoare complete activity logs really a #4 when we get the APIs?18:26
cr3intellectronica: I want to bear gustavo's children :)18:26
LaserJockI think so, personally18:26
LaserJockI was tempted to put it #118:26
henoI assume the item here is about the web version18:26
LaserJockbut it's more for me than for general users18:26
LaserJockheno: I think it would apply for both actually18:26
bdmurrayHaving package assignment in the activity log would be useful18:27
sbeattieintellectronica: was wondering if there's any support amongst the user base for additional first class elements; for example the elements in https://wiki.ubuntu.com/Bugs/Description18:27
LaserJockthe API may not give all the activity log either, I'm not sure18:27
LaserJockI've just seen a number of bugs that clearly had a history, but the activity log is blank18:27
sbeattiehaving the activity log be useful as an audit log of operations performed would be very useful.18:27
intellectronicasbeattie: not that i know, but if there's a need we should discuss it18:27
LaserJockand that's very frustrating when trying to put the history together or trying to see who did what18:28
intellectronicaLaserJock: the api currently doesn't expose bug activity log (or bug searching, or bug filing). but it will very soon18:28
ScottKI don't understand why not losing history is a "feature".  It's a bug and they should fix it.18:28
arai am back18:28
LaserJockfor instance, for SRU tracking, we'd like to know who approves the SRU or changes the status18:28
LaserJockhaving a good ways of getting complete history is important18:29
sbeattieintellectronica: in particular, I'd like to see testcase as a first class element, perhaps as an attachment type, to make automatically pulling them out easier.18:29
intellectronicaas you can see, fixing the activity log is something we worked on speccing and estimating. it's quite expensive in terms of effort, but i personally am very much in favour of prioritizing it high18:29
intellectronicasbeattie: that's an interesting idea (extending the list of attachment types). maybe that's the way to do that18:30
henook, there seems to be consensus around that18:30
intellectronicasbeattie: for other types of metadata attachments would be less aprropriate, though18:31
henoin fact, let's go through the top 5 from 'my version' of the list and get views18:31
cr3intellectronica: extending it to what types exactly?18:31
heno#1 Package-specific reporting guidelines18:31
intellectronicacr3: test case, for example18:31
cr3sbeattie: test cases as bug attachments would be awesome. would you distinguish test steps from test scripts?18:31
henoMy aim there is to improve new reports being filed18:32
cr3heno: do you think reporting test cases would help improve that?18:32
araI think that improving new reports is the key point, the welcome email to new reporters is a great idea18:32
araand easy to implement18:33
ScottKI don't understand why that isn't just part of the signup process.18:33
LaserJockI don't get the point of th email to new reporters18:33
henocr3: it may be a bit advanced for filers18:33
LaserJockLaunchpad *should* be self-descriptive18:33
cr3hm, so I think that test cases would be an awesome idea but I think it would only be interesting to a minority of people out there, so perhaps concentrating on the welcome email to reach the larger masses would be time better spent18:33
intellectronicaLaserJock: i think it's a good way to get the attention of new bug reporters and introduce them to the process18:33
LaserJockintellectronica: I would submit that if that's needed something else is wrong18:34
henoThe idea is that you would get an email the first time you file on a given package with info on how to better file bugs on it18:34
henoand info about what will happen next18:34
LaserJockoh good lord, on every package?18:34
ScottKheno: Why isn't that in the U/I?18:34
cr3heno: oh, a different email on a per package basis!? interesting...18:34
intellectronicai'm not sure doing this for every package makes sense. i would do this for ubuntu globally18:35
henoScottK: because people don't read web pages ;)18:35
araand maybe for some packages like firefox18:35
LaserJockpeople don't read email either18:35
ScottKheno: They aren't going to read the mail either18:35
cr3intellectronica: I think heno would have a few key packages in mind18:35
henothat could be18:35
persiaI think a per-package thing is more interesting in the UI.  A per-project thing might be interesting in email.18:35
persiaI certainly don't want to get a new email for every bug I file (I very rarely file two bugs in the same package)18:35
intellectronicacr3: right, as long as we restrain ourselves so that we don't become abusive to our users18:36
cr3persia: you would only get an email the first time you report a bug against a specific package18:36
LaserJockI could see giving an email with useful wiki pages (we have quite useful documentation in the BugSquad) on first filing18:36
henoso if we keep guided filing at #1 we should demote the email one which is similar?18:36
persiacr3: Which for me, is likely to be every bug I file.18:36
persiaI much prefer guided bug filing as a solution to that problem.18:36
LaserJockpersia: yeah, that would be big-time spam18:36
ScottKPersonally I think sending mail to tell me something you could have put on the web page I was at when I didn't ask for the mail borders on abusive.18:37
henoOK, I'll demote that as I seem to be the only supporter of it :)18:37
heno#2 Duplicate-detection inside launchpad18:37
henothat should make triage easier18:37
LaserJockI like it, but think other things should be higher than it18:38
henothis is basically using the new-bug-filing dupe-finder on exisiting bugs18:38
LaserJockit sort of depends on how well the dup detection works18:38
araLaserJock:  it works pretty well18:39
henowhat do triagers think?18:39
sbeattieOne of the use cases which makes ubuntu a different user of launchpad than most projects hosted on it, is that it is an aggregation of packages, and subgroups of those packages could/would be useful (weather report, per package bug filing info)18:39
araI use a fake new report sometimes to look after dups18:39
ScottKI guess I don't understand why if the dupe finder could find it, it isn't already found.18:39
pedro_could it be also look into the summary and not only in the title? (which is what's currently the dup-finder is doing)18:39
LaserJockone of the things I'm concerned about with it what is done once a dup is detected?18:39
LaserJockif we have to go back and retriage dups then I'm not sure how much we save18:40
intellectronicaScottK: the only case is where the bug reporter ignored it18:40
persiaPerhaps if the UI offered a clickable list of possible dupes when selecting a duplicate, rather than just asking for entry?18:40
henoScottK: because the bug you are looking for may have been filed afterwards, it's description changed, etc18:40
persiaThat might be helpful without being disruptive.18:40
LaserJockso how would this be implemented?18:40
ScottKintellectronica: In that case I think it's actively harmful.18:41
LaserJockwould it be flagged somehow as "possible dup"?18:41
henoor the filer may not have wanted to dupe it for some reason18:41
intellectronicaLaserJock: yes, that's the idea. to make it easier to search for 'maybe dupes'18:41
LaserJockpersia: ohhhh, I l ike that18:41
ScottKAnd I'd prefer not to have some automagic over-ride what the reporter decided.18:41
pedro_persia: that would be good, it's what the GNOME Bugzilla does18:41
henoit's not an automatic thing, just a search feature18:42
LaserJockok, that's cool18:42
LaserJockI like persia's idea of it18:42
henome too18:43
LaserJockthough I think it's more of a "handy for us" than a "helps make reports higher quality" which I sort of perfer in generall18:43
ScottKAs a search feature, I think it might be useful, but not high priority.18:43
henook, that can be lowered a bit too it seems18:43
heno3 and 4 we covered18:44
sbeattieScottK: we were thinking/hoping that it would be relatively easy to implement, given that the dupe detection capability alreayd exists.18:44
heno#5 Bugtask forwarding relationships18:44
LaserJockhmm, I didn't quite get that one18:44
LaserJockintellectronica: can you explain that one more?18:44
ScottKWhat were 3 and 4?18:44
sbeattie3: email to new reporters 4: full activity log18:45
heno#3 Email first-time bug-reporters  #4 activity log18:45
persiaScottK: https://wiki.ubuntu.com/QATeam/LaunchpadBugsFeaturePriorities has the order18:45
intellectronicaLaserJock: basically, it's a way to refine the way bug tasks are raised18:45
intellectronicaLaserJock: the suggestion is to have 'phantom' bug tasks on some bugs, which you can confirm or deny18:46
henoIMO it's important to be able to say 'this bug does not need upstreaming'18:46
LaserJockhmm, that sounds initially easy to abuse18:46
ScottKWhat's the use case for this?18:46
henoor 'for this one we don't know yet'18:47
LaserJockI see18:47
henoFor people who specialise in working with upstream, forwarding issues18:47
LaserJockso we're trying to figure out how to sort packages into "Ubuntu specific", "May affect upstream", and "Affects Upstream" ?18:47
intellectronicaLaserJock: exactly.18:48
pedro_i like that idea ;-)18:48
ScottKI think being able to remove ones that shouldn't be there is far more important.18:48
persiaIs this just a UI change for "Also Affects..." ?18:48
LaserJockwell I would initially say that that could be done via tags18:48
intellectronicaScottK: with this feature implemented, you'll be able to remove them before they are even created! :)18:48
LaserJockthe number of ubuntu-specific bugs is generally quite low18:48
LaserJockso if you were to tag those18:48
LaserJockand have negative tag searches18:49
henoright, it shpuld be possible to change it between any of those 3 states18:49
LaserJockyou'd have "ubuntu specific" and "non-ubuntu specific"18:49
persiaHaving a list of Ubuntu-specific bugs would likely be interesting to some subset of developers18:49
ScottKLaserJock: It's not so easy.  Just because it's not a packaging bug, doens't mean I won't patch it if I can.18:49
ScottKWe already have a tag for 'packaging' bugs.18:49
LaserJockScottK: why is it not that easy18:49
intellectronicaLaserJock: sure, but you won't have to connection to upstream proejcts in cases where an upstream task is due18:50
LaserJockwe're just talking about tagging here18:50
henoit could also be a code bug we introduced18:50
LaserJockI never said anything about what kind of bug it is18:50
persiaheno: Those tend to fall under "packaging" as well, as in "some patch oughtn't be applied"18:50
LaserJockI just said we can tag ubuntu vs. non-ubuntu bugs18:50
intellectronicafor many packages we know what the relevant upstream project is, so it would be nice to be able to use that relation effectively18:50
LaserJockintellectronica: I don't get how this spec would improve that?18:51
persiaThat reminds me, I don't see "Inheriting upstream links between releases" on the list.  Is that an option?18:51
LaserJockdoes it make it easier to file a bug upstream?18:51
ScottKPersonally, I'd like clearer disambiguation between upstream and Ubuntu tasks when upstream uses LP.18:52
ScottKI find the an upstream that uses LP makes life much more confusing for me.18:52
intellectronicaLaserJock: when a bug is filed on an ubuntu package, you will get a suggestion for where it should be reported upstream, and you'll be able to decided whether to file it, or indicate that it's ubuntu-specific18:52
henoit makes it easier to triage the bugs that _may need filing upstream_18:52
persiaOr even when someone randomly registered the upstream project in LP and didn't set a foreign bug tracker.18:52
intellectronicaScottK: how so?18:52
LaserJockintellectronica: oh, and how would that look in the UI?18:52
henobecause you start with a big unknown pile and put bugs in two other piles18:52
ScottKFirst, is upstream is external, I just get status changes.  If they use LP, I get every single effing piece of bugmail and no way to turn it off.18:53
ScottKAnd the difference between that and Ubuntu related comments is very small.18:53
intellectronicaLaserJock: using 'phantom tasks'. lines in the bug task table that are clearly indicative of their requiring confirmation. also in search18:53
henowhere as now it's 'upstream' and 'ubuntu spec + don't know'18:53
ScottKAlso, I think most triager's don' t know enough to know what should go upstream.18:53
LaserJockintellectronica: we've had a lot of people who abuse the upstream stuff already, who can confirm these?18:53
ScottKEven more specifically what should go to Debian and what should go to the eventual upstream.18:54
intellectronicaLaserJock: the same people who can set Triaged (though of course we can discuss that when implementing)18:54
ScottKMaking this to easy is a recipe for disaster.18:54
persiaWell, making this easy may impose a large training burden.18:54
ScottKMaking it easy invites abuse.18:55
ScottKIf people were sufficiently trained, they could handle it anyway.18:55
intellectronicaScottK: well, i believe that real access control is much better than obscurity. if too easy means that you get lots of junk it means that we didn't get the permissions right18:55
LaserJockso is this just making "Also affects project/distribution" easier to use by assuming we want the tasks and letting us confirm or not?18:55
intellectronicaLaserJock: sort of. it also helps marking bugs as ubuntu-specific18:56
ScottKFundamentally I think this entire U/I piece is pretty broken anyway.18:56
LaserJockintellectronica: how so?18:56
intellectronicaLaserJock: if you mark a bug as not affecting upstream, launchpad will remember it18:56
persiaintellectronica: There aren't so many of those: it's typically only for ubuntu-local packages or when we broke something.  I wouldn't like to assume that's the general case.18:56
LaserJockbasically I think the assumption is that *everything* is assumed to be Ubuntu-specific until somebody explicitly finds that it's not18:57
intellectronicabut hey, it could be that the best thing to do is de-prioritize this feature. there are definitely many other features we could consider instead18:57
LaserJockideally we indicate that by filing the bug upstream and opening a task for it18:57
persia(Mind you, I think "Also Affects..." could use work, I just don't want to optimise for the "Ubuntu-only" case, as I think it's rare)18:57
henoIt's seems we need more details on the implementation before taking a clear view on it18:58
LaserJockyeah, I'm still not sure what it's going to do18:58
henook, any other items on the list we should cover?18:58
ScottKI'd love a feature where I don't have to go through the useful project registration stuff to link a bug.18:58
henohigher or lower priority18:58
intellectronicaheno: ok. shall we make it an action for me to upload a spec so that we have something more concrete to discuss?18:58
henointellectronica: yes please18:59
LaserJockin general I think tags are a pain point18:59
henoScottK: get jcastro to do it for you ;)18:59
ScottKheno: It's a useless barrier18:59
ScottKI'd like to discuss the qualifying bug reporters one.19:00
ScottKI think it should be removed.19:00
henoLaserJock: and is official tags the right answer19:00
ScottKIt's very un-Ubuntu to tell people the don't know enough to report bugs.19:00
LaserJockI think it's also actively harmful to register projects in Launchpad just for bug tracking19:00
LaserJockheno: part of it19:00
LaserJockwe've also discussed better viewing of tags19:00
ScottKIf I put my upstream hat on for a moment, I find them very troublesome19:00
LaserJocki.e. sorting by number of bugs tagged rather than alphabetical19:01
LaserJockand having a threshold number19:01
henoright qualifying bug reporters will clearly be controvertial19:01
ScottKThey show up in google searches and look like the upstream home when they aren't.19:01
bdmurrayLaserJock: by the way there is a greasemonkey script for that now19:01
LaserJockbdmurray: cool, we just need to get that into LP proper :-)19:01
persiabdmurray: Sure, but isn't this the opportunity to not need that anymore ? :)19:02
henoI don't feel strongly about it, but assumed it would raise the quality of bugs on average, though at a cost19:02
bdmurraypersia: that's why I qualified it with by the way19:02
LaserJockhenkjan: what would?19:02
persiaOh.  I thought you were just passing FYI.  Sorry for confusion.19:02
LaserJockheno: ^^19:02
heno'qualifying bug reporters'19:03
LaserJockoh right19:03
LaserJockyeah, I think that's a terrible idea19:03
LaserJockand really hope it never sees the light of day ;-)19:03
henoScottK wants it removed, as does LaserJock19:03
henoany other views?19:03
LaserJockI can't imagine what upstream's would think19:03
LaserJock"I can't file bugs on my own software???"19:04
pedro_I'm with ScottK on this too, it's going to be very controversial for upstream people19:04
henook, I'll set that to '-' then19:04
LaserJockI mean, it's an interesting idea19:04
henoanything else on the list?19:04
ScottKI'd also think U/I for submitting to upstream is not a good idea.19:05
LaserJockbut I don't think there's any real metric that will work to figure out what "qualified" is19:05
persiaPerhaps the redirection can be part of the guided-bug-filing process, so it is noted but not enforced.19:05
henoit's meant to give you a template basically hat you can paste upstream, not fully automatic19:05
JonPackardI like the idea of an e-mail after the first time a user reports a bug with Ubuntu, but I think we should take it a step further. Would it be possible to add some sort of HELP button to the "Report a bug" page? Perhaps something like https://help.ubuntu.com/community/ReportingBugs would be very helpful to first time bug reporters.19:05
ScottKJonPackard: Link on a web page or "Click here if you want us to mail you more information", but not automatic.19:06
persiaI'd be a fan of search filtering.  Sometimes someone asks me about classes of bugs that keep popping up in their searches, and I have to read a bit to understand how to suggest they search differently to find what they seek.19:06
henoJonPackard: that could be worked into 'guided filing'19:06
ScottKheno: I guess I have a hard time envisioning a template that would work for more than one upstream.19:07
henoScottK: it needs to be tailored for each, indeed19:07
LaserJockI put "Capture Distro Series When Filing Bugs" and "Better package name UI guidance" on my list19:07
LaserJockI think it would be good to help reporters get good information the first time19:08
LaserJockhow often do we see triagers asking "what version of Ubuntu and package are you using?"19:08
ScottKheno: Seems to me like a huge amount of work for little to no payoff (generally the same people that are qualified to upstream bugs know how to use the upstream bug tracker)19:08
henopersia: you want "Explicit Search Filtering" raised a bit?19:08
ScottKLaserJock: Agreed.19:08
LaserJockand then we have quite a few reports with no package associated that I think we can get rid of19:08
henowe don't do enough upstreaming today though19:09
henomany bugs are just lingering with us19:09
persiaheno: I don't help in #ubuntu-bugs as much as I'd like, but it's certainly something that would make helping some of the triagers easier for me.19:09
henopersia: ok, thanks19:09
persiaOn the other hand, it doesn't affect me personally, and I'm happy that it got a number if everyone else feels it's not so important.19:09
ScottKheno: I think not sending everything upstream is better than sending them lots of junk that leads to Ubuntu bugs getting ignored.19:10
LaserJockheno: I believe the lack of upstreaming is mostly a cultural/social issue19:10
henoLaserJock: right, there should be room for those now that we have demoted a few19:10
henobtw, LaserJock's prioritised list was helpful - it'd be great if a few more people did that19:11
LaserJockthe problem is that upstreaming is almost by definition a pretty hard thing to do19:11
henothat way I can try to reconcile the different lists19:11
henoit is, but we should try to make it easier where we can19:12
henolet's try to wrap up the meeting19:12
henokeep using the mailing list19:12
henoit's all good stuff!19:12
LaserJockyes, productive meeting for sure19:13
henoany other business?19:13
LaserJockpoor intellectronica  ;-)19:13
henook, thanks all!19:13
MootBotMeeting finished at 13:17.19:13
henowe can continue in #ubuntu-quality19:13
cr3crap, I wanted to mention that daily builds are being tested now :)19:13
intellectronicathanks, heno (and everyone)19:14
ScottKheno: The hard part with upstreaming isn't the filing, but the knowing if and when to do so and what to say.19:14
arathanks intellectronica and everyone!19:14
pedro_thanks all19:14
LaserJockScottK: and followup, IMO19:14
henoScottK: agreed, you need to spend some time learning about that upstream19:14
LaserJockwhen you file a bug upstream you become the new bug reporter19:14
henocr3: ROCK!19:15
LaserJockcr3: where will the results be?19:15
sbeattiecr3: woot!19:15
henolook forward to seeing the results from that for Alpha 419:15
cr3LaserJock: currently, they are only accessed on a private site but we are working towards opening up the site in the near future19:15
henoOh, btw, I'm away next week19:16
LaserJockcr3: what kind of tests are being done?19:16
henobut I'll log on for this meeting19:16
cr3sbeattie: we're already seeing tangible results from this testing: cjwatson has modified the cd image building process to fail if the kernel image in the debian-installer is different from the kernel packages on the images19:16
cr3LaserJock: for now, very simple tests. the objective at this point is simply to determine whether each image installs. we'll be adding tests gradually19:17
cr3sbeattie: we need to hug cjwatson for this next time we see him :)19:17
tuxmaniacLaserJock: avogadro is in Intrepid :-) Can you please subscribe that package to MOTU-Science team?19:17
LaserJockcr3: please do make all that available to the Ubuntu community as soon as you can19:17
cr3LaserJock: you bet, I'm as anxious to make this data available as you are :)19:18
henoLaserJock: simple pre-seeds of d-i and some post-install data collection with hwtest19:18
LaserJockheno: ah, cool19:18
henoI think the source and tests is already on the hwtest LP project19:19
LaserJockit'd be good to get other people helping19:19
cr3heno: confirmed19:19
sbeattiecr3: that's awesome!19:20
henobut running them still requires some setting up19:20
henonot sure how easy that would be on a home box, say19:20
LaserJockit'd be nice to get some docs on the wiki (under /Testing )19:20
henocr3: ^ :)19:20
henoI believe that is already on your todo list19:21
cr3heno: there's far more to it, we currently don't support submissions from the public so there are far more pressing matters than documenting what doesn't exist19:21
LaserJockwe don't necessarily need  a place to submit stuff19:21
LaserJockthe important thing is to get people testing19:21
henoin any case, cr3, schwuk and stgraber are working on extending and opening this up19:22
persiacr3: The value of documentation is that others can provide input (note that documentation can be working code)19:22
cr3heno: I had a long discussion with schwuk this morning about the roadmap for making this possible within the scope of the message queue task. the specific steps will be documented shortly within the wiki page we've been working on together.19:22
henocr3: excellent, thanks19:22
henoI'll wander off for a bit19:24
cr3LaserJock: err, you need a way to determine which tests passed or failed. there is no interface for this in the testing tool because there is tremendous value in historical test results for detecting regressions for example, hence the incentive to submit this information in some central database19:24
LaserJockcr3: there's no way to tell the outcome outside the website?19:24
cr3LaserJock: unless you feel like reading xml19:24
LaserJockwell, that's not bad19:24
LaserJockwe could write a quick xml parser19:25
cr3LaserJock: it's just a matter of weeks before it is possible to submit results to the website, so I wouldn't worry about this problem19:25
schwukcr3: Perhaps we should include a summary in the tool, or similar to LaserJock suggested (I've already had some thoughts along those lines)19:25
LaserJockI'm just getting antsy as we're running out of time for Intrepid19:25
cr3LaserJock: if we were talking about months, I'd definately agree with you and spend appropriate time for an interim solution19:25
LaserJockif we want to test stuff out and build a community effort we need some time19:26
LaserJockI'd like to have an Ubuntu Testing Jam for a late Alpha and/or  Beta19:26
cr3LaserJock: time will be tight for intrepid so, realistically speaking, I expect this release to be a beta testing phase for how testing could become. then, we'd start our ideal way of testing from day one for intrepid+119:27
LaserJockcr3: ok, but if you want people to test it then Intrepid Beta is a good time to do it19:27
cr3LaserJock: this is a very important phase though, we need to learn as much from the process as possible during intrepid, so we need to make the tools available ideally before your jam19:27
cr3LaserJock: absolutely19:28
LaserJockI mean, I have no idea right now how many people would be interested in hwtest19:28
* persia notes that it's 18:30, and that #ubuntu-quality is a nice channel for this type of discussion.19:28
LaserJockbut I'd really love to see Ubuntu QA present a suite of testing tools19:28
cr3schwuk: I'd learn towards dumping html and letting firefox display elaborate test results, I'd hate to implement this in gtk19:29
LaserJockpersia: yes, you're right19:29
cr3schwuk: s/learn/lean19:29
=== e-jat is now known as e-jat_zZzZ
=== mc44_ is now known as mc44
=== ubottu changed the topic of #ubuntu-meeting to: Current meeting: Maryland LoCo IRC | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 07 Aug 12:00 UTC: Ubuntu Mobile Team | 07 Aug 14:00 UTC: Ubuntu Java Team | 08 Aug 00:00 UTC: Americas Board | 08 Aug 04:00 UTC: Ubuntu MOTU | 08 Aug 15:00 UTC: Ubuntu Release
=== ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 07 Aug 12:00 UTC: Ubuntu Mobile Team | 07 Aug 14:00 UTC: Ubuntu Java Team | 08 Aug 00:00 UTC: Americas Board | 08 Aug 04:00 UTC: Ubuntu MOTU | 08 Aug 15:00 UTC: Ubuntu Release | 10 Aug 21:00 UTC: Arizona LoCo IRC
james_wmorning TheMuso23:00
james_whi all23:00
brycehi all23:00
cjwatsonevenin' all23:00
* ArneGoetje rubs his eyes23:01
* slangasek waves23:01
cjwatsondoko,ogra: ping?23:02
dokogood evening23:02
cjwatsonok, there were no explicit outstanding actions, though I wanted to check in on the items people promised for "after alpha 3" or similar23:05
cjwatsonogra expected to be able to finish off compcache for alpha 4, but doesn't seem to be here, so we'll skip that for now23:05
cjwatsonasac: how goes NM 0.7?23:05
cjwatsonI assume you hit a roadblock of some kind today ...23:06
asacit worked for you ;)23:06
cjwatsonyes, it did :)23:06
asacso yes. i got trapped by some intermediate mozilla work, doing the final cleanup now23:06
cjwatsonok, fair enough, thanks23:07
asacits basically not stopping NetworkManager during shutdown and upgrade23:07
asacbut displaying "restart system" ... i know this sucks23:07
cjwatsonmy upgrade seemed to be subtly less painful than the previous tries23:07
asacbut thats the only way upstream supports upgrades without tearing down the connection23:07
asacstill it tears down interfaces on upgrade and upstream says: restart required.23:08
cjwatsonbeforehand, nm-applet crashed and burned; this time it kept the connection up and a logout/login largely seemed to sort things out23:08
asacwell. at least that takes care for restarting the applet too23:08
cjwatsonbut if a restart is going to be required, I guess we'll have to cope; the hardy->intrepid kernel upgrade will require one anyway23:08
asactrue. i think thats ok for now. 0.8 will have something to deal with keeping interfaces up according to upstream23:09
asacbut lest first get NM out23:09
cjwatsonwe'll see :)23:09
cjwatson * Team name23:09
asacs/NM/NM 0.7/23:09
cjwatsonso, as I mentioned at the sprint, Mark has asked for the Canonical distro team to be renamed to the Ubuntu Platform Team23:09
slangasekthe Ubuntu Trellis23:10
* liw votes for the Ubuntu Bananenkartoffeln Team23:10
cjwatsonit's worth noting that "platform" means different things in different organisations, and I think Mark thinks of it more widely than I do23:10
cjwatsonanyway, the upshot is we lost the name game and get to rename ourselves23:10
dokoliw: it's Bratkartoffel23:10
calcsuper core dev ;-)23:10
* TheMuso still has no new ideas.23:10
liw(iow, I don't care about the name :)23:10
=== johnc4511 is now known as johnc4510
cjwatsonI talked with mdz and sabdfl, juggled a lot of ideas, most of which suck; as an executive decision I have agreed with mdz to call ourselves the Ubuntu Foundations Team, by analogy with the Launchpad Foundations Team that occupies a rather similar position over that way23:11
calcso we have desktop, desktop experience, qa, any others i forget inside of ubuntu platform?23:11
cjwatsonyes, I know this clashes with the Ubuntu Foundation23:11
slangasekas long as it doesn't clash with the Ubuntu Mascara, that should be ok23:11
asacFoundations Team really remembers me of a charity23:12
cjwatsonbut since that's dormant until it's needed (with any luck never), I don't think this is a serious problem23:12
cjwatsonI will wander round and rename wiki pages and such in due course23:12
cjwatsoncalc: mobile, server, kernel, community; desktop experience is external23:13
TheMusoSounds reasonable.23:13
calcoh yea those teams are important too, esp the kernel one ;-)23:13
cjwatson * https://wiki.ubuntu.com/DistributedDevelopment/ClientToolsDiscussion23:14
cjwatson   (James)23:14
cjwatsonjames_w: would you introduce this?23:14
james_wso, I'm starting to look at the parts of my work that affect people more clearly, rather than just trying to get good history for the branches.23:14
james_wthis means that I'm looking to receive input on various things, and so I'm starting to draft some wiki documents for comment by others, so that I know which direction to go in23:15
james_wone of these is the document above, looking at some high level tool questions23:16
james_wwe need some way to access and work with the branches, and this document is about getting answers to a couple of questions about how this tools should look in the abstract.23:16
james_wThere are two questions discussed on there currently, and I'm happy to add more, and I would like input to make sure that I haven't missed any arguments either way, or mis-evaluated things23:17
james_wor indeed if I'm barking up completely the wrong tree, or just barking23:17
james_wthe first question there is whether we should have a new tool/suite of tools for working with these branches, or make the existing tools we have for dealing with packaging branches do out bidding23:18
cjwatsonit occurred to me that it would be worth considering tools separately23:18
cjwatsondebcheckout is much more complicated (for this purpose) than debcommit23:18
james_wyes, I think debcommit may still be encouraged23:19
james_wdebcheckout is the harder one to thing about23:19
cjwatsondebcheckout and debrelease are also used much less often, and so easier to swap out23:20
james_wI'd appreciate any comments people have on the page, either now, or at a later date after you have had more time to digest it23:20
* TheMuso is still reading.23:20
cjwatsonI have to say the structured workflow bit of it doesn't really appeal to me23:21
liwjames_w, I haven't digested that yet, but I'm curious about whether you think unperish might fit into that picture in some way?23:21
cjwatsonalthough if it just amounts to "sensible defaults, which you can override", that would be no bad thing23:21
james_wliw: that's interesting, I'd not considered it23:22
james_wyeah, I realise the second may well be more controversial23:22
james_wso I'm kind of asking, how much would you hate it if the tool layed things out for you so that it worked well?23:23
cjwatsonI can't say that I would be terribly upset if we ended up with ubuntu-checkout and ubuntu-release tools in ubuntu-dev-tools, or similar23:23
james_wthere will be the bzr interface to get full control, but you would want to be somewhere in the middle, where you have some help, but some control?23:23
james_wI haven't worked out yet if I can organise it in a way such that you get "sensible defaults, which you can override" without making the interface unwieldy23:24
liwjames_w, an additional random thought: the mr package may provide some inspiration, too, although it's not directly related23:25
asaci can not yet estimate how much those tools would constraint me, but having some sane best-practices scripts sounds reasonable imo.23:25
james_wliw: yes, I've never looked at in detail23:25
james_wdoes anyone think that two tools would be good, an easy one, and a more complex one, where they could be interchangeable and not cause problems if used together would work?23:26
cjwatsonit's possibly worth considering that if you start out a developer tool with a very restrictive design, it tends to accumulate wishlist bugs to make it less restrictive :)23:26
cjwatsonsometimes it's better to make the design flexible from the start, and then you end up with something more coherent23:26
liwjames_w, I think you may want to consider a heavily plugin based design to allow flexibility23:27
cjwatsonplugins seem like overkill for a "checkout Ubuntu source package" tool. What were you thinking of?23:27
james_wcjwatson: that is true, two tools could make it hard to know where to draw the line23:27
slangasekjames_w: I don't think we want two separate tools; IME that tends to cause gulfs between the hard-core users and the novices23:27
asacgood point23:28
james_wliw: it will at least be a library, so you can script specific operations that you like23:28
cjwatsonbzr ubuntu-root ~/src/ubuntu23:28
cjwatsonbzr ubuntu-checkout man-db23:28
cjwatson# checks out to ~/src/ubuntu/man-db/intrepid23:28
cjwatsonsomething like that?23:28
james_wslangasek: good point, would two command sets in one tool lead to the same thing?23:29
cjwatsonand ultimately it just maps to mkdir; cd; bzr checkout lp:ubuntu/intrepid/man-db anyway23:29
slangasekjames_w: if they're two completely disparate sets, then possibly, to a lesser degree?23:29
liwgit has that23:29
james_wcjwatson: that would be the idea23:30
cjwatsonI have a feeling that making the whole thing be a bzr command set might be no bad thing, and then we can reuse bzr's configuration infrastructure23:30
james_wcjwatson: with a shared repo thrown in23:30
liwif it's just for checking code out with bzr, then a bzr plugin seems the most logical choice23:31
cjwatsondebcommit is sort of different because its primary job is parsing debian/changelog to figure out the commit message (as well as VCS independence)23:31
cjwatsonbzr ubuntu-release would amount to debcommit -r and (for the time being) upload?23:31
james_wyeah, you'll be able to "bzr branch lp:ubuntu/hardy/gcc" or similar23:32
cjwatsonubuntu-release would have to deal with alternative upload locations, e.g. PPAs23:32
james_wit would be easy to add things as bzr commands, and then have a separate tool which has just those commands, so that new users can find the commands for Ubuntu stuff more easily23:32
cjwatsonperhaps just arbitrary dupload/dput arguments23:32
liwin unperish I have "unperish dput --dput-host=foo", which seems to work well for me (but the userbase is limited :)23:33
james_wcjwatson: my thought earlier was perhaps to switch to "mark-uploaded" or something, where you do the upload, and then tell the tool to do it's thing23:33
james_wit would leave plenty room for transitioning to another system later23:34
cjwatsonmaybe people here could volunteer to basically instrument their workflow for a day, logging each time you do a checkout, commit, or tag/upload operation23:34
cjwatsonregardless of current tool23:34
james_wthat would be an interesting idea23:35
james_wwould a package that diverted a load of packaging tools and just logged their use before invoking them be a bad idea?23:36
cjwatsonin my case, many of the operations are sftp and dpkg-source23:36
cjwatsonyou might find it tricky :)23:36
liwstudying history files might be enough?23:36
cjwatson(I haven't got round to writing a tool to forcibly fetch from my local mirror or fetch alternative versions, so often just use lftp directly)23:37
* TheMuso is usually using dpkg-source/dput/dpkg, except cases where I need to use bzr.23:37
=== Moot2 is now known as MootBot
cjwatsonjames_w: I wondered also whether it was worthwhile to "hide bzr, so that you don't have to know you are using it"23:37
james_wI think everyone needs something more concrete to discuss. My aim today was to get first reactions to the idea really.23:37
james_wcjwatson: I think there is some value to it23:38
* TheMuso is happy to go with the flow, as he doesn't have any concrete ideas either way yet.23:38
james_wcjwatson: it's possible to have a very thin wrapper if we decide to stuff most things in to bzr23:38
slangasekis the argument there that people will resist if they see that it's built on bzr?23:38
slangasekbecause I hope you're delivering us something that works so awesome that everyone will want to use it :-)23:39
cjwatsonISTM that only extremely naive use would avoid needing to use more sophisticated bzr commands (even things like log, viz, etc.) and that people would outgrow a thin wrapper very quickly23:39
asaci dont understand that argument too. if its easy to use then we dont need to hide it I hope.23:39
james_wslangasek: partly, and partly that many people won't need to see most of what bzr does, so "ubuntu-bzr commands" lists only ubuntu related stuff23:39
cjwatsonI can see the help-guidance argument, although perhaps there are other ways to achieve that23:40
james_wyes, there are I think23:40
slangasekI guess I would expect that we would be /encouraging/ people to use bzr's full range of features, particularly branching/merging to allow parallel development23:40
cjwatsonwhen we finally get round to an Ubuntu Developer's Reference for instance ...23:40
james_wI would like to make it a gradual transition to the more advanced features though23:41
james_wputting everything in bzr does remove some bumps from that though, even if it doesn't sheild the user from the features immediately23:41
james_wand there are other ways to provide the transition23:42
james_wso it sounds like I should go for using bzr to start with, especially as for this release it will be people that are interested that will try it out23:43
james_wI'll put this discussion in to the document.23:43
james_wThanks all for your input, it was very valuable.23:43
james_wThere's one more thing I would like to mention.23:43
james_wis the home that I am making on the wiki for all of the design stuff23:44
lifelesshating my isp right now :P23:44
james_whey lifeless23:44
james_wand one thing I am doing is looking at the processes we have and seeing what the requirements of the tool would be for each of them.23:44
james_wif you'd like to help, or have an area which you would like to make sure is covered please ping me23:45
brycejames_w, for X one workflow consideration is interop with git (which I know probably won't be there for some time).23:45
james_we.g. slangasek and SRUs23:45
james_wbryce: yeah, it's not at the top of my list right now, but it is something that I want to make work well.23:46
james_wbryce: perhaps we should talk about what you would like out of my work in the short/medium term so that I know where to focus23:46
james_wI saw you fighting with git earlier, so I understand if you want to switch :-)23:46
brycejames_w, :-)23:47
* cjwatson wonders how hard adding git support to cscvs would really be23:47
lifelessbzr can import from git already23:47
james_wcjwatson: jelmer is working on bzr-git at the moment, so hopefully we won't need to23:47
lifelessfastexport | fastimport23:47
lifelessI wouldn't add it to cscvs23:47
james_wcjwatson: I believe the other day he said he was working on "bzr branch git://..."23:47
cjwatsonI was thinking of it in the light of getting it into the code import infrastructure in the most expedient way23:48
lifelessgit doesn't need all of cscvs's machinery because its not as brain damaged23:48
lifelesscjwatson: sure; I doubt that that is it; :P23:48
cjwatsonlifeless: heh, ok23:49
lifelessanyhow, as the phase 1 branches have no upstream links; it doesn't really help to have a import in bzr23:49
brycejames_w, lifeless: https://wiki.ubuntu.com/X/GitUsage documents our git workflow pretty well23:49
lifelessbecause you still can't merge-to-update23:49
james_wthanks bryce23:49
cjwatsonlifeless: thinking ahead23:49
lifelesscjwatson: fair enough23:49
brycebasically it involves merging from debian's git repo.  Also we occasionally pull git straight from fdo upstream for testing (I'm currently trying to put together packages from the drm-gem branches of things for BenC)23:49
brycebeing able to do that through bzr would be sweet23:50
cjwatsonok, sounds like the end of that topic; any other business? (thanks, James)23:52
james_wthanks everyone, that was very useful to me23:52
* slangasek raises his hand23:53
cjwatsonslangasek: go23:53
slangasekCDs are oversized again; they were missing the matching kernel for a few days, during which some packages snuck some more bloat in :)23:53
cjwatsonBTW I arranged that kernel skew will cause a build failure rather than just spitting out a busted CD, in future23:54
* TheMuso should really get to downsizing sounds. WIll look into that today.23:54
slangasekI'm trying to trim it back today so that we can get a good ISO to use for testing NM 0.7 when it lands, but if anybody spots anything, help is appreciated23:54
cjwatsonslangasek: just alternates, or desktops too?23:54
slangasekcjwatson: great, that should help us be more proactive23:54
slangasekcjwatson: oh, the desktops aren't oversized; is the build from this morning intact?23:54
slangasekor are they going to get bigger on the next run?23:55
cjwatsonit may be a bit screwed (the kernel image is still taken from d-i), but not in a way that affects size significantly23:55
slangasekcurrently alternate is the only oversized, so that decreases the urgency some - makes it only an issue of getting down to size for alpha-4 :)23:55
slangasekfwiw, a new enchant sync has pulled all of voikko (the Finnish spellchecker) onto the CDs23:56
slangasekI'm kicking that back out into a separate binary now23:56
calcif only alternate is oversized just rebuild something with lzma ;-)23:56
cjwatsonI'll test the removal of the uncompressed Packages files nowish and commit that if it works23:57
slangasekcalc: we have some candidates for that, as well, still; samba would be a good one, new upstream version bloated quite a bit and smbclient was already on the watch list23:57
asacone thing: could someone please check that running /usr/share/update-notifier/notify-reboot-required brings up the "restart" notification? for me it doesnt work.23:58
slangasektouch: cannot touch `/var/run/reboot-required': Permission denied23:58
slangasek? :)23:58
slangasekoh, I already have the 'reboot required' icon glaring at me, so - no effect ;)23:59
asactoo bad ;)23:59
asacanyone else?23:59
* TheMuso is not running intrepid.23:59
cjwatsonwell, all the kernel packages do is simply run that without arguments23:59
james_wasac: nothing yet, is it polled for?23:59
liwasac, on hardy, no effect23:59
cjwatsonso if you do that, you'll be in good company23:59
asacstill it doesnt work23:59
asacnot on hardy, nor on intrepid23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!