| *** dijenerate has joined #mer | 00:06 | |
| *** KaIRC has quit IRC | 00:06 | |
| *** lynxis_ has quit IRC | 00:12 | |
| [JT] | I'm thinking about KDE Plasma Active Two on a Toshiba Thrive (NVidia Tegra 2). Has anyone attempted that yet? | 00:13 |
|---|---|---|
| *** zabomber has joined #mer | 00:18 | |
| *** KaIRC has joined #mer | 00:19 | |
| *** ssirkia has left #mer | 00:27 | |
| *** sebsauer__ has joined #mer | 00:39 | |
| *** sebsauer_ has quit IRC | 00:40 | |
| *** trbs has quit IRC | 00:44 | |
| *** raignarok has quit IRC | 00:54 | |
| *** buser has joined #mer | 00:54 | |
| *** purban has quit IRC | 00:58 | |
| *** raignarok has joined #mer | 01:05 | |
| *** buser has quit IRC | 01:18 | |
| *** tilgovi has joined #mer | 01:23 | |
| *** tilgovi has joined #mer | 01:23 | |
| *** jvd_ has quit IRC | 01:27 | |
| *** beford has joined #mer | 01:31 | |
| *** M4rtinK has quit IRC | 01:31 | |
| *** sebsauer has joined #mer | 01:34 | |
| *** phaeron1 has quit IRC | 01:35 | |
| *** sebsauer__ has quit IRC | 01:35 | |
| *** GeneralAntilles1 has joined #mer | 01:38 | |
| *** GeneralAntilles has quit IRC | 01:40 | |
| *** tilgovi has quit IRC | 01:59 | |
| *** raignarok has quit IRC | 02:05 | |
| cxl000 | [JT] it is not listed on http://wiki.merproject.com/wiki/Community_Workspace. If you want to try an adaptation you will 1st need to be able to boot your own kernel. | 02:05 |
| *** raignarok has joined #mer | 02:06 | |
| *** raignarok has joined #mer | 02:09 | |
| [JT] | cxl000: Okay; I think I can probably boot my own kernel (the device is rooted and I've loaded ClockworkMod). I'll do some research on how to get that done. | 02:22 |
| *** tilgovi has joined #mer | 02:24 | |
| *** tilgovi has joined #mer | 02:24 | |
| *** sebsauer_ has joined #mer | 02:26 | |
| cxl000 | [JT] Once you can know how to boot your own kernel you could look at http://wiki.meego.com/ARM/TEGRA2 and http://wiki.meego.com/ARM/TEGRA2/Notes | 02:27 |
| *** sebsauer has quit IRC | 02:27 | |
| *** HazardousWaster has quit IRC | 02:28 | |
| *** raignarok has quit IRC | 02:28 | |
| *** sebsauer_ has quit IRC | 02:40 | |
| *** kiviluoto has joined #mer | 02:41 | |
| *** kiviluoto_ has quit IRC | 02:41 | |
| *** zabomber has quit IRC | 02:46 | |
| *** lynxis has joined #mer | 02:51 | |
| *** jvd_ has joined #mer | 03:09 | |
| *** dijenerate has quit IRC | 03:31 | |
| *** zabomber has joined #mer | 03:32 | |
| *** tilgovi has quit IRC | 03:42 | |
| *** dijenerate has joined #mer | 03:43 | |
| *** sledges has quit IRC | 03:52 | |
| *** berndhs_950 has joined #mer | 04:01 | |
| *** dl9pf_ has joined #mer | 04:05 | |
| *** dl9pf has quit IRC | 04:05 | |
| *** berndhs has left #mer | 04:06 | |
| *** KaIRC has quit IRC | 04:51 | |
| *** DocScrutinizer has quit IRC | 05:42 | |
| *** DocScrutinizer has joined #mer | 05:42 | |
| *** sebsauer_ has joined #mer | 05:42 | |
| *** disco_stu_droid has joined #mer | 05:53 | |
| *** disco_stu has quit IRC | 05:53 | |
| *** disco_stu_droid is now known as disco_stu | 05:54 | |
| *** beford has quit IRC | 05:55 | |
| *** sebsauer__ has joined #mer | 05:56 | |
| *** sebsauer_ has quit IRC | 05:57 | |
| *** Alison_Chaiken has quit IRC | 05:57 | |
| *** zabomber has quit IRC | 06:05 | |
| *** zabomber has joined #mer | 06:11 | |
| *** sebsauer__ has quit IRC | 06:22 | |
| *** sebsauer__ has joined #mer | 06:25 | |
| *** sebsauer__ has quit IRC | 06:30 | |
| Stskeeps | zz | 06:56 |
| *** kiviluoto_ has joined #mer | 07:30 | |
| *** kiviluoto has quit IRC | 07:31 | |
| *** kiviluoto_ is now known as kiviluoto | 07:31 | |
| dm8tbr | z | 07:48 |
| dm8tbr | riga airport, weather sux | 07:48 |
| Stskeeps | windy? | 07:53 |
| Bostik | more likely rains perpendicular to the ground | 08:00 |
| Stskeeps | Bostik: what was the conflicts of having a dual stack qt4-qt5 btw? besides some things above it having to be built for both? | 08:06 |
| Stskeeps | pkgconfig conflicts is one, i guess, what else? | 08:06 |
| *** rdqfdx has joined #mer | 08:07 | |
| Bostik | Stskeeps: library paths (/usr/lib/libQt*) | 08:11 |
| Bostik | the plugins, modules and imports are in versioned paths, libs are not | 08:11 |
| Stskeeps | okay, but i would hope they have different so versions | 08:11 |
| Stskeeps | like libQtCore.so.5 ? | 08:11 |
| Bostik | okay, that holds true | 08:12 |
| Bostik | just not for -devel :) | 08:12 |
| Stskeeps | yes, of course | 08:12 |
| Stskeeps | that's another side of the story :) | 08:12 |
| Stskeeps | just wondering if we can make mer a dual stack, so people on top can decide which one to use | 08:12 |
| Bostik | then there's the issue of qmake, which would probably need to follow debian's route (qmake-qt4, symlink) | 08:13 |
| Bostik | ah, the tools require the same | 08:14 |
| Bostik | binaries, naked .so symlinks, pkgconfig files | 08:16 |
| *** npm_ has joined #mer | 08:16 | |
| Stskeeps | :nod: | 08:16 |
| Stskeeps | but this is mostly for building not so much runtime | 08:17 |
| *** npm has quit IRC | 08:17 | |
| Bostik | oh for that it already works | 08:18 |
| Stskeeps | my aim is basically that people can start making qt5 based stuff while rest of stack doesn't break :) | 08:19 |
| Stskeeps | perhaps with a pkgconfig(QtCore) >= 5.0 ish kind of thing | 08:19 |
| Bostik | I feel a deluge of bug reports coming in :) | 08:20 |
| Bostik | "pkgconfig files missing/broken/faulty/empty/..." | 08:22 |
| Stskeeps | yeah.. | 08:23 |
| Stskeeps | they should work(TM) | 08:23 |
| Bostik | for most parts they don't | 08:24 |
| Bostik | I put patches in to create them properly but that's it | 08:24 |
| Stskeeps | :nod: | 08:24 |
| Stskeeps | that's an upstream bug isn't it? | 08:26 |
| Bostik | yep | 08:26 |
| *** l32606 has joined #mer | 08:41 | |
| *** M4rtinK has joined #mer | 08:46 | |
| *** marquiz_ has joined #mer | 09:12 | |
| *** vivijim has joined #mer | 09:13 | |
| *** jvd_ has quit IRC | 09:23 | |
| *** NIN101 has joined #mer | 09:27 | |
| *** mingwandroid has joined #mer | 09:36 | |
| *** M4rtinK has quit IRC | 09:38 | |
| *** jvd_ has joined #mer | 09:41 | |
| *** phaeron has joined #mer | 09:46 | |
| *** Venemo_N950 has joined #mer | 09:55 | |
| *** phaeron has quit IRC | 09:55 | |
| *** phaeron has joined #mer | 10:01 | |
| *** Venemo_N950 has quit IRC | 10:02 | |
| *** andre__ has quit IRC | 10:19 | |
| *** mdavey has joined #mer | 10:30 | |
| *** bergie has quit IRC | 10:42 | |
| *** buser has joined #mer | 11:00 | |
| *** chokzi has joined #mer | 11:04 | |
| *** phaeron has quit IRC | 11:07 | |
| mingwandroid | Stskeeps: Morning/afternoon. | 11:08 |
| *** chokzi has left #mer | 11:09 | |
| Stskeeps | morn | 11:09 |
| mingwandroid | trying out ICS on my t2 tab. | 11:10 |
| mingwandroid | there's been some kernel work done that I need to get working for Mer for the vega. | 11:11 |
| mingwandroid | this thing is booting slower than mer PA. | 11:12 |
| *** mdavey has quit IRC | 11:14 | |
| Stskeeps | that's depressing | 11:24 |
| mingwandroid | think I needed to reflash it or it's broke somehow. plus first boots are the worst boots. | 11:25 |
| *** lynxis has quit IRC | 11:27 | |
| mingwandroid | it booted! cool. | 11:27 |
| *** npm_ has quit IRC | 11:29 | |
| mingwandroid | not bad, smooth. | 11:33 |
| mingwandroid | so I've got some kernel work to do on mer for vega.. | 11:33 |
| Stskeeps | :nod: | 11:38 |
| Stskeeps | i'm fixing up last package atm, poppler-qt (not TC related) | 11:38 |
| *** NIN101 has quit IRC | 11:45 | |
| *** mdavey has joined #mer | 11:45 | |
| *** NIN101 has joined #mer | 11:45 | |
| *** sebsauer__ has joined #mer | 11:54 | |
| *** Venemo_N950 has joined #mer | 11:54 | |
| *** mdavey has quit IRC | 11:59 | |
| *** arcean has joined #mer | 12:05 | |
| *** mdavey has joined #mer | 12:06 | |
| mingwandroid | Getting unresolvables: | 12:11 |
| mingwandroid | linux-firmware newt-devel u-boot-tools | 12:11 |
| mingwandroid | I don't need u-boot-tools, though getting uboot to work would be a good idea. | 12:12 |
| *** sebsauer has joined #mer | 12:18 | |
| *** sebsauer__ has quit IRC | 12:19 | |
| Stskeeps | u-boot-tools are usable for making uimage | 12:23 |
| Stskeeps | have you seen sage's new kernel packaging? | 12:23 |
| mingwandroid | no, got a link. I think I've not setup some dependencies right. | 12:26 |
| Stskeeps | https://build.pub.meego.com/package/files?package=kernel-adaptation-pandaboard&project=CE%3AAdaptation%3APandaBoard | 12:27 |
| *** Eismann has quit IRC | 12:30 | |
| *** Eismann has joined #mer | 12:31 | |
| mingwandroid | ok great. I'll investigate. | 12:36 |
| mingwandroid | google say they'll release tegra-2 ICS kernel sources very soon. | 12:36 |
| *** raignarok has joined #mer | 12:36 | |
| mingwandroid | ofc with lots of android crap in there :-( | 12:36 |
| Stskeeps | what kernel version are they on these days anywa?? | 12:37 |
| Stskeeps | anyway | 12:37 |
| mingwandroid | 2.6.39 AFAIK | 12:37 |
| Stskeeps | ok | 12:37 |
| Stskeeps | so not that bad anymore | 12:37 |
| mingwandroid | we're currently 2.6.38-3 or something like that with the vega | 12:37 |
| mingwandroid | there's a script in ICS AOSP to download nv drivers, wonder if modifying the url a bit would lead to hardfp versions ;-) | 12:39 |
| Stskeeps | hehe | 12:39 |
| Stskeeps | ICS isn't hardfp is it? | 12:39 |
| mingwandroid | naah. should be, but would break all apps | 12:40 |
| Stskeeps | well, all using native code, yeah | 12:40 |
| mingwandroid | when they initially started supporting armv7a they should've used that as a chance to move to hardfp | 12:40 |
| *** tomeff1 has quit IRC | 12:40 | |
| *** berndhs has joined #mer | 12:40 | |
| mingwandroid | and forced devs to supply binaries for both arm6 soft and armv7a hard. | 12:40 |
| mingwandroid | app devs I mean. | 12:41 |
| Stskeeps | yeah.. | 12:41 |
| Stskeeps | one idea that's been brewing around the place is something alike the LLVM based native client stuff | 12:41 |
| Stskeeps | portable NaCl one | 12:42 |
| mingwandroid | yeah, LLVM's gained so much momentum lately. | 12:42 |
| mingwandroid | an NaCl looks great. We should definitely get chromium browser building on Mer. | 12:42 |
| Stskeeps | i'm intentionally not promising binary compatibility in mer on app side because i think this is an area we really need to look into | 12:42 |
| Stskeeps | for Qt side, i had a thought .. just like shader programs are supported and practically compiled on the spot, embedded in QML | 12:43 |
| Stskeeps | and executed on GPU | 12:43 |
| Stskeeps | why couldn't you put CPU program there too, built with LLVM on the fly :) | 12:43 |
| mingwandroid | I read some discussions on LLVM dev list that they didn't think using their IR (bitcode is it?) for cross-platform was a great idea... | 12:44 |
| mingwandroid | lemme dig it out. | 12:44 |
| mingwandroid | http://www.phoronix.com/scan.php?page=news_item&px=OTk2Nw | 12:44 |
| Stskeeps | i don't think so either, so i was pondering actually to include code, like we include code for shaders | 12:44 |
| mingwandroid | Dan argues that the intermediate representation for this Apple-sponsored compiler infrastructure is "a poor system for building a Platform." | 12:44 |
| Stskeeps | :nod: | 12:45 |
| *** zenvoid has joined #mer | 12:45 | |
| Stskeeps | 'lo zenvoid :) | 12:45 |
| mingwandroid | do you mean actual C/C++ source code compiled on the client by LLVM? | 12:45 |
| Stskeeps | yes | 12:45 |
| zenvoid | hello Stskeeps | 12:45 |
| Stskeeps | i mean, it's socially acceptable to build shaders | 12:45 |
| mingwandroid | shaders have very few deps | 12:45 |
| mingwandroid | makes it sort of easy | 12:45 |
| Stskeeps | yeah, sure | 12:46 |
| mingwandroid | no automatic dynamic loading etc | 12:46 |
| mingwandroid | I had wanted to go down the IR route with a project until I read that stuff. | 12:46 |
| *** M4rtinK has joined #mer | 12:46 | |
| Stskeeps | zenvoid: how are things? mer's coming along nicely, for armv6 too :) | 12:46 |
| *** l32606 has left #mer | 12:47 | |
| *** l32606 has joined #mer | 12:47 | |
| *** sebsauer has quit IRC | 12:47 | |
| *** marquiz_ has quit IRC | 12:48 | |
| zenvoid | well... I'm trying to find a phone to buy now, can't use the openmoko anymore | 12:50 |
| Stskeeps | n900's quite hackable | 12:50 |
| *** phaeron has joined #mer | 12:50 | |
| Stskeeps | n9 too, for that matter | 12:50 |
| *** phaeron has quit IRC | 12:51 | |
| zenvoid | I would prefer the n900 actually, even with the smaller screen but... | 12:51 |
| zenvoid | not easy to buy one new | 12:51 |
| zenvoid | nowadays | 12:51 |
| *** Venemo_N950 has quit IRC | 12:51 | |
| Stskeeps | yeah | 12:52 |
| zenvoid | do you know if those problems with the usb port are real? | 12:52 |
| Stskeeps | yes they are | 12:52 |
| zenvoid | ouch | 12:52 |
| Stskeeps | i've killed one myself | 12:52 |
| Stskeeps | though it was due to a jackass stepping over my cord | 12:52 |
| zenvoid | hahaha | 12:53 |
| zenvoid | well, getting one used and without warranty could be a problem then | 12:53 |
| Stskeeps | yeah | 12:53 |
| Stskeeps | n9 situation: you can hack the device fairly easily, flash own kernel, but with a "no warranty" notice.. kernel is 2.6.32 and we don't have redistributable rights for NFC and gps | 12:54 |
| *** tomeff has joined #mer | 12:54 | |
| zenvoid | I'm outdated and lost about the latest developments of maemo/meego/tizen/mer/whatever, trying to read a bit now | 12:54 |
| Stskeeps | tizen = nothing public | 12:55 |
| Stskeeps | at least :P | 12:55 |
| *** tomeff has left #mer | 12:55 | |
| Stskeeps | Nemo mobile (based on Mer), http://www.youtube.com/watch?v=dGrvs7TbVBs&feature=BFa&list=UUt3jrWgutwPvS79NfGs9MQQ&lf=plcp | 12:56 |
| Stskeeps | zenvoid: btw, didn't you use to use SB2 back in old Mer days? | 12:57 |
| zenvoid | the n9 is nice but I like hw keyboard and don't like amoled... I think if nokia just shell the n950 is the one that I'll buy | 12:58 |
| zenvoid | I'm looking at chinese clones and some android phones too, like samsumg's optimous q2 | 12:58 |
| zenvoid | Stskeeps: yes, I used sb2 but it has some bugs, then I coded custom software in C | 13:00 |
| Stskeeps | :nod: | 13:00 |
| Stskeeps | we're moving to using SB2 within OBS now, i've made a very nice prototype with it | 13:00 |
| Stskeeps | as a new cross compilation approach | 13:00 |
| *** ashok has joined #mer | 13:01 | |
| zenvoid | ah, a few hints may interest you, learning during my experiments: | 13:01 |
| ashok | can any1 help to install maemo5 on n800 | 13:02 |
| Stskeeps | ashok: sorry, not possible | 13:02 |
| *** l32606 has quit IRC | 13:02 | |
| zenvoid | Stskeeps: my custom software was working ok, for static binaries I coded a very simple detection test and run them under complete emulation | 13:02 |
| *** ashok has quit IRC | 13:03 | |
| Stskeeps | ok | 13:03 |
| zenvoid | but there were complicated cases that scaped the fake chroot | 13:03 |
| zenvoid | very difficult to detect | 13:03 |
| Stskeeps | yeah, i've spoken a bit with the author on the pitfalls | 13:03 |
| *** mdavey has quit IRC | 13:03 | |
| zenvoid | ok | 13:04 |
| Termana | zenvoid, GTA04 on the cards perhaps? | 13:04 |
| zenvoid | Stskeeps: for example I've found that the realpath binary sometimes failed, and it turns out that gcc/glibc optimization code inlines a call to the realpath syscall | 13:05 |
| zenvoid | then I've found many other cases | 13:05 |
| Stskeeps | zenvoid: interesting | 13:05 |
| zenvoid | yeah, it took days of debugging xD | 13:05 |
| zenvoid | if the syscall is inlined, ld preload does not work :( | 13:06 |
| Stskeeps | yeah, i guess in that case you could perhaps add a pragma to glibc not to inline it | 13:07 |
| zenvoid | Termana: yeah, its a posibility, I just would prefer to change the openmoko case and screen too :) | 13:07 |
| *** l32606 has joined #mer | 13:08 | |
| zenvoid | Stskeeps: probably yes, compiling with -O0 worked too | 13:08 |
| Stskeeps | zenvoid: other things i'm brewing on is an extension of the SB2 work, where we basically split Mer into Toolchain and Core, effectively that we bootstrap glibc, gcc and such from x86 side into target and our target no longer needs to be self-hosting | 13:09 |
| zenvoid | but I just taken the motherboard of my touchbook and used it for native compilations instead | 13:09 |
| Stskeeps | :nod: | 13:09 |
| *** l32606 has quit IRC | 13:13 | |
| *** marquiz_ has joined #mer | 13:13 | |
| marquiz_ | afternoon | 13:13 |
| Stskeeps | afternoon marquiz_ | 13:13 |
| marquiz_ | on my way to tampere, this time :) | 13:14 |
| marquiz_ | in a bus, of course | 13:14 |
| Stskeeps | hehe, you certainly get around in finland :) | 13:14 |
| Stskeeps | but i guess choirs are quite active in december season | 13:14 |
| marquiz_ | i thought this would be good time to ver bump mce and dsme | 13:14 |
| marquiz_ | yep | 13:14 |
| * Stskeeps glances at ikea chairs to assemble vs software to assemble.. | 13:16 | |
| marquiz_ | i recommend physical excercise :) | 13:17 |
| marquiz_ | although ikea chairs might prove to be lot more complex that software | 13:18 |
| *** HazardousWaster has joined #mer | 13:24 | |
| dm8tbr | and they sometimes miss dependencies | 13:28 |
| mingwandroid | always | 13:30 |
| *** tomeff has joined #mer | 13:30 | |
| *** Venemo_N950 has joined #mer | 13:34 | |
| zenvoid | Stskeeps: your comment about ikea led me to think about "ikea phones", and it turns out that they exist :D | 13:34 |
| zenvoid | http://www.engadget.com/2009/05/21/flow-is-like-the-ikea-bookshelf-of-android-phones/ | 13:34 |
| Stskeeps | hehe | 13:37 |
| *** arc_mat|tp has joined #mer | 13:40 | |
| *** Venemo_N950 has quit IRC | 13:42 | |
| *** KaIRC has joined #mer | 13:44 | |
| *** Venemo_N950 has joined #mer | 13:51 | |
| Stskeeps | ah, ikea chairs gone, now for some python.. | 13:56 |
| marquiz_ | sounds like good activity for saturday evening :)# | 13:57 |
| Stskeeps | yeah.. going to some birthday party in 2 hours or so, so trying to squeeze in some code before that | 13:57 |
| marquiz_ | rebasing mce patches | 13:58 |
| marquiz_ | argh, not a single patch rebases cleanly | 13:58 |
| Stskeeps | i'm afraid to ever touch pulseaudio again :P | 13:59 |
| marquiz_ | ah, i have birthday today!!! | 13:59 |
| Stskeeps | oh congratualtions :) | 14:00 |
| marquiz_ | thx! | 14:00 |
| Stskeeps | er, congratulations :) | 14:00 |
| *** mdavey has joined #mer | 14:01 | |
| *** Venemo_N950 has quit IRC | 14:01 | |
| *** tomeff has quit IRC | 14:03 | |
| marquiz_ | i guess i gotta grab a beer later today :) | 14:03 |
| *** mdavey has quit IRC | 14:06 | |
| *** kiviluoto has quit IRC | 14:15 | |
| *** kiviluoto has joined #mer | 14:16 | |
| Stskeeps | lbt_away: ping | 14:28 |
| *** alien_ has quit IRC | 14:40 | |
| *** alien_ has joined #mer | 14:45 | |
| *** andre__ has joined #mer | 14:45 | |
| *** javier has left #mer | 14:47 | |
| * marquiz_ is arriving in tampere | 14:56 | |
| marquiz_ | mce patches rebased, nice timing :) | 14:57 |
| Stskeeps | :) | 14:57 |
| marquiz_ | doesn't build, though :( | 15:02 |
| marquiz_ | have to fix that tomorrow or so | 15:02 |
| *** lbt_away is now known as lbt | 15:07 | |
| lbt | Stskeeps: pong | 15:07 |
| marquiz_ | bye | 15:15 |
| *** marquiz_ has left #mer | 15:15 | |
| Stskeeps | lbt: so, i'm a vendor and i am maintaining a mer fork for product purposes.. how do i rebase from one core release branch to another? | 15:16 |
| Stskeeps | based on our idea of branching off one release branch per weekly release | 15:17 |
| Stskeeps | i mean, there's commits in the stabilization branch that likely doesn't exist in the linear progression from the branch point | 15:18 |
| lbt | yep - that's the kind of "day in the life of" item I want to do | 15:18 |
| Stskeeps | i'm coding a bit on MDS and it doesn't clean to have a seperate file indicating what branch is the current prerelease branch | 15:19 |
| Stskeeps | +seem | 15:19 |
| Stskeeps | so i'm pondering how to encode that information the best | 15:19 |
| * lbt presses reset button in brain | 15:20 | |
| lbt | OK - so commits in stabilisation ... not our problem | 15:21 |
| lbt | clarify | 15:21 |
| lbt | commits in Mer release stabilisation | 15:21 |
| lbt | we do another release from linear + some stable patches in a weeks time | 15:22 |
| lbt | vendor needs to rebase | 15:22 |
| lbt | that may not be clean | 15:22 |
| *** tomeff has joined #mer | 15:22 | |
| lbt | and they only rebase *their* patches | 15:22 |
| lbt | agree? | 15:23 |
| Stskeeps | right, linearly we push commits (read: core changes) into 'master', once a week we branch off, apply changes to the branch until it's releasable according to a number of criteria, do same next week | 15:24 |
| lbt | yes | 15:24 |
| Stskeeps | 1) how do we indicate best what's the current prerelease branch | 15:25 |
| Stskeeps | (sorry for that tangent) | 15:25 |
| Stskeeps | ok, forget i ever asked that question :) | 15:25 |
| lbt | yeah | 15:25 |
| Stskeeps | isn't it too rough on the vendor to do having to do a rebase? is there any way we can make it easier to jump from release to release? | 15:26 |
| lbt | lets think of the cases | 15:27 |
| lbt | 1. vendor has own package ... | 15:27 |
| lbt | 2. vendor has a patch not accepted (yet) | 15:27 |
| Stskeeps | the thing is that the vendor is indeed not seeing the changes from week A to week A+1 in a linear manner | 15:27 |
| lbt | 3. vendor has a patch that won't get in | 15:28 |
| lbt | yeah, but why are they even modifying Mer? | 15:28 |
| Stskeeps | right | 15:28 |
| Stskeeps | why? because they have to for various technical reasons :) | 15:28 |
| lbt | 1,2,3 above | 15:28 |
| Stskeeps | but yes, those are the three cases | 15:29 |
| lbt | so, only 3 has patches they have to carry and re-apply | 15:29 |
| lbt | 2 should vanish | 15:29 |
| Stskeeps | the idea was to provide vendors a linear stream of core updates, wasn't it? | 15:29 |
| lbt | I think master is a linear stream ... and if they have no patches then yes | 15:30 |
| lbt | if they have patches then that's not really possible | 15:30 |
| lbt | they have to rebase | 15:30 |
| Stskeeps | ok, if we imagine they apply their patches on master, then they can easily rebase on a release branch | 15:30 |
| lbt | consider 2 vendors applying the same semi-trivial patch | 15:30 |
| lbt | yes | 15:31 |
| Stskeeps | that makes more sense, i guess | 15:31 |
| lbt | and we hope that release branches will have minimal deltas from master | 15:31 |
| lbt | typically I expect any fixes will go straight to master too | 15:32 |
| lbt | unless someone jumps in with an API change minutes post-fork | 15:32 |
| Stskeeps | that makes sense | 15:33 |
| * Stskeeps adds a postit for vendor advice | 15:33 | |
| lbt | so the normal case is linear | 15:33 |
| lbt | "day in the life" | 15:33 |
| Stskeeps | "apply and follow on master but rebase on release branches" | 15:33 |
| lbt | yes | 15:33 |
| Stskeeps | ok | 15:34 |
| lbt | as we get to more major releases we expect longer branches | 15:34 |
| Stskeeps | yes | 15:34 |
| lbt | I also think this becomes a whole lot easier when we use pristine tar | 15:34 |
| lbt | and have a 'proper'-ish git tree | 15:35 |
| Stskeeps | i'm pondering to drop tarballs and simply have a distfiles dir instead, preferred to in the git | 15:35 |
| arc_mat|tp | its pretty inconvenient to rebase your own work on upstream updates, if you don't intend to contribute them back | 15:35 |
| lbt | arc_mat|tp: what's the alternative? | 15:35 |
| arc_mat|tp | difficult to say... | 15:35 |
| Stskeeps | arc_mat|tp: well, best thing we can do is to make it easier | 15:36 |
| lbt | yeah - that point is actually the cost of OSS+proprietary | 15:36 |
| lbt | "patch weight" | 15:36 |
| lbt | it's what Samsung are about to learn :D | 15:36 |
| arc_mat|tp | from own experience, with e.g. linux kernel, we have a lot of patches that will never make it upstream because they are hacks | 15:36 |
| lbt | Nokia learnt it - hence MeeGo (I think) | 15:36 |
| lbt | arc_mat|tp: exactly ... so the cost is rebase vs cleanup | 15:37 |
| lbt | and that must be calculated over the product lifetime | 15:37 |
| Stskeeps | arc_mat|tp: yeah, so we have to make it easy to follow and merge our local changes | 15:37 |
| arc_mat|tp | indeed | 15:37 |
| Stskeeps | your local changes, that is | 15:37 |
| Stskeeps | lbt: ok, so, from a git POV, how do i best indicate what's the current prerelease branch? or even latest release | 15:38 |
| arc_mat|tp | Stskeeps: what we usually do is either git merge upstream and then rebase on our internal branch, or cherry pick a range of patches from upstream, fixing conflicts as we go along | 15:38 |
| Stskeeps | arc_mat|tp: yeah | 15:38 |
| Stskeeps | arc_mat|tp: that's what we want to enable with mer, both on package and core level | 15:38 |
| lbt | arc_mat|tp: we're proposing the inverse | 15:38 |
| Stskeeps | we are? | 15:39 |
| lbt | I think so | 15:39 |
| arc_mat|tp | rebasing our internal branches for upstream "maintenance" updates is impossible | 15:39 |
| lbt | we suggest vendors cherry-pick/re-apply their patches to new upstream | 15:39 |
| lbt | fixing conflicts as they go | 15:39 |
| arc_mat|tp | we'd have to lock the whole repo for hours to avoid loss of work | 15:40 |
| arc_mat|tp | lbt: that's maximum inconvenience | 15:40 |
| lbt | which package? | 15:40 |
| arc_mat|tp | lbt: I'm not talking about a specific package, or even mer | 15:41 |
| lbt | but this is typically HA space issue? | 15:41 |
| arc_mat|tp | what is HA space? | 15:41 |
| lbt | hardware adaptation | 15:41 |
| Stskeeps | i think what arc_mat|tp is trying to say is that in his experience with linux kernel, even rebasing internal branches for upstream maintaining updates is difficult? | 15:42 |
| arc_mat|tp | not really | 15:42 |
| Stskeeps | maintenance, that is | 15:42 |
| *** raignarok has quit IRC | 15:42 | |
| lbt | Stskeeps: kernel is different - and not in Mer | 15:42 |
| arc_mat|tp | my experience is mainly with android | 15:42 |
| Stskeeps | lbt: right, i know, but in principle a similar issue | 15:42 |
| arc_mat|tp | Stskeeps: +1 | 15:42 |
| lbt | agreed - but kernel really is different | 15:42 |
| lbt | what arc_mat|tp is talking about is taking over internal maintenance of a package | 15:43 |
| lbt | isn't it? | 15:43 |
| arc_mat|tp | yes | 15:43 |
| lbt | so to a large degree that's what Mer is supposed to avoid | 15:44 |
| lbt | so it's not a primary use-case | 15:44 |
| lbt | however | 15:44 |
| lbt | mer doesn't preclude it | 15:44 |
| arc_mat|tp | lbt: I think its mainly a matter of bandwidth | 15:44 |
| lbt | whose? Mer or vendor? | 15:45 |
| arc_mat|tp | lbt: what we would do is to pick a stable release, and productize it. | 15:45 |
| arc_mat|tp | lbt: vendor | 15:45 |
| lbt | OK - and that's fine | 15:45 |
| lbt | but we're back to the "co-operative" nature of Mer | 15:45 |
| Stskeeps | lbt: we should really set up a list of vendor use cases.. | 15:45 |
| lbt | productisation happens in the open | 15:45 |
| lbt | for the non-differentiation packages | 15:46 |
| arc_mat|tp | lbt: it depends on what a "stable" release is, and how many there are within one of our product development cycles | 15:46 |
| lbt | and we need to minimise overhead | 15:46 |
| lbt | *nod* | 15:46 |
| lbt | currently we're talking about weekly iteration | 15:46 |
| lbt | Stskeeps: agreed | 15:46 |
| arc_mat|tp | lbt: and if course if there is a market driven necessity to closely follow "stable" releases for marketing reasons | 15:46 |
| arc_mat|tp | lbt: like for android | 15:46 |
| arc_mat|tp | lbt: it's close to impossible to sell a device with an "old" version of android | 15:47 |
| lbt | yep - and Mer is about being able to influence what's in stable | 15:47 |
| lbt | you don't have to contribute | 15:47 |
| lbt | but then your patch weight goes up | 15:47 |
| lbt | but the cost of contribution is not zero | 15:47 |
| lbt | balance | 15:48 |
| lbt | I think the initial focus of this chat was how to minimise cost of contribution | 15:48 |
| lbt | I agree we'd like to support carrying patches forward | 15:48 |
| lbt | I think the split to HA and MWare is good | 15:48 |
| lbt | the MW is less likely to have closed patches | 15:49 |
| lbt | and HA is down to the vendor with 'stable' apis | 15:49 |
| lbt | I have toyed with describing Mer as "from the kernel .config to Qt" | 15:49 |
| arc_mat|tp | HA comes to play at the start of each new product generation, when new hardware is designed. It's a critical step, because you want a full system up as soon as possible for hardware verification | 15:49 |
| lbt | yep - and we should be clear about what we need there - particularly things like DRI/udev etc | 15:50 |
| arc_mat|tp | but it's mostly manual labor. not really easy to carry on patches that you made for the previous product generation | 15:51 |
| arc_mat|tp | for example, our kernel is usually "thrown away" each year. | 15:51 |
| lbt | yep | 15:51 |
| arc_mat|tp | and we start to productize from whatever version is feasible at a certain point in time | 15:52 |
| lbt | at the kernel level I'm not surprised | 15:52 |
| arc_mat|tp | by that point our last product kernel and upstream have diverged so much that we cannot reasonably rebase our patches | 15:52 |
| lbt | upstream = android ? | 15:53 |
| Stskeeps | think that's covers for normal linux products too | 15:53 |
| lbt | so you *can* apply that model to Mer ... and there's not a lot we can do to help | 15:53 |
| arc_mat|tp | upstream for the kernel is rarely "android", as in AOSP, for example, but whatever the system (chip) vendor chose to deliver | 15:53 |
| lbt | OK | 15:54 |
| arc_mat|tp | but for all other packages, yes, in my case it's android | 15:54 |
| lbt | (at least I can't trivially see anything we can do) | 15:54 |
| arc_mat|tp | yeah | 15:54 |
| arc_mat|tp | it is of course most convenient for us to have a linear history from release to release | 15:54 |
| lbt | the alternative is to spread the ongoing deltas (especially in non-kernel areas) | 15:55 |
| lbt | that makes each change *relatively* easy to make - but if you're not using that then why would you? | 15:55 |
| lbt | arc_mat|tp: linear? | 15:55 |
| lbt | hmm | 15:56 |
| lbt | the problem there is that it can't be generalised | 15:56 |
| arc_mat|tp | without having to dive into branches | 15:56 |
| lbt | lets say we release 1.1 and you use it | 15:56 |
| lbt | we *could* rebase master of Mer to 1.1 and then your upgrade would be linear | 15:56 |
| lbt | now we release 1.1.1 | 15:57 |
| lbt | sorry | 15:57 |
| lbt | we release 1.2 | 15:57 |
| lbt | then we release 1.1.1 | 15:58 |
| lbt | which do we rebase master onto ... either way, vendors using 1.2 or 1.1.1 can't have a linear upgrade path | 15:58 |
| arc_mat|tp | that depends on if there is a necessity to move to 1.2, for whatever reason | 15:58 |
| lbt | exactly | 15:59 |
| lbt | so if you don't then we'd have to rebase 1.2 onto 1.1.1 | 15:59 |
| lbt | which doesn't make sense | 15:59 |
| arc_mat|tp | yes | 15:59 |
| arc_mat|tp | its mainly a question of roadmap, and policy | 15:59 |
| lbt | *nod* | 16:00 |
| arc_mat|tp | it depends on how fast you want/need to follow your own upstreams | 16:01 |
| Stskeeps | our situation might also be different in terms of that we're not dealing with one huge source tree to patch for a product, but instead a core will have patches against it (not for hardware) and a bunch of packages outside it by vendor compiled into it | 16:01 |
| lbt | yes - that non-hardware part is crucial | 16:01 |
| Stskeeps | which means it's just the "Core" programme in the company is not terribly intensive | 16:01 |
| arc_mat|tp | I think maintenance is not really a critical issue (unless things are really screwed up), what matter is how easily you can move from one "major" release to another | 16:03 |
| arc_mat|tp | that is what gives us most headaches, for example when moving from honeycomb to ics on android | 16:03 |
| *** raignarok has joined #mer | 16:03 | |
| lbt | yeah - and we're hoping that most of that will be in the Qt space | 16:04 |
| Stskeeps | if you don't mind me asking, are you OHA participants or not? | 16:04 |
| Stskeeps | ie, able to see the tree before release | 16:05 |
| arc_mat|tp | not even OHA participants are able to see that | 16:05 |
| Stskeeps | ok, so android's more closed than i thought | 16:05 |
| arc_mat|tp | there is a circle of a few chosen vendors that are doing the "GED", the Google Experience Devices, and only one of them is chosen each year | 16:06 |
| arc_mat|tp | or, for each new version | 16:06 |
| arc_mat|tp | Stskeeps: indeed | 16:06 |
| arc_mat|tp | Stskeeps: there is AOSP of course, but the updates you get to see are only "maintenance", not upcoming new major releases | 16:07 |
| arc_mat|tp | Stskeeps: and even as OHA members you're not involved in the development. | 16:07 |
| arc_mat|tp | Stskeeps: contribution is limited to bugfixes, if they are interesting for a broader audience | 16:08 |
| arc_mat|tp | because there a are quite a number of areas that google chooses to "neglect", i.e. they barely work ;) | 16:08 |
| arc_mat|tp | mtp for example | 16:09 |
| arc_mat|tp | but that's fine, really. you would not contribute your differentiators anyway | 16:10 |
| lbt | arc_mat|tp: I think we must remember that *that* is what Mer is about | 16:10 |
| *** vakkov has joined #mer | 16:10 | |
| lbt | We're expecting differentiatores to sit above Mer | 16:10 |
| arc_mat|tp | which is a totally legit assumption. | 16:10 |
| *** meng has joined #mer | 16:11 | |
| meng | hello | 16:11 |
| lbt | hey meng | 16:11 |
| meng | hey , mer project? | 16:12 |
| lbt | arc_mat|tp: we do think that some things may move from differentiated to shared | 16:12 |
| lbt | meng: we are indeed :) | 16:12 |
| meng | Looking forward to it | 16:12 |
| lbt | meng: what's your interest? | 16:12 |
| meng | do you guys know about XMS had release for N9? | 16:12 |
| meng | my interest? programming, but I don't think i could help in develop Mer project | 16:12 |
| arc_mat|tp | I think the decision about which version to productize on would be driven from stuff above Mer anyway. But not entirely. sometimes you need core stuff to get all aspects of your hardware running... | 16:12 |
| meng | I'm still learning vb.net code.. | 16:12 |
| lbt | meng: hehe | 16:13 |
| Stskeeps | meng: everybody started somewhere :) | 16:13 |
| meng | thanks | 16:13 |
| meng | btw, | 16:13 |
| meng | this is the first time i use IRC | 16:13 |
| Stskeeps | you seem better at it than most people we see | 16:13 |
| lbt | meng: try Qt/QML then - you should be able to handle both | 16:13 |
| lbt | arc_mat|tp: yes - and I think Qt and HTML5 apis would be in the shared areas | 16:14 |
| meng | hey sts, thanks. | 16:14 |
| meng | QT and QML? | 16:14 |
| Stskeeps | meng: are you able to see youtube videos? | 16:14 |
| meng | yes. | 16:14 |
| Stskeeps | meng: http://www.youtube.com/watch?v=Fr5FuGhTqm8&feature=results_main&playnext=1&list=PL084A46CE1D502DB3 - it's basically a language to create exciting user interfaces | 16:15 |
| Stskeeps | meng: quite easy to write, my wife can do it :) | 16:15 |
| Stskeeps | you can even prototype in photoshop and export to QML | 16:15 |
| meng | alright, thanks for your information. | 16:16 |
| meng | just found out something special in google | 16:16 |
| meng | search let it snow at google. | 16:16 |
| Stskeeps | hehe :) | 16:16 |
| meng | Stskeeps, owner of n900? | 16:17 |
| Stskeeps | meng: yeah, i have two | 16:17 |
| meng | Wow, that's great. I've only one. | 16:17 |
| Stskeeps | lbt: anyway, since i'm implementing mds.. how do you propose we figure out what's most recent prerelease branch? date wise maybe? | 16:17 |
| Stskeeps | meng: nokia 770, n800, n810, n900, n950 but no n9 yet ;) | 16:17 |
| Stskeeps | lbt: prelease_week40 kind of thing | 16:17 |
| meng | O_O | 16:18 |
| meng | awesome. | 16:18 |
| meng | well, i lost the oppurtunity. | 16:18 |
| meng | i started to learn programming in 2011, | 16:18 |
| meng | i can't develop for n900, can't get N950. | 16:18 |
| Stskeeps | there'll be more devices, hopefully | 16:19 |
| Stskeeps | i develop for mer in a virtualbox VM | 16:19 |
| Stskeeps | as well | 16:19 |
| Stskeeps | can run mer on old pc hardware as well :) | 16:20 |
| lbt | Stskeeps: "most recent" ? | 16:20 |
| meng | need an intel proc isn't it ? | 16:20 |
| Stskeeps | lbt: yes, latest | 16:20 |
| Stskeeps | meng: nop, we have i486 port which should work on non-Atom too | 16:20 |
| meng | even AMD? | 16:21 |
| Stskeeps | yes | 16:21 |
| meng | that's great. | 16:21 |
| lbt | symbolic branch name ? | 16:21 |
| Stskeeps | what on earth is that? | 16:21 |
| lbt | a branch that we randomly make point to the most recent | 16:21 |
| lbt | forced push | 16:22 |
| Stskeeps | ok, that's a git feature? | 16:22 |
| lbt | abuse? | 16:22 |
| lbt | but have a branch called "latest-pr" | 16:22 |
| lbt | it may share HEAD with week-23 | 16:22 |
| lbt | and then next week it shares HEAD with week-24 | 16:22 |
| lbt | but always latest | 16:23 |
| Stskeeps | yeah, okay | 16:23 |
| Stskeeps | that could work | 16:23 |
| Stskeeps | there's git symbolic-ref too? | 16:24 |
| meng | hey I've a question but not related to mer project :S | 16:26 |
| Stskeeps | just ask, don't ask to ask :) | 16:26 |
| meng | is it hard to port a QT apps from N9 to N900? | 16:27 |
| Stskeeps | it depends on what APIs yu use | 16:27 |
| Stskeeps | we have Nemo Mobile which is for N900 which is closer to N9 architecture | 16:27 |
| lbt | Stskeeps: that may be even better | 16:27 |
| vakkov | http://www.youtube.com/watch?v=6HtzwswaN-k | 16:27 |
| vakkov | :) | 16:28 |
| meng | vakkov, thanks for the link, i saw that just now. | 16:28 |
| meng | Nemo use deb extension too? | 16:28 |
| *** tomeff has quit IRC | 16:28 | |
| Stskeeps | no, we use rpm | 16:28 |
| meng | same as meego CE? | 16:28 |
| Stskeeps | yeah, Nemo is meego CE continued on top of Mer | 16:29 |
| *** tomeff has joined #mer | 16:29 | |
| meng | then how do we install deb file on Nemo? since n9 is deb, nemo is rpm | 16:30 |
| meng | and what can i do to contribute this project? | 16:31 |
| lbt | bbiab | 16:32 |
| meng | I'm not that good as you guys but I'm willing to spend my free time to learn. | 16:32 |
| *** tomeff has quit IRC | 16:34 | |
| *** tomeff has joined #mer | 16:34 | |
| Stskeeps | meng: it's just packaging, so the binaries are inside | 16:34 |
| meng | okay, thanks for your information . | 16:35 |
| Stskeeps | and extractable with simple commands :) | 16:35 |
| meng | alright. :D | 16:35 |
| meng | so when is the next release? | 16:36 |
| Stskeeps | mer releases each week | 16:36 |
| Stskeeps | we try to incrementally improve it | 16:36 |
| meng | Did nemo become smoother? compare to 1.2.9 CE | 16:36 |
| Stskeeps | yes it did, we already gained quite a lot with the rebase to meego 1.3 | 16:37 |
| Stskeeps | and mer is much lower memory footprint | 16:37 |
| wmarone | Stskeeps: have you used the %pre section in a kickstart to manipulate files before? | 16:37 |
| Stskeeps | wmarone: i haven't used %pre, i usually just use %post | 16:37 |
| wmarone | ok | 16:37 |
| Stskeeps | i didn't even know there was a %pre :) | 16:37 |
| wmarone | yeah, I need to use %pre to generate the image, unless there's a flag for "part" that allows me to specify the starting offset of a partition | 16:38 |
| *** mdavey has joined #mer | 16:38 | |
| *** lynxis has joined #mer | 16:39 | |
| Stskeeps | i wonder, since we would have to need same thing as pandaboard i would assume | 16:39 |
| Stskeeps | / beagleboard | 16:39 |
| wmarone | yeah | 16:39 |
| Stskeeps | sage would know but i think he's having a proper weekend for once :) | 16:39 |
| wmarone | always good | 16:39 |
| wmarone | the only open question is how the filename for the image is handled within the .ks | 16:40 |
| Stskeeps | :nod: | 16:46 |
| Stskeeps | bbl | 16:46 |
| meng | one more question !! :D hows the battery consumption when n900 connect to 3g or wifi? | 16:46 |
| *** mdavey has quit IRC | 16:46 | |
| meng | will it drain battery like nitdroid online? | 16:46 |
| *** trumee_ has joined #mer | 16:48 | |
| *** trumee has quit IRC | 16:50 | |
| *** trumee_ is now known as trumee | 16:50 | |
| meng | hm.. | 16:52 |
| meng | aynone there? | 16:52 |
| meng | i still remember that, 1.2.9 CE has a bug in conversation. unable to scroll down to read the latest message when you have too many message from same user.. | 16:52 |
| meng | is the problem still exist? | 16:53 |
| *** trumee_ has joined #mer | 16:55 | |
| *** trumee has quit IRC | 16:56 | |
| *** trumee_ is now known as trumee | 16:56 | |
| *** mdavey has joined #mer | 16:59 | |
| meng | testing one two three.. | 17:02 |
| *** Ans5i has quit IRC | 17:06 | |
| meng | Hello | 17:12 |
| *** meng has quit IRC | 17:14 | |
| *** SharkCrew has joined #mer | 17:14 | |
| *** tomeff has quit IRC | 17:14 | |
| *** lynxis has quit IRC | 17:35 | |
| *** gabrbedd has joined #mer | 17:47 | |
| *** raignarok has quit IRC | 17:52 | |
| *** slx is now known as swerden | 17:54 | |
| *** toscalix has joined #mer | 18:07 | |
| *** kiviluoto has quit IRC | 18:07 | |
| *** kiviluoto has joined #mer | 18:07 | |
| *** mingwandroid has quit IRC | 18:10 | |
| *** mingwandroid has joined #mer | 18:10 | |
| *** Anssi138 has joined #mer | 18:17 | |
| SharkCrew | Hello | 18:26 |
| *** raignarok has joined #mer | 18:35 | |
| *** SharkCrew has quit IRC | 18:42 | |
| *** berndhs has left #mer | 18:42 | |
| *** ALoGeNo has joined #mer | 18:49 | |
| *** ALoGeNo has joined #mer | 18:49 | |
| *** phaeron has joined #mer | 18:51 | |
| *** berndhs_950 has quit IRC | 18:53 | |
| *** kiviluoto has quit IRC | 19:00 | |
| *** berndhs_950 has joined #mer | 19:04 | |
| *** kiviluoto has joined #mer | 19:10 | |
| *** berndhs has joined #mer | 19:10 | |
| *** araujo has quit IRC | 19:10 | |
| *** vakko has joined #mer | 19:13 | |
| *** vakkov has quit IRC | 19:13 | |
| *** vakko is now known as vakkov | 19:13 | |
| *** araujo has joined #mer | 19:24 | |
| *** araujo has quit IRC | 19:26 | |
| *** raignarok has quit IRC | 19:28 | |
| *** raignarok has joined #mer | 19:28 | |
| *** araujo has joined #mer | 19:39 | |
| *** alexxy has joined #mer | 19:46 | |
| *** berndhs_950 has quit IRC | 19:47 | |
| *** ALoGeNo has quit IRC | 19:48 | |
| *** berndhs_950 has joined #mer | 19:48 | |
| *** berndhs has quit IRC | 19:49 | |
| *** Sage has quit IRC | 19:50 | |
| *** vivijim has joined #mer | 20:00 | |
| *** toscalix has quit IRC | 20:00 | |
| *** Sage has joined #mer | 20:01 | |
| *** ALoGeNo has joined #mer | 20:07 | |
| *** ALoGeNo has joined #mer | 20:07 | |
| *** gabrbedd has quit IRC | 20:07 | |
| *** lynxis has joined #mer | 20:09 | |
| Anssi138 | IOError: [Errno 2] No such file or directory: '/usr/local/bin/mic' | 20:10 |
| *** berndhs_950 has quit IRC | 20:12 | |
| *** Wong has joined #mer | 20:13 | |
| Wong | Hello | 20:13 |
| Wong | Hello | 20:13 |
| Wong | anyone there? | 20:13 |
| Anssi138 | maybe | 20:14 |
| Wong | just now | 20:15 |
| Wong | i downloaded the image of mer project | 20:16 |
| Wong | i use GnuWin32 to decompress it | 20:16 |
| Wong | and now the image gone | 20:16 |
| Wong | i tried twice. | 20:16 |
| Wong | image missing in action and hard disk space gone | 20:16 |
| Wong | any idea? | 20:17 |
| Wong | hmm... | 20:19 |
| Wong | anyone there? | 20:19 |
| *** ALoGeNo has quit IRC | 20:20 | |
| *** Wong has quit IRC | 20:21 | |
| *** Nicholas has joined #mer | 20:25 | |
| Nicholas | Helllo | 20:25 |
| Nicholas | anyone there? | 20:25 |
| *** Nicholas is now known as Guest72016 | 20:25 | |
| _av500_ | </crickets> | 20:25 |
| Guest72016 | hi. | 20:25 |
| arc_mat|tp | damn, a deja vu. they're changing the matrix! out!! | 20:26 |
| Guest72016 | hi | 20:28 |
| Anssi138 | ho | 20:29 |
| Anssi138 | i am trying to build mer with http://wiki.merproject.org/wiki/Trying_it_out. the mic-creator fails due missing /usr/local/bin/mic, i wonder if the bootstrap is ok | 20:31 |
| *** Guest72016 has quit IRC | 20:33 | |
| *** berndhs has joined #mer | 20:43 | |
| Stskeeps | Anssi138: missing /usr/local/bin/mic? mic2 or mic? | 20:50 |
| *** slx has joined #mer | 20:58 | |
| Anssi138 | $ which mic | 20:59 |
| Anssi138 | /usr/bin/mic | 20:59 |
| Stskeeps | hmm | 21:01 |
| Stskeeps | show me full log? | 21:01 |
| *** swerden has quit IRC | 21:02 | |
| *** niqt has joined #mer | 21:12 | |
| Anssi138 | http://pastebin.com/zsGNTgK0 | 21:16 |
| Stskeeps | yeah, that's a missing bootstrap.. hang on | 21:17 |
| Stskeeps | Anssi138: mic-create-bootstrap -n trunk -k /var/cache/mic -r http://repo.meego.com/MeeGo/builds/trunk/latest/repos/oss/ia32/packages/ -o /var/cache/meego-bootstrap | 21:18 |
| Stskeeps | and get rid of the --mainrepo stuff | 21:18 |
| Anssi138 | http://wiki.merproject.org/wiki/Trying_it_out < should that be updated? | 21:19 |
| Stskeeps | yes, please do | 21:19 |
| Stskeeps | we've started writing proper guides for this | 21:19 |
| *** sandroandrade has joined #mer | 21:20 | |
| *** raignarok has quit IRC | 21:24 | |
| *** raignarok has joined #mer | 21:33 | |
| Anssi138 | doesn't work for me yet. | 21:40 |
| *** niqt_ has joined #mer | 21:42 | |
| *** shanem has quit IRC | 21:43 | |
| *** niqt has quit IRC | 21:44 | |
| *** gabrbedd_ has joined #mer | 21:55 | |
| *** niqt has joined #mer | 21:57 | |
| *** shanem has joined #mer | 21:57 | |
| Anssi138 | *fixed | 21:59 |
| *** niqt_ has quit IRC | 22:00 | |
| *** niqt has quit IRC | 22:07 | |
| *** dijenerate has quit IRC | 22:09 | |
| *** dijenerate has joined #mer | 22:14 | |
| Anssi138 | Stskeeps: there was wrong bin_path in /usr/lib/pymodules/python2.7/mic/utils/bootstrap.py on line 686.changed /usr/local/bin to /usr/bin | 22:17 |
| *** dijenerate has quit IRC | 22:24 | |
| *** dijenerate has joined #mer | 22:25 | |
| *** ALoGeNo has joined #mer | 22:28 | |
| *** ALoGeNo has joined #mer | 22:28 | |
| *** dijenerate has quit IRC | 22:32 | |
| Anssi138 | actually it was line on 699 | 22:35 |
| *** dijenerate has joined #mer | 22:35 | |
| *** shanem has quit IRC | 22:37 | |
| *** shanem has joined #mer | 22:39 | |
| Anssi138 | Stskeeps: http://wiki.merproject.org/wiki/Talk:Trying_it_out | 22:46 |
| *** vivijim has quit IRC | 22:48 | |
| *** jonnor_work has joined #mer | 22:55 | |
| *** lynxis has quit IRC | 22:57 | |
| *** Venemo has joined #mer | 23:00 | |
| *** Venemo has quit IRC | 23:00 | |
| *** Venemo has joined #mer | 23:00 | |
| *** lynxis has joined #mer | 23:05 | |
| *** ali1234 has quit IRC | 23:09 | |
| *** ali1234 has joined #mer | 23:10 | |
| *** ali1234 has quit IRC | 23:16 | |
| *** zenvoid has quit IRC | 23:19 | |
| *** ali1234 has joined #mer | 23:28 | |
| *** raignarok_ has joined #mer | 23:35 | |
| *** raignarok has quit IRC | 23:36 | |
| *** raignarok_ is now known as raignarok | 23:36 | |
| *** rantom has quit IRC | 23:47 | |
| *** rantom has joined #mer | 23:47 | |
| *** NIN101 has quit IRC | 23:52 | |
| *** berndhs_950 has joined #mer | 23:56 | |
| *** raignarok has quit IRC | 23:58 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!