00:04.42 | *** join/#oe dijenerate (n=dijenera@69.73.223.106) |
00:10.22 | *** join/#oe alex_l (n=alex_l@nat/cisco/x-a6148e7e03317eef) |
00:10.40 | *** join/#oe dijenerate (n=dijenera@69.73.223.106) |
00:33.55 | *** join/#oe wrobbie (n=rob@203.117.215.163) |
00:45.09 | *** join/#oe dijenerate (n=dijenera@69.73.223.106) |
00:50.53 | josch | hah! |
00:51.09 | josch | Marcel_M and i got further concerning the _bsddb module in python |
00:51.28 | josch | have a look at this excerp from the compile log: |
00:51.30 | josch | http://phpfi.com/341175 |
00:52.23 | josch | this happend on building python |
00:52.30 | josch | and obviosly shouldnt happen |
00:52.37 | josch | does anyone have a quick fix? |
00:52.45 | josch | or is this worth a bugreport? |
00:53.27 | *** join/#oe aloril (n=aloril@dsl-tkubrasgw1-fe25fa00-28.dhcp.inet.fi) |
00:54.48 | josch | ah i forgot... |
00:54.55 | josch | oe.org is still down... |
00:54.56 | josch | :/ |
00:55.04 | josch | so any ideas? :D |
01:06.29 | *** join/#oe osas (n=nnnnnnnn@nslu2-linux/osas) |
01:33.53 | *** join/#oe BenLauDC (n=benlau@221.125.8.105) |
01:36.37 | *** join/#oe dijenerate (n=dijenera@69.73.223.106) |
01:42.24 | *** join/#oe HellDragon (n=jd@Wikipedia/HellDragon) |
01:42.52 | *** join/#oe eno__ (n=eno@adsl-70-137-146-183.dsl.snfc21.sbcglobal.net) |
02:07.40 | *** join/#oe rsalveti (n=salveti@189.70.143.203) |
02:15.09 | *** join/#oe crweb (n=tom@12-210-83-225.client.mchsi.com) |
02:20.38 | *** join/#oe davygravy (n=davygrav@h69-128-156-59.mdtnwi.dsl.dynamic.tds.net) |
02:21.57 | *** join/#oe crweb (n=tom@12-210-83-225.client.mchsi.com) |
02:32.12 | digital-ex | Hello everyone |
02:32.34 | *** join/#oe chouimat|away (n=dieu@kde/developer/chouinard) |
02:32.57 | digital-ex | Does anyone have experience with OE on the Sequoia? |
02:33.48 | *** join/#oe jtaji (n=jtaji@unaffiliated/astro76) |
02:35.37 | *** join/#oe xjqian (n=gordon@68-188-71-196.dhcp.stls.mo.charter.com) |
03:05.34 | *** join/#oe bin1010 (n=aars@rrcs-24-227-199-231.sw.biz.rr.com) |
03:20.25 | *** join/#oe dcordes_ (n=dcordes@unaffiliated/dcordes) |
03:34.23 | *** join/#oe eno (n=eno@nslu2-linux/eno) |
03:39.53 | *** join/#oe allyourrejects (n=tom@12-210-83-225.client.mchsi.com) |
04:20.27 | *** join/#oe johncylee (n=john@firewall.tw.openmoko.org) |
05:13.16 | *** join/#oe wick7xx (n=wicknix@74.213.217.246) |
05:14.12 | *** join/#oe bazbell (n=a0192809@nat/ti/x-c0e00dd620e766fd) |
05:37.25 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
05:39.17 | *** join/#oe bin10101 (n=aars@rrcs-24-227-199-231.sw.biz.rr.com) |
06:00.19 | *** join/#oe alex_l (n=alex_l@nat/cisco/x-5937c96c0600ec94) |
06:01.35 | *** join/#oe hvontres|home (n=hvontres@adsl-75-18-119-132.dsl.sndg02.sbcglobal.net) |
06:07.05 | *** join/#oe wozza (n=Wozza@nat-dz2-1.aster.pl) |
06:19.20 | *** join/#oe xjqian (n=gordon@68-184-200-222.dhcp.stls.mo.charter.com) |
06:28.09 | *** join/#oe mbuf (n=shakthim@61.16.248.242) |
06:39.23 | *** join/#oe methril (n=Methril@213.27.233.98) |
06:39.40 | methril | morning |
06:47.20 | *** join/#oe wozza_ (n=Wozza@nat-dz2-1.aster.pl) |
06:49.10 | *** join/#oe trickie|work (n=trickie@basesoft.xs4all.nl) |
06:56.17 | *** join/#oe kwek (n=kwek@188.Red-213-97-48.staticIP.rima-tde.net) |
07:04.38 | *** join/#oe lafille (n=lafille@212-198-248-33.rev.numericable.fr) |
07:07.02 | *** join/#oe pvanhoof (n=pvanhoof@d54C0C0BA.access.telenet.be) |
07:07.20 | *** join/#oe cyberdeck (n=molter@iss60.vlsi.informatik.tu-darmstadt.de) |
07:13.18 | *** join/#oe zoolooc (n=lucian@nrbg-4dbfc65c.pool.einsundeins.de) |
07:23.14 | *** join/#oe smancke (n=smancke@gate.tarent.de) |
07:24.43 | josch|nsn | well since openembedded.org is still down i hop you dont mind if i ask here: who is maintaining python in oe? |
07:24.57 | josch|nsn | mickeyl perhaps? |
07:39.21 | *** join/#oe darkschneider (n=gab@213-140-15-160.fastres.net) |
07:39.32 | *** join/#oe rschuster (n=rob@e178068082.adsl.alicedsl.de) |
07:40.59 | *** join/#oe BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
07:41.17 | stefan_schmidt | josch|nsn: yes |
07:41.50 | hrw | morning |
07:42.06 | josch|nsn | stefan_schmidt: thx - then i will message him if he gets back :) |
07:42.21 | josch|nsn | s/if/when/ :P |
07:42.29 | stefan_schmidt | heh |
07:42.33 | stefan_schmidt | morning hrw |
07:47.00 | *** join/#oe lrg (n=liam@79-68-78-64.dynamic.dsl.as9105.com) |
07:54.37 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
07:58.57 | *** join/#oe jekhor_ (n=jek@mm-166-254-57-86.leased.line.mgts.by) |
08:05.44 | *** join/#oe Genesis (n=Ronan@AMontsouris-153-1-20-171.w86-212.abo.wanadoo.fr) |
08:07.17 | Genesis | bonjour |
08:15.46 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
08:19.27 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
08:23.05 | *** join/#oe Marajin (n=marajin@87-194-102-189.bethere.co.uk) |
08:23.25 | Marajin | So er... trying to bitbake kdepimpi actually produces the error: "requires the runtime entity 'kdepimpi' but it wasn't found in any PACKAGE or RPROVIDES variable" |
08:23.28 | Marajin | clues? |
08:27.19 | *** join/#oe Sleep_Walker (n=Sleep@gprs8.vodafone.cz) |
08:29.58 | hrw | kdepimpi? no idea |
08:30.19 | *** join/#oe MarcOChapeau (n=mbarre@bgn92-4-82-238-213-101.fbx.proxad.net) |
08:33.26 | Marajin | I find it boggleable that a package depends on itself and can't find itself somehow |
08:41.43 | Marajin | Oh |
08:41.56 | Marajin | oh do I make it compile libqpe-opie with qte-mt ? |
08:42.07 | Marajin | it keeps trying to -lqte instead of -lqte-mt |
08:42.23 | Marajin | I have PALMTOP_USE_MULTITHREADED_QT="yes" |
08:54.19 | *** join/#oe pleemans (n=peter@host130-161-static.37-88-b.business.telecomitalia.it) |
09:01.18 | *** join/#oe ribbits (n=bob@host86-154-243-88.range86-154.btcentralplus.com) |
09:09.42 | *** join/#oe buri (n=swisscom@26-95.104-92.cust.bluewin.ch) |
09:10.22 | *** join/#oe lrg (n=liam@79-68-78-64.dynamic.dsl.as9105.com) |
09:16.15 | buri | hello, I try to build an openmoko toolchain for a i686 system using bitbake on a x86_64 machine - tried to edit openembedded/conf/bitbake.conf setting HOST_ARCH = "i686" but I guess I got a bit confused with TARGET and HOST.... |
09:19.11 | buri | well, I see openembedded/classes/sdk.bbclass:HOST_ARCH = "${BUILD_ARCH}" - therefore I think HOST_ARCH would be the right variable to change... what would be the right value? |
09:19.54 | buri | anybody here who did that before? |
09:20.17 | *** part/#oe Marajin (n=marajin@87-194-102-189.bethere.co.uk) |
09:26.02 | *** part/#oe xjqian (n=gordon@68-184-200-222.dhcp.stls.mo.charter.com) |
09:26.45 | pb__ | buri: what exactly are you trying to accomplish? |
09:26.49 | *** join/#oe hillct (n=hillct@cpe-024-211-242-232.nc.res.rr.com) |
09:27.10 | pb__ | do I understand correctly that you are trying to build i686 binaries on your x86-64 host? if so, TARGET_ARCH is the variable you want to set. |
09:28.06 | pb__ | if you mean that you are trying to do a canadian cross sdk, I don't think this is something that oe supports very well (or maybe at all). It might be possible to make it work but I suspect you are on your own. :-} |
09:28.33 | *** join/#oe Sleep-Walker (n=Sleep@gprs6.vodafone.cz) |
09:35.53 | *** join/#oe florian_ (n=fuchs@217.146.132.69) |
09:37.49 | pb__ | florian_: good morning |
09:39.41 | florian_ | good morning |
09:43.33 | *** join/#oe thebohemian (n=rschus@p579E1B4F.dip.t-dialin.net) |
09:44.57 | *** join/#oe ao2 (n=u@2001:1418:117:0:0:0:0:1) |
09:45.16 | *** part/#oe ao2 (n=u@2001:1418:117:0:0:0:0:1) |
09:51.36 | *** join/#oe DarthWader (n=sith@gw.vniro.ru) |
10:05.21 | buri | pb__: I try to build an openmoko toolchain (gcc etc.) on a x86-64 system that should run on a i686 system and produce binaries for the openmoko (arm) |
10:05.28 | *** join/#oe Sleep-Walker (n=Sleep@gprs9.vodafone.cz) |
10:10.00 | buri | pb__: I think TARGET_ARCH should still be ARM, as the sdk.bbclass takes for HOST_x all the settings from BUILD_x |
10:10.20 | thebohemian | buri: I think you will get into trouble with this |
10:10.41 | pb__ | buri: right, that's a canadian cross. I don't think it will work with sdk.bbclass out of the box. |
10:10.54 | thebohemian | buri: while you can override BUILD_x variables you certainly won't fool the autotools |
10:12.30 | thebohemian | buri: because the way the things are now they will call your system's uname and whatnot to find out on what it is running on |
10:13.04 | thebohemian | buri: as pb__ said canadian cross (compilation) is not handled right now. |
10:13.15 | thebohemian | buri: contributions in this way are very much welcome! :) |
10:15.26 | buri | thebohemian: canadian cross? never heard of that - I tried to overwrite the HOST_ARCH variable and I get an error: NOTE: Handling BitBake files: \ (0755/5722) [13 %]ERROR: Information not available for target 'i386-linux-gnueabi' |
10:17.05 | *** join/#oe xjqian (n=gordon@68-184-200-222.dhcp.stls.mo.charter.com) |
10:17.09 | thebohemian | buri: http://en.wikipedia.org/wiki/Cross_compile#Canadian_Cross |
10:18.05 | thebohemian | buri: compilation is for beginners, cross-compilation is for adepts, canadian cross-compilation is for the elite ;) |
10:19.21 | thebohemian | buri: AFAIK the autotools are the only build system that can deal with it by design |
10:19.32 | buri | thebohemian: I guess your right... and I think I'm not the elite type of embedded developer |
10:20.21 | buri | thebohemian: ... and it probably takes a genius to even but all that into bitbake.... |
10:20.47 | thebohemian | buri: it boils down to pass the right options to the configure scripts |
10:21.01 | thebohemian | buri: the autotools manuals describe this scenario |
10:25.17 | buri | thebohemian: I'll have a look at it. But to get bitbake to pass the right things on to autotools beats me. I'm not that familiar with the bb-files and classes... In general I feel rather lost with all the variables around... |
10:28.44 | buri | thebohemian: but thanks for the input. At least I know now what's it called what I'm trying to do. I will first get everything built and tested on the i686 directly before I attempt to leverage our cluster powered by x86_86 cores. |
10:30.47 | *** join/#oe mwester_ (n=mwester@adsl-75-49-209-164.dsl.emhril.sbcglobal.net) |
10:31.50 | *** join/#oe thebohemia1 (n=rschus@p579E18CD.dip.t-dialin.net) |
10:37.08 | thebohemia1 | florian: I got answer from the district court regarding OE e.V. I have to send money and we need to fix a few minor issues in our statutes |
10:37.34 | thebohemia1 | florian: I will write a mail about this after work (or tomorrow) |
10:38.30 | florian | thebohemia1: ah cool |
10:38.47 | florian | thebohemia1: okay, so lets do this :) |
10:58.37 | Crofton|work | thebohemia1, thanks |
11:05.11 | *** join/#oe jekhor_ (n=jek@cpmsq.epam.com) |
11:05.43 | Crofton|work | what is up with amethyst? |
11:06.32 | udovdh | anyone awake here? |
11:06.52 | udovdh | I have one small question about serial_cs on h2200 |
11:06.59 | florian | Crofton|work: mickeyl said somethign about network problems at the hosting location. |
11:07.17 | udovdh | I built a kernel with serial_cs and dependent modules (Koen gave me a patch to defconfig) |
11:07.21 | udovdh | but I get: |
11:07.32 | udovdh | <4>[ 253.950000] serial_cs: Unknown symbol serial8250_unregister_port |
11:07.33 | udovdh | <4>[ 253.950000] serial_cs: Unknown symbol serial8250_resume_port |
11:07.33 | udovdh | etc |
11:07.40 | udovdh | modprobe 8250 says device busy |
11:08.26 | florian | He promised to call there today... |
11:09.06 | florian | That's why I prefer renting servers :) |
11:09.45 | ynezz | and it's even cheaper :) |
11:11.47 | Crofton|work | we should send in the oe mafia |
11:23.42 | *** join/#oe tcooksey (n=tcooksey@nat/trolltech/x-22b9f904b5f43505) |
11:50.06 | Genesis | does any project other that openembedded & consors use bitbake ? |
11:56.25 | thebohemia1 | Genesis: I don't think so |
11:57.00 | thebohemia1 | Genesis: however its used by openmoko, mamona and poky ;) |
11:58.25 | Genesis | so all the tasks are for building distro/packages/... |
11:59.17 | *** join/#oe Sleep_Walker (n=Sleep@gprs9.vodafone.cz) |
11:59.19 | Genesis | bitbake is supposed to be a generic task manager , we don't associate bbclass in it because it's distro specific , i'm okay but i was wondering if it's really a good idea |
11:59.52 | Genesis | we could have bbclass by catégory in the bitbake tree |
12:00.30 | *** join/#oe Laibsch (n=Laibsch@ip-62-143-12-162.hsi.ish.de) |
12:01.04 | *** join/#oe mickeyl (n=mickey@openmoko/coreteam/mickey) |
12:01.22 | Genesis | i try to make a qemu-launch task but it's a bit different than other tasks i'm wrote |
12:02.45 | *** topic/#oe by mickeyl -> OpenEmbedded Developer Lounge | Web: http://www.openembedded.org | Bugtracker: http://bugs.openembedded.net | Repository: monotone.openembedded.org | This is not a distro or machine support channel | OE.org is down, we work on it. Pull/Push from/to opensource.wolfsonmicro.com in the meantime. |
12:07.38 | josch|nsn | mickeyl: you think the bothering about oe.org being down will stop now? :P |
12:08.00 | mickeyl | i do :D |
12:13.35 | mwester | josch|nsn: :D At least the answers will be shorter! |
12:14.18 | josch|nsn | heh |
12:16.25 | *** join/#oe xjqian (n=gordon@mir-nil-pat-118-150.wustl.edu) |
12:19.57 | pb__ | mickeyl: yo |
12:21.35 | mickeyl | hi pb__ |
12:21.51 | *** join/#oe aloisiojr (n=aloisio@200.184.118.132) |
12:23.26 | Crofton|work | mickeyl, do we need to send the OE mafia in to solve the connectivity issue? |
12:23.44 | Crofton|work | curses the openmoko store not having anything to sell |
12:25.08 | hrw | Crofton|work: you need jtag hardware? |
12:26.20 | *** join/#oe dijenerate (n=dijenera@69.73.223.106) |
12:28.20 | mickeyl | Crofton|work: heh, well, the one with access tries to reach the computing centre guys, but it's friday... |
12:29.44 | Crofton|work | hrw, no I want a freerunner |
12:29.50 | Crofton|work | hmmm |
12:30.05 | Crofton|work | needs to move to a country where you do not work on Friday :) |
12:31.48 | chouimat|away | morning .... |
12:32.18 | chouimat|away | hides his freerunner from Crofton|work sight ;) |
12:32.52 | *** join/#oe thesing (n=tkunze@BAA14f7.baa.pppool.de) |
12:33.15 | thesing | morning all |
12:34.05 | florian | hi thesing |
12:44.56 | hrw | Crofton|work: freerunner... |
13:19.50 | *** join/#oe mranostay_work (n=mranosta@cpe-089228.fiber.wadsnet.net) |
13:19.54 | mranostay_work | hello |
13:20.17 | mranostay_work | i see OE.org is down, any idea for how long? |
13:20.45 | mickeyl | unfortunately not, it's an unscheduled outage |
13:21.01 | *** join/#oe frikker (n=blaine@107.135.68.216.DED-DSL.fuse.net) |
13:21.13 | mickeyl | my guess would be not later than monday |
13:23.36 | mranostay_work | is the monotone server still up? |
13:24.08 | mranostay_work | or is there a mirror? |
13:24.33 | mwester | see topic |
13:26.26 | mranostay_work | ah ok |
13:36.28 | *** join/#oe rkirti (n=Kirtika@203.199.213.3) |
13:38.00 | *** join/#oe dijenerate (n=dijenera@69.73.223.106) |
13:40.57 | *** join/#oe chouimat|work (n=dieu@kde/developer/chouinard) |
13:45.18 | mranostay_work | wow the server must be getting hammered |
13:55.20 | frikker | so i have compiled octave 3.0.0. After installing the 10 libraries, and finally the octave ipkg, I get this when I run it: octave: error while loading shared libraries: liboctinterp.so: cannot open shared object file: No such file or directory |
13:55.38 | frikker | I have done this, which did not help: root@gumstix-custom-verdex:~$ find /* | grep liboctinterp.so |
13:55.38 | frikker | /usr/lib/octave-3.0.0/liboctinterp.so.3.0.0 |
13:55.38 | frikker | root@gumstix-custom-verdex:~$ export LD_LIBRARY_PATH=/usr/lib/octave-3.0/ |
13:55.45 | frikker | any suggestions? |
13:56.05 | frikker | actually that was /usr/lib/octave-3.0.0 (I fixed it).. |
14:00.10 | pb__ | try making a symlink from liboctinterp.so.3.0.0 -> liboctinterp.so |
14:00.35 | pb__ | if that fixes it, you need to look into the octave build to see why the binary is getting mis-linked like that |
14:04.41 | *** join/#oe trickie|work (n=trickie@basesoft.xs4all.nl) |
14:06.14 | *** join/#oe crweb (n=tom@12-210-83-225.client.mchsi.com) |
14:08.15 | *** join/#oe Gnutoo (n=gnutoo@ABordeaux-152-1-15-106.w82-125.abo.wanadoo.fr) |
14:13.26 | *** join/#oe rkirti (n=kirtibr@203.199.213.3) |
14:24.25 | *** join/#oe Sleep_Walker (n=Sleep@gprs1.vodafone.cz) |
14:27.04 | *** join/#oe tharvey (n=tharvey@adsl-76-205-222-173.dsl.snlo01.sbcglobal.net) |
14:27.52 | frikker | pb__: thanks, i'll try that |
14:29.17 | frikker | pb__: where do you think i should put that soft link? |
14:29.27 | frikker | root@gumstix-custom-verdex:/usr/lib/octave-3.0.0$ ls |
14:29.27 | frikker | libcruft.so.3.0.0 liboctave.so.3.0.0 liboctinterp.so.3.0.0 |
14:31.48 | frikker | lol look what i did on accident.... a symbolic link to itself |
14:31.50 | frikker | root@gumstix-custom-verdex:/usr/lib/octave-3.0.0$ ls -la |
14:31.50 | frikker | drwxr-xr-x 2 root root 0 Aug 3 02:34 . |
14:31.50 | frikker | drwxr-xr-x 11 root root 0 Jul 29 15:51 .. |
14:31.50 | frikker | -rwxr-xr-x 1 root root 1690052 Jul 29 15:51 libcruft.so.3.0.0 |
14:31.50 | frikker | -rwxr-xr-x 1 root root 4971956 Jul 29 15:51 liboctave.so.3.0.0 |
14:31.51 | frikker | lrwxrwxrwx 1 root root 14 Aug 3 02:34 liboctinterp.s -> liboctinterp.s |
14:31.53 | frikker | lrwxrwxrwx 1 root root 21 Aug 3 02:34 liboctinterp.so -> liboctinterp.so.3.0.0 |
14:31.55 | frikker | -rwxr-xr-x 1 root root 7022736 Jul 29 15:51 liboctinterp.so.3.0.0 |
14:31.57 | frikker | root@gumstix-custom-verdex:/usr/lib/octave-3.0.0$ cat liboctinterp.s |
14:31.59 | frikker | cat: liboctinterp.s: Too many levels of symbolic links |
14:32.01 | frikker | oops, sorry for the long paste |
14:38.32 | *** join/#oe Sleep-Walker (n=Sleep@gprs2.vodafone.cz) |
14:42.40 | *** join/#oe dijenerate (n=dijenera@69.73.223.106) |
14:43.07 | frikker | if i have a package, like gnuplot, installed on my embedded system - is there an easy way using ipkg to see how much room the package and its dependencies take up? |
14:46.24 | *** join/#oe mickey|shopping (n=mickey@e180143247.adsl.alicedsl.de) |
14:48.09 | pb__ | no, not really. you could make a script to do it but there's no builtin facility. |
14:49.01 | pb__ | obviously there's the complication that you don't want, say, libc6 to get charged against gnuplot even though gnuplot depends on it. you'd need to make the script check for dependencies that aren't depended on by any other package, I guess. |
14:49.24 | *** join/#oe thebohemian (n=rschus@p579E18CD.dip.t-dialin.net) |
14:52.03 | frikker | sure |
14:52.04 | frikker | hmm |
14:54.20 | *** join/#oe vivijim (n=vivijim@unaffiliated/vivijim) |
14:56.06 | *** join/#oe abner (n=birunko@200.184.118.132) |
14:57.26 | frikker | alright, so i have an X server up and running but it loads matchbox, matchbox panel, desktop, etc. |
14:57.35 | frikker | I can't figure out how to decouple matchbox from it |
14:57.47 | frikker | xinit /etc/X11/Xsession -- /usr/bin/Xfbdev :0 -br -pn -screen 480x272@180 |
14:58.04 | frikker | can i just get Xfbdev running and use gtk with that? or do i need matchbox too? |
14:58.19 | frikker | we just have a single app that will be running |
14:58.53 | tharvey | I'm trying to use OE to generate a 'bootstrap' image of a kernel+initramfs, therefore my kernel recipe needs to have the initramfs cpio.gz as a DEPEND, yet if I create an image recipe for my initramfs that inherits task-base it depends on task-boot which depends on kernel - what is suggested? |
14:59.35 | tharvey | I see a 'bootstrap-image' recipe but it depends on MACHINE_TASK_PROVIDER which by default is task-base which depends on kernel |
15:00.14 | pb__ | don't use task-base, I suppose. |
15:00.55 | pb__ | you can roll your own filesystem from raw materials, and in the case of an initramfs that probably is what you want to do. |
15:01.00 | tharvey | ya, I was wondering if that would be the suggestion - but it seems like you would loose a lot of nice features by not using task-base, I'm wondering if task-base should really not be depending on kernel? |
15:01.11 | *** join/#oe rsalveti_ (n=salveti@200.184.118.132) |
15:01.27 | *** join/#oe rsalveti (n=salveti@200.184.118.132) |
15:01.36 | pb__ | what features would you lose? I don't think there's anything magic in task-base: anything it can do, you can do. |
15:02.04 | tharvey | pb__, yes, but I do like the concepts of task-base as I need to do this for several machines that have various hardware support - but I suppose I can recreate those aspects of task-base in my initramfs recipe |
15:02.18 | *** join/#oe MarcOChapeau (n=mbarre@bgn92-4-82-238-213-101.fbx.proxad.net) |
15:02.26 | tharvey | I'm referring to the matchup of MACHINE_FEATURES and DISTRO_FEATURES |
15:03.02 | pb__ | tharvey: hm, right, but presumably you don't want most of that stuff in your initramfs anyway. |
15:04.37 | tharvey | pb__, perhaps not... I just didn't want to deviate from the standard way of doing things if there was a better way that I'm missing |
15:05.06 | pb__ | but, all that aside, I think probably the right answer to your original question is that the kernel image oughtn't to be depending on the initramfs.cpio.gz anyway. |
15:05.32 | pb__ | if you do that, it will be impossible to put any modules into the initramfs, which I suspect will defeat its purpose |
15:06.09 | pb__ | you probably want to have one recipe for the kernel which doesn't depend on anything, another recipe for the initramfs, which can depend on the kernel if it likes, and a third recipe to take the two things and glom them together to make the bootable binary lump. |
15:07.14 | tharvey | yes, I thought about that aspect as well |
15:07.44 | tharvey | currently I'm using initramfs via kernel CONFIG_INITRAMFS_SOURCE so in order to build the kernel the cpio.gz has to exist |
15:08.12 | tharvey | I think I need to change that to use an initrd (which can be a cpio.gz if I wish, or anything else initrd supports) |
15:08.39 | pb__ | ah, I see. well, in that case the third recipe (the one that does the combining) might be a variant of the kernel build. |
15:08.53 | tharvey | I wish to build a sing-file image with the kernel+initrd but as you say I could do that outside of the kernel build process and add another recipe that handles that |
15:09.14 | pb__ | so, in that case, you'd have two separate kernel recipes: one that builds the modules but doesn't include the cpio.gz, and then another one that builds the kernel with the initramfs included. |
15:09.31 | *** part/#oe zoolooc (n=lucian@nrbg-4dbfc65c.pool.einsundeins.de) |
15:09.58 | tharvey | pb__, ah... yes, you mean actually build the kernel first w/o INITRAMFS_SOURCE so that mods etc are built, then have a 3rd recipe that relinks the kernel or something? |
15:11.09 | pb__ | right |
15:11.19 | tharvey | I'm not sure there is really a huge benefit to using internal intramfs vs a cpio.gz initrd - in the 2nd case the kernel utilizes the initramfs code and doesn't really treat it as an initrd other than the fact the kernel got passed a pointer to it vs it being linked to the kernel directly (AFAIK) |
15:11.54 | pb__ | yeah, I don't think there is any significant difference between the two methods. |
15:12.06 | pb__ | if your bootloader knows how to pass an initrd, it is probably just as good to use that mechanism. |
15:13.21 | tharvey | ya, and in some cases such as powerpc's cuImage you can wrap up kernel+initrd with a bootwrapper that does it for you without the help of the bootloader |
15:13.57 | pb__ | right |
15:16.47 | *** join/#oe e-ffi (n=cybercom@dslb-088-068-166-115.pools.arcor-ip.net) |
15:28.10 | *** join/#oe Sleep-Walker (n=Sleep@gprs9.vodafone.cz) |
15:32.34 | *** join/#oe DarthWader (n=sith@vorphalack.msk.ru) |
15:33.05 | *** join/#oe memeruiz__ (n=memeruiz@e176227035.adsl.alicedsl.de) |
15:37.13 | *** join/#oe hvontres|work (n=hvontres@hentges.net) |
15:40.52 | *** join/#oe mranostay_work (n=mranosta@cpe-089228.fiber.wadsnet.net) |
15:40.58 | mranostay_work | ERROR: '['/home/mranostay/easi-oe/projects/rmi_dbau1200/current/openembedded/packages/tasks/task-maemo.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'outo' but it wasn't found in any PACKAGE or RPROVIDES variables |
15:40.58 | mranostay_work | NOTE: Runtime target 'outo' is unbuildable, removing... |
15:40.58 | mranostay_work | Missing or unbuildable dependency chain was: ['outo'] |
15:41.07 | mranostay_work | any clue why that outo is missing from OE? |
15:44.30 | thesing | pb_: I think we should split the build of the kernel into build modules and build kernel. |
15:44.58 | pb__ | why? |
15:47.06 | *** join/#oe mrdata (i=unknown@dslb-088-074-188-116.pools.arcor-ip.net) |
15:47.54 | mrdata | hi all |
15:51.22 | florian | hi mrdata |
15:51.35 | mrdata | ih florian |
15:55.51 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928272.dsl.bell.ca) |
16:16.17 | thesing | pb_: to solve the problem with initramfs with modules included. the initramfs could depend on package_modules and build_kernel on image:do_rootfs. |
16:23.10 | *** join/#oe valhalla (n=valhalla@81-174-37-232.dynamic.ngi.it) |
16:28.57 | pb__ | thesing: true, but that is an uncommon case that is already soluble. it doesn't seem like breaking up the kernel build process for everyone would bring much benefit. |
16:29.13 | *** join/#oe Jay7 (n=jay@89.250.164.201) |
16:30.30 | thesing | pb_: if its done right nobody will notice. And the actual solution (having two recipies) is not very elegant. |
16:32.09 | pb__ | isn't two recipes exactly what you are proposing? |
16:32.19 | pb__ | maybe I don't quite understand your suggestion. can you explain it in more concrete terms? |
16:32.37 | *** join/#oe AlGe (n=alge@chello080109231226.4.uni-klu.teleweb.at) |
16:35.48 | AlGe | hi, |
16:35.49 | AlGe | is there an option for the bb git fetcher to specify a specific git branch to fetch? |
16:37.56 | hvontres|work | thesing: where do you specify the stic device tables for kexecboot? I think I mostly have it working, but I need to set up the mmc card nodes |
16:38.31 | *** join/#oe jekhor_ (n=jek@mm-166-254-57-86.leased.line.mgts.by) |
16:46.11 | thesing | hvontres|work: you need to add device-table-collie.txt to DEVICE_TABLES (or so) |
16:46.19 | *** join/#oe alphaone (n=alphaone@a064.apm.etc.tu-bs.de) |
16:46.25 | thesing | hvontres|work: see collie.conf for an example |
16:48.49 | *** join/#oe steliosk (n=Stelios@athedsl-282534.home.otenet.gr) |
16:55.17 | *** join/#oe lrg (n=liam@79-68-78-64.dynamic.dsl.as9105.com) |
17:02.59 | *** join/#oe stephank (n=urk@2002:52c5:cfc7:1:2c0:9fff:feb7:e03f) |
17:04.03 | *** join/#oe diego (n=diego@host-84-222-23-218.cust-adsl.tiscali.it) |
17:08.31 | dcordes_ | is there some website that informs about the server status |
17:09.48 | hvontres|work | dcordes_: check here for updates.... |
17:10.56 | dcordes_ | ok |
17:16.18 | *** join/#oe likewise (n=likewise@82-171-51-231.ip.telfort.nl) |
17:22.22 | *** join/#oe rschuster (n=rob@e178068082.adsl.alicedsl.de) |
17:25.02 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
17:32.25 | *** join/#oe bin1010 (n=aars@rrcs-24-227-199-231.sw.biz.rr.com) |
17:45.19 | *** part/#oe jdav_gone (n=james@d75-157-13-250.bchsia.telus.net) |
17:51.05 | thesing | bye |
18:00.29 | *** join/#oe alex_l (n=alex_l@nat/cisco/x-d82bacf8758ad893) |
18:04.26 | *** join/#oe davygravy (n=davygrav@h69-128-156-59.mdtnwi.dsl.dynamic.tds.net) |
18:14.32 | *** join/#oe Crofton|Durham (n=ben@wireless-5213.wireless.ece.vt.edu) |
18:22.44 | *** join/#oe HellDragon (n=jd@Wikipedia/HellDragon) |
18:34.39 | *** join/#oe jekhor (n=jek@mm-166-254-57-86.leased.line.mgts.by) |
18:40.17 | *** part/#oe enigmaedge (n=mbailon@209.191.15.3) |
18:42.14 | *** join/#oe rschuster (n=rob@e178068082.adsl.alicedsl.de) |
18:52.01 | *** join/#oe arun (n=arun@unaffiliated/sindian) |
18:57.31 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928272.dsl.bell.ca) |
19:13.50 | *** join/#oe mrdata_ (i=unknown@dslb-088-075-227-011.pools.arcor-ip.net) |
19:19.22 | *** join/#oe timtimred (n=meh@82-34-50-106.cable.ubr02.chel.blueyonder.co.uk) |
19:19.35 | *** join/#oe smancke (n=smancke@ip-62-143-107-19.hsi.ish.de) |
19:23.18 | *** part/#oe Crofton|Durham (n=ben@wireless-5213.wireless.ece.vt.edu) |
19:26.10 | *** join/#oe angom (n=angom@201.170.65.143) |
19:30.27 | *** part/#oe angom (n=angom@201.170.65.143) |
19:35.13 | *** part/#oe wmat (n=btraynor@gromit.mixdown.ca) |
19:36.07 | *** join/#oe lpotter (n=ljp@CPE-124-191-144-181.vic.bigpond.net.au) |
19:40.55 | Crofton | what's the mtn incantation to pull from wolfson? |
19:44.42 | chouimat|work | grrrrrr |
19:52.16 | Crofton | answers his own question by reading his email mtn pull opensource.wolfsonmicro.com org.openembedded.dev |
19:56.39 | *** join/#oe mrdata_ (i=mrdata@dslb-088-074-174-158.pools.arcor-ip.net) |
20:00.56 | chouimat|work | kicks openssl-native for not building |
20:01.46 | *** join/#oe frikker (n=blaine@107.135.68.216.DED-DSL.fuse.net) |
20:02.49 | sakoman | Crofton: do you know what the status is on openembeded.org? seems to have been down for a couple of days now |
20:03.20 | Crofton | not sure |
20:03.21 | Jay7 | $topic |
20:03.26 | Crofton | it is in a data center |
20:03.33 | Crofton | and someone needs to kick it |
20:03.36 | sakoman | source.mvista.com is down also |
20:03.42 | sakoman | it's a conspiracy! |
20:03.43 | Crofton | but, apparently non one works on fridays |
20:03.45 | Crofton | yeah |
20:03.48 | Crofton | bash.org also |
20:03.58 | Crofton | maybe the internet tubes need cleaning |
20:04.04 | sakoman | an all out assault on open source! |
20:05.10 | Crofton|work | yes, really annoying |
20:06.55 | *** join/#oe flo_lap (n=fuchs@g227195090.adsl.alicedsl.de) |
20:08.43 | hvontres|work | Crofton|work: maybe there is a serious bug in the bind fix.... |
20:09.13 | Crofton|work | I've been wondering, although it feels more like rounting headaches |
20:09.38 | hvontres|work | either that or the chineese got a bit carried away trying to lock soen the internet |
20:10.14 | hvontres|work | err down that is |
20:13.36 | mwester | Al Gore took it back. |
20:14.32 | hvontres|work | at least kernel.org still works :) |
20:14.54 | flo_lap | re |
20:18.10 | Crofton|work | crap, builds go really slow when tinderbox is not there to receive results |
20:18.20 | *** join/#oe bluelightning (n=blueligh@pdpc/supporter/active/bluelightning) |
20:21.55 | tharvey | even if I don't add a package manager to an image, the image contains /usr/lib/opkg/* - I believe this is from the image creation step as ipkg is used to create the image - is there something in OE that allows this data to be cleaned out or should I simply add a custom task after do_rootfs to clean it? |
20:35.20 | *** join/#oe hillct (n=hillct@cpe-024-211-242-232.nc.res.rr.com) |
20:40.38 | *** join/#oe ant_ (n=ant@host250-12-dynamic.60-82-r.retail.telecomitalia.it) |
20:41.00 | ant_ | morning |
20:42.26 | Jay7 | ant_: really :) |
20:43.25 | ant_ | hi Jay7 |
20:45.01 | ant_ | sh*t, again a u-boot_git change...basically 4-5 per week... |
20:45.17 | ant_ | even with wolfsonmicro... |
20:45.35 | ant_ | somebody can't resist and update it |
20:46.31 | ant_ | pb__: mercy |
20:47.14 | tharvey | looks like ROOTFS_POSTPROCESS_COMMAND would be good for what I'm looking for |
20:50.02 | tharvey | ROOTFS_POSTPROCESS_COMMAND = "remove_packaging_data_files" - remove_packaging_data_files is defined in rootfs_ipk.bbclass - but its not exported via EXPORT_FUNCTIONS - is EXPORT_FUNCTIONS required to export? |
20:51.51 | ant_ | Jay7: I have update the u-boot patch to the actual r16 and have bumped it to r17 |
20:52.09 | ant_ | now bugzilla is down I'll post it asap |
20:52.26 | ant_ | but are trivial chabge |
20:52.37 | ant_ | you can do by yourself |
20:53.09 | Jay7 | ant_: send me whole package by email |
20:53.18 | Jay7 | or patch only |
20:53.50 | ant_ | ok |
20:54.13 | Jay7 | I'm not sure about my time at weekend but I'll try to test u-boot + kexecboot + .dev :) |
20:54.43 | ant_ | about u-boot, I really hope somebody will commit it and let us work on that foundation... |
20:55.00 | ant_ | kexecboot needs so much test as possible, though |
20:55.06 | Jay7 | I hope too |
20:55.14 | ant_ | because will be heavily employed |
20:55.39 | Jay7 | it's very bad that bugzilla is down.. :\ |
20:55.56 | ant_ | eh |
20:58.23 | ant_ | Jay7: now I'm conmpiling a new kexecboot kernel..if it's too big I'll just install u-boot and gain that few bastard kilobytes |
20:58.34 | ant_ | :-) |
20:58.38 | Jay7 | :) |
20:59.46 | Jay7 | hm.. may be I start up the build of .dev x11-image tonight.. |
21:02.09 | ant_ | I'm sending you the patch |
21:04.21 | ant_ | done |
21:06.14 | tharvey | is anyone familiar with using the various initramfs- images? I'm curious what they are doing with the resulting cpio.gz to get it built into a kernel w/o a chicken-and-egg scenario |
21:08.48 | Jay7 | ant_: got it :) |
21:09.23 | Jay7 | but I'm unsure about how recent is my local u-boot-zaurus package.. |
21:09.55 | ant_ | Jay7: remember you have to set the UBOOT_ENTRYPOINT="0x80008000" and UBOOT_LOADADDRESS="0x80008000" in akita.conf and CUSTOM_ROOTFS_SIZE and KERNEL_IMAGETYPE = "uImage" in local.conf |
21:10.24 | ant_ | or just do it by hand... |
21:10.58 | Jay7 | we really need to push this work to .dev :) |
21:11.20 | ant_ | Jay7: kernel.bbclass is ready |
21:11.23 | Jay7 | it's too easy to forget some of this |
21:12.14 | ant_ | nah, it's only that hack for rootfs-size...the rest should be standard oe for uImage deployment |
21:14.54 | ant_ | (but some lazy developer is not convinced...) |
21:16.48 | *** join/#oe stephank (n=urk@2002:52c5:cfc7:1:2c0:9fff:feb7:e03f) |
21:24.22 | ant_ | Jay7: actually you can just improve akita.conf and set all the new vars there... |
21:24.34 | Jay7 | ant_: what is solution with udev? |
21:24.43 | Jay7 | comment out udevsettle? |
21:24.57 | ant_ | comment udevadm settle in /etc/init.d/udev |
21:25.06 | ant_ | in the last rel |
21:25.19 | ant_ | seems to work |
21:25.34 | ant_ | with kernel 2.6.26 you could even strace udevadm settle |
21:25.43 | ant_ | :-/ |
21:26.23 | ant_ | the delay introduced by strace seems enough to let it work without races |
21:26.43 | ant_ | but why only on Zaurus? must be some linux-rp problem... |
21:27.17 | ant_ | the behaviour is inconsisten between 2.6.24 and 2.6.26 (strace makes it work with latter) |
21:28.50 | ant_ | Jay7: or prefer udev_092 |
21:29.02 | ant_ | or udev_115 from Poky |
21:32.55 | ant_ | hvontres|work: is udev working ok on poodle? |
21:35.54 | Jay7 | hehe.. I have open tab in my opera with udev bug from bugzilla :) |
21:36.14 | Jay7 | 4 days uptime :) |
21:38.03 | ant_ | Jay7: zImage-kexecboot-2.6.26-r2-c7x0.bin ?1303372?Aug 8 23:35 |
21:38.12 | ant_ | uh...too big... ;-] |
21:38.56 | Jay7 | It's showtime :) |
21:39.14 | ant_ | now rootfs_size 96mb... |
21:39.22 | ant_ | just to see |
21:39.49 | ant_ | need a beer...pause |
21:42.05 | *** join/#oe dyqith (n=dyqith@lattice.cs.ucdavis.edu) |
21:42.42 | Jay7 | ant_: I have looking into altlinux bugzilla |
21:43.07 | Jay7 | they have problems with udevsettle in udev 0.96 |
21:43.20 | Jay7 | here is some explanations |
21:45.46 | Jay7 | quick solution applied - is to create file /dev/.udev/uevent_seqnum |
21:45.59 | Jay7 | but I'm not sure that it's same problem |
21:50.38 | Jay7 | ant_: look here when will back: https://bugzilla.altlinux.org/attachment.cgi?id=1583 |
21:55.30 | ant_ | Jay7: I think I already tried that patch... |
21:55.36 | ant_ | IIRC no go |
21:55.58 | ant_ | the only initscript working oob are _115 and the old _092 |
21:56.17 | ant_ | but hrw is working on this issue |
21:56.25 | ant_ | with udev_124 |
21:56.40 | ant_ | http://svn.o-hand.com/view/poky/ |
22:00.40 | Jay7 | ant_: did you try it? |
22:01.50 | ant_ | not yet, now working on kexec-bootmenu |
22:02.25 | ant_ | tried a previous version with the hack from u-dev ml |
22:02.38 | ant_ | the one I posted on bug 4118 |
22:03.02 | Jay7 | ok |
22:03.08 | ant_ | at least you see which devices are left out |
22:03.18 | ant_ | if you don't give enough time |
22:04.04 | ant_ | Jay7: I forgot you have to set UBOOT_MACHINE="akita_config" too |
22:04.15 | Jay7 | hm.. |
22:04.30 | ant_ | at least I have (c7x0 != corgi) |
22:04.45 | Jay7 | ant_: where it should be inserted? |
22:04.52 | Jay7 | local.conf/akita.conf? |
22:04.53 | ant_ | akita.conf |
22:04.56 | Jay7 | ok |
22:05.08 | ant_ | where you like, now I have all in machine.conf |
22:06.57 | *** join/#oe NAiL (i=repvik@nslu2-linux/pdpc.active.NAiL) |
22:07.23 | Jay7 | can you mail me latest u-boot-zaurus too? |
22:07.58 | Jay7 | or it is not needed anymore? |
22:08.07 | ant_ | Jay7: it works ! I have u-boot.bin and u-boot-c7x0-git-r17.bin (the kernel) in my deploy dir |
22:08.13 | ant_ | no, delete it |
22:08.23 | ant_ | it's now merged in u-boot_git.bb |
22:08.37 | ant_ | that's why the frequent updates... |
22:10.20 | ant_ | Jay7: hmmm I have no uImage...sorry... |
22:11.39 | Jay7 | ant_: your diff don't provide patches |
22:12.08 | ant_ | <PROTECTED> |
22:12.19 | ant_ | # patch "packages/u-boot/u-boot_git.bb" |
22:12.20 | ant_ | # from [dd5c9df20b550f8e184483944ba911d7de096d98] |
22:12.20 | ant_ | # to [5b959df4c25d00f0207145c9e111401dae0ee696] |
22:12.39 | ant_ | ah, how are you importing it ? |
22:13.01 | ant_ | just add the couple of lines... |
22:13.21 | Jay7 | file://pdaXrom-u-boot.patch;patch=1 |
22:13.38 | ant_ | ouch...you are right... |
22:13.41 | Jay7 | and next two |
22:13.48 | ant_ | sorry... |
22:13.50 | ant_ | 1 mom |
22:13.53 | Jay7 | np |
22:14.02 | ant_ | (I hate mtn diff) |
22:17.55 | Jay7 | 9.8G tmp/ |
22:18.10 | Jay7 | wow.. |
22:20.01 | ant_ | Jay7: ok, I forgot to 'mtn add' the files after a checkout... |
22:22.08 | ant_ | mail resent |
22:22.21 | Jay7 | 10x :) |
22:23.12 | ant_ | yes, I remember I had to delete org.openembedded.dev because it was fscked and did not recognize anymore the arch (some crazy messages like defaulting to I686...) |
22:23.32 | ant_ | si I did a fresh checkout from wolfsonmicro |
22:24.21 | Jay7 | 2nd try is bigger at least :) |
22:25.02 | ant_ | should be all this time... |
22:27.22 | Jay7 | ehh.. I will to save previous builds against .stable but I have no 10G now.. |
22:28.21 | Jay7 | btw is here some scripts to clean up sources directory? |
22:28.29 | ant_ | do you use INHERIT += "rm_work" in your local.conf ? |
22:28.44 | Jay7 | no I did not |
22:28.48 | ant_ | (like Gentoo) |
22:28.55 | ant_ | try ;-) |
22:28.55 | Jay7 | ah |
22:29.10 | Jay7 | good idea :) |
22:29.38 | ant_ | would be a good idea if you add your builds to oestats |
22:30.09 | Jay7 | howto? :) |
22:30.10 | ant_ | INHERIT += "oestats-client" |
22:30.10 | ant_ | OESTATS_BUILDER = "Jay?" |
22:30.10 | ant_ | OESTATS_SERVER = "tinderbox.openembedded.net" |
22:30.24 | ant_ | but it's down atm... |
22:30.30 | ant_ | he he |
22:30.54 | Jay7 | remind me when it will be back :) |
22:31.03 | ant_ | put it now |
22:31.14 | ant_ | then if you want to add smthg ##ANGSTROM_EXTRA_INSTALL = "mc gpe-bluetooth gpsd speech-dispatcher flite navit" |
22:31.22 | ant_ | or similar |
22:31.31 | ant_ | all above in local.conf |
22:32.15 | *** join/#oe DarthWader (n=sith@vorphalack.msk.ru) |
22:32.35 | ant_ | I'm not sure anybody is testing akita... |
22:34.13 | Jay7 | ok, I've added |
22:34.20 | ant_ | Jay7: if you want to build all the possible dependencies, add BB_DEFAULT_TASK = "buildall" to local.con (similar to emerge -D) |
22:37.40 | Jay7 | is waiting for rm -rf in work/*/* |
22:40.19 | ant_ | Jay7: sorry..right ones are UBOOT_LOADADRESS_akita = "0xa0800000" |
22:40.20 | ant_ | UBOOT_ENTRYPOINT_akita = "0xa0800000" |
22:40.37 | ant_ | and perhaps UBOOT_MACHINE_akita = "akita_config" |
22:41.02 | ant_ | then you have to set somewhere CUSTOM_ROOTFS_SIZE_akita ?= "59392k" |
22:41.25 | ant_ | (default in patched u-boot_git.bb) |
22:41.35 | Jay7 | ok, fixed |
22:41.46 | ant_ | http://projects.linuxtogo.org/pipermail/openembedded-issues/2008-February/007432.html |
22:41.59 | ant_ | google cache is your friend |
22:42.53 | ant_ | nowI have to see why the mkimage step is skipped... |
22:43.26 | ant_ | where, why I can guess :-) |
22:44.59 | *** join/#oe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net) |
22:48.25 | *** join/#oe dcordes (n=dcordes@f049170097.adsl.alicedsl.de) |
22:48.36 | *** join/#oe bin1010 (n=aars@rrcs-24-227-199-231.sw.biz.rr.com) [NETSPLIT VICTIM] |
22:48.36 | *** join/#oe HopsNBarley_ (n=hops@pool-71-116-67-183.snfcca.dsl-w.verizon.net) |
22:48.36 | *** join/#oe borg_ (n=olaf@80.149.17.21) [NETSPLIT VICTIM] |
22:48.36 | *** join/#oe Foolean (n=emil@foolean.ros.sgsnet.se) [NETSPLIT VICTIM] |
22:48.36 | *** join/#oe piroko (n=jeremy@pohl.ececs.uc.edu) [NETSPLIT VICTIM] |
22:48.36 | *** join/#oe slapin_nb (n=slapin@saris-243.ip.PeterStar.net) [NETSPLIT VICTIM] |
22:48.36 | *** join/#oe denix (n=denys@nat/ti/x-292ca2ca61732e6c) [NETSPLIT VICTIM] |
22:48.36 | *** join/#oe mewyn (n=mike@elune.tuxnami.net) [NETSPLIT VICTIM] |
22:49.04 | *** join/#oe hvontres|work (n=hvontres@81.169.178.128) |
22:49.06 | *** join/#oe wick7xx (n=wicknix@74.213.217.246) |
22:49.58 | *** join/#oe rsalveti (n=salveti@200.184.118.132) |
22:52.10 | *** join/#oe ml-something (n=no@c-76-105-18-51.hsd1.ca.comcast.net) |
23:05.01 | Jay7 | ant_: I've started up build of console image |
23:05.20 | Jay7 | now I go sleep :) resume experiments at morning |
23:05.42 | ant_ | good night |
23:05.59 | Jay7 | you too |
23:31.59 | *** join/#oe CIA-24 (n=CIA@208.69.182.149.simpli.biz) |