Linux000 | This is my first triage, so could someone make sure bug 534582 is a wishlist item? | 00:08 |
---|---|---|
ubot4 | Launchpad bug 534582 in light-themes (Ubuntu) "background looks weird on vertical panels (affects: 1)" [Undecided,New] https://launchpad.net/bugs/534582 | 00:08 |
crimsun | plars: in Lucid, please export LIBASOUND_DEBUG as a non-empty value and try again | 00:25 |
crimsun | plars: alternately, ltrace | 00:26 |
bdrung_ | Linux000: i wouldn't consider it as withlist item. it's a bug and not a feature request. | 00:26 |
Linux000 | Thanks, so what would it be? | 00:26 |
Linux000 | Sorry, misread your post | 00:27 |
Linux000 | Could someone set bug 534582 to Importance low, I can't seem to. | 00:29 |
ubot4 | Launchpad bug 534582 in light-themes (Ubuntu) "background looks weird on vertical panels (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/534582 | 00:29 |
plars | crimsun: exporting LIBASOUND_DEBUG=y and playing something doesn't give me anything | 00:29 |
plars | crimsun: do you want the ltrace on aplay, or paplay? | 00:29 |
crimsun | plars: both, please | 00:31 |
Linux000 | And set bug 534582 to Triaged? Thanks. | 00:31 |
ubot4 | Launchpad bug 534582 in light-themes (Ubuntu) "background looks weird on vertical panels (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/534582 | 00:31 |
crimsun | plars: current board is running 1.0.22-0ubuntu6, correct? | 00:31 |
Linux000 | Never mind the Triaged status on 534582, new here. | 00:32 |
plars | crimsun: of which package? | 00:32 |
crimsun | plars: libasound2 | 00:32 |
plars | crimsun: yes | 00:33 |
plars | crimsun: do you think that's where I should file a bug against for now? then attach the logs? | 00:33 |
crimsun | plars: please do, yes. | 00:34 |
plars | crimsun: will do that shortly, have an interrupt at the moment | 00:35 |
crimsun | np. Thanks. | 00:36 |
=== jonathan_ is now known as jjesse | ||
crimsun | plars: note: aplay expects PCM. It won't play vorbis as you intend. | 03:07 |
crimsun | plars: specifically, PCM->wav | 03:08 |
plars | crimsun: ah, my mistake. Still, the rest of it holds true. I'll retry that part with wav files | 03:08 |
crimsun | plars: now, the symptom that you describe in bug 534815 typically points to an incorrect resampling rate configured in pulse | 03:09 |
ubot4 | Launchpad bug 534815 in alsa-lib (Ubuntu) "imx51 some audio files play, others do not (affects: 1)" [Undecided,New] https://launchpad.net/bugs/534815 | 03:09 |
plars | crimsun: I have a similar, but opposite bug on another SoC | 03:10 |
crimsun | plars: to verify, please see default-sample-rate in /etc/pulse/daemon.conf | 03:10 |
plars | ; default-sample-rate = 44100 | 03:11 |
crimsun | plars: in verbose mode, the pulse daemon will use snd_pcm_dump() to print hw config. Please see https://wiki.ubuntu.com/PulseAudio/Log | 03:11 |
crimsun | plars: another more apropos environment variable to test is to export PULSE_NO_SIMD to a non-empty value and forcibly restart the pulse daemon | 03:12 |
crimsun | plars: finally, try bypassing pulse entirely by using speaker-test -Dplughw:0 [any additional params] | 03:13 |
crimsun | plars: (or, pasuspender -- speaker-test -Dplughw:0 [...]) | 03:13 |
* persia idly notes that it's common for different hardware solutions to need different sorts of quirks. | 03:15 | |
=== emma_ is now known as emma | ||
plars | crimsun: ah, yes, with -Dplughw:0 speaker-test -c2 -t wav works (without it, it does not) | 03:31 |
crimsun | plars: ok, definitely a pulse bug, then. | 04:00 |
crimsun | plars: did PULSE_NO_SIMD=1 help? | 04:01 |
plars | crimsun: no, I turned that on when I reproduced it for the verbose log | 04:02 |
crimsun | ok, I haven't read the log yet | 04:03 |
crimsun | still commuting from work | 04:03 |
plars | crimsun: np, thanks for all your help. About to go to sleep myself | 04:05 |
dreamer_ | has anyone here got jack+pulse working in lucid | 04:47 |
dreamer_ | everytime I fire up jack with pulse apps won't start and I get Bus error (core dumped) messages from almost all apps I try to run (even ubuntu-bug) | 04:47 |
=== micahg1 is now known as micahg | ||
kermiac | vish: ping re last comment in bug 532633. I'll ask as you have been involved in this bug too. Are you happy for me to go ahead & change the description to focus only on the wm controls? | 07:18 |
ubot4 | Launchpad bug 532633 in light-themes (Ubuntu) "[light-theme] please centre window title and order window controls (affects: 36) (dups: 6)" [Wishlist,Triaged] https://launchpad.net/bugs/532633 | 07:18 |
kermiac | vish: the wm controls are the main issue in this bug | 07:19 |
vish | kermiac: yeah , sure , i wanted to do it either way.. there are many dups , we can use this for the controls.. | 07:19 |
vish | only the title needs change | 07:20 |
vish | kermiac: thanks for following up | 07:20 |
kermiac | you don't think i should remove the reference to the window title from the description? If I change one, I think both should be changed | 07:20 |
kermiac | vish: ^^ | 07:22 |
vish | kermiac: hmm , the title and the controls will probably need to be changed at the same time , we can just leave it alone | 07:22 |
kermiac | vish: ok, no probs :) I'll update the title | 07:22 |
Anzenketh | That is a lot of bugs | 07:30 |
Zus | hello guys | 07:45 |
Zus | and gals | 07:45 |
BUGabundo_remote | \0 | 08:54 |
ikt | BUGabundo_remote: \o/ | 09:25 |
BUGabundo_remote | /8\ ikt | 09:31 |
ikt | BUGabundo_remote: wut is that? | 09:34 |
=== pts is now known as pths | ||
ikt | https://bugs.launchpad.net/ubuntu/+source/yelp/+bug/529378 | 10:01 |
ubot4 | Launchpad bug 529378 in yelp (Ubuntu) "yelp crashed with signal 5 (affects: 2)" [Medium,Incomplete] | 10:01 |
ikt | wow @ vish w/57 days in a row | 10:12 |
ikt | 57 weeks? | 10:14 |
vish | ikt: 57 weeks is 1 yr ;) | 10:19 |
vish | more than* | 10:19 |
ikt | that would be quite insane | 10:20 |
ikt | or not really | 10:20 |
ikt | so if you can do 5 a day for 5 days in a 7 day week, that counts if you say miss out on 2 days? | 10:21 |
vish | ikt: hm.. i havent done 57 weeks , but yeah , 5 in 7 days counts | 10:22 |
ikt | ah sweet | 10:24 |
=== pts is now known as pths | ||
=== kermiac is now known as kermiac_ | ||
ttx | pedro_: hey, thanks for the samba bugday announcement. Unfortunately I have an emergency on Wednesday (European) morning so I won't be able to kick off early | 12:57 |
pedro_ | ttx, hola, no worries!, thanks for let us know ;-) | 13:00 |
pedro_ | ttx, we can always wait a little bit for the other folks on the server team to ask questions if we have any | 13:01 |
ttx | pedro_: ack | 13:01 |
chrigi | hi! i'm new here and i've got a question regarding the ubuntu bugfixing process. is this the right place for such a question? | 13:02 |
pedro_ | chrigi, better to ask at the #ubuntu-motu channel | 13:04 |
persia | We can try. | 13:04 |
pedro_ | oh well persia is here ;-) | 13:04 |
persia | pedro_: Why? | 13:04 |
* persia thinks bugsquad is probably subscribed to more bugs than MOTU :) | 13:05 | |
pedro_ | cause they might know better about the bug fixing process from the developer point of view ;-) | 13:07 |
chrigi | Well some time ago I had this problem that my keyboard went dead after I resumed from suspend. I found several bugreports on launchpad on it. Further I found that the problem was already fixed in the head of the upstream repository. now my question is: how will the bug find it's way from the upstream github to the ubuntu repos? And what to do with the bugreport? | 13:09 |
chrigi | Sorry for the n00b question ;) | 13:09 |
=== asac_ is now known as asac | ||
yofel | waah, there I'm busy for 2 weeks only to come back and find out we have the meeting, kernel bug day and 2 hug days the same week o.O, busy... | 13:11 |
yofel | chrigi: usually the bug get's fixed in the development release once a new upstream release gets into lucid containing the fix | 13:12 |
yofel | chrigi: to fix bugs in released versions of ubuntu you have to follow https://wiki.ubuntu.com/StableReleaseUpdates | 13:13 |
yofel | chrigi: btw, you mentioned a bug report, which bug? | 13:15 |
chrigi | yofel: thanks! well I think it's not major enough for a StableReleaseUpdate, but is there some place I can see what development release of the package will make it into lucid? | 13:15 |
chrigi | yofel: it's the following bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/437862 | 13:16 |
ubot4 | Launchpad bug 437862 in xserver-xorg-input-evdev (Ubuntu) "device key_bitmask has changed (affects: 19) (dups: 3)" [Medium,Triaged] | 13:16 |
yofel | ah, X... | 13:16 |
yofel | !info xserver-xorg-input-evdev lucid | 13:17 |
ubot4 | yofel: xserver-xorg-input-evdev (source: xserver-xorg-input-evdev): X.Org X server -- evdev input driver. In component main, is optional. Version 1:2.3.2-3ubuntu1 (lucid), package size 80 kB, installed size 204 kB | 13:17 |
yofel | chrigi: that's the version we have right now | 13:17 |
yofel | chrigi: for more details you'll probably get better help in #ubuntu-x | 13:17 |
chrigi | yofel: 2.3.2 is perfect, where did you get this info? | 13:18 |
yofel | chrigi: look at the last line I posted before ubot4 posted the information, also you can query the bot in private with '/msg ubot4 info <pkg> lucid' | 13:19 |
chrigi | and what to do with the bug report? just leave it as "triaged" or change it to fix released (as it is already fixed in upstream)? | 13:20 |
chrigi | yofel: thanks! | 13:20 |
yofel | chrigi: also useful is the 'rmadison' command that's part of the devscripts package | 13:21 |
yofel | actually I find most of the 'ubuntu-dev-tools' package useful | 13:21 |
chrigi | !info xserver-xorg-input-evdev lucid | 13:24 |
ubot4 | chrigi: xserver-xorg-input-evdev (source: xserver-xorg-input-evdev): X.Org X server -- evdev input driver. In component main, is optional. Version 1:2.3.2-3ubuntu1 (lucid), package size 80 kB, installed size 204 kB | 13:24 |
=== jonathan_ is now known as jjesse | ||
zeroseven0183 | Hi! Am I right in saying that the meeting will start in two hours? | 14:08 |
zeroseven0183 | I'm living in the Southeast Asia and it's already 10PM in the evening here. I won't be able to attend the meeting if my timing is correct. | 14:09 |
yofel | zeroseven0183: yes, in 2 hours | 14:14 |
persia | zeroseven0183: I have a similar issue in my timezone. If I have something I want to raise, I usually ask someone else to raise it for me, and review the logs later. | 14:19 |
persia | zeroseven0183: logs can always be found at irclogs.ubuntu.com | 14:19 |
persia | (or if they are missing, complain, because they *should* be there) | 14:20 |
zeroseven0183 | Thanks for the suggestion persia. I guess I have to checkout the logs after | 14:23 |
zeroseven0183 | I wanted to familiarize myself with the terminologies the BugSquad is using | 14:24 |
zeroseven0183 | So I can easily triage bugs | 14:24 |
zeroseven0183 | and better help this team | 14:24 |
persia | zeroseven0183: Best way to do that is to check the wiki pages in the /topic | 14:24 |
zeroseven0183 | Yup. Actually, it helps me a lot. | 14:25 |
persia | zeroseven0183: Or just ask: there's lots of us in Asia, and a healthy overlap with early-rising Europeans, and late-sleeping Americans. | 14:25 |
persia | (for the purposes of the above, the antipodes are "Asia": apologies for overgeneralisation. Africans aren't mentioned only because I don't see many early-rising ones around often) | 14:26 |
BUGabundo_remote | seb128: I'm experiencing similar lag as the fixed GTK bug we had a few weeks ago :( | 14:30 |
seb128 | BUGabundo_remote, ok, dunno where from since we dropped this gtk patch a week ago in lucid | 14:31 |
BUGabundo_remote | I'll test with gtkperf once I get home | 14:32 |
BUGabundo_remote | it just started feeling like that right after this last batch of updates | 14:32 |
BUGabundo_remote | The following packages will be upgraded: | 14:32 |
BUGabundo_remote | cheese cheese-common f-spot firefox firefox-branding firefox-gnome-support gdm gnome-settings-daemon gstreamer0.10-plugins-good gstreamer0.10-pulseaudio libcheese-gtk18 libgnomekbd-common libgnomekbd4 libgweather-common libgweather1 linux linux-generic linux-headers-generic linux-image linux-image-generic tomboy xulrunner-1.9.1 xulrunner-1.9.1-gnome-support | 14:32 |
BUGabundo_remote | but I don't see anything even closelly related | 14:33 |
=== seb128_ is now known as seb128 | ||
bdmurray | Today is meeting day right? | 15:59 |
yofel | if everybody remembered yes | 15:59 |
bdmurray | I remembered ;-) | 15:59 |
yofel | me too :P | 15:59 |
yofel | hm, hggdh is here, qense and micahg aren't :/ | 16:00 |
mrand | As usual, I'll be in and out. | 16:00 |
pedro_ | is there any agenda item? | 16:01 |
bdmurray | There are some additional topics we haven't discussed | 16:01 |
bdmurray | I guess the only topic with an attendee is hggdh's | 16:04 |
bdmurray | hggdh: ? | 16:04 |
BUGabundo_remote | foo | 16:05 |
=== yofel_ is now known as yofel | ||
hggdh | here, sorry | 16:08 |
yofel | maybe we should send out a metting reminder to the ML a day before ^^ | 16:08 |
bdmurray | no problem | 16:08 |
yofel | *meeting | 16:08 |
bdmurray | yofel: yeah, that'd be good ;-) | 16:08 |
mrand | Should probably be a way to do that automatically so someone doesn't have remember to send it out ;-) | 16:09 |
hggdh | so. Are we going to talk about the pending nominations? | 16:10 |
bdmurray | hggdh: yes, sounds good | 16:10 |
BlackZ | hi all | 16:10 |
hggdh | Laibsch started to review pending nominations, and asked what is the procedure there. This is a rather vague process right now | 16:11 |
bdmurray | If its vague its because the nomination workflow is incomplete or lacking in Launchpad | 16:12 |
bdmurray | One issue is that any bug can be nominated for a release - it doesn't need to be confirmed or triaged or anything | 16:13 |
bdmurray | That might be handled socially if we were to educate people about when to nominate | 16:13 |
hggdh | yes indeed. I would rather have social controls than programatic ones | 16:13 |
bdmurray | However, another issue is that its not possible to renominate a bug for a release so if you decline a nomination people don't have much recourse | 16:14 |
hggdh | which, then, makes it difficult to work on them... | 16:14 |
hggdh | coiuld we have package owners/bug-control able to re-nominate? | 16:15 |
hggdh | (which would mean a LP bug to be opened, of course) | 16:16 |
bdmurray | well, package uploaders can target disapproved nominations for release but there is no way for them to get back in the queue | 16:16 |
hggdh | but this is an individual action, bypassing the rejected nomination | 16:16 |
bdmurray | so let's pretend we have a new / incomplete bug nominated for lucid | 16:16 |
bdmurray | it then gets declined / rejected ... how will it be renominated? | 16:17 |
bdmurray | should the decliner subscribe to the bug in the off chance it becomes complete? | 16:17 |
hggdh | hum | 16:18 |
bdmurray | Maybe there is some workaround we could use with tags? | 16:18 |
thekorn | sorry, but I'm missing something: how are nominations used in the development comunity? is the current use of nominations described somewhere? | 16:19 |
hggdh | perhaps by -- instead of officially declining it -- by tagging "declined"? | 16:19 |
bdmurray | hggdh: right and telling people to remove it if the bug is squared away | 16:19 |
nigelb | thekorn: nominations are used for SRU I think | 16:19 |
hggdh | but the flow is quite undocumented | 16:20 |
thekorn | release management is also using it, right? | 16:20 |
bdmurray | thekorn: https://wiki.ubuntu.com/RCBugTargetting | 16:20 |
bdmurray | 'To indicate that a bug should be fixed prior to the final release, the bug should be nominated using the "nominate for release" option in Launchpad' | 16:21 |
hggdh | bdmurray: who has final decision power on nominations? | 16:21 |
charlie-tca | Then why can you nominate for any release instead of just the development release? | 16:21 |
bdmurray | hggdh: generally uploaders of the packages | 16:21 |
pedro_ | charlie-tca, because of the SRU | 16:21 |
thekorn | ok, cool. Related question: who can set nomination in ubuntu? | 16:22 |
bdmurray | thekorn: anybody | 16:22 |
charlie-tca | anyone | 16:22 |
thekorn | I think I never used it ;) | 16:23 |
bdmurray | hggdh: so using tags for declining would allow more people to participate in the workflow | 16:23 |
bdmurray | which would be good I think | 16:23 |
hggdh | I agree | 16:23 |
hggdh | and it is something we can do without changes to LP | 16:24 |
hggdh | I guess we could do with just one tag -- to signal it is being declined. Absence of the tag would mean it is game for nominations | 16:25 |
bdmurray | hggdh: yes and then query for nominations without the "declined" tag | 16:26 |
charlie-tca | The problem is the bug could be nominated for 5 releases, then declined for one only | 16:26 |
pedro_ | declined-release , right? | 16:26 |
bdmurray | pedro_: yep | 16:26 |
bdmurray | and maybe even nomination-declined-lucid | 16:26 |
pedro_ | sounds better to me | 16:27 |
bdmurray | to avoid confusion with declining other things that I don't have an example of ;-) | 16:27 |
charlie-tca | As in a bug nominated for lucid, karmic, hardy, dapper | 16:27 |
bdmurray | charlie-tca: I think that's covered right? | 16:29 |
charlie-tca | As long it is a release specific tag | 16:29 |
hggdh | and I like the hierarchical naming | 16:30 |
charlie-tca | nominating is a favorite for spammers. Once they do it, you have to decline all of them, and the bug can never be nominated again at a later date | 16:30 |
hggdh | yes. This is why we are considering tagging instead of officially declining them | 16:31 |
thekorn | does anyone know if the procedure described in https://wiki.ubuntu.com/RCBugTargetting "untargeting bugs" ever worked? | 16:31 |
bdmurray | thekorn: I think it does | 16:32 |
hggdh | but it gets to be more work than tagging, I think | 16:32 |
bdmurray | thekorn: they are talking about if a bug is targetted to lucid, then it doesn't have a current release tag if you won't fix the lucid task a "current" one gets added | 16:32 |
bdmurray | current release task not tag | 16:32 |
thekorn | hmm, maybe I'm just too confused ;) | 16:33 |
thekorn | sorry | 16:33 |
bdmurray | https://bugs.staging.launchpad.net/ubuntu/+source/debian-installer/+bug/229699 | 16:33 |
ubot4 | Launchpad bug 229699 in debian-installer (Ubuntu) ""setting locale failed" if using other keyboard layout then language (affects: 1) (dups: 1)" [Undecided,Confirmed] | 16:33 |
bdmurray | there is an example I just made | 16:34 |
bdmurray | on staging | 16:34 |
bdmurray | so I think if you won't fix the lucid task a new one will appear | 16:34 |
bdmurray | It doesn't really help with the work flow we are discussing as this one's nomination was already approved | 16:34 |
bdmurray | hggdh: So I think we should discuss this with the release team / slangasek | 16:35 |
hggdh | I agree. | 16:35 |
thekorn | no, it did not work, but yeah it's not relevant to our discussion | 16:35 |
bdmurray | In the mean time an announcement about when to nominate a bug would still be a good idea though | 16:36 |
hggdh | and a wiki update? | 16:36 |
bdmurray | thekorn: I think it did work as there is now a confirmed task | 16:37 |
bdmurray | hggdh: maybe I was thinking mailing list / blog | 16:37 |
thekorn | bdmurray, sorry, you are right | 16:38 |
hggdh | bdmurray: probably the wiki should wait for after the discussion with slangasek | 16:40 |
bdmurray | hggdh: right, I was just thinking saying don't nominated bugs unless they are confirmed | 16:40 |
hggdh | bdmurray: +1 | 16:40 |
bdmurray | okay anything else about release nominations? | 16:42 |
hggdh | not from me | 16:42 |
thekorn | no | 16:42 |
pedro_ | nope | 16:42 |
bdmurray | And any other agenda items to discuss? | 16:43 |
yofel | how about backporting apport? | 16:44 |
yofel | micahg: ping | 16:44 |
micahg | yofel: pong | 16:44 |
hggdh | micahg: can you expand on backporting apport? | 16:44 |
micahg | hggdh: well, where possible add new feature/hooks that are useful in older releases | 16:45 |
nigelb | micahg: basically backporting hooks to older releases? | 16:46 |
bdmurray | apport depends on python-launchpadlib so that would likely get tricky | 16:46 |
hggdh | is it a large dependency tree? | 16:46 |
bdmurray | have a package that was a collection of backported package hooks would be neat | 16:47 |
bdmurray | however, those might also depend on a newer version of apport if they call a general hook | 16:47 |
sbeattie | you'd also want to be sure that the reason the package hook is different in the newer release is not because something in the package configuration (e.g. different logfile layout, etc.) | 16:48 |
micahg | bdmurray: how about where possible? | 16:48 |
hggdh | which releases would we target (if we get to do it)? | 16:48 |
micahg | hggdh: LTSs | 16:48 |
micahg | at least | 16:48 |
bdmurray | micahg: I think its a neat idea and interesting but not something I'd work on directly. | 16:49 |
micahg | one of the big problems in triaging bugs is trying to get info off of a harsystemdy | 16:49 |
bdmurray | maybe it is something we could do for Lucid though | 16:49 |
micahg | hardy system | 16:49 |
bdmurray | so as new hooks come out in M add them to Lucid | 16:49 |
nigelb | I can help with that :) | 16:49 |
micahg | could package hooks also be allowed in SRUs | 16:50 |
bdmurray | I mean really its Hardy and Lucid is almost here | 16:50 |
hggdh | another thing to think on -- as bdmurray said, a package with the hooks, as opposed to hooks in each package | 16:50 |
bdmurray | micahg: there is some cost to having an SRU just for a package hook - downloading the whole thing etc... | 16:50 |
micahg | hggdh: that package would probably get updated frequently | 16:51 |
micahg | bdmurray: maybe included with some other fix? | 16:51 |
hggdh | yes, it will, but better than -- for example -- rebuild Evolution for a hook | 16:51 |
bdmurray | micahg: right better one small package than all of X / firefox | 16:51 |
hggdh | and all other large packages... | 16:52 |
micahg | bdmurray: k, sounds good, but who maintains it? | 16:52 |
bdmurray | ubuntu-bugcontrol in backports? | 16:52 |
micahg | bdmurray: well, wouldn | 16:53 |
micahg | t' that mean that it can't be shipped with the release? | 16:53 |
micahg | and not everyone uses -backports | 16:53 |
bdmurray | so an optional package in universe with updated version of the package hooks for apport | 16:54 |
micahg | bdmurray: I'd say we need to discuss this on the -devel list | 16:54 |
bdmurray | micahg: okay, could you start the discussion? | 16:55 |
micahg | bdmurray: sure | 16:55 |
micahg | but the problem with bugsquad maintaining the hooks is a lack of the package knowledge | 16:56 |
micahg | I think that's one of the reasons there are hooks in the package | 16:56 |
hggdh | this would not change | 16:57 |
hggdh | it is just the target package that would change | 16:57 |
bdmurray | micahg: I'm not following I think it would be as simple as watch the archive for new package hook. Put package hook in meta-package. | 16:57 |
micahg | hggdh: you can;t have two packages offering the same file | 16:57 |
hggdh | no, you cannot. This is another thing to discuss with -devel. I frankly do not like having the hooks on each package | 16:58 |
bdmurray | hggdh: it makes it so universe devels can add a hook to their one package without waiting on apport | 16:58 |
micahg | hggdh: yes, but as I said it's usually the package maintainers that best know what should be in the hook | 16:58 |
bdmurray | s/one/own/ | 16:58 |
hggdh | bdmurray: the universe devels could just forward the branch | 16:59 |
hggdh | micahg: so could the maintainers | 16:59 |
bdmurray | hggdh: still it becomes a bottleneck | 16:59 |
micahg | hggdh: as it is, we;re short on core-devs | 16:59 |
hggdh | more than now? | 16:59 |
micahg | hggdh: exhibit A is the main sponsors queue :) | 17:00 |
hggdh | LOL. The DA rests ;-) | 17:00 |
micahg | it would be nice to be able to at least authorize in SRU inclusion an updated hook | 17:01 |
micahg | and any apport features that aren't py-lplib specific | 17:01 |
hggdh | obviously, this would require a lot of talking. But I still think it simpler to change a small package (with a low cost to build) than a whole complex one | 17:01 |
bdmurray | and maybe we could stick them in /usr/share/apport/package-hooks/backported/ | 17:02 |
micahg | bdmurray: that's an idea... | 17:02 |
hggdh | good idea, makes it more resistant to other unintentional consequences | 17:02 |
micahg | then those can be in a single package :) | 17:03 |
hggdh | defence rests... | 17:03 |
hggdh | defense | 17:03 |
micahg | still needs to be discussed on -devel list but this has a chance of being awarded by the jury :) | 17:03 |
hggdh | yes | 17:03 |
hggdh | next one? | 17:04 |
bdmurray | I think that's all we have time for | 17:04 |
hggdh | CoC signing requirement? | 17:04 |
hggdh | oh, OK | 17:04 |
nigel_nb | meeting officially over? | 17:05 |
hggdh | nigel_nb: yes, I guess so. Left-over for next meeting | 17:06 |
nigel_nb | hggdh: :) | 17:06 |
nigel_nb | pedro_: got a min? | 17:06 |
pedro_ | nigel_nb, yes | 17:07 |
nigel_nb | you had confirmed bug 401028, but the original bug was in telepathy-butterfly and the upstream task is also actually in telepathy-butterfly | 17:07 |
pedro_ | no bot? | 17:07 |
ubot4 | Launchpad bug 401028 in pymsn (Ubuntu Karmic) (and 4 other projects) "telepathy-butterfly crashed with TypeError in b64decode() (affects: 416) (dups: 27)" [Undecided,New] https://launchpad.net/bugs/401028 | 17:07 |
pedro_ | ah just slow | 17:07 |
* nigel_nb pets ubot4 :) | 17:08 | |
pedro_ | looking nigel_nb | 17:08 |
nigel_nb | :) | 17:08 |
nigel_nb | bdmurray: any particular requirements to meet to be part of reviewers? | 17:10 |
bdmurray | nigel_nb: no, not really | 17:10 |
nigel_nb | bdmurray: I had applied, I guess you'll get to it. | 17:10 |
bdmurray | nigel_nb: I actually can't add people | 17:10 |
nigel_nb | oh | 17:11 |
nigel_nb | Persia and I've worked with expanding the tags for review too. Mailed you the conclusion of what could be a better workflow | 17:11 |
bdmurray | I'll try and get that sorted | 17:11 |
bdmurray | nigel_nb: right I need to reply to that but I think its overly complicated | 17:11 |
nigel_nb | it sounds complicated, but its practical when you want to work on patches | 17:12 |
nigel_nb | I was hitting debdiffs a lot of times | 17:12 |
nigel_nb | we actually developed that workflow when I was doing patch review, based on each situation that I faced | 17:13 |
bdmurray | okay, fine but have 6 or 8 tags seems like a bit much if you want people to participate in the process easily | 17:14 |
nigel_nb | the idea is, it helps filter out bugs that area already dealt with | 17:15 |
nigel_nb | or need not be reviewed by reviewers | 17:15 |
pedro_ | nigel_nb, done, I've closed the pymsn task | 17:16 |
nigel_nb | pedro_: I would have done it, but I wasn't really sure :) | 17:16 |
nigel_nb | pedro_: when I was going through the SRU, I quite confused | 17:17 |
pedro_ | nigel_nb, is ok, the bug is actually on papyon rather than at pymsn | 17:17 |
nigel_nb | its on papyon | 17:17 |
nigel_nb | while the pymsn bug may exisit, it is not related to papyon | 17:18 |
nigel_nb | pymsn does not depend on papyon( at least as far as I could see) | 17:18 |
nigel_nb | now the trouble is, a lot of people who says "Affects me too" may have said it for pymsn :( | 17:18 |
pedro_ | well i think the quantity of affected users are counted as a whole at the bug reports and not per task | 17:21 |
nigel_nb | I know | 17:21 |
nigel_nb | This means there might be a bug in pymsn too | 17:22 |
nigel_nb | and that might not be fixed yet | 17:22 |
=== radoe_ is now known as radoe | ||
hggdh | bdmurray: on it now | 22:41 |
hggdh | bdmurray: "... it is possible comment on the branch in a merge ..." I am not sure what you wanted to state here | 22:43 |
bdmurray | hggdh: fixed thanks | 22:44 |
Hillshum | Bug #417757 is fixed, but people with similar symptoms keep complaining. What should be done? | 22:47 |
ubot4 | Launchpad bug 417757 in glibc (Fedora) (and 6 other projects) "[karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups (affects: 158) (dups: 17)" [Unknown,Confirmed] https://launchpad.net/bugs/417757 | 22:47 |
hggdh | bdmurray: some typos corrected. Also, you talk about ubuntu-core-devs and ubuntu-devs (and give examples with both). Are they interchangeable? | 22:51 |
bdmurray | hggdh: yes for now | 22:51 |
bdmurray | maybe I'll just use one in there | 22:52 |
kklimonda | is there a master bug for all reports about missing mouseover tooltip for all applications ported to the appindicator? | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!