<wolfspraul>
not the best location but the fped Debian package will also show up there so I just put it there for now
<wolfspraul>
then I installed KiCad+your patches, as well as fped, on our buildhost machine, and made the entire /home/git/repositories available to the buildhost as read-only (via nfs)
<wolfspraul>
now I want to try to run the schhist scripts on the buildhost
<wolfspraul>
there is a schhist/Makefile but the paths seem quite hardcoded
<wolfspraul>
I cannot find much documentation either, so I will just start and try to run it see what happens :-)
<wolfspraul>
I want to automate this so that all KiCad projects on the Qi projects server automatically have it
<wolfspraul>
pretty cool stuff I think :-) at least very important for the goals of our copyleft hardware project
<Textmode>
interesting.
<wolfspraul>
the visualization creates opportunities to join the development or review process
<wpwrak>
wolfspraul: sounds good so far :) most of the hardcoded stuff is meta-data. links to the project page and such.
<wpwrak>
wolfspraul: there are a few tricky/irregular bits, though: projects with more than one kicad project inside, the use of the -f option, and the project name
<wpwrak>
wolfspraul: you need -f if the project doesn't assign useful subsheet names. right now, only SIE CEIMTUN has this problem.
<wpwrak>
wolfspraul: one could of course consider this a bug in the project :)
<wpwrak>
what -f does is that it switches to using the file names instead of the subsheet names
<wolfspraul>
wpwrak: yes I see it already
<wolfspraul>
you try to give it a positive spin though
<tuxbrain>
wolfgang: apart of empower the visibility/participation on existing project I bet including this will atract other project to join qi-hardware :)
<wolfspraul>
even though almost every project has its own options, at least they are not called -wpan-cntr etc :-)
<wolfspraul>
exporting the git repos via nfs was utter nonsense of course
<tuxbrain>
only a feeling, but I see some bright eyes when I show the demo on CEDI
<wolfspraul>
wpwrak: do the scripts use git commands to go through the revisions?
<wpwrak>
wolfspraul: (nonsense) why ? you need them, too
<wolfspraul>
the repos?
<wpwrak>
wolfspraul: yes, it checks out the old revisions. but it does this in a temp directory
<wolfspraul>
yes but I exported the actual git repository folder, which I think is not a good idea
<wolfspraul>
instead, I just need to do a git clone with the git:// read-only urls
<wpwrak>
wolfspraul: it uses the current repos as a starting point
<wpwrak>
wolfspraul: (repo/clone) is there a difference ? :)
<wolfspraul>
since the nfs export is read-only, you cannot run git commands in there
<wolfspraul>
yes sure, because you wouldn't want to run the scripts on an nfs export of the actual server-side repository
<wolfspraul>
that's a bit hard-core
<wolfspraul>
my bad
<wpwrak>
wolfspraul: hmm, read-only should be okay. not that i've tried it, but the things that run there shouldn't need to write
<wolfspraul>
but they need to checkout somewhere otherwise how can you run scripts on the files
<wpwrak>
wolfspraul: yes, they get checked out in repo-root/_something directories
<wpwrak>
wolfspraul: or, rather, repo-parent
<wolfspraul>
sure but it's a clone
<wpwrak>
wolfspraul: e.g., if you have ben-wpan in /foo/bar/ben-wpan, then the temp directories are in /foo/bar/_whatever
<wolfspraul>
are the scripts safe to be run from another folder?
<wolfspraul>
did you ever test it? I see lots of paths in them, so I tend to stay with the 'default'
<wpwrak>
wolfspraul: the temp directories are called _gitsch2ps and _schhist2web
<wpwrak>
wolfspraul: hmm, which paths do you mean ?
<wpwrak>
wolfspraul: the scripts shouldn't care about the directory they run from, as long as they can figure out where the rest of the scripts lives
<wpwrak>
wolfspraul: what you have to tell them is where the checked-out tree is (with .git repo) and where in that tree the kicad project lives
<wolfspraul>
I'll work my way through, no worries
<wpwrak>
wolfspraul: and they need the name of the output directory. that can be a relative path.
<wpwrak>
of course, as always, you may find bugs :)
<wpwrak>
the huge number of things in schhist/Makefile is mainly because i didn't make a project-name -> environment mapping. things like SCHHIST_HOME_URL and SCHHIST_COMMIT_TEMPLATE are just a function of the project name
<wolfspraul>
sure sure
<wolfspraul>
let me work a bit
<wolfspraul>
:-)
<wpwrak>
something that's highly project-specific is SCHHIST_ORDER. that's the "human-friendly" order of the sheets. not really sure how to automate this.
<wolfspraul>
how efficient is the script, can I run it every 5 minutes in a cron job going over all KiCad projects?
<wpwrak>
(SCHHIST_ORDER) the same information can exist at other places (other scripts), but there's not really a standard representation for it
<wolfspraul>
or I have some kind of flag that is set whenever a commit is made
<wolfspraul>
but if the scripts are efficient they will just look at a timestamp and then do nothing anyway
<wolfspraul>
not sure
<wpwrak>
hmm, 5 minutes may be too often. maybe submit an at job 5 min after the last run terminated
<wpwrak>
if there's a big update, the scripts can run for a long while
<wolfspraul>
sure but that's no problem
<wolfspraul>
let's say there are no changes at all
<wpwrak>
lemme see how long they take if there's nothing to do ...
<wolfspraul>
how efficient is the script in 'doing nothing'?
<wolfspraul>
yes, thanks
<wolfspraul>
if it's not very efficient, I will have a little commit flag
<wpwrak>
it takes a few minutes because the pngs and the index.html are always regenerated. only the pnm and pdfs are cached.
<wolfspraul>
the thing is I want to run the scripts immediately after a commit, to give people some satisfaction in looking at what they just committed visually
<wpwrak>
yes, i understand
<wolfspraul>
few minutes, wow
<wolfspraul>
so I cannot run this over all KiCad projects
<wolfspraul>
no problem I'll have a little flag then
<wpwrak>
you're running right on the machine that will host the output files, right ? i.e., no rsync needed afterwards ?
<wolfspraul>
no it's the buildhost
<wolfspraul>
I think it fits better there, from the load characteristics
<wolfspraul>
I'll figure out how to get the files to the Apache server, there are many options
<wolfspraul>
rsync, nfs, redirects, etc.
<wpwrak>
okay. so, testing the timing with rsync then. let's see how it goes ...
<wolfspraul>
I'm not there yet, step by step
<wolfspraul>
I should probably clone kicad-libs too, right?
<wolfspraul>
is schhist able to deal with kicad-libs, also in revisioning?
<wolfspraul>
probably not yet :-)
<wpwrak>
6 minutes 11 seconds, with git-pull at the beginning and rsync at the end
<wpwrak>
(that's for all the projects i'm watching, ben-wpan/(atusb, atusd, cntr), xue, sie-cemtun, sie-v2
<wpwrak>
(kicad-libs) no, i don't track revisions there. i just use the current state
<wpwrak>
global revisions would be interesting :)
<wolfspraul>
so I need to have kicad-libs checked out?
<wpwrak>
yes. and if they use anything else, that too. ideally, just check out all the projects.
<wpwrak>
things that span projects are a bit of a weakness in the way git is normally used. e.g., in openmoko's svn, we just had one tree for everything. svn lets you check out subtrees and such, so things far away don't get that much in the way.
<wpwrak>
with git, this is harder. not that the svn approach would be without its own issues. e.g., limiting things to directories doesn't work perfectly.
<SiENcE>
@ Textmode, bartbes does not respond. can i find infos for nLove somewhere else?
<Textmode>
SiENcE: bartbes *is* nlove atm.
<Textmode>
but yes, I think he's asleep.
<mth>
more likely afk but not asleep
<SiENcE>
uhm
<wolfspraul>
wpwrak: hmm
<wolfspraul>
my folder setup is a bit different, I run into a seg fault
<wolfspraul>
I have a home dir /home/schhist
<wolfspraul>
the scripts are in /home/schhist/eda-tools/schhist
<wolfspraul>
the git repos are in /home/schhist/git
<wolfspraul>
the output dir is /home/schhist/output
<wolfspraul>
I run the scripts from /home/schhist
<wolfspraul>
the segfault comes from gitsch2ps, which has a parameter /home/schhist/_schhist2web
<wolfspraul>
this directory does not exist at the time gitsch2ps is called. when I create it before running schhist2web, it is deleted before gitsch2ps is called
<wolfspraul>
still investigating
<wolfspraul>
maybe I should run everything in exactly the same folder structure you have
<B_Lizzard>
Hi, I'm looking to build a battery indicator type thing
<B_Lizzard>
I see there exists a file called /sys/class/power_supply/battery/capacity but I was wondering what are the values it emits
<larsc>
percent
<B_Lizzard>
It never reaches 100%
<B_Lizzard>
kernel bug?
<larsc>
na, i would say thats a natural thing for batteries
<larsc>
escpecialy if such simple methods of measuring it are used
<B_Lizzard>
Ah, OK
<B_Lizzard>
I suspect things will be better in the future
<larsc>
the driver is pretty dump. it meassures the current battery voltage and compares it to a reference voltage which is supposed to be 100%
<wolfspraul>
wpwrak: the segfault is from eeschema, I will rebuild kicad on the buildhost
<B_Lizzard>
I see.
<wpwrak>
wolfspraul: how do you invoke schhist ?
<B_Lizzard>
I suppose things should be even harder if the system is to handle nokia batteries or worse, knockoff nokia batteries
<larsc>
yes.
<larsc>
since it probably has a different reference voltage
<wolfspraul>
wpwrak: from a Makefile, as user schhist
<B_Lizzard>
I think Nokia batteries have internal circuits which give a better estimate
<B_Lizzard>
Are those supported?
<B_Lizzard>
Or is support planned?
<wpwrak>
wolfspraul: i mean, with which arguments ?
<larsc>
B_Lizzard: nope. there is no method to access those
<B_Lizzard>
OK, thanks a lot, larsc.
<larsc>
B_Lizzard: but you could probably build a hw hack to do so
<wolfspraul>
you mean schhist2web? exactly like you do in Makefile
<wolfspraul>
let me rebuild kicad first, maybe that solves the problem already
<wolfspraul>
the scripts are a bit hard to follow/debug for a newbie, but I'll find my way through
<wolfspraul>
I just wanted to keep you posted
<wpwrak>
wolfspraul: hmm, ben-wpan would be in /home/schhist/git/ben-wpan/ or /home/schhist/ben-wpan/ ?
<wpwrak>
wolfspraul: (hard to debug) yeah, i know :)
<wolfspraul>
/home/schhist/git/ben-wpan
<wolfspraul>
I can change any of this to make it work, and I will :-)
<wpwrak>
wolfspraul: and you're running schhist2web from /home/schhist/eda-tools/schhist/ ? with, say, ./schhist2web ../../ben-wpan atrf/wpan-atrf.sch _atusb  ?
<wolfspraul>
first I ran from /home/schhist
<wpwrak>
wolfspraul: okay. so what does the line look like ?
<wolfspraul>
as eda-tools/schhist/schhist2web git/ben-wpan atrf/wpan-atrf.sch output/atusb
<wpwrak>
okay, perfect
<wolfspraul>
hmm, there is a _gitsch2ps folder in /home/schhist/git
<wolfspraul>
I'm a bit worried if my folder structure is different from yours the various scripts will not hand over stuff correctly, look in the wrong place
<bartbes>
SiENcE: of course
<bartbes>
what do you want?
<wpwrak>
_gitsch2ps is where it should be
<wolfspraul>
good
<wolfspraul>
I will continue tomorrow, late here...
<wpwrak>
it needs to be there so that eeschema will find things in other projects that are accessed via relative paths
<wpwrak>
e.g., ../kicad-libs/etc
<SiENcE>
hey bartbes,
<SiENcE>
what is currently done and where is the repository?
<SiENcE>
i wanna build it for dingoo
<bartbes>
SiENcE: well, there kind of is no repo atm