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