<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.
<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.
<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.
<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).
<wpwrak>
that's the three issues i can think of at the moment
<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.
<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.
<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 :-)
<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.
<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"
<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.
<wpwrak>
s/purning/pruning/
<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.
<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.
<wpwrak>
so if OE/opkg has something like this, that may be a nice and clean solution.
<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 ?
<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.
<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
<wpwrak>
how does this sound ?
<wpwrak>
(now .. what shall i do until rafa wakes up .... :)
<wolfspraul>
wpwrak: sleep?
<wpwrak>
wolfspraul: just got up :)
<wpwrak>
wolfspraul: if you remember anything from OM's attempts to bring patent (in)sanity to OE, that might be useful
<wolfspraul>
no not really. back then we just tried to get mp3 out, but never succeeded.
<wolfspraul>
even though the message was clear, everybody knew it, everybody knew the priority
<wpwrak>
can you be more specific ? what was tried and how did it not succeed ?
<wolfspraul>
I don't know.
<wolfspraul>
I only know you could still play mp3 :-)
<wpwrak>
urgh
<wpwrak>
how did you find out you could still play mp3 ?
<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.
<wolfspraul>
the player was in the rootfs :-)
<wpwrak>
okay. i agree with your point :)
<wpwrak>
sounds a is OM's lack of success with this undertaking had more to do with ineptitude than anything else :)
<wpwrak>
s/a is/as if/
<wolfspraul>
well with that many people, the problem is more of a high level problem first
<wolfspraul>
does everybody (who needs to) understand the problem
<wolfspraul>
do they understand the priority of the problem
<wolfspraul>
do they agree on one common way to solve the problem
<wolfspraul>
and finally - can they pull off the solution as a team
<wolfspraul>
maybe all of those failed, I don't know...
<wolfspraul>
just technically, it's clear though that removing something like MP3 is not trivial in OE
<wolfspraul>
but it sounds like we are quite far, so let's see. almost there maybe/hopefully!
<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 ...
<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.
<wpwrak>
ah, i know. i could do a Great Renaming :-)
<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 :
<rafa>
"I have tried for the last 10 days to build pyth..plot and I have problems with 100 librarires missed"
<rafa>
"I have tried the last week to build a fancy editor..." .. Things like that.
<wpwrak>
good morning ! :)
<wpwrak>
(finish the upload) yup, that's good. finish one thing, then do the next. i should do that more often, too ;-)
<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.
<wpwrak>
(messy dependencies) well, we can call it a "beta" with some unresolved dependencies not fully cleaned up yet ;-)
<rafa>
but this example or=but on this example either
<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)
<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 ;-)
<kyak>
openwrt does support a bunch of patented things, but it won't build unless you explicitely allow them by setting CONFIG_BUILD_PATENTED
<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
<kyak>
other than throwing away libraries and breaking things in OE
<wpwrak>
rafa: does OE have alternative choices ? e.g., my vi/joe/emacs example ?
<wpwrak>
rafa: also, does OE have build variants of the same (source) package ? e.g., emacs vs emacs-x11 ?
<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
<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.
<wpwrak>
kyak: this could even be a useful tool for checking the integrity of repositories that supposedly contain "everything"
<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
<rafa>
wpwrak: what do you mean with "alternative choices" (vi/joe/emacs)?
<wpwrak>
rafa: your message was cut as "The system should k|"
<wpwrak>
s/as/at/
<rafa>
wpwrak: "The system should k|"= "The system should know if those packages could be built or not"
<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)
<wpwrak>
rafa: another example could be bison vs. berkeley-yacc. both provide a "yacc"
<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.
<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.
<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.
<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.
<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
<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.
<wpwrak>
rafa: (continuing step 2) sorry, that's lib-with-E and lib-without-E
<wpwrak>
rafa: (cont) so the applications that don't need E would simply depend on lib-without-E and everyone is happy
<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 ;-)
<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.
<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..
<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
<rafa>
wpwrak: The program P just uses Z.
<wpwrak>
in this case, and if there is no other mechanism, you wold have to tell P which variant of Z he can use
<wpwrak>
i don't know if OE has other mechanisms, though
<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?
<wpwrak>
for example, gentoo has flags for general capabilities
<wpwrak>
so you could say, for example, that you have opengl hardware, and then it would enable opengl support in all the packages
<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
<wpwrak>
that is, unless you have an alternative mechanism, like the one in gentoo
<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.
<wpwrak>
you could of course just make the relevant members of the chain depend on license-foo
<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.
<wpwrak>
how do the other jlime members like the debian idea ? :)
<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
<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.
<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 ?
<wpwrak>
(what form) form of the feature, not form of the welcome :-) ("sure, we're already cooking the pot of tar to welcome you ...")
<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)
<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 :)
<rafa>
But Fedora does not support all the archs which Debian does well
<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
<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"
<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
<wpwrak>
(debian) hmm, so we should win one of the debian gods over
<wpwrak>
libmanga-brutal-underage ;-) perfectly legal in japan, of course ;-)
<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?
<wpwrak>
pheew. so .. what's the plan then ? :)
<wpwrak>
i think it's all manual
<rafa>
libmanga ;-))))
<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.
<wpwrak>
not sure what it does about dependencies of the kind you desribed. probably just build something that doesn't quite work ;)
<rafa>
wpwrak: and does the people know that CONFIG_PATENTED?
<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.
<wpwrak>
(do they know it) i guess it sinks in after the first public flogging ;-)
<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.
<wpwrak>
it's not really all that hard once you've made the initial preparations. what's painful is to get there from zero.
<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 ;)
<wpwrak>
excellent
<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.
<rafa>
wpwrak: OE: maybe they already solved that well and we are talking without sense :P
<kyak>
pretty important though small fix, which would help a lot..
<larsc>
is ncursesw part of backfire?
<kyak>
nope, but i'm trying to build it from openwrt-packages
<kyak>
(i guess this change is helpfull not only for libncursesw)
<kyak>
larsc: so what do you think?
<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
<qi-bot>
[commit] Werner Almesberger: The Great ATSPI Renaming, part 2: rename ATSPI_* identifiers to ATUSB_* http://qi-hw.com/p/ben-wpan/96b6a50
<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
<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
<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
<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
<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
<xiangfu>
wpwrak: I don't know. maybe ask Wolfgang.
<wolfspraul>
I don't know either.
<wpwrak>
hmm. well, we can always ping him and see where this leads
<wpwrak>
wolfspraul: i guess you'd be happier with debian than with OE ? :)
<wolfspraul>
on the NanoNote?
<wolfspraul>
too little memory
<wolfspraul>
Fedora was interested to support it, they just lowered their minimum memory requirement from 128 to 64
<wolfspraul>
but they will stay away from 32mb platforms
<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...
<wolfspraul>
oe always was kind of in the middle, say for 32 or 64 it should be fine?
<wolfspraul>
so am I happier with Debian than with OE (on the NN) - no
<wpwrak>
well, the basic assumption is that there would be work on debian to make it happy with a smaller memory footprint
<wolfspraul>
not sure
<wolfspraul>
this doesn't sound like a good plan to me
<wolfspraul>
nobody will join the effort
<wpwrak>
the sources are the same, so there's nothing that would fundamentally prevent debian from running on small systems
<wolfspraul>
maybe start with Debian 2.1? :-)
<wolfspraul>
ah well, projects have a focus
<wolfspraul>
memory is going up
<wolfspraul>
any decent android phone has how much now? 512mb? more?
<wolfspraul>
don't fight mother nature
<wpwrak>
yeah :) 1 GB is the new 640 kB ;-)
<wpwrak>
people are even doing crazy reworks on the ben ;-)
<wolfspraul>
debian on a 32mb system is off-chart
<wolfspraul>
so it's great that we got it working, and I hope the port stays alive
<wolfspraul>
but I doubt we get enough mindshare about Debian folks for our problems once they discover we are targeting a 32mb system
<wolfspraul>
I meant 'among Debian folks'
<wpwrak>
let me rephrase the question: if its size requirements were compatible with the ben, would you like it better than OE ?
<wolfspraul>
yes
<wolfspraul>
I see Debian as a 'distro'
<wolfspraul>
not as a tool to create custom/optimized images
<wolfspraul>
(that's how I see OpenWrt)
<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 ?
<wolfspraul>
and from what I know about OE, I would say the result of OE is also a distro
<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
<wpwrak>
OE is even a meta-distro ;-)
<wolfspraul>
fine
<wolfspraul>
:-)
<wolfspraul>
so yes, if I have enough memory, I would 100% want Debian or Fedora
<wpwrak>
hmm, except for openmoko, you mean ;-)
<wpwrak>
(customized images)
<wolfspraul>
I don't know why those decisions were made, it was way before me.
<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.
<wolfspraul>
Debian also includes MP3,I think
<wolfspraul>
and I doubt it's a flexible enough tool to remove such stuff easily
<wpwrak>
given the general political background of debian, they should at least be sympathetic to the cause :)
<wolfspraul>
especially not if some new nonsense patent comes up, but we need to react and do some surgery
<wolfspraul>
ok but I don't want to be in 5 years of lobbying during which I cannot sell my stuff
<wpwrak>
sure. needs to get fixed first. much like the memory footprint.
<wolfspraul>
I think fedora is getting more aggressive on the patents now
<wolfspraul>
did I read this somewhere? I forgot...
<wolfspraul>
are they even removing mp3 now?
<wpwrak>
right now, we have openwrt. very soon we have jlime. let's save the colonialization of debian for the next year ;-)
<wolfspraul>
it's already there, and I hope nebajoth will keep it alive :-)
<wpwrak>
maybe in their "forbidden things" like ?
<wolfspraul>
he will, I'm sure, just a little later
<wpwrak>
(debian) well, make it a first-class citizen of qi-hw, like openwrt and jlime.
<wolfspraul>
biggest stopper (maybe only one?) is patents as well
<wolfspraul>
first nebajoth needs to come live again, which I'm sure he will at some point
<wolfspraul>
of course you need things like swapfile on sd card :-)
<wpwrak>
wolfspraul: the more we mention the name of nebajoth, the more likely it is, nebajoth will notice and become alive ;-)
<wolfspraul>
wpwrak: btw, I think there was a gentoo for nanonote effort too at some point
<wolfspraul>
not sure what happened to it
<wolfspraul>
max poseidon in belarus did it? forgot...
<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
<wolfspraul>
was a blocker
<wpwrak>
hmm, pity
<wolfspraul>
wpwrak: gbraad is our Fedora guy here :-)
<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 ?
<wpwrak>
rafa: same question for OE/jlime :)
<wolfspraul>
but it seems Fedora, in the form of Fedora Electronic Lab, is getting behind Milkymist in a big way (as a dev environment)
<wolfspraul>
so there could be some marriage later on...
<wolfspraul>
I believe openwrt started on 2mb systems
<wolfspraul>
2mb memory
<wolfspraul>
or maybe 4?
<wolfspraul>
anyway around there
<wolfspraul>
that's all I know, not how they did it...
<wejp>
it started on a 4 MB system, but there are trimmed down version for systems with only 2 MB
<wolfspraul>
wejp: ah great, thanks
<wolfspraul>
how about the backfire release? still runs on 4 mb systems?
<wejp>
yes, it does, it still runs on the original WRT54G (which is the device openwrt got its name from)
<wejp>
that one has 4 MB flash and 16 MB RAM
<wolfspraul>
wejp: is 16 mb RAM the lowest in memory backfire supports? (off the top of your mind)
<wejp>
not sure, but even if it runs with 8 MB, it would be of very little use
<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 .. :)
<wolfspraul>
ok got it
<wejp>
basically it is that. uclibc saves lots of memory compared to glibc
<wolfspraul>
my point is still valid - 32 mb memory is a very nice system for openwrt :-)
<wpwrak>
wolfspraul: dreaming of linux-2.6.42/arch/8051-nommu/ ? ;-)
<wolfspraul>
(I mixed up memory and nand size earlier)
<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)
<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
<wpwrak>
my first linux system had 4 MB of RAM ... later needed to upgrade to 8 MB for X, though. damn bloatware :)
<wejp>
hehe, one can even run X with 4 MB only
<wejp>
without swap that is!
<wejp>
but you can't do much else then ;)
<wpwrak>
wejp: (uclibc) does openwrt need a lot of patches to work with uclibc ? or do applications usually not notice / already come uclibc-ready ?
<wejp>
many applications just need to be compiled against uclibc and run just fine, there are a few incompatibilities with glibc though
<wejp>
but most applications run fine without patches as far as i can tell
<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
<wolfspraul>
wpwrak: for the oe decision at om. remember gta01 had 64mb memory.
<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.
<wolfspraul>
and with 64mb, debian and fedora were not really possible either
<wolfspraul>
so it came down to only oe
<wolfspraul>
with the gta02, of course memory would have been enough for debian or fedora already
<wolfspraul>
meanwhile openwrt started to pickup more and more gui apps
<wpwrak>
wejp: kewl. so perhaps a debian wouldn't be too traumatic once someone figures out how to make it use uclibc
<wolfspraul>
just my recollections, others may have observed things differently...
<wpwrak>
wejp: or make eglibc drop some fat :) eglibc is supposedly already a huge improvement over glibc.
<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
<wejp>
you need to have swap to use it, which i really don't like
<wpwrak>
wolfspraul: (oe at om) and let's not forget that mickey is a zaurus/oe veteran ;-)
<wejp>
ipkg/opkg uses a lot less memory
<wpwrak>
wejp: couldn't you use just opkg to install those debian packages ?
<wejp>
not sure. ipkg is quite similar to dpkg, but not identical
<wpwrak>
wejp: rafa did some work on making opkg (right ?) behave even better
<wpwrak>
well, i'd file the package installer under "minor problems" :) the problem per se isn't exactly "NP = P ?"
<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
<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
<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 :)
<wpwrak>
yup, the insane memory demands are a known issue. and already a partially fixed one.
<wejp>
maybe it is fixable. question is if it is worth the effort
<wejp>
okay
<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
<wpwrak>
but i'm sure that can be dealt with, too
<wejp>
when going through all that, what woulbd be the advantage over openwrt in the end?
<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.
<wpwrak>
(advantage) LOTS of packages :)
<wejp>
ok, but you have to compile every single one of them
<wpwrak>
i view the ben as basically a PC
<wejp>
you cannot just use the mips debian packages
<wpwrak>
we have computers for that ;-)
<wejp>
;)
<wejp>
for my taste debian is much too bloated, but having another option for a operating system is nice of course
<wpwrak>
(build everything) and let's not forget gentoo, where every single user does the whole rebuiling each time something changes :)
<rafa>
wpwrak: jlime uses eglibc.
<wpwrak>
rafa: and you're happy with its size ?
<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
<wpwrak>
wejp: sigh. busybox does save space. but at what a horrible price ... :-(
<wpwrak>
i've grown quite a hatred for busybox over the years. busybox and dropbear.
<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
<wejp>
why is that? what do you hate about those so much?
<wpwrak>
the price is that you can't trust any scripts to work. there are countless subtle incompatibilities
<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
<wejp>
scripts only fail if you rely on bash functions
<wpwrak>
yes, i understand the point for extreme low-memory systems
<wpwrak>
there you'
<wejp>
if you stick with sh you should not run into bigger problems
<wpwrak>
re heavily customizing anyway. so then it's okay if you have to work around incompatibilities.
<wpwrak>
/bin/echo >/dev/full
<wejp>
:o
<wpwrak>
just to name a recent discovery :)
<wejp>
what's that supposed to do?
<wpwrak>
expected: /bin/echo: write error: No space left on device
<wpwrak>
a correct shell would also do the same for just  echo >/dev/full
<wpwrak>
(with echo usually being a built-in)
<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.
<rafa>
wpwrak: size is okey. bootstrap is just 8MB I would say
<wpwrak>
and of course, you'll still miss things, which come to haunt you later
<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).
<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.
<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
<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.
<wpwrak>
rafa: (8 MB) okay, not quite down to uclibc levels, but not too obese either. hopefully it stays that way :)
<wpwrak>
rafa: (a lot of RAM for debian) how come ?
<wejp>
even bash alone uses more than 1.5 MB of RAM which is a lot for a machine with only 32 MB
<rafa>
wejp: if I build a rootfs using Debian repo which does not have but busybox
<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 ;-)
<wpwrak>
wejp: (bash) yeah, bash is a bit of a pig. i wholeheartedly recommend staying away form bashims wherever possible.
<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
<wejp>
wpwrak, which shell do you recommend?
<wpwrak>
wejp: yan to the rescue ! ;-)
<wpwrak>
s/yan/ya/
<wejp>
hehe, yeah, more RAM and USB host are the most important features :)
<wpwrak>
wejp: oh, i basically still use bash everywhere. but i try to write my scripts such that they don't require bash.
<wpwrak>
aye. and a bit of RF, and we have a nice package :)
<wejp>
yeah, shell scripts should avoid relying on bash
<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.
<wpwrak>
kshisms are also bad. particularly since they easily drift into bashisms.
<rafa>
scripts should be written on JAVA
<wejp>
lol
<rafa>
:D
<wpwrak>
rafa: JAVA with .NET :)
<rafa>
wpwrak: yeah.. and the whole Visual Everything SDK inside of the binaries
<wpwrak>
rafa: (how come) okay, that's what i was after
<wpwrak>
/bin/true
<wpwrak>
error: cannot initialize OpenGL
<rafa>
:D
<rafa>
/bin/yes
<wpwrak>
maybe store error message in .xls files and use libreoffice to retrieve them, too :)
<rafa>
New release..: busybox framework for JAVA.. good for small devices with 4GB of RAM
<wpwrak>
kyak: rafa found something ... are you sure there's no mpeg (mp3, i suppose) codec in there ?
<wpwrak>
(url in private message, no need to log this)
<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 :)
<rafa>
kristianpaul: help=help me
<rafa>
kristianpaul: no!..
<rafa>
kyak: help=help me
<kyak>
rafa, wpwrak i'm here
<kyak>
indeed you are right... i think i need to delete it?
<kyak>
libmad as well as MPlayer have support for patented functionality
<rafa>
kyak: is not it a "virtual" lib or something?..
<rafa>
ah.. I see
<kyak>
DEPENDS:=@BUILD_PATENTED
<kyak>
both libmad and mplayer
<kyak>
(though mplayer could be built without mp3 support, but this is not sexy)
<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
<Ornotermes>
haha, i linked a friend a screenshot of wireshark listening to usb from a virtual machine running windows, he called black magic :P
<kyak>
rafa: can you start from scratch, gradually adding utils and libs one by one? making sure each of them is free
<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
<kyak>
the build system should automatically deselect packages with unresolved dependencies
<kyak>
and this will lead to other packages that depend on those libes being deselected, too
<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,
<rafa>
well, some applications using that lib-patented-technology would not work well surely. SO repo would be sane, but applications no :P
<kyak>
the idea is that those apps would not be built at all
<rafa>
kyak: if we remove.. we will need to remove packages which used those.. etc.. following the chain
<kyak>
yup.. this should be done automatically by the build system
<kyak>
i see a very good example of conditional depends
<kyak>
so mplayer in OE is basically "clean" if ENTERPRISE_DISTRO is not set
<rafa>
kyak: ah.. that is really great it seems. Thanks! let me check further
<kyak>
i'll remove those file for now from ~/people... just in case
<kyak>
sleep();
<kristianpaul>
rafa: sure what u need?
<rafa>
kristianpaul: I tried to talk with kyak .. but you have a similar to many guys here ;-))
<rafa>
so I failed using TAB ;)
<wpwrak>
kyak: (removal) thanks !
<wpwrak>
kyak: (mplayer without mp3) oh, but it's still a nice player. i use it for ogg too.
<rafa>
wolfspraul: morning..
<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.
<wpwrak>
rafa: you mentioned some 2000 packages ... are they all because of mp3, or were there a number of unresolved dependencies already before ?
<rafa>
okey= if the package is on repo then user can install it without dependences problems
<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 :)
<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:
<rafa>
balsa had unresolved dependencies.. but similar packages as well:
<rafa>
balsa-locale-am
<rafa>
balsa-locale-ar
<rafa>
balsa-locale-az
<rafa>
balsa-locale-be
<rafa>
balsa-locale-bg
<rafa>
balsa-locale-ca
<rafa>
balsa-locale-cs
<rafa>
balsa-locale-da
<wpwrak>
aah, i see
<rafa>
balsa-locale-de
<rafa>
balsa-locale-dz
<wpwrak>
okay okay ;-)
<rafa>
balsa-locale-el
<rafa>
..
<rafa>
a lot more
<rafa>
that is why the 2000 number
<wpwrak>
so maybe 100 real pakcages ? hopefully not too many popular packages among them
<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
<rafa>
wpwrak: nautilus is on that list
<wpwrak>
okay, that one really shouldn't REQUIRE libmad :)
<wpwrak>
some things have the strangest dependencies ;-) evince ! for audio-books ? :)
<rafa>
others: fso-* gallery gemdropx, some gnome-*, gparted (why?, poor gparted) grdesktop, some gpe-*, gst-* gstreamer* gthumb
<wpwrak>
maybe for some warning sounds
<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
<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.
<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
<rafa>
yum
<rafa>
that is the main list.
<wpwrak>
wxwidgets ;-) oh dear
<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.
<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
<rafa>
;-))
<rafa>
om-maps-buenos-aires: saved ;-)
<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 :)
<wpwrak>
(om-maps) i wonder if they're getting updated ...
<rafa>
om-maps: I have no idea
<rafa>
wpwrak: you mean that maybe those maps are from 1810? :)
<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 ?
<rafa>
wpwrak: om-maps-buenos-aires.. maybe it says: "Buenos Aires, Spain"
<wpwrak>
rafa: (1810) hmm, i guess they would be if they were sponsored by the government ...
<wpwrak>
rafa: (1810) naw, just the day after it stopped being spanish :)
<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
<rafa>
came up with a patent on .. libgtk2.0.. maybe I have a script to decide what to do :)
<wpwrak>
yes, automation would be good. that way, also future updates from "complete" jlime would be no problem
<rafa>
yep, exactly
<rafa>
ah.. gdb is there on repo, great.. Good that it does not need libmad and duke3d :P
<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
<kristianpaul>
wpwrak: btw is your USRP config described somwhere?
<wpwrak>
kristianpaul: it's a USRP2 with the XCVR2450. you can see them here: http://www.ettus.com/order
<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 :-( )
<kristianpaul>
wpwrak: you asked for refunf to ettus?
<kristianpaul>
refund*
<wpwrak>
naw. i can still use it. just need to change my test setup.