| === prpplague is now known as prpplague^3 | ||
| === prpplague^3 is now known as prpplague | ||
| === prpplague is now known as prpplague^3 | ||
| === prpplague^2 is now known as prpplague | ||
| === asac_ is now known as asac | ||
| === lilstevie|ZNC is now known as lilstevie | ||
| === txwikinger2 is now known as txwikinger | ||
| === lilstevie is now known as lilstevie|ZNC | ||
| === lilstevie|ZNC is now known as lilstevie | ||
| nemoz | Hello, I would like to know what wifi usb devices people have used successfully on the beagleboard-xm with Ubuntu? | 11:31 |
|---|---|---|
| nemoz | ARM Cortex-A8 | 11:31 |
| ogra_ | plenty | 11:32 |
| tonu | yes, plenty | 11:32 |
| tonu | it does not matter is beagleboard or not. Anything supported on linux works | 11:32 |
| ogra_ | right | 11:32 |
| ogra_ | well, at least anything supported on ubuntu :) | 11:33 |
| ogra_ | minus ndiswrapper cards indeed :) | 11:33 |
| nemoz | So it should be pretty safe buying any of the usual wifi dongles? | 11:33 |
| ogra_ | right | 11:33 |
| ogra_ | you will have the same issues you have on other arches (if you have issues) | 11:34 |
| tonu | I used ALFA ones with RT8187 chipset | 11:34 |
| nemoz | I was reading things about wifi devices not being recognised correctly by the device so I thought I would make certain | 11:34 |
| tonu | also some others but ALFA is something I always can recommend | 11:35 |
| hrw | I use tplink with ath9k_htc module | 11:40 |
| nemoz | Just plug and go? Or any extra hoops | 11:46 |
| hrw | just | 11:46 |
| nemoz | actually there is an extra constraint, are the devices capable of creating and joining an ad-hoc network? | 11:54 |
| * ogra_ never tried adhoc on omap | 11:55 | |
| hrw | I have AP under desk | 11:56 |
| zul | ogra_: ping | 13:47 |
| ogra_ | zul, yeppers | 13:47 |
| zul | ogra_: hi, so im suppose to press control-esc when the machine is powering on with the usb and the card plugged in right? | 13:48 |
| ogra_ | no card needed | 13:49 |
| ogra_ | but i wont do harm either i guess | 13:50 |
| zul | ok so why is the usb needed again? | 13:50 |
| ogra_ | the LEDs should light up, the screen should stay black | 13:50 |
| ogra_ | the usb is the connection you flash the boot partitions on the internal MMC with | 13:50 |
| ogra_ | from the host computer using nvflash | 13:51 |
| * ogra_ needs to reboot, brb | 13:51 | |
| zul | ok.. | 13:51 |
| ogra_ | re | 13:55 |
| zul | ogra_: hey and where do you extract the linux4tegra tarball to? | 13:57 |
| ogra_ | your PC the USb is connected to | 13:57 |
| zul | just anywhere on that pc? | 13:58 |
| ogra_ | yes | 14:00 |
| lool | ogra_: Hey, while updating the list of images in a local mirror, some questions popped up; is there still a wiki page with the daily images which you folks care about? | 14:01 |
| lool | I've noticed that there is an ubuntu-netbook project where the dailies aren't under ports: http://cdimage.ubuntu.com/ubuntu-netbook/ also I thought netbook was replaced by regular "ubuntu" (desktop) | 14:01 |
| ogra_ | it wasnt replaced yet, thats A2 | 14:02 |
| lool | so that image is going away, right? | 14:02 |
| ogra_ | there should be a release manifest wikipage page, not sure its there for oneiric yet | 14:02 |
| ogra_ | yes, ubuntu-netbook-preinstalled will just become ubuntu-preinstalled | 14:03 |
| zul | ogra_: ok duh...i got it now | 14:13 |
| === prpplague is now known as prpplague^2 | ||
| zul | how long is flashing suppose to take usually? | 14:56 |
| ogra_ | a few seconds | 14:59 |
| ppisati | guys, what's the status of PM on omap4? | 15:12 |
| zul | ogra_: ok its working now thanks for the help | 15:13 |
| === brendand_ is now known as brendand | ||
| brendand | hi, i'm trying to boot an omap4 natty image on a pandaboard | 15:25 |
| brendand | my SD card has 2 partitions, i 74MB and 1 2.6GB | 15:26 |
| StevenK | ~,. | 15:41 |
| StevenK | ~> | 15:41 |
| === zyga is now known as zyga-afk | ||
| === apachelogger is now known as transitlogger | ||
| === jkridner_ is now known as jkridner | ||
| ogra_ | Daviey, http://people.canonical.com/~ogra/tegra/2.6.37/README first shot of the installer ... should make your life easier | 22:48 |
| ogra_ | NCommander, ^^ in case you want to play ^^^^ | 22:53 |
| Daviey | ogra_: groovy.. what boot img should i use? | 22:53 |
| ogra_ | http://people.canonical.com/~ogra/tegra/2.6.37/ | 22:53 |
| ogra_ | download the files there | 22:53 |
| zul | sweeeet | 22:53 |
| ogra_ | if it works it should make life easier ... i only tested it locally yet | 22:54 |
| ogra_ | (the ac100 models all differ a bit) | 22:54 |
| ogra_ | persia, in case yu are still intrested in setting up a wikipage for the ac100, http://people.canonical.com/~ogra/tegra/2.6.37/README should be a first start | 22:57 |
| Daviey | standard platform++ | 22:57 |
| ogra_ | heh | 22:57 |
| persia | ogra_, Nice improvement. It's worth mentioning that the 8GB model should have stuff on /dev/mmcblk0p7 and the 16GB model on /dev/mmcblk0p12 (and one needs to appropriately adjust the configuration). I'm mostly waiting for you to confirm that it no longer requires a PPA and has a real image. | 23:01 |
| ogra_ | persia, no, the installer hides all that details | 23:01 |
| persia | I'm not sure it's a good idea to have things automatically install to the "first partition", as this may not have the right amount of space. | 23:02 |
| ogra_ | ?? | 23:02 |
| persia | Oh, nevermind. I read README incorrectly. | 23:02 |
| persia | It takes the image *from* the first partition. | 23:02 |
| persia | How are you detecting the appropriate target partition? Just finding the largest? | 23:03 |
| ogra_ | yeah | 23:03 |
| ogra_ | yep | 23:03 |
| * ogra_ will package all that stuff for oneiric, natty is my testbed atm | 23:03 | |
| ogra_ | then you can look at the code :) | 23:03 |
| * persia still thinks that the regular installers should be used, and that the speed issue should be solved generally, but this is a separate issue. | 23:03 | |
| * persia is extra uncomfortable about having unreviewable installation code, and hugs the old version of the SD image that allows one to debootstrap | 23:04 | |
| ogra_ | well, i'm just to tired to make a branch and upload atm | 23:05 |
| persia | Now is not a good time for you to upload :) | 23:06 |
| ogra_ | its just three initramfs files | 23:06 |
| ogra_ | and one script that adds an overlay to the initrd | 23:06 |
| ScottK | rsalveti: Looking at Bug #791250 which you filed (I believe with the aid of a script). It says "This log snippet might be of interest, since it triggered the matcher 'Purging chroot-autobuild'". Wouldn't all build failures trigger on that? | 23:06 |
| ubot2 | Launchpad bug 791250 in kdegames "kdegames version 4:4.6.3-1ubuntu1 failed to build on armel" [High,Triaged] https://launchpad.net/bugs/791250 | 23:06 |
| persia | I don't really like that fix: there are several GL-capable video devices available for armel devices (note that this class of fix is pervasive, unfortunately, so this specific example isn't in any more need of fixing than anything else) | 23:08 |
| rsalveti | ScottK: there can also be "Source-dependencies not satisfied" for broken dependencies | 23:08 |
| rsalveti | and yes, it's a script | 23:09 |
| rsalveti | lp:svammel | 23:09 |
| ScottK | True. | 23:09 |
| ScottK | I guess it seems like a pretty broad brush. | 23:09 |
| ScottK | We don't really need a bug for every build failure. | 23:09 |
| ScottK | When I'm curious about build failures I look at http://qa.ubuntuwire.com/ftbfs/ and not the bug tracker. | 23:10 |
| ogra_ | ++ | 23:10 |
| rsalveti | ScottK: we're tracking build failures with bug because the it's easier to go over the bug list at launchpad | 23:10 |
| rsalveti | and use that at the arm porting queue | 23:10 |
| rsalveti | and also put more folks involved on this | 23:11 |
| persia | In the case where the build failure is particularly interesting, and someone has an idea to address the class of problem, bugs can be nice, but that's a special case. | 23:11 |
| ScottK | rsalveti: Easier for who? It's more stuff to mess with for us. | 23:11 |
| persia | rsalveti, Please don't. It annoys other developers. | 23:11 |
| rsalveti | the script can also close the bugs once a newer package version is uploaded without build failures | 23:11 |
| ScottK | Seems like pointless paperwork. | 23:11 |
| ogra_ | super pointelss paperwork | 23:11 |
| ogra_ | and annoying too | 23:11 |
| rsalveti | I don't think it's pointeless | 23:11 |
| ogra_ | since now everyone is forced into that paperwork ... else we end up with tons of open bugs | 23:12 |
| rsalveti | it helped identifying easily the issues we had with binutils and ld | 23:12 |
| ogra_ | the build logs didnt suffice ? | 23:12 |
| rsalveti | and I really prefer a bug to be filled than just let it at the ftbfs list | 23:12 |
| rsalveti | well, you need to go over all logs | 23:12 |
| rsalveti | bugs you can trace status | 23:12 |
| persia | rsalveti, The issue is that FTBFS is transient. We did an automated build-failure-bug-report thing before (back in Dapper), and stopped because by the time people looked at many of the bugs, they had been addressed by some other upload addressing the transient issue. | 23:12 |
| rsalveti | who is taking care of that | 23:12 |
| rsalveti | details about what happened and such | 23:13 |
| persia | Considering the number of packages that get updated for reasons having nothing to do with build failures, often in ways that affect them (new upstream versions, Debian syncs, etc.), it's especially pointless this early in the cycle. | 23:13 |
| rsalveti | persia: that's why the script can also close bugs | 23:13 |
| ScottK | rsalveti: I think it may be different near release, but in this stage of the cycle, it's just a lot of churn. | 23:13 |
| ScottK | rsalveti: All of which doesn't keep people's inbox from getting clogged. | 23:13 |
| persia | rsalveti, Why not just add status tracking to the FTBFS page, if that's what you need. | 23:13 |
| rsalveti | persia: why not bugs? | 23:14 |
| rsalveti | what's the problem with this? | 23:14 |
| rsalveti | noise? | 23:14 |
| ogra_ | yes | 23:14 |
| rsalveti | come on, it's a good thing to track the issues there | 23:14 |
| ScottK | Low signal to noise ration. | 23:14 |
| ScottK | rsalveti: We disagree. | 23:14 |
| ogra_ | noise, mail, harder to use interface, slowness | 23:14 |
| rsalveti | if we're maintaining the bug list | 23:14 |
| persia | Not just noise, but noise that often has zero value. Noise with value can be tolerated. | 23:14 |
| rsalveti | if you point me that the script is really creating just noise and no value, then it's ok | 23:15 |
| ogra_ | but most annoying as i said above, i need to invest extra time into weeding through LP if i gave back a package | 23:15 |
| rsalveti | for now it's just people complaining because of noise | 23:15 |
| ScottK | rsalveti: If it files a bug for a random FTBFS, it's noise. | 23:15 |
| ogra_ | (or even fixed the buildfailure) | 23:15 |
| persia | rsalveti, We're so pointing. Can you demonstrate some value? Do you need anything other than status? | 23:15 |
| rsalveti | persia: just check the bugs that were filled and changed status | 23:16 |
| persia | It would be fairly easy to have the FTBFS tracker export some JSON, so you could parse it more easily (not that it's that hard to parse in the current state) | 23:16 |
| rsalveti | for example, there are a lot of bugs for the gles porting for Qt | 23:16 |
| persia | rsalveti, So, what value does this bring over the existing FTBFS tracker? | 23:16 |
| Daviey | ogra_: Ah nice! It works directly from the tarball | 23:16 |
| rsalveti | it's a good thing to have bugs for that | 23:16 |
| ogra_ | Daviey, does it work for you ? | 23:16 |
| rsalveti | persia: it's just a tracking tool | 23:16 |
| rsalveti | that's already there | 23:16 |
| rsalveti | and we can easily use | 23:16 |
| rsalveti | if you want to improve the ftbfs to track the status I'd be fine with it | 23:17 |
| persia | rsalveti, I disagree, but that's because I think that the assumption that armel == GLES is fundamentally flawed, and have hardware that you are breaking with the "transition" | 23:17 |
| Daviey | ogra_: Don't know yet... i copied the contents of the tgz and got "No tarball found".... so now putting the tarball in place :) | 23:17 |
| ogra_ | rsalveti, if we can get around drowning in pointless bugs thorough that | 23:17 |
| ScottK | rsalveti: Most of the tasks on the Qt GLES bug were added manually. That one is a bit of an exception. | 23:17 |
| ScottK | That was a case of trying to coordinate effecting deliberate change. | 23:18 |
| ScottK | These auto bugs are completely different. | 23:18 |
| ogra_ | Daviey, heh, damned, READMEs dont allow <blink> :) | 23:18 |
| rsalveti | well, I guess I can only put some more manual work before actually filling the bugs | 23:18 |
| rsalveti | trying to identify it's valuable or not | 23:18 |
| persia | ogra_, You could have written it in HTML: you are asking people to pull over HTTP after all... | 23:18 |
| ScottK | rsalveti: Do you think filing a bug for every compiler warning in a build log is a good idea? | 23:18 |
| ogra_ | persia, yes, as well as i could have uploaded my code to a branch :P | 23:19 |
| Daviey | ogra_: heh, i am a typical man... try first, read the instructions afterwards :( | 23:19 |
| persia | rsalveti, That would have *huge* value, if you did. Bugs with notes about *why* something FTBFS, or other useful information are very useful. | 23:19 |
| ScottK | This is basically the same kind of noise only a lesser scale. | 23:19 |
| rsalveti | so what you're saying is that is basically useless to track ftbfs in bugs in general? | 23:19 |
| ScottK | rsalveti: I agree with persia. If the bug includes some human pre-processing to indicate what went wrong or the class of fix, then it could have value. | 23:20 |
| rsalveti | ok, that's something we can improve | 23:20 |
| persia | No. It's useless to have automatically-filed bugs with no additional information. | 23:20 |
| ScottK | rsalveti: It's useless to track them in the bug tracker. We have other tools for htat. | 23:20 |
| Daviey | packages in Main, or ones a particualr team are going to work on for certain has value in having bugs for FTBFS IMO. | 23:20 |
| ogra_ | rsalveti, i usually open a bug if a first poke on a package didnt help, but i would never do it automatically | 23:20 |
| ScottK | Daviey: I disagree. | 23:21 |
| persia | Daviey, How do components affect this? I don't see any relation. | 23:21 |
| rsalveti | I also don't like the idea of just going over and filling without any kind of filter | 23:21 |
| rsalveti | that's why I believe that if this is fixed, it'll actually bring value | 23:21 |
| rsalveti | and not just noise | 23:21 |
| ScottK | Unless there's more information available than what can be found in the build log, it doesn't help. | 23:21 |
| Daviey | ScottK: I know you disagree.. we'll have to agree to differ :) | 23:21 |
| Daviey | persia: In so far as Canonical /has/ to care about supporting Main, and if a particualr team is committed to certain packages it helps tracking. | 23:22 |
| persia | rsalveti, What sort of filter do you imagine? For me, the threshold is a filter that requires human intelligence: if we can figure it out in an automated manner, I'd rather have a realtime reporting system. | 23:22 |
| rsalveti | persia: manual work before actually filling it | 23:22 |
| rsalveti | checking at least if it looks like a bug | 23:22 |
| Daviey | ogra_: 30 mins! bah. | 23:22 |
| rsalveti | currently the script just goes and fill everything | 23:23 |
| rsalveti | doesn't even ask if you want to check it first | 23:23 |
| ogra_ | Daviey, really depends on your devices ... 30 is worst case | 23:23 |
| persia | rsalveti, If you did that, I'd be arguing that you were doing a good thing by filing the bugs :) | 23:23 |
| rsalveti | sure, that's something I can do | 23:23 |
| persia | Cool! | 23:23 |
| Daviey | persia: A random package in universe that has never been touched in Ubuntu.. where it is most unlikely that any ubuntu contributor is going to fix, would just be a noise raising a bug. | 23:24 |
| rsalveti | just tried today as slangasek was doing for past cycle | 23:24 |
| persia | Daviey, And how does this differ from a random package in main that hasn't been re-uploaded since the Debian import in Warty? I agree with the thoughts behind your statement, just don't believe it has any relation to components. | 23:24 |
| ScottK | rsalveti: And if (thinking down the road) you had tags for classes of FTBFS bugs then that would be super useful as if someone has fixed (as an example) a linker failure in a cmake based package, fixing the second one of those is pretty easy. | 23:24 |
| Daviey | If we rely on using a FTBFS tracker for packages we really care about... we need somewhere to link branches, diffs and discussion.. so the FTBFS tracker needs enriching. Would also be nice to be able to assign it to someone.. And track as Work Items. Suddenly, the FTBFS tracker has re-implemented launchpad. :) | 23:25 |
| persia | (nor that it is specific to Canonical: same applies for any of the other firms that sponsor developers to do stuff) | 23:25 |
| persia | Daviey, Talk to the LP team: there is work *within* LP to integrate the FTBFS tracker. That doesn't mean we should be using bugs. | 23:25 |
| rsalveti | ScottK: yup, also thought about that | 23:25 |
| ScottK | Daviey: I typically don't do any of those things with FTBFS, I just fix stuff. | 23:25 |
| rsalveti | having specific tags can for sure help a lot | 23:25 |
| Daviey | persia: I agree.. the fact is, I have raised FTBFS bugs for packages the server team care about.. Other teams can, or cannot do the same if they like. :) | 23:26 |
| ScottK | rsalveti: You might also talk to dholbach about integrating that thought with the work he's doing on helping getting new developers involved. | 23:26 |
| Daviey | ScottK: Well tracking work that needs to happen in the cycle helps to be able to check we are getting stuff done, and not duplicating effort. | 23:26 |
| persia | Daviey, Implicit in that action is the presumption that nobody external to that team is likely to do anything. I think such a presumption is actively harmful. | 23:26 |
| Daviey | persia: hmm, no | 23:27 |
| rsalveti | ScottK: yeah, will talk with him | 23:27 |
| Daviey | persia: you are missundertanding me | 23:27 |
| ScottK | Daviey: you don't need a bug to have a branch, so that's off your list. | 23:27 |
| ScottK | Work items are for features, not bug fixing. So that's out. | 23:27 |
| Daviey | Having a bug against a package is being MORE open so other teams, within or external to Canonical can see the progress of the issue being resolved. | 23:27 |
| ScottK | So except for assignment and discussion, I think the FTBFS page is fine and what fraction of FTBFS fixes need any of that? | 23:28 |
| Daviey | If it's just remembered in my or ScottK's head... how can others see that it is being noticed and worked on? | 23:28 |
| Daviey | directed to persia ^^ | 23:28 |
| ogra_ | Daviey, but we have a list where it shows up already | 23:28 |
| ogra_ | why do we need another one ? | 23:28 |
| Daviey | ogra_: I haz ubiquity! | 23:28 |
| persia | Daviey, That's why we have an FTBFS tracker, and why the LP team is working to improve the available overviews of FTBFS status *within* launchpad. It needs to be available, but having bugs is needlessly duplicative, unless there is useful value added in the bug. | 23:28 |
| ogra_ | it even categorizes packages by tasks | 23:28 |
| ogra_ | Daviey, awesome ! | 23:29 |
| ScottK | Daviey: Based on your logic, instead of MoM we should have it autofile bugs. | 23:29 |
| persia | Well, by packagesets, so that groups (like the server developers) can easily see which packages interest them. | 23:29 |
| Daviey | persia: but tracking work that needs to happen in the sub-cycle makes it easier aswell. | 23:29 |
| persia | ScottK, We used to do that too :) | 23:29 |
| ScottK | persia: I know. | 23:29 |
| persia | Daviey, Yes, but the defect management system is the wrong way to "track work". | 23:29 |
| Daviey | I do /not/ see the harm it has in having tracking bugs via this method util we have something better. | 23:29 |
| Daviey | persia: FTBFS is a defect, no? | 23:30 |
| ScottK | We already have something better. | 23:30 |
| persia | No, because it's transient: see above. | 23:30 |
| Daviey | we do not. | 23:30 |
| Daviey | As i said at the start of this... i'm not trying to influence you to change what you think is better or not. | 23:31 |
| persia | If you need WIs, the FTBFS tracker should be extended to allow folks to have stuff show up as WIs. This is unrelated to polluting the bug tracker. | 23:31 |
| ScottK | Daviey: The only thing we lack that a bug gives is the ability to assign someone work. If someone is going to assign someone to fix a FTBFS then in that rare instance said someone can file a bug. | 23:31 |
| Daviey | last cycle, when the server team tracked FTBFS issues via bugs - we got MORE community contributions than we had before we had the bugs. | 23:31 |
| ScottK | That's far more efficient than N developers subscribed to bugs dealing with stuff in their inbox. | 23:31 |
| persia | And assignment inherently assures that nobody other than the assignee will do the work. | 23:31 |
| Daviey | Why do you both feel so strongly about this? | 23:31 |
| persia | Daviey, Is this because of the bugs, or because of a lack of socialising potential server contributors to the existing tools? | 23:32 |
| ScottK | Because I get so much bugmail already that I really dislike seeing even more of it autogenerated and thrown into my inbox for no point. | 23:32 |
| Daviey | persia: Well probably both... | 23:32 |
| persia | Because we did it before, and we drowned, and we turned off the automated systems, and it's *really* frustrating to encounter the same issue again, with certain forknowledge that it fails to scale. | 23:32 |
| Daviey | ScottK: Well thanks to LP's latest bug mail filtering, that should be easier. | 23:33 |
| NCommander | Daviey: LP's bug filtering is still very limited | 23:33 |
| ScottK | Daviey: Not really. I still don't seem to be able to unsubscribe from bugs as an individual without unsubscribing the entire team. | 23:33 |
| NCommander | +1 ScottK | 23:33 |
| persia | Daviey, No, because that makes everyone else do work. Is the total sum of that work worth the benefit? How does it compare to the total volume of work required to extend the existing tracker to meet your needs? | 23:33 |
| ScottK | So the improvements turn out not to help much at all with the general use case I have. | 23:34 |
| Daviey | Okay.. The only complaint i had last time was from ScottK. If there were a handful of complaints, then i'd be a little more understanding. | 23:34 |
| ScottK | Daviey: I think persia is referring to something general. | 23:35 |
| NCommander | Daviey: for FTBFS that require cooridination or input, bugs are opened and generally go a long way. For the five minute fix type, not so much | 23:35 |
| Daviey | Well the fact remains, it got results last time. | 23:35 |
| persia | I am. Specifics are relatively uninteresting to me. I actively avoid any mail originating from launchpad anyway. | 23:35 |
| micahg | ScottK: unsubscribing as an individual I think was just fixed | 23:35 |
| persia | Daviey, Sure, but I stand by my argument that this is due to not exposing the common resources used by Ubuntu Developers to nascent members of your team combined with a poor definition of the current "server" packageset, making the current report insufficiently interesting to your team. Both of these need be sorted *anyway*. | 23:36 |
| Daviey | agreed | 23:37 |
| persia | Daviey, And, please, if you do need WI tracking for FTBFS, at least file a bug against the FTBFS tracker and the WI tracker (two tasks). You may or may not have time to actually enable these features, but the above IRC log is not a good way to capture the requirements (and the primary developers of both of those tools are not in this channel) | 23:40 |
| Daviey | persia: ok | 23:45 |
| Daviey | ScottK: Do you filter your bug mail on X-Launchpad-Bug-Tags ? | 23:46 |
| persia | Thank! | 23:46 |
| ScottK | micahg: Just as in when? I tried a couple of days ago and couldn't. | 23:46 |
| ScottK | Daviey: No. I have a mailbox that it all goes into. | 23:46 |
| micahg | ScottK: well, I'm in the beta test group, so I think I've had the feature for a couple weeks | 23:47 |
| Daviey | ScottK: crikey. | 23:47 |
| persia | micahg, Wasn't that allowing individuals to unsubscribe from specific bugs where they are subscribed to the package? This is different from being a member of a team that is subscribed to a bug. | 23:47 |
| micahg | ScottK: http://blog.launchpad.net/bug-tracking/coming-soon-improved-bug-subscriptions, it's coming soon :) | 23:48 |
| micahg | persia: as I understood it, it was both | 23:48 |
| persia | Hrm. I hope so. | 23:48 |
| ScottK | micahg: When I tried it a couple of days ago I could unsubscribe the team from the bug, but not just myself. | 23:49 |
| ScottK | Daviey: I've experimented with more detailed sorting, but find all in one mailbox and use local search tools is more efficient for me than trying to predefine how I want stuff sorted out. | 23:50 |
| micahg | persia: ScottK: right, so it's just the beta team ATM, it's the mute bug feature that does it, it's not subscription based | 23:52 |
| ScottK | Ah. OK. | 23:52 |
| ScottK | There's a lot of release team bugmail I'll stop seeing soon after that lands then. | 23:52 |
| micahg | it covers both use cases mentioned (subscribed to package/product and team mail that's not going to a ML) | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!