[03:36] Good morning [04:35] hi pitti [04:35] anyone know of a tool to put a machine under cpu load for a while? [04:36] I'm wanting to see if load effects my test runs [04:36] or i/o load [04:36] build a kernel :) [04:38] pfft [04:38] actually [04:38] not such a stupid idea [04:39] * thumper recalls system 76 demo at UDS [04:42] hey thumper [04:42] thumper: CPU load> cat /dev/urandom > /dev/null [04:42] thumper: IO load: find / [04:43] pitti: thanks [04:49] Although you might also want to have some write load for your IO; that'll touch different parts of the kernel. [06:03] good morning [06:06] bonjour didrocks [06:06] guten morgen pitti :) [06:20] didrocks: hm, I still have some trouble with how to integrate manually installed drivers [06:20] pitti: isn't that the distro=False? [06:20] didrocks: you can't switch between that and installing nvidia-current, as installing the latter would break the manual install [06:20] ah yeah, if you use the .run for instance [06:20] in this case the GUI should probably not allow you to change anything [06:21] hum, indeed [06:21] so adding a "manual" flag to system_driver_packages() does not make sense at all, as this only shows you the ubuntu-provided packages [06:21] I'll add it to the by-device API then [06:21] indeed [06:21] make more sense there [06:22] how do you detect them btw? seems to me there is no reliable way for that [06:23] didrocks: I was thinking, if the kmod exists, but the package is not installed, I'll treat it as a manual install [06:23] yeah, seems the most straightforward way [06:24] pitti: btw, I don't remember your input yesterday, but there is no table mapping for "Graphical device/Wifi device…" and so on? [06:25] didrocks: I desperately try to not pass any human readable string from u-d-common [06:25] as we cannot translate it there [06:25] indeed [06:25] vendor/model is straight from the PCI database, and we don't need to translate that one [06:25] but I mean, do you have any idea of how we could detect that? there is no such map IIRC [06:25] for the GUI you need to have a mapping of nvidia -> _("NVidia proprietary driver") etc. [06:26] yeah, I'm fine with that :) [06:26] but that's not the "type" of the device, which is what mpt put in the spec [06:26] didrocks: I guess we need to key it on the package name [06:26] we can also have an enum-like "type" key in the info dict [06:27] for the known ones [06:27] "graphics", "wifi", "modem", or not present for "unknown" [06:27] but why do we need it? [06:27] pitti: well, let's not focus on that on the first iteration, but yeah, per package name is an option [06:27] I thought you'd just show the actual device name [06:27] https://wiki.ubuntu.com/SoftwareAndUpdatesSettings#drivers [06:27] see the first image [06:27] oh, for the "Graphics card:" prefix [06:28] right [06:28] or Wi-Fi card: [06:28] ok, we can add an enum for that, too [06:29] hum, you don't want to maintain a full database of all available drivers to their type? [06:29] I can't [06:29] for custom detection plugins [06:29] or for third-party drivers [06:29] hence no guarantee that the enum will be present [06:30] ah ok, so just that for the most common set of drivers [06:30] but we can for the well-known ones (nv, ati, bcm) [06:30] for the others I suggest you don't print a prefix at all [06:30] got it, I was thinking you were going for a crazy mapping :) [06:30] agreed [06:30] it gets even worse, though [06:31] so that will be part of the built device API? [06:31] for e. g. the sl-modem driver (a custom detection plugin) [06:31] we don't even know the sysfs device this is mapping to [06:31] we detect it through grepping aplay -l [06:31] and there are other drivers like the PVR omap4 [06:31] for those we can just show the driver package description and on/off [06:32] this is the main reason why I designed the current api around packages, not sysfs devices [06:32] yeah, I understand now [06:32] someone might even provide a btrfs backport dkms package, which is not hardware specific at all [06:33] so any by-device mapping is necessarily heuristic, and we need an "other" pot for those [06:33] for those we could use the name of the custom detection plugin as dictionary key, instead of the sysfs pat [06:33] h [06:34] right, that what's make more sense to me [06:34] some kind of virtual device as we don't know the real one [06:53] pitti: what would be the difference between the "manual install" flag and the from_distro one? [06:53] didrocks: from_distro == False -> it's a package, but from a third-party repo [06:53] didrocks: that's the "tested by Ubuntu" bit [06:54] ah ok ;) [06:54] thanks pitti [07:08] good morning [07:09] today I can only get 1024x768 resolution instead of the regular 1366x768 on quantal - did anyone else run into this already? [07:10] I have my usual 1280x1024 here [07:10] we didn't get a new kernel, X, or compiz yesterday, though [07:10] dholbach: is this the safe fallback perhaps? [07:10] ah, yes it is, because the boot-up got stuck [07:10] haha [07:10] thanks pitti [07:10] didrocks: how would you use the recommended flag? [07:10] I'm still trying to figure out why it got stuck there [07:11] dholbach: I sometimes have that because it times out on finding the encrypted swap partition [07:11] didrocks: I implemented it for the nvidia variants now [07:11] didrocks: and we still do recommend the proprietary nvidia driver [07:11] didrocks: but I wonder if you need/want it for ATI [07:12] didrocks: as I really think we shouldn't recommend the proprietary one any more, but the free one === philipballew__ is now known as philballew [07:14] pitti: I agree with that, I can recommend the ones will be listed in the _device API if there is no driver in the _driver API attached to that device that is recommended [07:14] wdyt? [07:15] didrocks: the _device API will have its own recommended flags, we can add it to the free driver [07:16] didrocks: do you want to use the _driver API at all, BTW? [07:16] pitti: oh, if _device has the flag as well, yeah, recommending the free driver by default, apart from some special case like nvidia [07:16] pitti: well, if you wrap all of that in the _device API and there is no need, I'm in favor of not using it [07:16] we still need the _driver API for the command line tool, ubiquity, etc. [07:17] but for the GUI you might only want the _device API then [07:17] the current UI code I'm seeing is doing a lot of loops for rebuilding a hierachy :/ [07:17] not sure how it was before this cycle, but at some point a fresh start will be good [07:17] ok, then I guess for the _driver API you don't care much about the recommended flag at all [07:17] pitti: in that case, yeah [07:51] hey desktopers [07:51] salut seb128! Meeting report reminder [07:51] didrocks, oh, indeed ;-) [07:51] waouh, robert_ancell keeps rocking the GNOME updates ;-) [07:52] yeah ;) [07:52] if only I could have trade some MIRs against GNOME updates :-) [07:52] hehe, I don't think he would fall into that one :p [07:57] mpt: hey, would you provide the green/yellow icons for https://wiki.ubuntu.com/SoftwareAndUpdatesSettings#drivers or should I just try to play with the jockey ones and turn the green one to other colors? [07:58] didrocks, please report a bug and assign it to ~jnick-tait [07:59] mpt: doing so [08:03] mpt: bug #1025562 FYI [08:03] Launchpad bug 1025562 in software-properties "Need green/yellow/red icons for software-properties driver installation spec" [Undecided,New] https://launchpad.net/bugs/1025562 [08:03] not sure if he's reading them :) [08:43] RAOF, hey [08:44] RAOF, do you have a minute to discuss xorg,apport? [08:49] pitti: (saw the recommended addition, thanks!), do you need any help for the rest? the device API and the manually installed one? [08:50] didrocks: I'll get to it; I'm currently working on something else, but I'll return to u-d-common in < 1 h [08:50] pitti: just offering my help if needed, but yeah, you will probably be more efficient that I can ever be on that. No hurry btw ;) === popey_ is now known as popey [10:38] mvo, hey, do you know if glatzor is around atm? cjwatson replied to him on bug #926340 and it would be nice to get that fix included in 12.04.1 [10:38] Launchpad bug 926340 in aptdaemon "aptd crashed with UnicodeDecodeError in _set_error(): 'ascii' codec can't decode byte 0xc3 in position 9: ordinal not in range(128)" [High,Fix committed] https://launchpad.net/bugs/926340 === jibel_ is now known as jibel [10:39] didrocks: ok, getting back to this, had to fix something else first; how does http://paste.ubuntu.com/1096416/ look to you? [10:41] didrocks: this is extensible for the 'device_type': 'wifi' flag we discussed earlier, but that'll be a separate step [10:43] mvo, is there any way somebody from your team could help to verify bug #803280 as well? it's in -proposed for 42 days [10:43] Launchpad bug 803280 in piston-mini-client "software-center crashed with OSError in makedirs(): [Errno 17] El fichero ya existe: '/home/ubuntu/.cache/software-center/rnrclient'" [Medium,Fix committed] https://launchpad.net/bugs/803280 [10:43] jibel: around? [11:09] pitti: yeah, I went outside for a run (need shower now ;)). A manually installed driver will just have from_distro to False and recommended to False, right? [11:09] didrocks: there is no 'manual' yet, that'll get added later as well [11:09] pitti: yeah, device_type will be in the device info dict I guess [11:09] ok :) [11:09] didrocks: ^ yes [11:10] pitti: otherwise, from that, looks good :) [11:10] didrocks: I was mostly asking about the structure of theh result [11:10] looks like what is needed [11:10] do you ensure the keys are there? [11:10] like if builtin is true [11:10] do you still put the free/from_distro ? [11:11] keys [11:12] didrocks: let's discuss in bug 1025632, I just filed that [11:12] Launchpad bug 1025632 in ubuntu-drivers-common "Add "manual install" flag" [Undecided,In progress] https://launchpad.net/bugs/1025632 [11:13] didrocks: I just updated the description to what I believe is more sensible [11:13] pitti: as the qa guy around here: can you tell we what makes https://jenkins.qa.ubuntu.com/view/Quantal/view/All%20Quantal/job/quantal-pkg-libreoffice/ have red bubbles? I see no obvious error in the log .... [11:14] didrocks: i. e. not add it to the driver package info, but to the device info (i. e. "this device has a manually installed driver, don't touch it") [11:14] Sweetshark: [11:14] Err http://archive.ubuntu.com/ubuntu/ quantal/universe libservlet3.0-java all 7.0.27-1 [11:14] 404 Not Found [IP: 91.189.92.181 80] [11:14] E: pbuilder-satisfydepends failed. [11:14] Sweetshark: from https://jenkins.qa.ubuntu.com/view/Quantal/view/All%20Quantal/job/quantal-pkg-libreoffice/ARCH=amd64,label=albali/53/console [11:15] just needs a retry, I guess [11:15] pitti: ah, ok. [11:15] didrocks: do have a shower first, I'll have lunch now anyway [11:15] didrocks: I'll add the manual stuff separately [11:15] pitti: yeah, I'll think about it during my shower :) [11:16] because I think mpt would like that we think of a way to tell "remove this manually install drivers" [11:16] but yeah, it's not trivial :/ [11:17] didrocks, pitti, that UI requires only a way to say "use this driver instead of the manually installed one". That might require uninstalling the manually installed one, I don't know. [11:17] pitti: I was just talking to jason about testing in general. It seems to me we could switch to directly build the upstream release branch (not tagged only rcs) now as the branch is stable enough. I wonder about reporting this back to upstream though (which jason was interested in) ... [11:17] mpt: I don't think we can do that safely [11:18] mpt: I think for now the UI shouldn't try and mess up your manual installation [11:18] ... if we fail to often because of such flukes, upstream wouldnt be happy with it. [11:19] pitti, does that mean if you have a manually installed driver, it is impossible to graphically present "use one of these packaged drivers instead"? [11:20] i.e. would we have to grey out those radio buttons in that case? [11:21] mpt: in general, yes; for the nvidia driver in particular there might be a way to get rid of it, but I'd need to ask tseliot [11:21] but as we have quite a lot of other drivers, the UI does need to consider this possibility [11:21] i. e. just show "manually installed driver" with no options [11:22] * pitti bbl, lunch [11:24] that does seem a bit weird [11:24] mpt: pitti: what do you think about just showing all of them, and grey all of them apart from the manual installed one + a note telling that removing it should be manual? === MacSlow is now known as MacSlow|lunch [11:25] didrocks, pitti, specification updated. https://wiki.ubuntu.com/SoftwareAndUpdatesSettings?action=diff&rev2=17&rev1=16 [11:25] like on the label stating "This device may work… " or "This device is not working…" [11:25] * didrocks refreshes [11:25] mpt: no additional note to "This device is using a manually-installed driver." [11:26] like, please remove it manually? [11:28] didrocks, that's verging on being impolite ... We're not offering to do something that we could do, and instead saying "go do it yourself" [11:29] or to put it another way, I don't know how we'd present it in a way that it was obvious why we weren't offering to uninstall it. [11:30] mpt: one could argue that presenting other driver that we have but can't install (greyed) is also getting in the impolite front, like "too bad, you can't use them" :) [11:30] (especially with no explanation why) [11:31] yes, that's true [11:32] ok, let's step back a bit [11:53] pitti, when you say "I think for now the UI shouldn't try and mess up your manual installation", is that because we shouldn't do it for now but should sometime later, because it's dangerous, or some other reason? [12:16] mpt: it'll always be a compromise; we might be able to remove the manual nvidia driver installation, but we won't be able to put it back; and we can't remove the other drivers if they are installed manually [12:16] mpt: thanks for the spec update! [12:17] pitti: look at my comment on the bug report if we need to still display the others but disabled [12:17] didrocks: ok, so we'll keep the drivers map, but add the manual flag to the device props? [12:18] pitti: yeah, seems to make totally sense [12:18] didrocks: description updated [12:18] pitti: you will put one of those in the fake service data you provide? (not sure if they are just a static list or linked to your tests) [12:19] didrocks: fake service data? [12:19] pitti: looking good, thanks! [12:19] didrocks: and what's "on of those"? [12:19] pitti: /usr/share/ubuntu-drivers-common/fake-devices-wrapper [12:19] didrocks: ah, we can't fake module existance that easily [12:19] one of those == one manually installed device [12:19] didrocks: I'll add a test case for it, though [12:20] didrocks: if we need it for the wrapper as well, I'll think about how to do that [12:20] pitti: oh? you are not just sending some static dict? [12:20] didrocks: yeah, I think I have an idea [12:20] \o/ [12:21] that would be sweet so that we can have all static data and cases into the wrapper [12:21] didrocks: nah, this builds an actual sysfs tree [12:21] oh ok [12:22] but it could grow an option to claim that a particular module is installed, with a wrapper modinfo program [12:22] which we put into $PATH [12:23] interesting, so mapping our own fake modinfo :) [12:23] pitti: seems you are really taking the wrapper seriously, I thought it was just a small testing tool :) [12:24] it is a small testing tool [12:24] but it's using the same "fakesys.py" as the test suite [12:24] I am working on getting a generalization of this into gudev itself, BTW [12:24] so that you can use it from C and from GI [12:24] excellent :) [12:24] and don't have to copy&paste that between projects [12:25] we need to fake nonexisting hardware in quite a lot of places [12:25] yeah, that would really rock! Hardware testing/getting info/drivers seems to be too much plumbings to mock to reinvent the wheel everytime [12:25] I have the patches ready already, it just needs some more convincing to Kay [12:26] good luck ;) [12:34] happy tuesday [12:34] happy tuesday desrt! [12:35] desrt: happy tuesday indeed! [12:35] didrocks: how's PS-world shaping up? [12:35] Sweetshark: good news? [12:35] desrt: squaddy ;) [12:36] * desrt wonders if he is about to be taught some english by a frenchman [12:36] oh hi desrt, how is it going? [12:37] larsu: hey. how was your vaca? [12:37] desrt, awesome :) [12:37] desrt: just made up the word after finding some interesting definition on urban dictionary :) [12:37] larsu: go anywhere? [12:37] desrt: http://skyfromme.wordpress.com/2012/07/16/call-for-testing-ubuntu-libreoffice-packages/ <- good news even have a soundtrack [12:37] didrocks: ya... i think i found those same 'interesting' definitions as well :) [12:37] desrt, yeah, canoeing in Sweden [12:37] larsu: cool. what part? [12:37] desrt, Dalsland [12:37] (about two hours north of Gothenburg) [12:38] i'm seeing that [12:38] do your friends/parent/etc have a place up there or is it more of a park type of thing? [12:38] desrt: (please note, that I do not have a lifejournal anymore -- I remember you complaining about that) [12:39] Sweetshark: i am very unlikely to test libreoffice :) [12:39] Sweetshark: but just so you know, i hate wordpress as well [12:39] i should know -- i use it :) [12:40] desrt, it's not a park, but you can camp anywhere in Sweden. (There were some small camping-like sites with some firewood and shelter, though) [12:41] ah. i think i've heard of this rule. [12:41] pretty neat [12:41] desrt: *hrhr* I hope you dont have anything like http://skyfromme.wordpress.com/2012/07/16/move-from-livejournal/ to report -- If you had I would not have had to bother with moving ... [12:42] definitely, but I guess it wouldn't work very well in more densly populated countries... [12:42] Sweetshark: i just hate how it fails to post what i tell it to [12:42] and its comment handling is some kind of disaster as well [12:42] larsu: so you're in charge of that gtkmenu work, i hope you know :) [12:42] desrt: did it postpone a "immediate release" post for 6 hours for you? [12:42] Sweetshark: no [12:43] desrt: see? what are you complaining! [12:43] ;) [12:43] desrt, I figured. Do you have a plan for the accel stuff yet? [12:43] that's the only thing missing, right? [12:43] nope. was wondering if you'd cook one up :) [12:44] my brain is in a totally different place lately [12:44] * desrt just turned over 6000 lines in dconf the past few weeks [12:44] hm, really? I'm really busy trying to land the new messaging menu api [12:44] desrt, is there list support in those 6000 lines? [12:44] incidentally, i discovered that locking is really really really bad [12:44] larsu: no. that comes next. [12:45] great [12:45] pthread_mutex_lock() is _slow_ [12:46] desrt, re accels: what's the problem? Just getting them to work again? [12:46] ya [12:46] desrt: depends on what kind of lock you're using [12:46] i never really _fully_ understood how they work [12:46] * larsu neither [12:46] mclasen did them [12:47] i think there's this weird global state in gtk that maps accel names to key sequences [12:47] and the menu items associate themselves with accel names [12:47] in the case of GAction they do it by action name [12:47] ok thanks, I'll look into it [12:47] so the menu item will go look up "/app.quit" in the global accel map to find out what key sequence it should bind to [12:47] then ((magic)) [12:47] where are the accels defined? [12:48] they get inserted with gtk_application_add_accel [12:48] ah okay [12:48] which gets called as well when adding a menu that has an accel='' label [12:48] don't be fooled, though [12:48] the accel='' label in the menu doesn't actually do anything for the menu :) [12:48] the whole thing is slightly BS. i probably wouldn't have allowed it to happen if i knew how crazy it was [12:50] desrt: but you have different kind of pthread mutexes so pthread_mutex_lock doesn't have to be slow :) [12:50] desrt, is it too much work to fix it now? [12:51] larsu: no. i imagine not. [12:51] just gotta wrap your head around it [12:51] the one thing that you may have a bad time with is your action prefixing [12:51] do you include the action prefix when doing the lookup in the global table? [12:51] yes, i guess? [12:52] mlankhorst: hm? [12:52] desrt, iirc, yes [12:53] argh, osx support is incomplete, too [12:53] larsu: i guess the answer is that we will probably not care about accels in any place that prefixing is in use [12:53] larsu: so for now, i guess any prefixing should just cause accels not to be rendered [12:53] larsu: the osx support is working, actually [12:53] or at least it was :) [12:53] not with prefixing, though [12:54] I need accel rendering for some indicators, but maybe we can fake it for now (as those are desktop-wide keybindings anyway) [12:54] ya [12:54] that's a really interesting situation :) [12:56] desrt: you have a ton of options with pthread_mutex, whether you want it global or local (local to process is slightly faster), recursive, error checking, with priority inheritance (rt mutexes) :-) [12:56] mlankhorst: they're all slow [12:57] mlankhorst: and the large number of choices i have makes it even slower [12:57] shouldn't be slow with futexes at least [12:57] pitti, I wasn't imagining that you would be able to switch back to the manually installed driver afterwards [12:57] mlankhorst: the slowness comes from the global synchronisation step required to flush out the write cache and do an atomic operation [12:57] ah [12:58] no matter what type of lock i'm using (unless it's thread-local ;)) i'm gonna hit that [12:58] what good would a thread local lock be [12:58] :p [12:58] and depends if you have coherent cache or not :D [12:59] so yeah I'd guess on arm it would be slow === MacSlow|lunch is now known as MacSlow [13:18] pitti: I can try and remove whatever the Nvidia installer did but this won't guarantee that the system will be ok afterwards [13:20] tseliot: yeah, thought so; would you recommend we best leave it alone when there is a manual install? [13:22] seb128: poke [13:22] desrt, hey [13:22] desrt, how are you? [13:22] seb128: good. [13:22] seb128: just wanted to make sure you don't hate me for the release [13:22] does anyone here own a samsung s2 phone? [13:23] desrt, which one? [13:23] dconf [13:23] desrt, I didn't notice it yet so no hate so far ;-) [13:23] sweet! [13:24] * desrt was worried about sonames or some stupid crap like that [13:24] desrt, did you roll the tarball yet? [13:24] ya. yesterday. [13:24] doh, yeah, I see that [13:24] desrt, I'm leaving a bit in my own world this cycle, still being on the LTS :p I let the crack to robert_ancell [13:24] cool [13:24] pitti: I'll try to fix it in my packaging scripts and error out in case of failure [13:24] what are you working on? [13:25] desrt, I will check on it later though [13:25] tseliot: thanks; I also add a mode for this to u-d-common to detect this [13:25] desrt, LTS .1, in 3 words: SRUs, SRUs, SRUs [13:25] desrt, that an trying to fit in pitti's old shoes ;-) [13:25] right. i think you mentioned this. [13:25] tseliot: if the "nvidia" kmod is present, but the nvidia-* package is not installed, we can consider this as manual installation, right? [13:25] pitti: very good [13:26] pitti: yes, unless you've just uninstalled a packaged driver which was in use [13:26] tseliot: modinfo should fail then, though? [13:26] desrt, I'm glad you got the new dconf out though, that will unblock gsettingslist work hopefully, which is showing up in red on our charts ;-) [13:26] tseliot: package removal ought to remove the .ko [13:27] pitti, what phone do you have nowadays? not a s2 by any luck? [13:27] seb128: no, Sony-Ericsson Xperia mini pro [13:27] ok [13:27] if anyone has a samsung s2 and can test libgphoto on it let me know [13:28] I want a phone, not a tablet :) [13:28] seb128: blah blah blah [13:28] pitti, I didn't say galaxy note :p [13:28] seb128: I MUST WRITE MORE TESTS FIRST [13:28] 100% coverage!!! [13:28] seb128: is that really model specific? I had assumed it would be more likely dependent on the android version [13:28] * pitti applauds desrt [13:28] seb128: still, the galaxy mobiles are way too big for my taste [13:29] they are half a tablet [13:29] pitti, well, it is the decade of the *big* phones ... just get a backpack and move with the mases ;) [13:29] pitti, not sure, I crossed http://gphoto.svn.sourceforge.net/viewvc/gphoto/branches/libgphoto2-2_4/libgphoto2/camlibs/ptp2/ptp-pack.c?r1=13960&r2=13959&pathrev=13960 [13:29] *masses [13:29] pitti, and http://gphoto.svn.sourceforge.net/viewvc/gphoto?view=revision&revision=13969 [13:29] seb128: oh, product IDs? [13:30] these would be model specific, yes [13:30] pitti, no, product IDs are trivial to backport [13:30] pitti, those have a bit of specific code [13:31] but I guess I will just skip that and look at backporting if somebody shows up with a device to test or with a bug complaining it doesn't work === zyga is now known as zyga-afk [13:31] pitti, in fact I started because of https://bugs.launchpad.net/bugs/1025598 [13:31] Ubuntu bug 1025598 in shotwell "shotwell doesn't get the new pictures since a few days" [High,Confirmed] [13:32] pitti, but that one seems to be "android 4.1.1 changed something and shotwell,libgphoto don't like it" [13:32] damn android hackers! ;-) [13:32] I'm still running 2.x on my sony [13:44] * desrt rebases the old gsettingsbackend/gsettingslist branch [13:44] * desrt has the next month of uninterrupted pure 100% hacking time to slay this beast [13:44] oh. guadec. crap! [13:51] didrocks: uploaded for now, as I'll call it a day quite soon [13:51] didrocks: will do the manual flag/fake addition tomorrow morning [13:51] pitti: sounds good to me, still making my road in the current code [13:52] but will clearly need cleanage once someone gets time, because it needs it so much (not sure how old this is :)) [13:53] Sweetshark, pong [14:18] jibel: now that the 3.6.0 packaging seems to be mostly stable and the release branch upstream is getting less frantic, I think we can consider switching the qa jenkins to not do a fixed upstream tag, but move along with the upstream release branch. [14:22] jibel: that would mean: a/ deleting the upstream tarballs b/ do a './debian/rules get-orig-source USE_GIT_TARBALLS=y GIT_TAG=libreoffice-3-6' [14:22] which would take whatever is at the upstream release branch atm. [14:25] seb128: I'm switching lo back to v-done unless you're waiting on someone else in your comment [14:26] Sweetshark, ok. I'll update the test script to do that. [14:27] micahg, thanks, no I was not, I just didn't want to do it myself before checking with you since you were the one who moved it to verification-failed [14:28] seb128: thanks, I won't bother with my own testing since the reporter confirmed then [14:29] micahg, ok, works for me, the new comments seem to make it clear that problem was already there in 3.5.3, so yeah, not a regression === zyga-afk is now known as zyga [15:21] didrocks, kenvandine, mterry, Sweetshark, tkamppeter, Laney, mlankhorst, cyphermox: the meeting time is in 10 min if you have any topic to add, please update https://wiki.ubuntu.com/DesktopTeam/Meeting/2012-07-17 (if you are not didrocks) with what you did as well, thanks [15:23] where has the morning gone! [15:23] kenvandine: west [15:24] kenvandine: it's over there galloping into the distance [15:25] seb128: uploading 3.6.0~rc1 [15:26] indeed [15:26] Sweetshark, great [15:26] * mterry has just been doing boring archive stuff :-/ [15:27] seb128: had to redo it it for -sa .. [15:27] Sweetshark, I guess it's taking a while to pack the source ;-) [15:27] * Sweetshark is getting consistent 2MB/s to chinstrap ... [15:27] mterry, soon you will be back on fun stuff ;-) [15:28] seb128: 2min 7 sec in a pbuilder (on a SSD and with 16GB RAM in that machine) [15:28] not too bad [15:29] seb128, it's fun for me! just not fun for reports [15:30] Sweetshark: how many cores? [15:32] mlankhorst: 4+hyperthreading (i7-2720QM) -- its only a notebook. [15:33]