| *** javispedro has joined #maemo-ssu | 00:08 | |
| *** nox- has joined #maemo-ssu | 00:08 | |
| *** andre__ has quit IRC | 00:10 | |
| *** scoobertron has quit IRC | 01:09 | |
| *** M4rtinK has joined #maemo-ssu | 01:38 | |
| *** javispedro has quit IRC | 03:04 | |
| *** M4rtinK has quit IRC | 03:17 | |
| *** arcean_ has quit IRC | 03:18 | |
| *** javispedro has joined #maemo-ssu | 03:22 | |
| *** amiconn has quit IRC | 03:42 | |
| *** amiconn has joined #maemo-ssu | 03:42 | |
| *** psycho_oreos has joined #maemo-ssu | 04:07 | |
| *** dafox has quit IRC | 04:08 | |
| *** nox- has quit IRC | 04:19 | |
| *** javispedro has quit IRC | 05:16 | |
| *** amiconn_ has joined #maemo-ssu | 05:17 | |
| *** amiconn has quit IRC | 05:17 | |
| *** amiconn_ is now known as amiconn | 05:18 | |
| *** DocScrutinizer has quit IRC | 08:08 | |
| *** DocScrutinizer has joined #maemo-ssu | 08:09 | |
| *** mirandir has joined #maemo-ssu | 08:42 | |
| *** wmarone__ has quit IRC | 09:22 | |
| *** wmarone_ has joined #maemo-ssu | 09:22 | |
| *** fw190 has joined #maemo-ssu | 09:24 | |
| *** scoobertron has joined #maemo-ssu | 09:29 | |
| *** m0use has joined #maemo-ssu | 09:56 | |
| *** scoobertron has quit IRC | 10:17 | |
| *** trbs has joined #maemo-ssu | 10:25 | |
| *** scoobertron has joined #maemo-ssu | 10:50 | |
| *** M4rtinK has joined #maemo-ssu | 11:46 | |
| *** BCMM has joined #maemo-ssu | 12:18 | |
| *** arcean has joined #maemo-ssu | 13:02 | |
| *** andre__ has joined #maemo-ssu | 13:05 | |
| *** fw190 has left #maemo-ssu | 13:13 | |
| *** scoobertron has quit IRC | 13:23 | |
| *** scoobertron has joined #maemo-ssu | 13:28 | |
| *** scoobert1on has joined #maemo-ssu | 13:29 | |
| *** dafox has joined #maemo-ssu | 14:41 | |
| *** BCMM has quit IRC | 15:21 | |
| *** wmarone_ has quit IRC | 15:54 | |
| *** wmarone has joined #maemo-ssu | 15:54 | |
| *** BCMM has joined #maemo-ssu | 16:00 | |
| *** fw190 has joined #maemo-ssu | 16:07 | |
| fw190 | hello | 16:07 |
|---|---|---|
| fw190 | is there a maemo-ssi team meeting today? | 16:07 |
| fw190 | maemo-ssu | 16:08 |
| andre__ | normally it should be in 3hours | 16:09 |
| andre__ | but sometimes people are around, sometimes not | 16:09 |
| *** scoobertron has quit IRC | 16:13 | |
| *** scoobertron has joined #maemo-ssu | 16:13 | |
| *** scoobertron has quit IRC | 16:13 | |
| *** scoobert1on has quit IRC | 16:13 | |
| *** scoobertron has joined #maemo-ssu | 16:14 | |
| *** rd has joined #maemo-ssu | 16:40 | |
| *** scoobertron has quit IRC | 16:52 | |
| DocScrutinizer | I've actually never seen any proper meeting at Fri 18:00 CET | 16:58 |
| DocScrutinizer | esp not here in this chan | 16:58 |
| fw190 | hmmm | 17:15 |
| fw190 | I recall that the first one was ok | 17:15 |
| fw190 | but it was the last real one | 17:16 |
| *** Jade has quit IRC | 17:23 | |
| *** dafox has quit IRC | 17:24 | |
| *** Jade has joined #maemo-ssu | 17:25 | |
| *** dafox has joined #maemo-ssu | 17:37 | |
| *** dafox is now known as Guest26350 | 17:37 | |
| merlin1991 | well I'm here | 17:39 |
| merlin1991 | but since the testing release still isn't out there is nothing to discuss regarding stable | 17:39 |
| merlin1991 | fw190: ^^ | 17:40 |
| fw190 | OK I understand | 17:40 |
| fw190 | I just was thinking that some generall chit chat abut the direction or wasy to imporve would happen ;) | 17:41 |
| merlin1991 | well so for I've spooted 2 things that probably will make it into the testing release after this one | 17:42 |
| merlin1991 | one is updated obexd stack for proper car kit support | 17:42 |
| merlin1991 | and 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 driver | 17:43 |
| arcean | locking Qt apps to portrait is not possible without forced rotation | 17:43 |
| arcean | they're misleading h-d as MBWM_ATOM_HILDON_PORTRAIT_MODE_SUPPORT is set only when the window is about to rotate to portrait | 17:43 |
| arcean | merlin1991: ^ | 17:43 |
| fw190 | regarding the obex- is this the thingi from the wiki? | 17:43 |
| merlin1991 | yes | 17:43 |
| merlin1991 | do you know some problem that exists with it? | 17:44 |
| fw190 | well 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 ok | 17:44 |
| merlin1991 | arcean: I guess that speaks agains a portrait lock in cssu since we always said that forced rotation is not meant to be enabled by default | 17:45 |
| arcean | you're right, and I think we should fix the problem in Qt itself | 17:45 |
| merlin1991 | we can do that ofc :) | 17:45 |
| merlin1991 | so gtk has the flag always set when the application supports portrait? | 17:46 |
| arcean | yes | 17:46 |
| merlin1991 | that screams for a fix then :D | 17:46 |
| arcean | indeed | 17:47 |
| * merlin1991 really would like to know what's up with MohammadAG these days | 17:47 | |
| arcean | moreover with the Qt fix, we would be able to implement better landscape lock, where windows with REQUEST flag | 17:48 |
| arcean | wouldn't be locked to landscape | 17:48 |
| arcean | e.g. incoming call UI | 17:48 |
| merlin1991 | enlighten me about the request flag | 17:49 |
| arcean | REQUEST means that the window should be displayed in portrait mode even if device is in horizontal position | 17:49 |
| merlin1991 | so there is a flag for rotate me depending on orientation and another one for I'm portrait only | 17:51 |
| arcean | yes | 17:51 |
| * merlin1991 wonders how much sense it makes to honor the 2nd flag in a landscape lock | 17:52 | |
| merlin1991 | though with the great call-ui we obviously have a point where we need to honor it to get all buttons :/ | 17:52 |
| merlin1991 | ah yet another thing Pali pointed out | 18:05 |
| merlin1991 | there is a repo with updated to the rss reader which looks interesting | 18:05 |
| merlin1991 | though the guy there implemented rotation by listening to mce so we'd have to fix that before we include it at all | 18:05 |
| *** Guest26350 has quit IRC | 18:12 | |
| *** dafox has joined #maemo-ssu | 18:25 | |
| *** dafox is now known as Guest28391 | 18:26 | |
| *** arcean_ has joined #maemo-ssu | 18:30 | |
| merlin1991 | arcean: does the portrait lock need any more adjustments after we fixed qt? | 18:30 |
| merlin1991 | arcean_: ^^ :D | 18:30 |
| *** arcean has quit IRC | 18:30 | |
| *** fw190 has left #maemo-ssu | 18:32 | |
| amiconn | Can't the call UI be fixed to work in landscape as well? Or is that one proprietary? | 18:33 |
| merlin1991 | that one is proprieatry | 18:36 |
| merlin1991 | otherwise we would have fixed it long time ago :D | 18:36 |
| merlin1991 | actually the whole sequence of incoming call call ui launch and the call itself is proprietary | 18:37 |
| DocScrutinizer | I still wonder what is the suggested allegedly *right* thing to ask for whether portrait mode or not | 18:38 |
| *** Guest28391 has quit IRC | 18:38 | |
| DocScrutinizer | as 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_both | 18:42 |
| merlin1991 | DocScrutinizer: that would be h-d as the central state (our aim here) and the flags as your enum | 18:42 |
| merlin1991 | though atm qt still missbehaves | 18:42 |
| merlin1991 | s/state/instance/ | 18:43 |
| DocScrutinizer | h-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 lock | 18:52 |
| DocScrutinizer | so 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 |
| merlin1991 | actually 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 apps | 18:55 |
| DocScrutinizer | hmm, I'm not exactly a friend of abusing gconf for API | 18:56 |
| * DocScrutinizer mumbles d-bus | 18:56 | |
| merlin1991 | d-bus is an option ofc too :D | 18:56 |
| * merlin1991 thinks the various gconf keys we have in h-d currently need some refactoring | 18:57 | |
| DocScrutinizer | definitely | 18:57 |
| Lava_Croft | i concur | 18:57 |
| merlin1991 | (as soon as qt is fixed so we have proper knowledge of portrait/not) | 18:57 |
| Lava_Croft | i wonder why nobody ever made a port of a more decent terminal emulator | 18:57 |
| merlin1991 | and "forced rotation" should die in hell | 18:58 |
| Lava_Croft | that was an ugly hack 'solution' anyway | 18:58 |
| Lava_Croft | well, is | 18:58 |
| merlin1991 | it bloats the h-d code heavily whilst not brining much at all | 18:58 |
| Lava_Croft | i used it for a day and then became annoyed with it | 18:58 |
| merlin1991 | a decent whitelist for apps that should rotate even though the propagate they shouldn't would be a nice thing | 18:58 |
| merlin1991 | but forced rotation is just a huge mess | 18:59 |
| Lava_Croft | i think i quit using it once i noticed the insanely long blacklist that was needed for it to work properly | 18:59 |
| Lava_Croft | apart from all the brokenness | 18:59 |
| *** psycho_oreos has quit IRC | 19:00 | |
| DocScrutinizer | merlin1991: exactly, a proper whitelist/blacklist overriding the "enum" I demanded for apps, is exactly what we need | 19:02 |
| merlin1991 | actually what's the consensus about dropping forced-rotation in favour of a proper whitelist? | 19:02 |
| merlin1991 | Doc obviously agrees :D | 19:02 |
| DocScrutinizer | yap | 19:02 |
| DocScrutinizer | at least if your definition of "whitelist" isn't as tight as "list of apps that may use portrait" | 19:06 |
| merlin1991 | actually by whitelist I mean list of apps that will be rotated to portrait despite their window flags | 19:07 |
| merlin1991 | and for everything else we use the window flags | 19:07 |
| merlin1991 | maybe forcelist is a more appropriate word | 19:08 |
| DocScrutinizer | it 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 |
| DocScrutinizer | use-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 specified | 19:13 |
| merlin1991 | I think you solution is troughout but a lil overkill | 19:15 |
| DocScrutinizer | use-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 quits | 19:16 |
| merlin1991 | forced 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 use | 19:18 |
| DocScrutinizer | merlin1991: 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 solution | 19:18 |
| merlin1991 | true, though in order to get your solution up and running we'd need a proper ui for editing it too | 19:19 |
| DocScrutinizer | the 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-app | 19:20 |
| merlin1991 | I don't really understand the usecase of the freeze options though | 19:20 |
| merlin1991 | esepecially the use and freeze | 19:20 |
| DocScrutinizer | the 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 | :D | 19:21 |
| merlin1991 | anway what is the usecase for use and freeze? | 19:21 |
| DocScrutinizer | merlin1991: 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 app | 19:22 |
| DocScrutinizer | it's just a second conditional in each of the tests for state transitions in the orientation statemachine | 19:23 |
| merlin1991 | only thing is as far I understand the code there is no statemachine as of yet | 19:24 |
| DocScrutinizer | that's the major problem right now | 19:24 |
| DocScrutinizer | the implementation in h-d probably is abysmally messy | 19:25 |
| DocScrutinizer | right now | 19:25 |
| merlin1991 | but 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 rotated | 19:25 |
| merlin1991 | that is solved at the moment so far that applications have the window flags that tell h-d about possibility of rotating | 19:25 |
| DocScrutinizer | merlin1991: you should know me by now to tell I'm not reacting good on "user *usually* will..." | 19:26 |
| merlin1991 | DocScrutinizer: wait a lil :D | 19:26 |
| merlin1991 | my argument is still not done :D | 19:26 |
| merlin1991 | then there is the problem of applications that work in portrait but don't define said flag --> here we need configuration | 19:27 |
| DocScrutinizer | thenm there are apps that have the flag but look like shit | 19:27 |
| DocScrutinizer | so user don't want this app to rotate | 19:27 |
| merlin1991 | and 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 orientation | 19:28 |
| DocScrutinizer | then there are apps that user always wants to be in a certain orientation: for me that's dialer:portrait, xterm:landscape | 19:28 |
| DocScrutinizer | merlin1991: the user-override of physical orientation is a rather distinct problem and not related to our "white"list problem | 19:29 |
| merlin1991 | but it is the rationale for the lock, I simply want everyhting rotation related here :D | 19:30 |
| merlin1991 | the 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 too | 19:31 |
| DocScrutinizer | yes, 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 whatever | 19:31 |
| DocScrutinizer | merlin1991: nope, you can not say "this has to be fixed in app, we don't care" | 19:32 |
| merlin1991 | yeah yeah | 19:32 |
| merlin1991 | so we actually need 2 distinct settings | 19:32 |
| DocScrutinizer | we need a list of tupels | 19:33 |
| merlin1991 | distinct as in logically seperated | 19:33 |
| DocScrutinizer | and we need something in our central instance that allows user to override accelerometer | 19:33 |
| merlin1991 | there is the problem of what applications propagate they can do | 19:33 |
| merlin1991 | and the user who might to fix it | 19:33 |
| merlin1991 | err meant to write and the user who might want to restrict it | 19:34 |
| DocScrutinizer | the settings-list always overrides what an app propagates | 19:34 |
| merlin1991 | I'm just trying to find a way todo this without introducing a statemachine to h-d | 19:34 |
| DocScrutinizer | why? | 19:35 |
| DocScrutinizer | what's wrong with a nice statemachine? | 19:35 |
| merlin1991 | well actually the statemachine is just an implementation thing you're right that that is of no concern | 19:36 |
| DocScrutinizer | actually you already got a statemachine, as for sure you're not triggering a transition to portrait if you are already in portrait | 19:36 |
| merlin1991 | hm I wonder what is more intuitive to use as a lock | 19:38 |
| DocScrutinizer | now 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 orientation | 19:38 |
| merlin1991 | something that locks to the current state, or where you explecitely state what you want | 19:38 |
| DocScrutinizer | gets used* | 19:39 |
| *** arcean_ is now known as arcean | 19:39 | |
| DocScrutinizer | merlin1991: 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 here | 19:40 |
| DocScrutinizer | you could provide 17 alternative ways, with 17 little orientation-lock apps | 19:40 |
| merlin1991 | a configureable status menu plugin, yay for the clusterfuck :D | 19:41 |
| *** NIN101 has joined #maemo-ssu | 19:41 | |
| merlin1991 | but yea, I think the sanest solution would be to use window flags by default, and have your idea of state config that overrides it | 19:42 |
| DocScrutinizer | :-) | 19:42 |
| merlin1991 | + the accelerometer override | 19:42 |
| DocScrutinizer | :-) | 19:42 |
| merlin1991 | which imo renders most of your "freeze" states m00t | 19:42 |
| merlin1991 | at 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 usecase | 19:43 |
| DocScrutinizer | well maybe. I already admited that they were a bit made-up. Better ones are: both-aalowed_even-when-orientation-locked | 19:43 |
| merlin1991 | that one makes sense :D | 19:44 |
| DocScrutinizer | for spirit level for example | 19:44 |
| DocScrutinizer | that relies on properly working display-orientation rotation | 19:44 |
| merlin1991 | spirit level? | 19:45 |
| merlin1991 | and I have another item on my todo list :D | 19:46 |
| DocScrutinizer | doesn'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 incorrect | 19:46 |
| DocScrutinizer | 90° | 19:46 |
| DocScrutinizer | there 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 handstand | 19:47 |
| merlin1991 | yep | 19:48 |
| merlin1991 | so 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 |
| DocScrutinizer | that's why I say let's get a config list with tupels, that allows an arbitrary set of options per app | 19:48 |
| DocScrutinizer | accelerometer lock := API to query current orientation, and to overide accelerometer with a fixed virtual orientation that won't change until reverted via same API | 19:49 |
| *** int_ua has joined #maemo-ssu | 19:50 | |
| merlin1991 | can you think of any states other than portrait, landscape, both, bothignorelock ? | 19:52 |
| DocScrutinizer | yes, antiportait, antilandscape | 19:55 |
| merlin1991 | ? | 19:55 |
| DocScrutinizer | prtriat top-down | 19:55 |
| DocScrutinizer | there are 4 natural orientations of a screen | 19:55 |
| DocScrutinizer | when the screen is a rectangle :-D | 19:55 |
| DocScrutinizer | see xrandr | 19:56 |
| merlin1991 | do 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 |
| DocScrutinizer | you might want to make that a set of options, all aloowing one aspect: landscape,portrait,antiportrait,ignorelock | 19:58 |
| DocScrutinizer | and maybe even something like ~landscape to forbid an option | 20:00 |
| DocScrutinizer | you also might *specify* orientations face-up, face-down - FWIW. e.g gestures already use face-down for mute | 20:01 |
| DocScrutinizer | a spirit level might use a special display for face-up orientation | 20:01 |
| DocScrutinizer | a map app as well | 20:02 |
| DocScrutinizer | so specifying all 6 possible orientations isn't an insane thing, though we maybe never will need them for display rotation purposes | 20:02 |
| DocScrutinizer | so: 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 |
| DocScrutinizer | all options are and-ed, an option may be "negative" by preceding it with a "~" | 20:06 |
| DocScrutinizer | umm, wait | 20:06 |
| DocScrutinizer | ok, we get a wildcard for each logical group of options then, as well: like "acmeapp=all-orientations,~anti-landscape" | 20:08 |
| DocScrutinizer | all-orientations is a shortcut for "landscape,portrait,antilandscape,antiportrait,face-up,facedown" | 20:09 |
| DocScrutinizer | all-orientations is the implicit default when no orientation is given at all | 20:10 |
| DocScrutinizer | so "acme_app=" is same as "acme_app=alorientations" | 20:11 |
| DocScrutinizer | while "acme_app=~portrait" is same as "acme_app=allorientations,~portrait" | 20:12 |
| DocScrutinizer | but "acme_app=portrait" is just that - as soon as any "positive" option is used, the default is the opposite | 20:13 |
| DocScrutinizer | so "acme_app=portrait" is like "acme_app=~allorientations,portrait" | 20:14 |
| merlin1991 | wtf does face up and facedown have todo with the window orientation? | 20:16 |
| DocScrutinizer | actually >> 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-ssu | 20:17 | |
| Robot101 | hey, I've got a bugfix for loudmouth (the Jabber library) which should fix signing in to XMPP servers with wildcard / subjAltName TLS certificates | 20:18 |
| DocScrutinizer | merlin1991: 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 anyway | 20:18 |
| Robot101 | how do I get it tested and included in CSSU? | 20:18 |
| merlin1991 | Robot101: tested I guess the best way is to throw it at tmo | 20:18 |
| Robot101 | I 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 N900 | 20:19 |
| Robot101 | actually two guys there it's broken for atm :) | 20:19 |
| DocScrutinizer | Robot101: is it fixing a part of maemo-MP-pr? | 20:19 |
| merlin1991 | DocScrutinizer: yes | 20:19 |
| DocScrutinizer | :nod: | 20:19 |
| Robot101 | http://maemo.org/packages/source/view/fremantle_sdk_free_source/loudmouth/1.4.1-0osso10+0m5/ | 20:19 |
| Robot101 | I have 1.4.1-0osso10.1 | 20:19 |
| Robot101 | I've only touched one file and not gone in with any other changes to avoid any chance of regressions | 20:20 |
| Robot101 | and it's actually already-tested code from our new XMPP library Wocky that we wrote to replace Loudmouth | 20:20 |
| Robot101 | because it's terrible | 20:20 |
| DocScrutinizer | Robot101: 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 Testing | 20:21 |
| Robot101 | the patch is http://people.collabora.com/~robot101/loudmouth_1.4.1-0osso10.1.diff | 20:21 |
| DocScrutinizer | hmm, so you say we need to find testers ourselves? | 20:22 |
| DocScrutinizer | or it is already tested? | 20:22 |
| merlin1991 | Robot101: 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 repo | 20:22 |
| merlin1991 | then when it's tested pester me and I'll get it onto gitorious and will pester mag to include it to next cssu | 20:22 |
| Robot101 | I'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 place | 20:23 |
| Robot101 | if someone wants to review the patch and check my logic that would be nice | 20:23 |
| Robot101 | as it's security-critical | 20:23 |
| DocScrutinizer | hmm, 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-T | 20:24 |
| Robot101 | merlin1991: 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 preferred | 20:24 |
| DocScrutinizer | yep | 20:24 |
| DocScrutinizer | most apreciated was a clear howto to (build and) install it on a CSSU-T system | 20:25 |
| merlin1991 | Robot101: I only mentioned it because some of the maemo sources have public git repos and we like to preserv previous commit history | 20:25 |
| Robot101 | DocScrutinizer: dpkg-buildpackage -uc -us -rfakeroot I hope :) | 20:26 |
| DocScrutinizer | sure :-D | 20: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 |
| merlin1991 | starting a new repo on gitorious with a first commit of "importetd sources from maemo.org" is kinda ugly | 20:26 |
| DocScrutinizer | then publish somewhere, prolly tmo | 20:26 |
| DocScrutinizer | so somebody can *use* it on a T system | 20:27 |
| Robot101 | hrm... I can't even remember if I have a tmo account | 20:27 |
| DocScrutinizer | or stock maemo5 for that purpose | 20:27 |
| DocScrutinizer | any other place is also nice, if you don't like tmo | 20:27 |
| DocScrutinizer | just provide all that's needed to test it there | 20:27 |
| DocScrutinizer | (modulo the N900 and maemo system ;-D ) | 20:28 |
| Robot101 | I need someone who has a working M5 scratchbox SDK to build it for me first :D | 20:28 |
| merlin1991 | can do | 20:28 |
| DocScrutinizer | offer a way for users to give feedback | 20:28 |
| merlin1991 | gimme 2 mins | 20:28 |
| merlin1991 | and Doc stop scaring him off ;) | 20:28 |
| DocScrutinizer | then when there's some WFM feedback, come here and pester us to get it into T | 20:29 |
| Robot101 | DocScrutinizer: 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 :D | 20:29 |
| DocScrutinizer | nah, Robot101 won't get scared by my ranting :-) | 20:29 |
| Robot101 | I'm actually kinda embarrassed it shipped with that so broken :/ | 20:29 |
| Robot101 | missing subjAltName is I think acceptable (it's comparatively new) but that wildcard implementation is so bogus | 20:30 |
| Robot101 | hmmm I wonder if I can pull the SVN history from... er... somewhere... inside... :) | 20:30 |
| * DocScrutinizer waves | 20:31 | |
| merlin1991 | Robot101: 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 cssu | 20:31 |
| Robot101 | merlin1991: sounds great, thanks | 20:31 |
| merlin1991 | okay maemo scratchbox is up and running, time to find out if the build depends of loudmouth are proper | 20:33 |
| Robot101 | wow, code here from 2-6 years ago | 20:34 |
| * Robot101 suddenly feels ooooold | 20:34 | |
| merlin1991 | Robot101: so there are no publicly avaiable repos for loudmout besides the tarball in the sdk? | 20:34 |
| merlin1991 | also tar.gz you posted above includes the patch? | 20:35 |
| Robot101 | https://github.com/mhallendal/loudmouth/tree/loudmouth-1-4 | 20:35 |
| Robot101 | and yeah that tar.gz is pre-patched | 20:35 |
| Robot101 | and I bumped the package version from 10+0m5 to 10.1 | 20:35 |
| merlin1991 | Robot101: but you said earlier the loudmouth version in meamo is quite a delta from that repo? | 20:36 |
| Robot101 | it definitely has a bunch of other stuff - it adds OpenSSL and AsyncNS support on top of upstream | 20:37 |
| Robot101 | and it's a comparatively old version | 20:37 |
| merlin1991 | I guess we'll go the way of import mameo sources then :/ | 20:37 |
| Robot101 | how 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 scrubbing | 20:37 |
| merlin1991 | do you have a gitorious account? | 20:37 |
| merlin1991 | git svn co url afaik | 20:37 |
| Robot101 | at the least I could at least get a clean diff from 1.4.1 to maemo 1.4.1 | 20:38 |
| Robot101 | so we'd have "import maemo stuff" on top of upstream | 20:38 |
| merlin1991 | that would be perfect | 20:38 |
| merlin1991 | Robot101: you could clone the entire svn with "git-svn clone URL" and the just pull the svn branch you need into your git | 20:39 |
| merlin1991 | I don't know how you'd pull a specific svn branch directly | 20:40 |
| Robot101 | svn "branches" are just in a different path so there's no problem there | 20:40 |
| Robot101 | I can take trunk - all of the releases into maemo were tags off trunk | 20:40 |
| Robot101 | the rtcom team was quite well organised :) | 20:40 |
| merlin1991 | well git-svn does quite some stuff to svn repos | 20:40 |
| merlin1991 | it replicates svn "branches" into real git branches | 20:41 |
| *** BCMM has quit IRC | 20:41 | |
| merlin1991 | though the whole import svn into git process can take quite some time depending on the amount of revisions you have | 20:43 |
| Robot101 | heh embarrasingly I can't remember where the SVN repos are, just the trac browser for them | 20:45 |
| Robot101 | gotta dig in the wiki | 20:45 |
| merlin1991 | Robot101: http://188.40.39.11/~christian/cssu/libloudmouth1-0_1.4.1-0osso10.1_armel.deb | 20:46 |
| Robot101 | aha, found the SVN URL | 20:47 |
| merlin1991 | disregard the earlier link, http://188.40.39.11/~christian/maemo/cssu/libloudmouth1-0_1.4.1-0osso10.1_armel.deb | 20:48 |
| merlin1991 | :D | 20:48 |
| * Robot101 goes on an aptitude yak-shave mission to upgrade perl so he can install git-svn... | 20:54 | |
| merlin1991 | ouch | 20:55 |
| Robot101 | am running some random unstable snapshot | 20:55 |
| Robot101 | I'm just a dumb PHB now so I should just run Ubuntu tbh | 20:55 |
| Robot101 | I never actually want to upgrade anything | 20:55 |
| Robot101 | just worries me I'll be broken without my e-mail / browser / libreoffice / ... | 20:55 |
| merlin1991 | PHB? (I really need to read up on TLAs) | 20:56 |
| Robot101 | pointy-haired boss, from dilbert :) | 20:56 |
| merlin1991 | damn I just looked at the collabora webpage, how on earth is one supposed to fullfill the requirements to get hired | 20:57 |
| merlin1991 | requirements include the typical "are you interested in $x, you are perfect if you have 10 years of prior experienece in $x" :D | 20:58 |
| Robot101 | merlin1991: the only vacancy there is engineering manager - they're meant to be experienced :) | 20:59 |
| Robot101 | we actually tend to hire engineers a lot more... quietly | 20:59 |
| Robot101 | people apply to jobs@collabora.com and we've heard of people / seen their OSS contributions, it usually goes pretty quickly | 21:00 |
| Robot101 | sometimes we need an expert in $foo and we'll go and try to find someone we know or ask around | 21:00 |
| merlin1991 | yeah I noticed that the webpage nearly never contains engineers in the vacancys | 21:00 |
| Robot101 | OSS means we can kinda... tell if it's the right kinda person based on if we've heard of them before or not | 21:01 |
| Robot101 | we can know about skills and attitude just from someone's name and ask around internally :) | 21:01 |
| merlin1991 | well I'm still far away from doing a full time job anyway :D | 21:01 |
| Robot101 | we take interns too... :) | 21:02 |
| Robot101 | and part-timers / students / etc | 21:02 |
| merlin1991 | I would fall into the students category, but I live somewhat outside the usual area according to the contact map | 21:03 |
| merlin1991 | (austria that is) | 21:03 |
| Robot101 | 80% of collabora is outside our offices :) | 21:03 |
| Robot101 | crap, that import didn't work properly | 21:04 |
| merlin1991 | svn -> git or deb repo -> your system? | 21:04 |
| Robot101 | svn -> git | 21:04 |
| Robot101 | well I got the src but it only goes back to: | 21:05 |
| Robot101 | Author: jlaako <jlaako@64d1ce6a-1406-0410-9ac8-afed03b27183> | 21:05 |
| Robot101 | Date: Wed Oct 17 13:04:24 2007 +0000 | 21:05 |
| Robot101 | Branch the trunk to main level | 21:05 |
| Robot101 | comes from somewhere else | 21:05 |
| DocScrutinizer | engineering? | 21:05 |
| DocScrutinizer | what engineering? | 21:05 |
| merlin1991 | I suppose software ;) | 21:05 |
| Robot101 | somewhere else in the repo - this is just how svn works guys :P | 21:06 |
| Robot101 | it's just git-svn didn't follow it | 21:06 |
| Robot101 | heh, gone from trunk to OSSO-1.x to OSSO-1.0 | 21:06 |
| merlin1991 | I've noticed git-svn only works to a certain degree | 21:06 |
| Robot101 | that's the N800 I think... :) | 21:06 |
| Robot101 | if I can feed the previous branches to git-svn I can reconstruct all the history, heheh | 21:07 |
| *** m0use has quit IRC | 21:07 | |
| DocScrutinizer | hey Robot101, I'm interested in a part-time remote job | 21:07 |
| DocScrutinizer | :-D | 21:07 |
| merlin1991 | or 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 |
| DocScrutinizer | Robot101: preferably something where I don' | 21:08 |
| DocScrutinizer | t have to cope with ClearCase and winXP all day long | 21:09 |
| Robot101 | we don't use either | 21:10 |
| DocScrutinizer | I'm pretty good as a catalyst at the interface between EE world and SW department | 21:10 |
| merlin1991 | DocScrutinizer: this is #maemo-ssu ;) | 21:10 |
| Robot101 | actually I lied, we've got some windows buildslaves because we have a couple of projects to make Telepathy run on different platforms | 21:10 |
| DocScrutinizer | I also can review and maybe even design Architectures, also sw | 21:11 |
| merlin1991 | DocScrutinizer: I always thought you're more on the hw side | 21:12 |
| DocScrutinizer | Robot101: plus a few years of not-so-indeepth experience with SIP | 21:12 |
| DocScrutinizer | merlin1991: my heart is, my business always been sw development though, except with Openmoko who hired me for EE | 21:13 |
| DocScrutinizer | Robot101: and I'm extremely good at bashing UIs and suggesting improvements - so let's call that usability | 21:14 |
| DocScrutinizer | you could sub-sum APIs inder UI maybe | 21:15 |
| DocScrutinizer | under* | 21:15 |
| Robot101 | DocScrutinizer: you can certainly work up a CV and send to jobs@collabora.com | 21:15 |
| DocScrutinizer | I might do that. yes | 21:16 |
| DocScrutinizer | though I always found it a bit hard to propagate my *real* expertise in a CV, it's usually way too formal | 21:16 |
| DocScrutinizer | and my job description isn't exactly fitting any of the usual stereotypes | 21:18 |
| DocScrutinizer | neither do my ideas of what a contract might look like ;-) | 21:19 |
| DocScrutinizer | freelancer being my fav for that | 21:19 |
| DocScrutinizer | basically what I did for #maemo last 2..3 years been sth like 3rd level helpdesk | 21:21 |
| Robot101 | we're happy (happier?) with a "oss contributions bragsheet" section of CV | 21:21 |
| DocScrutinizer | sometimes even project manager | 21:21 |
| DocScrutinizer | yeah, this "bragsheet" already assumes a certain scheme of producing sth that would show up in written form somewhere | 21:23 |
| Robot101 | it does when you write it... :D | 21:23 |
| DocScrutinizer | I'm probably not the right one for this job | 21:23 |
| DocScrutinizer | I'm writing a lot on IRC for example | 21:24 |
| DocScrutinizer | hard to refer to that in a bragsheet | 21:24 |
| Robot101 | well mostly it's about knowing people are available and matching them to the stuff we need | 21:24 |
| DocScrutinizer | even harder when it'son private channels | 21:24 |
| Robot101 | I don't have a specific job in mind, but I have projects where if I know you're available you could fit | 21:24 |
| DocScrutinizer | that's why I mentioned it directly here rather than sending an unsolicited application | 21:25 |
| DocScrutinizer | I'd be interested in small jobs right now, like max 25% and of limited duration | 21:26 |
| DocScrutinizer | option to grow in workload and duration in the future | 21:26 |
| DocScrutinizer | for now I just started a job to get some working LTE chipsets to 'you', where I'll fix issues in e.g I2C-drivers etc | 21:27 |
| DocScrutinizer | this being a fultime job I'm only available 25% ATM | 21:28 |
| DocScrutinizer | maybe 50% for a 4 weeks period | 21:28 |
| merlin1991 | the 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 tmo | 21:28 |
| DocScrutinizer | otoh I wouldn't ming getting hired on a per-day basis | 21:28 |
| DocScrutinizer | merlin1991: exactly | 21:29 |
| DocScrutinizer | merlin1991: so how are we both going to brag with what we both do here? :-D | 21:30 |
| merlin1991 | I'm at least visible on gitorious ;) | 21:30 |
| DocScrutinizer | hehe, I'm somewhat visible on h-e-n | 21:30 |
| DocScrutinizer | under "special appearance" in "about h-e-n" | 21:30 |
| * Robot101 is torturing some poor SVN server at projects.maemo.org | 21:31 | |
| Robot101 | just when it was resting so well, expecting to be put out of its misery soon... | 21:31 |
| Robot101 | still importing S+ revisions | 21:31 |
| Robot101 | lol | 21:31 |
| Robot101 | I don't know how to smush two histories together properly though | 21:31 |
| Robot101 | I have the upstream git history, and Nokia SVN history which I'm importing to git | 21:32 |
| Robot101 | but the upstream stuff just appeared in Nokia SVN by "commit upstream 1.0.3" | 21:32 |
| merlin1991 | checkout the upstream base commit, branch it and rebase --onto the svn history | 21:32 |
| DocScrutinizer | Robot101: my "bragsheet": http://www.google.de/search?q=joerg@openmoko.org | 21:32 |
| DocScrutinizer | if eventually you aka collabora are interested, I'm always ping'able via IRC, or send me a mail to above addr | 21:34 |
| Robot101 | hrm | 21:34 |
| Robot101 | checksum mismatch | 21:34 |
| Robot101 | and git svn just dies | 21:34 |
| Robot101 | bad juju :( | 21:34 |
| *** NIN102 has joined #maemo-ssu | 21:41 | |
| Robot101 | not sure what that means really - how did it arrive at that error? | 21:42 |
| Robot101 | r4756 = e35e49fd64fdd14880d843de5cee3c5d8a4102e1 (refs/remotes/python) | 21:42 |
| Robot101 | Checksum mismatch: changelog | 21:42 |
| Robot101 | expected: a13ce8bfc31e6bda1e4c5f916464df7e got: 49740d3145665f0f41bd18f83a4d4f4e | 21:42 |
| *** NIN101 has quit IRC | 21:42 | |
| merlin1991 | Robot101: sry, I've only used git-svn twice so far and it has been a mess both times | 21:42 |
| *** ThreeM has quit IRC | 21:44 | |
| *** ThreeM has joined #maemo-ssu | 21:44 | |
| Robot101 | fail :/ | 21:45 |
| *** scoobertron has joined #maemo-ssu | 22:00 | |
| *** BCMM has joined #maemo-ssu | 22:02 | |
| *** BCMM has quit IRC | 23:19 | |
| *** nox- has joined #maemo-ssu | 23:55 | |
| *** rd has quit IRC | 23:57 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!