2010-11-11 00:48 <qi-bot> [commit] Werner Almesberger: atspi-rssid: for color and geometry, use #defines instead of literals http://qi-hw.com/p/ben-wpan/256da91
2010-11-11 00:48 <qi-bot> [commit] Werner Almesberger: atusb/: connect TST to P0_7 (rework of existing boards) http://qi-hw.com/p/ben-wpan/c45f1bb
2010-11-11 00:48 <qi-bot> [commit] Werner Almesberger: atusd firmware now supports setting the TST pin. http://qi-hw.com/p/ben-wpan/2337557
2010-11-11 00:48 <qi-bot> [commit] Werner Almesberger: libatspi: new function atspi_test_mode to enter test mode http://qi-hw.com/p/ben-wpan/5d63a00
2010-11-11 00:48 <qi-bot> [commit] Werner Almesberger: atspi-txrx: option -T <delta_MHz> to emit a constant wave http://qi-hw.com/p/ben-wpan/d4fe027
2010-11-11 00:48 <qi-bot> [commit] Werner Almesberger: atspi-txrx: new option -f to set the channel by frequency http://qi-hw.com/p/ben-wpan/1e78135
2010-11-11 05:23 <wpwrak> rafa: 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.
2010-11-11 05:25 <wpwrak> rafa: 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.
2010-11-11 05:27 <wpwrak> 2) 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.
2010-11-11 05:30 <wpwrak> 3) 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).
2010-11-11 05:30 <wpwrak> that's the three issues i can think of at the moment
2010-11-11 05:31 <wpwrak> 1) 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.
2010-11-11 05:33 <wpwrak> 2) 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.
2010-11-11 05:34 <wpwrak> he 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 :-)
2010-11-11 05:36 <wpwrak> rafa: 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.
2010-11-11 05:37 <wpwrak> maybe 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"
2010-11-11 05:39 <wpwrak> the 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.
2010-11-11 05:39 <wpwrak> s/purning/pruning/
2010-11-11 05:41 <wpwrak> for 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.
2010-11-11 05:43 <wpwrak> if 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.
2010-11-11 05:44 <wpwrak> so if OE/opkg has something like this, that may be a nice and clean solution.
2010-11-11 05:45 <wpwrak> there'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 ?
2010-11-11 05:47 <wpwrak> i 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.
2010-11-11 05:48 <wpwrak> rafa: 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 on
2010-11-11 05:48 <wpwrak> how does this sound ?
2010-11-11 05:49 <wpwrak> (now .. what shall i do until rafa wakes up .... :)
2010-11-11 05:51 <wolfspraul> wpwrak: sleep?
2010-11-11 05:52 <wpwrak> wolfspraul: just got up :)
2010-11-11 05:55 <wpwrak> wolfspraul: if you remember anything from OM's attempts to bring patent (in)sanity to OE, that might be useful
2010-11-11 05:55 <wolfspraul> no not really. back then we just tried to get mp3 out, but never succeeded.
2010-11-11 05:56 <wolfspraul> even though the message was clear, everybody knew it, everybody knew the priority
2010-11-11 05:56 <wpwrak> can you be more specific ? what was tried and how did it not succeed ?
2010-11-11 05:56 <wolfspraul> I don't know.
2010-11-11 05:56 <wolfspraul> I only know you could still play mp3 :-)
2010-11-11 05:57 <wpwrak> urgh
2010-11-11 05:57 <wpwrak> how did you find out you could still play mp3 ?
2010-11-11 05:57 <wolfspraul> I 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.
2010-11-11 05:57 <wolfspraul> the player was in the rootfs :-)
2010-11-11 05:58 <wpwrak> okay. i agree with your point :)
2010-11-11 05:59 <wpwrak> sounds a is OM's lack of success with this undertaking had more to do with ineptitude than anything else :)
2010-11-11 05:59 <wpwrak> s/a is/as if/
2010-11-11 05:59 <wolfspraul> well with that many people, the problem is more of a high level problem first
2010-11-11 06:00 <wolfspraul> does everybody (who needs to) understand the problem
2010-11-11 06:00 <wolfspraul> do they understand the priority of the problem
2010-11-11 06:00 <wolfspraul> do they agree on one common way to solve the problem
2010-11-11 06:00 <wolfspraul> and finally - can they pull off the solution as a team
2010-11-11 06:00 <wolfspraul> maybe all of those failed, I don't know...
2010-11-11 06:01 <wolfspraul> just technically, it's clear though that removing something like MP3 is not trivial in OE
2010-11-11 06:02 <wolfspraul> but it sounds like we are quite far, so let's see. almost there maybe/hopefully!
2010-11-11 06:05 <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 ...
2010-11-11 06:06 <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.
2010-11-11 06:16 <wpwrak> ah, i know. i could do a Great Renaming :-)
2010-11-11 07:08 <rafa> wpwrak: 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 :
2010-11-11 07:08 <rafa> "I have tried for the last 10 days to build pyth..plot and I have problems with 100 librarires missed"
2010-11-11 07:09 <rafa> "I have tried the last week to build a fancy editor..." .. Things like that.
2010-11-11 07:10 <wpwrak> good morning ! :)
2010-11-11 07:11 <wpwrak> (finish the upload) yup, that's good. finish one thing, then do the next. i should do that more often, too ;-)
2010-11-11 07:11 <rafa> wolfspraul: 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.
2010-11-11 07:12 <wpwrak> (messy dependencies) well, we can call it a "beta" with some unresolved dependencies not fully cleaned up yet ;-)
2010-11-11 07:12 <rafa> but this example or=but on this example either
2010-11-11 07:14 <rafa> If 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)
2010-11-11 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 ;-)
2010-11-11 07:16 <kyak> openwrt does support a bunch of patented things, but it won't build unless you explicitely allow them by setting CONFIG_BUILD_PATENTED
2010-11-11 07:18 <kyak> and 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 process
2010-11-11 07:18 <kyak> other than throwing away libraries and breaking things in OE
2010-11-11 07:18 <wpwrak> rafa: does OE have alternative choices ? e.g., my vi/joe/emacs example ?
2010-11-11 07:19 <wpwrak> rafa: also, does OE have build variants of the same (source) package ? e.g., emacs vs emacs-x11 ?
2010-11-11 07:20 <rafa> wpwrak: 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 kn
2010-11-11 07:21 <wpwrak> kyak: 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.
2010-11-11 07:21 <wpwrak> kyak: this could even be a useful tool for checking the integrity of repositories that supposedly contain "everything"
2010-11-11 07:21 <rafa> kyak: 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 package
2010-11-11 07:22 <rafa> wpwrak: what do you mean with "alternative choices" (vi/joe/emacs)?
2010-11-11 07:22 <wpwrak> rafa: your message was cut as "The system should k|"
2010-11-11 07:22 <wpwrak> s/as/at/
2010-11-11 07:23 <rafa> wpwrak: "The system should k|"= "The system should know if those packages could be built or not"
2010-11-11 07:23 <wpwrak> rafa: (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)
2010-11-11 07:24 <wpwrak> rafa: another example could be bison vs. berkeley-yacc. both provide a "yacc"
2010-11-11 07:25 <wpwrak> rafa: (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.
2010-11-11 07:26 <wpwrak> rafa: (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.
2010-11-11 07:27 <wpwrak> rafa: 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.
2010-11-11 07:27 <wpwrak> rafa: 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.
2010-11-11 07:28 <rafa> wpwrak: (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 accomplish
2010-11-11 07:28 <wpwrak> rafa: 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.
2010-11-11 07:29 <wpwrak> rafa: (continuing step 2) sorry, that's lib-with-E and lib-without-E
2010-11-11 07:30 <wpwrak> rafa: (cont) so the applications that don't need E would simply depend on lib-without-E and everyone is happy
2010-11-11 07:30 <wpwrak> rafa: (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 ;-)
2010-11-11 07:31 <wpwrak> rafa: (many combinations) in reality, the relevant number will probably be small, though. maybe just patents/no-patents. also, such things could be automated.
2010-11-11 07:32 <rafa> wpwrak: 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..
2010-11-11 07:32 <wpwrak> step 2 would be to split the library into variants. step 3 would be to adjust the dependencies in the users of the library
2010-11-11 07:32 <rafa> wpwrak: The program P just uses Z.
2010-11-11 07:34 <wpwrak> in this case, and if there is no other mechanism, you wold have to tell P which variant of Z he can use
2010-11-11 07:34 <wpwrak> i don't know if OE has other mechanisms, though
2010-11-11 07:34 <rafa> wpwrak: 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?
2010-11-11 07:34 <wpwrak> for example, gentoo has flags for general capabilities
2010-11-11 07:35 <wpwrak> so you could say, for example, that you have opengl hardware, and then it would enable opengl support in all the packages
2010-11-11 07:36 <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 chain
2010-11-11 07:36 <wpwrak> that is, unless you have an alternative mechanism, like the one in gentoo
2010-11-11 07:36 <rafa> wpwrak: 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.
2010-11-11 07:36 <wpwrak> you could of course just make the relevant members of the chain depend on license-foo
2010-11-11 07:37 <rafa> wpwrak: and that is why I would like to use Debian on everything.. Just that the packages are made for PC or similar powerful devices.
2010-11-11 07:37 <wpwrak> how do the other jlime members like the debian idea ? :)
2010-11-11 07:40 <rafa> wpwrak: 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+ files
2010-11-11 07: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.
2010-11-11 07:41 <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 ?
2010-11-11 07:42 <wpwrak> (what form) form of the feature, not form of the welcome :-) ("sure, we're already cooking the pot of tar to welcome you ...")
2010-11-11 07:43 <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)
2010-11-11 07:44 <rafa> wpwrak: 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 :)
2010-11-11 07:45 <rafa> But Fedora does not support all the archs which Debian does well
2010-11-11 07: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 not
2010-11-11 07:47 <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"
2010-11-11 07:48 <rafa> wpwrak: 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 system
2010-11-11 07:48 <wpwrak> (debian) hmm, so we should win one of the debian gods over
2010-11-11 07:49 <wpwrak> libmanga-brutal-underage ;-) perfectly legal in japan, of course ;-)
2010-11-11 07:51 <rafa> wpwrak: 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?
2010-11-11 07:51 <wpwrak> pheew. so .. what's the plan then ? :)
2010-11-11 07:52 <wpwrak> i think it's all manual
2010-11-11 07:52 <rafa> libmanga ;-))))
2010-11-11 07:52 <wpwrak> when 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.
2010-11-11 07:53 <wpwrak> not sure what it does about dependencies of the kind you desribed. probably just build something that doesn't quite work ;)
2010-11-11 07:53 <rafa> wpwrak: and does the people know that CONFIG_PATENTED?
2010-11-11 07:53 <wpwrak> but that's okay, you can always refine things later. no need to make something mega-complex just to handle every last corner case.
2010-11-11 07:54 <wpwrak> (do they know it) i guess it sinks in after the first public flogging ;-)
2010-11-11 07:55 <wpwrak> naw, 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.
2010-11-11 07:55 <wpwrak> it's not really all that hard once you've made the initial preparations. what's painful is to get there from zero.
2010-11-11 07:55 <rafa> wpwrak: 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 ;)
2010-11-11 07:56 <wpwrak> excellent
2010-11-11 07:57 <wpwrak> we 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.
2010-11-11 07:58 <rafa> wpwrak: OE: maybe they already solved that well and we are talking without sense :P
2010-11-11 07:59 <wpwrak> that's actually how it *should* be ;-)
2010-11-11 08:09 <kyak> larsc: 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..
2010-11-11 08:09 <kyak> ..from previous build get removed.
2010-11-11 08:10 <kyak> pretty important though small fix, which would help a lot..
2010-11-11 08:11 <larsc> is ncursesw part of backfire?
2010-11-11 08:11 <kyak> nope, but i'm trying to build it from openwrt-packages
2010-11-11 08:12 <kyak> (i guess this change is helpfull not only for libncursesw)
2010-11-11 08:26 <kyak> larsc: so what do you think?
2010-11-11 08:39 <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/7e71f98
2010-11-11 08:39 <qi-bot> [commit] Werner Almesberger: The Great ATSPI Renaming, part 2: rename ATSPI_* identifiers to ATUSB_* http://qi-hw.com/p/ben-wpan/96b6a50
2010-11-11 08: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/84b61f3
2010-11-11 08: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/cf23ac6
2010-11-11 08: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/688df97
2010-11-11 08: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/bcd3691
2010-11-11 08: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/2873174
2010-11-11 08: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/6ee5142
2010-11-11 08:39 <qi-bot> [commit] Werner Almesberger: The Great ATSPI Renaming, part 9: update comments as well http://qi-hw.com/p/ben-wpan/a8a898e
2010-11-11 08:39 <qi-bot> [commit] Werner Almesberger: lib/atusb.c: fix typo in function name http://qi-hw.com/p/ben-wpan/8093112
2010-11-11 08: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/4d7cb12
2010-11-11 08:40 <wpwrak> phew. that one's been haunting me for a good while
2010-11-11 08:46 <wpwrak> xiangfu: do you know what position Jan Luebbe has in the debian hierarchy ?
2010-11-11 08:58 <qi-bot> [commit] Werner Almesberger: The Great ATSPI Renaming, part 10: more title comment fixes http://qi-hw.com/p/ben-wpan/d1953cd
2010-11-11 08: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/7f9488e
2010-11-11 08:58 <qi-bot> [commit] Werner Almesberger: Various items in CNTR referred to ATSPI/atspi http://qi-hw.com/p/ben-wpan/b2049e7
2010-11-11 09:05 <xiangfu> wpwrak: I don't know. maybe ask Wolfgang.
2010-11-11 09:06 <wolfspraul> I don't know either.
2010-11-11 09:12 <wpwrak> hmm. well, we can always ping him and see where this leads
2010-11-11 09:12 <wpwrak> wolfspraul: i guess you'd be happier with debian than with OE ? :)
2010-11-11 09:13 <wolfspraul> on the NanoNote?
2010-11-11 09:13 <wolfspraul> too little memory
2010-11-11 09:13 <wolfspraul> Fedora was interested to support it, they just lowered their minimum memory requirement from 128 to 64
2010-11-11 09:13 <wolfspraul> but they will stay away from 32mb platforms
2010-11-11 09:14 <wolfspraul> openwrt 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...
2010-11-11 09:14 <wolfspraul> oe always was kind of in the middle, say for 32 or 64 it should be fine?
2010-11-11 09:14 <wolfspraul> so am I happier with Debian than with OE (on the NN) - no
2010-11-11 09:17 <wpwrak> well, the basic assumption is that there would be work on debian to make it happy with a smaller memory footprint
2010-11-11 09:17 <wolfspraul> not sure
2010-11-11 09:17 <wolfspraul> this doesn't sound like a good plan to me
2010-11-11 09:17 <wolfspraul> nobody will join the effort
2010-11-11 09:17 <wpwrak> the sources are the same, so there's nothing that would fundamentally prevent debian from running on small systems
2010-11-11 09:17 <wolfspraul> maybe start with Debian 2.1? :-)
2010-11-11 09:18 <wolfspraul> ah well, projects have a focus
2010-11-11 09:18 <wolfspraul> memory is going up
2010-11-11 09:18 <wolfspraul> any decent android phone has how much now? 512mb? more?
2010-11-11 09:18 <wolfspraul> don't fight mother nature
2010-11-11 09:18 <wpwrak> yeah :) 1 GB is the new 640 kB ;-)
2010-11-11 09:18 <wpwrak> people are even doing crazy reworks on the ben ;-)
2010-11-11 09:18 <wolfspraul> debian on a 32mb system is off-chart
2010-11-11 09:19 <wolfspraul> so it's great that we got it working, and I hope the port stays alive
2010-11-11 09:19 <wolfspraul> but I doubt we get enough mindshare about Debian folks for our problems once they discover we are targeting a 32mb system
2010-11-11 09:20 <wolfspraul> I meant 'among Debian folks'
2010-11-11 09:20 <wpwrak> let me rephrase the question: if its size requirements were compatible with the ben, would you like it better than OE ?
2010-11-11 09:20 <wolfspraul> yes
2010-11-11 09:20 <wolfspraul> I see Debian as a 'distro'
2010-11-11 09:21 <wolfspraul> not as a tool to create custom/optimized images
2010-11-11 09:21 <wolfspraul> (that's how I see OpenWrt)
2010-11-11 09:21 <wpwrak> whether 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 ?
2010-11-11 09:21 <wolfspraul> and from what I know about OE, I would say the result of OE is also a distro
2010-11-11 09:21 <wolfspraul> at least it's so hard to build that I have rarely seen someone touting it as a great tool to make customized images
2010-11-11 09:21 <wpwrak> OE is even a meta-distro ;-)
2010-11-11 09:21 <wolfspraul> fine
2010-11-11 09:21 <wolfspraul> :-)
2010-11-11 09:22 <wolfspraul> so yes, if I have enough memory, I would 100% want Debian or Fedora
2010-11-11 09:22 <wpwrak> hmm, except for openmoko, you mean ;-)
2010-11-11 09:22 <wpwrak> (customized images)
2010-11-11 09:22 <wolfspraul> I don't know why those decisions were made, it was way before me.
2010-11-11 09:23 <wpwrak> regarding 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.
2010-11-11 09:23 <wolfspraul> Debian also includes MP3,I think
2010-11-11 09:23 <wolfspraul> and I doubt it's a flexible enough tool to remove such stuff easily
2010-11-11 09:23 <wpwrak> given the general political background of debian, they should at least be sympathetic to the cause :)
2010-11-11 09:23 <wolfspraul> especially not if some new nonsense patent comes up, but we need to react and do some surgery
2010-11-11 09:24 <wolfspraul> ok but I don't want to be in 5 years of lobbying during which I cannot sell my stuff
2010-11-11 09:24 <wpwrak> sure. needs to get fixed first. much like the memory footprint.
2010-11-11 09:24 <wolfspraul> I think fedora is getting more aggressive on the patents now
2010-11-11 09:25 <wolfspraul> did I read this somewhere? I forgot...
2010-11-11 09:25 <wolfspraul> are they even removing mp3 now?
2010-11-11 09:25 <wpwrak> right now, we have openwrt. very soon we have jlime. let's save the colonialization of debian for the next year ;-)
2010-11-11 09:25 <wolfspraul> it's already there, and I hope nebajoth will keep it alive :-)
2010-11-11 09:26 <wpwrak> maybe in their "forbidden things" like ?
2010-11-11 09:26 <wolfspraul> he will, I'm sure, just a little later
2010-11-11 09:26 <wpwrak> (debian) well, make it a first-class citizen of qi-hw, like openwrt and jlime.
2010-11-11 09:27 <wolfspraul> biggest stopper (maybe only one?) is patents as well
2010-11-11 09:27 <wolfspraul> first nebajoth needs to come live again, which I'm sure he will at some point
2010-11-11 09:27 <wpwrak> patents, memory footprint, probably usability
2010-11-11 09:27 <wolfspraul> well debian works today
2010-11-11 09:27 <wolfspraul> of course you need things like swapfile on sd card :-)
2010-11-11 09:27 <wpwrak> wolfspraul: the more we mention the name of nebajoth, the more likely it is, nebajoth will notice and become alive ;-)
2010-11-11 09:29 <wolfspraul> wpwrak: btw, I think there was a gentoo for nanonote effort too at some point
2010-11-11 09:29 <wolfspraul> not sure what happened to it
2010-11-11 09:29 <wolfspraul> max poseidon in belarus did it? forgot...
2010-11-11 09:30 <wolfspraul> and fedora would have almost started, but the 32mb was a blocked and they didn't want to start on the dev-only avt2 board
2010-11-11 09:30 <wolfspraul> was a blocker
2010-11-11 09:31 <wpwrak> hmm, pity
2010-11-11 09:31 <wolfspraul> wpwrak: gbraad is our Fedora guy here :-)
2010-11-11 09:32 <wpwrak> so, 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 ?
2010-11-11 09:33 <wpwrak> rafa: same question for OE/jlime :)
2010-11-11 09:33 <wolfspraul> but it seems Fedora, in the form of Fedora Electronic Lab, is getting behind Milkymist in a big way (as a dev environment)
2010-11-11 09:33 <wolfspraul> so there could be some marriage later on...
2010-11-11 09:34 <wolfspraul> I believe openwrt started on 2mb systems
2010-11-11 09:34 <wolfspraul> 2mb memory
2010-11-11 09:34 <wolfspraul> or maybe 4?
2010-11-11 09:34 <wolfspraul> anyway around there
2010-11-11 09:34 <wolfspraul> that's all I know, not how they did it...
2010-11-11 09:34 <wejp> it started on a 4 MB system, but there are trimmed down version for systems with only 2 MB
2010-11-11 09:35 <wolfspraul> wejp: ah great, thanks
2010-11-11 09:35 <wolfspraul> how about the backfire release? still runs on 4 mb systems?
2010-11-11 09:36 <wejp> yes, it does, it still runs on the original WRT54G (which is the device openwrt got its name from)
2010-11-11 09:36 <wejp> that one has 4 MB flash and 16 MB RAM
2010-11-11 09:36 <wolfspraul> wejp: is 16 mb RAM the lowest in memory backfire supports? (off the top of your mind)
2010-11-11 09:37 <wejp> not sure, but even if it runs with 8 MB, it would be of very little use
2010-11-11 09:37 <wpwrak> wejp: so where's the magic ? just switch to uclibc ? heavily customized packages ? just don't install the big ones (that's cheating, but .. :)
2010-11-11 09:37 <wolfspraul> ok got it
2010-11-11 09:37 <wejp> basically it is that. uclibc saves lots of memory compared to glibc
2010-11-11 09:38 <wolfspraul> my point is still valid - 32 mb memory is a very nice system for openwrt :-)
2010-11-11 09:38 <wpwrak> wolfspraul: dreaming of linux-2.6.42/arch/8051-nommu/ ? ;-)
2010-11-11 09:38 <wolfspraul> (I mixed up memory and nand size earlier)
2010-11-11 09:38 <wejp> also 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)
2010-11-11 09:39 <wejp> oh, 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 MB
2010-11-11 09:39 <wpwrak> my first linux system had 4 MB of RAM ... later needed to upgrade to 8 MB for X, though. damn bloatware :)
2010-11-11 09:40 <wejp> hehe, one can even run X with 4 MB only
2010-11-11 09:40 <wejp> without swap that is!
2010-11-11 09:40 <wejp> but you can't do much else then ;)
2010-11-11 09:40 <wpwrak> wejp: (uclibc) does openwrt need a lot of patches to work with uclibc ? or do applications usually not notice / already come uclibc-ready ?
2010-11-11 09:41 <wejp> many applications just need to be compiled against uclibc and run just fine, there are a few incompatibilities with glibc though
2010-11-11 09:41 <wejp> but most applications run fine without patches as far as i can tell
2010-11-11 09:43 <wejp> i 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 using
2010-11-11 09:43 <wolfspraul> wpwrak: for the oe decision at om. remember gta01 had 64mb memory.
2010-11-11 09:43 <wolfspraul> at that time openwrt hardly had any gui packages, I don't think openwrt would have looked like any reasonable option at that time.
2010-11-11 09:44 <wolfspraul> and with 64mb, debian and fedora were not really possible either
2010-11-11 09:44 <wolfspraul> so it came down to only oe
2010-11-11 09:44 <wolfspraul> with the gta02, of course memory would have been enough for debian or fedora already
2010-11-11 09:44 <wolfspraul> meanwhile openwrt started to pickup more and more gui apps
2010-11-11 09:44 <wpwrak> wejp: kewl. so perhaps a debian wouldn't be too traumatic once someone figures out how to make it use uclibc
2010-11-11 09:45 <wolfspraul> just my recollections, others may have observed things differently...
2010-11-11 09:45 <wpwrak> wejp: or make eglibc drop some fat :) eglibc is supposedly already a huge improvement over glibc.
2010-11-11 09:45 <wejp> wpwark, 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 memory
2010-11-11 09:45 <wejp> you need to have swap to use it, which i really don't like
2010-11-11 09:45 <wpwrak> wolfspraul: (oe at om) and let's not forget that mickey is a zaurus/oe veteran ;-)
2010-11-11 09:46 <wejp> ipkg/opkg uses a lot less memory
2010-11-11 09:46 <wpwrak> wejp: couldn't you use just opkg to install those debian packages ?
2010-11-11 09:47 <wejp> not sure. ipkg is quite similar to dpkg, but not identical
2010-11-11 09:47 <wpwrak> wejp: rafa did some work on making opkg (right ?) behave even better
2010-11-11 09:48 <wpwrak> well, i'd file the package installer under "minor problems" :) the problem per se isn't exactly "NP = P ?"
2010-11-11 09:48 <wejp> hehe, 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 distro
2010-11-11 09:49 <wejp> and 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 it
2010-11-11 09:49 <wpwrak> that's true. but an inefficient package manager sound fixable. particularly in the debian universe where there are already several partially compatible package managers :)
2010-11-11 09:50 <wpwrak> yup, the insane memory demands are a known issue. and already a partially fixed one.
2010-11-11 09:50 <wejp> maybe it is fixable. question is if it is worth the effort
2010-11-11 09:50 <wejp> okay
2010-11-11 09:50 <wpwrak> the 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 installer
2010-11-11 09:51 <wpwrak> but i'm sure that can be dealt with, too
2010-11-11 09:51 <wejp> when going through all that, what woulbd be the advantage over openwrt in the end?
2010-11-11 09:53 <wpwrak> what 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.
2010-11-11 09:53 <wpwrak> (advantage) LOTS of packages :)
2010-11-11 09:53 <wejp> ok, but you have to compile every single one of them
2010-11-11 09:54 <wpwrak> i view the ben as basically a PC
2010-11-11 09:54 <wejp> you cannot just use the mips debian packages
2010-11-11 09:54 <wpwrak> we have computers for that ;-)
2010-11-11 09:54 <wejp> ;)
2010-11-11 09:56 <wejp> for my taste debian is much too bloated, but having another option for a operating system is nice of course
2010-11-11 09:56 <wpwrak> (build everything) and let's not forget gentoo, where every single user does the whole rebuiling each time something changes :)
2010-11-11 09:56 <rafa> wpwrak: jlime uses eglibc.
2010-11-11 09:57 <wpwrak> rafa: and you're happy with its size ?
2010-11-11 09:58 <wejp> oh and another important aspect of openwrt is busybox of course. that saves a lot of space on the flash as well as memory in RAM
2010-11-11 09:58 <wpwrak> wejp: sigh. busybox does save space. but at what a horrible price ... :-(
2010-11-11 09:59 <wpwrak> i've grown quite a hatred for busybox over the years. busybox and dropbear.
2010-11-11 09:59 <wejp> i don't think it is such a horrible price, and i think it is quite an accomplishment what the busybox guys have achieved
2010-11-11 10:00 <wejp> why is that? what do you hate about those so much?
2010-11-11 10:00 <wpwrak> the price is that you can't trust any scripts to work. there are countless subtle incompatibilities
2010-11-11 10:00 <wejp> besides, with only 4 or even 8 MB flash which is very common with routers, you don't have much of a choice there
2010-11-11 10:00 <wejp> scripts only fail if you rely on bash functions
2010-11-11 10:00 <wpwrak> yes, i understand the point for extreme low-memory systems
2010-11-11 10:01 <wpwrak> there you'
2010-11-11 10:01 <wejp> if you stick with sh you should not run into bigger problems
2010-11-11 10:01 <wpwrak> re heavily customizing anyway. so then it's okay if you have to work around incompatibilities.
2010-11-11 10:01 <wpwrak> /bin/echo >/dev/full
2010-11-11 10:01 <wejp> :o
2010-11-11 10:01 <wpwrak> just to name a recent discovery :)
2010-11-11 10:02 <wejp> what's that supposed to do?
2010-11-11 10:03 <wpwrak> expected: /bin/echo: write error: No space left on device
2010-11-11 10:04 <wpwrak> a correct shell would also do the same for just  echo >/dev/full
2010-11-11 10:04 <wpwrak> (with echo usually being a built-in)
2010-11-11 10:06 <wpwrak> particularly 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.
2010-11-11 10:06 <rafa> wpwrak: size is okey. bootstrap is just 8MB I would say
2010-11-11 10:06 <wpwrak> and of course, you'll still miss things, which come to haunt you later
2010-11-11 10:07 <rafa> wpwrak: 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).
2010-11-11 10:07 <wpwrak> so 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.
2010-11-11 10:07 <rafa> wpwrak: 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 RAM
2010-11-11 10:08 <rafa> wpwrak: 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.
2010-11-11 10:08 <wpwrak> rafa: (8 MB) okay, not quite down to uclibc levels, but not too obese either. hopefully it stays that way :)
2010-11-11 10:09 <wpwrak> rafa: (a lot of RAM for debian) how come ?
2010-11-11 10:11 <wejp> even bash alone uses more than 1.5 MB of RAM which is a lot for a machine with only 32 MB
2010-11-11 10:11 <rafa> wejp: if I build a rootfs using Debian repo which does not have but busybox
2010-11-11 10:12 <wpwrak> wejp: 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 ;-)
2010-11-11 10:13 <wpwrak> wejp: (bash) yeah, bash is a bit of a pig. i wholeheartedly recommend staying away form bashims wherever possible.
2010-11-11 10:13 <wejp> wpwrak, 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 change
2010-11-11 10:13 <wejp> wpwrak, which shell do you recommend?
2010-11-11 10:13 <wpwrak> wejp: yan to the rescue ! ;-)
2010-11-11 10:14 <wpwrak> s/yan/ya/
2010-11-11 10:14 <wejp> hehe, yeah, more RAM and USB host are the most important features :)
2010-11-11 10:14 <wpwrak> wejp: oh, i basically still use bash everywhere. but i try to write my scripts such that they don't require bash.
2010-11-11 10:15 <wpwrak> aye. and a bit of RF, and we have a nice package :)
2010-11-11 10:15 <wejp> yeah, shell scripts should avoid relying on bash
2010-11-11 10:15 <rafa> wpwrak: 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.
2010-11-11 10:15 <wpwrak> kshisms are also bad. particularly since they easily drift into bashisms.
2010-11-11 10:15 <rafa> scripts should be written on JAVA
2010-11-11 10:15 <wejp> lol
2010-11-11 10:15 <rafa> :D
2010-11-11 10:16 <wpwrak> rafa: JAVA with .NET :)
2010-11-11 10:16 <rafa> wpwrak: yeah.. and the whole Visual Everything SDK inside of the binaries
2010-11-11 10:17 <wpwrak> rafa: (how come) okay, that's what i was after
2010-11-11 10:17 <wpwrak> /bin/true
2010-11-11 10:18 <wpwrak> error: cannot initialize OpenGL
2010-11-11 10:18 <rafa> :D
2010-11-11 10:19 <rafa> /bin/yes
2010-11-11 10:19 <wpwrak> maybe store error message in .xls files and use libreoffice to retrieve them, too :)
2010-11-11 10:20 <rafa> New release..: busybox framework for JAVA.. good for small devices with 4GB of RAM
2010-11-11 10:21 <wejp> :D
2010-11-11 10:23 <wpwrak> true.c: usage() { execl("bash", "bash", "firefox", "/usr/share/true/usage.swf");
2010-11-11 10:24 <rafa> haha ;-)))
2010-11-11 10:25 <rafa> better use fat-static-standalone-firefox.. so it uses its own libraries inside and no from system
2010-11-11 10:26 <wpwrak> oh, right ! :) and put it all into a VM
2010-11-11 10:27 <wpwrak> we can still make april 1st, bloatix for ben, minimum system requirement: 8 GB swap to boot :)
2010-11-11 10:28 <wejp> haha
2010-11-11 10:28 <wejp> and it takes a week to boot the system :D
2010-11-11 10:29 <wpwrak> in console mode
2010-11-11 10:29 <wejp> of course
2010-11-11 10:29 <wejp> if you want to launch something graphical you have to wait another month :P
2010-11-11 10:29 <rafa> dont forget single user
2010-11-11 10:30 <wpwrak> single user license ;-)
2010-11-11 13:44 <kyak> finally libncursesw is working
2010-11-11 13:45 <kyak> need to enable uClibc locale support, libncursesw is useless without that
2010-11-11 14:24 <qi-bot> [commit] Juan64Bits: Revisions, Changing M12 holder. http://qi-hw.com/p/xue/d9912a8
2010-11-11 14:38 <larsc> kyak: https://dev.openwrt.org/changeset/23966
2010-11-11 14:39 <kyak> larsc: thanks a lot!
2010-11-11 15:07 <wpwrak> kyak: rafa found something ... are you sure there's no mpeg (mp3, i suppose) codec in there ?
2010-11-11 15:07 <wpwrak> (url in private message, no need to log this)
2010-11-11 15:10 <rafa> kyak: if no.. could you help to do something similar?.. I need to know some tips about how to work with stuff without stuff :)
2010-11-11 15:10 <rafa> kristianpaul: help=help me
2010-11-11 15:10 <rafa> kristianpaul: no!..
2010-11-11 15:10 <rafa> kyak: help=help me
2010-11-11 15:19 <kyak> rafa, wpwrak i'm here
2010-11-11 15:20 <kyak> indeed you are right... i think i need to delete it?
2010-11-11 15:20 <kyak> libmad as well as MPlayer have support for patented functionality
2010-11-11 15:20 <rafa> kyak: is not it a "virtual" lib or something?..
2010-11-11 15:20 <rafa> ah.. I see
2010-11-11 15:22 <kyak> DEPENDS:=@BUILD_PATENTED
2010-11-11 15:22 <kyak> both libmad and mplayer
2010-11-11 15:22 <kyak> (though mplayer could be built without mp3 support, but this is not sexy)
2010-11-11 15:22 <rafa> kyak: 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 thing
2010-11-11 15:22 <Ornotermes> haha, i linked a friend a screenshot of wireshark listening to usb from a virtual machine running windows, he called black magic :P
2010-11-11 15:24 <kyak> rafa: can you start from scratch, gradually adding utils and libs one by one? making sure each of them is free
2010-11-11 15:25 <kyak> also 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 package
2010-11-11 15:26 <kyak> the build system should automatically deselect packages with unresolved dependencies
2010-11-11 15:27 <kyak> and this will lead to other packages that depend on those libes being deselected, too
2010-11-11 15:27 <rafa> kyak: 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,
2010-11-11 15:27 <rafa> well, some applications using that lib-patented-technology would not work well surely. SO repo would be sane, but applications no :P
2010-11-11 15:28 <kyak> the idea is that those apps would not be built at all
2010-11-11 15:28 <rafa> kyak: if we remove.. we will need to remove packages which used those.. etc.. following the chain
2010-11-11 15:29 <kyak> yup.. this should be done automatically by the build system
2010-11-11 15:32 <kyak> http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/mplayer/mplayer_0.0+1.0rc2.bb
2010-11-11 15:32 <kyak> i see a very good example of conditional depends
2010-11-11 15:32 <kyak> so mplayer in OE is basically "clean" if ENTERPRISE_DISTRO is not set
2010-11-11 15:35 <rafa> kyak: ah.. that is really great it seems. Thanks! let me check further
2010-11-11 15:35 <kyak> i'll remove those file for now from ~/people... just in case
2010-11-11 15:38 <kyak> sleep();
2010-11-11 15:44 <kristianpaul> rafa: sure what u need?
2010-11-11 15:45 <rafa> kristianpaul: I tried to talk with kyak .. but you have a similar to many guys here ;-))
2010-11-11 15:45 <rafa> so I failed using TAB ;)
2010-11-11 15:46 <wpwrak> kyak: (removal) thanks !
2010-11-11 15:46 <wpwrak> kyak: (mplayer without mp3) oh, but it's still a nice player. i use it for ogg too.
2010-11-11 19:42 <rafa> wolfspraul: morning..
2010-11-11 19:44 <rafa> I 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.
2010-11-11 19:45 <wpwrak> rafa: you mentioned some 2000 packages ... are they all because of mp3, or were there a number of unresolved dependencies already before ?
2010-11-11 19:45 <rafa> okey= if the package is on repo then user can install it without dependences problems
2010-11-11 19:46 <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 :)
2010-11-11 19:48 <rafa> wpwrak: 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:
2010-11-11 19:48 <rafa> balsa had unresolved dependencies.. but similar packages as well:
2010-11-11 19:48 <rafa> balsa-locale-am
2010-11-11 19:48 <rafa> balsa-locale-ar
2010-11-11 19:48 <rafa> balsa-locale-az
2010-11-11 19:48 <rafa> balsa-locale-be
2010-11-11 19:48 <rafa> balsa-locale-bg
2010-11-11 19:48 <rafa> balsa-locale-ca
2010-11-11 19:48 <rafa> balsa-locale-cs
2010-11-11 19:49 <rafa> balsa-locale-da
2010-11-11 19:49 <wpwrak> aah, i see
2010-11-11 19:49 <rafa> balsa-locale-de
2010-11-11 19:49 <rafa> balsa-locale-dz
2010-11-11 19:49 <wpwrak> okay okay ;-)
2010-11-11 19:49 <rafa> balsa-locale-el
2010-11-11 19:49 <rafa> ..
2010-11-11 19:49 <rafa> a lot more
2010-11-11 19:49 <rafa> that is why the 2000 number
2010-11-11 19:52 <wpwrak> so maybe 100 real pakcages ? hopefully not too many popular packages among them
2010-11-11 19:53 <wpwrak> i guess someone should examine the libraries that directly depend on libmad to see if they could be built without libman and still be useful
2010-11-11 19:57 <rafa> wpwrak: nautilus is on that list
2010-11-11 19:58 <wpwrak> okay, that one really shouldn't REQUIRE libmad :)
2010-11-11 20:00 <rafa> some of them: batmand (?) cellhunter davfs2 duke3d evince evopedia ffalarms file-roller flumotion frameworkd (from openmoko?) freeciv freedroin freedoom frozen-bubble
2010-11-11 20:01 <wpwrak> some things have the strangest dependencies ;-) evince ! for audio-books ? :)
2010-11-11 20:01 <rafa> others: fso-* gallery gemdropx, some gnome-*, gparted (why?, poor gparted) grdesktop, some gpe-*, gst-* gstreamer* gthumb
2010-11-11 20:02 <wpwrak> maybe for some warning sounds
2010-11-11 20:03 <wpwrak> someone 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 of
2010-11-11 20:04 <wpwrak> well, the mp3 patents won't be with us for all that much longer, so it may already be a bit late for this.
2010-11-11 20:04 <rafa> more: gtkmm gvsd-* hsetroot, a lot of lib*, matchbox2 :(, midori, nautilus, openmoko-*, pidgin, paroli-*, pulseaudio, some python-*, qtnx, some qt4-*, scummvm, shr-*, sugar, supertux, toppler, wxwidgets
2010-11-11 20:05 <rafa> yum
2010-11-11 20:05 <rafa> that is the main list.
2010-11-11 20:05 <wpwrak> wxwidgets ;-) oh dear
2010-11-11 20:06 <wpwrak> lots of them look as if it would be easy to clean them up. someone at the OE level, others at the program level.
2010-11-11 20:07 <wpwrak> we 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 it
2010-11-11 20:07 <rafa> ;-))
2010-11-11 20:09 <rafa> om-maps-buenos-aires: saved ;-)
2010-11-11 20:11 <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 :)
2010-11-11 20:11 <wpwrak> (om-maps) i wonder if they're getting updated ...
2010-11-11 20:13 <rafa> om-maps: I have no idea
2010-11-11 20:14 <rafa> wpwrak: you mean that maybe those maps are from 1810? :)
2010-11-11 20:14 <wpwrak> rafa: 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 ?
2010-11-11 20:14 <rafa> wpwrak: om-maps-buenos-aires.. maybe it says: "Buenos Aires, Spain"
2010-11-11 20:14 <wpwrak> rafa: (1810) hmm, i guess they would be if they were sponsored by the government ...
2010-11-11 20:15 <wpwrak> rafa: (1810) naw, just the day after it stopped being spanish :)
2010-11-11 20:19 <rafa> wpwrak: 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 someone
2010-11-11 20:19 <rafa> came up with a patent on .. libgtk2.0.. maybe I have a script to decide what to do :)
2010-11-11 20:20 <wpwrak> yes, automation would be good. that way, also future updates from "complete" jlime would be no problem
2010-11-11 20:21 <rafa> yep, exactly
2010-11-11 20:23 <rafa> ah.. gdb is there on repo, great.. Good that it does not need libmad and duke3d :P
2010-11-11 20:24 <wpwrak> gdb --nostartup-sound ;-)
2010-11-11 20:27 <rafa> haha
2010-11-11 21:42 <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/22288a2
2010-11-11 21: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/000c087
2010-11-11 21:49 <kristianpaul> wpwrak: btw is your USRP config described somwhere?
2010-11-11 21:52 <wpwrak> kristianpaul: it's a USRP2 with the XCVR2450. you can see them here: http://www.ettus.com/order
2010-11-11 21:54 <wpwrak> kristianpaul: (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 :-( )
2010-11-11 21:56 <kristianpaul> wpwrak: you asked for refunf to ettus?
2010-11-11 21:56 <kristianpaul> refund*
2010-11-11 21:57 <wpwrak> naw. i can still use it. just need to change my test setup.
2010-11-11 21:58 <kristianpaul> ah good :)