#mer log for Sunday, 2012-02-19

*** jstaniek has quit IRC00:00
*** asdfafew has quit IRC00:01
*** dijenerate has joined #mer00:03
*** tilgovi has quit IRC00:04
*** yue has joined #mer00:04
*** NIN_ has quit IRC00:22
*** Alison_Chaiken has joined #mer00:28
*** kurtul has joined #mer00:32
*** tpn has quit IRC00:42
*** M4rtinK has joined #mer00:46
*** lynxis has joined #mer00:55
*** trbs has quit IRC01:12
*** M4rtinK has quit IRC01:12
*** KaiRo_Mozilla has quit IRC01:16
*** lynxis has quit IRC01:29
*** lynxis has joined #mer01:33
*** lynxis has quit IRC01:40
*** HazardousWaster has quit IRC01:50
*** HazardousWaster has joined #mer01:50
*** phaeron has joined #mer01:53
*** returnth` is now known as returnthis02:01
*** BeholdMyGlory has quit IRC02:05
*** BeholdMyGlory has joined #mer02:07
*** rolandx1_ has joined #mer02:41
*** wubudubudubudu has joined #mer02:41
*** rolandx1 has quit IRC02:44
*** Venemo has quit IRC02:45
*** otep has quit IRC03:03
*** otep has joined #mer03:05
*** thomashc has quit IRC03:21
*** thomashc has joined #mer03:21
*** cxl000 has quit IRC03:32
*** smoku has left #mer03:43
*** sonach has joined #mer03:45
*** kurtul has quit IRC03:48
*** cxl000 has joined #mer03:49
*** returnthis has left #mer03:56
*** GeneralAntilles1 is now known as GeneralAntilles04:00
*** GeneralAntilles has joined #mer04:00
*** cxl000 has quit IRC04:04
Macerhm04:31
Macerdoes anybody here have a tranformer?04:31
Maceri'm trying to figure out how to back it up in recovery mode/apx mode04:31
*** phaeron has quit IRC04:32
Macerhm04:36
*** jargon-_ has quit IRC04:49
*** phaeron has joined #mer04:50
Macerah well04:59
Maceri'm stuck :)04:59
*** beyondcreed has joined #mer05:12
*** cxl000 has joined #mer05:16
*** kurtul has joined #mer05:18
*** ZiQiangHuan has joined #mer05:23
*** sonach has left #mer05:24
*** kthomas_vh_ has joined #mer05:27
*** onekenthomas has quit IRC05:28
*** Alison_Chaiken has quit IRC05:29
*** cxl000 has quit IRC05:31
*** ZiQiangHuan has quit IRC05:33
*** Alison_Chaiken has joined #mer05:41
*** cxl000 has joined #mer05:43
*** lynxis has joined #mer05:50
*** cxl000 has quit IRC05:51
*** lynxis has quit IRC05:56
*** Alison_Chaiken has quit IRC05:58
*** wwweagle has joined #mer06:05
*** wwweagle has left #mer06:06
*** wwweagle has joined #mer06:06
*** cxl000 has joined #mer06:17
*** rolandx1_ is now known as rolandx106:25
*** phaeron has quit IRC06:37
*** Alison_Chaiken has joined #mer06:43
*** Khaled has joined #mer06:57
*** Khaled has quit IRC07:17
Stskeepsmorn07:19
wwweagleafternoon @ china:)07:20
Stskeepshehe07:21
Stskeepsi should really visit mainland china at some point, i've only been to hong kong07:21
wwweaglesure07:22
cxl000morn07:22
Stskeepsmorn cxl000, how is it going?07:22
wwweagleyou'll got ton's of semi-fake tablets for few dollars07:22
cxl000too many irons in the fire.07:22
wwweagleand happily porting mer on them...07:23
cxl000I currently been struggling with sgx drivers on the pandora07:23
cxl000It has an ancient 1.0.3 core07:23
Stskeepswwweagle: i do wonder to find some armv6 featurephone and just trying to hack mer on to them for the learning experience, yeah07:24
Stskeepscxl000: isn't there sgx drivers available for that anyway?07:24
cxl000TI's 4_04_00_03 code drop was the last to support them.07:26
Stskeepsok07:27
cxl000I can get them build with same minor changes for the 3.2.1 kernel I'm using and run the Raw demos but not he X demos07:27
*** wwweagle has left #mer07:31
Stskeepscombine with omapfb maybe07:40
cxl000I trying to understand the internals of the interface to try and work out how to proceed.07:43
cxl000Is that what you have done with the n9xx omap/sgx X driver?07:46
Stskeepsi wouldn't try to combine those, they're very specialized07:46
*** xtcx has joined #mer08:07
*** thomashc has quit IRC08:09
*** s1gk1ll has joined #mer08:19
* Stskeeps ponders08:20
*** M4rtinK has joined #mer08:21
*** sigkill_ has quit IRC08:23
*** Alison_Chaiken has quit IRC08:37
Stskeepshttp://prog21.dadgum.com/128.html08:48
*** kurtul has quit IRC08:49
*** M4rtinK has quit IRC08:59
*** andre__ has joined #mer09:04
*** andre__ has joined #mer09:04
*** kurtul has joined #mer09:10
lbtmorning all09:13
*** NIN101 has joined #mer09:15
Stskeepsmorn lbt09:26
*** DocScrutinizer has quit IRC09:29
*** DocScrutinizer has joined #mer09:30
* Stskeeps grabs his small whiteboard09:32
andre__yoyoyo!09:33
* lbt looks at his rather messy whiteboard which is just a big todo list09:34
*** beford has quit IRC09:34
Stskeepslbt: so what's the plan for today?09:38
lbtI opened the bug list09:39
Stskeepsok09:39
lbtSDK needs finishing09:39
lbtI thought I'd try to fix something using it09:39
lbt2 birds09:39
Stskeeps:nod:09:39
lbtI packaged it better too09:39
lbtso it's a multi-package09:39
lbthnn09:39
Stskeepsfrom my side meego COBS matters as i can then do a proper prerelease monday or tuesday09:39
lbtit depends on itself09:39
StskeepsSDK also matters so we can have along on next release09:40
lbtis the hackday over?09:41
Stskeepsthink so09:42
Stskeepsthe next dependency in line is then i can show sb2-obs in production and i can try to mainline my patches to obs09:48
lbt*nod*09:49
Macerhm09:49
lbteek09:49
Stskeepshmm?09:49
lbtno, eek09:49
Stskeepsmice?09:50
Stskeeps:P09:50
lbtROFL , yes actually09:50
Macerstill trying to figure out how to get this transformer to backup09:50
lbtkilled 2 last night09:50
Macerusing nvflash09:50
Macerblah. i'll figure it out in a little bit. need to wake up now... been sick and slept 30 of the last 48 hours09:50
Stskeepslbt: http://build.meego.com/package/files?package=kvmic&project=Tools%3ABOSS09:56
lbt...09:57
lbt:)09:57
Stskeepsnew mic kvm wrapper or something09:58
lbtdunno - obs makes browsing code a bitch10:05
Stskeepsdownload the tar.gz10:05
Stskeeps:P10:05
lbtlike I said...10:06
lbtthe standalone tool to create, deploy and launch kvm images to run mic2 for image creation10:07
Stskeepsand new mic too, i think10:07
lbtthe packaging uses rpm/* style - interesting10:07
lbtit copies rootfs images10:08
Stskeepsrpm/* ?10:08
lbtphaeron and I discussed either qcow or better, writeable lvm snapshots10:09
Stskeepsalso plausible10:09
lbtjust as a place to keep the spec/yaml/changes/patches10:09
* Stskeeps is trying to architect up a sane solution for toolchain-core split10:10
Stskeepsie, an actual maintainable one10:10
lbt"sb2 is the toolchain"10:12
Stskeepsi wish it was that easy10:12
lbthow tied do they need to be10:12
Stskeepsokay, let me try to explain what's going on, if you have time for a 30 minutes brainstorm or something10:13
* Stskeeps gets his camera10:13
lbtOK10:13
*** zutesmog1 has quit IRC10:15
*** zutesmog has joined #mer10:15
Stskeepshttp://releases.merproject.org/~carsten/20120219_001.jpg10:18
*** kurtul has quit IRC10:18
Stskeepsso, the story is that toolchain is x86, self-hosted (as in, it can build itself) , it's left hand .. right hand is core and isn't self hosted10:18
Stskeepstoolchain and core are two seperate dependency trees10:19
Stskeepscore is built towards a target, can be armv7l, x86, etc10:19
Stskeepsin order to start build for target with 'ordinary' packages, the target must have a number of packages cross built/baselibs'ed over10:20
Stskeepssuch as 'setup', 'filesystem', 'mer-rpm-config', as well as target specific RPM configuration (cross target rpm build config, cross target) rpm config10:20
Stskeepsyou also need to build a cross compiler -- you do this by first building a bootstrap gcc which can only build glibc, then you build a bootstrap glibc, which you then build a final cross compiler with10:21
Stskeepsthis requires kernel headers to do, naturally10:21
Stskeepsthe results of the cross compiler (it's libgcc for target, libgomp, libmudflap-devel, libobjc, libstdc++-devel) should be available as packages in target10:22
Stskeepsas well as exporting a built glibc + devel headers10:22
Stskeeps.. makes sense/any questions?10:23
lbtyes/yes10:23
lbt"you also need to build a cross compiler "10:23
lbtthis is target specific I assume10:23
lbtbut lives on the left10:23
Stskeepsyes10:23
lbtso it feels like the LHS has target specific sections and a common section10:24
lbtor there's a middle section10:24
Stskeepsit is x86 binary with built ARM libraries to build against (libgcc, libstdc++-devel, etc)10:24
Stskeeps(cross compiler)10:24
lbtthinking of the architectural view10:24
lbttoolchain/target-toolchain/target are 3 distinct areas ?10:25
lbttarget = core and goes on device10:25
lbtdoes target-toolchain contribute some things to the core? (libgcc)10:26
Stskeepsyes, it does10:27
lbtvia baselibs?10:27
Stskeepsyes, aggregated over10:27
Stskeepsas you can't mix toolchain and target dependancies10:27
lbtbut nothing that lives in the toolchain is aggregated over10:27
Stskeepsat the moment i've envisioned target-toolchain as part of toolchain, as it builds against it for sure10:28
Stskeepsbut you're right, in toolchain itself, it does not necessarily need to be10:29
Stskeepsright now i'm exporting stuff like rpm configs, filesystem, setup, etc10:29
Macerugh10:30
Macer[mace@mer Linux]$ ./nvflash --bct transformer.bct --setbct --configfile flash.cfg --bl bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync10:30
MacerNvflash started10:30
MacerPermission Denied[mace@mer Linux]$10:30
StskeepsMacer: sudo..10:30
lbtso... what do they do10:31
lbtand where do they live?10:31
Macerhm10:32
Macerok10:32
Stskeepsrpm configs is pretty simple, it's the stuff rpm needs to function (not binaries), so it's /usr/lib/rpm/rpmrc /macros and such10:32
Maceri just realized it may have something to do with the fact i encrypted the tablet lol10:32
Stskeepsfilesystem imposes a basic file system structure inside rpm, owning certain directories, so does setup10:32
lbtare any of them not noarch ?10:33
Stskeepsthey're noarch, but rpm configs do need some changes to fit with the architecture they're installed onto10:34
lbtthat's OK - that's just source control of the target10:34
Stskeepsyeah10:34
MacerBACKUP_DIR="tf101-backup-`date +%Y%m%d%H%M%S`"10:35
Macermkdir $BACKUP_DIR10:35
Maceroops10:35
Stskeepslbt: so, one of the problems i'm having is for example, ease of making a new target for core, can we make generation of the target-toolchain exports dynamic, how can we avoid ending up with 3 OBS projects to accomplish this, etc10:35
Stskeepsideally i'd have a toolchain release, and then you can aggregate from the target-toolchain stuff into a core OBS project start building core sources10:37
Stskeepsie, one toolchain, N targets10:37
lbtI know the answer ... what does core sources build against?10:38
lbtdoes that part need to change?10:38
Stskeepsit does not build against toolchain10:38
lbtdo we need to add a <toolchainpath>10:39
Stskeepsit builds against the results of target-toolchain exports10:39
Stskeepsthe dependency tree of toolchain is out of reach10:39
lbttoolchain-target10:39
lbtcan toolchain-target build toolchain?10:39
Stskeepsno10:39
Stskeepswell, i suppose it could, but it'd be a little more involved10:40
*** arcean has joined #mer10:40
lbtagreed - but it could10:40
lbtnm10:40
Stskeepsthe general idea is that we should be able to drive core down to a set of dependencies lesser than what we're able to if it had to be self-hosting10:41
Stskeepsas well as increase portability, ie, we can point it at a android-sh4 target if we so cared10:41
lbtyes10:41
Stskeepsand i want to do it in such a way that we're not modifying typical .spec files10:41
lbtso toolchainpath10:42
Stskeepsor voodoo rpm configs10:42
lbtdoes that terminology I mentioned - the 3-way split - add value ?10:42
Stskeepsit might10:42
lbttoolchain, toolchain-target, target10:42
lbttoolchain, toolchain-target, core10:42
lbtso if toolchain-target is added to the <path> list10:43
Stskeepswe cannot let core in any way get dependancies that isn't explicitly exported from toolchain-target10:43
lbtlike ?10:44
Stskeepsok, i think i forgot to mention one thing10:44
Stskeeps / is initialized with 'toolchain' x86 binaries, including cross compiler and so on, /target is where target packages gets installed into10:44
Stskeepsand sb2 in / oto10:45
Stskeepstoo10:45
lbtmmm - that's the build environment10:45
Stskeepsyes10:45
Stskeepsjust to understand what -does- get passed on somehow10:46
Stskeepsfrom toolchain side10:46
lbtbut nothing of that gets into buildroot and into %files10:46
Stskeepscorrect10:46
*** beyondcreed has quit IRC10:47
Stskeepsso, we have toolchain core with some template packages, we create a second project, target-toolchain-XXX and then export from target-toolchain-XXX to target?10:48
Stskeepstemplate packages being put into target-toolchain-XXX with config for what target to target10:48
lbtyep10:48
Stskeepser, s/toolchain core/toolchain/10:48
lbtyep :)10:48
Stskeepsi suppose that could work10:48
* lbt wasn't going to mention that10:48
lbtbut why export10:48
lbtlast step10:48
lbtwhy not multi-path10:49
Stskeepsyou need to, in order to be able to build packages for the core10:49
Stskeepsthe stuff on my picture is the minimal set of being able to build a package transparently10:49
Stskeepsfor a target10:49
lbtnot sure I understand why they differ10:50
Stskeepswhen i hear multi path, i hear target-toolchain and toolchain's dependency tree slipping into target10:50
lbtyeahbut10:50
lbtdoes core have gcc10:50
lbtno10:50
lbtso it has to BR it10:51
lbtso that comes from tc-target10:51
lbttc-target is a valid dep source10:51
lbtit's also isolated from target10:51
lbttc-target is an invalid Require source10:51
lbtand IMG will get that10:51
lbtwhen we install test10:51
lbtincidentally tc-target is a valid indirect Require source during build10:52
Stskeepsah, okay, so, gcc and so on is provided by the sb2 tools (the stuff in / i was mentioning), and there's a package that Provides: gcc , autoconf, automake and so on, that's empty10:53
Stskeepsas it's all handled in sb2 tools10:53
lbtyep - makes sense10:53
Stskeepsthat package is in target10:53
Stskeepsand exported as well10:53
lbtOK10:53
lbtso I'd prefer to say that a version is built for tc-target10:53
lbtto keep it clean10:53
Stskeepsrephrase that?10:54
lbtre-reading to check10:54
*** tomeff has quit IRC10:54
lbtah you said "that package is in target" I read "that package is in toolchain"10:54
lbtwhich sounded wrong10:55
Stskeeps:nod:10:55
Macerwow10:55
Maceri think i managed to make a backup of my transformer10:55
lbtcould it go in toolchain-target ?10:55
Maceras well as get the kernel downloaded etc10:55
Macerlol10:55
Macerone step closer10:55
Stskeepslbt: it's being exported from toolchain-target to target as toolchain-target is the only one knowing what exact gcc versions autoconf , etc there are10:55
lbtagain - why export?10:56
Stskeepsbecause we can't get a clean dependancy tree in core else10:56
Stskeepsexport == baselibs10:56
Stskeepsand aggregate10:56
lbtwhich is important why? since we're not self-hosting10:56
lbtso...10:57
lbtthe reason I ask is that export = aggregate == copy to somewhere I can depend on it during build10:57
lbtbut I don't care during install10:57
lbtso instead of copying10:57
lbtput it somewhere I can find it during build10:57
lbtie during build add another <path> so I look there10:57
lbtand don't have to bother aggregating (which is conceptually a pita)10:58
lbt( but I don't care during install == during device image/rootfs creation)10:58
Stskeepsduring build we can't dep on gcc because it doesn't exist for the target, obviously10:58
lbtmmm10:59
lbtbut you said we provide a stub10:59
lbtso .... that's a valid solution10:59
lbtduring install we can't depend on it10:59
lbtbut if you aggregated that package to core - we could!10:59
lbtor am I missing something ?10:59
Stskeepsthe stub package is aggregated to core and if you end up installing the stub in an image, that's bad packaging11:00
Stskeeps:P11:00
lbt:)11:00
lbtand that *never* happens11:00
Stskeepsmm11:00
lbtso ... don't aggregate it to core11:00
Stskeepsi'd like to know what your alternative is11:01
lbt<path>11:01
Stskeepsto what11:01
lbtbut only to toolchain-target11:01
lbtwhich is only a buildtime thing11:01
Stskeepsyou can't limit the length of a path11:01
Stskeepsif we path to toolchain-target, it'll path to toolchain11:01
lbtwhich is why I mentioned <toolchainpath>11:02
Stskeepsas toolchain-target needs toolchain to build11:02
lbtor even <path depth=1>11:02
lbtor something11:02
Stskeepsanother fun issue11:02
Stskeepswe need independent prjconfs for core11:02
Stskeepsso this feels like a rabbithole11:03
lbtincidentally11:03
lbthow about publishing toolchain-target11:03
Stskeepsso there's two ways to solve the install-issue11:03
lbtthen DoD it11:03
lbtkinda11:04
Stskeepsok, three11:04
lbtwe want a static version of it for a long time11:04
lbtso changing the toolchain *is* rare and explicit11:04
lbt(for vendors)11:04
Stskeepsso, two sides: we want to have CI working with changing toolchain bits, or updating the libc11:04
Stskeepsso we need a change in toolchain to ripple through to core11:05
lbtreally ?11:06
Stskeepsyes11:06
Stskeepselse we can't ever see results of toolchain upgrades11:06
lbtyesbut11:06
lbtaren't you mixing CI of toolchain and CI of core11:06
lbtif you want them split .... then split them11:07
StskeepsCI of toolchain naturally means that core will be rebuilt too11:07
Stskeepsand that's validation of toolchain11:07
lbtby all means use a copy of core as the CI validation of toolchain11:07
lbtbut.... do vendors want to see that - what's the release process11:07
Stskeepsanyway, you do have a point with the install process11:08
Stskeepstwo ways to solve that11:08
Stskeepsok, three11:08
Stskeeps1) your proposal 2) publishfilter the aggregated packages 3) have two repos in toolchain-target repo, one is attached to toolchain, the other one is a dead end, aggregate within it11:08
Stskeepsattached == <path>11:09
lbtis 1) the <path depth=1> thing?11:09
Stskeepsno, publishing/DoD, so we're up at 4..11:09
lbtgood <path depth> was an idea ... 1) is more sane I think11:10
lbtalthough it would avoid aggregates and be nicely OBS-ish11:11
lbtbut too little time11:11
Stskeepsmy head tells me that DoD/publishing can be more trouble than worth, i'm just having difficulties to put words on it11:13
Stskeepsas there's some problem when target is i586 to11:13
Stskeepso11:13
Stskeepsi'm not discounting it though11:13
lbt3) seems interesting11:14
lbt2) would send them to core?   I'm not keen on that11:14
Stskeeps2) would send them in for build process but not for publish phase11:15
Stskeepsi'm thinking 3) might be sane11:15
*** ieatlint has quit IRC11:16
*** ieatlint has joined #mer11:16
* lbt tries to remember why aggregate and not link11:17
Stskeepslink is sources11:17
Stskeepsaggregate is binaries11:17
lbtso it'd rebuild11:17
lbttry + fail11:17
Stskeeps:nod:11:17
lbtprojlink11:17
lbt....11:17
Stskeepsprojlink is sources too11:18
lbtprojaggregate :)11:18
Stskeepson occasion i wouldn't mind having that11:18
Stskeepsi think 3) and the three OBS repo split can be very flexible11:19
Stskeepsrepo=project11:19
Stskeepsand automation-able11:19
lbtincidentatlly11:21
lbta snapshot of 3) is a release of the target toolchain isn't it ?11:21
lbtso a vendor only needs that - no need for bootstrapping the tc11:21
Stskeeps:nod:11:22
Stskeepswe do have one place where we can't do that11:22
Stskeepswe need to have glibc and libgcc and such for install phase11:22
lbtgrrr11:23
Stskeepsyes, it's amazing what comes to your mind when you go to the bathroom..11:23
Stskeeps:P11:23
lbttmi11:24
Stskeepsbut 3) is still sane, but may need more kludgery11:25
lbtI vaguely thought about having a template spec to build them11:25
lbtthat uses "cp" as the builder11:26
Stskeepsi think we can do templates within toolchain that gets effectuated through toolchain-target by prjconf macros11:26
lbtand similarly into core for libgcc and co ?11:27
Stskeepsyes, i guess that could work11:27
Stskeepsso we provide templates in toolchain, these get linkpac'ed into toolchain for target and becomes toolchain for target when built11:27
Stskeepsvery automate-able11:27
lbtOK - so how about I do this ... with much guidance ... it'll be slower but educational11:28
lbtyou may feel the need for a large brandy before starting though11:28
Stskeepsi'm a martini person, but yeah11:28
lbtso let this stew and we'll do cobs and stuff today11:29
Stskeepseven script-able: "here's a source dump of toolchain, binaries on MDS, write in the parameters for your target and we'll build it.."11:30
Stskeepsthanks for the brainstorm, it got me past the problem nicely11:31
lbtyeah - nice to do something interesting!11:31
*** himamura has quit IRC11:32
Stskeeps:nod:11:34
*** himamura has joined #mer11:35
Stskeepsi do wonder what some of the downsides of the split will be, though11:35
lbtlack of devel capability on device?11:37
Stskeepsthat's one thing, yes11:37
Stskeepson the other side of things, it does enable a wide range of targets and possibilities instead11:37
lbtwould the tc-target be "build-essential" though11:37
Stskeepsyes11:37
Stskeepsbut for x8611:38
lbtand simply mean that build-essential was a discrete repo (which may be a -ve for 'openness')11:38
lbtyah11:38
lbtcould we build tc-target-native ?11:38
Stskeepstheoretically, but we need entire tc too11:39
lbtI think that's what I had in mind when I asked if tc-target could build tc11:39
Stskeepsi guess technically but i can't promise it for every core11:40
Stskeepsthink mer for bionic libc11:40
lbtthere are a lot of things (mainly ruby/python/perl style) where native extensions are needed11:40
lbtyeah - I'm talking linux :)11:40
Stskeeps:nod:11:40
Stskeepspython/ruby/perl stuff is another issue11:41
lbtobs built should be fine shouldnt' it?11:41
lbtcan't see a problem there11:41
lbtbut using pip or bundler something on device11:42
Stskeepsanyway, moving on .. in SDK, it'd likely be an instance of toolchain+a number of target toolchains11:42
lbtand with PA we're talking about a 'normal' linux platform experience11:42
lbtOK - but add tc-target-native to the architectural backlog11:43
Stskeeps:nod:11:43
Stskeepsi'm aware the approach may be controversial as it changes the way you build device systems11:44
*** smoku has joined #mer11:44
Stskeepsand that a full Motif experience might not be posible easily, etc..11:45
lbtIf we can provide the native toolchain then I think we're OK11:46
Stskeepsyeah, but even then, it's not always 'apt-get' able into device11:47
*** phaeron has joined #mer11:47
lbtit means that the device can't update it's own toolchain using the same build mechanism11:47
Stskeepsit might have to be a chroot11:47
Stskeepsi think i can build the nasty set of packages needing to self-host with this approach11:48
lbtit should be installable - may need a bit of trickery to replace dummies11:48
Stskeepsso we can get a native sdk if really needed11:48
lbtI think it's needed for acceptance11:48
phaeronhello11:48
jafdhttps://bugs.merproject.org/show_bug.cgi?id=183 by the way, I have followed advice from yesterday. Sorry for dropping in.11:49
Stskeepslo phaeron11:49
lbtgood afternoon phaeron11:49
Stskeepsjafd: you're going to hate me in a moment..11:49
Stskeeps:P11:49
lbtjafd: welcome11:49
Stskeepsjafd: you filed in wrong bugtracker :)11:49
* lbt grins11:49
Stskeepsjafd: n900 hardware adaptation is in nemo mobile, mer doesn't have ui's or hardware adaptations11:49
Stskeepsjafd: either way11:50
Stskeepsjafd: the reason why bluetooth isn't working on n900 is two-fold11:50
lbtphaeron: we've had a really interesing chat on toolchain splits11:50
phaeronlbt: so newmic seems to be able to run natively on debian11:50
phaeronoh11:50
* phaeron holds back11:50
jafdStskeeps: can you please move it to where it belongs? It's the ONLY bugtracker I've been able to find on *Nemo* page...11:50
lbtphaeron: interesting11:50
Stskeepsjafd: ah, we should fix that..11:50
Stskeepshang on11:50
* lbt slaps the nemo people11:50
Stskeepsjafd: 1) the serial line to bluetooth chip gets shut down by power management before it's possible to communicate with it11:50
jafdI don't really care if the reporter changes in the course11:50
lbt*ouch*11:51
Stskeepsjafd: 2) the calibration tool won't work either because of this fact11:52
Stskeepsjafd: if you figure out why 1) happens, then everything else should fall in place11:52
jafdhm, I thought power management is more in-kernel than in-board11:52
StskeepsOMAP PM11:52
Stskeepswe've done some experiments to try to fix the issue but we haven't found a cure just yet11:53
phaeronlbt: also new mic forces using zypper for creating bootstrap. I don't know if this is really necessary but at least it means it can't bootstrap without zypper on debian (needs packaging ?)11:53
jafdWhat I was wondering about is some report from meego bug that they have fixed it for some "release" but not in trunk.11:53
lbtphaeron: I did notice this11:53
Stskeepsjafd: show me the meego bug report?11:53
lbtphaeron: but honestly ... SDK11:53
jafdhttps://bugs.meego.com/show_bug.cgi?id=1236311:53
*** wwweagle has joined #mer11:54
phaeronlbt: I am talking about imager11:54
Stskeepsjafd: yes, that was from before we added power management patches11:54
lbtphaeron: mmm11:54
lbtphaeron: isn't the kvm worker a mer root using SDK ?11:55
lbtwhen we do it right11:55
jafdStskeeps: so. There's an alternative of having bluetooth and draining battery really fast, or not having bluetooth, as of now11:55
lbtphaeron: give me 5min to edit these notes b4 I forget11:55
*** wwweagle has left #mer11:55
Stskeepsjafd: as in being able to warm your hands on it, or bluetooth, yes, http://elinux.org/OMAP_Power_Management#UART_wakeup_and_timeout_options11:56
Stskeepsthe problem is that characters simply get lost in the wakeup process11:56
Stskeepsit sits on one of the UARTs11:56
*** zuh has quit IRC11:57
jafdWell. As a quick-and-dirty workaround, it comes to mind that either userspace forces wake on UART, waits for it to settle and loads the module; or the module itself should take care of that.11:58
Stskeepsjafd: either one works, it's just we haven't had time to really work on that part11:58
Stskeepsjafd: you're more than welcome to investigate with those values and see if it helps11:58
jafdStskeeps: all right, can you please move the bugreport to the right place and tell where it is, for starts?>11:59
Stskeepswill do11:59
Stskeepssec11:59
Stskeepsjafd: https://bugs.nemomobile.org/show_bug.cgi?id=14912:00
Stskeepsyou can use merproject bugtracker username on there + login12:00
lbt(note, username, not email)12:00
Stskeeps+ password, i mean12:01
*** kulve has quit IRC12:02
Stskeepsi would have explained this issue more last night but was already in bed :) (most of n900 hackers are EU based012:02
*** zuh has joined #mer12:03
phaeronlbt: this is for the non-kvm path. anyway mic needs to be installable on host because imager uses some of its python modules12:03
*** KaIRC has joined #mer12:03
lbtoh12:04
phaeronlbt: for debian I removed the zypper deps as it is only needed when bootstrapping12:04
lbtgood12:04
phaeronI already committed the code for imager to work with new mic and was able to use it on debian to produce a rootfs12:05
phaeron(native)12:05
phaeronSage_: had some patches to new mic but the version in Mer:Tools:Testing doesn't have them I think12:07
lbtneat - so this gets us up to speed with IMG much quicker12:07
*** kulve has joined #mer12:08
phaeronyes we don't have to mess around with kvm just yet12:08
lbtbefore we started on the toolchain chat, Stskeeps and I said we'd do c.obs when you arrived12:08
phaeronalthough I'll work on the kvm + lvm thing we talked about12:08
lbtso are you up for that today?12:08
phaeronlbt: upgrade ?12:08
lbtphaeron: yep12:08
lbtJFDI12:09
lbt:)12:09
phaeronsure I was trying to generate a short diff to see what the hell changed12:09
*** toscalix has joined #mer12:09
phaeronI know at least that all declined requests will become open and needs someone to really close them or supersede etc ..12:09
jafdStskeeps: thanks12:10
phaeronand Stskeeps said about the Hostarch thing12:10
lbtphaeron: eek12:10
lbtall declined requests!12:10
phaeronyeah declined is no longer the final state. and action from requester is needed12:11
phaeron(or admin)12:11
lbtoh cool -- hardcoded processes that hit processes that we thought were done ... how neat is that!12:11
Stskeepsobs upgrade issue?12:20
lbtyeah12:22
lbtwe'll deal with it when it arises though12:22
Stskeepsk12:22
*** leinir_ has joined #mer12:26
*** leinir has quit IRC12:26
*** leinir_ is now known as leinir12:27
lbtStskeeps join #meego-it ?12:33
Stskeepsmmk12:33
*** tarantism has quit IRC12:35
*** talavis has quit IRC12:35
*** tomeff has joined #mer12:35
*** sonach has joined #mer12:41
Stskeeps[13:42] <lbt> we have some unplanned maintenance on c.obs... sorry for the slight outage12:43
*** sonach has left #mer12:56
*** mdavey has joined #mer12:59
*** tsdedst has quit IRC13:01
*** vgrade has quit IRC13:10
*** vgrade has joined #mer13:13
*** toscalix has quit IRC13:13
*** flywheel has joined #mer13:27
Macernice13:29
Macerhttp://vetus.scientiam.org/2012/02/17/the-removal-of-ad-droid-from-an-asus-transformer-in-progress/13:31
Macermaking progress lol13:31
*** flywheel has quit IRC13:33
*** flywheel_ has joined #mer13:34
Macerpretty soon i'm hoping to actually start trying to put mer onto it13:34
Macerjust have to get past the transformer learning curve.. well.. mer+active :-P13:35
*** flywheel_ has quit IRC13:35
*** flywheel_ has joined #mer13:36
*** flywheel_ has joined #mer13:37
*** arcean has quit IRC13:38
phaeronStskeeps: so OT, how about the old glibc kernel headers issue. will I need to build my own ?13:38
Stskeepsyes, perhaps13:39
phaeroncrap :/13:39
Stskeepsit's easy13:40
Stskeepsjust replace tarball13:40
Stskeepsadjust version number13:40
Stskeepsgo13:40
Stskeeps:P13:40
* phaeron is lazy13:40
phaeronok13:40
*** shanem_ has joined #mer13:40
*** shanem has quit IRC13:41
* lbt wonders when/why a vendor would need to do that13:41
Stskeepslbt: bleeding edge btrfs snapshotting syscall as an example..13:42
phaeronwell if your device can run new kernels and you have software that can get benefit from newer kernel headers13:42
phaeronin my case it's the udisks package which needs 3.1 kernel for some new loopdev syscalls13:43
lbtStskeeps: yeah - so then what13:43
Stskeepslbt: 'run own core programme' story, upgrade kernel-headers package13:43
phaeronthat's why I was asking13:44
phaeronwould glibc need to be rebuilt !13:44
Stskeepsi don't think so13:44
Stskeepssometimes i would need to be but in this case, no13:45
lbtso what does need a rebuild - I thought glibc was the thing that depended on headers13:45
Stskeepslbt: it theoretically needs to, but in this particular example, it doesn't need to13:45
Stskeepsi think13:45
Stskeepsi might be wrong13:45
*** Cwalle has joined #mer13:53
*** Cwalle has quit IRC14:07
*** trbs has joined #mer14:14
*** drussell has quit IRC14:20
*** HazardousWaster has quit IRC14:20
*** HazardousWaster has joined #mer14:22
*** Cwalle has joined #mer14:23
*** M4rtinK has joined #mer14:28
*** Cwalle has quit IRC14:30
*** pohly has joined #mer14:34
*** dionet has joined #mer14:40
Stskeepswoo, my gfx chip on my r-pi actually works14:49
*** talavis has joined #mer15:12
vgradeStskeeps, do you have the eth0 issue?15:37
Stskeepsvgrade: it worked on first bootup but i'm almost sure i'd have the issue15:38
Stskeeps(stowed away the kit again)15:38
vgradeI edited the udev config and that fixed it15:38
Stskeepsok15:38
DocScrutinizerStskeeps: what's state with ofono (or what else do you plan to use for interfacing modem?), esp regarding www.wirelessmodemapi.com being down obviously?15:40
StskeepsDocScrutinizer: ofono looks to continue normally15:41
Stskeepsi have no idea about wirelessmodemapi15:41
DocScrutinizerwell, no idea about why it's down, or no idea what it's all about generally?15:42
Stskeepsi have no idea about why it's down15:42
DocScrutinizerhmm15:42
DocScrutinizerdown doesn't reassure me of Nokia's willingness to support FOSS development for their modems15:43
Stskeepskeep in mind the modem division got sold to Renesas15:43
DocScrutinizeroooh15:43
Stskeepsso it's not even in nokia anymore15:44
DocScrutinizerso *what* is Nokia now?15:44
Stskeepsthat's a very good question15:44
DocScrutinizera rebranding for windows hardware?15:44
DocScrutinizers/windows/misocroft/15:46
Stskeepswell, i'm not a nokia employee, so i wouldn't know15:46
Stskeepsbut anyway, you might be able to get in touch with renesas15:46
DocScrutinizerindeed, might be reasonable15:47
DocScrutinizerso is Nokia buying the BB5 chips for N9 from Renesas now?15:49
Stskeepsi have no idea, the split happened quite a while ago15:49
* DocScrutinizer feels terribly depressed15:50
DocScrutinizerwell, at least that's kinda additional motivation for me to help make STE Thorium LTE chipset a success story, for my daywork employer15:51
Stskeepsisn't STE modems ISI too?15:52
DocScrutinizerhmm, no idea15:52
DocScrutinizerI think they got classic AT interface, but also something that looks pretty similar to ISI by architecture15:53
DocScrutinizercalled CAIF15:53
DocScrutinizerit's in kernel directly beneath phonet defs15:53
DocScrutinizerCAIF being the transport layer above (usually) HSI interface15:55
DocScrutinizeractually the connection layer15:55
DocScrutinizerseveral muxed virtual channels15:55
DocScrutinizerhttp://www.stericsson.com/products/u9500-novathor.jsp et al15:58
DocScrutinizerhttp://en.wikipedia.org/wiki/CAIF  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=70596b612c04694806a31dd389bd796c035085fa15:59
*** yue has quit IRC16:19
*** smoku has left #mer16:26
*** araujo has quit IRC16:34
*** araujo has joined #mer16:36
*** smoku has joined #mer16:38
*** Alison_Chaiken has joined #mer16:51
*** cam- has quit IRC16:54
*** Dotti has joined #mer16:58
*** lynxis has joined #mer17:08
*** deathrighns has joined #mer17:20
deathrighnshello ?17:20
deathrighnsthis place for help with n900 meego installations ?17:21
andre__define "n900 meego".17:27
andre__If you mean Mer/Nemo: yes17:27
andre__(previously called MeeGo CE/DE = Community/Developer Edition)17:27
Sage_phaeron: I've submitted all my patches for new mic to mic upstream17:31
Sage_and AFAIK all of those have been accepted already as wel17:31
phaeronI can't see the --save-kernel option, maybe we need to update our package17:33
*** andre__ has quit IRC17:35
Sage_phaeron: hmm... what version?17:41
phaeron0.417:41
Sage_--copy-kernel is in 0.517:42
Sage_and yes it was renamed from save-kernel to copy-kernel17:42
Sage_ps. 0.6 has regressions which makes fs type not working fix is in https://github.com/jfding/mic/commit/5abead0efc7b0f84c83c9445b565c794dbf54e8a17:43
phaeronSage_: ok thanks17:47
*** phdeswer has joined #mer17:48
*** afiestas has joined #mer18:05
*** xtcx is now known as tomas18:10
*** tomas is now known as thomashc18:18
*** deathrighns has quit IRC18:20
*** andre__ has joined #mer18:20
*** berndhs has joined #mer18:24
*** shanem_ has quit IRC18:25
*** nsuffys has joined #mer18:27
*** shanem_ has joined #mer18:39
*** beford has joined #mer18:42
*** beford has quit IRC18:42
*** beford has joined #mer18:42
Stskeepslbt: i've sent out the bug triage mail so everything's ready for you to handle it18:57
lbtok - no problem18:57
Stskeepsso far so good on sb2-obs enabled builds18:58
lbtjust fixing MythTV listings, then back to workers18:58
*** smoku has left #mer18:58
*** smoku has joined #mer18:58
lbtyeah they look OK apart from the workers with bad kernel18:58
lbtmay just need a reboot18:58
Stskeepslbt: yeah18:58
Stskeepssmoku: Core-next now is sb2-obs enabled, please let me know if any of your GTK based stuff breaks18:58
lbtrebooting 0318:59
Stskeepsmakes sense18:59
lbtit was, for sure, checked uname and lib/modules18:59
lbtmismatch :)18:59
lbtpuppet should magically fix things too19:00
lbtI spent ages on that19:00
*** cmazieri has joined #mer19:01
Stskeepshello cmazieri19:01
cmazierihello19:01
Stskeepswelcome :) so what brings you here to #mer ?19:02
cmazieriI am qt developer, I have a N9 phone and create some apps19:02
Stskeepsah, cool :)19:02
cmazieriI would like to test mer19:02
Stskeepswell, first the confusing part: mer's just a core, you couple it with a hardware adaptation (outside the project) and you get a login: prompt, couple it together with a ui and you have a device booting to your ui :)19:03
Stskeepsso you're likely to find someone already putting a ui on top of mer, for example plasma active or nemo19:04
*** cmazieri has quit IRC19:05
smokuStskeeps: I sure will :)19:06
*** jbos has quit IRC19:18
*** khohm has quit IRC19:18
*** spre has quit IRC19:18
Stskeepslbt: pubworker03 is still screwed19:22
lbtok19:22
Stskeepslbt: thanks for taking time to upgrade today, we can have a good start on the week tomorow then19:23
lbtheh, no problem19:24
*** smoku has left #mer19:24
*** smoku has joined #mer19:25
smokuStskeeps: where should I get compatible osc and build sources?19:26
Stskeepssmoku: yeah, hmm.. are you against installing them from a git yourself right now?19:27
*** thomashc has quit IRC19:27
*** vgrade has quit IRC19:27
Stskeepshttps://github.com/Merproject - obs-build and osc19:27
Stskeepsi'm working hard to upstream this stuff so it should be temporary19:27
smokuStskeeps: I would prefer to upgrade tarballs in packaging and just wait to rebuild19:27
*** lynxis has quit IRC19:28
smokuI will just git archive them then :)19:28
Sage_Stskeeps: nice, I'll build the new image against next Tomorrow19:29
StskeepsSage_: :nod:19:29
*** vgrade has joined #mer19:30
*** M4rtinK has quit IRC19:31
lbtStskeeps: removed initrd and puppet magically fixed it19:33
*** smoku has left #mer19:33
*** smoku has joined #mer19:34
*** smoku has left #mer19:40
Stskeepspubworker03 looks better now yes19:44
*** andre__ has quit IRC19:53
StskeepsSage_: spotted https://build.pub.meego.com/package/show?package=plymouth-lite&project=CE%3AMW%3AShared so far19:54
*** harbaum has joined #mer19:57
*** harbaum has quit IRC20:03
*** talavis has quit IRC20:04
*** harbaum has joined #mer20:08
*** berndhs has quit IRC20:08
*** jstaniek has joined #mer20:10
*** thomashc has joined #mer20:10
*** brooklyn has joined #mer20:13
*** singler has joined #mer20:16
*** dionet has quit IRC20:20
*** tpn has joined #mer20:20
*** _av500_ is now known as av500CDGS20:40
*** brooklyn has quit IRC20:46
*** harbaum has quit IRC20:50
*** kavurt has joined #mer20:53
*** Free-MG has joined #mer20:57
*** pdz- has quit IRC21:07
*** brooklyn has joined #mer21:13
*** lynxis has joined #mer21:18
*** M4rtinK has joined #mer21:22
*** Free-MG has quit IRC21:30
*** thomashc has quit IRC21:36
*** thomashc has joined #mer21:42
*** talavis has joined #mer22:03
*** NIN101 has quit IRC22:04
*** himamura has quit IRC22:10
*** HazardousWaster has quit IRC22:31
*** HazardousWaster has joined #mer22:31
*** phaeron has quit IRC22:41
*** gimli has quit IRC22:44
*** nsuffys has quit IRC23:00
*** paulo has joined #mer23:25
*** paulo has quit IRC23:26
*** paulo has joined #mer23:27
*** paulo has quit IRC23:31
*** andre__ has joined #mer23:33
*** M4rtinK has quit IRC23:48
*** Alison_Chaiken has quit IRC23:48
*** andre__ has quit IRC23:48
*** M4rtinK has joined #mer23:49
*** paulo has joined #mer23:59

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!