| ashadiqi | can i chat now? | 07:05 |
|---|---|---|
| anpok | what is the cross-compilation safe way of querying QT_INSTALL_QML path within cmake? | 09:43 |
| anpok | i have seen scripts calling qmake -query QT_INSTALL_QML? But that seems to fail in sbuild | 09:43 |
| anpok | oh ok Saviq already reported that | 09:53 |
| anpok | boneheads /o\ | 10:01 |
| Saviq | anpok, yeah, the "safe" way is ${CMAKE_INSTALL_LIBDIR}/qt5/qml | 10:24 |
| Saviq | AlbertA, could you please confirm in bug #1364453 what needs to happen | 10:29 |
| ubot5` | bug 1364453 in unity8 (Ubuntu) "Brightness setting does not persist across reboots" [High,Confirmed] https://launchpad.net/bugs/1364453 | 10:29 |
| anpok | Saviq: thx works | 10:41 |
| facundobatista | Buenas | 11:01 |
| === MacSlow is now known as MacSlow|lunch | ||
| === _salem is now known as salem_ | ||
| === ubot5` is now known as ubot5 | ||
| === MacSlow|lunch is now known as MacSlow | ||
| dandrader | dednick, I wonder how come this wasn't crashing http://paste.ubuntu.com/8318782/ As was doing some qtmir changes this test was crashing and I did this change to fix it. | 13:05 |
| greyback | Actual (): USD0.99 | 13:19 |
| greyback | Expected (): 0.99USD | 13:19 |
| greyback | what do I set to fix that test? | 13:19 |
| Saviq | greyback, LC_ALL=C | 13:24 |
| greyback | Saviq: I guessed that, thanks | 13:24 |
| greyback | just wanted confirmation while I waited :) | 13:25 |
| dednick | dandrader: erm. | 13:48 |
| dednick | dandrader: i guess the memory was still valid | 13:49 |
| dednick | dandrader: were you doing test in a debug build maybe? | 13:50 |
| dandrader | dednick, yeah. maybe debug builds clear out freed memory right away | 13:51 |
| dandrader | but release ones don't just bother (aka optimization) | 13:51 |
| dandrader | *just don't | 13:52 |
| dednick | dandrader: ya. probably | 13:52 |
| kgunn | popey: hey, so these are both yours...kinda feels like a dup...wonder if there's a slight nuance diff i'm missing (before i dup) | 13:57 |
| kgunn | bug 1355422 | 13:57 |
| ubot5 | bug 1355422 in unity8 (Ubuntu) "[notifications] Can't dismiss notification bubbles" [High,In progress] https://launchpad.net/bugs/1355422 | 13:57 |
| kgunn | bug 1334855 | 13:58 |
| ubot5 | bug 1334855 in Ubuntu UX "[design] Can't use toolbar while notifications on screen" [Undecided,New] https://launchpad.net/bugs/1334855 | 13:58 |
| popey | yeah, they're same | 13:58 |
| popey | i expect i forgot i filed one | 13:59 |
| popey | yeah, 2 months between them, i certainly forgot ☻ | 13:59 |
| popey | feel free to dupe them. | 13:59 |
| Saviq | karni, https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1368243/comments/2 | 14:02 |
| ubot5 | Ubuntu bug 1368243 in unity-scopes-api (Ubuntu) "Scope consistently causes scope runner crash" [Undecided,New] | 14:02 |
| karni | Saviq: yes | 14:03 |
| karni | Saviq: I'm supposed to run this on the device, or can I adb pull the log and run it on it? | 14:06 |
| karni | on my PC | 14:06 |
| Saviq | karni, device | 14:06 |
| Saviq | karni, although at this point (I assume it's uploaded to errors.u.c it already has all the data) | 14:06 |
| karni | there's no .uploaded file yet | 14:07 |
| Saviq | karni, enough if there's an .upload one | 14:07 |
| Saviq | karni, in general if you have a .crash file, use apport-cli to file it to LP | 14:07 |
| karni | not either | 14:07 |
| Saviq | karni, then yeah, on device | 14:07 |
| karni | ok | 14:07 |
| Saviq | karni, 'cause the .crash doesn't have info from the device yet | 14:07 |
| karni | Saviq: Can I force the upload of the crash files? I'm reading apport-cli and apport-collect manual, and I've got other important work to do as well :( | 14:10 |
| karni | I don't know what's the package name of scope runner | 14:10 |
| karni | and apport-collect won't just take the crash file | 14:10 |
| Saviq | karni, just apport-cli /path/to/crash | 14:10 |
| Saviq | karni, let me know the bug number and I'll dupe as needed (you'll have to subscribe me 'cause bug will be private initially) | 14:11 |
| karni | Saviq: https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1368243/comments/3 | 14:11 |
| ubot5 | Ubuntu bug 1368243 in unity-scopes-api (Ubuntu) "Scope consistently causes scope runner crash" [Undecided,New] | 14:11 |
| Saviq | karni, you can remove the "Reason" line from the .crash file | 14:12 |
| Saviq | karni, you should be able to upload then | 14:12 |
| karni | Saviq: the crash file does not contain a "Reason" word | 14:13 |
| Saviq | karni, looks like the crash collection didn't work then | 14:13 |
| Saviq | karni, steps to repro would be great (or removing the .crash and getting it to crash again, hoping the core will be good) | 14:13 |
| karni | Saviq: repro is very simple. fresh flash (as of today), and open Photos scope | 14:14 |
| karni | I'll include that in the report | 14:14 |
| Saviq | karni, k | 14:14 |
| seb128 | you guys know qml right? do you see anything wrong in http://paste.ubuntu.com/8319172/ | 14:15 |
| seb128 | taht's driving me crazy | 14:15 |
| seb128 | why isn't a text entry widget in a mainview with nothing else getting the keyboard focus by default, even with "focus: true" set | 14:15 |
| Saviq | seb128, because you don't have a FocusScope with focus: true | 14:15 |
| seb128 | Saviq, I though the scope was useful when you had groups of widgets | 14:16 |
| Saviq | seb128, you need at least one, but in any case I'd recommend Component.onCompleted: forceActiveFocus() | 14:16 |
| seb128 | Saviq, thanks, I guess that works, but it still seems qml is being overly complex there | 14:18 |
| seb128 | those sort of things should just work :/ | 14:18 |
| Saviq | seb128, yeah, but setting focus: true without a FocusScope doesn't do much | 14:19 |
| seb128 | Saviq, the concept of focusscope is not easy to grasp, at least to me | 14:20 |
| seb128 | on a normal column layout, there should be one scope and whatever widget has focus: true should get the focus | 14:20 |
| Saviq | seb128, http://qt-project.org/doc/qt-5/qtquick-input-focus.html | 14:20 |
| seb128 | without needing of magic | 14:20 |
| seb128 | Saviq, I read that in the past, I guess I need to read it again | 14:20 |
| seb128 | that's the sort of things that seem to just work in other toolkit, I wonder why it doesn't in qt :/ | 14:21 |
| Saviq | seb128, within a FocusScope there's a chain/hierarchy of items, only one on each hierarchy level can have focus: true | 14:21 |
| Saviq | seb128, that's basically a "cache" of focus | 14:21 |
| Saviq | seb128, meaning that when the FocusScope gets focus, the last child to have focus: true gains activeFocus | 14:21 |
| seb128 | Saviq, well, in my example there is nothing else that could get focus | 14:22 |
| Saviq | seb128, this way you can move focus between FocusScopes while maintaining the focus chain within them | 14:22 |
| seb128 | well I can change the pastbin to MainView { TextInput { }} | 14:22 |
| Saviq | seb128, but only FocusScope handles these | 14:22 |
| * Saviq has no idea how MainView deals with that | 14:22 | |
| seb128 | Saviq, I appreciate it allows for complex scenarios to work | 14:22 |
| seb128 | but it makes simple cases not work | 14:23 |
| seb128 | like one widget on a page | 14:23 |
| seb128 | and focus: true does nothing | 14:23 |
| seb128 | I'm sure I'm not the only appdev to struggle with that ;-) | 14:23 |
| seb128 | Saviq, thanks for the help/explanations! | 14:23 |
| seb128 | Saviq, also on the same example, clicking on the button unfocus the entry, is that normal or a bug? | 14:24 |
| seb128 | http://qt-project.org/doc/qt-5/qml-qtquick-controls-button.html states | 14:24 |
| seb128 | "This property specifies whether the button should gain active focus when pressed. | 14:24 |
| seb128 | The default value is false. | 14:24 |
| seb128 | " | 14:24 |
| Saviq | seb128, you most probably need to set focus: true on the MainView, too | 14:25 |
| seb128 | setting that property to false works | 14:25 |
| seb128 | so I guess the "default value is false" has an iossue | 14:25 |
| seb128 | Saviq, oh, that works indeed ;-) | 14:25 |
| Saviq | seb128, wonder if MainView is a FocusScope actually | 14:26 |
| === shiznix_ is now known as shiznix | ||
| dednick | Cimi: hey. can you look over the changes i've made to https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/indicator-polishing/+merge/229083 since you approved? | 14:49 |
| Cimi | dednick, why are you not in the hangout? :) | 14:49 |
| dednick | Cimi: i am! | 14:50 |
| dednick | seb128: with the datetime sync issue in u8 indicators, how long does it take to resync once the screen is back on? | 14:55 |
| Saviq | dednick, under a minute | 15:03 |
| Saviq | dednick, it looks like it doesn't get the update until it changes again | 15:03 |
| dednick | Saviq: hm. | 15:04 |
| Saviq | dednick, but folks confirmed that if they dbus-query it, it's correct there | 15:04 |
| seb128 | dednick, yeah, less than a minute usually | 15:04 |
| seb128 | but it doesn't seem to be on minute changes | 15:04 |
| dednick | seb128: after the dbus query does the indicator ui sync? or still wrong for a bit? | 15:05 |
| dednick | seb128: you see the datetime thing on krillin? | 15:33 |
| seb128 | dednick, yes | 15:33 |
| seb128 | dednick, that's the device I'm testing on | 15:33 |
| dednick | seb128: can't seem to get it to fail on mako | 15:33 |
| dednick | seb128: will try on krillin | 15:33 |
| seb128 | thanks | 15:33 |
| seb128 | how much did you try? | 15:33 |
| seb128 | it's not consistently happening | 15:33 |
| seb128 | but I can see it several time a day | 15:33 |
| dednick | 2 or 3 times now. bit painfull waiting constantly :) | 15:34 |
| === dandrader is now known as dandrader|afk | ||
| seb128 | well, I don't think waiting/trying after a few minutes is going to work | 15:35 |
| seb128 | though it might, who knows | 15:35 |
| Saviq | dednick, you did disconnect it from usb did you? | 15:35 |
| dednick | Saviq: ya | 15:35 |
| seb128 | typically I pick my krillin from my pocket after an hour not using it, to look at the time | 15:35 |
| dednick | seb128: my last try was about 20 minutes, but no sync issue i could see | 15:36 |
| dednick | but if it's random... | 15:36 |
| seb128 | yeah | 15:36 |
| seb128 | what sort of info would you need when it happens? | 15:36 |
| seb128 | the dbus call to the indicator display the right time | 15:36 |
| seb128 | the greeter/lock and panel are off though | 15:36 |
| dednick | seb128: doesn't it sync straight after you reconnect usb? | 15:38 |
| seb128 | dednick, not sure, going to tell you next time | 15:39 |
| dednick | seb128: how did you check that the datetime was in sync while the indicator was since it's re-syncing quickly | 15:39 |
| seb128 | oh, good point, so "no, it's not resyncing my plugged" | 15:39 |
| dednick | seb128: or did you just connect it, then check | 15:39 |
| seb128 | I did connect and check | 15:39 |
| dednick | ah | 15:39 |
| dednick | mh | 15:40 |
| seb128 | it took like 45 seconds before having it updated | 15:40 |
| seb128 | I had time to poke around and run the command several times | 15:40 |
| seb128 | dednick, ok, in fact just having it | 15:41 |
| dednick | seb128: i know that indicator-datetime goes to sleep sometimes when the screen is off (charles, this is correct right?). So i'm just wondering if it's that. | 15:41 |
| seb128 | my device says :39 | 15:41 |
| seb128 | I connected to usb, no update | 15:41 |
| seb128 | still outdated | 15:41 |
| dednick | seb128: can check process state of indicator-datetime? | 15:41 |
| charles | seb128, is this the issue? https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1359802 | 15:42 |
| ubot5 | Ubuntu bug 1359802 in indicator-datetime (Ubuntu) "header's timestamp can take a minute to update after resume from suspend" [High,In progress] | 15:42 |
| seb128 | dednick, if the indicator was not running, then the "--object-path /com/canonical/indicator/datetime --method org.gtk.Actions.Describe phone-header" would be outdated | 15:42 |
| seb128 | charles, yes | 15:42 |
| charles | seb128, dednick, that one's on my short-term TODO after the brightness slider in i-power | 15:43 |
| dednick | seb128: erm, well it would resume the process through dbus call no? | 15:43 |
| seb128 | dednick, well, that's not enough to have the unity synced thoguh | 15:43 |
| seb128 | I can call the dbus check, get a result | 15:43 |
| seb128 | and still see unity outdated | 15:43 |
| charles | seb128, if unity is out of sync with the service, that's not the same as 1359802 | 15:44 |
| seb128 | charles, indeed not | 15:44 |
| dednick | charles: yeah, the header seems to be correct | 15:44 |
| Saviq | dednick, one other thing I noticed that might be related | 15:44 |
| seb128 | dednick, charles, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1365530 | 15:44 |
| ubot5 | Ubuntu bug 1365530 in unity8 (Ubuntu) "Time in indicator out of sync on resume from suspend" [High,Triaged] | 15:44 |
| Saviq | dednick, when you get a push notification in the notification center menu | 15:44 |
| dednick | seb128: and calling that dbus method doesn't cause the resync? | 15:44 |
| === alecu is now known as PyAr | ||
| seb128 | dednick, need to check again to be sure, but iirc no | 15:45 |
| === PyAr is now known as alecu | ||
| dednick | seb128: ok. thanks | 15:45 |
| Saviq | dednick, the LED doesn't light up until you turn the screen on | 15:45 |
| dednick | LED? | 15:45 |
| dednick | Saviq: ah. | 15:45 |
| dednick | Saviq: you mean the notification LED? | 15:46 |
| seb128 | dednick, charles: hum, just tried, in that case the indicator dbus info was outdated | 15:47 |
| seb128 | so maybe several issues there | 15:47 |
| charles | seb128, how far out of date? | 15:48 |
| charles | >1 minute? | 15:48 |
| seb128 | charles, 3 minutes | 15:48 |
| Saviq | dednick, yeah | 15:49 |
| seb128 | it displayed 44 where time was 47 | 15:49 |
| charles | seb128, you queried indicator-datetime on dbus and it returned a time that was 3 minutes off from the wall clock? | 15:49 |
| seb128 | charles, correct | 15:49 |
| seb128 | $ gdbus call --session --dest com.canonical.indicator.datetime --object-path /com/canonical/indicator/datetime --method org.gtk.Actions.Describe phone-header | 15:49 |
| seb128 | ((true, signature '', [<{'title': <'Upcoming events'>, 'visible': <true>, 'label': <'17:44'>, 'accessible-desc': <'17:44 (a retourné des alertes)'>, 'icon': <('themed', <['alarm-clock', 'alarm']>)>}>]),) | 15:49 |
| seb128 | 15:49 | |
| seb128 | where computer was on 17:47 | 15:49 |
| charles | seb128: ! | 15:49 |
| seb128 | which is the time the phone displayed 15 seconds later | 15:49 |
| dednick | i'm going to start blaming indicator-datetime ;) | 15:50 |
| charles | lol | 15:50 |
| charles | seb128, that's a variation on this theme that I haven't seen before. Is it still happening for you? | 15:50 |
| seb128 | dednick, well, I had cases where the indicator info was right but the unity ui was behind | 15:50 |
| seb128 | charles, "still"? | 15:50 |
| seb128 | the phone is awake now | 15:50 |
| seb128 | let me a few minutes | 15:50 |
| seb128 | but it happens consistently enough | 15:50 |
| seb128 | like I've been 3 occurences in the 15 minutes where we started discussing that | 15:51 |
| charles | seb128, we've discussed this before but in the past iiuc it's always been unity8 and indicator-datetime being out of sync with each other | 15:51 |
| charles | rather than datetime being (>1 min) out of sync with the wall clock | 15:52 |
| charles | seb128, could you please write up how to reproduce that in #1359802 and I will investigate today | 15:52 |
| seb128 | charles, how to reproduce? "wake up your phone, look at the clock" | 15:52 |
| seb128 | not sure what else to write | 15:52 |
| seb128 | charles, | 15:53 |
| seb128 | http://paste.ubuntu.com/8319927/ | 15:53 |
| seb128 | just tried again and got ^ | 15:53 |
| seb128 | basically "press power button to suspend the krillin, unplug from usb, wait a few minutes, press power button, notice time is off, plug usb cable, adb shell and run commands" | 15:54 |
| charles | ack | 15:54 |
| charles | I don't understand why it would lag behind like that | 15:55 |
| charles | it's easier to explain not updating at all | 15:55 |
| charles | but how can it lag 3 minutes behind like that? | 15:55 |
| seb128 | I'm happy to help getting debug info if you tell me what to try/do | 15:56 |
| seb128 | charles, well, it might be "not updating", 3 minutes is about the time I let it on the desk while typing on IRC | 15:56 |
| seb128 | hum, just woke it up | 15:56 |
| seb128 | it was on :54 | 15:56 |
| seb128 | when I turned it off at :53 | 15:56 |
| seb128 | and it should be :56 | 15:56 |
| seb128 | ok, just turned :57 | 15:57 |
| * seb128 turns off and wait another 5 minutes | 15:57 | |
| charles | seb128, so, maybe I'm not asking the question right: | 15:57 |
| charles | 1359802 is about not updating the clock for [1..60] seconds after we wake up from sleep | 15:57 |
| charles | so if the clock went to sleep at :45 and you woke it up at :50, it might still read :45 for up to 60 seconds | 15:58 |
| seb128 | k | 15:58 |
| === dandrader|afk is now known as dandrader | ||
| seb128 | that might be what I'm seeing here | 15:58 |
| charles | so I'm less worried about the size of the offset there (5 minutes) than the time to update (<=1 minute) | 15:58 |
| charles | seb128, if it "fixes" itself in <=1 minute after wakeup then we're still talking about the known bug in 1359802 | 16:01 |
| seb128 | charles, ok, let's assume it's that and see if some issue is remaining once that's fixed | 16:01 |
| charles | ack | 16:01 |
| seb128 | charles, but I had cases some ~10 days ago where the indicator time was right on dbus but the unity ui was not | 16:02 |
| charles | after that lands I'll start blaming dednick again | 16:02 |
| seb128 | but let's do one issue at tim | 16:02 |
| seb128 | e | 16:02 |
| charles | seb128, there was one fix for that a couple of weeks ago that I think dednick landed already | 16:02 |
| seb128 | right | 16:02 |
| charles | seb128, that was around the same time that the datetime indicator was showing up completely empty | 16:02 |
| seb128 | I had that fix for sure | 16:02 |
| seb128 | it was like a week after the fix landed | 16:02 |
| charles | ugh | 16:03 |
| seb128 | jibel confirmed that | 16:03 |
| dednick | i'm wondering if fixing 1359802 will just hide the other problem by forcing a reconnection or something | 16:05 |
| dednick | i'm sorting out my krillin device now. hopefully will be able to put some logging in to find out what's up. | 16:07 |
| dednick | if i can reproduce it :) | 16:07 |
| Saviq | bug #1359802 | 16:09 |
| ubot5 | bug 1359802 in indicator-datetime (Ubuntu) "header's timestamp can take a minute to update after resume from suspend" [High,In progress] https://launchpad.net/bugs/1359802 | 16:09 |
| dednick | Saviq: ya, it's possible there are 2 bugs | 16:11 |
| mzanetti | bregma: hi, I think we're good to go with this now. I've fixed all of Saviq's concerns: https://code.launchpad.net/~mzanetti/unity/new-key-in-launcher-schema/+merge/232199 | 17:09 |
| mzanetti | bregma: what do I need to do to get this released? | 17:09 |
| bregma | mzanetti, you just wait until I do the next Unity landing (soon...) | 17:10 |
| mzanetti | bregma: ok, cool. thanks. Can you ping me when it happened so I can release the unity8 related changes for it? | 17:11 |
| bregma | mzanetti, sure | 17:11 |
| mzanetti | cheers | 17:11 |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| dandrader | greyback, still there? | 18:24 |
| greyback | dandrader: yeah | 18:24 |
| dandrader | greyback, For the MirSurfaceItem test in qtmir I'll need to create a QGuiApplication and a QQuickWindow, just to be able to send touch events to it via QTest::touchEvent() (unless I abstract that away, but I would rather not) | 18:25 |
| dandrader | greyback, so is that a problem is qtmir's "make check" has such a "UI" test? | 18:26 |
| greyback | dandrader: probably yes. We want those tests to run on a headless system | 18:26 |
| greyback | dandrader: I wonder what my Mir guys have | 18:27 |
| dandrader | greyback, so I would need that xvfb setup... so much work | 18:28 |
| greyback | a mock mir server that doesn't talk to hardware would do | 18:28 |
| greyback | is this testing Mir stuff? You need the mirserver QPA? | 18:28 |
| dandrader | greyback, did you read my first sentence? :) | 18:29 |
| greyback | dandrader: I don't understand what you're trying to test | 18:29 |
| dandrader | greyback, I think I will just abstract away MirSurfaceItem::touchEvent() for now. enough for me to test the touch sequence validation thingy | 18:29 |
| dandrader | greyback, a scheme similar (but simpler) to what was done for QtEventFeeder | 18:30 |
| greyback | ok | 18:30 |
| dandrader | greyback, if you disable an item that is currently receiving a touch sequence | 18:30 |
| dandrader | greyback, that item will never get a QEvent::TouchEnd for that sequence | 18:30 |
| dandrader | greyback, QQuickWindow won't send it | 18:31 |
| dandrader | greyback, sounds like a QT bug, although I wouldn't be surprised if they say that you shouldn't disable a touch owner in the first place | 18:31 |
| greyback | dandrader: /me surprised by that. How does a MouseArea deal with it? | 18:31 |
| dandrader | (this kind of stuff) | 18:31 |
| dandrader | greyback, so I'm adding this touch sequence validation before forwarding touch events to the mir surface | 18:32 |
| dandrader | greyback, so things keep working regardless of whether qt fixes that or not | 18:32 |
| greyback | ok, I understand what you're doing at least | 18:32 |
| greyback | am just curious, can MultiPointTouchAreas be confused in a similar fashion? | 18:33 |
| dandrader | greyback, the right question is: how does a client-side QQuickWindow deal with it? | 18:33 |
| greyback | it presumably just waits for the TouchEnd | 18:34 |
| dandrader | greyback, its mouse event emulation gets stuck, just like unity8's QQuickWindow without that qteventfeeder fix | 18:34 |
| greyback | dandrader: could this go in qtubuntu then? | 18:34 |
| greyback | similar event processing that you added to qtmir | 18:34 |
| dandrader | greyback, it could. but I chose to put it in MirSurfaceItem. fixed earlier in the flow of events | 18:35 |
| greyback | dandrader: I just think of using qt apps with another mir server - they would potentially exhibit the same problem? | 18:36 |
| greyback | dandrader: it probably should be fixed in MirSurfaceItem yes, as other toolkits may have the same difficulty | 18:36 |
| dandrader | greyback, you could add validation on both sides | 18:37 |
| greyback | dandrader: keep doing what you're doing anyway. Can look at qtubuntu if we actually see a need to fix that | 18:37 |
| dandrader | greyback, the next step, if we have the time, would be to tackle that issue in Qt itself: reporting a bug and proposing a patch | 18:38 |
| greyback | dandrader: right | 18:38 |
| dandrader | greyback, more important than a qtubuntu-side validation imho | 18:38 |
| greyback | and presumably getting Mir to behave better :) | 18:38 |
| dandrader | greyback, that's what racarr is doing if I'm not mistaken | 18:39 |
| greyback | him and RAOF | 18:39 |
| === Malinux_ is now known as Malinux | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!