IRC log of #maemo-ssu for Friday, 2012-01-06

*** javispedro has joined #maemo-ssu00:08
*** nox- has joined #maemo-ssu00:08
*** andre__ has quit IRC00:10
*** scoobertron has quit IRC01:09
*** M4rtinK has joined #maemo-ssu01:38
*** javispedro has quit IRC03:04
*** M4rtinK has quit IRC03:17
*** arcean_ has quit IRC03:18
*** javispedro has joined #maemo-ssu03:22
*** amiconn has quit IRC03:42
*** amiconn has joined #maemo-ssu03:42
*** psycho_oreos has joined #maemo-ssu04:07
*** dafox has quit IRC04:08
*** nox- has quit IRC04:19
*** javispedro has quit IRC05:16
*** amiconn_ has joined #maemo-ssu05:17
*** amiconn has quit IRC05:17
*** amiconn_ is now known as amiconn05:18
*** DocScrutinizer has quit IRC08:08
*** DocScrutinizer has joined #maemo-ssu08:09
*** mirandir has joined #maemo-ssu08:42
*** wmarone__ has quit IRC09:22
*** wmarone_ has joined #maemo-ssu09:22
*** fw190 has joined #maemo-ssu09:24
*** scoobertron has joined #maemo-ssu09:29
*** m0use has joined #maemo-ssu09:56
*** scoobertron has quit IRC10:17
*** trbs has joined #maemo-ssu10:25
*** scoobertron has joined #maemo-ssu10:50
*** M4rtinK has joined #maemo-ssu11:46
*** BCMM has joined #maemo-ssu12:18
*** arcean has joined #maemo-ssu13:02
*** andre__ has joined #maemo-ssu13:05
*** fw190 has left #maemo-ssu13:13
*** scoobertron has quit IRC13:23
*** scoobertron has joined #maemo-ssu13:28
*** scoobert1on has joined #maemo-ssu13:29
*** dafox has joined #maemo-ssu14:41
*** BCMM has quit IRC15:21
*** wmarone_ has quit IRC15:54
*** wmarone has joined #maemo-ssu15:54
*** BCMM has joined #maemo-ssu16:00
*** fw190 has joined #maemo-ssu16:07
fw190hello16:07
fw190is there a maemo-ssi team meeting today?16:07
fw190maemo-ssu16:08
andre__normally it should be in 3hours16:09
andre__but sometimes people are around, sometimes not16:09
*** scoobertron has quit IRC16:13
*** scoobertron has joined #maemo-ssu16:13
*** scoobertron has quit IRC16:13
*** scoobert1on has quit IRC16:13
*** scoobertron has joined #maemo-ssu16:14
*** rd has joined #maemo-ssu16:40
*** scoobertron has quit IRC16:52
DocScrutinizerI've actually never seen any proper meeting at Fri 18:00 CET16:58
DocScrutinizeresp not here in this chan16:58
fw190hmmm17:15
fw190I recall that the first one was ok17:15
fw190but it was the last real one17:16
*** Jade has quit IRC17:23
*** dafox has quit IRC17:24
*** Jade has joined #maemo-ssu17:25
*** dafox has joined #maemo-ssu17:37
*** dafox is now known as Guest2635017:37
merlin1991well I'm here17:39
merlin1991but since the testing release still isn't out there is nothing to discuss regarding stable17:39
merlin1991fw190: ^^17:40
fw190OK I understand17:40
fw190I just was thinking that some generall chit chat abut the direction or wasy to imporve would happen ;)17:41
merlin1991well so for I've spooted 2 things that probably will make it into the testing release after this one17:42
merlin1991one is updated obexd stack for proper car kit support17:42
merlin1991and the other thing I didn't spot but Pali said we should include the fix for osso-wlan that fixes a rescan battery drain cycle if you use the injection driver17:43
arceanlocking Qt apps to portrait is not possible without forced rotation17:43
arceanthey're misleading h-d as MBWM_ATOM_HILDON_PORTRAIT_MODE_SUPPORT is set only when the window is about to rotate to portrait17:43
arceanmerlin1991: ^17:43
fw190regarding the obex- is this the thingi from the wiki?17:43
merlin1991yes17:43
merlin1991do you know some problem that exists with it?17:44
fw190well I've installed the files a few times- didn't test it as I don't have a car which supports it but everything works ok17:44
merlin1991arcean: I guess that speaks agains a portrait lock in cssu since we always said that forced rotation is not meant to be enabled by default17:45
arceanyou're right, and I think we should fix the problem in Qt itself17:45
merlin1991we can do that ofc :)17:45
merlin1991so gtk has the flag always set when the application supports portrait?17:46
arceanyes17:46
merlin1991that screams for a fix then :D17:46
arceanindeed17:47
* merlin1991 really would like to know what's up with MohammadAG these days17:47
arceanmoreover with the Qt fix, we would be able to implement better landscape lock, where windows with REQUEST flag17:48
arceanwouldn't be locked to landscape17:48
arceane.g. incoming call UI17:48
merlin1991enlighten me about the request flag17:49
arceanREQUEST means that the window should be displayed in portrait mode even if device is in horizontal position17:49
merlin1991so there is a flag for rotate me depending on orientation and another one for I'm portrait only17:51
arceanyes17:51
* merlin1991 wonders how much sense it makes to honor the 2nd flag in a landscape lock17:52
merlin1991though with the great call-ui we obviously have a point where we need to honor it to get all buttons :/17:52
merlin1991ah yet another thing Pali pointed out18:05
merlin1991there is a repo with updated to the rss reader which looks interesting18:05
merlin1991though the guy there implemented rotation by listening to mce so we'd have to fix that before we include it at all18:05
*** Guest26350 has quit IRC18:12
*** dafox has joined #maemo-ssu18:25
*** dafox is now known as Guest2839118:26
*** arcean_ has joined #maemo-ssu18:30
merlin1991arcean: does the portrait lock need any more adjustments after we fixed qt?18:30
merlin1991arcean_: ^^ :D18:30
*** arcean has quit IRC18:30
*** fw190 has left #maemo-ssu18:32
amiconnCan't the call UI be fixed to work in landscape as well? Or is that one proprietary?18:33
merlin1991that one is proprieatry18:36
merlin1991otherwise we would have fixed it long time ago :D18:36
merlin1991actually the whole sequence of incoming call call ui launch and the call itself is proprietary18:37
DocScrutinizerI still wonder what is the suggested allegedly *right* thing to ask for whether portrait mode or not18:38
*** Guest28391 has quit IRC18:38
DocScrutinizeras I elaborated on several times now, in epic verbosity, there should be one central instance that decides what orientation is the one that user wants right now, and every app should have a enum that has states like landscape_only, portrait_only, allow_both18:42
merlin1991DocScrutinizer: that would be h-d as the central state (our aim here) and the flags as your enum18:42
merlin1991though atm qt still missbehaves18:42
merlin1991s/state/instance/18:43
DocScrutinizerh-d for a central instance is probably as good as any other way. We just need a properly defined API then to tell h-d about orientation lock18:52
DocScrutinizerso on a fictive tablet a fictive slider-switch would lock orientation to what it's ATM, managed by some app that monitors the switch, queries the current orientation from h-d via that API, and then on switch-action tells h-d to freeze orientation to either portrait or landscape (or top-down, or portrait top-down)18:54
merlin1991actually the sanest way would be to have a gconf key "locked" and h-d listens to that key and when it's changed stops rotating apps18:55
DocScrutinizerhmm, I'm not exactly a friend of abusing gconf for API18:56
* DocScrutinizer mumbles d-bus18:56
merlin1991d-bus is an option ofc too :D18:56
* merlin1991 thinks the various gconf keys we have in h-d currently need some refactoring18:57
DocScrutinizerdefinitely18:57
Lava_Crofti concur18:57
merlin1991(as soon as qt is fixed so we have proper knowledge of portrait/not)18:57
Lava_Crofti wonder why nobody ever made a port of a more decent terminal emulator18:57
merlin1991and "forced rotation" should die in hell18:58
Lava_Croftthat was an ugly hack 'solution' anyway18:58
Lava_Croftwell, is18:58
merlin1991it bloats the h-d code heavily whilst not brining much at all18:58
Lava_Crofti used it for a day and then became annoyed with it18:58
merlin1991a decent whitelist for apps that should rotate even though the propagate they shouldn't would be a nice thing18:58
merlin1991but forced rotation is just a huge mess18:59
Lava_Crofti think i quit using it once i noticed the insanely long blacklist that was needed for it to work properly18:59
Lava_Croftapart from all the brokenness18:59
*** psycho_oreos has quit IRC19:00
DocScrutinizermerlin1991: exactly, a proper whitelist/blacklist overriding the "enum" I demanded for apps, is exactly what we need19:02
merlin1991actually what's the consensus about dropping forced-rotation in favour of a proper whitelist?19:02
merlin1991Doc obviously agrees :D19:02
DocScrutinizeryap19:02
DocScrutinizerat least if your definition of "whitelist" isn't as tight as "list of apps that may use portrait"19:06
merlin1991actually by whitelist I mean list of apps that will be rotated to portrait despite their window flags19:07
merlin1991and for everything else we use the window flags19:07
merlin1991maybe forcelist is a more appropriate word19:08
DocScrutinizerit has to be a list with "app=orientation-option" tupels. where "orientation-option is any of: portrait-only, landscape-only, both-allowed, portrait_use-and-freeze-on-start, landscape_use-and-freeze-on-start, portrait_use-and-freeze-anytime, landscape_use-and-freeze-anytime,19:10
DocScrutinizeruse-and-freeze-on-start means: app will start in requested orientation when device held in that orientation when app starts, then the app will stick to that orientation. If orientation wasn't the requested one on start, then app will just behave as if both-allowed was specified19:13
merlin1991I think you solution is troughout but a lil overkill19:15
DocScrutinizeruse-and-freeze-anytime means app starts up like both-allowed was given, but will lock to the requested orientation as soon as device is held so that app will rotate to display that orientation. I.E. when you start an app that has portrait_use-and-freeze-anytime while device is held in landscape, the app will start in landscape, but as soon as you turn device to portrait, the app will act like when portrait-only was given, until app quits19:16
merlin1991forced rotation + blacklist exists in order to get the proprietary apps that work just fine in portrait into portrait, I suggested replacing the current implementation with one that bloats h-d less and is more convenient to use19:18
DocScrutinizermerlin1991: there's not that much overhead in implementing this set of functions, compared to a simpler solution. So while it's maybe a lil overkill, it is a reasonable tradeoff between effort to implement a comprehensive handling and a lean but limited solution19:18
merlin1991true, though in order to get your solution up and running we'd need a proper ui for editing it too19:19
DocScrutinizerthe list I just suggested for sure is extremely convenient to use, except for the problem of keeping per-app settings in one central place rather than per-app19:20
merlin1991I don't really understand the usecase of the freeze options though19:20
merlin1991esepecially the use and freeze19:20
DocScrutinizerthe UI to edit that list is so dirt simple I could implement it with 5 lines of shellscript using any windowing tool.19:21
merlin1991:D19:21
merlin1991anway what is the usecase for use and freeze?19:21
DocScrutinizermerlin1991: the usecases are a bit made up right now, I admit. But I had to come up instantly with something to show we got more than just 1 or 2 options in that list for each app19:22
DocScrutinizerit's just a second conditional in each of the tests for state transitions in the orientation statemachine19:23
merlin1991only thing is as far I understand the code there is no statemachine as of yet19:24
DocScrutinizerthat's the major problem right now19:24
DocScrutinizerthe implementation in h-d probably is abysmally messy19:25
DocScrutinizerright now19:25
merlin1991but lets look at it from a user perspecitve for a moment: the user will usually want to have the application rotated the way he holds the device and ofc only have those applications rotate that still hae a proper ui rotated19:25
merlin1991that is solved at the moment so far that applications have the window flags that tell h-d about possibility of rotating19:25
DocScrutinizermerlin1991: you should know me by now to tell I'm not reacting good on "user *usually* will..."19:26
merlin1991DocScrutinizer: wait a lil :D19:26
merlin1991my argument is still not done :D19:26
merlin1991then there is the problem of applications that work in portrait but don't define said flag --> here we need configuration19:27
DocScrutinizerthenm there are apps that have the flag but look like shit19:27
DocScrutinizerso user don't want this app to rotate19:27
merlin1991and then there is the case where the user holds the device other than he wants the application rotated (due to messed reading of senser lying in bed or whatver) --> lock to enable temporary for any orientation19:28
DocScrutinizerthen there are apps that user always wants to be in a certain orientation: for me that's dialer:portrait, xterm:landscape19:28
DocScrutinizermerlin1991: the user-override of physical orientation is a rather distinct problem and not related to our "white"list problem19:29
merlin1991but it is the rationale for the lock, I simply want everyhting rotation related here :D19:30
merlin1991the thing wit the messed up apps is that they should be fixed in the application itself, certain orientation is already implemented in h-d with the set of 2 flags (dialer has the option) though that could be done outside too19:31
DocScrutinizeryes, for sure there is the obvious need to pretend for all (or almost all) apps that device is in physical portrait orientation while it's actually upside-down or whatever19:31
DocScrutinizermerlin1991: nope, you can not say "this has to be fixed in app, we don't care"19:32
merlin1991yeah yeah19:32
merlin1991so we actually need 2 distinct settings19:32
DocScrutinizerwe need a list of tupels19:33
merlin1991distinct as in logically seperated19:33
DocScrutinizerand we need something in our central instance that allows user to override accelerometer19:33
merlin1991there is the problem of what applications propagate they can do19:33
merlin1991and the user who might to fix it19:33
merlin1991err meant to write and the user who might want to restrict it19:34
DocScrutinizerthe settings-list always overrides what an app propagates19:34
merlin1991I'm just trying to find a way todo this without introducing a statemachine to h-d19:34
DocScrutinizerwhy?19:35
DocScrutinizerwhat's wrong with a nice statemachine?19:35
merlin1991well actually the statemachine is just an implementation thing you're right that that is of no concern19:36
DocScrutinizeractually you already got a statemachine, as for sure you're not triggering a transition to portrait if you are already in portrait19:36
merlin1991hm  I wonder what is more intuitive to use as a lock19:38
DocScrutinizernow you accept that fact, and actually call it staemachine and pull it out of the other code of h-d and aggregate it into a single function, that gets ised at other places in h-d code whenever you need to handle orientation19:38
merlin1991something that locks to the current state, or where you explecitely state what you want19:38
DocScrutinizergets used*19:39
*** arcean_ is now known as arcean19:39
DocScrutinizermerlin1991: as we will do this in a separate process that's using the (d-bus)API to query/lock orientation of h-d statemachine, that doesn't really matter here19:40
DocScrutinizeryou could provide 17 alternative ways, with 17 little orientation-lock apps19:40
merlin1991a configureable status menu plugin, yay for the clusterfuck :D19:41
*** NIN101 has joined #maemo-ssu19:41
merlin1991but yea, I think the sanest solution would be to use window flags by default, and have your idea of state config that overrides it19:42
DocScrutinizer:-)19:42
merlin1991+ the accelerometer override19:42
DocScrutinizer:-)19:42
merlin1991which imo renders most of your "freeze" states m00t19:42
merlin1991at least for me it feels like freezing an application at some point to one orientation is more of a once at a time thing whils locking it to either orientation forever is actually a usecase19:43
DocScrutinizerwell maybe. I already admited that they were a bit made-up. Better ones are: both-aalowed_even-when-orientation-locked19:43
merlin1991that one makes sense :D19:44
DocScrutinizerfor spirit level for example19:44
DocScrutinizerthat relies on properly working display-orientation rotation19:44
merlin1991spirit level?19:45
merlin1991and I have another item on my todo list :D19:46
DocScrutinizerdoesn't make much sense if the spirit level uses another display when rotating to portrait from landscape, and then to freeze that display to a 80° off orientation so the virtual horizon is incorrect19:46
DocScrutinizer90°19:46
DocScrutinizerthere are evidently apps that want to *always* use physical orientation as display-orientation, no matter if user is standing, laying in bed, or doing a handstand19:47
merlin1991yep19:48
merlin1991so my todo list now includes this: hildon-desktop portrait lock / forced rotation / g-conf refactor --> replace current clusterfuck with "window flags" < "lock config" | "accelerometer lock"19:48
DocScrutinizerthat's why I say let's get a config list with tupels, that allows an arbitrary set of options per app19:48
DocScrutinizeraccelerometer lock := API to query current orientation, and to overide accelerometer with a fixed virtual orientation that won't change until reverted via same API19:49
*** int_ua has joined #maemo-ssu19:50
merlin1991can you think of any states other than portrait, landscape, both, bothignorelock ?19:52
DocScrutinizeryes, antiportait, antilandscape19:55
merlin1991?19:55
DocScrutinizerprtriat top-down19:55
DocScrutinizerthere are 4 natural orientations of a screen19:55
DocScrutinizerwhen the screen is a rectangle :-D19:55
DocScrutinizersee xrandr19:56
merlin1991do you think it's sensible to make a 360° gadget out of the n900 keeping in mind that we only have a hw keyboard on one side and no proper rotateable on screen keyboard?19:57
DocScrutinizeryou might want to make that a set of options, all aloowing one aspect:  landscape,portrait,antiportrait,ignorelock19:58
DocScrutinizerand  maybe even something like ~landscape to forbid an option20:00
DocScrutinizeryou also might *specify* orientations face-up, face-down - FWIW. e.g gestures already use face-down for mute20:01
DocScrutinizera spirit level might use a special display for face-up orientation20:01
DocScrutinizera map app as well20:02
DocScrutinizerso specifying all 6 possible orientations isn't an insane thing, though we maybe never will need them for display rotation purposes20:02
DocScrutinizerso: whenever there's a record in configlist for an app, this record overrides all flags the app announced. each record is built like "appname=option[,option]*"20:05
DocScrutinizerall options are and-ed, an option may be "negative" by preceding it with a "~"20:06
DocScrutinizerumm, wait20:06
DocScrutinizerok, we get a wildcard for each logical group of options then, as well: like "acmeapp=all-orientations,~anti-landscape"20:08
DocScrutinizerall-orientations is a shortcut for "landscape,portrait,antilandscape,antiportrait,face-up,facedown"20:09
DocScrutinizerall-orientations is the implicit default when no orientation is given at all20:10
DocScrutinizerso "acme_app="  is same as "acme_app=alorientations"20:11
DocScrutinizerwhile "acme_app=~portrait" is same as "acme_app=allorientations,~portrait"20:12
DocScrutinizerbut "acme_app=portrait" is just that - as soon as any "positive" option is used, the default is the opposite20:13
DocScrutinizerso  "acme_app=portrait" is like "acme_app=~allorientations,portrait"20:14
merlin1991wtf does face up and facedown have todo with the window orientation?20:16
DocScrutinizeractually >>  if first orientation-option starts with "~" use all-orientations for initial value, else use ~all-orientations as initial value <<20:17
*** Robot101 has joined #maemo-ssu20:17
Robot101hey, I've got a bugfix for loudmouth (the Jabber library) which should fix signing in to XMPP servers with wildcard / subjAltName TLS certificates20:18
DocScrutinizermerlin1991: as I already said, the window probably can't rotate orientation to face-up or face-down for now. but we will specify those values in our syntax definition anyway20:18
Robot101how do I get it tested and included in CSSU?20:18
merlin1991Robot101: tested I guess the best way is to throw it at tmo20:18
Robot101I have the .dsc / .tar.gz at the moment with my patch applied, I've been helping someone in #maemo who has the SDK set up so should be able to try it on his N90020:19
Robot101actually two guys there it's broken for atm :)20:19
DocScrutinizerRobot101: is it fixing a part of maemo-MP-pr?20:19
merlin1991DocScrutinizer: yes20:19
DocScrutinizer:nod:20:19
Robot101http://maemo.org/packages/source/view/fremantle_sdk_free_source/loudmouth/1.4.1-0osso10+0m5/20:19
Robot101I have 1.4.1-0osso10.120:19
Robot101I've only touched one file and not gone in with any other changes to avoid any chance of regressions20:20
Robot101and it's actually already-tested code from our new XMPP library Wocky that we wrote to replace Loudmouth20:20
Robot101because it's terrible20:20
DocScrutinizerRobot101: publish it somewhere, preferably on tmo, then after some weeks, with some users testing it, you come here and pester MohammadAG  to include it to Testing20:21
Robot101the patch is http://people.collabora.com/~robot101/loudmouth_1.4.1-0osso10.1.diff20:21
DocScrutinizerhmm, so you say we need to find testers ourselves?20:22
DocScrutinizeror it is already tested?20:22
merlin1991Robot101: as DocScrutinizer get it tested, and in that time please check if the loudmouth source is only avaiaible in the sdk as tar.gz or if you can actually find a public repo20:22
merlin1991then when it's tested pester me and I'll get it onto gitorious and will pester mag to include it to next cssu20:22
Robot101I've not tested this patch - the code is tested and I literally copy-pasted and wrote two defines and about 6 new lines to include it into the file in the same place20:23
Robot101if someone wants to review the patch and check my logic that would be nice20:23
Robot101as it's security-critical20:23
DocScrutinizerhmm, I of course think you're capable to pull such a thing without any oopsies, but I'd prefer to see it tested on two or three devices, prior to including it to next CSSU-T20:24
Robot101merlin1991: the loudmouth is in the sdk as .tar.gz but it's got quite some delta from an upstream release - I could easily repackage it as an orig.tar.gz and a diff.gz if that's preferred20:24
DocScrutinizeryep20:24
DocScrutinizermost apreciated was a clear howto to (build and) install it on a CSSU-T system20:25
merlin1991Robot101: I only mentioned it because some of the maemo sources have public git repos and we like to preserv previous commit history20:25
Robot101DocScrutinizer: dpkg-buildpackage -uc -us -rfakeroot I hope :)20:26
DocScrutinizersure :-D20:26
Robot101( http://people.collabora.com/~robot101/loudmouth_1.4.1-0osso10.1.tar.gz and http://people.collabora.com/~robot101/loudmouth_1.4.1-0osso10.1.dsc )20:26
merlin1991starting a new repo on gitorious with a first commit of "importetd sources from maemo.org" is kinda ugly20:26
DocScrutinizerthen publish somewhere, prolly tmo20:26
DocScrutinizerso somebody can *use* it on a T system20:27
Robot101hrm... I can't even remember if I have a tmo account20:27
DocScrutinizeror stock maemo5 for that purpose20:27
DocScrutinizerany other place is also nice, if you don't like tmo20:27
DocScrutinizerjust provide all that's needed to test it there20:27
DocScrutinizer(modulo the N900 and maemo system ;-D )20:28
Robot101I need someone who has a working M5 scratchbox SDK to build it for me first :D20:28
merlin1991can do20:28
DocScrutinizeroffer a way for users to give feedback20:28
merlin1991gimme 2 mins20:28
merlin1991and Doc stop scaring him off ;)20:28
DocScrutinizerthen when there's some WFM feedback, come here and pester us to get it into T20:29
Robot101DocScrutinizer: yeah seriously man, I don't actually have an N900 any more - I'm meant to be reviewing some contracts atm and this is just me being a good samaritan^W^W^W^Wwork avoidance :D20:29
DocScrutinizernah, Robot101 won't get scared by my ranting :-)20:29
Robot101I'm actually kinda embarrassed it shipped with that so broken :/20:29
Robot101missing subjAltName is I think acceptable (it's comparatively new) but that wildcard implementation is so bogus20:30
Robot101hmmm I wonder if I can pull the SVN history from... er... somewhere... inside... :)20:30
* DocScrutinizer waves20:31
merlin1991Robot101: just have the dude test it and if he reports back with a success story ping me and I'll try to get a few more testers on tmo and eventually make sure it ends up in cssu20:31
Robot101merlin1991: sounds great, thanks20:31
merlin1991okay maemo scratchbox is up and running, time to find out if the build depends of loudmouth are proper20:33
Robot101wow, code here from 2-6 years ago20:34
* Robot101 suddenly feels ooooold20:34
merlin1991Robot101: so there are no publicly avaiable repos for loudmout besides the tarball in the sdk?20:34
merlin1991also tar.gz you posted above includes the patch?20:35
Robot101https://github.com/mhallendal/loudmouth/tree/loudmouth-1-420:35
Robot101and yeah that tar.gz is pre-patched20:35
Robot101and I bumped the package version from 10+0m5 to 10.120:35
merlin1991Robot101: but you said earlier the loudmouth version in meamo is quite a delta from that repo?20:36
Robot101it definitely has a bunch of other stuff - it adds OpenSSL and AsyncNS support on top of upstream20:37
Robot101and it's a comparatively old version20:37
merlin1991I guess we'll go the way of import mameo sources then :/20:37
Robot101how do you pull SVN history into a git branch? I've found the internal repo for Nokia's loudmouth which I could slurp, rebase and do some history scrubbing20:37
merlin1991do you have a gitorious account?20:37
merlin1991git svn co url afaik20:37
Robot101at the least I could at least get a clean diff from 1.4.1 to maemo 1.4.120:38
Robot101so we'd have "import maemo stuff" on top of upstream20:38
merlin1991that would be perfect20:38
merlin1991Robot101:  you could clone the entire svn with  "git-svn clone URL" and the just pull the svn branch you need into your git20:39
merlin1991I don't know how you'd pull a specific svn branch directly20:40
Robot101svn "branches" are just in a different path so there's no problem there20:40
Robot101I can take trunk - all of the releases into maemo were tags off trunk20:40
Robot101the rtcom team was quite well organised :)20:40
merlin1991well git-svn does quite some stuff to svn repos20:40
merlin1991it replicates svn "branches" into real git branches20:41
*** BCMM has quit IRC20:41
merlin1991though the whole import svn into git process can take quite some time depending on the amount of revisions you have20:43
Robot101heh embarrasingly I can't remember where the SVN repos are, just the trac browser for them20:45
Robot101gotta dig in the wiki20:45
merlin1991Robot101: http://188.40.39.11/~christian/cssu/libloudmouth1-0_1.4.1-0osso10.1_armel.deb20:46
Robot101aha, found the SVN URL20:47
merlin1991disregard the earlier link, http://188.40.39.11/~christian/maemo/cssu/libloudmouth1-0_1.4.1-0osso10.1_armel.deb20:48
merlin1991:D20:48
* Robot101 goes on an aptitude yak-shave mission to upgrade perl so he can install git-svn...20:54
merlin1991ouch20:55
Robot101am running some random unstable snapshot20:55
Robot101I'm just a dumb PHB now so I should just run Ubuntu tbh20:55
Robot101I never actually want to upgrade anything20:55
Robot101just worries me I'll be broken without my e-mail / browser / libreoffice / ...20:55
merlin1991PHB? (I really need to read up on TLAs)20:56
Robot101pointy-haired boss, from dilbert :)20:56
merlin1991damn I just looked at the collabora webpage, how on earth is one supposed to fullfill the requirements to get hired20:57
merlin1991requirements include the typical "are you interested in $x, you are perfect if you have 10 years of prior experienece in $x" :D20:58
Robot101merlin1991: the only vacancy there is engineering manager - they're meant to be experienced :)20:59
Robot101we actually tend to hire engineers a lot more... quietly20:59
Robot101people apply to jobs@collabora.com and we've heard of people / seen their OSS contributions, it usually goes pretty quickly21:00
Robot101sometimes we need an expert in $foo and we'll go and try to find someone we know or ask around21:00
merlin1991yeah I noticed that the webpage nearly never contains engineers in the vacancys21:00
Robot101OSS means we can kinda... tell if it's the right kinda person based on if we've heard of them before or not21:01
Robot101we can know about skills and attitude just from someone's name and ask around internally :)21:01
merlin1991well I'm still far away from doing a full time job anyway :D21:01
Robot101we take interns too... :)21:02
Robot101and part-timers / students / etc21:02
merlin1991I would fall into the students category, but I live somewhat outside the usual area according to the contact map21:03
merlin1991(austria that is)21:03
Robot10180% of collabora is outside our offices :)21:03
Robot101crap, that import didn't work properly21:04
merlin1991svn -> git or deb repo -> your system?21:04
Robot101svn -> git21:04
Robot101well I got the src but it only goes back to:21:05
Robot101Author: jlaako <jlaako@64d1ce6a-1406-0410-9ac8-afed03b27183>21:05
Robot101Date:   Wed Oct 17 13:04:24 2007 +000021:05
Robot101Branch the trunk to main level21:05
Robot101comes from somewhere else21:05
DocScrutinizerengineering?21:05
DocScrutinizerwhat engineering?21:05
merlin1991I suppose software ;)21:05
Robot101somewhere else in the repo - this is just how svn works guys :P21:06
Robot101it's just git-svn didn't follow it21:06
Robot101heh, gone from trunk to OSSO-1.x to OSSO-1.021:06
merlin1991I've noticed git-svn only works to a certain degree21:06
Robot101that's the N800 I think... :)21:06
Robot101if I can feed the previous branches to git-svn I can reconstruct all the history, heheh21:07
*** m0use has quit IRC21:07
DocScrutinizerhey Robot101, I'm interested in a part-time remote job21:07
DocScrutinizer:-D21:07
merlin1991or you could try to export a patchset from svn that has a common start to a commit on github and just apply it ;)21:08
DocScrutinizerRobot101: preferably something where I don'21:08
DocScrutinizert have to cope with ClearCase and winXP all day long21:09
Robot101we don't use either21:10
DocScrutinizerI'm pretty good as a catalyst at the interface between EE world and SW department21:10
merlin1991DocScrutinizer: this is #maemo-ssu ;)21:10
Robot101actually I lied, we've got some windows buildslaves because we have a couple of projects to make Telepathy run on different platforms21:10
DocScrutinizerI also can review and maybe even design Architectures, also sw21:11
merlin1991DocScrutinizer: I always thought you're more on the hw side21:12
DocScrutinizerRobot101: plus a few years of not-so-indeepth experience with SIP21:12
DocScrutinizermerlin1991: my heart is, my business always been sw development though, except with Openmoko who hired me for EE21:13
DocScrutinizerRobot101: and I'm extremely good at bashing UIs and suggesting improvements - so let's call that usability21:14
DocScrutinizeryou could sub-sum APIs inder UI maybe21:15
DocScrutinizerunder*21:15
Robot101DocScrutinizer: you can certainly work up a CV and send to jobs@collabora.com21:15
DocScrutinizerI might do that. yes21:16
DocScrutinizerthough I always found it a bit hard to propagate my *real* expertise in a CV, it's usually way too formal21:16
DocScrutinizerand my job description isn't exactly fitting any of the usual stereotypes21:18
DocScrutinizerneither do my ideas of what a contract might look like ;-)21:19
DocScrutinizerfreelancer being my fav for that21:19
DocScrutinizerbasically what I did for #maemo last 2..3 years been sth like 3rd level helpdesk21:21
Robot101we're happy (happier?) with a "oss contributions bragsheet" section of CV21:21
DocScrutinizersometimes even project manager21:21
DocScrutinizeryeah, this "bragsheet" already assumes a certain scheme of producing sth that would show up in written form somewhere21:23
Robot101it does when you write it... :D21:23
DocScrutinizerI'm probably not the right one for this job21:23
DocScrutinizerI'm writing a lot on IRC for example21:24
DocScrutinizerhard to refer to that in a bragsheet21:24
Robot101well mostly it's about knowing people are available and matching them to the stuff we need21:24
DocScrutinizereven harder when it'son private channels21:24
Robot101I don't have a specific job in mind, but I have projects where if I know you're available you could fit21:24
DocScrutinizerthat's why I mentioned it directly here rather than sending an unsolicited application21:25
DocScrutinizerI'd be interested in small jobs right now, like max 25% and of limited duration21:26
DocScrutinizeroption to grow in workload and duration in the future21:26
DocScrutinizerfor now I just started a job to get some working LTE chipsets to 'you', where I'll fix issues in e.g I2C-drivers etc21:27
DocScrutinizerthis being a fultime job I'm only available 25% ATM21:28
DocScrutinizermaybe 50% for a 4 weeks period21:28
merlin1991the priv chan thing is quite true, I hade guys over in #maemo ask me wtf I am since only Mag is visible as cssu front man on tmo21:28
DocScrutinizerotoh I wouldn't ming getting hired on a per-day basis21:28
DocScrutinizermerlin1991: exactly21:29
DocScrutinizermerlin1991: so how are we both going to brag with what we both do here? :-D21:30
merlin1991I'm at least visible on gitorious ;)21:30
DocScrutinizerhehe, I'm somewhat visible on h-e-n21:30
DocScrutinizerunder "special appearance" in "about h-e-n"21:30
* Robot101 is torturing some poor SVN server at projects.maemo.org21:31
Robot101just when it was resting so well, expecting to be put out of its misery soon...21:31
Robot101still importing S+ revisions21:31
Robot101lol21:31
Robot101I don't know how to smush two histories together properly though21:31
Robot101I have the upstream git history, and Nokia SVN history which I'm importing to git21:32
Robot101but the upstream stuff just appeared in Nokia SVN by "commit upstream 1.0.3"21:32
merlin1991checkout the upstream base commit, branch it and rebase --onto the svn history21:32
DocScrutinizerRobot101: my "bragsheet": http://www.google.de/search?q=joerg@openmoko.org21:32
DocScrutinizerif eventually you aka collabora are interested, I'm always ping'able via IRC, or send me a mail to above addr21:34
Robot101hrm21:34
Robot101checksum mismatch21:34
Robot101and git svn just dies21:34
Robot101bad juju :(21:34
*** NIN102 has joined #maemo-ssu21:41
Robot101not sure what that means really - how did it arrive at that error?21:42
Robot101r4756 = e35e49fd64fdd14880d843de5cee3c5d8a4102e1 (refs/remotes/python)21:42
Robot101Checksum mismatch: changelog21:42
Robot101expected: a13ce8bfc31e6bda1e4c5f916464df7e got: 49740d3145665f0f41bd18f83a4d4f4e21:42
*** NIN101 has quit IRC21:42
merlin1991Robot101: sry, I've only used git-svn twice so far and it has been a mess both times21:42
*** ThreeM has quit IRC21:44
*** ThreeM has joined #maemo-ssu21:44
Robot101fail :/21:45
*** scoobertron has joined #maemo-ssu22:00
*** BCMM has joined #maemo-ssu22:02
*** BCMM has quit IRC23:19
*** nox- has joined #maemo-ssu23:55
*** rd has quit IRC23:57

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