#qi-hardware IRC log for Thursday, 2010-11-11

qi-bot[commit] Werner Almesberger: atspi-rssid: for color and geometry, use #defines instead of literals http://qi-hw.com/p/ben-wpan/256da9100:48
qi-bot[commit] Werner Almesberger: atusb/: connect TST to P0_7 (rework of existing boards) http://qi-hw.com/p/ben-wpan/c45f1bb00:48
qi-bot[commit] Werner Almesberger: atusd firmware now supports setting the TST pin. http://qi-hw.com/p/ben-wpan/233755700:48
qi-bot[commit] Werner Almesberger: libatspi: new function atspi_test_mode to enter test mode http://qi-hw.com/p/ben-wpan/5d63a0000:48
qi-bot[commit] Werner Almesberger: atspi-txrx: option -T <delta_MHz> to emit a constant wave http://qi-hw.com/p/ben-wpan/d4fe02700:48
qi-bot[commit] Werner Almesberger: atspi-txrx: new option -f to set the channel by frequency http://qi-hw.com/p/ben-wpan/1e7813500:48
wpwrakrafa: i've been thinking about the problem of making the whole patent cruft exclusion process a bit more sustainable. what you've solved so far is making it work once. that's that hard part. now that we know that it works and where the remaining problems are, it may not be all that overwhelming to make it work all the time.05:23
wpwrakrafa: first of all, i think the remaining issue are: 1) you're (manually) removing only a small number of layers from the dependency graph. so users can still get complains about missing packages, which isn't nice.05:25
wpwrak2) the removal mechanism is not integrated into the jlime or OE workflow. thus, it would need manual work for each future update, which is a boring task.05:27
wpwrak3) packages that integrate many other things that aren't used all the time, such as libsdl-mixer, may cause overly pessimistic dependencies, making the whole affair frustrating for users (who want as many things as possible to work) and distribution makers (who want to make a good and featureful distribution as possible).05:30
wpwrakthat's the three issues i can think of at the moment05:30
wpwrak1) seems to be a pure software problem. maybe you already have most of the solution with your opkg optimizer. if not, it can probably be hacked quickly.05:31
wpwrak2) and 3) may need OE upstream support. in fact, it would be best if all this doesn't stay a jlime problem but something OE just supports natually.05:33
wpwrakhe who just rejoined the channel mentioned that, once upon a time, openmoko tried to move OE in this direction, but failed for some reason. that's a good sign. if openmoko failed to do it, it's probably not very hard to accomplish :-)05:34
wpwrakrafa: for 2), i think your idea of expressing things in terms of package dependencies, has a lot of potential. just instead of making it a conflict, i would make it a requisite. e.g., have a meta-package license-mp3, which the usual suspects depend on. if you have license-mp3, you can install them, if not, it'll fail.05:36
wpwrakmaybe there are even other mechanisms in the dependency system of OE or opkg that let you accomplish such things. i.e., the use of meta-packages as "config flags"05:37
wpwrakthe purning tool of 1) would then clean up the dependency graph such that no trace of license-mp3 remains visible. in fact, if you frame it this way, it doesn't look all that much like a subterfuge anymore.05:39
wpwrakfor step 3, perhaps there is a way to express this in terms of dependencies, too. e.g., could you have a package that needs a certain feature but doesn't care about how you implement it ? e.g., "mail-client" needs "editor", but doesn't care whether you use vi, joe, or emacs.05:41
wpwrakif this is possible, then you could have two (or more) variants of such integrator libs. e.g., a libmad-mp3 and a libmad-basic. libsdl-mixer would depend on libmad-mp3 || libmad-basic. libmad-mp3 in turn would depend on license-mp3. now if we remove license-mp3 and reconstruct the dependency graph, libsdl-mixer would simply depend on libmad-basic. problem solved.05:43
wpwrakso if OE/opkg has something like this, that may be a nice and clean solution.05:44
wpwrakthere's also the question of how the dependencies are mapped. does OE use exactly the same dependency data you have for opkg and/or the Packages file ? or is it slightly different, and translated in the process ?05:45
wpwraki would propose a three-step process: a) find out what can work with the available technology. b) prototype this and see how it goes (doesn't need to be polished or complete). c) if we're not happy with the result, back to a). if we are, try to sell the idea to OE upstream.05:47
wpwrakrafa: of course, if you have a regular OE upstream contact for this sort of things, it would make sense to involve that person/these persons early on05:48
wpwrakhow does this sound ?05:48
wpwrak(now .. what shall i do until rafa wakes up .... :)05:49
wolfspraulwpwrak: sleep?05:51
wpwrakwolfspraul: just got up :)05:52
wpwrakwolfspraul: if you remember anything from OM's attempts to bring patent (in)sanity to OE, that might be useful05:55
wolfspraulno not really. back then we just tried to get mp3 out, but never succeeded.05:55
wolfsprauleven though the message was clear, everybody knew it, everybody knew the priority05:56
wpwrakcan you be more specific ? what was tried and how did it not succeed ?05:56
wolfspraulI don't know.05:56
wolfspraulI only know you could still play mp3 :-)05:56
wpwrakhow did you find out you could still play mp3 ?05:57
wolfspraulI think we are already further than that, we have rafa and a bunch of people who clearly understand the problem, understand a potential solution, are quite a way into that solution, etc.05:57
wolfspraulthe player was in the rootfs :-)05:57
wpwrakokay. i agree with your point :)05:58
wpwraksounds a is OM's lack of success with this undertaking had more to do with ineptitude than anything else :)05:59
wpwraks/a is/as if/05:59
wolfspraulwell with that many people, the problem is more of a high level problem first05:59
wolfsprauldoes everybody (who needs to) understand the problem06:00
wolfsprauldo they understand the priority of the problem06:00
wolfsprauldo they agree on one common way to solve the problem06:00
wolfsprauland finally - can they pull off the solution as a team06:00
wolfspraulmaybe all of those failed, I don't know...06:00
wolfsprauljust technically, it's clear though that removing something like MP3 is not trivial in OE06:01
wolfspraulbut it sounds like we are quite far, so let's see. almost there maybe/hopefully!06:02
wpwrak(many people) and, last but not least, do those who play an essential role in making this happen actually know that ? :-) that's why i'd like to start bouncing this ideas around with jlime. keep the circle small. i'd rather not send memos for the 4th annual meeting of the G21 representatives to the mp3-patent removal group of the policy compliance subcommittee of the united nations ...06:05
wpwrak(almost there) yes. most of the time, the hard part is finding *some* way to do it. once you know it can be done, it's relatively easy to make it smoother and better.06:06
wpwrakah, i know. i could do a Great Renaming :-)06:16
rafawpwrak: Hey morning. Your plan sounds okey for me. Kristoffer has rights on OE mainstream. But I would try to upload the current repo sane and safe. That is the thing I could work these days (or not, it depends, we will see). I just wanted to share jlime for qi/resellers to avoid, for example, guys here saying :07:08
rafa"I have tried for the last 10 days to build pyth..plot and I have problems with 100 librarires missed"07:08
rafa"I have tried the last week to build a fancy editor..." .. Things like that.07:09
wpwrakgood morning ! :)07:10
wpwrak(finish the upload) yup, that's good. finish one thing, then do the next. i should do that more often, too ;-)07:11
rafawolfspraul: if a library uses A+B+C+D.. A is problematic (patented technology).. And somebody would like to add "E" feature which could be patented technology soon. I think that to remove that from a system (OE, openwrt, debian) is not trivial for anybody. I mean, I do not know exactly what openwrt does.. but this example or you remove the whole library or you can not automate that.07:11
wpwrak(messy dependencies) well, we can call it a "beta" with some unresolved dependencies not fully cleaned up yet ;-)07:12
rafabut this example or=but on this example either07:12
rafaIf you remove the whole library a lot of packages which need it will not work and you will need to remove them as well (if we are talking on building level then the building system should not build those)07:14
wpwrak(can't automate) you mean automating building a library that only uses B+C+D ? or automatically detecting that someone may add E in the future ? the latters seems impossible indeed ;-)07:14
kyakopenwrt does support a bunch of patented things, but it won't build unless you explicitely allow them by setting CONFIG_BUILD_PATENTED07:16
kyakand it is much easier to control it in openwrt, when you can build a minimal system and then add libraries/utilities there one by one, thus controlling thw hole process07:18
kyakother than throwing away libraries and breaking things in OE07:18
wpwrakrafa: does OE have alternative choices ? e.g., my vi/joe/emacs example ?07:18
wpwrakrafa: also, does OE have build variants of the same (source) package ? e.g., emacs vs emacs-x11 ?07:19
rafawpwrak: automatically detect everything.. For example if somebody is adding a new package to that building system another person or the same guy should stare it for a while to understand if it has patented stuff. automatically building a library that only uses B+C+D needs that you know exactly the options to build.. ANd worst.. the system should be really smart if other packages which uses that "A" feature from that library are around. The system should kn07:20
wpwrakkyak: i think the "throw away" approach has its flaws but it should be easy to fix them. you'd just have to pick up the meta-data set and check for referential integrity (recursively, of course). remove anything that's orphaned and dump the result.07:21
wpwrakkyak: this could even be a useful tool for checking the integrity of repositories that supposedly contain "everything"07:21
rafakyak: yes.. it is almost a manual work.. Debian and Fedora surely works quite well on that because every package has a stare from somebody which take cares of every package07:21
rafawpwrak: what do you mean with "alternative choices" (vi/joe/emacs)?07:22
wpwrakrafa: your message was cut as "The system should k|"07:22
rafawpwrak: "The system should k|"= "The system should know if those packages could be built or not"07:23
wpwrakrafa: (alt choices) if you need one of several possible implementations of a certain feature, can you express this such that only one will be installed ? (or, if you already have it, nothing new will be installed)07:23
wpwrakrafa: another example could be bison vs. berkeley-yacc. both provide a "yacc"07:24
wpwrakrafa: (automate) okay, i understand it. no, you can't fully automate this. but you can break it down into individual steps, so it's easier to fix.07:25
wpwrakrafa: (steps) for instance, if someone adds E, then E could depend on license-foo. the person submitting E or the person(s) reviewing the submission would add that dependency.07:26
wpwrakrafa: if you have license-foo enabled/installed, then everything is fine. if not, E could not be installed, and thus the library could not be installed, and thus all the apps depending on it couldn't be installed.07:27
wpwrakrafa: step 2: now someone can go and clean up that mess. e.g., find out if E can be split into an E-with-foo and an E-without-foo part.07:27
rafawpwrak: (alternatives): Ah, no sure. Surely, but on libraries doing many tasks (like libsdl-mixer which lets programmer to play wav/ogg/midi/mod/mp3) does the "alternatives" option hard to accomplish07:28
wpwrakrafa: that may be desirable anyway. e.g., if you want to build a small system, you may not want to have libraries for stuff you'll never use anyway. even if you don't care at all about patents.07:28
wpwrakrafa: (continuing step 2) sorry, that's lib-with-E and lib-without-E07:29
wpwrakrafa: (cont) so the applications that don't need E would simply depend on lib-without-E and everyone is happy07:30
wpwrakrafa: (many alternatives) yes, combinatorial explosion could become a problem :-) put ten sub-packages into a library and if they all are potential trouble, you get 2^10 choices ;-)07:30
wpwrakrafa: (many combinations) in reality, the relevant number will probably be small, though. maybe just patents/no-patents. also, such things could be automated.07:31
rafawpwrak: how would you work the chain?.. library X uses A+B+C+D.. Anothere library Z uses X. A programmer used library Z into his program P. He wanted to use the C feature from X but using the nice API of Z. That is not trivial.. Now..07:32
wpwrakstep 2 would be to split the library into variants. step 3 would be to adjust the dependencies in the users of the library07:32
rafawpwrak: The program P just uses Z.07:32
wpwrakin this case, and if there is no other mechanism, you wold have to tell P which variant of Z he can use07:34
wpwraki don't know if OE has other mechanisms, though07:34
rafawpwrak: how would we work that if the feature A is problematic?.. ANd if the chain has 20 jumps?.. Should the guy adding that software on the building system to follow the chain to find that the program P wants to use C but on the same time C lives with A?07:34
wpwrakfor example, gentoo has flags for general capabilities07:34
wpwrakso you could say, for example, that you have opengl hardware, and then it would enable opengl support in all the packages07:35
wpwrak(20 jumps) not sure if you really get chains this deep. but yes, it would be messy. you'd have to split each member of the chain07:36
wpwrakthat is, unless you have an alternative mechanism, like the one in gentoo07:36
rafawpwrak: yes.. gentoo is doing that nice.. But well, you need that amount of people working on that.. That is why Debian or Fedora do a proper work on that as well. Because every package is being checked almost manually.07:36
wpwrakyou could of course just make the relevant members of the chain depend on license-foo07:36
rafawpwrak: and that is why I would like to use Debian on everything.. Just that the packages are made for PC or similar powerful devices.07:37
wpwrakhow do the other jlime members like the debian idea ? :)07:37
rafawpwrak: I do not know :).. But well, Debian is not prepared for tiny devices I would say. It has into the packages a lot of stuff that you would remove/split for mobile devices.. If you want to check a simple example, check the package "perl" on ubuntu/debian.. If somebody would like to use just a small perl lib he should install the complete perl package which has around 700+ files07:40
wpwrak(many people needed) i think the multi-step approach should scale well. you can delegate tasks so you don't get a single choke point. also, you can always stop at some point and everything will still work, just a little less nicely.07:40
wpwrak(big packages) yes, they may have to be broken down into smaller bits. that would be a policy question for debian upstream - would they welcome something like this ? and if yes, in what form ?07:41
wpwrak(what form) form of the feature, not form of the welcome :-) ("sure, we're already cooking the pot of tar to welcome you ...")07:42
wpwrak(20 jumps) i think that would also be a very odd scenario. most of the time, libraries try to provide an abstraction. so libmedia may use libmp3, but the users of libmedia may just see something like play_media(const char *filename)07:43
rafawpwrak: No idea about to work with Debian.. They are a little negative with new ideas if you are not one of the 50 big devs. Fedora is nicer to welcome I would say :)07:44
rafaBut Fedora does not support all the archs which Debian does well07:45
wpwrak(20 jumps) of course, you can get fancy dependencies. e.g., of you have a libmedia-py that's just a wrapper for libmedia (and doesn't know anything about MP3 either), but then you have a game that comes with MP3 files and uses libmedia-py, then libmedia would depend on license-mp3 and the game would depend on license-mp3 but libmedia-py not07:45
wpwrak(20 jumps) but i think these are corner cases. in the end, you may just do it this way for the occasional odd package, and not mess with the library dependencies. you could also argue that this is in fact a correct dependency graph, because libmedia does not per se guarantee mp3. much like you may have a dependency on "cat" but that doens't mean that cat knows about every file you may wish to "cat"07:47
rafawpwrak: bah... with distributions...distributions....  I will download the whole internet into my PC and I'll build everything like I want. I will have a flag "porn" as well on my building system07:48
wpwrak(debian) hmm, so we should win one of the debian gods over07:48
wpwraklibmanga-brutal-underage ;-) perfectly legal in japan, of course ;-)07:49
rafawpwrak: how is happening right now on qi-openwrt git?.. I see some mails of people saying that they ported some stuff.. and then that stuff lives now on the qi openwrt git.. Is there some "check" "flag" process there?.. Or all that is automatically checked for patented technologies?07:51
wpwrakpheew. so .. what's the plan then ? :)07:51
wpwraki think it's all manual07:52
rafalibmanga ;-))))07:52
wpwrakwhen you put a package, you'd probably decide whether it needs CONFIG_PATENTED or not. after that, the build system can figure out what to do.07:52
wpwraknot sure what it does about dependencies of the kind you desribed. probably just build something that doesn't quite work ;)07:53
rafawpwrak: and does the people know that CONFIG_PATENTED?07:53
wpwrakbut that's okay, you can always refine things later. no need to make something mega-complex just to handle every last corner case.07:53
wpwrak(do they know it) i guess it sinks in after the first public flogging ;-)07:54
wpwraknaw, there are only few committers, it seems. so it's easy to communicate that policy. i think most distros have a review system anyway, so reviewers would know what to look for.07:55
wpwrakit's not really all that hard once you've made the initial preparations. what's painful is to get there from zero.07:55
rafawpwrak: plan: no idea.. I will work on having a sane and safe repo useful for qi/resellers.. Because free time is not with me I could try to think the best idea for the future (best idea: OE, or Debian, etc...). So now resellers can use jlime with a sane repo if they want.. And we can work on some better idea for the next year ;)07:55
wpwrakwe can also see what the OE guys think. i mean, this isn't just "our" problem. particularly OE should be keenly aware of such issues.07:57
rafawpwrak: OE: maybe they already solved that well and we are talking without sense :P07:58
wpwrakthat's actually how it *should* be ;-)07:59
kyaklarsc: hi! could you please backport your changeset here https://dev.openwrt.org/changeset/22668/trunk/include/package.mk to backfire? i'm trying to build ncurses variants, but it fails because the files..08:09
kyak..from previous build get removed.08:09
kyakpretty important though small fix, which would help a lot..08:10
larscis ncursesw part of backfire?08:11
kyaknope, but i'm trying to build it from openwrt-packages08:11
kyak(i guess this change is helpfull not only for libncursesw)08:12
kyaklarsc: so what do you think?08:26
qi-bot[commit] Werner Almesberger: The Great ATSPI Renaming, part 1: rename atusb firmware files from atspi to atusb http://qi-hw.com/p/ben-wpan/7e71f9808:39
qi-bot[commit] Werner Almesberger: The Great ATSPI Renaming, part 2: rename ATSPI_* identifiers to ATUSB_* http://qi-hw.com/p/ben-wpan/96b6a5008:39
qi-bot[commit] Werner Almesberger: The Great ATSPI Renaming, part 3: rename libatspi.a to libatrf.a http://qi-hw.com/p/ben-wpan/84b61f308:39
qi-bot[commit] Werner Almesberger: The Great ATSPI Renaming, part 4: rename include/atspi.h to include/atrf.h http://qi-hw.com/p/ben-wpan/cf23ac608:39
qi-bot[commit] Werner Almesberger: The Great ATSPI Renaming, part 5: rename "struct atspi_driver" to "atrf_driver" http://qi-hw.com/p/ben-wpan/688df9708:39
qi-bot[commit] Werner Almesberger: The Great ATSPI Renaming, part 6: change atrf API from atspi_* to atrf_* http://qi-hw.com/p/ben-wpan/bcd369108:39
qi-bot[commit] Werner Almesberger: The Great ATSPI Renaming, part 7: rename tools/atspi-* to tools/atrf-* http://qi-hw.com/p/ben-wpan/287317408:39
qi-bot[commit] Werner Almesberger: The Great ATSPI Renaming, part 8: rename the tools from atspi-* to atrf-* http://qi-hw.com/p/ben-wpan/6ee514208:39
qi-bot[commit] Werner Almesberger: The Great ATSPI Renaming, part 9: update comments as well http://qi-hw.com/p/ben-wpan/a8a898e08:39
qi-bot[commit] Werner Almesberger: lib/atusb.c: fix typo in function name http://qi-hw.com/p/ben-wpan/809311208:39
qi-bot[commit] Werner Almesberger: atusb.sch: mention that the TST connection is a rework and not in the layout http://qi-hw.com/p/ben-wpan/4d7cb1208:39
wpwrakphew. that one's been haunting me for a good while08:40
wpwrakxiangfu: do you know what position Jan Luebbe has in the debian hierarchy ?08:46
qi-bot[commit] Werner Almesberger: The Great ATSPI Renaming, part 10: more title comment fixes http://qi-hw.com/p/ben-wpan/d1953cd08:58
qi-bot[commit] Werner Almesberger: The Great ATSPI Renaming, part 11: TODO update and fix script using a tool http://qi-hw.com/p/ben-wpan/7f9488e08:58
qi-bot[commit] Werner Almesberger: Various items in CNTR referred to ATSPI/atspi http://qi-hw.com/p/ben-wpan/b2049e708:58
xiangfuwpwrak: I don't know. maybe ask Wolfgang.09:05
wolfspraulI don't know either.09:06
wpwrakhmm. well, we can always ping him and see where this leads09:12
wpwrakwolfspraul: i guess you'd be happier with debian than with OE ? :)09:12
wolfspraulon the NanoNote?09:13
wolfspraultoo little memory09:13
wolfspraulFedora was interested to support it, they just lowered their minimum memory requirement from 128 to 6409:13
wolfspraulbut they will stay away from 32mb platforms09:13
wolfspraulopenwrt on the other hand (correct me if I'm wrong) was designed for and runs on 4mb, 8mb systems without a problem. even 2 mb? maybe not anymore...09:14
wolfsprauloe always was kind of in the middle, say for 32 or 64 it should be fine?09:14
wolfspraulso am I happier with Debian than with OE (on the NN) - no09:14
wpwrakwell, the basic assumption is that there would be work on debian to make it happy with a smaller memory footprint09:17
wolfspraulnot sure09:17
wolfspraulthis doesn't sound like a good plan to me09:17
wolfspraulnobody will join the effort09:17
wpwrakthe sources are the same, so there's nothing that would fundamentally prevent debian from running on small systems09:17
wolfspraulmaybe start with Debian 2.1? :-)09:17
wolfspraulah well, projects have a focus09:18
wolfspraulmemory is going up09:18
wolfspraulany decent android phone has how much now? 512mb? more?09:18
wolfsprauldon't fight mother nature09:18
wpwrakyeah :) 1 GB is the new 640 kB ;-)09:18
wpwrakpeople are even doing crazy reworks on the ben ;-)09:18
wolfsprauldebian on a 32mb system is off-chart09:18
wolfspraulso it's great that we got it working, and I hope the port stays alive09:19
wolfspraulbut I doubt we get enough mindshare about Debian folks for our problems once they discover we are targeting a 32mb system09:19
wolfspraulI meant 'among Debian folks'09:20
wpwraklet me rephrase the question: if its size requirements were compatible with the ben, would you like it better than OE ?09:20
wolfspraulI see Debian as a 'distro'09:20
wolfspraulnot as a tool to create custom/optimized images09:21
wolfspraul(that's how I see OpenWrt)09:21
wpwrakwhether the debian folks would consider this a worthwhile goal is indeed to be seen. i also don't know how hard exactly it would be. i mean, does openwrt have a ton of local patches to upstream sources to shrink the stuff ?09:21
wolfsprauland from what I know about OE, I would say the result of OE is also a distro09:21
wolfspraulat least it's so hard to build that I have rarely seen someone touting it as a great tool to make customized images09:21
wpwrakOE is even a meta-distro ;-)09:21
wolfspraulso yes, if I have enough memory, I would 100% want Debian or Fedora09:22
wpwrakhmm, except for openmoko, you mean ;-)09:22
wpwrak(customized images)09:22
wolfspraulI don't know why those decisions were made, it was way before me.09:22
wpwrakregarding images, i don't particularly like that "cook an image" kind of process. that really ought to be a stage the follows the making of packages. like my myroot thingy.09:23
wolfspraulDebian also includes MP3,I think09:23
wolfsprauland I doubt it's a flexible enough tool to remove such stuff easily09:23
wpwrakgiven the general political background of debian, they should at least be sympathetic to the cause :)09:23
wolfspraulespecially not if some new nonsense patent comes up, but we need to react and do some surgery09:23
wolfspraulok but I don't want to be in 5 years of lobbying during which I cannot sell my stuff09:24
wpwraksure. needs to get fixed first. much like the memory footprint.09:24
wolfspraulI think fedora is getting more aggressive on the patents now09:24
wolfsprauldid I read this somewhere? I forgot...09:25
wolfspraulare they even removing mp3 now?09:25
wpwrakright now, we have openwrt. very soon we have jlime. let's save the colonialization of debian for the next year ;-)09:25
wolfspraulit's already there, and I hope nebajoth will keep it alive :-)09:25
wpwrakmaybe in their "forbidden things" like ?09:26
wolfspraulhe will, I'm sure, just a little later09:26
wpwrak(debian) well, make it a first-class citizen of qi-hw, like openwrt and jlime.09:26
wolfspraulbiggest stopper (maybe only one?) is patents as well09:27
wolfspraulfirst nebajoth needs to come live again, which I'm sure he will at some point09:27
wpwrakpatents, memory footprint, probably usability09:27
wolfspraulwell debian works today09:27
wolfspraulof course you need things like swapfile on sd card :-)09:27
wpwrakwolfspraul: the more we mention the name of nebajoth, the more likely it is, nebajoth will notice and become alive ;-)09:27
wolfspraulwpwrak: btw, I think there was a gentoo for nanonote effort too at some point09:29
wolfspraulnot sure what happened to it09:29
wolfspraulmax poseidon in belarus did it? forgot...09:29
wolfsprauland fedora would have almost started, but the 32mb was a blocked and they didn't want to start on the dev-only avt2 board09:30
wolfspraulwas a blocker09:30
wpwrakhmm, pity09:31
wolfspraulwpwrak: gbraad is our Fedora guy here :-)09:31
wpwrakso, what does openwrt do to stay lean ? swap eglibc for uclibc and that's it ? or are there a gazillion patches that trim down every last bit of fat, plus another gazillion that make things work with uclibc ?09:32
wpwrakrafa: same question for OE/jlime :)09:33
wolfspraulbut it seems Fedora, in the form of Fedora Electronic Lab, is getting behind Milkymist in a big way (as a dev environment)09:33
wolfspraulso there could be some marriage later on...09:33
wolfspraulI believe openwrt started on 2mb systems09:34
wolfspraul2mb memory09:34
wolfspraulor maybe 4?09:34
wolfspraulanyway around there09:34
wolfspraulthat's all I know, not how they did it...09:34
wejpit started on a 4 MB system, but there are trimmed down version for systems with only 2 MB09:34
wolfspraulwejp: ah great, thanks09:35
wolfspraulhow about the backfire release? still runs on 4 mb systems?09:35
wejpyes, it does, it still runs on the original WRT54G (which is the device openwrt got its name from)09:36
wejpthat one has 4 MB flash and 16 MB RAM09:36
wolfspraulwejp: is 16 mb RAM the lowest in memory backfire supports? (off the top of your mind)09:36
wejpnot sure, but even if it runs with 8 MB, it would be of very little use09:37
wpwrakwejp: so where's the magic ? just switch to uclibc ? heavily customized packages ? just don't install the big ones (that's cheating, but .. :)09:37
wolfspraulok got it09:37
wejpbasically it is that. uclibc saves lots of memory compared to glibc09:37
wolfspraulmy point is still valid - 32 mb memory is a very nice system for openwrt :-)09:38
wpwrakwolfspraul: dreaming of linux-2.6.42/arch/8051-nommu/ ? ;-)09:38
wolfspraul(I mixed up memory and nand size earlier)09:38
wejpalso it is important to only enable the necessary stuff in the kernel and leave everything else out (build everything else as modules which can be installed optionally)09:38
wejpoh, yes, 32 MB of RAM is pretty good for openwrt, although there are routers with more, most of the supported devices have either 16 or 32 MB09:39
wpwrakmy first linux system had 4 MB of RAM ... later needed to upgrade to 8 MB for X, though. damn bloatware :)09:39
wejphehe, one can even run X with 4 MB only09:40
wejpwithout swap that is!09:40
wejpbut you can't do much else then ;)09:40
wpwrakwejp: (uclibc) does openwrt need a lot of patches to work with uclibc ? or do applications usually not notice / already come uclibc-ready ?09:40
wejpmany applications just need to be compiled against uclibc and run just fine, there are a few incompatibilities with glibc though09:41
wejpbut most applications run fine without patches as far as i can tell09:41
wejpi have recently built my own little linux system from scratch with uclibc (for a device with similar hardware specs like the Ben) and i did not need to apply sepcial pathces for the application i have been using09:43
wolfspraulwpwrak: for the oe decision at om. remember gta01 had 64mb memory.09:43
wolfspraulat that time openwrt hardly had any gui packages, I don't think openwrt would have looked like any reasonable option at that time.09:43
wolfsprauland with 64mb, debian and fedora were not really possible either09:44
wolfspraulso it came down to only oe09:44
wolfspraulwith the gta02, of course memory would have been enough for debian or fedora already09:44
wolfspraulmeanwhile openwrt started to pickup more and more gui apps09:44
wpwrakwejp: kewl. so perhaps a debian wouldn't be too traumatic once someone figures out how to make it use uclibc09:44
wolfsprauljust my recollections, others may have observed things differently...09:45
wpwrakwejp: or make eglibc drop some fat :) eglibc is supposedly already a huge improvement over glibc.09:45
wejpwpwark, the thing is  you have to recompile every single package, if you do that, you could use debian, but keep in midn that dpkg with apt uses a lot of memory09:45
wejpyou need to have swap to use it, which i really don't like09:45
wpwrakwolfspraul: (oe at om) and let's not forget that mickey is a zaurus/oe veteran ;-)09:45
wejpipkg/opkg uses a lot less memory09:46
wpwrakwejp: couldn't you use just opkg to install those debian packages ?09:46
wejpnot sure. ipkg is quite similar to dpkg, but not identical09:47
wpwrakwejp: rafa did some work on making opkg (right ?) behave even better09:47
wpwrakwell, i'd file the package installer under "minor problems" :) the problem per se isn't exactly "NP = P ?"09:48
wejphehe, no i guess not, but still, i wouldn't say it is a minor problem, because the package manager is an important part of every linux distro09:48
wejpand i've tried debian on a similar system like the ben (312 MHz ARM9, 32 MB RAM) and without swap it is not possible to use apt and even with swap (on a sd card) it is damn slow. i cannot recommend it09:49
wpwrakthat's true. but an inefficient package manager sound fixable. particularly in the debian universe where there are already several partially compatible package managers :)09:49
wpwrakyup, the insane memory demands are a known issue. and already a partially fixed one.09:50
wejpmaybe it is fixable. question is if it is worth the effort09:50
wpwrakthe only thing that's not so nice about rafa's approach is that, as far as i know, it's just a script wrapped around the installer09:50
wpwrakbut i'm sure that can be dealt with, too09:51
wejpwhen going through all that, what woulbd be the advantage over openwrt in the end?09:51
wpwrakwhat scares me a bit about uclibc is that qi-hw even has to revert a uclibc upgrade due to too many problems. that doesn't sound nice.09:53
wpwrak(advantage) LOTS of packages :)09:53
wejpok, but you have to compile every single one of them09:53
wpwraki view the ben as basically a PC09:54
wejpyou cannot just use the mips debian packages09:54
wpwrakwe have computers for that ;-)09:54
wejpfor my taste debian is much too bloated, but having another option for a operating system is nice of course09:56
wpwrak(build everything) and let's not forget gentoo, where every single user does the whole rebuiling each time something changes :)09:56
rafawpwrak: jlime uses eglibc.09:56
wpwrakrafa: and you're happy with its size ?09:57
wejpoh and another important aspect of openwrt is busybox of course. that saves a lot of space on the flash as well as memory in RAM09:58
wpwrakwejp: sigh. busybox does save space. but at what a horrible price ... :-(09:58
wpwraki've grown quite a hatred for busybox over the years. busybox and dropbear.09:59
wejpi don't think it is such a horrible price, and i think it is quite an accomplishment what the busybox guys have achieved09:59
wejpwhy is that? what do you hate about those so much?10:00
wpwrakthe price is that you can't trust any scripts to work. there are countless subtle incompatibilities10:00
wejpbesides, with only 4 or even 8 MB flash which is very common with routers, you don't have much of a choice there10:00
wejpscripts only fail if you rely on bash functions10:00
wpwrakyes, i understand the point for extreme low-memory systems10:00
wpwrakthere you'10:01
wejpif you stick with sh you should not run into bigger problems10:01
wpwrakre heavily customizing anyway. so then it's okay if you have to work around incompatibilities.10:01
wpwrak/bin/echo >/dev/full10:01
wpwrakjust to name a recent discovery :)10:01
wejpwhat's that supposed to do?10:02
wpwrakexpected: /bin/echo: write error: No space left on device10:03
wpwraka correct shell would also do the same for just  echo >/dev/full10:04
wpwrak(with echo usually being a built-in)10:04
wpwrakparticularly status/error reporting is a mess in busybox/dropbear. and if you have to test every single possible error condition to see if the tools treat it correctly, that makes for very slow going.10:06
rafawpwrak: size is okey. bootstrap is just 8MB I would say10:06
wpwrakand of course, you'll still miss things, which come to haunt you later10:06
rafawpwrak: also.. about OE/Debian/Fedora.. I see them sexy because they have a huge repo with software already built (well, no OE, but you can build that using OE).10:07
wpwrakso yes, if you're dying for space, fine. but if you have at least a tiny bit of breathing room, i'd stay away from these things.10:07
rafawpwrak: I do not see OE/Debian/Fedora sexy to build the minimal rootfs.. Maybe they are , but I would not say.. Debian is not okey because it uses a lot of RAM10:07
rafawpwrak: If I build a minimal rootfs from Debian repo using the same software that openwrt uses for its image surely that Debian rootfs would use few RAM.10:08
wpwrakrafa: (8 MB) okay, not quite down to uclibc levels, but not too obese either. hopefully it stays that way :)10:08
wpwrakrafa: (a lot of RAM for debian) how come ?10:09
wejpeven bash alone uses more than 1.5 MB of RAM which is a lot for a machine with only 32 MB10:11
rafawejp: if I build a rootfs using Debian repo which does not have but busybox10:11
wpwrakwejp: please don't get me wrong. i love openwrt for what it does, but i just don't see it as a good fit for a general-purpose machine. also, i don't think there's much of a point in building a temple around the 32 MB of the ben. before too long, it will be expensive to have such small amounts of memory ;-)10:12
wpwrakwejp: (bash) yeah, bash is a bit of a pig. i wholeheartedly recommend staying away form bashims wherever possible.10:13
wejpwpwrak, for machines with more RAM i agree that it is mor comfortable to have a more fully featured system, but then ben as it is right now has only 32 MB and that will not change10:13
wejpwpwrak, which shell do you recommend?10:13
wpwrakwejp: yan to the rescue ! ;-)10:13
wejphehe, yeah, more RAM and USB host are the most important features :)10:14
wpwrakwejp: oh, i basically still use bash everywhere. but i try to write my scripts such that they don't require bash.10:14
wpwrakaye. and a bit of RF, and we have a nice package :)10:15
wejpyeah, shell scripts should avoid relying on bash10:15
rafawpwrak: what do you mean with "how come"?.. I am saying that "Debian uses a lot of ram" is not a good argument to discard its repo. We could build a Debian rootfs using busybox dropbear etc.. The exact same packages that OE uses for example.. And that Debian rootfs would use few RAM surely. No completely sure, but technically it sounds okey.10:15
wpwrakkshisms are also bad. particularly since they easily drift into bashisms.10:15
rafascripts should be written on JAVA10:15
wpwrakrafa: JAVA with .NET :)10:16
rafawpwrak: yeah.. and the whole Visual Everything SDK inside of the binaries10:16
wpwrakrafa: (how come) okay, that's what i was after10:17
wpwrakerror: cannot initialize OpenGL10:18
wpwrakmaybe store error message in .xls files and use libreoffice to retrieve them, too :)10:19
rafaNew release..: busybox framework for JAVA.. good for small devices with 4GB of RAM10:20
wpwraktrue.c: usage() { execl("bash", "bash", "firefox", "/usr/share/true/usage.swf");10:23
rafahaha ;-)))10:24
rafabetter use fat-static-standalone-firefox.. so it uses its own libraries inside and no from system10:25
wpwrakoh, right ! :) and put it all into a VM10:26
wpwrakwe can still make april 1st, bloatix for ben, minimum system requirement: 8 GB swap to boot :)10:27
wejpand it takes a week to boot the system :D10:28
wpwrakin console mode10:29
wejpof course10:29
wejpif you want to launch something graphical you have to wait another month :P10:29
rafadont forget single user10:29
wpwraksingle user license ;-)10:30
kyakfinally libncursesw is working13:44
kyakneed to enable uClibc locale support, libncursesw is useless without that13:45
qi-bot[commit] Juan64Bits: Revisions, Changing M12 holder. http://qi-hw.com/p/xue/d9912a814:24
larsckyak: https://dev.openwrt.org/changeset/2396614:38
kyaklarsc: thanks a lot!14:39
wpwrakkyak: rafa found something ... are you sure there's no mpeg (mp3, i suppose) codec in there ?15:07
wpwrak(url in private message, no need to log this)15:07
rafakyak: if no.. could you help to do something similar?.. I need to know some tips about how to work with stuff without stuff :)15:10
rafakristianpaul: help=help me15:10
rafakristianpaul: no!..15:10
rafakyak: help=help me15:10
kyakrafa, wpwrak i'm here15:19
kyakindeed you are right... i think i need to delete it?15:20
kyaklibmad as well as MPlayer have support for patented functionality15:20
rafakyak: is not it a "virtual" lib or something?..15:20
rafaah.. I see15:20
kyakboth libmad and mplayer15:22
kyak(though mplayer could be built without mp3 support, but this is not sexy)15:22
rafakyak: delete: I can not say anything about what is okey and what no.. I am trying to learn how to "replace" patented technologies with some stub.. or similar virtual thing15:22
Ornotermeshaha, i linked a friend a screenshot of wireshark listening to usb from a virtual machine running windows, he called black magic :P15:22
kyakrafa: can you start from scratch, gradually adding utils and libs one by one? making sure each of them is free15:24
kyakalso i'm not familiar with oe build system, but you could add some virtual package named "BUILD_PATENTED" and make patented libs dependant on this package15:25
kyakthe build system should automatically deselect packages with unresolved dependencies15:26
kyakand this will lead to other packages that depend on those libes being deselected, too15:27
rafakyak: well, maybe, but it would be a hard work better for no just one person. What I found on jlime repo is the problematic packages. Then either we remove that or we find some way fancy. I am thinking that, for example, if some package needs some lib-patented-technology package I could try to build a similar lib with empty functions or stubs.. or some idea well done. So the whole repo does not break.. But,15:27
rafawell, some applications using that lib-patented-technology would not work well surely. SO repo would be sane, but applications no :P15:27
kyakthe idea is that those apps would not be built at all15:28
rafakyak: if we remove.. we will need to remove packages which used those.. etc.. following the chain15:28
kyakyup.. this should be done automatically by the build system15:29
kyaki see a very good example of conditional depends15:32
kyakso mplayer in OE is basically "clean" if ENTERPRISE_DISTRO is not set15:32
rafakyak: ah.. that is really great it seems. Thanks! let me check further15:35
kyaki'll remove those file for now from ~/people... just in case15:35
Action: kyak sleep();15:38
kristianpaulrafa: sure what u need?15:44
rafakristianpaul: I tried to talk with kyak .. but you have a similar to many guys here ;-))15:45
rafaso I failed using TAB ;)15:45
wpwrakkyak: (removal) thanks !15:46
wpwrakkyak: (mplayer without mp3) oh, but it's still a nice player. i use it for ogg too.15:46
rafawolfspraul: morning..19:42
rafaI am uploading the repo.. I got after some work a repo without packages with patented technologies. I also removed, following the chain, the packages which need those problematic packages. SO the repo should be okey.19:44
wpwrakrafa: you mentioned some 2000 packages ... are they all because of mp3, or were there a number of unresolved dependencies already before ?19:45
rafaokey= if the package is on repo then user can install it without dependences problems19:45
wpwrak(okey) very nice ! it'll be so smooth that nobody even thinks of mp3. if people would just forget mp3 ever existed, that would be the worst defeat the patent mongers could suffer :)19:46
rafawpwrak: maybe there were some number of unresolved before.. but many of those 2000 packages were because mp*. BUt also.. there are a lot of very similar packages.. similar= for example:19:48
rafabalsa had unresolved dependencies.. but similar packages as well:19:48
wpwrakaah, i see19:49
wpwrakokay okay ;-)19:49
rafaa lot more19:49
rafathat is why the 2000 number19:49
wpwrakso maybe 100 real pakcages ? hopefully not too many popular packages among them19:52
wpwraki guess someone should examine the libraries that directly depend on libmad to see if they could be built without libman and still be useful19:53
rafawpwrak: nautilus is on that list19:57
wpwrakokay, that one really shouldn't REQUIRE libmad :)19:58
rafasome of them: batmand (?) cellhunter davfs2 duke3d evince evopedia ffalarms file-roller flumotion frameworkd (from openmoko?) freeciv freedroin freedoom frozen-bubble20:00
wpwraksome things have the strangest dependencies ;-) evince ! for audio-books ? :)20:01
rafaothers: fso-* gallery gemdropx, some gnome-*, gparted (why?, poor gparted) grdesktop, some gpe-*, gst-* gstreamer* gthumb20:01
wpwrakmaybe for some warning sounds20:02
wpwraksomeone should call for a jihad, much as it was done for GIF. then people would stop using mp3 just because it's the first thing they can think of20:03
wpwrakwell, the mp3 patents won't be with us for all that much longer, so it may already be a bit late for this.20:04
rafamore: gtkmm gvsd-* hsetroot, a lot of lib*, matchbox2 :(, midori, nautilus, openmoko-*, pidgin, paroli-*, pulseaudio, some python-*, qtnx, some qt4-*, scummvm, shr-*, sugar, supertux, toppler, wxwidgets20:04
rafathat is the main list.20:05
wpwrakwxwidgets ;-) oh dear20:05
wpwraklots of them look as if it would be easy to clean them up. someone at the OE level, others at the program level.20:06
wpwrakwe need a duty heckler who goes after those things, finds out who can fix them, then contacts them, explains the situation, and convinces them to act on it20:07
rafaom-maps-buenos-aires: saved ;-)20:09
wpwrak(duty heckler) ah well, that's for another time. it's already great what you've achieved so far. jlime may well be "cleaner" than openwrt now :)20:11
wpwrak(om-maps) i wonder if they're getting updated ...20:11
rafaom-maps: I have no idea20:13
rafawpwrak: you mean that maybe those maps are from 1810? :)20:14
wpwrakrafa: about the scrubbing process: if, say, tomorrow someone came up with a patent on, say, libgtk2.0, how hard would it be to drop everything that uses libgtk2.0 ?20:14
rafawpwrak: om-maps-buenos-aires.. maybe it says: "Buenos Aires, Spain"20:14
wpwrakrafa: (1810) hmm, i guess they would be if they were sponsored by the government ...20:14
wpwrakrafa: (1810) naw, just the day after it stopped being spanish :)20:15
rafawpwrak: I ran a few sed+grep+friends to understand how to work.. for me it were around 3 commands getting differnt kind of stuff from expressions.. Then I got the next link of the chain.. then I continued doing the same to go to the next link.. I did that manually 6 times. There the output from 6 was part of the output from 5th so there were no new packages to add to the "list_to_remove".. So now I understood a bit better how to automate that. If someone20:19
rafacame up with a patent on .. libgtk2.0.. maybe I have a script to decide what to do :)20:19
wpwrakyes, automation would be good. that way, also future updates from "complete" jlime would be no problem20:20
rafayep, exactly20:21
rafaah.. gdb is there on repo, great.. Good that it does not need libmad and duke3d :P20:23
wpwrakgdb --nostartup-sound ;-)20:24
qi-bot[commit] Werner Almesberger: atrf-txrx can now run a shell command while emitting a test wave http://qi-hw.com/p/ben-wpan/22288a221:42
qi-bot[commit] Werner Almesberger: fw/atusb/atusb.c: make the LED flash 1/4 the previous time in test mode http://qi-hw.com/p/ben-wpan/000c08721:42
kristianpaulwpwrak: btw is your USRP config described somwhere?21:49
wpwrakkristianpaul: it's a USRP2 with the XCVR2450. you can see them here: http://www.ettus.com/order21:52
wpwrakkristianpaul: (note that the daughter board "catalog" doesn't describe the xcvr2450 quite accurately. it makes it sound as if it could operate full-duplex but it can't. threw a bit of a spanner in my gears :-( )21:54
kristianpaulwpwrak: you asked for refunf to ettus?21:56
wpwraknaw. i can still use it. just need to change my test setup.21:57
kristianpaulah good :)21:58
--- Fri Nov 12 201000:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!