**** BEGIN LOGGING AT Sat Apr 25 02:59:57 2009 Apr 25 04:42:06 03Angus Ainslie 07fso/milestone5.5 * r92bb1ef815 10openembedded.git/ (4 files in 2 dirs): efl.bbclass : more SONAME catchup Apr 25 07:25:23 gremlin[it]: hi Apr 25 07:30:53 hi mckoan ! Apr 25 07:31:14 mckoan, buon onomastico !!! Apr 25 07:31:29 grazie Apr 25 07:35:37 mckoan: hey, how is your devshell? :) Apr 25 07:36:15 * Cannot find package locale-base-en-us Apr 25 07:36:20 hm.. Apr 25 07:38:59 hehe.. imho, 'sh: rm: command not found' coming from opkg Apr 25 07:41:16 Jay7: what are you referring to? Apr 25 07:42:03 mckoan: about devshell - you had some troubles with terminals afaik :) Apr 25 07:42:21 about locale and rm - it's my current problems Apr 25 07:42:53 (rm is not real problem) Apr 25 07:55:37 03Koen Kooi 07org.openembedded.dev * re5ef487e25 10openembedded.git/recipes/efl1/ (7 files): Apr 25 07:55:37 Revert "efl: sync versions with upstream" Apr 25 07:55:37 This reverts commit 6898f8ca089d35109b3652d640ebb907d8115736. Apr 25 07:55:38 03Koen Kooi 07org.openembedded.dev * r32281c5a33 10openembedded.git/recipes/efl1/ecore.inc: Apr 25 07:55:38 Revert "ecore: catch up with the new SONAMEs; move to autosplitting" Apr 25 07:55:42 This reverts commit 8101ad8e1229b3b9f8aa0be0fdc262b5283034d0. Apr 25 07:55:44 03Koen Kooi 07org.openembedded.dev * rd25011ebad 10openembedded.git/recipes/efl1/ (evas-native_svn.bb evas.inc evas_svn.bb): Apr 25 07:55:47 Revert "evas: catch up with new upstream library names; bump version string" Apr 25 07:55:49 This reverts commit 80c85e0af3865710a189ba536022d326fa996d26. Apr 25 07:55:51 03Koen Kooi 07org.openembedded.dev * r46c34116ec 10openembedded.git/recipes/linux/ (3 files in 3 dirs): linux-omap-pm: readd patch to register all OPPs, fix overo defconfig Apr 25 07:55:54 03Koen Kooi 07org.openembedded.dev * r9b4e61a447 10openembedded.git/recipes/efl1/ (ecore.inc ecore_svn.bb): ecore: fix git merge damage Apr 25 07:55:59 03Koen Kooi 07org.openembedded.dev * r676cd23058 10openembedded.git/recipes/images/distcc-master-image.bb: distcc-master-image: image that servers as distcc master, with GUI Apr 25 07:56:04 03Koen Kooi 07org.openembedded.dev * r4115ea0d26 10openembedded.git/recipes/dsplink/gstreamer-ti_svn.bb: gstreamer-ti: bump SRCREV Apr 25 07:56:07 03Koen Kooi 07org.openembedded.dev * r5795c0b430 10openembedded.git/recipes/u-boot/u-boot_git.bb: u-boot git: update omap3evm Apr 25 07:56:10 03Koen Kooi 07org.openembedded.dev * r0f4089d170 10openembedded.git/recipes/u-boot/ (u-boot-1.2.0/dm355-leopard.diff u-boot_1.2.0.bb): u-boot 1.2.0: adjust dm355-leopard patch, still needs work to compile with eabi Apr 25 07:56:14 03Koen Kooi 07org.openembedded.dev * rd8b6dce76b 10openembedded.git/recipes/libsdl/libsdl-mixer_1.2.8.bb: libsdl-mixer: convert to autotools_stage Apr 25 07:56:19 03Koen Kooi 07org.openembedded.dev * ra4a7d90f3e 10openembedded.git/recipes/webif/webif_svn.bb: Apr 25 07:56:22 webif: add recipe to build the webif binary and package support files Apr 25 07:56:24 * still needs tweaking to work with some OE config files Apr 25 07:58:18 Jay7: uh, ok now I remember Apr 25 07:59:26 seems it was resolved :) Apr 25 08:00:50 Jay7: good what was the problem? xauth? Apr 25 08:01:26 Jay7: no, you say about MY problem, isn't it? Apr 25 08:01:51 * mckoan just woke up... yawn Apr 25 08:01:52 mckoan: I have just draw this conclusion because you are forget about this :) Apr 25 08:02:13 Jay7: yes is is solved, see ML Apr 25 08:04:02 thread "devshell not working with screen remote shell" Apr 25 08:05:43 tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.2.4/include/limits.h:122:61: error: limits.h: No such file or directory Apr 25 08:05:57 * Jay7 got more fun Apr 25 08:29:51 well, cleaning glibc requires rebuild glibc-initial to build glibc again Apr 25 08:35:22 03Andrea Adami 07org.openembedded.dev * rfb4dc83ea6 10openembedded.git/recipes/kexecboot/kexecboot-cfg_0.1.bb: kexecboot-cfg: initial deploy of /boot/boot.cfg (for kexecboot_0.6) Apr 25 11:03:50 which window manager is preferred for a embedded device with a small lcd Apr 25 11:04:33 i am used to matchbox, i think i need a different one for a change Apr 25 16:18:57 hi all Apr 25 16:20:46 hi Apr 25 16:21:19 can you help me Gnutoo Apr 25 16:21:29 i have a little problem Apr 25 16:21:34 cali__, it depend on your problem Apr 25 16:21:42 :D Apr 25 16:21:59 by the way I've a question...I don't know if it's HS...I've a device that has kdrive 1.3...and I'd like to modify the startup scripts to take into account my keyboard how do I do that Apr 25 16:22:38 note that kdrive 1.3 doens't have the -keybd options Apr 25 16:23:03 cali__, could you tell what your problem is so me or other people could help you Apr 25 16:23:17 i am sorry i don't have idea for you problem Apr 25 16:23:56 ok I was asking aroung... Apr 25 16:24:06 s/aroung/around/ Apr 25 16:24:35 my problem it's when i try to make a bitbake -b on a .bb file on the task do_install: started i have on error Apr 25 16:24:48 ok I'll look what bitbake -b is Apr 25 16:25:12 make: *** No rule to make target `install'. Stop. Apr 25 16:25:17 cali__, don't use -b Apr 25 16:25:35 FATAL: oe_runmake failed Apr 25 16:25:40 using -b means that you bypass all the dependencies Apr 25 16:26:01 what package are you bitbaking? Apr 25 16:26:07 i try without -b Apr 25 16:26:24 i create an file.bb Apr 25 16:26:37 for add some file and directories to my project Apr 25 16:27:26 ok Apr 25 16:27:38 the message means that the makefile doesn't contain an install target Apr 25 16:27:43 without -b don't work Apr 25 16:27:58 => it makes : "make install" and there is no install in the Makefile Apr 25 16:28:05 ok Apr 25 16:29:14 so the error are in my .bb file Apr 25 16:30:03 not necessarly Apr 25 16:30:18 have you more details on the Makefile Apr 25 16:30:19 ? Apr 25 16:30:33 wich makefile? Apr 25 16:30:35 what package are you trying to install? Apr 25 16:30:46 ah ok you just want copy some files? Apr 25 16:30:52 yes Apr 25 16:30:56 ah ok Apr 25 16:31:05 add some file and make some directories Apr 25 16:31:14 overrides do_install(){} Apr 25 16:31:29 and do not inherit autotools Apr 25 16:31:45 do_install_append() {} not good? Apr 25 16:32:07 In that case I don't think it's good Apr 25 16:32:15 append appends Apr 25 16:32:30 I'll verify the syntax I just told you Apr 25 16:32:41 but could you pastebin your recipe? Apr 25 16:32:43 ok so just do_install(){} Apr 25 16:33:59 yes Apr 25 16:34:11 and inside you can use cp or install command Apr 25 16:37:39 thx now it's ok Apr 25 16:39:43 :) Apr 25 16:42:36 03Khem Raj 07org.openembedded.dev * raa12d953b9 10openembedded.git/recipes/gcc/ (154 files in 5 dirs): Apr 25 16:42:36 gcc-4.4.0: Add recipes for latest gcc release 4.4.0 Apr 25 16:42:36 * This is a preliminary port. Now all patches has been ported yet. Apr 25 16:44:45 ouch...did someone read mickey's blog? Apr 25 17:05:51 NOTE: Not creating empty archive for TodoDream-common-dbg-1.0-r0 Apr 25 17:06:15 *** Error: Package name contains illegal characters, (other than [a-z0-9.+-]) Apr 25 17:13:20 cali call your pacakge tododrean Apr 25 17:13:24 tododream Apr 25 17:35:32 03Khem Raj 07org.openembedded.dev * r329d3c4cac 10openembedded.git/conf/checksums.ini: checksums.ini: Add gcc-4.4.0 checksum. Apr 25 17:36:50 thanks eFfeM Apr 25 17:39:14 yw Apr 25 19:07:12 :-) Apr 25 19:08:06 otavio, "was" ? Apr 25 19:08:16 meta-toolchain* is broken :) Unless khem pushed the fix and I missed it Apr 25 19:08:27 Tartarus: ah ok :-) Apr 25 19:08:56 Tartarus: anyway I do think we ought to use branches for those things Apr 25 19:08:57 my point is that stuff gets broken in dev, and we should fix it Apr 25 19:09:06 not stick it somewhere else until someone has time to fix it Apr 25 19:09:08 Tartarus: that is what GIT offers us Apr 25 19:09:33 Tartarus: I belive you can see the difference between a thing that is broken and an upgrade path Apr 25 19:09:44 Tartarus: an upgrade path is something that will hurt uncountable people Apr 25 19:10:01 Tartarus: while a bug is something is more controlled and even more. Something that we will work to fix Apr 25 19:10:15 otavio, a little. But I care a whole lot about SDKs building and frankly, if on-device pkg management went away I wouldn't care :) Apr 25 19:10:24 Tartarus: while the upgrade path once broke, is rather difficult someone put the effort to make it work again Apr 25 19:10:42 otavio, upgrade path breakage in dev is fine, stable it's not, imho Apr 25 19:10:55 E is in flux, once again it seems Apr 25 19:10:58 Tartarus: the problem is that dev is our "next" stable Apr 25 19:11:05 otavio, right Apr 25 19:11:15 But it's not going to be a surprise when stable happens next Apr 25 19:11:19 Tartarus: and then we won't have an upgrade path from stable to stable+1 Apr 25 19:11:20 Thinking in kernel terms Apr 25 19:11:31 -rc1 and before, it can all be kinda wonky :) Apr 25 19:11:44 otavio, sure we will Apr 25 19:11:52 if we say we only care about upgrade path from stable to stable+1 Apr 25 19:11:56 Tartarus: sorry; I didn't follow you Apr 25 19:12:03 not stable to stable+1 including all sub-points Apr 25 19:12:14 otavio, lemme try again Apr 25 19:12:24 stable to stable+1 must be upgradable Apr 25 19:12:44 Tartarus: I belive it will be rather difficult to support stable -> stable+1 if we just not care about it during dev development Apr 25 19:12:48 But when stable+1 happens won't be a surprise so we have time to sort out short-term breakage Apr 25 19:12:57 Tartarus: that is the way Debian does and there're reasons for that Apr 25 19:13:10 The right answer is "Hey mickeyl, you broke the upgrade path, can you please look at it?" Apr 25 19:13:17 Tartarus: E doesn't looks as a short-term breakage Apr 25 19:13:17 Not "OH NO!! REVERT NOW!!!" Apr 25 19:13:38 Nor "Uh-oh, lets stick that in a branch until it's fixed" Apr 25 19:14:05 dev can be a little rough, like the kernel is, at -rc1 and earlier Apr 25 19:14:13 Tartarus: I really prefer those "massive changes" to be done in a branch and then people can look at it Apr 25 19:14:19 It takes time for everyone to find the little things that someone else happened to break, unintentionally Apr 25 19:14:31 Tartarus: sure; of course this happens Apr 25 19:14:31 otavio, but it wasn't really a massive change Apr 25 19:14:47 It looks like changing to having packages be auto-generated exposed a little bug Apr 25 19:14:58 Tartarus: well; something as big as E, X and like are big. Apr 25 19:15:01 It should also be an easy enough thing to fix Apr 25 19:15:12 Tartarus: sure; aren't tose risky changes? Apr 25 19:15:25 otavio, depends on who is making them Apr 25 19:15:36 For me? Maybe. For someone that's hacking on X or E a lot, no. Apr 25 19:15:37 Tartarus: when you change how something is working for long time? Apr 25 19:16:21 Tartarus: sorry but I disagree; everyone can miss something. That is the main reason to have a review process and also why kernel uses branches and subsystem maintainers Apr 25 19:16:38 Right Apr 25 19:16:40 Tartarus: that's why we have merge window at kernel Apr 25 19:16:47 even subsystem maintainers make mistakes that get into linus Apr 25 19:16:49 that's all this way Apr 25 19:16:50 *was Apr 25 19:17:02 Tartarus: and that's why those changes are kept in the subsystems trees until the window is open Apr 25 19:17:30 Tartarus: sure; but they do hold changes during the version development in the hope to catch them Apr 25 19:17:37 otavio, yeah Apr 25 19:17:40 Tartarus: it is a process to avoid them to go to mainline Apr 25 19:17:48 Tartarus: that I miss at OE is the process for it Apr 25 19:17:49 otavio, I don't see a problem with more review at the start Apr 25 19:17:57 My concern is the freakout about when something bad happens Apr 25 19:18:24 upgrade path is broken, that's bad, but we can sort it out by means other than reverting Apr 25 19:18:35 Unless it's really not possible after investigation Apr 25 19:18:37 Tartarus: i fully agree that it is not the end of World but if a single commit breaks something the logical thing is to revert it and start on it again once fixed Apr 25 19:19:08 Tartarus: but I rather not focus on the E specific issue but the process behind it Apr 25 19:19:12 otavio, I disagree. I think it's logical to accept something being broken in the development line and focus on fixing it now, in the development line, before it gets out of hand Apr 25 19:19:20 otavio, me too :) Apr 25 19:19:36 Tartarus: and specially how to improve the process to avoid it to happen Apr 25 19:19:40 A more pull-oriented method is good Apr 25 19:19:51 Tartarus: yes; I think it is the way to go Apr 25 19:20:03 And since we agree on that much, -EOUTSIDETIME :) Apr 25 19:20:27 Tartarus: hah ok Apr 25 19:44:46 03Angus Ainslie 07fso/milestone5.5 * rb2de76bc87 10openembedded.git/recipes/efl1/etk_svn.bb: etk: more SONAME changes Apr 25 20:28:42 03Angus Ainslie 07fso/milestone5.5 * r616055f2da 10openembedded.git/recipes/openmoko-projects/paroli_git.bb: paroli: ship paroli.png icon Apr 25 20:59:29 ~curse OE ML discussions Apr 25 20:59:35 BADLY Apr 25 21:02:20 * eFfeM agrees ! Apr 25 21:02:37 :'( Apr 25 21:04:12 I should be sleeping not reading/answering etc Apr 25 21:04:57 saw your email to the list Apr 25 21:05:06 * eFfeM agrees Apr 25 21:05:13 * cbrake is amazed at how OE succeeds in spite of itself Apr 25 21:06:16 o yes Apr 25 21:06:42 cbrake: I think thats due to thick skin of many devs which just ignore shouting people and do the work Apr 25 21:07:11 and the problem is that OE was supposed to be 'project which gives fun' Apr 25 21:07:30 and for many devs it is now not fun but work (or work+fun) Apr 25 21:07:32 * eFfeM just does his thing and tries not to get involved into politics Apr 25 21:07:41 and like to keep having fun Apr 25 21:07:57 for me OE is mostly work now Apr 25 21:08:21 but I try to have fun with it too - like getting all those dusted not-used-by-sane-people device Apr 25 21:08:23 i try to keep it fun, if it turns into work someone should pay me for it .... Apr 25 21:08:25 s Apr 25 21:08:47 Apr 25 21:09:06 * eFfeM has his own device "archive" :-) Apr 25 21:09:10 who sane would use EDB9301? it is old board with broken armv4t cpu which has unusable 'FP unit' etc Apr 25 21:09:31 but I found it on shelve at friend's office and took it just for fun Apr 25 21:09:48 sounds familiar Apr 25 21:09:58 atmel ngw100 (avr32) is on my desk ONLY for fun - I do not have a use for it Apr 25 21:10:24 part of the fun is to show that you actually can do something with it, even though most people think you cannot Apr 25 21:10:31 yes Apr 25 21:10:44 eFfeM: my friend specialize on pic18 programming. Apr 25 21:10:56 but he was great Amiga coder so... Apr 25 21:11:00 cool, never did that Apr 25 21:11:12 * eFfeM was in the Atari camp :-) Apr 25 21:11:27 once he got arm7tdmi board at work. with nokia cellphone screen, audio output, sd slot and 64KB of ram. Apr 25 21:11:27 * eFfeM started programming with intel 8008 Apr 25 21:11:43 instruction set fitted on a double sided A4, that is with a short description Apr 25 21:11:47 he got audio playing from SD and some vector dots rotating on screen Apr 25 21:11:51 just for fun... Apr 25 21:11:55 lol Apr 25 21:12:12 i made my own harddisk video recorder with nslu2 just for fun Apr 25 21:12:30 and thats the feeling which I want to have with OE when I not use it just for work Apr 25 21:12:39 then bought a commercial one, since otherwise the family would not give the nslu2 back .... Apr 25 21:13:09 hrw|gone: I fully understand, and that is why I feel sad with the tone in the oe ml tread Apr 25 21:13:09 in few months I will probably have arm based audiobook reader for blind people Apr 25 21:13:19 cool Apr 25 21:13:32 they made own system but wants someone to take care of system creating Apr 25 21:13:47 the goal is: boot in less then 5s Apr 25 21:14:09 it will be work. but also fun Apr 25 21:14:12 cool, I'd love my beagle do that Apr 25 21:14:15 and it will be OE Apr 25 21:14:46 btw, I was thinking long time ago to step back from 'core team' but decided against it. Apr 25 21:14:49 i worked on a mips system where the time between startign the kenrel and running init was less than a second (if I recall correctly) Apr 25 21:15:21 * eFfeM is happy as a regular dev Apr 25 21:15:51 and I think that we will have to make some kind of vote for 'senior devs' group which will take place of 'core team' and will take decisions when needed Apr 25 21:16:32 key rule which is broken is that key changes should be discussed in the ml first before they are committed Apr 25 21:16:57 and that rule is broken in this case (and in some other cases in the past too) Apr 25 21:17:00 eFfeM: I do not see those e17 changes as key changes Apr 25 21:17:23 they are just changes, adaptations to upstream. Apr 25 21:17:40 i didn't grasp the details of it, though there were some lib name changes that were pretty drastic Apr 25 21:17:45 if they break something - discuss it, provide patches which will make use of good parts of that etc Apr 25 21:17:47 but maybe i did not fully understand Apr 25 21:17:53 yes Apr 25 21:18:00 I am ending mail on that Apr 25 21:19:13 sent Apr 25 21:19:32 hasn't landed her eyet Apr 25 21:19:34 here yet Apr 25 21:25:01 I got it Apr 25 21:25:12 me too now, reading it now Apr 25 21:26:29 fully agree Apr 25 21:26:45 calling it a day for now (and suggest you do the same) Apr 25 21:27:02 * hrw|gone -> daughter Apr 25 21:27:10 then another mail to finish Apr 25 21:27:28 ok, cya tomorrow or so Apr 25 21:28:15 "OE is not Kenny" <--- somebody needs to put that quote into the topic. :-) That's classic. Apr 25 21:29:23 re Apr 25 21:29:58 :-D Apr 25 21:30:48 Tartarus: your sdk related changes for stable are nice stuff Apr 25 21:31:16 hrw|gone, thanks, need ack'ing :) Apr 25 21:31:34 and, OE needs a nice benevolent dictator, ala Linus, but those are always in short supply :( Apr 25 21:36:56 Tartarus: basically I think that I can ack this patchset. But I want to check wireless-tools one and this will be on Monday or even later Apr 25 21:58:11 hrw|gone, k, that's fine Apr 25 21:58:21 I'm doing my best to take weekends off too :) Apr 25 21:58:48 have a good night/rest of weekend Apr 25 22:01:15 * mwester gets the most free time to work on OE on weekends. So he can see the argument that leaving OE dev broken for a weekend is painful; he has experienced that pain more than a few times so far. :( Apr 25 22:01:50 * mwester supports the "donut-able" offense rule. Apr 25 22:06:42 just to note: we need genext2fs 1.4.1 in stable/2009 (and in .dev too) Apr 26 00:16:53 03Mike Westerhof 07org.openembedded.dev * r1a33200c79 10openembedded.git/recipes/meta/slugos-packages.bb: SlugOS: packages - deprecate ctrlproxy, depends on unstaged tbd.h (samba) Apr 26 01:52:05 * Crofton|work skipped email all day to see Mil Mascaras versus the Aztec Mummy Apr 26 02:15:17 Crofton|work: you misse da nice flamewar on oe-dev Apr 26 02:15:39 I gather Apr 26 02:15:56 I need to read the list Apr 26 02:16:03 but may wait until Monday Apr 26 02:16:15 I need to get better at not working weekends Apr 26 02:18:19 We drove four hours to see http://mmvsam.com/ Apr 26 02:18:45 man this is annoying Apr 26 02:18:51 all my oe builds are full of errors Apr 26 02:18:55 eithe gnu_hsh stuff Apr 26 02:18:56 no shit Apr 26 02:19:01 or gcc itself segv'ing Apr 26 02:19:03 SHR is trashed. Apr 26 02:19:11 or git getting remote hangups from src for kernels Apr 26 02:19:13 grrr Apr 26 02:19:31 Seems somebody changed E again. Dunno why we don't all use gtk or something that's a bit more stable. ;-) Apr 26 02:19:35 in fact.. the only thing now that builds ok is my omap3 build Apr 26 02:19:49 mwester: :-P Apr 26 02:19:55 it was only a change in .so names Apr 26 02:20:11 not our fault that oe is so sensitive to the actual names of files inside its packages Apr 26 02:20:11 :) Apr 26 02:20:30 thge debian and ubuntu packages were already patching the builds to add soname changes Apr 26 02:20:32 You sound like a politician! Apr 26 02:20:39 we just standardised them upstream Apr 26 02:21:26 we could use a few politicians Apr 26 02:21:42 So now there's your upstream naming; then OE, then whatever is done on the fso/milestone5.5 branch -- which is still broken, so SHR has thier own set of patches to fix up the mess. That's three levels of name hackery. Apr 26 02:21:58 SHR? Apr 26 02:22:06 YAD Apr 26 02:22:08 well by changing upsteram we removed 1 level opf hackery for debian and ubuntu Apr 26 02:22:10 Yet Another Distro Apr 26 02:22:14 ah Apr 26 02:22:15 Oooooooo Apr 26 02:22:46 all that is needed is for the oe recipies to be dumb and just compile then name the packages explicitly and explicitly state what file patches are to be included in what packages :) Apr 26 02:23:15 Crofton|work: aztec mummy? 4hrs to see that? thats a hike! Apr 26 02:23:24 yeah Apr 26 02:23:33 My friend was an extra Apr 26 02:23:46 aaaah Apr 26 02:23:51 he was pleased with his appearance Apr 26 02:24:46 I wish people could talk about the reasons, and not about personaslaities Apr 26 02:25:00 yeah Apr 26 02:25:05 i decided to say something Apr 26 02:25:19 our upsteram shanges from our view are really simple file name changes Apr 26 02:25:21 the problem people tune out an dstop paying attention to what is really being discussed Apr 26 02:25:24 i dont see what al lthe fuss is about Apr 26 02:25:42 I do Apr 26 02:26:06 just adapt to the filename changes. Apr 26 02:26:27 Yep, that easy. Apr 26 02:26:28 oe-dev is a minefield of breaks Apr 26 02:26:36 That's true. Apr 26 02:26:41 things break- all the time Apr 26 02:26:45 fix and move on Apr 26 02:26:52 Well, that didn't happen this time. Apr 26 02:27:10 wqorry when u get into fixing wars ie person A fixes it the A way then person B fixes it again the B way Apr 26 02:27:14 I can see everyone's point of view here. Apr 26 02:27:18 then A changes it again and then B and so on Apr 26 02:27:19 yeah Apr 26 02:27:31 then you need to stop the war and figur out a compromise Apr 26 02:27:52 Upstream changes stuff, often for no reason that is apparent to the OE users (as in this case). Might be valid reasons - for others, but nothing but pain for OE. Apr 26 02:27:58 Downstream are distros - using it. Apr 26 02:28:09 IN the middle are the folks that keep it working, getting it from both ends. Apr 26 02:28:14 yup Apr 26 02:28:15 They eventually get frustrated. Apr 26 02:28:36 And when they percieve that it is each other that is causing pain, they sometimes respond. Apr 26 02:28:43 I can make several conflicting arguments for this situation Apr 26 02:28:43 in this case upsteram has its reasons and at least for some distros we reduced their workload Apr 26 02:28:56 pulling from svn refs is "crazy" :) Apr 26 02:29:01 it may not help oe - but its just another adaption like anything that changes Apr 26 02:29:11 I know I have done so, when I've lost my patience with the countless fixes and correctons fror SlugOS, all in the name of progress for someone else. Apr 26 02:29:28 Crofton|work: we slapped out tarballs of what we consider "good" Apr 26 02:29:35 http://dwonloads.enlightenment.org Apr 26 02:29:36 yes, pulling from svn refs has really messed up OE, in my opionion Apr 26 02:29:40 but they also have the soname changes Apr 26 02:29:44 one way or another u get them Apr 26 02:29:58 pulling from svn or not you get the same problem Apr 26 02:30:05 the problem is the frequency of updates Apr 26 02:30:08 not pulling from svn Apr 26 02:30:13 and WHEN you pull from svn Apr 26 02:30:17 No Apr 26 02:30:17 trying to track svn and maintaining sane packaging is crazy Apr 26 02:30:33 we clean3ed stuff up and "blessed" a specific svnrev for a subset of svn Apr 26 02:30:36 svn/git is a moving target; you have ONE SINGLE recipe. Apr 26 02:30:45 If you build from releases, you have multiple recipes. Apr 26 02:30:53 That simple bit makes things work. Apr 26 02:31:22 in some sense, OE solves too many peoples problems :) Apr 26 02:31:25 We need to review our policies for SVN and GIT fetchers, and the recipes. Apr 26 02:31:37 it doesnt much matter imho Apr 26 02:31:54 the workload gets high if you regularly update your svnrevs Apr 26 02:31:56 I think everything else is fine, if we focus on the problem being the process around the dynamic recipes, maybe we can narrow it down to something we can solve. Apr 26 02:32:01 mwester, that is really a distro issue, do you use these recipes Apr 26 02:32:02 an thus have to very often adapt to changes Apr 26 02:32:12 as opposed to releases where you adapt once every 6 or 12 months to a release Apr 26 02:32:16 Crofton|work: Not for SlugOS, and we are generally happy. Apr 26 02:32:31 For Openmoko -- almost everyrthing is svnrev, and it is miserable. Apr 26 02:32:36 the problem is when you are tracking bleeding edge stuff Apr 26 02:32:42 imho dynamic stuff - if u are pulling from svn should be delt with like upstream does Apr 26 02:32:45 ie quick and fast Apr 26 02:32:50 if it changes and uw ant the changes adapt Apr 26 02:32:51 It violates the basic idea of stability, you can never guarantee you get the same thing twice. Apr 26 02:32:53 and do it quickly Apr 26 02:33:05 and cycle very fast - dont put in mountaisn of "process" Apr 26 02:33:14 I think to track bleeding edge we need to do something like an overlay Apr 26 02:33:15 OR saimply have blessed release versions and just stick to them Apr 26 02:33:17 take your pick Apr 26 02:33:25 bleeding edge - or stable safety land Apr 26 02:33:38 OE proper would do just releases, and everyone would create their own overlay for svn or git stuff Apr 26 02:33:48 well there is part of the problem Apr 26 02:33:53 ok, I need to fall over, gn Apr 26 02:33:56 i know that people want svn efl because it moves fast Apr 26 02:34:01 someone compl;ains about bug X Apr 26 02:34:06 it gets a fix in svn in a matter of days Apr 26 02:34:13 or new feature X appears in a few days Apr 26 02:34:16 That's why I commented on gtk+. E may not be ready yet. Apr 26 02:34:18 and they want it NOW Apr 26 02:34:35 thatds up to them Apr 26 02:34:41 technically i dont see it as unstable Apr 26 02:34:44 If it's not ready, it shouldn't be in the main OE repo, it should be an overlay. Apr 26 02:34:48 it szimple grows new features faster than gtk Apr 26 02:34:49 Only releases in OE. Apr 26 02:35:09 if peolpe build against gtk they will also be stuck with its inherent limitations too Apr 26 02:35:13 and they dont want that Apr 26 02:35:53 Well everyone want's a solution that's perfect for them; the trouble is that perfect solution is someone else's nightmare. Apr 26 02:36:09 hehehe Apr 26 02:36:10 Which is how we came to be talking about this in the first place. Apr 26 02:36:12 true Apr 26 02:36:22 but in this case it is a SIMPLE small change Apr 26 02:36:28 that is being blown out of all proportion Apr 26 02:36:35 It was the proverbial straw Apr 26 02:36:45 the actual technical problem is now taking a seat Apr 26 02:37:06 Just like samba took the blame for the "delete old recipes" explosion. Apr 26 02:37:28 It wasn't just samba, that was just the one that finally caused me to lose my patience with the issue. Apr 26 02:37:32 don't get me started on python 2.5 disappearing ... Apr 26 02:37:54 You too? Yeah, I bit my tongue to keep from saying something about aht. Apr 26 02:38:10 my tongue has marks in it over that Apr 26 02:38:29