<zrafa>
wpwrak: we could use your myroot to do a smaller bootstrap rootfs yet, and also, we could use your myroot to have a system to build rootfs customized (using opkg-target and full repo) :)
<wpwrak>
zrafa: yup, that's the idea :) i used it to make root file systems with lots of "full-sized" programs, no busybox or dropbear
<wpwrak>
zrafa: but you can of course do pretty much anything with it
<zrafa>
wpwrak: and I think that I know how to make a proper ipk package using toolchain easily, so extra-packages repository could grow by users contributors; and because that extra-packages repository does not touch/break important repositories for the base system we could write those instructions for people who wants to contribute with packages they need on repo
<wolfspraul>
wpwrak: I have a question about eeschema erc and pcbnew drc. in our 'policy', should we say we are aiming for 0 warnings in those two?
<wolfspraul>
how important do you think are those 2 checks/reports?
<zrafa>
wpwrak: then we would have: the current sane repo, and an extra repo for contributions. In order to have a sane (or stable) thing for a while the sane repo would not change. And if people want more new packages on repo they would use the easy instructions to create packages to upload on extra-packages repo.
<wpwrak>
wolfspraul: hmm, 0 warnings isn't always possible. but yes, i'd recommend to try to reach this goal. also because it's easier to recognize it going from zero to non-zero than going from X to Y, with X and Y > 0.
<wolfspraul>
on the flight I was hacking a bit on more KiCad command line options
<wolfspraul>
which ones do you want?
<wolfspraul>
I think I will add --bom for eeschema (that already works)
<wpwrak>
wolfspraul: the DRC is quite important. there are things it doesn't catch without it. ERC is often just nagging, but it can occasionally be helpful, too.
<wolfspraul>
then we have a whole lot in pcbnew
<wpwrak>
wolfspraul: --bom: excellent !!
<wolfspraul>
gerber, svg, drill file, vrml, drc
<wolfspraul>
which ones do you want and what are important options in the dialog you often switch away from the default, or from one setting to another?
<wolfspraul>
any hints? at the beginning I will just use the dialog defaults
<wpwrak>
wolfspraul: pcbnew ... i need postscript (A4, front, mirror, no drill mark; A4, back, no mirror no drill mark), gerber (board edges, default settings), drill file (default settings)
<wpwrak>
wolfspraul: for front/back, "real drill" should also be possible (for manual instead of CNC drilling). "small mark" is misleading, because it's often bigger (!) than the real mark.
<wpwrak>
wolfspraul: adam may have a bunch of additional formats/settings, e.g., gerbers for the pcb fab
<wpwrak>
wolfspraul: important options that get switched: the drill mark, plot format, "plot mirror", the layer selection, maybe also plot mode
<wolfspraul>
ok this is a lot, overwhelmed... let me see...
<wpwrak>
zrafa: (user repo) hmm, maybe. or have people who help with these integration steps. so the normal developers doesn't worry about ipkg, but someone else picks up the package, advises the developer on changes to make it properly ipkg-able, and then makes the ipkg
<wolfspraul>
ok I start with the drill file dialog
<wpwrak>
zrafa: making "nice" packages needs a lot of context, so you're better off with expert help :)
<wpwrak>
wolfspraul: (a lot) hehe ;-)
<wolfspraul>
in there you are always happy with the defaults right now?
<wpwrak>
wolfspraul: (drill file defaults) yup
<wolfspraul>
drill units: inches (default)
<wolfspraul>
zeros format: decimal format (default)
<wolfspraul>
precision: 2:4
<wpwrak>
wolfspraul: at least i hope that my defaults really are the standard defaults. it's never easy to tell where they come from ...
<wolfspraul>
drill origin: absolute
<wolfspraul>
drill sheet: none
<wolfspraul>
(or do you want Drill map (PostScript) here?)
<wolfspraul>
drip report: none
<wpwrak>
perfect so far
<wolfspraul>
hpgl plotter options: 20cm/s 1pen
<wpwrak>
don't even know what the "drill sheet" is
<wolfspraul>
options: mirror y axis _OFF_
<wolfspraul>
options: minimal header _OFF_
<wpwrak>
yeah. that's what i have.
<wolfspraul>
that's all
<wolfspraul>
ok, only the defaults then for now, we can always add more options later
<wpwrak>
which kicad version are you using the latest or our "current' ?
<wolfspraul>
I think our standardized werner/qi version
<wolfspraul>
I mean I'm packaging it :-) would be kinda weird if my own system didn't have it...
<wolfspraul>
now I look at pcbnew -> file -> Plot
<wolfspraul>
hmm, lots of checkboxes for copper layers and technical layers
<wolfspraul>
I guess they should be settable from the command line (on/off)
<wolfspraul>
Scale Opt: Scale 1 - should be ok?
<wolfspraul>
Plot Mode: Filled
<wolfspraul>
Plot Format: HPGL (default) - do you want Postscript A4 here? there is also just 'Postscript'
<wolfspraul>
some options:
<wolfspraul>
Print sheet references: off
<wolfspraul>
print pads on silkscreen: off
<wolfspraul>
print module value: on
<wolfspraul>
prin module reference: on
<wolfspraul>
print other module texts: on
<wolfspraul>
force print visible texts: off
<wolfspraul>
then some hpgl options, pen size 0.015'' speed 20cm/s ovr 0.002''
<wolfspraul>
which ones do you want to control from the command line?
<wpwrak>
plot format: need gerber and postscript a4. not really sure what "postscript" would do. in any case, my paper is a4 :)
<zrafa>
wpwrak: nice packages: I mean, packages which install properly and run. If the software itself needs some changes to be nice for nn (for example if it is a GUI software for 640x480 it will not work) that is another problem. I just see a nice posibility to make proper ipks packages for the current repo (extra repo) easily (from sources with configure, make, make install)
<wpwrak>
none of the options you listed matter to me
<wolfspraul>
the others are ok?
<wolfspraul>
ok
<wolfspraul>
how about the checkboxes for copper layers and technical layers?
<wolfspraul>
they need to be controllable, right?
<wolfspraul>
they probably also depend on how many layers the board has, I'll figure that out
<wpwrak>
plot mode filled is good. layer selection is at least highly desirable, yes. (if you don't have it, it will just dump all selected layers, one per file, and you can then pick the ones you like. but it's more environmentally friendly to stop the waste production at its root)
<wpwrak>
(how many layers) presumably
<wpwrak>
zrafa: (nice pkg) i mean just making the ipkg. porting the software itself is another issue.
<wolfspraul>
ok so that one is clear
<wolfspraul>
then maybe I add the drc report
<wolfspraul>
and svgs for the layers, could be nice in giving people quick view access without installing kicad
<wolfspraul>
I guess for the rest, nobody really needs it right now
<wpwrak>
wolfspraul: svg should be nice, yes. adam will have bunch of files, too
<wolfspraul>
like Specctra DSN, Module Report, GenCad, VRML
<wpwrak>
specctra is for the external (gratis but non-open) router
<wolfspraul>
bom file we use eeschema
<wolfspraul>
alright I think I have enough to start with
<wpwrak>
hehe :) how's the snow ? i read about europe falling into chaos and ruins
<zrafa>
wpwrak: making the ipkg is something which often is done by development systems like OE, or openwrt. We know that, but after working a while I am seeing some easy way which would work always (using uploaded toolchain) :) (always=if porting works then package would be built against current repo)
<wpwrak>
zrafa: i basically see three roles: author, porter-to-ben, and package maker. all this may be done by the same person, but it could also be that several people are involved. i would consider 2-3 people the normal case.
<zrafa>
working a while=since I started to use those different kind of tools (from development systems)
<wolfspraul>
not much, all fine here
<wpwrak>
zrafa: (easy way) yeah, but then there's debian, openwrt, and a bunch of others. that's not very friendly, no matter how nice you make it look :)
<zrafa>
wpwrak: okey, I am talking about the last person (package maker)
<wpwrak>
zrafa: i would imagine that the the package maker is distro-specific and handles several/many packages
<wpwrak>
zrafa: knows the rules of that distro, knows how to handle corner cases, knows the people to ask for approval, and so on.
<wpwrak>
zrafa: so someone porting/writing something to the ben would just make sure it builds with make/self-punishment/cmake/whatever, and the packager(s) would then take it from there
<wpwrak>
zrafa: of course, if someone happens to know a distro's packaing process very well, like you do, then that person may directly do the package, too
<zrafa>
wpwrak: you go further :)
<zrafa>
wpwrak: let me put it simpler
<zrafa>
wpwrak: I am talking about extra packages, no more.. A place where we could upload packages which do not disturb the rest of the repo
<zrafa>
wpwrak: if the package uploaded does not work then that would not matter for the rest of the system or repo
<zrafa>
wpwrak: and the page maker I am thinking is just an script, which take the binaries built from sources and decide which packages are needed to install this new package. The rest of the info is not important.
<wpwrak>
zrafa: okay, that would then be 67% of the packager's work :)
<wpwrak>
(just a script) hmm, i think that's how they all start ;-))
<zrafa>
haha :D
<zrafa>
but I already tried the basic case
<wpwrak>
the basic case is where "just a script" usually works well
<wpwrak>
then you get the cases that depend on something unusual .... :)
<wpwrak>
and so on
<wpwrak>
your script would make packages for jlime and openwrt ?
<zrafa>
nah.. for jlime only. You need a proper toolchain working .. Mmmh, well, you could have the thing built, but I was thinking to use "./configure destination" on this process
<zrafa>
and the packages jlime uses are debian packages. openwrte uses another kind of packages I think (still if both ends .ipk)
<wpwrak>
ah, never heard of "configure destination"
<zrafa>
destination= I was thinking on --prefix
<wpwrak>
ah, i see
<zrafa>
wpwrak: and keep it simpler, it would be a simple way for people who wants to make a ipkg for extra packages using just the toolchain on their PCs. Forget the beast of OE/debian/openwrt who needs to keep all sync with millons of packages around and things changing
<zrafa>
simpler=simple
<wpwrak>
well, you can try and see. it will certainly be useful to some people.
<wpwrak>
(keeping in sync) i'm not sure you can avoid this, though. people will still install whatever they get from upstream. so the changed do affect you, if only indirectly.
<wpwrak>
s/changed/changes/
<wpwrak>
also remember, the only things that don't change are dead ;-)
<zrafa>
wpwrak: well, I am thinking on jlime repo on qi. That repo will not change still if OE upstream changes. So people will not install things from upstream
<wpwrak>
steve|m: yeah ! ;-))
<wpwrak>
zrafa: your "repo will not change" theory is in fact what worries me a bit :) when new things get added upstream, or get updated/fixed, etc., the repo _should_ change
<wpwrak>
zrafa: i don't think it's realistic to assume that a "frozen" repo will be good for a long time
<zrafa>
wpwrak: it is unmaintained repo. The current jlime is alive, and a few jlime devs are working. But that lives on jlime.com, no here
<zrafa>
wpwrak: so no chance to keep that.
<zrafa>
wpwrak: and I still think that a frozen repo is good
<wpwrak>
(unmaintained) yes, that's the bit that needs fixing :)
<zrafa>
wpwrak: sorry, different point of views.. Jlime has a repository for jornada which is 3 years old perhaps. And it is useful, no dead from my point of view. Just tell me the greatest nicest application openwrt/OE/whatever added this year for freerunner, or another mobile device. Which you think that you would like to have on current repos. For me, a lot of basic software does not change. psmisc, bash, init, top, bc, etc etc.. all the minimal tools you woul
<wpwrak>
(frozen) a frozen repo means that, when new stuff comes along, people will first wait. then, when nothing happens, they will devise work-arounds. then you get an increasing number of hacks that live on top of the repo. eventually, it will become too inconvenient to use and people switch away. by that time, everyone will hate it.
<zrafa>
Or those dont change on same way for you telling, if I do not get the latest top version then I will kill myself
<wpwrak>
zrafa: hmm, how many jornada users are out there ? ;-)
<zrafa>
wpwrak: but repo changing is not attracting users. I would love to have Debian, I already said that, and that explains that I think: I would like to have a huge and maintained repo
<zrafa>
but that does not exist on tiny projects
<wpwrak>
zrafa: the basic stuff doesn't change. but the ben is still a young platform. people are experimenting with new things.
<wpwrak>
zrafa: (debian) yup, perhaps some project for next year :)
<zrafa>
openmoko people was telling that they had several guys working to have a thing maitained.. and finally that was a mess
<zrafa>
so you need all the users and Debian developers , no my tiny script to make a package :)
<zrafa>
all the users and Debian developers you see for PC = you will need the same amount of nn users and Debian developers for nn
<zrafa>
if you want a really serious repo maintained and useful like we want.
<zrafa>
wpwrak: I do not see any develop for nn.. just gmu and another few things were written. From qi I see a big effort to have a basic linux system (init, shell) more  a GUI (which was already written for another device). No new things around. Nightsky is new and nice, but no much more
<zrafa>
all the efforts are trying to port current stuff, trying to find console applications or X applications which fit. That is nice, but no new
<zrafa>
the nice new things are on the hardware side
<wpwrak>
zrafa: (number of developers to maintain a distro) well, you're building on OE and "full" jlime. i would hope that this reduces the amount of work ;-)
<wpwrak>
zrafa: (effort on porting) yes, i see this as a weakness caused by the focus on openwrt. openwrt is so far behind when it comes to a "desktop" distribution, that people who could work on new things are still completely tied up with catching up
<wpwrak>
zrafa: of course, it's hard to tell what they would do if the basis was something more suitable, like jlime.
<zrafa>
we have some Debian developers here in Arg, we should talk with them face to face :)
<wpwrak>
and now it seems that folks working on qi-hw openwrt are pissed off at openwrt for some "downsizing" changes. of course, that's a predictable conflict: openwrt tries to be extremely small and not really interactive. the ben needs something compact but not excessively so, and a lot of interactivity. there's only so far you can go before conflicting design goals cause trouble.
<wpwrak>
zrafa: making debian embedded-friendly would be a great achievement
<zrafa>
Debian developer in arg. Moreover one of them was nominated as Debian leader http://www.debian.org/vote/2010/vote_001 (margarita), but she did not win it seems
<wolfspraul>
wpwrak: I'm not aware of any 'downsizing' unhappiness, but listening... first time I hear this
<wpwrak>
wolfspraul: a few days (or was it yesterday), there were complaints about openwrt breaking some - i think i18n - things into main and stub package, breaking lots of dependencies, because small systems often don't care about this anyway, but many things on tbe ben do
<wpwrak>
zrafa: kewl. a voting process where only mathematicians can understand the result. we should use this for politics ;-)
<wolfspraul>
sounds like normal discussions (and good I think)
<wpwrak>
wolfspraul: yeah, nothing evil per se. but i found the direction interesting, and how it was interpreted here.
<wpwrak>
wolfspraul: Dec 20 11:20:15 <kyak> these are all problems that we face because upstream is thinking about openwrt as a distro for routers
<wpwrak>
wolfspraul: Dec 20 11:34:33 <kyak> xiangfu: we will have to struggle with such things all the time
<wpwrak>
wolfspraul: Dec 20 11:37:02 <kyak> like @I_HAS_CRAPPY_ROUTER
<wpwrak>
just some soundbites  :)
<wpwrak>
wolfspraul: of course, kyak may just be unhappy about them messing with i18n, considering that
<wpwrak>
wolfspraul: Dec 20 11:46:32 <kyak> really, every time i see a software that is not i18n-aware, i get angry. this is less and less often now when utf-8 is taking its positions, but still there are a lot of developers there thinking "ASCII"
<zrafa>
wpwrak: voting process: yeah.. but then either we would not have politics anymore or they would like to kill owners of that voting process idea :P
<wpwrak>
zrafa: i think such a voting process would greatly change the concept of populism ;-)
<wolfspraul>
totally agree with kyak. still need to see what it means specifically for openwrt on the nn. kyak has been extremely helpful on this end, so let's see...
<wolfspraul>
not sure how many open issues there are right now, in that area
<wolfspraul>
kyak: 'released their gpl drivers' must be the overstatement of the century
<wolfspraul>
first they don't understand gpl, or free software
<wolfspraul>
maybe I should try again, see whether something has changed in the year or so since I last spoke with them...
<wpwrak>
so is the driver gpl or not ?
<wolfspraul>
which one?
<wolfspraul>
the wifi driver took me months, and in the end it came from Renesas, not Spectec
<wolfspraul>
I had to go to Tokyo, etc. etc.
<wolfspraul>
Spectec is, at best, very ignorant of the GPL.
<wolfspraul>
if they do understand it (even a little), they will be very worried.
<wolfspraul>
we had this situation with their Zigbee card, where we pulled back because they would stubbornly insist that all the work they had put into their driver was very valuable and had to be closed.
<wolfspraul>
of course, we kept telling them we will throw away their driver anyway, and write a new one, and only need to look at their sources for register documentation. but there was no way.
<wolfspraul>
the fact that we kept insisting on 'looking' at their sources must have made them believe even more how great and valuable their stuff is
<wolfspraul>
I'd rather not deal with Spectec, it's tiring with little results.
<wolfspraul>
like speaking to the wall
<wpwrak>
hmm, i see. alas, the seems to be pretty common among companies that make this sort of "exotic" peripherals
<wpwrak>
so i wouldn't have high hopes for vga either then. that's always been a nasty battleground for as long as i remember.
<wolfspraul>
Spected is only doing the microSD packaging
<wolfspraul>
the driver is not written by them, but by the IC maker
<wolfspraul>
at the most what Spectec does is to set the base address, compile, make a binary
<wolfspraul>
:-)
<wolfspraul>
that's their tremendous 'investment' that costs them so much money that they have to 'protect' it
<wpwrak>
you can't be too careful ;-)
<wolfspraul>
it's a small Taipei company, they are specializing in taking whatever IC they can find, and package it in *SD packages
<wolfspraul>
sometimes the things on their website are not really available, just 'announced'
<wolfspraul>
they also have the nasty habit of changing IC vendors without changing their model number (saves them money because they don't have to print new boxes etc)
<wolfspraul>
then you can only tell from the lot numbers (if you know), which IC you will get
<wolfspraul>
but other than that, they are a small and nimble company, and once in a while they hit a product that actually sells well
<wpwrak>
lovely. exactly what we're looking for :)
<wolfspraul>
I feel we are much further down the road.
<wolfspraul>
if anything I would put a micro-fpga on such a card, and try to develop the IC logic myself
<wolfspraul>
of course the entire hw design in our work-in-progress kicad process, etc.
<wpwrak>
heh, micro-fpga ;-)
<wpwrak>
now there's an idea :)
<zrafa>
wolfspraul: I really like how you are explaining what is Spected and the details you know :)
<wpwrak>
we ought to ask xylinx for sponsorship. qi-hw, the project that puts fpgas a the most unlikely places ;-)
<wolfspraul>
zrafa: well, I know the folks :-) been there several times, etc. they are cool. but we need to be realistic. so I explain it in the clearest possible language.
<kristianpaul>
micro-fpga :)
<wolfspraul>
they wouldn't even mind, I know that this chat is logged and wouldn't be worried about it on my next meeting there, if ever
<kristianpaul>
I never saw a FPGA in small package from Xilinx..
<zrafa>
wolfspraul: yeah, I guessed you knew the folks for the clear explanation .. that is great you know about that and other companies around
<zrafa>
for=from
<wolfspraul>
from their perspective we are retards too, introducing a random/arbitrary concept such as 'freedom', instead of just going for the highest sales volume
<wolfspraul>
they need volume, and fast
<wolfspraul>
like every hardware company
<wolfspraul>
everything else is secondary
<wolfspraul>
if I cannot give them volume (and fast), my bla bla will be even less impressive
<wolfspraul>
for Spectec, volume starts at 1k
<wolfspraul>
at least that's a 'real' custome
<wolfspraul>
customer
<kristianpaul>
You can give them some kind of knowledge may be?.. ;-)
<wolfspraul>
for 10k, they could probably even do a card just for you, and at that point the openess issue would also go away - you would own it all :-)
<wolfspraul>
knowledge?
<wolfspraul>
how about money?
<kristianpaul>
:-)
<wolfspraul>
so spectec is a good company to have. if we ever have a specific 8:10 card in mind, and we can make 10k, they would be the ones to work with on the manufacturing side.
<wolfspraul>
they have done it > 100 times, so they have seen it all and will for sure get it done
<wpwrak>
wolfspraul: speaking of which, you should post about the 8:10 card idea
<wpwrak>
grmbl
<Jay7>
kristianpaul: can you write some kind of RFC/proposal about fb menu launcher to ML?