[06:51] Good morning [06:51] Ampelbein: seems someone gave it back, g-keyring should be fine now [06:51] hey jasoncwarner_, happy new year! [06:52] hey pitti you as well! [06:57] Good Morning. [06:59] good morning [06:59] after ~4 hours of sleep I can't really call it good .. :> [07:00] :/ [07:00] that's why I get for staying up late and hacking ... [07:00] :> [07:02] bonjour didrocks [07:05] guten morgen pitti. How are you? [07:06] didrocks: cold in full progress. :/ [07:06] pitti: urgh, take it easy today then! [07:50] didrocks, bonjour [07:51] bonjour rickspencer3, comment vas-tu? [07:51] ça va bien, et tois? [07:52] en fait, j'ai commencé mon script pour «unity_stress» [07:53] didrocks, so far, the script changes workspaces every .5 seconds n times [07:53] didrocks, what else should I make it do? [07:54] rickspencer3: trigger expose for applications with multiple windows [07:54] didrocks, that sounds hard ;) [07:54] I'll give it a try though [07:54] like, open a bunch of gedit windows and trigger exposé? [07:55] rickspencer3: yeah, and then close expose, and trigger it again. You have a keyboard shortcut in ccsm for that, so rather, using that shortcut I woul say [07:56] would [07:56] ok, I'll look into it [07:56] obviously minimizing windows as well ;) [07:57] yeah, minimzing/restoring/maximizing [07:57] we can as well use my little soft for quicklist/progress bars [08:03] hey desktoppers, who in Ubuntu One do I assign bugs to? is there a team? [08:08] rickspencer3: ~ubuntuone-hackers AFAIK [08:08] thanks pitti [08:33] rickspencer3: how are you writing this script btw ? [08:33] rickspencer3: compiz can expose certain functionality over dbus, might make it easier for you to automate these things [08:34] (user driven things, like, initiating expo, scale, etc etc etc) [08:40] hi smspillaz it's a bash script, if that helps [08:47] didrocks, looks like there is a compiz update in the desktop PPA [08:47] should I take it? [08:47] (for Oneiric) [08:50] rickspencer3: seb128 did it on december, he told me that he didn't see any isssue so far [08:50] ok [08:50] rickspencer3: so yeah, please, take it and pull the trigger if things go badly :) [08:50] * rickspencer3 clicks Install Updates [08:51] * didrocks crosses fingers :) [08:54] didrocks, what command in ccsm do I need to use to activate spread by keyboard? [08:54] rickspencer3: uno momento! :) [08:54] en espanol? [08:55] rickspencer3: mon espagnole est pire que mon allemand, tu ne veux pas tester :) [08:56] didrocks windows-z spreads everything [08:56] is that good enough? [08:56] or do you need to one app only spread? [08:56] rickspencer3: yeah, was just looking at that, it's the same code, so for stressing, it's good enough :) [08:56] ok [08:56] thanks man [08:56] you're really welcome :) [09:06] hey [09:06] bonjour seb128, ca va? [09:07] hey pitti, I'm good, my cold is almost over (at least my nose stopped being blocked during nights) [09:07] how are you? [09:07] cold still in full progress, but bearable in the mornings [09:09] :-( [09:12] pitti, libgda5 got accepted in Debian btw [09:12] efficient NEWing nowadays ;-) [09:12] seb128: I saw, it was really quick! [09:12] seb128: btw, do you have a clue about bug 911622? [09:12] Launchpad bug 911622 in gdk-pixbuf "[12.04] GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': Datei oder Verzeichnis nicht gefunden (file not found)" [Undecided,New] https://launchpad.net/bugs/911622 [09:12] not off hand, let me have a look [09:21] pitti, ok, I know [09:23] good morning world [09:25] hey chrisccoulson, how are you? [09:26] seb128, yeah, good thanks. how are you? [09:26] pitti, hum, no, in fact I don't know, I though it was maybe similar to the gtk3 I fixed yesterday and the postinst call failing when the olddir was empty [09:26] but that has been handled in gdk-pixbuf by using find to list the files [09:26] chrisccoulson, I'm good thanks [09:31] wow, it's quite amazing that when you search for "chrome" in google this morning, this page ranks higher than google's browser: https://developer.mozilla.org/en/Chrome_Registration [09:36] chrisccoulson, open a bug! [09:36] seb128, lol [09:36] seb128, i think it's intentional: http://searchengineland.com/google-chrome-page-will-have-pagerank-reduced-due-to-sponsored-posts-106551 ;) [09:37] google got caught out violating their own rules with a sponsored post campaign for chrome ;) [09:37] which is hardly surprising tbh..... [09:40] chrisccoulson, "sponsored post compain"? [09:40] seb128, paying sites to post bogus content with a link to the chrome website to boost page rankings ;) [09:41] ... [09:41] no comment [09:41] heh [09:41] I switch to bing, at least it lists chrome first when I type "chrome" :p [09:41] lol [09:42] bing must be using a similar algorithm for page rankings as chrome then. perhaps someone should contact microsoft to have them decrease the ranking for the chrome website too ;) [09:42] **as google [09:42] d'ohg [09:42] ;-) [09:55] rickspencer3: yeah, so it should be possible, if we enable the d-bus plugin by default to trigger those things using d-bus-send [09:56] smspillaz, I'm finding it rather easy with xdotool to do what I want, in fact [09:57] sure [09:57] xdotool works as well, although using d-bus might make things a little less fragile in case, eg, the keybindings change [10:11] seb128: hm, I have an apport fix for ignoring the __memcpy_sse3 and friends stuff [10:11] seb128: I'll also ignore __kernel_vsyscall() while I'm at it [10:11] pitti, \o/ [10:11] seb128: the problem is that committing this will break the existing duplicate db [10:12] as a lot of the current signatures have the old stuff [10:12] so we'll temporarily get non-detected duplicates, but dup detection will have a higher quality in the future [10:12] that's a bit tricky [10:12] well, we will deal with it [10:12] seb128: hopefuly the address signatures will take care of it somewhat [10:12] but we'll see more of these SystemErrors in teh future [10:13] seb128: so there's two options: [10:13] - leave the assertions and dupe the bugs manually [10:13] - ignore the assertion and force the duplication, at the expense of false positives [10:13] I propose we'll roll this out, wait for a few crashes, investigate that duping is really correct in these cases [10:14] and once we get convinced that it's right, automatically dupe for a while [10:14] seb128: unfortunately it's not easy to manually hack the dupe db to just filter out the ignored stuff, as we are lacking the frames after the existing ones [10:15] pitti, you somewhat lost me there, why will we have an increase of those systemerrors? [10:15] seb128: we currently get this assertion if the following happens: [10:15] - a crash has the same address signature as the existing one [10:15] (that's the new way of client-side dupe detection) [10:16] - after retracing the fully symbolic trace has a different signature than the existing bug [10:16] this assumes that fully symbolic traces are "better" [10:16] which is a correct enough assumption ;-) [10:16] i. e. all equal address sigs should also have an equal symbolic sig [10:16] we got the previous SystemErrors because the symbolic sigs had different __strcpy_sse42 vs. __strcpy_sse2 or what not [10:17] which broke above assumption [10:17] yeah, gotcha [10:17] now that we filter them out, we'll break it even harder, until we get crash duplicates with the cleaned up signatures [10:17] - leave the assertions and dupe the bugs manually [10:17] so we could say "if either teh address or the symbolic signature matches, dupe it" [10:17] I would try that for a while and see how it goes and review the buggy cases [10:17] seb128: ok, that was my proposal [10:18] right, I agree with you then ;-) [10:18] and once we get sufficiently convinced that it DTRT, we'll switch over to automatic duping [10:18] sounds good [10:18] this is still in a kind of test drive where I added several asserts that the logic is correct, to avoid false dupes [10:18] seb128: ok, so you have been warned :) [10:18] thanks a lot for the explanations ;-) [10:18] seb128: whenever we get such a crash, we should verify that the retraced and master IDs are really dupes, and dupe them manually, then restart [10:19] ok [10:19] will dupping manually "resolve" the issue? [10:19] for that particular bug, yes [10:19] oh, hang on [10:19] i.e the retracer will know that it matches the signature of the "new" bug which is a duplicate of the old one? [10:19] we also need to kill the "wrong" symbolic signatures from the dupe db [10:20] otherwise we'll keep the wrong ones around forever [10:20] can you made a small utility which replace a signature by the one from another bug? [10:20] like "replace-sig bug1 bug2" [10:21] so we can run that when we hit those buggy cases? [10:21] let me think about this for a bit first [10:21] ok [10:21] we already know which bugs now will have "wrong" sigs [10:21] those which have the symbols you started filtering out? [10:21] let me think about/check what happens if we just remove them [10:21] seb128: right [10:21] ok [10:24] seb128: I'm creating fake lock files while I'm working on this, FYI [10:24] (i. e. stop the retracers) [10:25] pitti, noted [10:30] seb128: ok, I'll just wipe the existing wrong ones from the DB; they'll just get recreated if there's already a matching address sig [10:30] great [10:30] $ cp apport_duplicates.db apport_duplicates.db.__sse_sigs [10:47] slomo: is there a plan to get gstreamer-vaapi packaged at some point? [10:48] tjaalton: sure, when someone with time and hardware that supports it does it ;) [10:49] slomo: i see the long-term plan is to integrate it with -plugins-bad, but an interim solution would be a separate package until it's merged [10:49] or? [10:49] i have the hw, might package it then [10:49] chrisccoulson, there? [10:49] seb128, yeah [10:50] tjaalton: yes [10:50] chrisccoulson, can you help on https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/903973 ? [10:50] Launchpad bug 903973 in gnome-settings-daemon "gnome-settings-daemon crashed with signal 5 in _XReply()" [High,Confirmed] [10:50] chrisccoulson, just giving hints on how to debug those [10:50] chrisccoulson, would it help if we disable the libxklavier handler during the unstable cycle for a bit to get the real stacktraces from g-s-d? [10:51] chrisccoulson, rather than getting stuff libxlavier is catching? [10:54] slomo: ok, I might spend some cycles on it then [10:55] seb128: retracers back on, let the fun begin :) [10:55] seb128, it probably wouldn't help in this case, as the call which actually generates the error is the one which is on the stack [10:56] pitti, \o/ [10:57] chrisccoulson, how do you see if libxklavier "hijacked" the call or not? I don't remember what you told me by then about libxklavier and how it was "misleading" the stacktraces [10:58] seb128, the error handler used by libxklavier exists to swallow some errors that occur normally, so if you disable that then they will just be caught by the GDK handler instead (which will abort) [11:00] in this case though, the call which generates the error is the one which is in the trace (XGetWindowAttributes) [11:00] called by xklavier :-) [11:03] chrisccoulson, I'm not sure to understand why we had issues with libxklavier then, if it just "traps" error it should have stopped issues, not leaded to confusing stacktraces? [11:03] chrisccoulson, well anyway this one seems a g-s-d keyboard bug then? would you be interested to have a look to it or should I just assign it to the team? [11:04] i'll have a quick look to see if i can figure out what's going on [11:05] chrisccoulson, thanks [11:08] ok, XGetWindowAttributes throws a BadMatch error if the specified window isn't actually a window [11:13] chrisccoulson, do you read the source to see that? ;-) [11:13] the manpage states " XGetWindowAttributes can generate BadDrawable and BadWindow errors." [11:13] seb128, yeah [11:14] dixLookupWindow returns that error it finds some resource using the specified ID, but it isn't a window [11:15] those manpages often don't reflect reality ;) [11:17] I see ;-) [11:36] seb128: FYI an attempt to bring the discussion with upstream about accountsservice's role for language/locale settings forward: [11:36] https://bugs.freedesktop.org/42857#c4 [11:36] (pitti and rodrigo_ are on the CC list) [11:36] GunnarHj, hi, great [11:37] seb128: That's basically all that I can come up with, I think. Not sure how to proceed. [11:37] wait for a reply from mathias? [11:39] seb128: Yeah, that's the obvious first step, of course. :) [12:29] seb128, ok, deferred bug 903973 to RAOF ;) [12:29] Launchpad bug 903973 in gnome-settings-daemon "gnome-settings-daemon crashed with signal 5 in _XReply()" [High,Confirmed] https://launchpad.net/bugs/903973 === MacSlow is now known as MacSlow|lunch [12:30] chrisccoulson, way to go! ;-) [12:31] it's always the xorg guys fault at the end! [12:32] heh [12:32] well, they display, it's their fault :) [12:32] it seems that i've investigated pretty much the exact same problem at some point in the past [12:32] didrocks, exactly! [12:32] seeing as i reported https://bugs.freedesktop.org/show_bug.cgi?id=23562 ;) [12:32] Freedesktop bug 23562 in Protocol/Core "GetProperty can return BadMatch error under certain conditions" [Normal,Resolved: fixed] [12:33] chrisccoulson, I've done "also affect xorg-server" and assigned that one to RAOF [12:33] thanks [12:33] yw ;-) [12:33] thank you for looking at it [12:33] g-s-d didn't change in precise and the bug started there [12:34] so it might be a new issue somewhere in the xorg stack [12:34] hello everyone! [12:34] hey nessita! [12:34] xorg didn't change either, the actual bug has been there all along. however, i suspect that something else on the desktop has changed which just exposes the race now [12:34] could be yes [12:34] something creating and destroying a window very quickly ;) [12:34] hi seb128! [12:34] nessita, show are you? [12:35] chrisccoulson, is there any way to find that something? and what is g-s-d tracking,why? [12:35] seb128, gsd is tracking all windows for the keyboard-layout-per-window stuff [12:35] seb128: great, thanks. You? [12:35] (ie, xklavier adds some properties to each top-level window) [12:36] only when that option is activated? [12:36] seb128, i'm not too sure about that. possibly [12:36] ok, that might explain why some people see it and others not [12:36] I will try to activate it just to see if I get the bug [12:36] nessita, I'm great thanks! [12:36] nessita, I had a cold but it's mostly over ;-) [12:37] slangasek, do you use more than one keyboard layout? (re, bug 903973) [12:37] nessita, do you come to budapest next week? [12:37] Launchpad bug 903973 in gnome-settings-daemon "gnome-settings-daemon crashed with signal 5 in _XReply()" [High,Confirmed] https://launchpad.net/bugs/903973 [12:38] seb128: oh, I envy your weather, I guess you have a cold because *is* cold there. We're suffering the heat a lot here. And sadly no, not going to budapest, not this time. I will miss you, though :-/ [12:38] nessita, :-( I wil miss you as well [12:38] well it's not real cold this year, we have a weird weather [12:38] cold and dry is good, we have a not-so-cold and rainy weather [12:38] same here ;) [12:39] it's just dull and wet here [12:39] ugh [12:39] same as the rest of the year ;) [12:39] lol [12:39] heh [12:39] seems about right for birmingham :p [12:39] so, if anyone feels like it, I could use a sponsorship for https://code.launchpad.net/~nataliabidart/ubuntu/precise/ubuntuone-control-panel/ubuntuone-control-panel-2.99.1/+merge/87406? I checked the patch pilot calendar and is kinda empty for today, but there is no rush :-) [12:39] nessita, doing it [12:40] nessita, I guess it's empty because dholbach usually fills it but he's not back from holidays yet I think [12:40] seb128: thanks! (link has an extra ? at the end) [12:40] ah, daniel, daniel :-P [12:40] nessita, launchpad seems smart enough to not break on the trailing "?" ;-) [12:44] nessita, uploaded [12:45] seb128: awesome, thanks! [12:45] nessita, yw [12:45] you rock [12:45] :-) [12:45] nessita, you as well ;-) [12:48] pitti, bug #911734, is that an apport bug? [12:48] Launchpad bug 911734 in gnome-keyring "package libgcr-3-common 3.2.2-1ubuntu2 failed to install/upgrade: trying to overwrite '/usr/share/gcr-3/ui/gcr-import-dialog.ui', which is also in package libgcr-3-1 3.2.2-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/911734 [12:49] hm, I thought I fixed that [12:49] pitti, you fixed the gnome-keyring bug [12:49] but "Package: libgcr-3-common 3.2.2-1ubuntu2" [12:49] though " Unpacking libgcr-3-common (from .../libgcr-3-common_3.2.2-1ubuntu1_all.deb) ..." [12:49] [12:49] pitti, i.e it picks the newest version and wrongly assume it's a regression [12:49] but the log shows it's 1ubuntu1 which hit the bug [12:50] not sure what get the version wrong [12:50] hmm [12:50] i.e that "the version changed between the time the bug got collected and reported"? [12:51] seb128: that's one plausible explanation [12:51] pitti, I can dup it manually but it seems a buggy retracer case, do you want it reassigned to apport or something? [12:51] I'm not 100% sure which information the apt hook already adds [12:51] seb128: all information is in the bug, so please go ahead and dup, yes [12:52] seb128: right, or we just reassign it to apport, that's even better [12:52] doing that, it's easier that to open a new bug [12:52] and it has the infos needed from a buggy cases [12:54] pitti, done and title updated, bug #911734 [12:54] Launchpad bug 911734 in apport "installation issues report sometimes the wrong package version" [Undecided,New] https://launchpad.net/bugs/911734 [12:54] seb128: thanks [12:54] yw [13:00] pitti: Hi Martin, hope you are fighting your cold successfully. [13:00] hey GunnarHj, happy new year! [13:00] pitti: Happy new year to you as well. [13:00] pitti: Do you possibly have time to take a shot at the a-s MP (bug 866062) and the related l-s MP? I can be available here for instant clarifications... [13:00] Launchpad bug 866062 in accountsservice "SetLanguage(): Write ~/.pam_environment instead of ~/.profile" [Medium,In progress] https://launchpad.net/bugs/866062 [13:02] GunnarHj: I saw your post to the upstream bug [13:03] pitti: Yeah, that's the forwarding aspect of it. But I really think that we should get the MPs into the archive before that discussion is completed. [13:04] it's really tricky to review, as it contains several things in one huge MP: the new API, the migration, the (still TBD) changed meaning of LANG, and the .bashrc -> .pam_environment bits [13:05] doing just the latter should be rather simple really, and everything else shoudl really be done upstream [13:06] this is now so utterly complex and error prone that it'll get harder and harder to do even more migrations in the future if upstream does something different or sticks to the current approach [13:08] pitti: Well, I realize that it may appear complex at first sight, but there is a rather clear logic if you take a closer look. [13:09] pitti: I did try to adjust the code in accordance with your first review. [13:09] GunnarHj: it's still on my list, but again, this is not something that I can review in an hour or so [13:10] and I'd like to pick it apart into above four parts, so that it's easier to review and understand [13:12] pitti: I can try to split it into more revisions. But please note that the migration part covers both ~/.profile -> ~/.pam_environment and the changed LANG (format -> language) ... [13:13] well, "mentally split" is fine, too [13:13] pitti: What do you mean by that? Expanding the comments? [13:13] but anyway, this requires pretty much a full day of review; in December I was on a different team, and now I have some catching up to do, that's why it took so long, sorry [13:14] GunnarHj: no, I mean it'll take some time to understand the current behaviour, the new one, reviewing the huge changeset, finding error cases, etc. [13:14] and it's again pretty spaghetti-ish [13:14] C code, shell code, more shell scripts, zenity, the $(ls /tmp/) ... rm loop (which might have a security problem), and so on [13:15] and I'm not convinced that we should land the LANG changes now [13:16] it's a rather large change which also impacts KDE, XFCE, etc., multiple window managers, gnome, and what not [13:18] pitti: Hmm.. as regards LANG it's my impression that the way Ubuntu uses it is the 'odd' way. GNOME does it the other way for sure. [13:18] GNOME only handles LANG ATM, it doesn't have a concept of a language/region split so far? [13:19] meh, our g-s-d package is a mess .. 20ish patches without any patch header [13:19] pitti: I think they have: Language -> LANG via /etc/gdm/Xsession and formats -> LC_* via gsettings g-s-d [13:21] ah, indeed [13:22] pitti: So that's one good reason to do the LANG change, considering the move to g-c-c. It also will take care of some cases of incorrect display language. === MacSlow|lunch is now known as MacSlow [13:25] pitti: Please let me know if there is anything I can do to clarify the a-s MP. Some level of 'mental split' is hopefully in the changelog... [13:25] GunnarHj: how do you handle existing settings in .bashrc now? [13:27] pitti: I didn't touch .bashrc. Reason: Since possible locale settings there has been made manuelly, it's reasonable to assume that the user has chose to ignore the UI and do it manually. [13:27] GunnarHj: but previous l-s wrote its settings there [13:27] so we need a migration path [13:27] otherwise you could never change the language again any more [13:27] pitti: No, you mean ~/.profile, don't you? [13:28] GunnarHj: ah, yes I do [13:28] pitti: And that's certainly taken care of. [13:29] ah, I see the sed call there [13:29] I think we should only do that if ~/.pam_environment doesn't exist yet [13:29] or rather, doesn't have the locale settings [13:29] i. e. once, not every time [13:30] pitti, g-s-d> we have 16 patches and they are mostly trivial ones? [13:30] pitti: Existence of ~/.pam_environment is exactly the criteria I'm using in the MP. [13:30] seb128: yes, but almost none of them have a description or bug link [13:30] right... [13:30] pitti, well most are ubuntu specific [13:30] pitti, I will add descriptions next time I do an upload for it [13:31] pitti: So migration happens only once, which of course is essential. [13:33] seb128: right, I was more concerned about the bug fixes; would really be nice to get them upstream, etc. [13:33] pitti, I don't think we have any fix coming from Ubuntu not upstreamed [13:34] pitti: Possibly the latter isn't as clear as it could be, since the test for existence of ~/.pam_environment happens in the beginning of user_migration_from_profile(). [13:35] GunnarHj: *nod*, sounds fine (we don't want to run the shell script at all if it exists) [13:35] pitti: Right. [13:36] seb128: do you happen to know how to get the g_debug() output from gnome-settings-daemon? --debug doesn't [13:37] IIRC --debug used to work, but not any more [13:37] pitti, it doesn't? did you try to kill g-s-d and run a new one with --no-daemon --debug?. [13:37] yes, I killed it [13:37] --no-daemon doesn't exist [13:37] it does run in the foreground [13:37] let me check [13:37] it just doesn't output anything except warnings [13:37] bug not the g_debug [13:38] hum [13:38] seb128: don't worry, I just asked in case you knew the trick by heart [13:38] well I usually use --debug which worked for me :p [13:40] pitti, oh, I know [13:41] looking... [13:41] gsd_log_default_handler() has debug==1 [13:42] so it seems g_log_default_handler eats it [13:43] pitti, yeah, since glib 2.31 there is a G_SOMETHING to set [13:44] I'm trying to find which one... [13:45] How would I suppress delete-event on Gtk.Window? I don't want my window deleted just hidden when I click X [13:46] pitti, try G_MESSAGES_DEBUG=all [13:46] seb128: aah, that worked; many thanks! [13:46] pitti, G_MESSAGES_DEBUG=all g-s-d --debug [13:46] pitti, yw [13:47] took me a while to find it back! [13:47] it's helpfully not mentioned in the g_debug docs [13:48] indeed [13:48] pitti, https://bugzilla.gnome.org/show_bug.cgi?id=661926 [13:48] Gnome bug 661926 in general "Improve the default logging setup in GLib" [Normal,Resolved: fixed] [13:49] pitti, it's documented in http://developer.gnome.org/glib/2.31/glib-Message-Logging.html#g-log-default-handler [13:50] but yeah, the api for g_debug etc could have a note about it [13:51] chrisccoulson, do you think you could send to GNOME your gsd login speed patches? [13:51] seems you didn't do it? [13:54] am I the only one having trouble with hide_on_delete in python? *bursts into tears* [13:55] seb128: ah nice, I can do G_MESSAGES_DEBUG=print-notifications-plugin [13:55] right [13:55] that was the idea, filter on domains [14:00] BigWhale, just put a callback on the signal and return TRUE in the handler? [14:00] seb128, yeah I just figured it out [14:01] I used return self.hide_on_quit() [14:16] kenvandine: do you even have any "readiness tests" for u1? [14:17] dobey, no... i would need you guys to help define that [14:17] it would be something like confirming upstream tests pass, etc [14:17] and some integration stuff, perhaps [14:17] :-/ [14:22] kenvandine: so i had a sort of discussion with jason last night about this; and it seems upload privs for anyone not on platform team, for canonical packages, are basically worthless now :( [14:23] :( [14:24] so as you can guess, i am quite unhappy about that [14:25] kenvandine: why's that? [14:25] as long as there are AC, it doesn't matter much who runs them? [14:25] pitti, it was really a question of if that person has to be on the platform team or not [14:25] u1 has their own uploaders [14:26] so they don't want to block on having one of us do it [14:26] the whole reason they wanted upload rights [14:27] and we have our own qa team even [14:28] pitti, so u1 had assigned distro acceptance to one of their folks [14:28] hm, can we (i. e. you) really do a better job at QA than U1's own QA? [14:28] well, i think it just wasn't clear what was supposed to go in that column [14:28] pitti, no... i can't [14:28] especially now that i have probably nearly 30 packages on my plate [14:33] pitti: so what do you think? [14:35] dobey: I think it worked quite fine the way it was; I wouldn't change it from my POV [14:35] dobey, i'll talk to jason about it [14:35] i. e. U1 doing their own QA (lots of tests, etc.) and uploading [14:35] i really think you guys are best to fill that role [14:36] ok, thanks [14:36] dobey: ^ that is, we sohuld of course help you with packaging, and other process-y bits (MIRs, and what not) [14:36] but I don't see that kenvandine now handling all uploads and AC checks would improve anything [14:36] pitti: yes, there are obviously certain cases where we will have to bug DMB/platform/whatever [14:36]