DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
herpderphurr has quit [Ping timeout: 250 seconds]
enyc has quit [Ping timeout: 258 seconds]
xman has quit [Ping timeout: 260 seconds]
<DocScrutinizer05>
wpwrak: you're aware that apt-get is not exactly compatible to my system?
<DocScrutinizer05>
so seems you sugest I run this in my debian chroot?
radekp has joined #neo900
chainsawbike has quit [Ping timeout: 240 seconds]
chainsawbike has joined #neo900
<DocScrutinizer05>
I guess I need to approach this on a "what's intended/needed" basis and apply the according instructions that mazch my genuine system environment. For that I need to understand what all the git et al commands are supposed to do
<wpwrak>
DocScrutinizer05: libcairo2 sounds good, yes. so on suse, installing libfoo also installs the developer stuff (headers, libraries with [more] symbols, and such), not just the run-time lib for already compiled applications ?
<DocScrutinizer05>
kudos to diff, you're a magician
<wpwrak>
/nick harry :)
<wpwrak>
does suse have a libgit2 package ?
<wpwrak>
(or maybe it's just called libgit, git-devel, or such)
<DocScrutinizer05>
yep
<DocScrutinizer05>
libgit2.9 and libgit2.0-devel
<wpwrak>
perfect. then you'll soon be able to avoid all those git commands, and just tell sch2fig to retrieve the file directly from git
<DocScrutinizer05>
s/9/0/
<DocScrutinizer05>
shouldn't it rather become a serverside addon?
<DocScrutinizer05>
(our server also has libgit2.0, FWIW)
jonsger has joined #neo900
<wpwrak>
also there, it's much better if you can pick files directly from the git repo instead of having to check them out first
<wpwrak>
the old schhist script did all this in a file-based way. and it was very complex and slow.
* DocScrutinizer05
even wonders if we should get a remote(?) repo of kicad nightly on our server, and have a devuan chroot and build chronkob
<DocScrutinizer05>
slave?
<wpwrak>
maybe convince the devuan developers to include the kicad devel branch in their collection ?
<DocScrutinizer05>
I want our own builds
Guest58120 has quit [Ping timeout: 265 seconds]
<DocScrutinizer05>
eventually we might have own patches that don't make it to mainline (think cmdline options which is off the table, what a pity)
<DocScrutinizer05>
there might come more
<wpwrak>
i think it's best to try to work closely with kicad mainline, so if we make changes, they should be rapidly acceptable. sadly, we already know that the "out-of-tree patches" approach doesn't really work.
<wpwrak>
and anything else would be placed outside / around kicad. that works quite nicely for a lot of things.
<DocScrutinizer05>
wpwrak: whatever works that doesn't require me to do daily builds on my own PC
<DocScrutinizer05>
neither to install ubuntu or whatever
Guest58120 has quit [Ping timeout: 244 seconds]
Guest58120 has joined #neo900
<atk>
If you find some automated system for finding out when something needs to be rebuilt (I imagine it exists) I could run it on a spare box I have at home and just upload the package somewhere.
<atk>
I wouldn't mind doing that, all the machine ever does is store too many files anyway.
<pigeons>
look at TravisCI
<pigeons>
it will check it out and rebuild
Guest58120 has quit [Ping timeout: 258 seconds]
jonwil has joined #neo900
Guest58120 has joined #neo900
<edwin>
there is also GitLab/GitLab CI if you want to self-host it, Travis should work fine if you host your stuff on github anyway
<DocScrutinizer05>
neo900 using gitweb
<DocScrutinizer05>
lightweight git daemon. No fancy gitlab stuff infested with JS killing performance and usability
<DocScrutinizer05>
though being FOSS afaik, gitlab is such an indigestible hairball that not even hellekin manages to get a custom favicon in devuan for it
Guest58120 has quit [Ping timeout: 252 seconds]
<hellekin>
DocScrutinizer05: gitweb is written by Kay Sievers, you know that? :)
<edwin>
well there is gogs too if you're looking for lightweight, although I don't know which CI system supports that
<edwin>
the docker hub would be another possibility, but using a GUI app from inside docker is a bit complicated
<hellekin>
gitlab is great. The community will bind their will :)
<pigeons>
:)
<edwin>
you could also have a cronjob that performs your build once a day from latest kicad git. You could write a dockerfile that uses whatever base Linux distro you prefer, install all prerequisites, then git clone / git checkout <git hash>, and build it
<edwin>
if git hash is the same docker will use the cache and not actually run the build
<edwin>
if git hash changed it will run the build
<edwin>
and you could mount a dir with -v where you put the resulting .deb file
<edwin>
and then you'd have all your deps listed explicitly in a file that is also checked into git
<edwin>
(the dockerfile)
<DocScrutinizer05>
hellekin: yes, I noticed it a week ago
<DocScrutinizer05>
puked a little
<DocScrutinizer05>
edwin: ((cronjob)) basically what I thought, yes
<DocScrutinizer05>
what you listed sounds great
<DocScrutinizer05>
only the word "docker" makes me boggle
<edwin>
in 'git checkout <git hash>' I mean that a script will generate this Dockerfile based on a template Dockerfile (ehrm, with sed)
<DocScrutinizer05>
though I gather it's only a glorified chroot
<edwin>
well you can use pbuilder or mock
<edwin>
guessing pbuilder since you're a debian guy
<DocScrutinizer05>
me? haha nope, not *yet*
* DocScrutinizer05
visits retraining facility every night
<edwin>
I've been using docker lots of times as a fancier/easier to manage chroot yeah
<DocScrutinizer05>
re-education
<edwin>
its basically you start out with lets say 'debian:8' as base, then run a bunch of commands
<edwin>
literally, you tell it: RUN apt-get install -y foo-dev
<edwin>
if the actual line haasn't c hanged it uses its cache to avoid rerunning it
<edwin>
if the line changed, or its a new line it will take the previous state and run the command
<DocScrutinizer05>
sounds good
<edwin>
for shipping docker containers aren't very good though, typical one with lots of dev tools is a few gigabytes
<edwin>
especially if you pull in X stuff
<edwin>
but if you aim to build a .deb package anyway
<edwin>
then just copy out the .deb when you're done
<edwin>
(or .rpm or whatever you build)
<DocScrutinizer05>
yes
<DocScrutinizer05>
sounds like a good approach
<edwin>
there are some caveats due to caching, e.g. always run apt-get update && apt-get install -y, otherwise your mirror may be out of date
<edwin>
by the time it runs apt-get install
<DocScrutinizer05>
unless we find a kicad source that already does that, for latest .deb and rpm
<edwin>
I see there is a docker container , 2GB...
<wpwrak>
DocScrutinizer05: cd ee/hw; eeshow/eeshow -r neo900.lib kicad-libs/components/powered.lib 6a9f71:neo900.sch -- pdf -o foo.pdf
<wpwrak>
it now uses the revision of neo900.sch also to look up neo900.lib and the sub-sheets
<wpwrak>
it doesn't know what to do about kicad-libs/components/powered.lib yet, so it warn abuot it (related_other_repo is no yet implemented)
<wpwrak>
oops, didn't push. now.
illwieckz has joined #neo900
illwieckz has quit [Changing host]
illwieckz has joined #neo900
<DocScrutinizer05>
I gather I need to pull for that?
<DocScrutinizer05>
or build anew?
<wpwrak>
so what this generates are the schematics like they looked after commit 6a9f71
<wpwrak>
pull and make
<wpwrak>
i.e., the schematics will show the older front sheet, and they will also not have your changes of the "fuel gauge". if there had been any changes in neo900.lib, they would also be consistent
illwieckz has quit [Client Quit]
<DocScrutinizer05>
jr@saturn:~/neo900git/sch2fig/newdir/hw/eda-tools/sch2fig> make
<wpwrak>
for "external" repos i'll need to get a little more creative, e.g., find a commit that was at the same time or before, and select that
<DocScrutinizer05>
make: *** Keine Targets angegeben und keine »make«-Steuerdatei gefunden. Schluss.
<DocScrutinizer05>
nah, that table isn't up-to-date
<wpwrak>
ah yes, you may have some more months: "openSUSE 13.2 - will be maintained until 2 months after release of Leap 42.2 (EXPECTED First Quarter of 2017)" https://en.opensuse.org/Lifetime
<DocScrutinizer05>
I updated to 13.2 ~1 year ago :-/
<DocScrutinizer05>
I'm generally skipping the notoriously shitty x.1 releases
<DocScrutinizer05>
formerly x.0
<wpwrak>
next, they'll make .2 shitty as well :)
<DocScrutinizer05>
so they drop x.1 too?
<DocScrutinizer05>
that would be really funny
<wpwrak>
release x.0, re-release it as x.1, then as x.2 :)
<DocScrutinizer05>
there are no x.0 anymore
<wpwrak>
so, only one re-release. excellent efficiency ! :)
<DocScrutinizer05>
not since 11.0
<DocScrutinizer05>
how about static linking of that shit
<wpwrak>
you still need a library to provide it
<DocScrutinizer05>
I thought about *you* doing that :-)
<DocScrutinizer05>
I've used a few statically linked binaries that were advertised as running on basically any arbitrary x86 linux system with a kernel