rogpeppefwereade: i think it's quite straightforward actually09:39
rogpeppefwereade: none of the tools-choosing logic is in the provider currently09:39
fwereaderogpeppe, the tools change? it's probably not *that* big I agree09:40
fwereaderogpeppe, but it's another environ thing the api needs to know/care about and I'm not currently sure I know how that stuff works09:40
rogpeppefwereade: i think it's just a matter of adding some kind of canary tag to an agent's info in the state.09:40
rogpeppefwereade: if the api just provided a way to list the available tools, that would be sufficient, i think09:41
fwereaderogpeppe, I'd rather be able to ask a machine directly what it should be running really09:42
rogpeppefwereade: essentially we'd be making environs.FindAvailableTools call a method on state rather than on the provider (it might even take an interface so it could work on both)09:42
rogpeppefwereade: i dunno, i don't mind much09:43
fwereaderogpeppe, we could indeed do it that way too, I think I'd generally  prefer to keep as much of that sort of work behind the API as possible09:43
rogpeppefwereade: i quite like the idea that an agent can choose how to upgrade itself.09:43
fwereaderogpeppe, maybe it has advantages I'm not seeing09:44
rogpeppefwereade: it's more flexible and it's very similar to the current system, so less churn. it may be more flexible than we need, i dunno.09:45
rogpeppefwereade: i can see the upgrade path more clearly in my head this way09:46
rogpeppefwereade: but that's probably just me being fuzzy headed :-)09:46
fwereaderogpeppe, we'll see how it looks when we actually implement it, that usually forces an extra dose of perspective09:47
rogpeppefwereade: indeed09:47
rogpeppefwereade: i'm hoping we can avoid too many semantic changes as we move towards using the API - they can happen later, i think.09:48
fwereaderogpeppe, agreed in principle at least, I just don't think we can get away with *none*09:49
rogpeppefwereade: we'll see, i guess.09:49
rogpeppefwereade: i'm hoping for none, but there will probably be some necessary.09:49
ahasenackhi guys, how do you update all the branches that go get fetched and placed in $GOPATH/src/*? go get doesn't seem to update12:01
ahasenackyou just go into each one and bzr pull / git pull / hg whatever?12:02
dimiternahasenack: either that, or use go get -u project-import-path/... - will fetch and update the project and all dependencies12:03
ahasenackdimitern: ah, cool, -u is what I was looking for, thanks12:03
rogpeppe"The engineers onside have advised that due to the severity of the damage they have to supply a revised fix date. They have confirmed that it is now 03/05/2013."13:16
rogpeppelooks like my internet is going to continue to be knackered for a while yet then13:16
rogpeppeit will have been dead for two weeks tomorrow :-(13:18
TheMuerogpeppe: at least you'll have hope that it is fixed when we're returning from oakland13:24
mgzgood thing you won't be there next week rogpeppe13:24
rogpeppethat is true13:25
rogpeppenot sure carmen will be very happy with no skype calls tho'13:25
rogpeppenot to mention no bbc iplayer :-)13:25
rogpeppemy phone has been a very busy gateway these last weeks13:27
rogpeppemobile hotspot ftw13:27
=== wedgwood_away is now known as wedgwood
rogpeppe if anyone fancies a non-juju review, here are the first two branches of the new godeps tool: https://codereview.appspot.com/9016043/ https://codereview.appspot.com/9047043/13:54
hazmatrogpeppe,  to avoid the working copy not pointed to master.. ideally you could detect origin/remote to see if its a non default checkout/branch, also a IsModified to check working copy for changes, abort in both cases14:14
mgzhazmat: right.14:15
hazmatfwiw, here's my take atm on a similiar problem, i don't have the branch/origin detection yet though. IsModified was  little tricky with bzr non current revs via the cli, i ended up using it as a lib.. http://bazaar.launchpad.net/~hazmat/juju-deployer/refactor/view/head:/deployer.py#L39214:17
rogpeppehazmat: in a call14:19
rogpeppehazmat: does it really matter if the working copy isn't pointed to master?14:32
mgzrogpeppe: yes, as we were talking about yesterday14:33
mgzyou can make work-in-progress hard to recover (and probably without much sign it's been unlinked)14:34
rogpeppefwereade: is the relation-list CL fixing a bug? it seems to me the change just removes an optional argument. is that right?14:34
fwereaderogpeppe, it drops the arg and uses a flag insteam14:34
fwereadeer instead14:34
rogpeppefwereade: oh yes, i'd missed the fact it wasn't using Var before14:35
rogpeppemgz, hazmat: istm that if we make it easy for the user to restore things as they were (for instance by printing the godeps before the modification) then it's not too bad a problem14:38
mgzthat doesn't help overwriting the head of someone's in-progress feature branch14:38
rogpeppemgz: we wouldn't overwrite any work that couldn't be restored easily14:39
mgzrogpeppe: try it.14:40
rogpeppemgz: ok, i will. what's the exact scenario you have in mind, so i can try it?14:40
mgz`bzr switch -b feature && bzr commit --unchanged -m "Important work, really" && ???`14:43
mgzwe're pretty careful about not chucking stuff away, but you can easily confuse people14:43
rogpeppemgz: what work will be lost there if we do "bzr update -r revid:something" ?14:45
mgzthe question is, what steps do you do to restore your feature branch?14:45
hazmatrogpeppe, in the absence of certainity refuse the temptation to guess, if its modified or non pointing to the origin, bailing is the simplest correct thing to do14:46
rogpeppehazmat: i'm just wondering about the "non pointing to the origin" thing here. what's the "origin" when you're using git for example?14:46
mgz(answer: `bzr update` and perhaps `bzr revert` if there were conflicts, but you need to notice and do those steps to recover,14:47
mgzand, it's different for each vcs)14:47
hazmatrogpeppe, default remote master14:47
rogpeppemgz: will "bzr update revid:foo; bzr update revid:bar" not always end up with revid:bar ?14:48
mgzyes, but you don't know the state of the tree after doing those two commands14:48
rogpeppemgz: insert -r's as appropriate14:48
mgz(the first will helpfully fail if the branch doesn't actualyl contain the revision at least)14:48
rogpeppemgz: oh. i thought the point of "bzr update -r revid:x" was to change the tree to update to revid:x.14:49
mgzalso, git does GC and things, so I don't think you can trust a dangling head will persist for ever14:49
rogpeppemgz: what other state might the tree end up in?14:49
rogpeppemgz: that's an interesting point.14:50
rogpeppemgz: although hopefully it won't be a dangling head, right?14:50
rogpeppemgz: it should be part of the history, and if it's not you should be able to fetch it with go get -u.14:50
rogpeppemgz: oh, i see14:51
rogpeppemgz: you mean the user's dangling head14:51
rogpeppemgz: hmm14:51
mgzrogpeppe: my feature branch removes file X. trunk changes file X. you update my feature branch to trunk... what is X? you update again back to the head rev from the feature branch... what is X?14:51
rogpeppemgz: doesn't a given revid specify file X absolutely?14:52
mgzbzr answer: conflict, you have both varients present in the tree and need ot resolve (or use `bzr revert` to just wipe state back to the current selected rev)14:52
mgzsure, but update is really a three way merge when history has diverged14:53
mgzit's not a "wipe everything and switch to this"... because that's less safe (and has a different spelling)14:54
rogpeppemgz: naively, i'd have thought that X after updating to trunk would be X as changed in trunk (newly created); updating back to the head rev would remove it again.14:54
rogpeppemgz: but you're saying that's not the case?14:54
rogpeppemgz: this destroys my faith in vcs's :-)14:55
mgzit should help encourage you, otherwise your un-landed changes would be much easier to accidentally lose14:55
mgz(and are I think, in one spelling of this people use with git)14:56
rogpeppemgz: i always thought that, given a clean tree, rm -r *; bzr update revid:x; would be semantically the same as bzr update revid:x (but faster)14:57
rogpeppemgz: i still don't quite see where the conflicts come in14:57
mgzit is not.14:57
rogpeppemgz: pardon my lack of vcs-fu14:58
mgzhg handles the same situation by refusing to update to a non-descendant14:58
rogpeppemgz: or ancestor?14:58
fwereaderogpeppe, dimitern: a thought about charm config changes on upgrade-charm14:59
dimiternfwereade: yeah?\15:00
fwereaderogpeppe, dimitern: when a setting type changes, is it *really* any better for us to barf than to just ignore it?15:00
fwereaderogpeppe, dimitern: if we ignore it we just get the default15:00
rogpeppefwereade: i think so15:00
dimiternfwereade: sgtm15:00
rogpeppefwereade: it's an incentive for charm authors to keep things compatible by only adding compatible settings15:01
fwereaderogpeppe, but *actual* compatibility is more than just the type15:01
rogpeppefwereade: sure. the new charm must declare all the old settings, right?15:02
fwereaderogpeppe, nope, we just discard ones that are now irrelevant15:02
fwereaderogpeppe, maybe *that* is crazy15:02
rogpeppefwereade: so you're proposing that there are no charm settings compatibility rules at all?15:02
fwereaderogpeppe, but I don;t *think* so15:02
rogpeppes/there are/there should be/15:02
fwereaderogpeppe, the only one that was ever mooted was the type one, and I'm struggling to see what value it delivers15:03
fwereaderogpeppe, delete is fine and add-new is fine15:03
rogpeppefwereade: i thought it was stronger than that. i think that the new charm should declare all the old settings and they should be of the same type.15:03
fwereaderogpeppe, so if a newer version of a charm adds some smarts that render some option irrelevant, it has to carry them forever?15:04
rogpeppefwereade: yeah. that's compatibility for you.15:04
fwereaderogpeppe, I don;t think that's helpful15:04
rogpeppefwereade: i think that settings are a good indicator of compatibility. relations not nearly so much.15:05
fwereaderogpeppe, this means that there's never any incentive to make a charm smarter -- once there's a config setting, the charm author either has to support it forever and allow it to override (complex) or just ignore a published config setting (evil)15:05
fwereaderogpeppe, the relations *are* a hard constraint15:05
rogpeppefwereade: yes, but loads of very different charms declare the same relations, right?15:06
fwereaderogpeppe, allowing a charm upgrade to break an existing relation is I think clearly not ok15:06
rogpeppefwereade: agreed. but my point is that's not a very strong constraint15:06
fwereaderogpeppe, yeah, that's inevitable15:06
fwereaderogpeppe, --switch has valid use cases, but they are tiny islands of sanity in a great ocean of borken15:07
rogpeppefwereade: i think that specifying settings compatibility makes the islands substantially larger15:07
fwereaderogpeppe, it just feels like walling off one tiny area of the borkenness and saying "this is really really bad" should probably be justified a bit more strongly15:07
fwereaderogpeppe, what is the benefit of not allowing config settings to be deleted?15:08
rogpeppefwereade: how about an explicit "deprecated" type?15:08
rogpeppefwereade: so you can upgrade to deprecated and deprecated settings can be deleted.15:09
fwereaderogpeppe, but we still have to carry "deprecated" forever, and I don't see who's helped by this15:09
rogpeppefwereade: that gives charm authors a path to deleting settings.15:10
fwereaderogpeppe, I don't see how it improves on just deleting the settings straight off15:10
rogpeppefwereade: it means we have much greater confidence that we're not upgrading to a totally unrelated charm15:11
fwereaderogpeppe, ah, sorry, you're proposing that we validate the two charms' schemas against one another15:11
rogpeppefwereade: isn't that essentially what we're currently doing?15:12
rogpeppefwereade: except we only validate some relations15:12
fwereaderogpeppe, no, we just validate the old settings against the new schema as forgivingly as possible, *apart* from the types15:12
fwereaderogpeppe, for config15:12
fwereaderogpeppe, and for relations, we validate only that the relations the charm is currently in can continue to exist15:13
fwereaderogpeppe, --switch is a great big gun that can blow your whole leg off ;)15:13
rogpeppefwereade: here's another much simpler validation scheme: just check that charm.Meta.Name() is the same15:14
rogpeppefwereade: and the relation check too15:14
fwereaderogpeppe, previously considered and discarded, the name is just a heuristic15:15
rogpeppefwereade: aren't heuristics exactly what we're playing at here?15:16
fwereaderogpeppe, I'm more concerned about --switch not allowing something that's sane than about it allowing something that's insane15:16
fwereaderogpeppe, the only sanity I think we can legitimately care about is that which maes our own internal state invalid15:16
rogpeppefwereade: i think that people will play by the rules we write15:16
fwereaderogpeppe, everything else is in the hands of the person who hopefully knows well enough what they're doing15:16
rogpeppefwereade: i think some sanity checks are really useful here. it's so easy to type a wrong url15:17
rogpeppefwereade: and the settings compatibility checks seem like a Good Thing to me15:17
rogpeppefwereade: it's not hard to comply with them15:17
rogpeppefwereade: compatibility rules that say you can change something you already support are quite usual15:18
teknicohi, I'm debugging the juju-gui charm and trying to manually run the config-get command, where do I get the client id it needs?15:19
rogpeppefwereade: but i think it's perfectly reasonable to say that the charm name is the lynchpin of compatibility15:19
rogpeppefwereade: heuristic or not. (well, we make it non-heuristic by attaching some semantics to it, i think)15:19
fwereadeteknico, sorry, it's basically impossible... well, not *impossible*, but definitely impractical15:20
fwereadeteknico, will a CLI get not help?15:20
rogpeppemgz: ah, a non-descendant of the same root, i suppose15:22
teknicofwereade, what's a CLI get?15:22
fwereaderogpeppe, `juju get myservice [configkey]`15:22
rogpeppeteknico: ^15:22
fwereadeer teknico ^^15:22
mgzright, it basically refuses to deal with the three-way merge case (which is reasonable)15:23
mgzthough it will still screw you over if you have uncommitted changes and don't pass a flag to abort on that too15:23
teknicofwereade, yes, it does, thank you15:24
fwereadeteknico, sweet15:25
fwereaderogpeppe, I'm still not following how your proposed checks solve user problems15:27
fwereaderogpeppe, I am taking as an idealistic axiom that charms should work correctly with all-default values, which I know is not strictly true, but I have no interest in making it any easier to deploy charms that are broken by default15:28
fwereaderogpeppe, we don't have the ability to track a charm's provenance, and I'm not sure we want to disallow the possibility of one charm being a drop-in replacement for another15:28
rogpeppefwereade: does the install hook get called again when a charm is upgraded?15:28
fwereaderogpeppe, no15:29
rogpeppefwereade: well then. charms should work correctly when *installed from scratch with all-default values*.15:29
rogpeppefwereade: but starting from the middle, probably not15:29
fwereaderogpeppe, what is the value to users in disallowing a --switch to an arbitrary charm? ISTM that we simply *cannot* know for sure that the user is doing something crazy *except* when existing relations do not match15:30
fwereaderogpeppe, I feel like --switch is an implicit "I know what I'm doing" to which the only acceptable failure is "that action is impossible" rather than "that action appears to be bloody stupid" ;)15:31
rogpeppefwereade: ISTM that with such a potentially dangerous feature, we should at least have some sanity checking15:32
fwereaderogpeppe, on the other side, when we're upgrading from the same base url, I don't see any value to fossilizing the config15:32
rogpeppefwereade: yeah, maybe. i'd like to speak to a real user about this issue.15:33
MakyoI'm getting a bunch of panics around mongo when running tests in trunk and out of ideas.  I'm on raring, think that might make a difference?15:34
rogpeppeMakyo: paste?15:35
fwereadem_3, rogpeppe and I would be interested to know (1) what level of safety you will require around upgrade-charm --switch and (2) your views on how liberal we should be wrt config conversion at upgrade-charm time (with or without --switch)15:36
rogpeppefwereade: the user problem i'm imagining is: juju upgrade-charm --switch wordpress # oops, i meant to type one of the dozen other charms that happened to have db and http relations declared.15:36
Makyorogpeppe, http://pastebin.ubuntu.com/5619482/15:37
rogpeppefwereade: perhaps we should do compatibility checks by default, but provide a --force flag to override them15:37
fwereaderogpeppe, I think that if you're using --switch you have a bit of extra responsibility to switch to things that are sane15:37
fwereaderogpeppe, hmm, --force-url?15:37
fwereaderogpeppe, --force's pre-existence is irritating15:38
rogpeppefwereade: what's the name of the flag currently?15:38
fwereaderogpeppe, there isn't one15:38
fwereaderogpeppe, it's to support a use case originally reported by m_315:38
fwereaderogpeppe, it's --switch but nothing has been released with that flag15:39
rogpeppefwereade: oh, darn, i'd forgotten about the existing --force15:39
fwereaderogpeppe, wrt config changes I am not confident, apart from anything else, that every existing charm is compatible with every version of itself15:39
rogpeppefwereade: it's highly unlikely to be.15:40
fwereaderogpeppe, so additional checking breaks upgrades that worked before15:40
fwereaderogpeppe, we could probably get away with that ofc15:40
rogpeppefwereade: but we can probably make the default (non-forced) behaviour reasonably safe15:40
fwereaderogpeppe, what is unsafe about using default values for removed or incompatible settings?15:41
rogpeppefwereade: just that settings are the only decent indicator that we have of whether a charm really is the same15:41
fwereaderogpeppe, charms *ought* to work with default settings, and if they don't I think I am comfortable calling it a charm bug15:42
fwereaderogpeppe, if it's from the same base charm url we have a pretty good indicator already I think15:42
fwereaderogpeppe, and --switch is a big-boy tool15:42
rogpeppefwereade: charms will probably work with default settings, but if you upgrade to a random charm, it will probably not work, because its install hook has never been called15:42
fwereaderogpeppe, right, so be careful with --switch15:43
rogpeppefwereade: we seem to have switched our usual roles here :-)15:43
rogpeppefwereade: what's wrong with using the charm name again?15:44
fwereaderogpeppe, I was pondering that, and I *think* I'm consistent: sync-tools is a *necessity* for a broad class of users, while --force-url (which I think is better than --switch) is a nice feature for a small group of particularly technical users15:44
fwereaderogpeppe, what does it get us? in the normal case it's redundant, in the --force-url case it's an arbitrary safety guard covering part of one blade on an infernal machine ;)15:45
rogpeppefwereade: nice features like that have a tendency to be picked up and used by everyone :-)15:45
rogpeppefwereade: yeah - it's like a safety catch15:45
rogpeppefwereade: it's easy to disable, but useful nonetheless15:46
fwereaderogpeppe, on one barrel of a terrifying scifi multicannon ;)15:46
fwereaderogpeppe, if the nuke doesn't get you the CAM dusting will15:46
rogpeppefwereade: that bad?15:46
rogpeppefwereade: why do we have a charm name anyway?15:47
fwereaderogpeppe, well, yeah, there is an arbitrarily large number of ways a charm can be irreparably broken despite all our checks here15:47
rogpeppefwereade: i see the mooted charm name check as a symbolic check more than anything15:48
=== makyo_ is now known as Makyo
rogpeppestupid python question: how do i easily find the source for a given python package?16:41
rogpeppe i'm about to do find / -name pythonpackage, and i'm sure there's a better way16:41
benjirogpeppe: import foo; foo.__file__16:41
benji(it will normally return a .pyc, just drop the "c" to get the source)16:41
ahasenackor foo.__path__ if it's a module16:42
rogpeppebenji: bingo, thanks16:42
benjimy pleasure16:42
rogpeppemgz, hazmat: i'm thinking that my proposed godeps -u is at least no more dangerous than go get -u, is it?16:53
rogpeppemgz, hazmat: leaving aside for the time being whether that's sufficiently safe or not16:53
mgzgo get -u is indeed a similar thing.16:54
rogpeppemgz: ha, trying your suggested scenario from before: http://paste.ubuntu.com/5619713/16:58
* rogpeppe has reached eod17:01
rogpeppeg'night all17:02
mgzrogpeppe: right, it's not a sane thing to do with that bzr model17:02
=== deryck is now known as deryck[lunch]
marcoceppiSo, does juju-core have the ability to upgrade the current environment in place?18:30
=== deryck[lunch] is now known as deryck
mrammmarcoceppi: it does18:50
mrammmarcoceppi: it currently is limited to minor version upgrades (1.10 to 1.11 for example)18:51
mrammmarcoceppi: but we will be adding major version upgrades in one of the very next minor version releases18:51
marcoceppimramm: at a high level, how does it work? is there a juju command for it - or is it just automagic18:52
mrammthere is a command18:53
mrammso you get to control when the update happens18:53
marcoceppicool, good enough for me18:53
m_3fwereade: sorry I missed the question about --switch earlier... conferencing atm19:39
fwereadem_3, no worries19:39
fwereadem_3, if you have leisure to read a spot of the conversation that went before, for context, I would be interested to know your thoughts19:39
m_3I'm wondering if specific charm version should be shown and then specified, but lemme read a bit more carefully19:40
fwereadem_3, we have a separate --revision, which just updates to the specified revision of the charm a service is already using19:42
fwereadem_3, we probably don't output "upgraded from %s to %s", and surely should19:42
m_3fwereade: yes... I'd almost conider the revision part of the charm namespace19:44
fwereadem_3, not sure what you mean by namespace -- but whenever we describe a charm we should certainly include the rev19:45
m_3fwereade: but anyways... in answer to the orig question, I think that if the user is specifying both the service and the namespace of the new charm explicitly19:46
m_3then a '--force' variant is not nec19:46
m_3fwereade: namespace would mean cs:mysql:5 or local:mysql:3719:47
m_3but not really important19:47
m_3fwereade: should work to have `juju upgrade-charm --switch local:mysql my_database_service`19:47
fwereadem_3, that's the use case I had in mind19:48
m_3and then the equiv `juju upgrade-charm --switch --revision 5 cs:mysql my_database_service`19:48
m_3the "cs:mysql" could be "mysql" of course19:48
fwereadem_3, the idea is that charm urls are inferred just as they would be at deploy time19:48
m_3and --revision optional19:48
fwereadem_3, we currently have it that --switch and --revision are mutually exclusive19:49
fwereadem_3, seemed simpler all round19:49
fwereadem_3, if you're switching, specify the url properly :)19:49
m_3but 1.) still service-specific, and 2.) the presence of '--switch' is enough checking imo19:49
fwereadem_3, if you skip revision, you get latest, which is probably what you meant19:49
m_3fwereade: hmmm.... as to mutially exclusive...19:50
fwereadem_3, --switch foo-1 --revision 219:50
m_3oh, so I only am able to switch from local to the latest store rev?19:50
fwereadem_3, no -- you specify the target charm as precisely as you care to in switch19:50
m_3but how can I specify target charm revision?19:51
m_3other than with '--revision'19:51
m_3oh, just `juju upgrade-charm --revision 5 mysql my_database_service`19:51
fwereadem_3, `--switch foo-1` will be expanded just as it would in deploy to cs:precise/foo-119:51
fwereadem_3, I have clearly not explained well at all19:52
fwereadem_3, no args: latest with same base url19:52
m_3sorry, I'm a bit confused as to how one switches _back_ to the store-based charm19:52
m_3scenario... `juju deploy mysql` gives me cs revision 5 say19:56
m_3find a bug... update local:mysql.. then switch with19:56
m_3sorry... lemme fix the previous19:56
m_3scenario... `juju deploy mysql mydb` gives me cs revision 5 say19:56
m_3`juju upgrade-charm --switch local:mysql mydb`19:56
m_3the fix didn't work... so I revert19:56
m_3but I'd like to revert to mysql '4' in the cs19:56
m_3what would the syntax for this be?19:56
m_3(if the answer is you can only revert back to the latest in the charm store, that's fine)19:56
m_3but does that "switch" require a '--switch'?19:56
fwereadem_3, `--switch mysql` for the latest; `--switch mysql-127` for a specific rev19:56
fwereadem_3, similarly `--switch local:mysql` or `--switch local:mysql-17`19:56
fwereadem_3, balls, thought of a bug, we might infer the wrong series19:56
fwereadem_3, we should take it from the previous charm url, not from the env19:56
fwereadedimitern, ^19:56
m_3fwereade: ack... perfect19:57
m_3fwereade: also not effecting 'myotherdb' service happily singing along on cs:mysql-5, right?19:58
fwereadem_3, shouldn't do -- there is the usual hairiness around local repos but I think it's near-enough orthogonal19:58
m_3fwereade: ack... thanks!  (and thanks roger)19:59
thumpermramm: did you plan some 1:1 calls?21:25
mrammI do21:26
mrammI just found out an hour ago that I need to get all the blueprints in by tomorrow morning21:26
mrammso I am madly working on that stuff right now21:26
mrammbut I should probably take a break and schedule the 1 on 1's or the tyranny of the urgent will get me ;)21:26
mrammthumper: added one for you21:49
mrammalready talked to dave on sunday night, but going to touch base again if he's around21:49
* thumper nods21:53
davecheneymramm: ping, you sent me a meeting invite for 45 mins ago23:32
=== wedgwood is now known as wedgwood_away

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!