*** jstaniek has quit IRC | 00:00 | |
*** asdfafew has quit IRC | 00:01 | |
*** dijenerate has joined #mer | 00:03 | |
*** tilgovi has quit IRC | 00:04 | |
*** yue has joined #mer | 00:04 | |
*** NIN_ has quit IRC | 00:22 | |
*** Alison_Chaiken has joined #mer | 00:28 | |
*** kurtul has joined #mer | 00:32 | |
*** tpn has quit IRC | 00:42 | |
*** M4rtinK has joined #mer | 00:46 | |
*** lynxis has joined #mer | 00:55 | |
*** trbs has quit IRC | 01:12 | |
*** M4rtinK has quit IRC | 01:12 | |
*** KaiRo_Mozilla has quit IRC | 01:16 | |
*** lynxis has quit IRC | 01:29 | |
*** lynxis has joined #mer | 01:33 | |
*** lynxis has quit IRC | 01:40 | |
*** HazardousWaster has quit IRC | 01:50 | |
*** HazardousWaster has joined #mer | 01:50 | |
*** phaeron has joined #mer | 01:53 | |
*** returnth` is now known as returnthis | 02:01 | |
*** BeholdMyGlory has quit IRC | 02:05 | |
*** BeholdMyGlory has joined #mer | 02:07 | |
*** rolandx1_ has joined #mer | 02:41 | |
*** wubudubudubudu has joined #mer | 02:41 | |
*** rolandx1 has quit IRC | 02:44 | |
*** Venemo has quit IRC | 02:45 | |
*** otep has quit IRC | 03:03 | |
*** otep has joined #mer | 03:05 | |
*** thomashc has quit IRC | 03:21 | |
*** thomashc has joined #mer | 03:21 | |
*** cxl000 has quit IRC | 03:32 | |
*** smoku has left #mer | 03:43 | |
*** sonach has joined #mer | 03:45 | |
*** kurtul has quit IRC | 03:48 | |
*** cxl000 has joined #mer | 03:49 | |
*** returnthis has left #mer | 03:56 | |
*** GeneralAntilles1 is now known as GeneralAntilles | 04:00 | |
*** GeneralAntilles has joined #mer | 04:00 | |
*** cxl000 has quit IRC | 04:04 | |
Macer | hm | 04:31 |
---|---|---|
Macer | does anybody here have a tranformer? | 04:31 |
Macer | i'm trying to figure out how to back it up in recovery mode/apx mode | 04:31 |
*** phaeron has quit IRC | 04:32 | |
Macer | hm | 04:36 |
*** jargon-_ has quit IRC | 04:49 | |
*** phaeron has joined #mer | 04:50 | |
Macer | ah well | 04:59 |
Macer | i'm stuck :) | 04:59 |
*** beyondcreed has joined #mer | 05:12 | |
*** cxl000 has joined #mer | 05:16 | |
*** kurtul has joined #mer | 05:18 | |
*** ZiQiangHuan has joined #mer | 05:23 | |
*** sonach has left #mer | 05:24 | |
*** kthomas_vh_ has joined #mer | 05:27 | |
*** onekenthomas has quit IRC | 05:28 | |
*** Alison_Chaiken has quit IRC | 05:29 | |
*** cxl000 has quit IRC | 05:31 | |
*** ZiQiangHuan has quit IRC | 05:33 | |
*** Alison_Chaiken has joined #mer | 05:41 | |
*** cxl000 has joined #mer | 05:43 | |
*** lynxis has joined #mer | 05:50 | |
*** cxl000 has quit IRC | 05:51 | |
*** lynxis has quit IRC | 05:56 | |
*** Alison_Chaiken has quit IRC | 05:58 | |
*** wwweagle has joined #mer | 06:05 | |
*** wwweagle has left #mer | 06:06 | |
*** wwweagle has joined #mer | 06:06 | |
*** cxl000 has joined #mer | 06:17 | |
*** rolandx1_ is now known as rolandx1 | 06:25 | |
*** phaeron has quit IRC | 06:37 | |
*** Alison_Chaiken has joined #mer | 06:43 | |
*** Khaled has joined #mer | 06:57 | |
*** Khaled has quit IRC | 07:17 | |
Stskeeps | morn | 07:19 |
wwweagle | afternoon @ china:) | 07:20 |
Stskeeps | hehe | 07:21 |
Stskeeps | i should really visit mainland china at some point, i've only been to hong kong | 07:21 |
wwweagle | sure | 07:22 |
cxl000 | morn | 07:22 |
Stskeeps | morn cxl000, how is it going? | 07:22 |
wwweagle | you'll got ton's of semi-fake tablets for few dollars | 07:22 |
cxl000 | too many irons in the fire. | 07:22 |
wwweagle | and happily porting mer on them... | 07:23 |
cxl000 | I currently been struggling with sgx drivers on the pandora | 07:23 |
cxl000 | It has an ancient 1.0.3 core | 07:23 |
Stskeeps | wwweagle: i do wonder to find some armv6 featurephone and just trying to hack mer on to them for the learning experience, yeah | 07:24 |
Stskeeps | cxl000: isn't there sgx drivers available for that anyway? | 07:24 |
cxl000 | TI's 4_04_00_03 code drop was the last to support them. | 07:26 |
Stskeeps | ok | 07:27 |
cxl000 | I 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 demos | 07:27 |
*** wwweagle has left #mer | 07:31 | |
Stskeeps | combine with omapfb maybe | 07:40 |
cxl000 | I trying to understand the internals of the interface to try and work out how to proceed. | 07:43 |
cxl000 | Is that what you have done with the n9xx omap/sgx X driver? | 07:46 |
Stskeeps | i wouldn't try to combine those, they're very specialized | 07:46 |
*** xtcx has joined #mer | 08:07 | |
*** thomashc has quit IRC | 08:09 | |
*** s1gk1ll has joined #mer | 08:19 | |
* Stskeeps ponders | 08:20 | |
*** M4rtinK has joined #mer | 08:21 | |
*** sigkill_ has quit IRC | 08:23 | |
*** Alison_Chaiken has quit IRC | 08:37 | |
Stskeeps | http://prog21.dadgum.com/128.html | 08:48 |
*** kurtul has quit IRC | 08:49 | |
*** M4rtinK has quit IRC | 08:59 | |
*** andre__ has joined #mer | 09:04 | |
*** andre__ has joined #mer | 09:04 | |
*** kurtul has joined #mer | 09:10 | |
lbt | morning all | 09:13 |
*** NIN101 has joined #mer | 09:15 | |
Stskeeps | morn lbt | 09:26 |
*** DocScrutinizer has quit IRC | 09:29 | |
*** DocScrutinizer has joined #mer | 09:30 | |
* Stskeeps grabs his small whiteboard | 09:32 | |
andre__ | yoyoyo! | 09:33 |
* lbt looks at his rather messy whiteboard which is just a big todo list | 09:34 | |
*** beford has quit IRC | 09:34 | |
Stskeeps | lbt: so what's the plan for today? | 09:38 |
lbt | I opened the bug list | 09:39 |
Stskeeps | ok | 09:39 |
lbt | SDK needs finishing | 09:39 |
lbt | I thought I'd try to fix something using it | 09:39 |
lbt | 2 birds | 09:39 |
Stskeeps | :nod: | 09:39 |
lbt | I packaged it better too | 09:39 |
lbt | so it's a multi-package | 09:39 |
lbt | hnn | 09:39 |
Stskeeps | from my side meego COBS matters as i can then do a proper prerelease monday or tuesday | 09:39 |
lbt | it depends on itself | 09:39 |
Stskeeps | SDK also matters so we can have along on next release | 09:40 |
lbt | is the hackday over? | 09:41 |
Stskeeps | think so | 09:42 |
Stskeeps | the next dependency in line is then i can show sb2-obs in production and i can try to mainline my patches to obs | 09:48 |
lbt | *nod* | 09:49 |
Macer | hm | 09:49 |
lbt | eek | 09:49 |
Stskeeps | hmm? | 09:49 |
lbt | no, eek | 09:49 |
Stskeeps | mice? | 09:50 |
Stskeeps | :P | 09:50 |
lbt | ROFL , yes actually | 09:50 |
Macer | still trying to figure out how to get this transformer to backup | 09:50 |
lbt | killed 2 last night | 09:50 |
Macer | using nvflash | 09:50 |
Macer | blah. i'll figure it out in a little bit. need to wake up now... been sick and slept 30 of the last 48 hours | 09:50 |
Stskeeps | lbt: http://build.meego.com/package/files?package=kvmic&project=Tools%3ABOSS | 09:56 |
lbt | ... | 09:57 |
lbt | :) | 09:57 |
Stskeeps | new mic kvm wrapper or something | 09:58 |
lbt | dunno - obs makes browsing code a bitch | 10:05 |
Stskeeps | download the tar.gz | 10:05 |
Stskeeps | :P | 10:05 |
lbt | like I said... | 10:06 |
lbt | the standalone tool to create, deploy and launch kvm images to run mic2 for image creation | 10:07 |
Stskeeps | and new mic too, i think | 10:07 |
lbt | the packaging uses rpm/* style - interesting | 10:07 |
lbt | it copies rootfs images | 10:08 |
Stskeeps | rpm/* ? | 10:08 |
lbt | phaeron and I discussed either qcow or better, writeable lvm snapshots | 10:09 |
Stskeeps | also plausible | 10:09 |
lbt | just as a place to keep the spec/yaml/changes/patches | 10:09 |
* Stskeeps is trying to architect up a sane solution for toolchain-core split | 10:10 | |
Stskeeps | ie, an actual maintainable one | 10:10 |
lbt | "sb2 is the toolchain" | 10:12 |
Stskeeps | i wish it was that easy | 10:12 |
lbt | how tied do they need to be | 10:12 |
Stskeeps | okay, let me try to explain what's going on, if you have time for a 30 minutes brainstorm or something | 10:13 |
* Stskeeps gets his camera | 10:13 | |
lbt | OK | 10:13 |
*** zutesmog1 has quit IRC | 10:15 | |
*** zutesmog has joined #mer | 10:15 | |
Stskeeps | http://releases.merproject.org/~carsten/20120219_001.jpg | 10:18 |
*** kurtul has quit IRC | 10:18 | |
Stskeeps | so, 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 hosted | 10:18 |
Stskeeps | toolchain and core are two seperate dependency trees | 10:19 |
Stskeeps | core is built towards a target, can be armv7l, x86, etc | 10:19 |
Stskeeps | in order to start build for target with 'ordinary' packages, the target must have a number of packages cross built/baselibs'ed over | 10:20 |
Stskeeps | such as 'setup', 'filesystem', 'mer-rpm-config', as well as target specific RPM configuration (cross target rpm build config, cross target) rpm config | 10:20 |
Stskeeps | you 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 with | 10:21 |
Stskeeps | this requires kernel headers to do, naturally | 10:21 |
Stskeeps | the results of the cross compiler (it's libgcc for target, libgomp, libmudflap-devel, libobjc, libstdc++-devel) should be available as packages in target | 10:22 |
Stskeeps | as well as exporting a built glibc + devel headers | 10:22 |
Stskeeps | .. makes sense/any questions? | 10:23 |
lbt | yes/yes | 10:23 |
lbt | "you also need to build a cross compiler " | 10:23 |
lbt | this is target specific I assume | 10:23 |
lbt | but lives on the left | 10:23 |
Stskeeps | yes | 10:23 |
lbt | so it feels like the LHS has target specific sections and a common section | 10:24 |
lbt | or there's a middle section | 10:24 |
Stskeeps | it is x86 binary with built ARM libraries to build against (libgcc, libstdc++-devel, etc) | 10:24 |
Stskeeps | (cross compiler) | 10:24 |
lbt | thinking of the architectural view | 10:24 |
lbt | toolchain/target-toolchain/target are 3 distinct areas ? | 10:25 |
lbt | target = core and goes on device | 10:25 |
lbt | does target-toolchain contribute some things to the core? (libgcc) | 10:26 |
Stskeeps | yes, it does | 10:27 |
lbt | via baselibs? | 10:27 |
Stskeeps | yes, aggregated over | 10:27 |
Stskeeps | as you can't mix toolchain and target dependancies | 10:27 |
lbt | but nothing that lives in the toolchain is aggregated over | 10:27 |
Stskeeps | at the moment i've envisioned target-toolchain as part of toolchain, as it builds against it for sure | 10:28 |
Stskeeps | but you're right, in toolchain itself, it does not necessarily need to be | 10:29 |
Stskeeps | right now i'm exporting stuff like rpm configs, filesystem, setup, etc | 10:29 |
Macer | ugh | 10:30 |
Macer | [mace@mer Linux]$ ./nvflash --bct transformer.bct --setbct --configfile flash.cfg --bl bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync | 10:30 |
Macer | Nvflash started | 10:30 |
Macer | Permission Denied[mace@mer Linux]$ | 10:30 |
Stskeeps | Macer: sudo.. | 10:30 |
lbt | so... what do they do | 10:31 |
lbt | and where do they live? | 10:31 |
Macer | hm | 10:32 |
Macer | ok | 10:32 |
Stskeeps | rpm configs is pretty simple, it's the stuff rpm needs to function (not binaries), so it's /usr/lib/rpm/rpmrc /macros and such | 10:32 |
Macer | i just realized it may have something to do with the fact i encrypted the tablet lol | 10:32 |
Stskeeps | filesystem imposes a basic file system structure inside rpm, owning certain directories, so does setup | 10:32 |
lbt | are any of them not noarch ? | 10:33 |
Stskeeps | they're noarch, but rpm configs do need some changes to fit with the architecture they're installed onto | 10:34 |
lbt | that's OK - that's just source control of the target | 10:34 |
Stskeeps | yeah | 10:34 |
Macer | BACKUP_DIR="tf101-backup-`date +%Y%m%d%H%M%S`" | 10:35 |
Macer | mkdir $BACKUP_DIR | 10:35 |
Macer | oops | 10:35 |
Stskeeps | lbt: 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, etc | 10:35 |
Stskeeps | ideally i'd have a toolchain release, and then you can aggregate from the target-toolchain stuff into a core OBS project start building core sources | 10:37 |
Stskeeps | ie, one toolchain, N targets | 10:37 |
lbt | I know the answer ... what does core sources build against? | 10:38 |
lbt | does that part need to change? | 10:38 |
Stskeeps | it does not build against toolchain | 10:38 |
lbt | do we need to add a <toolchainpath> | 10:39 |
Stskeeps | it builds against the results of target-toolchain exports | 10:39 |
Stskeeps | the dependency tree of toolchain is out of reach | 10:39 |
lbt | toolchain-target | 10:39 |
lbt | can toolchain-target build toolchain? | 10:39 |
Stskeeps | no | 10:39 |
Stskeeps | well, i suppose it could, but it'd be a little more involved | 10:40 |
*** arcean has joined #mer | 10:40 | |
lbt | agreed - but it could | 10:40 |
lbt | nm | 10:40 |
Stskeeps | the 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-hosting | 10:41 |
Stskeeps | as well as increase portability, ie, we can point it at a android-sh4 target if we so cared | 10:41 |
lbt | yes | 10:41 |
Stskeeps | and i want to do it in such a way that we're not modifying typical .spec files | 10:41 |
lbt | so toolchainpath | 10:42 |
Stskeeps | or voodoo rpm configs | 10:42 |
lbt | does that terminology I mentioned - the 3-way split - add value ? | 10:42 |
Stskeeps | it might | 10:42 |
lbt | toolchain, toolchain-target, target | 10:42 |
lbt | toolchain, toolchain-target, core | 10:42 |
lbt | so if toolchain-target is added to the <path> list | 10:43 |
Stskeeps | we cannot let core in any way get dependancies that isn't explicitly exported from toolchain-target | 10:43 |
lbt | like ? | 10:44 |
Stskeeps | ok, i think i forgot to mention one thing | 10:44 |
Stskeeps | / is initialized with 'toolchain' x86 binaries, including cross compiler and so on, /target is where target packages gets installed into | 10:44 |
Stskeeps | and sb2 in / oto | 10:45 |
Stskeeps | too | 10:45 |
lbt | mmm - that's the build environment | 10:45 |
Stskeeps | yes | 10:45 |
Stskeeps | just to understand what -does- get passed on somehow | 10:46 |
Stskeeps | from toolchain side | 10:46 |
lbt | but nothing of that gets into buildroot and into %files | 10:46 |
Stskeeps | correct | 10:46 |
*** beyondcreed has quit IRC | 10:47 | |
Stskeeps | so, 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 |
Stskeeps | template packages being put into target-toolchain-XXX with config for what target to target | 10:48 |
lbt | yep | 10:48 |
Stskeeps | er, s/toolchain core/toolchain/ | 10:48 |
lbt | yep :) | 10:48 |
Stskeeps | i suppose that could work | 10:48 |
* lbt wasn't going to mention that | 10:48 | |
lbt | but why export | 10:48 |
lbt | last step | 10:48 |
lbt | why not multi-path | 10:49 |
Stskeeps | you need to, in order to be able to build packages for the core | 10:49 |
Stskeeps | the stuff on my picture is the minimal set of being able to build a package transparently | 10:49 |
Stskeeps | for a target | 10:49 |
lbt | not sure I understand why they differ | 10:50 |
Stskeeps | when i hear multi path, i hear target-toolchain and toolchain's dependency tree slipping into target | 10:50 |
lbt | yeahbut | 10:50 |
lbt | does core have gcc | 10:50 |
lbt | no | 10:50 |
lbt | so it has to BR it | 10:51 |
lbt | so that comes from tc-target | 10:51 |
lbt | tc-target is a valid dep source | 10:51 |
lbt | it's also isolated from target | 10:51 |
lbt | tc-target is an invalid Require source | 10:51 |
lbt | and IMG will get that | 10:51 |
lbt | when we install test | 10:51 |
lbt | incidentally tc-target is a valid indirect Require source during build | 10:52 |
Stskeeps | ah, 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 empty | 10:53 |
Stskeeps | as it's all handled in sb2 tools | 10:53 |
lbt | yep - makes sense | 10:53 |
Stskeeps | that package is in target | 10:53 |
Stskeeps | and exported as well | 10:53 |
lbt | OK | 10:53 |
lbt | so I'd prefer to say that a version is built for tc-target | 10:53 |
lbt | to keep it clean | 10:53 |
Stskeeps | rephrase that? | 10:54 |
lbt | re-reading to check | 10:54 |
*** tomeff has quit IRC | 10:54 | |
lbt | ah you said "that package is in target" I read "that package is in toolchain" | 10:54 |
lbt | which sounded wrong | 10:55 |
Stskeeps | :nod: | 10:55 |
Macer | wow | 10:55 |
Macer | i think i managed to make a backup of my transformer | 10:55 |
lbt | could it go in toolchain-target ? | 10:55 |
Macer | as well as get the kernel downloaded etc | 10:55 |
Macer | lol | 10:55 |
Macer | one step closer | 10:55 |
Stskeeps | lbt: it's being exported from toolchain-target to target as toolchain-target is the only one knowing what exact gcc versions autoconf , etc there are | 10:55 |
lbt | again - why export? | 10:56 |
Stskeeps | because we can't get a clean dependancy tree in core else | 10:56 |
Stskeeps | export == baselibs | 10:56 |
Stskeeps | and aggregate | 10:56 |
lbt | which is important why? since we're not self-hosting | 10:56 |
lbt | so... | 10:57 |
lbt | the reason I ask is that export = aggregate == copy to somewhere I can depend on it during build | 10:57 |
lbt | but I don't care during install | 10:57 |
lbt | so instead of copying | 10:57 |
lbt | put it somewhere I can find it during build | 10:57 |
lbt | ie during build add another <path> so I look there | 10:57 |
lbt | and 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 |
Stskeeps | during build we can't dep on gcc because it doesn't exist for the target, obviously | 10:58 |
lbt | mmm | 10:59 |
lbt | but you said we provide a stub | 10:59 |
lbt | so .... that's a valid solution | 10:59 |
lbt | during install we can't depend on it | 10:59 |
lbt | but if you aggregated that package to core - we could! | 10:59 |
lbt | or am I missing something ? | 10:59 |
Stskeeps | the stub package is aggregated to core and if you end up installing the stub in an image, that's bad packaging | 11:00 |
Stskeeps | :P | 11:00 |
lbt | :) | 11:00 |
lbt | and that *never* happens | 11:00 |
Stskeeps | mm | 11:00 |
lbt | so ... don't aggregate it to core | 11:00 |
Stskeeps | i'd like to know what your alternative is | 11:01 |
lbt | <path> | 11:01 |
Stskeeps | to what | 11:01 |
lbt | but only to toolchain-target | 11:01 |
lbt | which is only a buildtime thing | 11:01 |
Stskeeps | you can't limit the length of a path | 11:01 |
Stskeeps | if we path to toolchain-target, it'll path to toolchain | 11:01 |
lbt | which is why I mentioned <toolchainpath> | 11:02 |
Stskeeps | as toolchain-target needs toolchain to build | 11:02 |
lbt | or even <path depth=1> | 11:02 |
lbt | or something | 11:02 |
Stskeeps | another fun issue | 11:02 |
Stskeeps | we need independent prjconfs for core | 11:02 |
Stskeeps | so this feels like a rabbithole | 11:03 |
lbt | incidentally | 11:03 |
lbt | how about publishing toolchain-target | 11:03 |
Stskeeps | so there's two ways to solve the install-issue | 11:03 |
lbt | then DoD it | 11:03 |
lbt | kinda | 11:04 |
Stskeeps | ok, three | 11:04 |
lbt | we want a static version of it for a long time | 11:04 |
lbt | so changing the toolchain *is* rare and explicit | 11:04 |
lbt | (for vendors) | 11:04 |
Stskeeps | so, two sides: we want to have CI working with changing toolchain bits, or updating the libc | 11:04 |
Stskeeps | so we need a change in toolchain to ripple through to core | 11:05 |
lbt | really ? | 11:06 |
Stskeeps | yes | 11:06 |
Stskeeps | else we can't ever see results of toolchain upgrades | 11:06 |
lbt | yesbut | 11:06 |
lbt | aren't you mixing CI of toolchain and CI of core | 11:06 |
lbt | if you want them split .... then split them | 11:07 |
Stskeeps | CI of toolchain naturally means that core will be rebuilt too | 11:07 |
Stskeeps | and that's validation of toolchain | 11:07 |
lbt | by all means use a copy of core as the CI validation of toolchain | 11:07 |
lbt | but.... do vendors want to see that - what's the release process | 11:07 |
Stskeeps | anyway, you do have a point with the install process | 11:08 |
Stskeeps | two ways to solve that | 11:08 |
Stskeeps | ok, three | 11:08 |
Stskeeps | 1) 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 it | 11:08 |
Stskeeps | attached == <path> | 11:09 |
lbt | is 1) the <path depth=1> thing? | 11:09 |
Stskeeps | no, publishing/DoD, so we're up at 4.. | 11:09 |
lbt | good <path depth> was an idea ... 1) is more sane I think | 11:10 |
lbt | although it would avoid aggregates and be nicely OBS-ish | 11:11 |
lbt | but too little time | 11:11 |
Stskeeps | my head tells me that DoD/publishing can be more trouble than worth, i'm just having difficulties to put words on it | 11:13 |
Stskeeps | as there's some problem when target is i586 to | 11:13 |
Stskeeps | o | 11:13 |
Stskeeps | i'm not discounting it though | 11:13 |
lbt | 3) seems interesting | 11:14 |
lbt | 2) would send them to core? I'm not keen on that | 11:14 |
Stskeeps | 2) would send them in for build process but not for publish phase | 11:15 |
Stskeeps | i'm thinking 3) might be sane | 11:15 |
*** ieatlint has quit IRC | 11:16 | |
*** ieatlint has joined #mer | 11:16 | |
* lbt tries to remember why aggregate and not link | 11:17 | |
Stskeeps | link is sources | 11:17 |
Stskeeps | aggregate is binaries | 11:17 |
lbt | so it'd rebuild | 11:17 |
lbt | try + fail | 11:17 |
Stskeeps | :nod: | 11:17 |
lbt | projlink | 11:17 |
lbt | .... | 11:17 |
Stskeeps | projlink is sources too | 11:18 |
lbt | projaggregate :) | 11:18 |
Stskeeps | on occasion i wouldn't mind having that | 11:18 |
Stskeeps | i think 3) and the three OBS repo split can be very flexible | 11:19 |
Stskeeps | repo=project | 11:19 |
Stskeeps | and automation-able | 11:19 |
lbt | incidentatlly | 11:21 |
lbt | a snapshot of 3) is a release of the target toolchain isn't it ? | 11:21 |
lbt | so a vendor only needs that - no need for bootstrapping the tc | 11:21 |
Stskeeps | :nod: | 11:22 |
Stskeeps | we do have one place where we can't do that | 11:22 |
Stskeeps | we need to have glibc and libgcc and such for install phase | 11:22 |
lbt | grrr | 11:23 |
Stskeeps | yes, it's amazing what comes to your mind when you go to the bathroom.. | 11:23 |
Stskeeps | :P | 11:23 |
lbt | tmi | 11:24 |
Stskeeps | but 3) is still sane, but may need more kludgery | 11:25 |
lbt | I vaguely thought about having a template spec to build them | 11:25 |
lbt | that uses "cp" as the builder | 11:26 |
Stskeeps | i think we can do templates within toolchain that gets effectuated through toolchain-target by prjconf macros | 11:26 |
lbt | and similarly into core for libgcc and co ? | 11:27 |
Stskeeps | yes, i guess that could work | 11:27 |
Stskeeps | so we provide templates in toolchain, these get linkpac'ed into toolchain for target and becomes toolchain for target when built | 11:27 |
Stskeeps | very automate-able | 11:27 |
lbt | OK - so how about I do this ... with much guidance ... it'll be slower but educational | 11:28 |
lbt | you may feel the need for a large brandy before starting though | 11:28 |
Stskeeps | i'm a martini person, but yeah | 11:28 |
lbt | so let this stew and we'll do cobs and stuff today | 11:29 |
Stskeeps | even 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 |
Stskeeps | thanks for the brainstorm, it got me past the problem nicely | 11:31 |
lbt | yeah - nice to do something interesting! | 11:31 |
*** himamura has quit IRC | 11:32 | |
Stskeeps | :nod: | 11:34 |
*** himamura has joined #mer | 11:35 | |
Stskeeps | i do wonder what some of the downsides of the split will be, though | 11:35 |
lbt | lack of devel capability on device? | 11:37 |
Stskeeps | that's one thing, yes | 11:37 |
Stskeeps | on the other side of things, it does enable a wide range of targets and possibilities instead | 11:37 |
lbt | would the tc-target be "build-essential" though | 11:37 |
Stskeeps | yes | 11:37 |
Stskeeps | but for x86 | 11:38 |
lbt | and simply mean that build-essential was a discrete repo (which may be a -ve for 'openness') | 11:38 |
lbt | yah | 11:38 |
lbt | could we build tc-target-native ? | 11:38 |
Stskeeps | theoretically, but we need entire tc too | 11:39 |
lbt | I think that's what I had in mind when I asked if tc-target could build tc | 11:39 |
Stskeeps | i guess technically but i can't promise it for every core | 11:40 |
Stskeeps | think mer for bionic libc | 11:40 |
lbt | there are a lot of things (mainly ruby/python/perl style) where native extensions are needed | 11:40 |
lbt | yeah - I'm talking linux :) | 11:40 |
Stskeeps | :nod: | 11:40 |
Stskeeps | python/ruby/perl stuff is another issue | 11:41 |
lbt | obs built should be fine shouldnt' it? | 11:41 |
lbt | can't see a problem there | 11:41 |
lbt | but using pip or bundler something on device | 11:42 |
Stskeeps | anyway, moving on .. in SDK, it'd likely be an instance of toolchain+a number of target toolchains | 11:42 |
lbt | and with PA we're talking about a 'normal' linux platform experience | 11:42 |
lbt | OK - but add tc-target-native to the architectural backlog | 11:43 |
Stskeeps | :nod: | 11:43 |
Stskeeps | i'm aware the approach may be controversial as it changes the way you build device systems | 11:44 |
*** smoku has joined #mer | 11:44 | |
Stskeeps | and that a full Motif experience might not be posible easily, etc.. | 11:45 |
lbt | If we can provide the native toolchain then I think we're OK | 11:46 |
Stskeeps | yeah, but even then, it's not always 'apt-get' able into device | 11:47 |
*** phaeron has joined #mer | 11:47 | |
lbt | it means that the device can't update it's own toolchain using the same build mechanism | 11:47 |
Stskeeps | it might have to be a chroot | 11:47 |
Stskeeps | i think i can build the nasty set of packages needing to self-host with this approach | 11:48 |
lbt | it should be installable - may need a bit of trickery to replace dummies | 11:48 |
Stskeeps | so we can get a native sdk if really needed | 11:48 |
lbt | I think it's needed for acceptance | 11:48 |
phaeron | hello | 11:48 |
jafd | https://bugs.merproject.org/show_bug.cgi?id=183 by the way, I have followed advice from yesterday. Sorry for dropping in. | 11:49 |
Stskeeps | lo phaeron | 11:49 |
lbt | good afternoon phaeron | 11:49 |
Stskeeps | jafd: you're going to hate me in a moment.. | 11:49 |
Stskeeps | :P | 11:49 |
lbt | jafd: welcome | 11:49 |
Stskeeps | jafd: you filed in wrong bugtracker :) | 11:49 |
* lbt grins | 11:49 | |
Stskeeps | jafd: n900 hardware adaptation is in nemo mobile, mer doesn't have ui's or hardware adaptations | 11:49 |
Stskeeps | jafd: either way | 11:50 |
Stskeeps | jafd: the reason why bluetooth isn't working on n900 is two-fold | 11:50 |
lbt | phaeron: we've had a really interesing chat on toolchain splits | 11:50 |
phaeron | lbt: so newmic seems to be able to run natively on debian | 11:50 |
phaeron | oh | 11:50 |
* phaeron holds back | 11:50 | |
jafd | Stskeeps: 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 |
lbt | phaeron: interesting | 11:50 |
Stskeeps | jafd: ah, we should fix that.. | 11:50 |
Stskeeps | hang on | 11:50 |
* lbt slaps the nemo people | 11:50 | |
Stskeeps | jafd: 1) the serial line to bluetooth chip gets shut down by power management before it's possible to communicate with it | 11:50 |
jafd | I don't really care if the reporter changes in the course | 11:50 |
lbt | *ouch* | 11:51 |
Stskeeps | jafd: 2) the calibration tool won't work either because of this fact | 11:52 |
Stskeeps | jafd: if you figure out why 1) happens, then everything else should fall in place | 11:52 |
jafd | hm, I thought power management is more in-kernel than in-board | 11:52 |
Stskeeps | OMAP PM | 11:52 |
Stskeeps | we've done some experiments to try to fix the issue but we haven't found a cure just yet | 11:53 |
phaeron | lbt: 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 |
jafd | What I was wondering about is some report from meego bug that they have fixed it for some "release" but not in trunk. | 11:53 |
lbt | phaeron: I did notice this | 11:53 |
Stskeeps | jafd: show me the meego bug report? | 11:53 |
lbt | phaeron: but honestly ... SDK | 11:53 |
jafd | https://bugs.meego.com/show_bug.cgi?id=12363 | 11:53 |
*** wwweagle has joined #mer | 11:54 | |
phaeron | lbt: I am talking about imager | 11:54 |
Stskeeps | jafd: yes, that was from before we added power management patches | 11:54 |
lbt | phaeron: mmm | 11:54 |
lbt | phaeron: isn't the kvm worker a mer root using SDK ? | 11:55 |
lbt | when we do it right | 11:55 |
jafd | Stskeeps: so. There's an alternative of having bluetooth and draining battery really fast, or not having bluetooth, as of now | 11:55 |
lbt | phaeron: give me 5min to edit these notes b4 I forget | 11:55 |
*** wwweagle has left #mer | 11:55 | |
Stskeeps | jafd: as in being able to warm your hands on it, or bluetooth, yes, http://elinux.org/OMAP_Power_Management#UART_wakeup_and_timeout_options | 11:56 |
Stskeeps | the problem is that characters simply get lost in the wakeup process | 11:56 |
Stskeeps | it sits on one of the UARTs | 11:56 |
*** zuh has quit IRC | 11:57 | |
jafd | Well. 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 |
Stskeeps | jafd: either one works, it's just we haven't had time to really work on that part | 11:58 |
Stskeeps | jafd: you're more than welcome to investigate with those values and see if it helps | 11:58 |
jafd | Stskeeps: all right, can you please move the bugreport to the right place and tell where it is, for starts?> | 11:59 |
Stskeeps | will do | 11:59 |
Stskeeps | sec | 11:59 |
Stskeeps | jafd: https://bugs.nemomobile.org/show_bug.cgi?id=149 | 12:00 |
Stskeeps | you can use merproject bugtracker username on there + login | 12:00 |
lbt | (note, username, not email) | 12:00 |
Stskeeps | + password, i mean | 12:01 |
*** kulve has quit IRC | 12:02 | |
Stskeeps | i would have explained this issue more last night but was already in bed :) (most of n900 hackers are EU based0 | 12:02 |
*** zuh has joined #mer | 12:03 | |
phaeron | lbt: this is for the non-kvm path. anyway mic needs to be installable on host because imager uses some of its python modules | 12:03 |
*** KaIRC has joined #mer | 12:03 | |
lbt | oh | 12:04 |
phaeron | lbt: for debian I removed the zypper deps as it is only needed when bootstrapping | 12:04 |
lbt | good | 12:04 |
phaeron | I already committed the code for imager to work with new mic and was able to use it on debian to produce a rootfs | 12:05 |
phaeron | (native) | 12:05 |
phaeron | Sage_: had some patches to new mic but the version in Mer:Tools:Testing doesn't have them I think | 12:07 |
lbt | neat - so this gets us up to speed with IMG much quicker | 12:07 |
*** kulve has joined #mer | 12:08 | |
phaeron | yes we don't have to mess around with kvm just yet | 12:08 |
lbt | before we started on the toolchain chat, Stskeeps and I said we'd do c.obs when you arrived | 12:08 |
phaeron | although I'll work on the kvm + lvm thing we talked about | 12:08 |
lbt | so are you up for that today? | 12:08 |
phaeron | lbt: upgrade ? | 12:08 |
lbt | phaeron: yep | 12:08 |
lbt | JFDI | 12:09 |
lbt | :) | 12:09 |
phaeron | sure I was trying to generate a short diff to see what the hell changed | 12:09 |
*** toscalix has joined #mer | 12:09 | |
phaeron | I know at least that all declined requests will become open and needs someone to really close them or supersede etc .. | 12:09 |
jafd | Stskeeps: thanks | 12:10 |
phaeron | and Stskeeps said about the Hostarch thing | 12:10 |
lbt | phaeron: eek | 12:10 |
lbt | all declined requests! | 12:10 |
phaeron | yeah declined is no longer the final state. and action from requester is needed | 12:11 |
phaeron | (or admin) | 12:11 |
lbt | oh cool -- hardcoded processes that hit processes that we thought were done ... how neat is that! | 12:11 |
Stskeeps | obs upgrade issue? | 12:20 |
lbt | yeah | 12:22 |
lbt | we'll deal with it when it arises though | 12:22 |
Stskeeps | k | 12:22 |
*** leinir_ has joined #mer | 12:26 | |
*** leinir has quit IRC | 12:26 | |
*** leinir_ is now known as leinir | 12:27 | |
lbt | Stskeeps join #meego-it ? | 12:33 |
Stskeeps | mmk | 12:33 |
*** tarantism has quit IRC | 12:35 | |
*** talavis has quit IRC | 12:35 | |
*** tomeff has joined #mer | 12:35 | |
*** sonach has joined #mer | 12:41 | |
Stskeeps | [13:42] <lbt> we have some unplanned maintenance on c.obs... sorry for the slight outage | 12:43 |
*** sonach has left #mer | 12:56 | |
*** mdavey has joined #mer | 12:59 | |
*** tsdedst has quit IRC | 13:01 | |
*** vgrade has quit IRC | 13:10 | |
*** vgrade has joined #mer | 13:13 | |
*** toscalix has quit IRC | 13:13 | |
*** flywheel has joined #mer | 13:27 | |
Macer | nice | 13:29 |
Macer | http://vetus.scientiam.org/2012/02/17/the-removal-of-ad-droid-from-an-asus-transformer-in-progress/ | 13:31 |
Macer | making progress lol | 13:31 |
*** flywheel has quit IRC | 13:33 | |
*** flywheel_ has joined #mer | 13:34 | |
Macer | pretty soon i'm hoping to actually start trying to put mer onto it | 13:34 |
Macer | just have to get past the transformer learning curve.. well.. mer+active :-P | 13:35 |
*** flywheel_ has quit IRC | 13:35 | |
*** flywheel_ has joined #mer | 13:36 | |
*** flywheel_ has joined #mer | 13:37 | |
*** arcean has quit IRC | 13:38 | |
phaeron | Stskeeps: so OT, how about the old glibc kernel headers issue. will I need to build my own ? | 13:38 |
Stskeeps | yes, perhaps | 13:39 |
phaeron | crap :/ | 13:39 |
Stskeeps | it's easy | 13:40 |
Stskeeps | just replace tarball | 13:40 |
Stskeeps | adjust version number | 13:40 |
Stskeeps | go | 13:40 |
Stskeeps | :P | 13:40 |
* phaeron is lazy | 13:40 | |
phaeron | ok | 13:40 |
*** shanem_ has joined #mer | 13:40 | |
*** shanem has quit IRC | 13:41 | |
* lbt wonders when/why a vendor would need to do that | 13:41 | |
Stskeeps | lbt: bleeding edge btrfs snapshotting syscall as an example.. | 13:42 |
phaeron | well if your device can run new kernels and you have software that can get benefit from newer kernel headers | 13:42 |
phaeron | in my case it's the udisks package which needs 3.1 kernel for some new loopdev syscalls | 13:43 |
lbt | Stskeeps: yeah - so then what | 13:43 |
Stskeeps | lbt: 'run own core programme' story, upgrade kernel-headers package | 13:43 |
phaeron | that's why I was asking | 13:44 |
phaeron | would glibc need to be rebuilt ! | 13:44 |
Stskeeps | i don't think so | 13:44 |
Stskeeps | sometimes i would need to be but in this case, no | 13:45 |
lbt | so what does need a rebuild - I thought glibc was the thing that depended on headers | 13:45 |
Stskeeps | lbt: it theoretically needs to, but in this particular example, it doesn't need to | 13:45 |
Stskeeps | i think | 13:45 |
Stskeeps | i might be wrong | 13:45 |
*** Cwalle has joined #mer | 13:53 | |
*** Cwalle has quit IRC | 14:07 | |
*** trbs has joined #mer | 14:14 | |
*** drussell has quit IRC | 14:20 | |
*** HazardousWaster has quit IRC | 14:20 | |
*** HazardousWaster has joined #mer | 14:22 | |
*** Cwalle has joined #mer | 14:23 | |
*** M4rtinK has joined #mer | 14:28 | |
*** Cwalle has quit IRC | 14:30 | |
*** pohly has joined #mer | 14:34 | |
*** dionet has joined #mer | 14:40 | |
Stskeeps | woo, my gfx chip on my r-pi actually works | 14:49 |
*** talavis has joined #mer | 15:12 | |
vgrade | Stskeeps, do you have the eth0 issue? | 15:37 |
Stskeeps | vgrade: it worked on first bootup but i'm almost sure i'd have the issue | 15:38 |
Stskeeps | (stowed away the kit again) | 15:38 |
vgrade | I edited the udev config and that fixed it | 15:38 |
Stskeeps | ok | 15:38 |
DocScrutinizer | Stskeeps: 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 |
Stskeeps | DocScrutinizer: ofono looks to continue normally | 15:41 |
Stskeeps | i have no idea about wirelessmodemapi | 15:41 |
DocScrutinizer | well, no idea about why it's down, or no idea what it's all about generally? | 15:42 |
Stskeeps | i have no idea about why it's down | 15:42 |
DocScrutinizer | hmm | 15:42 |
DocScrutinizer | down doesn't reassure me of Nokia's willingness to support FOSS development for their modems | 15:43 |
Stskeeps | keep in mind the modem division got sold to Renesas | 15:43 |
DocScrutinizer | oooh | 15:43 |
Stskeeps | so it's not even in nokia anymore | 15:44 |
DocScrutinizer | so *what* is Nokia now? | 15:44 |
Stskeeps | that's a very good question | 15:44 |
DocScrutinizer | a rebranding for windows hardware? | 15:44 |
DocScrutinizer | s/windows/misocroft/ | 15:46 |
Stskeeps | well, i'm not a nokia employee, so i wouldn't know | 15:46 |
Stskeeps | but anyway, you might be able to get in touch with renesas | 15:46 |
DocScrutinizer | indeed, might be reasonable | 15:47 |
DocScrutinizer | so is Nokia buying the BB5 chips for N9 from Renesas now? | 15:49 |
Stskeeps | i have no idea, the split happened quite a while ago | 15:49 |
* DocScrutinizer feels terribly depressed | 15:50 | |
DocScrutinizer | well, at least that's kinda additional motivation for me to help make STE Thorium LTE chipset a success story, for my daywork employer | 15:51 |
Stskeeps | isn't STE modems ISI too? | 15:52 |
DocScrutinizer | hmm, no idea | 15:52 |
DocScrutinizer | I think they got classic AT interface, but also something that looks pretty similar to ISI by architecture | 15:53 |
DocScrutinizer | called CAIF | 15:53 |
DocScrutinizer | it's in kernel directly beneath phonet defs | 15:53 |
DocScrutinizer | CAIF being the transport layer above (usually) HSI interface | 15:55 |
DocScrutinizer | actually the connection layer | 15:55 |
DocScrutinizer | several muxed virtual channels | 15:55 |
DocScrutinizer | http://www.stericsson.com/products/u9500-novathor.jsp et al | 15:58 |
DocScrutinizer | http://en.wikipedia.org/wiki/CAIF http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=70596b612c04694806a31dd389bd796c035085fa | 15:59 |
*** yue has quit IRC | 16:19 | |
*** smoku has left #mer | 16:26 | |
*** araujo has quit IRC | 16:34 | |
*** araujo has joined #mer | 16:36 | |
*** smoku has joined #mer | 16:38 | |
*** Alison_Chaiken has joined #mer | 16:51 | |
*** cam- has quit IRC | 16:54 | |
*** Dotti has joined #mer | 16:58 | |
*** lynxis has joined #mer | 17:08 | |
*** deathrighns has joined #mer | 17:20 | |
deathrighns | hello ? | 17:20 |
deathrighns | this place for help with n900 meego installations ? | 17:21 |
andre__ | define "n900 meego". | 17:27 |
andre__ | If you mean Mer/Nemo: yes | 17: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 upstream | 17:31 |
Sage_ | and AFAIK all of those have been accepted already as wel | 17:31 |
phaeron | I can't see the --save-kernel option, maybe we need to update our package | 17:33 |
*** andre__ has quit IRC | 17:35 | |
Sage_ | phaeron: hmm... what version? | 17:41 |
phaeron | 0.4 | 17:41 |
Sage_ | --copy-kernel is in 0.5 | 17:42 |
Sage_ | and yes it was renamed from save-kernel to copy-kernel | 17:42 |
Sage_ | ps. 0.6 has regressions which makes fs type not working fix is in https://github.com/jfding/mic/commit/5abead0efc7b0f84c83c9445b565c794dbf54e8a | 17:43 |
phaeron | Sage_: ok thanks | 17:47 |
*** phdeswer has joined #mer | 17:48 | |
*** afiestas has joined #mer | 18:05 | |
*** xtcx is now known as tomas | 18:10 | |
*** tomas is now known as thomashc | 18:18 | |
*** deathrighns has quit IRC | 18:20 | |
*** andre__ has joined #mer | 18:20 | |
*** berndhs has joined #mer | 18:24 | |
*** shanem_ has quit IRC | 18:25 | |
*** nsuffys has joined #mer | 18:27 | |
*** shanem_ has joined #mer | 18:39 | |
*** beford has joined #mer | 18:42 | |
*** beford has quit IRC | 18:42 | |
*** beford has joined #mer | 18:42 | |
Stskeeps | lbt: i've sent out the bug triage mail so everything's ready for you to handle it | 18:57 |
lbt | ok - no problem | 18:57 |
Stskeeps | so far so good on sb2-obs enabled builds | 18:58 |
lbt | just fixing MythTV listings, then back to workers | 18:58 |
*** smoku has left #mer | 18:58 | |
*** smoku has joined #mer | 18:58 | |
lbt | yeah they look OK apart from the workers with bad kernel | 18:58 |
lbt | may just need a reboot | 18:58 |
Stskeeps | lbt: yeah | 18:58 |
Stskeeps | smoku: Core-next now is sb2-obs enabled, please let me know if any of your GTK based stuff breaks | 18:58 |
lbt | rebooting 03 | 18:59 |
Stskeeps | makes sense | 18:59 |
lbt | it was, for sure, checked uname and lib/modules | 18:59 |
lbt | mismatch :) | 18:59 |
lbt | puppet should magically fix things too | 19:00 |
lbt | I spent ages on that | 19:00 |
*** cmazieri has joined #mer | 19:01 | |
Stskeeps | hello cmazieri | 19:01 |
cmazieri | hello | 19:01 |
Stskeeps | welcome :) so what brings you here to #mer ? | 19:02 |
cmazieri | I am qt developer, I have a N9 phone and create some apps | 19:02 |
Stskeeps | ah, cool :) | 19:02 |
cmazieri | I would like to test mer | 19:02 |
Stskeeps | well, 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 |
Stskeeps | so you're likely to find someone already putting a ui on top of mer, for example plasma active or nemo | 19:04 |
*** cmazieri has quit IRC | 19:05 | |
smoku | Stskeeps: I sure will :) | 19:06 |
*** jbos has quit IRC | 19:18 | |
*** khohm has quit IRC | 19:18 | |
*** spre has quit IRC | 19:18 | |
Stskeeps | lbt: pubworker03 is still screwed | 19:22 |
lbt | ok | 19:22 |
Stskeeps | lbt: thanks for taking time to upgrade today, we can have a good start on the week tomorow then | 19:23 |
lbt | heh, no problem | 19:24 |
*** smoku has left #mer | 19:24 | |
*** smoku has joined #mer | 19:25 | |
smoku | Stskeeps: where should I get compatible osc and build sources? | 19:26 |
Stskeeps | smoku: yeah, hmm.. are you against installing them from a git yourself right now? | 19:27 |
*** thomashc has quit IRC | 19:27 | |
*** vgrade has quit IRC | 19:27 | |
Stskeeps | https://github.com/Merproject - obs-build and osc | 19:27 |
Stskeeps | i'm working hard to upstream this stuff so it should be temporary | 19:27 |
smoku | Stskeeps: I would prefer to upgrade tarballs in packaging and just wait to rebuild | 19:27 |
*** lynxis has quit IRC | 19:28 | |
smoku | I will just git archive them then :) | 19:28 |
Sage_ | Stskeeps: nice, I'll build the new image against next Tomorrow | 19:29 |
Stskeeps | Sage_: :nod: | 19:29 |
*** vgrade has joined #mer | 19:30 | |
*** M4rtinK has quit IRC | 19:31 | |
lbt | Stskeeps: removed initrd and puppet magically fixed it | 19:33 |
*** smoku has left #mer | 19:33 | |
*** smoku has joined #mer | 19:34 | |
*** smoku has left #mer | 19:40 | |
Stskeeps | pubworker03 looks better now yes | 19:44 |
*** andre__ has quit IRC | 19:53 | |
Stskeeps | Sage_: spotted https://build.pub.meego.com/package/show?package=plymouth-lite&project=CE%3AMW%3AShared so far | 19:54 |
*** harbaum has joined #mer | 19:57 | |
*** harbaum has quit IRC | 20:03 | |
*** talavis has quit IRC | 20:04 | |
*** harbaum has joined #mer | 20:08 | |
*** berndhs has quit IRC | 20:08 | |
*** jstaniek has joined #mer | 20:10 | |
*** thomashc has joined #mer | 20:10 | |
*** brooklyn has joined #mer | 20:13 | |
*** singler has joined #mer | 20:16 | |
*** dionet has quit IRC | 20:20 | |
*** tpn has joined #mer | 20:20 | |
*** _av500_ is now known as av500CDGS | 20:40 | |
*** brooklyn has quit IRC | 20:46 | |
*** harbaum has quit IRC | 20:50 | |
*** kavurt has joined #mer | 20:53 | |
*** Free-MG has joined #mer | 20:57 | |
*** pdz- has quit IRC | 21:07 | |
*** brooklyn has joined #mer | 21:13 | |
*** lynxis has joined #mer | 21:18 | |
*** M4rtinK has joined #mer | 21:22 | |
*** Free-MG has quit IRC | 21:30 | |
*** thomashc has quit IRC | 21:36 | |
*** thomashc has joined #mer | 21:42 | |
*** talavis has joined #mer | 22:03 | |
*** NIN101 has quit IRC | 22:04 | |
*** himamura has quit IRC | 22:10 | |
*** HazardousWaster has quit IRC | 22:31 | |
*** HazardousWaster has joined #mer | 22:31 | |
*** phaeron has quit IRC | 22:41 | |
*** gimli has quit IRC | 22:44 | |
*** nsuffys has quit IRC | 23:00 | |
*** paulo has joined #mer | 23:25 | |
*** paulo has quit IRC | 23:26 | |
*** paulo has joined #mer | 23:27 | |
*** paulo has quit IRC | 23:31 | |
*** andre__ has joined #mer | 23:33 | |
*** M4rtinK has quit IRC | 23:48 | |
*** Alison_Chaiken has quit IRC | 23:48 | |
*** andre__ has quit IRC | 23:48 | |
*** M4rtinK has joined #mer | 23:49 | |
*** paulo has joined #mer | 23:59 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!