| sil2100 | Morning! | 07:01 |
|---|---|---|
| Laney | good day | 08:04 |
| darkxst | Laney, hi | 08:50 |
| darkxst | Laney, might be worth having a gnome3.8 session at UDS, but I am going to struggle with timezones, so will be hard, maybe at a stretch I can do first or last session of the day | 08:56 |
| darkxst | Laney, I think the main things are what is blocking gtk, and what is requited from gsd/gcc | 08:56 |
| Laney | darkxst: hey, alright - could you reply to the list saying so? See what the others say. | 08:57 |
| Laney | yeah | 08:57 |
| darkxst | and Jeremy is away at the moment, and unlikely to make the session | 08:57 |
| darkxst | Laney, will do, but my messages always seem to end up in the moderation queue for ever | 08:59 |
| Laney | hmm | 08:59 |
| Laney | are you subscribed? | 08:59 |
| darkxst | Laney, of course, how else would I see the emails? | 09:00 |
| Laney | web interface maybe | 09:00 |
| Laney | it surprises me that your emails are moderated if you're a subscriber | 09:00 |
| Laney | thought we only had that for -devel | 09:01 |
| Laney | anyway, ta, will see what we can sort out | 09:02 |
| darkxst | Laney, hmm ok, it worked, must have got the lists confused! | 09:06 |
| Laney | heh | 09:06 |
| darkxst | Laney, oh and we really need to land spidermonkey 17 this cycle! | 09:10 |
| * Laney runs | 09:11 | |
| * Laney points at the mozilla guy | 09:12 | |
| darkxst | I got them mozillians to make an official release and still nobody wants it! | 09:13 |
| darkxst | It makes a *huge* difference for gnome-shell though | 09:14 |
| Laney | you should talk to chrisccoulson, he's the maintainer (even in Debian) | 09:15 |
| darkxst | he didnt sound like he had time, last time I spoke with him ;( | 09:15 |
| Laney | although perhaps wants some help... http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=mozjs | 09:15 |
| Laney | maybe offer to move it into pkg-mozilla | 09:15 |
| Laney | or whatever the team is called | 09:16 |
| === tkamppeter_ is now known as tkamppeter | ||
| darkxst | Laney, then it will have to be called IceMonkey? | 09:24 |
| Laney | heh | 09:26 |
| Laney | mozjs is probably alright ... | 09:26 |
| dpm | hi jasoncwarner, we're trying to get the UDS schedule in shape, could you look into scheduling the sessions for the approved blueprints on the client track? http://summit.ubuntu.com/uds-1305/track/client/ | 11:53 |
| dpm | thanks! | 11:53 |
| === alan_g is now known as alan_g|lunch | ||
| sil2100 | attente: ping | 12:52 |
| attente | sil2100, pong | 12:53 |
| sil2100 | attente: are there any special requirements for the unity-gtk-module tests to run or just the unity-gtk3-module package? | 12:54 |
| sil2100 | attente: since I am getting some IndexErrors when doing documents_menu = documents_item[0] etc. | 12:54 |
| attente | sil2100, these are just basic tests to make sure the global menu is working | 12:56 |
| attente | if you open gedit, are the menu items enabled? | 12:57 |
| sil2100 | attente: yes, currently what I see the autopilot tests doing is the mouse moves to the panel, opens up one of the menu entries and closes with failure | 13:02 |
| sil2100 | Let me pastebin the output | 13:03 |
| attente | ok | 13:03 |
| sil2100 | (since I'm porting it to 1.3 now, but this seems to be unrelated to autopilot 1.3, more to pyatspi) | 13:03 |
| attente | it might also be an issue with the detection of the menubar | 13:03 |
| attente | there really isn't a good way of finding it, the test tries to make a guess based on the structure of the widget tree | 13:04 |
| sil2100 | http://paste.ubuntu.com/5647818/ <- the line numbers might be different at your branch, since I modded some imports for the 1.3 transition | 13:05 |
| sil2100 | But it seems to open the menu and hm, maybe not being able to find what it wanted? | 13:06 |
| sil2100 | It was supposed to check for the checked thing | 13:06 |
| attente | yes | 13:08 |
| sil2100 | I wonder why documents_item[0] gives an IndexError | 13:08 |
| attente | maybe it's not being populated in time before the test opens the menu? | 13:09 |
| attente | can you try changing the sleep duration from 0.2 to something like 2.2 at the start of that function | 13:09 |
| desrt | hi everybody!! | 13:12 |
| sil2100 | Hello | 13:13 |
| attente | sil2100, if this doesn't work, can you add the line "print_accessible(app_menu)" just after the app_menu is created on line 296? | 13:13 |
| sil2100 | attente: sadly, didn't work, will add the print thing | 13:13 |
| desrt | hmm. no seb today, again? | 13:13 |
| sil2100 | attente: ok, I have something, this output is really helpful! Now I can finally debug it correctly ;) | 13:15 |
| attente | sil2100, ha, awesome | 13:15 |
| sil2100 | attente: yep, I see the problem, I have been once beaten by this stupidity before | 13:15 |
| attente | sil2100: what is it? | 13:16 |
| sil2100 | attente: not sure if it's only on my system or it's globally, but gedit is one of those applications that exports 'separators' in the main menubar | 13:17 |
| sil2100 | attente: they're not being drawn on the menu since they're empty labels, not taken into account at all | 13:17 |
| sil2100 | attente: so, on my system the Documents item is not 5, it's 7 - since there are 2 empty lables in front of that item | 13:18 |
| * sil2100 sighs | 13:18 | |
| attente | oh, really? | 13:18 |
| attente | hrm | 13:18 |
| sil2100 | attente: we had a bug once with that in the past, even two bugs | 13:18 |
| attente | could you pastebin the debug output you have? | 13:19 |
| sil2100 | Yep, since at least I thought we fixed appmenu not to export separators | 13:19 |
| attente | looks like we'll have to find a smarter way to detect the correct widget | 13:19 |
| sil2100 | http://paste.ubuntu.com/5647852/ | 13:20 |
| sil2100 | I think the easiest way will be looking at the name of the item somehow, just a simple loop on app_menu contents until we find Documents | 13:21 |
| attente | yeah, i'll comb through the tests again to make sure it's not using absolute indexing | 13:22 |
| attente | thanks for this sil2100 | 13:22 |
| sil2100 | attente: no problem! Once you have a branch ready, I'll review and approve and then apply the 1.3 changes over that one | 13:23 |
| sil2100 | Once we do that, we can re-enable the daily-build | 13:23 |
| attente | sure, thanks! | 13:24 |
| === alan_g|lunch is now known as alan_g | ||
| sil2100 | cyphermox: ping | 13:29 |
| attente | sil2100, hey | 13:51 |
| attente | is unity-gtk-module actually running for you? i'm looking at your pastebin and wondering if you might actually have the old libdbusmenu proxy on instead? | 13:52 |
| cyphermox | sil2100: pong | 13:54 |
| sil2100 | attente: well, the GTK module was attached and GTK did not mention any problems, so I thought it was - is there a way I can make sure if it's running or not? | 14:02 |
| sil2100 | cyphermox: hi! Did you re-deploy the QA stack for head recently? | 14:02 |
| sil2100 | cyphermox: since I remember I added autopilot autopilot tests to be run on daily release, but I don't see the check job there | 14:03 |
| sil2100 | cyphermox: at least, I remember adding that to the QA stack config | 14:03 |
| cyphermox | no, I don't think I deployed it | 14:05 |
| cyphermox | we can do that in a minute | 14:06 |
| attente | sil2100, if you don't mind, you can try purging appmenu-gtk and appmenu-gtk3 | 14:06 |
| attente | and then if re-opening gedit puts the menubar back in the window, then the unity-gtk-module isn't doing its job | 14:07 |
| attente | but the pastebin seems to suggest you're still on the old one | 14:08 |
| attente | in which case, what we're doing right now is massaging the tests to work for the old menu proxy | 14:09 |
| sil2100 | attente: so it seems - I purged both of them, I have the menu on the panel but all entries are grayed out | 14:09 |
| sil2100 | And I get: | 14:09 |
| sil2100 | (gedit:20560): Gtk-WARNING **: Failed to load type module: (null) | 14:09 |
| sil2100 | `menu_proxy_module_load': gedit: undefined symbol: menu_proxy_module_load | 14:09 |
| sil2100 | Those errors on gedit load | 14:09 |
| attente | ah, ok | 14:09 |
| attente | so it was using the old menu, and you do have unity-gtk-module is installed, but your indicator-appmenu is missing a patch :) | 14:10 |
| sil2100 | ;) Is the indicator-appmenu patch already merged into trunk? | 14:11 |
| sil2100 | Or is it waiting for unity-gtk-module to be up and running? | 14:11 |
| sil2100 | Also, is there a way we can force the use of unity-gtk-module instead of appmenu-gtk? Since this will be a problem on the test machines | 14:11 |
| attente | so, it looks like it was merged a few days ago, but a new package hasn't been released yet | 14:12 |
| attente | i'm not sure how to force the builders to use unity-gtk-module instead of appmenu-gtk | 14:13 |
| attente | i'd assume that whatever is depending on appmenu-gtk would have to switch | 14:13 |
| attente | indicator-appmenu has recommends on appmenu-gtk* | 14:14 |
| sil2100 | attente: does it make sense to have both installed? Since the easiest way I see is to: | 14:16 |
| attente | if both are installed, then the appmenu-gtk wins every time, iirc | 14:17 |
| sil2100 | hm, give me a moment, need to check something | 14:17 |
| attente | the reason it wins is because of the menu proxy patch in gtk | 14:17 |
| attente | sure | 14:18 |
| === m_conley_away is now known as m_conley | ||
| sil2100 | The problem with the case of unity-gtk-module is that it doesn't really conflict with appmenu-gtk, it just doesn't work then, so doing it in packaging is strange - what's the decision for saucy? Is unity-gtk-module going to replace appmenu-gtk? | 14:29 |
| attente | that's true | 14:31 |
| attente | yes, that's the plan | 14:31 |
| sil2100 | attente: essentially, where, in what application 'component', is the decision made either to use the appmenu-gtk proxy or unity-gtk-module? Is it done on indicator-appmenu's side? | 14:31 |
| sil2100 | attente: since the most elegant way for now would be to make unity-gtk-module 'preferred' if it's available for now it seems, and use appmenu-gtk in all other default situations | 14:32 |
| sil2100 | attente: since I think appmenu-gtk is on the image right now by default, so this might be a problem - we would have to get rid of it from the iso | 14:33 |
| attente | as it is now, if the gtk installed on the user's system has the menu proxy patch, then unity-gtk-module will never work | 14:34 |
| attente | the goal is to entirely replace appmenu-gtk, so we should get rid of appmenu-gtk from the iso as well | 14:35 |
| attente | as such, there's no real way to make one work, and fall back to the other | 14:36 |
| sil2100 | attente: ok, so we'll do that in packaging then, since anyway the goal is to replace appmenu-gtk, then a Replaces tag is the thing we'll need | 14:38 |
| sil2100 | I'll take care of that later on | 14:38 |
| attente | ok, thanks | 14:38 |
| sil2100 | cyphermox: thanks! (I missed your reply earlier ;p ) | 14:38 |
| attente | the reason i brought all of this up in the first place was because i wasn't sure if it was better to have the tests fail when appmenu-gtk is active | 14:39 |
| attente | or if it's better to have the tests work in either case | 14:39 |
| Laney | Replaces isn't what you want - Conflicts might be | 14:41 |
| sil2100 | Getting rid of the hard-coded offsets might be a good idea anyway, since application menus can change in time | 14:41 |
| attente | sil2100, good point | 14:41 |
| attente | Laney: what's the difference between the two? | 14:42 |
| sil2100 | Laney: indeed you might be right, I just used Replaces as a placeholder, since I'll be anyway planning it later on in detail | 14:42 |
| sil2100 | ;) | 14:42 |
| Laney | http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces | 14:42 |
| Laney | attente: Replaces is for overwriting files, Conflicts is for making things go away (or be upgraded) | 14:42 |
| sil2100 | Laney: although there's also a section: "7.6.2 Replacing whole packages, forcing their removal" regarding Replaces | 14:43 |
| sil2100 | Which states to use both at once | 14:43 |
| Laney | yeah | 14:43 |
| Laney | if one package does exactly the same thing as another one | 14:43 |
| === alan_g is now known as alan_g|tea | ||
| cyphermox | sil2100: I can redeploy qa now if you like | 15:03 |
| cyphermox | sil2100: want to review a change for me? https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/job-authtoken-new-api/+merge/163016 | 15:03 |
| cyphermox | sil2100: Replaces + Conflicts: to make things go away and get their files replaced ;) | 15:05 |
| === alan_g|tea is now known as alan_g | ||
| === alan_g is now known as alan_g|life | ||
| sil2100 | attente: ping | 18:43 |
| sil2100 | attente: I approved your branch but it doesn't want to land - do you have autolanding? | 18:44 |
| sil2100 | attente: I wanted your changes to get in first, but it seems I would have to wait too long | 18:48 |
| sil2100 | attente: but here is a 1.3 mod change: | 18:48 |
| sil2100 | https://code.launchpad.net/~sil2100/unity-gtk-module/autopilot_1.3_modifications/+merge/163203 | 18:48 |
| attente | sil2100, thanks | 18:50 |
| attente | there isn't any autolanding for it yet | 18:50 |
| sil2100 | Ah, ok | 18:51 |
| sil2100 | attente: thanks for the test enhancments ;) | 18:52 |
| sil2100 | See you tomorrow! | 18:52 |
| cyphermox | ugh | 19:20 |
| cyphermox | attente: can I help you make autolanding work? | 19:20 |
| attente | cyphermox, sure | 19:26 |
| attente | do you need any changes from me to the source package? | 19:28 |
| === VD is now known as Guest73519 | ||
| robru | cyphermox, ping | 21:23 |
| cyphermox | robru: pong | 21:23 |
| cyphermox | suup | 21:23 |
| robru | cyphermox, https://code.launchpad.net/~robru/cupstream2distro-config/saucy/+merge/163225 is this premature? or a good idea? | 21:24 |
| robru | cyphermox, I think it's premature to release to distro, so this MP keeps things in the PPA... just that I'm running saucy now so I need saucy builds of things ;-) | 21:26 |
| cyphermox | not premature no ;) | 21:26 |
| cyphermox | things should also land in distro where possible actually | 21:26 |
| robru | cyphermox, yeah, but that's on a case-by-case basis, this was a global search and replace ;-) | 21:26 |
| robru | cyphermox, or in other words, each person responsible for each stack should enable theirs one by one... but we need everything saucy now ;-) | 21:27 |
| cyphermox | I agree | 21:27 |
| robru | cyphermox, great | 21:27 |
| cyphermox | actually... | 21:27 |
| cyphermox | hmm | 21:27 |
| robru | oh? | 21:27 |
| cyphermox | I wonder if our friends in #ubuntu-touch not need the stuff in raring still | 21:28 |
| cyphermox | but I guess we should agressively strive to make that saucy anyway | 21:28 |
| robru | cyphermox, this is why we have a review process and I didn't just commit to trunk ;-) | 21:28 |
| cyphermox | it's code, it can be reverted | 21:28 |
| robru | lol | 21:28 |
| cyphermox | we can still build one-off shots | 21:28 |
| robru | true | 21:28 |
| cyphermox | approving! :) | 21:28 |
| robru | great ;-) | 21:28 |
| cyphermox | err | 21:30 |
| cyphermox | I could have sworn I saw something about saucy in our spreadsheet | 21:30 |
| robru | cyphermox, oh, while you're at it, can I get you to push a manual run of the webapps stack? I finally got all the fixes landed in the branches, so I just need to see one manual run succeed and then we can enable webapps for daily releases to saucy | 21:30 |
| cyphermox | I can't find it anymore | 21:30 |
| cyphermox | sure | 21:30 |
| cyphermox | can this wait a few hours? | 21:30 |
| robru | cyphermox, yeah, for sure | 21:30 |
| cyphermox | ok | 21:31 |
| cyphermox | I'll start it in 2 hours or so | 21:31 |
| robru | cyphermox, I'm gonna push an MP against -config for you to review, but no hurry. | 21:31 |
| cyphermox | alright | 21:31 |
| cyphermox | I think we'll wait for didrocks for the rest of the saucy stuff | 21:31 |
| cyphermox | and just make sure everything touch is well landed before | 21:31 |
| robru | cyphermox, fair | 21:31 |
| cyphermox | robru: where is your MP for review | 21:37 |
| cyphermox | ? | 21:37 |
| robru | cyphermox, just writing it now | 21:37 |
| robru | cyphermox, ok, https://code.launchpad.net/~robru/cupstream2distro-config/saucy-webapps/+merge/163227 | 21:38 |
| cyphermox | robru: you're sure it's good to land in archive? | 21:40 |
| robru | cyphermox, yeah! everything is finally working ;-) | 21:40 |
| robru | cyphermox, there is definitely room for improvement with the tests, but we have some basic sanity checks in place. | 21:41 |
| cyphermox | ok | 21:41 |
| cyphermox | I'll give all the code a review too before approving the MR; just because I'm core dev and you need some further code review to land this | 21:42 |
| cyphermox | (and then an archive admin will review) | 21:42 |
| robru | cyphermox, which code review? you mean like debdiffs between new versions vs what was in raring already? | 21:42 |
| cyphermox | yeah | 21:43 |
| cyphermox | pretty much | 21:43 |
| robru | cyphermox, ok, sounds fair | 21:43 |
| cyphermox | that never landed did it? | 21:43 |
| cyphermox | or do you mean it's all already in the archive? | 21:43 |
| robru | cyphermox, no, webapps never daily released in raring. it was only ever manually pushed, and that was a nightmare that's finally coming to an end ;-) | 21:43 |
| achiang | is there a way to turn off compositing in Unity in 13.04 to make it work under Xvnc? | 21:43 |
| cyphermox | if the latter, I don't need to check anything again, I'm just confused | 21:43 |
| cyphermox | oh ok | 21:43 |
| cyphermox | so no special extra review no | 21:43 |
| robru | cyphermox, yeah, these apps are all already in the archive as far as I know, this is just getting newer versions of them via daily release. | 21:44 |
| cyphermox | achiang: I think support was just restarting unity in that case :/ | 21:44 |
| cyphermox | achiang: otherwise I don't know | 21:44 |
| robru | cyphermox, in fact most of them are actully already the same version... it's just that now daily release makes releasing easier when we do make changes | 21:44 |
| cyphermox | robru: ack, that's fine | 21:44 |
| achiang | cyphermox: hm, weird | 21:44 |
| attente | someone mentioned an environment variable for virtualization once which disables compositing i believe, but what variable that is i have no idea | 21:48 |
| cyphermox | let's grep for it ;) | 21:49 |
| attente | hey, maybe: getenv("UNITY_LOW_GFX_MODE")? | 21:51 |
| cyphermox | achiang: UNITY_LOW_GFX_MODE=1 | 21:51 |
| cyphermox | yeah :) | 21:51 |
| * cyphermox high five attente | 21:51 | |
| attente | woo :) | 21:52 |
| achiang | thanks! | 21:52 |
| LeartS | Hi all! I created a patch that fixes a bug in eog (eye of gnome). I proposed the patch upstream, what should I do about downstream (ubuntu/eog)? Make a branch with the patch in debian/patches and propose for merging, post the patch as comment, wait? | 22:01 |
| robru | LeartS, how bad is the bug? distropatches typically have a high maintenance burden associated with them, so usually it's better just to get the new upstream release packaged if possible ;-) | 22:05 |
| cyphermox | right, presumably if the patch was accepted we'll get it soon | 22:07 |
| cyphermox | if it's broken in raring though, we might want to cherry-pick it as SRU if it affects people a lot | 22:08 |
| robru | yeah | 22:08 |
| LeartS | By 'right' you mean wait? Btw it affects raring (it affects every distribution as far as I know) and it's the second most heated bug of eog | 22:09 |
| robru | LeartS, well you might have a strong case for an SRU then ;-) | 22:10 |
| robru | LeartS, so you want to confirm the bug is fixed in Saucy, and then apply the patch as a distropatch on the latest raring package | 22:10 |
| cyphermox | LeartS: what bug? | 22:10 |
| LeartS | #646798 | 22:11 |
| cyphermox | bug 646798 | 22:11 |
| ubot2` | Launchpad bug 646798 in eog (Ubuntu) "eog window size exceeds screen height" [Low,Triaged] https://launchpad.net/bugs/646798 | 22:11 |
| cyphermox | hahaha | 22:11 |
| robru | what's funnny | 22:12 |
| robru | ? | 22:12 |
| LeartS | I'm a newbie. SRU means? | 22:12 |
| robru | LeartS, SRU stands for Stable Release Update. it's the review process we use to ensure that we don't introduce new bugs into old releases of Ubuntu. | 22:13 |
| === m_conley is now known as m_conley_away | ||
| robru | LeartS, so i think the best course of action is to actually get this accepted upstream. The name of the game is that we want the fix to be well-tested before pushing it into raring. Once it's in upstream, it'll make it's way into saucy eventually, and then once it's in saucy you can backport it into raring | 22:14 |
| LeartS | Well, I find it kind of funny (in a sad way) that the bug was first reported almost three years ago, has high visibility, and nobody made a patch (literally 4 lines of code) :( | 22:14 |
| LeartS | Ok :) | 22:15 |
| robru | LeartS, yeah, that's the nature of community development. Unless a problem is really big and bad, nobody cares, or nobody has time. I use EoG all the time and never noticed this or bothered with it | 22:15 |
| cyphermox | LeartS: never noticed it either | 22:16 |
| robru | LeartS, must be an issue only on small screens or something | 22:16 |
| cyphermox | robru: no | 22:16 |
| LeartS | I have a 1600x900 | 22:16 |
| cyphermox | I think it's an issue only when only one dimension of a picture is too large | 22:17 |
| cyphermox | works for me for a radically larger image for both width and eight here; the whole image gets scaled to something that fits | 22:17 |
| robru | cyphermox, well I just opened an image that's 1920x2160 and eog shrunk it to fit on one screen just fine ;-) | 22:18 |
| cyphermox | robru: are you on raring? | 22:18 |
| LeartS | cyphermox: what's you're screen resolution? I'll give you an image size that should give you problems | 22:18 |
| robru | cyphermox, saucy now | 22:18 |
| cyphermox | 1366x768 | 22:18 |
| cyphermox | robru: I wonder if we don't already have the patch? | 22:19 |
| cyphermox | wait, no | 22:19 |
| robru | cyphermox, no, he said it wasn't accepted upstream yet, just proposed | 22:19 |
| cyphermox | right, but that doesn't mean it wasn't committed, or something else wasn't committed to fix the issue | 22:20 |
| LeartS | I have raring, maybe saucy has a patched version? That would be strange because the bug hasn't been marked as closed nor here nor on bugzilla | 22:20 |
| cyphermox | but, we're still on the same version as raring | 22:20 |
| cyphermox | and it's all 3.6.2 | 22:20 |
| LeartS | Let me calc the image size and we'll see | 22:20 |
| cyphermox | LeartS: so you say you have an image that should trigger it? | 22:20 |
| robru | LeartS, so is the issue that eog never shrinks any window? or is there some trick where the image has to be only x amount larger than the screen? | 22:20 |
| cyphermox | oh, if it's square. | 22:21 |
| cyphermox | if (img_width > img_height) { | 22:21 |
| robru | lol, eog doesn't shrink any square images? I guess I don't have any to test ;-) | 22:21 |
| cyphermox | you know... | 22:21 |
| LeartS | cyphermox: try 2732x2000 | 22:22 |
| cyphermox | ok | 22:22 |
| LeartS | no wait, I forgot the 0.75 factor | 22:23 |
| robru | LeartS, nice patch actually, I always love patches that reduce the number of lines of code ;-) | 22:24 |
| cyphermox | yup, obviously broken yet not scaled | 22:25 |
| cyphermox | the image needs to be smaller than screen size, if you don't count decoration | 22:25 |
| robru | Oh, i think I see. the old behavior was just that it only scaled based on if the image was wider, it used the width of the screen, or if the image was taller, it went by the height of the screen. I guess this would produce really strange results if you had a rotated screen that was taller than it was wide. | 22:25 |
| LeartS | cyphermox: 2732*2600 should be even more visible | 22:25 |
| cyphermox | yeah, I see what's up | 22:26 |
| LeartS | robru: the problem is that, even if the image is wider, it may need a "stronger" reduction factor for the height | 22:27 |
| robru | cyphermox, I'm thinking, an image that was wider than it was tall, but not as wide as your screen, but taller than your screen. that should bugger things up. | 22:27 |
| cyphermox | yes | 22:27 |
| cyphermox | well anyway the patch looks good | 22:28 |
| robru | cyphermox, hah, look at that, I just reproduced it ;-) | 22:29 |
| robru | cyphermox, so I made an image that was 1800x1600 and then opened it in eog. quite a bit cut off the bottom there (screen res is 1920x1080, so the image is quite a bit narrower and taller than my screen, without being wider than it is tall | 22:29 |
| cyphermox | yeah | 22:30 |
| robru | cyphermox, I guess back in the days of 4:3 screens, this bug was much less noticable. but it's easier to trigger on a widescreen. | 22:30 |
| cyphermox | LeartS: let's make this a SRU now; can you follow http://wiki.ubuntu.com/StableReleaseUpdates#Procedure and update the bug description? | 22:35 |
| cyphermox | LeartS: and if you can confirm that your email on launchpad is the one we should use to credit you for the change.. | 22:36 |
| LeartS | The bug occurs if the image width is < image height * 3/4 * ratio-of-the-screen and > of image height | 22:37 |
| LeartS | that's the formula :) | 22:37 |
| LeartS | the email is correct, i'm reading the link | 22:37 |
| LeartS | look at the formula: with a 4:3 screen that doesn't ever happen (well, it actually does because of panel and decoration, but is marginal) | 22:38 |
| mfisch | when I select files and right click on them and do compress, anyone know if that is still nautilus? I'm asking because the password protected zip doesn't work | 22:40 |
| mfisch | hmm looks like file-roller not nautilus | 22:41 |
| sarnold | mfisch: that might be for the best, zip encryption isn't very good.. | 22:41 |
| mfisch | there's no failure message | 22:42 |
| sarnold | that's not good :) | 22:42 |
| mfisch | so instead we should just remove the option | 22:42 |
| LeartS | cyphermox: I just have to update the bug description, or also the other steps? | 22:42 |
| mfisch | sarnold: I'll play around with it tonight and see what's going on. There's already a bug saying it can't uncompress encrypted ones | 22:42 |
| cyphermox | LeartS: as many steps as you want to be involved in ;) if you want to prepare a package for the SRU, that's fine too | 22:43 |
| sarnold | mfisch: .. and that's -also- not very kind :) hehe | 22:43 |
| mfisch | at least you know | 22:44 |
| LeartS | Well, I'm new so i'm afraid i may do something wrong. For example, it says: "Check that the bug is fixed in the current development release" but the bug report affects eog (upstream) and eog (ubuntu), not a specific release. Should I edit it to add a specific release (saucy) mark it as fixed for that, and then add another specific release (raring?) | 22:45 |
| LeartS | cyphermox: have patience with me :) | 22:47 |
| cyphermox | LeartS: nah, it's not fixed in the current development release | 23:01 |
| cyphermox | hmm | 23:01 |
| cyphermox | I guess I should upload this particular patch, as soon as we get the review from upstream | 23:01 |
| cyphermox | LeartS: you can skip ahead to after that check; it's no big deal since we should get an answer soon | 23:01 |
| cyphermox | it's really mostly for from point 3 about updating the description | 23:02 |
| LeartS | cyphermox: do you think it's ok as description? | 23:23 |
| LeartS | http://paste.ubuntu.com/5649453/ | 23:23 |
| robru | LeartS, I think your description is way overcomplicated. | 23:25 |
| robru | LeartS, all you need to say is "if the image is wider than it is tall, taller than your screen is, but not wider than the screen" | 23:25 |
| robru | and then give an example like what worked for me, image 1800x1600 displayed on screen 1900x1080 | 23:25 |
| robru | rather than give a complicated formula, nobody's going to understand what that means ;-) | 23:26 |
| LeartS | It's not that complicated (I actually think yours is more intricate to read!), and you're condition is exact (or, better, it's just a subset of when it happens). Also, there is a link to an image that should trigger the bug to most people | 23:29 |
| LeartS | exact -> inexact | 23:30 |
| LeartS | lol | 23:30 |
| robru | LeartS, http://ubuntuone.com/5d3T7gavMutpsvylKIJabD here's a diagram I drew up to better illustrate the situation | 23:30 |
| LeartS | but I could remove the formula I suppose, and just say: If you're screen is wider than taller, use this image | 23:30 |
| robru | LeartS, doesn't really matter if my description is imprecise or only a subset; the point is that it's clear what it says, and people will say "oh yeah, that old code clearly does have that wrong behavior in it" | 23:31 |
| cyphermox | robru: LeartS: just the test case with the image that fails on most usual screen resolutions is fine | 23:32 |
| robru | heh | 23:32 |
| cyphermox | it's basically going to be up to the QA team or me or robru to verify it later anyway | 23:32 |
| robru | funny how I've used eog for years and never noticed this, even with a widescreen where it's more likely to strike | 23:33 |
| LeartS | Someone (is it one of you?) Reviewed the patch upstream | 23:40 |
| robru | nope, I don't have any upstream connections... | 23:49 |
| robru | for eog at least | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!