<DocScrutinizer05> all I'll see from ubuntu is the kicad window, fullscreen in the VM window
<wpwrak> DocScrutinizer05: since the issue at hand is to get it to run in your suse setup, i'm not really sure what you expect me to do. i mean, i can help you google for suse + keyword, but even there you probably know better than me what to do. and i have no experience with suse.
<DocScrutinizer05> no, the ssue at hand is to get it running in an ubuntu system of which you please provide a disk image when done
<wpwrak> enyc: i think the more "mainstream" the better in this case :)
<enyc> unity is slow graphics dependent mess tbh
<wpwrak> sorry, i won't give you disks :) way too much personal stuff on them ...
* DocScrutinizer05 headdesks, severely
<wpwrak> s/disks/my disks/
<DocScrutinizer05> that's why I asked you to create a vagrant box. Or use virtualbox if you don't like vagrant, I can turn it into vagrant in no time
<DocScrutinizer05> vagrant is just a wrapper around all the VM providers they support, which are roundabout all known ones
<wpwrak> DocScrutinizer05: the way i do things here is that i 1) add the ppa repository: add-apt-repository ppa:js-reynaud/ppa-kicad
<DocScrutinizer05> so please could you install virtualbox (which maybe you never touched), install an ubuntu you consider right (which I never touched), and install and configure kicad on that ubuntu (which also I never did)
<wpwrak> DocScrutinizer05: then apt-get update and apt-get install kicad that's it. i don't have any VMs or such stuff
<DocScrutinizer05> then provide the VM disk image
<wpwrak> ``\`\================================
<wpwrak> i
wpwrak has quit [Quit: Leaving]
<DocScrutinizer05> o.O
<enyc> i have virtualbox but not diskspace, but can advise on doing it
<enyc> its not hard
<DocScrutinizer05> if course virtualbox isn't hard
<enyc> DocScrutinizer05: hrrm i've not looked into vagrant either hrrm
<DocScrutinizer05> vagrant is pretty nice, after a 1h of learning what it actually does: https://www.vagrantup.com/docs/getting-started/
<DocScrutinizer05> in the end it's not much different to virtualbox anyway, after all it uses virtualbox and just takes care about downloading disk images retc
<DocScrutinizer05> etc, like starting virtualbox, ssh into the box, and similar stuff
<DocScrutinizer05> it's pretty strange how Argentina fibertel hit the sack
lobito has joined #neo900
* DocScrutinizer05 ponders to run an X-server on our server
<enyc> DocScrutinizer05: Xvnc ?
<DocScrutinizer05> yep
<DocScrutinizer05> or just tunnel ssh -X
<enyc> DocScrutinizer05: anyway if you create a virtual machine via vagrant i can help with ppa install kicad and also how to build to packages i(and how to patch / create debian patched variants of source/binary packages)
<DocScrutinizer05> ssh -X devel@Neo900 kicad
<enyc> that will likely be very sloooooooooooooooooow over x11 over network
<DocScrutinizer05> it will be fast ebnough to allow wpwrak to configure kicad in the way he needs it
<enyc> i think from what he said there was no 'configure' needed per-se, just install ppa and install hat version of package to start with, off you go
<DocScrutinizer05> then everybody can download the VM disk image form server, which is way faster than uploading it to server when wpwrak does the install locally
<enyc> or indeed once you have your own vm copies just get updated deb's of kicad
<enyc> which makes it much easier to swap 'versions'
<enyc> not re-downloading whole vm ecah time or so
<DocScrutinizer05> sure, once we got same insatllation base everywhere, we can do same upgrades in sync everywhere
<enyc> it just needs to be amd64 ubuntu-xenial-variant i expect
<DocScrutinizer05> no idea
<enyc> i'd definetyl suggest trying to create a vagrant of ubuntu-mate 16.04(xenial long term support) 64bit
<enyc> and install the ppa as above, see what happens
<enyc> then i can show you the rebuild process
<enyc> also useful
<DocScrutinizer05> anyway time for me to have some food and possibly a nap, it's getting 'late' here, and I had my share of fun with two times installing kicad
<enyc> then work out good idea dont panic
<enyc> wowee -- looooads of build-dependencies but installing happily apparentyl can satisfy
luke-jr has quit [Ping timeout: 276 seconds]
<DocScrutinizer05> enyc: http://paste.opensuse.org/18446328
<DocScrutinizer05> oops, http://paste.opensuse.org/98841441
<enyc> ooooh
<enyc> it *looks* like the ubuntu xenial variant can be built on devuan-jessie
<enyc> about to find out.. =)
<enyc> waiting for build-deps to finisd installing ia package system
<enyc> DocScrutinizer05: you ready to use that vagrant instance for building -- it install a LOT of packages -- some keep theing build chroot separtae from where they 'use' package but i suspect that sharing is not an issue here
<DocScrutinizer05> I can just give it a try
<enyc> DocScrutinizer05: ok for starters "apt-get install dpkg-dev fakeroot" <- standard stuff for building/compiling in short
<enyc> devscripts could be useful later if using dpkg-source and all that to sign changes of source package
<DocScrutinizer05> after apt-get update it seems to work
<DocScrutinizer05> done
<enyc> now... there are neater ways to do this but...
<enyc> get most of dependencies first
<enyc> apt-get build-dep kicad
<enyc> (this may only get the deps for the version in debian jessie, but that gets much of them)
<enyc> obviosuly you could just "apt-get install kicad" but then that gets the jessie version, which isn't what you wanted i think
<enyc> press enter (y)
<enyc> will install much of the build dependencies
<DocScrutinizer05> done
<enyc> now heres the horribly ack i did but apparently succcessfully
<enyc> add to /etc/apt/sources.list :-
<enyc> and apt-get update -- it will complain about key
<DocScrutinizer05> hmm, I wonder if that works in devuan, but prolly should
<enyc> it would (outwardly) appear its possible to compile that xenial (ubuntu LTS) version of kicad source on devuan jessie (at least according to published dependencies)
<enyc> if that doesn't work you could create an ubuntu-mate-16.04 vagrant and try that of course
<DocScrutinizer05> root@devuan:~# cat >/etc/apt/sources.list.d/xenial.list
<DocScrutinizer05> deb-src http://ppa.launchpad.net/js-reynaud/kicad-4/ubuntu xenial main
<enyc> error > overrites file
<enyc> >> neded to append to
<DocScrutinizer05> look closer!
<enyc> oh
<enyc> yes ;p
<enyc> NOTICE this is a 'deb-src' line
<enyc> i.e. source package files only
<DocScrutinizer05> aah yes
<enyc> and apt-get update
<enyc> now
<enyc> i reccomend/prefer creating a parallel login here and adduser compile and su - compile (do all compile work as a normal user) but you can use root if you prefer for some reason
<enyc> if using your VMs maybe running as root is fine anyway
<DocScrutinizer05> aah yepa warning: >>W: GPG error: http://ppa.launchpad.net xenial InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 83FBAD2D910F124E<<
<enyc> but, normally, debian packages can be built as any user with aid of fakeroot
<enyc> debian package building quite helpful and strict qa etc
<enyc> make decision, be in user account // directory reade to get source package
<enyc> then "apt-get source kicad" <- we may need to disable checking for key though
<enyc> of coruse the may be proper way to get the special ppa key but ... please try this for now first to learn
<DocScrutinizer05> compile@devuan:~$ id
<DocScrutinizer05> uid=1001(compile) gid=1001(compile) groups=1001(compile)
<enyc> good
<enyc> "apt-get source kicad" now as that user
<enyc> (normal users can get / build sources)
<enyc> i think you prably need apt-get --allow-unauthenticated source kicad
<DocScrutinizer05> yep
<DocScrutinizer05> done
<enyc> did that get from that ppa ? see url given
<DocScrutinizer05> http://ppa.launchpad.net/js-reynaud/kicad-4/ubuntu/ xenial/main kicad 4.0.2+e4-6225~38~ubuntu16.04.1
<enyc> good
<DocScrutinizer05> what's ppa?
<enyc> now as i said this is technically xenial package variant
<DocScrutinizer05> aah see it
<enyc> portable-package-archive iirc could be wrong
<enyc> anyway... cd kican-4.0.2+e4 (directory it created)
<enyc> "dpkg-buildpackage -rfakeroot -b" <- should try to compile it , but will fail on extra deps over the older jessie version
<enyc> you can (separately, as root, apt-get install the missing dependoncies)
<enyc> which brings in a lot more deps ;p
<enyc> as i said who knows if that kicad source veriso actually works with versions of everything in jessie ... it could well be perfectly fine
<enyc> obviously could create a 16.04=xenial actual ubnntu if needbe
<enyc> does that all make sense?
<DocScrutinizer05> yes
<enyc> if it compiles ok...
<enyc> you should get .deb files in parent directory
<enyc> as root, somebody can "dpkg -i *.deb" them (there may only be one possibly)
<enyc> notice source packages have one to many, may or may not build multiple binary packages
<enyc> of course the runtime-dependencies may not be satisfied, "apt-get -f install" or otherwise apt-get install'ing them may fix this of course
ashneo76 has quit [Quit: ZNC - http://znc.in]
<enyc> i have done many many cases of fiddling source packages and compiling across debian//ubuntu variants over the years with much success
<DocScrutinizer05> 9 upgraded, 366 newly installed, 0 to remove and 102 not upgraded.
<DocScrutinizer05> Need to get 899 MB of archives.
<DocScrutinizer05> After this operation, 1,693 MB of additional disk space will be used.
<enyc> ;p
<enyc> yep loads ;p
<enyc> but at least it is ''satisfiable'' without 'fiddling'
<enyc> sometimse you end up backporting +installing some other package too etc etc first
<DocScrutinizer05> jessie/main texlive-latex-extra-doc all 2014.20141024-1 [327 MB] o.O
<enyc> hehhe
<enyc> every... single.. little... thing ;p
<DocScrutinizer05> Fetched 899 MB in 7min 43s (1,940 kB/s)
<enyc> MAYBE for ''developing kicad'' itself would be better off with using the source tree (copy from there) separately somehow.. so can keep rerunning 'make' and not having to recomile *everything*
<enyc> but its good to learn how to patch / commit to debian 'source' package
<enyc> and build deb's using dpkg tools
<enyc> after much fiddling with source pkg's we got mythtv ppa so it works on debian/devuan/ubuntu many variants=)
<enyc> has to have sysvinit+upstart+systemd startup for mythbackend etc =)
galiven has quit [Quit: Konversation terminated!]
<enyc> DocScrutinizer05: btw -- http to package databases useful -- http://packages.debian.org/kicad http://packages.ubuntu.com/kicad <s worth knowing you can lookup like that
<DocScrutinizer05> ta
<enyc> i may simple have not researched rpm so far
<enyc> 'but just my expreince has been the deb ecosystem much more helpful
<DocScrutinizer05> builds
<enyc> as in, getting on with it?
<DocScrutinizer05> yep
galiven has joined #neo900
<enyc> mines at 36%
<enyc> anway i may have to leave you to it for a while, will see
<enyc> but given you enough to figue out getting that versonio from the ppa working i hope
<DocScrutinizer05> I should've pondered how to add a -j5 or sth
<enyc> paralle debuild is usually possible
<enyc> if use debuld -us -uc -b or whatever it is i can't remember exactly
<enyc> not hard to find out
<enyc> however i reccomend doing basic dpkg-buildpackage -rfakeroot -b first and see it ''works''
<enyc> i tred to paralle build something in a qemu chroot and it broke ;p qemu limitation/bug apparentyl, though
<DocScrutinizer05> well, it can take its time, I'm off to bed. Many thanks enyc
<DocScrutinizer05> :-)
<enyc> at least you've ''got started'' with deb world discovery
<enyc> the resutant .deb (may) only 'install' on jessie so not directly for sharing with xenial or trusty ubuntu users in most cases
<enyc> but there are ways to create 'source' packae variant, patch creation with dpkg-source and all this fun =)
<enyc> sleep ewells =)
galiven has quit [Quit: Konversation terminated!]
Defiant has quit [Ping timeout: 276 seconds]
galiven has joined #neo900
Defiant has joined #neo900
ashneo76 has joined #neo900
<DocScrutinizer05> http://paste.opensuse.org/49605413 :-S
herpderphurr has joined #neo900
xman has joined #neo900
xman has quit [Quit: Leaving.]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
pagurus has quit [Ping timeout: 276 seconds]
pagurus has joined #neo900
pagurus has quit [Remote host closed the connection]
pagurus has joined #neo900
illwieckz has quit [Quit: Ça va couper chérie…]
lkcl has quit [Ping timeout: 276 seconds]
lkcl has joined #neo900
<enyc> DocScrutinizer05:
<enyc> cc1plus: out of memory allocating 3143748 bytes after a total of 30662656 bytes
<enyc> DocScrutinizer05: ontop of an ubuntu-trusty *64bit* (with updated kernel out of xenial), I successfully compiled ppa-xenial-kicad, on devuan stable chroot
<enyc> DocScrutinizer05: same procedure as you did
<enyc> DocScrutinizer05: some amount of ''warnings'' when compiling where normal
paulk-collins has joined #neo900
R0b0t1_ has quit [Read error: Connection reset by peer]
ecloud has quit [Ping timeout: 260 seconds]
ecloud has joined #neo900
mordac has quit [Ping timeout: 246 seconds]
arcean has joined #neo900
<enyc> DocScrutinizer05: I wonder if your vagrant simply needs more ram allocated =)
mordac has joined #neo900
SylvieLorxu has joined #neo900
<DocScrutinizer05> yes
freemangordon_ has joined #neo900
<DocScrutinizer05> vb.customize ["modifyvm", :id, "--memory", "2048"]
<DocScrutinizer05> vb.gui = true ;also nice
<DocScrutinizer05> yes, I prolly should try to get amd64
<enyc> DocScrutinizer05: yes
<enyc> DocScrutinizer05: NOTE, it may be possible to install a 64-bit kernel while keeping 32bit opensuse userland
<enyc> DocScrutinizer05: which should then allow chroot or virtual-starting 64bit 'guest'
<DocScrutinizer05> I just started a compile run, will wait until that finishes
<DocScrutinizer05> my host system (suse) is 64b
<enyc> aaah ok just your vagrant thingue selected 32bit hrrm ok
<DocScrutinizer05> just the vagrant box is i586
<enyc> debootstrap normally follows host architecture anyway
<enyc> qemu-debootstrap however .... can do allsorts cross mixing chaos ;p
<DocScrutinizer05> that's my concern :-)
<enyc> not a PROBLEM at all tbh
<enyc> e.g it doesn't use qemu if it doesn't need to (e.g. running i386 inside amd64)
<atk> Are you still trying to get kicad to work?
<enyc> ARM (armhf and armel compatible) emulation WORKS
<DocScrutinizer05> I guess the KiCAD build will be 32b
<DocScrutinizer05> hah, thunderstorm
<enyc> DocScrutinizer05: test that, though i'd reccomend making a 64bit vagrant / build now you have all the clues what to do
<enyc> DocScrutinizer05: then you will be in situation you can rebuild it yourself one way or another
<DocScrutinizer05> yes, that's why I said >>yes, I prolly should try to get amd64<<
<DocScrutinizer05> aiui vagrant, it's just a matter to comment config.vm.box = "http://vagrant.devuan.org/devuan-jessie-i386-alpha2.box" and uncomment # config.vm.box = "http://vagrant.devuan.org/devuan-jessie-amd64-alpha2.box"
<DocScrutinizer05> but that will nuke my complete box I guess
<DocScrutinizer05> meh, practizing builds experience
<DocScrutinizer05> ;-P
<DocScrutinizer05> I guess I could port the shell history
<DocScrutinizer05> actually I should write a job for building anyway
<DocScrutinizer05> what sucks is the dpkg-buildpackage -rfakeroot -b command nuking resp not resuming on all already build interim binaries
<DocScrutinizer05> s/build/built/
bemyak has joined #neo900
<enyc> no indeed thats for building redistributable packages consistently
<enyc> if doing interim-work, just compile // make it (chcek what commands they are using, of course)
<enyc> main thing is its been conviencet to get all the correct build deps sorted
<enyc> and able to "pull" from the same repo wpwrak been using
<enyc> (though, i don't know if wpwrak been using 16.04xenial or 14.04trusty ...)
<enyc> also, now you've apparently got the right 'build environment' you can equually manually pull from git/svn/nightlies/etc source from upsteam directly and build that, if that later helps
<DocScrutinizer05> :-)
<DocScrutinizer05> default: Progress: 3% (Rate: 614k/s, Estimated time remaining: 0:16:43)
<DocScrutinizer05> then writing scripts to automate the manual work done yesterday. Will be fun to get all the packages to install out of the error message
<DocScrutinizer05> sidenote: [ 75%] Building CXX object pcbnew/CMakeFiles/_pcbnew.dir/menubar_pcbframe.cpp.o
<DocScrutinizer05> a 2GB RAM helps a lot ;-)
<DocScrutinizer05> I wonder if wpwrak will eventually come back
<enyc> hopefully =) patience =)
arcean has quit [Read error: Connection reset by peer]
rjeffries has quit [Read error: Connection reset by peer]
<DocScrutinizer05> enyc: http://paste.opensuse.org/52477568
<enyc> DocScrutinizer05: under dpkg-buildpackage -rfakeroot -b ??
<DocScrutinizer05> yes
<enyc> not sure
<enyc> my build in a devuan chroot worked fine
<enyc> i had updated all the devuan packages to jessie-updates / jessie-security etc first
<enyc> using 64bit chroot
<DocScrutinizer05> nfc
<DocScrutinizer05> looks good, yes
<enyc> silly question did it run out of space?
<DocScrutinizer05> during a copy? ahh on disk?
<enyc> yes diskspace ;p
<DocScrutinizer05> MEH! yep
* enyc places dunce's cap on DocScrutinizer05
<DocScrutinizer05> lol :-P
<enyc> provide more space in 64bit box
<enyc> not forgetting the ram either
<enyc> [these things don't happen if just use a chroot.... but anyway...]
<DocScrutinizer05> yes, but I don't want to use a debian chroot on a RPM system
rjeffries has joined #neo900
<DocScrutinizer05> nightmare to even set up
<enyc> DocScrutinizer05: oh? they shouldn't ''conflict'' at all -- package systems working in separate locations
<enyc> all you are trying to 'share' is any access to working-files
<enyc> i'hve had debian bits within an ancient suse box in past etc etc
<DocScrutinizer05> I need a complete system, incl all libraries and cmdline tools
<enyc> yes, which works fine with chroot
<DocScrutinizer05> anyway, how to tell that friggin virtualbox to extend the virtual hdd?
<enyc> but anyway .... expand discspace AND ram in your 64bit vagrant and try build in htere
<enyc> DocScrutinizer05: im not sure i've ever done it that way.... vboxmanage and the like might be able to fiddle existing vhd disk image
<enyc> or use qemu-img tools to convert from one type to another then exand then back again
<DocScrutinizer05> first lemme check size, to start with
<DocScrutinizer05> Filesystem Size Used Avail Use% Mounted on
<DocScrutinizer05> /dev/dm-0 7.2G 6.8G 924K 100% /
<DocScrutinizer05> -->fail
<DocScrutinizer05> root@devuan:~# df -h
<DocScrutinizer05> Filesystem Size Used Avail Use% Mounted on
<DocScrutinizer05> /dev/dm-0 7.2G 903M 5.9G 14% /
<DocScrutinizer05> damn, exactly same
<enyc> if there are no virtualbox 'snapshots' you can probable just use VBoxManage modifyhd <absolute path to file> --resize <size in MB>
<enyc> then you will need to use dm-tools etc etc to resize that device mapper
<enyc> which is presumably backed by a /dev/xvda or /dev/sda sort of virtual hardware disk thingamiwodgit
<enyc> of course, vagrant might provide some wrappers//tools to help (investigate!)
<DocScrutinizer05> vagrant docs are not very in-depth with any of that stuff
<enyc> so... backup and then resize that vhd file
<enyc> obviosly stop/turn-off the virtual moachine first!
<DocScrutinizer05> or rather, I didn't find the canonical location for manpages yet
<enyc> reboot virtual machine with resized disk, show me 'fdisk -l' then too
<enyc> i suspect /dev/sda2 is the device-mapper partition?
<enyc> do that 'fdisk -l' now if you havent turned it off already
<DocScrutinizer05> http://termbin.com/mnat note the provider /VBox) specific config stuff
<DocScrutinizer05> vb.customize ["modifyvm", :id, "--memory", "2048"]
<DocScrutinizer05> in vagrant 'docs' I wasn't even able to spot >>vb.gui = true<<
<enyc> i don't *think* virtualbox gui will help you
<enyc> boot it quickly and check "fdisk -l" for me?
<enyc> show me the test list contents of the box file too --- 8z t http://paste.opensuse.org/49486081
<enyc> oops
<enyc> 7z t FILENAME.box
<enyc> so they really are using a logical-volume-manager partition on that single virtual disk
<enyc> the QUESTION is --- is this (a) setup at vagrant local installation of machine time -- in which case can rebuild it with different config
<DocScrutinizer05> the .box file gets nuked after box initialized
<enyc> OR --- (b) does the box file contain a pre-prepared fixed-size disk-image, and we will need to actually resize from that ?
<enyc> well get the box file or logon to server where it is, test list it... 7z t filename.box
<enyc> or tar tvzf or zip --whatever-papameter-it-is ...
<enyc> we see if it actually just came with the vdi or what
<DocScrutinizer05> or (c) could we mount an additional diskimage on host into the vbox
<enyc> yes, can do too... which you can do via virtualbox gui
<DocScrutinizer05> downloading the file takes 20 min
<enyc> to do (b) will need vboxmanage resize, parted resize (lvm container partition), and lvm internal resize, and ext4 online resize -- all very doable tbh just a case of figuring out
<enyc> yes, see what a .box comes with anyway =)
<enyc> its a zip or tar.gz or similar
<enyc> 7z t filename (if p7zip installed) will just do it ...
<enyc> so we get file name/size listing
<DocScrutinizer05> doesn't look much like any compressed format
<enyc> ok and ... the 7z t on the file list ?
<enyc> tar maybe
<enyc> tar tvf file.box
<enyc> or, as a said, 7z t file.box
<DocScrutinizer05> tar tvf devuan_jessie_1.0.0-beta_amd64_vagrant.box
<DocScrutinizer05> -rw------- jrml/jrml 1675 2016-04-25 17:54 ./vagrant_private_key
<DocScrutinizer05> -rw------- jrml/jrml 695716864 2016-04-25 17:54 ./box-disk1.vmdk
<DocScrutinizer05> -rw-r--r-- jrml/jrml 630 2016-04-25 17:54 ./Vagrantfile
<DocScrutinizer05> -rw------- jrml/jrml 11022 2016-04-25 17:53 ./box.ovf
<enyc> RIGHT ok now we know
<enyc> it really is a pre-prepared disk image in vmdk format
<enyc> using vmdk internal spaseness
<DocScrutinizer05> sparseness yes
<enyc> but spareseness could also be done on host filesystem, or compressed zeros if tar.gz/zip/etc etc
<enyc> anyway now you know
<DocScrutinizer05> no path ahead though
<enyc> (b) or (c) above
<enyc> I suggest trying to get virtualbox gui to just add another hdd to the vm
<enyc> then get that mounted, make directory owned by 'compile' user etc etc
<DocScrutinizer05> du -h|sort : http://paste.opensuse.org/83326129
<DocScrutinizer05> >>file INSTALL cannot ***copy*** file...<<
<DocScrutinizer05> do I *really* want that crap twice on my disk?
<enyc> you may be able to 'squeeze' some space with (a) apt-get clean and (b) deleting downloaded source package, just leaving extracted directory
<enyc> it copies to temp location setting up the tree to make package
<DocScrutinizer05> :nod: what I thought
<enyc> thats quite normal
<enyc> but you really don't want to be worknig with such a small vm space
<enyc> its going to be ongoing annoyance unnecessary limitation/waste of time
<enyc> you need more space in there or do the chroot thing instead
<DocScrutinizer05> 8GB = small?
<DocScrutinizer05> lol
<enyc> yes as you start copying / backup copies of source tree / etc etc
<DocScrutinizer05> this isn't meant to be a build server
<enyc> no, you could use a chroot for building and a vm for running
<enyc> for your usage case id be happy to have a larger vm to 'do both'
<DocScrutinizer05> actually I dunno if I want a installation anyway, rather use local binary in user's homedir
<enyc> possible too, but
<enyc> better to let dpkg build it and TEST it first before messing about
<enyc> then you can try other approaches for 'nistall' which make kicad development itself easier
<enyc> but need to show that their build with dpkg provided compile flags etc etc even *works*
<DocScrutinizer05> we're not that much interested in kicad development, we just need to make sure we *could* patch it when we needed
<enyc> yes
<enyc> which if you can build it and run it...
<enyc> but you need to add disk now, or try squeeze with apt-get clean now,, to let it complete build...
<DocScrutinizer05> for now my aim is to build a working kicad binary and run it, in that VM
<enyc> and just TRY the deb package built 'as is' *first*
<enyc> yes
<enyc> so
<enyc> either add a virtual disk now using virtualbox gui and i show you how to mount it
<enyc> or -- apt-get clean may well be enough!
<enyc> thinking about how many package files got downloaded
<DocScrutinizer05> I'll try redo the whole process on amd64 VM
<enyc> yes
<DocScrutinizer05> that ione is still clean
<enyc> yes
<enyc> but after installing all the dependencies (both passes)
<DocScrutinizer05> and I'll try to already wrap the whole build process into a script
<enyc> run "apt-get clean" which deletes all the downloaded .deb files
<DocScrutinizer05> I'll run apt-get clean now in the 32-VM
<enyc> check how much freed up
<DocScrutinizer05> then restart that hours-eating compile
<enyc> /var/cache/apt/archives ....
<enyc> might 'just be enough'
<DocScrutinizer05> apt.get clean does nothing
<enyc> it should give no response
<enyc> but free up space
<enyc> clears out /var/cache/apt/archives
<DocScrutinizer05> returns after 0.01s without any diag output or freeing up any space
<enyc> df will have changed ;p
<DocScrutinizer05> nope
<enyc> du -hs /var/cache/apt/archives
<DocScrutinizer05> ooh well, it changed Avail: 924K to 976M - didn't notice
<enyc> there you go
<enyc> given how late the compile failed...
<enyc> that may just be enough
<enyc> it was just copying completed binaries to temp locations to tar up the completed deb etc
<DocScrutinizer05> I still wonder if there's no way to nuke or just *test* the already succeeded build
<enyc> no idea but i wouldn't worry
<enyc> just let it run
<enyc> we dont want the unknown of half-completed etc etc
xman has joined #neo900
<DocScrutinizer05> a 900MB are for sure not enough to copy a 5GB
<enyc> the completed deb is 14m for amain kicad
<enyc> and 260m for kicad-dbf
<enyc> err dbg
<enyc> so it should be fine i suspect
<DocScrutinizer05> hmmph
<DocScrutinizer05> ok
<enyc> i'd probably delete the extracted directory, then run apt-get source kicad again (as compile user)
<enyc> it will say 'skipping already downloaded file' and extract it
<enyc> we just, want a known, clean, apparently workable, build!
<enyc> I WOULD be tempted to dpkg-buildpackage -rfakeroot -b > ../kicad_4.0.2+e4-6225~38~ubuntu16.04.1.binary-build.log 2>&1
<enyc> so we keep copy of the build messages along with created .deb's
<DocScrutinizer05> ok
<DocScrutinizer05> to the latter, no idea how to do the former
<enyc> you just need to a) delete the extracted kicad directory
<enyc> b) as user compile, in that location "apt-get source kicad" -- it will re-extract source having said 'skipping already downloaded file' etc
<DocScrutinizer05> ok, so rm -r kicad-4.0.2+e4
<enyc> c) cd into that directory, and dpkg-buildpackage -rfakeroot -b > ../kicad_4.0.2+e4-6225~38~ubuntu16.04.1.binary-build.log 2>&1
<DocScrutinizer05> http://paste.opensuse.org/18220959 no dice
<enyc> oh
<enyc> we used --allow-unauthenticated iirc
<DocScrutinizer05> aah yes
<DocScrutinizer05> yep
<enyc> nb: for future ref you can do "dpkg-source -x kicad_4.0.2+e4-6225~38~ubuntu16.04.1.dsc" sort of thing extracting sources from dsc file directly iirc but carry on as you were
<DocScrutinizer05> http://paste.opensuse.org/23273651 OK?
<enyc> looks promising though you'd need some other terminal to tail -f the log
<DocScrutinizer05> got that
<enyc> should work with any luck =)
<enyc> HOPEFULLY it will 'just' squeeze inside size limitations
xman has quit [Remote host closed the connection]
<enyc> but I really really really think you need to get more _space_ in 64bit box to be sensible
<enyc> in any case seeing kicad builds/installs/works on devuan following standard deb approach like that will be very helpful start
<DocScrutinizer05> how about dpkg-buildpackage -rfakeroot -b &|tee -a ../kicad_4.0.2+e4-6225~38~ubuntu16.04.1.binary-build.log
<enyc> probably ... theresa spurious & in there and you need 2>&1 in there SOMEWHERE so not sure
<enyc> use what you first gave, that will certainly work i think
<enyc> and catch both stdout+stderr in same file correctly
<DocScrutinizer05> err sorry
<DocScrutinizer05> how about dpkg-buildpackage -rfakeroot -b 2>&1 |tee -a ../kicad_4.0.2+e4-6225~38~ubuntu16.04.1.binary-build.log
<enyc> PROBABLY
<enyc> but not 100% sure not tried that lately
<DocScrutinizer05> I guess it should work
<enyc> HOPEFULLY
<enyc> =)
<enyc> let that get on
<enyc> if you can do it, at the same time, start adding disk image to the 64bit box anyway
<DocScrutinizer05> how would I do that?
<enyc> looking in history...
<enyc> 15:33 < enyc> I suggest trying to get virtualbox gui to just add another hdd to the vm
<DocScrutinizer05> hmmm
<enyc> the 64bit vm should be shut-down, then add disk, basically... create it for you and everything
xman has joined #neo900
<enyc> you can go to disk management and all that
<enyc> add new disk -- create new disk from scratch -- etc
<enyc> easy
<enyc> then... fdisk and mkfs.ext4 and edit /etc/fstab and mount ....
<DocScrutinizer05> that would imply I manage that VM via VBox GUI
<enyc> hrrm i suspect you can do it that way if you just launch virtualbox
<DocScrutinizer05> >>config.vm.synced_folder - Configures synced folders on the machine, so that folders on your host machine can be synced to and from the guest machine. Please see the page on synced folders for more information on how this setting works.<<
xes has quit [Ping timeout: 272 seconds]
<enyc> DocScrutinizer05: you could try that approach too =)
<enyc> DocScrutinizer05: but that sounds synced not *shared*
<enyc> DocScrutinizer05: network mounted smb shared is a reasonable approach
<enyc> DocScrutinizer05: but if you are doing all that.... i'd probably just do the whole resize vmdk thing instead =)
xes has joined #neo900
<enyc> I'm not 100% sure
<enyc> i'm guessing tat is 'mount a directory on the host in the guest' -- in which case that could work
<enyc> given they mention oand ssh and nfs .....
<enyc> err -oand
<enyc> that sounds promising
<DocScrutinizer05> yes
<enyc> virtualbox itself calls this 'shared folders' rather than 'synced' which i consider misnomer
<enyc> i note that build-log will hopefully contain gems like what flags debian build is calling ./configure with etc...
<enyc> which will be useful for quicker manual builds/rebuilds if you have to do kicad devel
<DocScrutinizer05> now it gets nasty
<enyc> hrrm
<enyc> i think its likely as simple as Please verify that
<enyc> the guest additions are properly installed in the guest
<enyc> they may well just not be
<enyc> virtualbox guest additions for linux
<enyc> depending on your virtualbox install, you may have an iso image available
<DocScrutinizer05> yes, been there tried that, when VM GUI was up. "install extensions" -> "No CD drive available in VM, please install CD"
<enyc> e.g. using debian//ubuntu packages for virtualbox has a virtualbox-guest-addinions-iso package that provides exactly that
<enyc> yes, go to disk drives, add a chrom drive, then do that
<enyc> then we can mount that maunally easily (support will be in the kernel etc already) and go from there
<DocScrutinizer05> again, needs management via VBox utils
<enyc> you can probably just launch "VirtualBox" or "virtualbox" binary to get the gui up
<enyc> its just a sort of frontend to manage vms running in backend basically
<DocScrutinizer05> yep
<DocScrutinizer05> been there done that, but it sucks from a vagrant perspective
<DocScrutinizer05> you can't manage a ruining machine, regarding *any* config
<DocScrutinizer05> you need to stopit first
<enyc> hrrm no but then i guess this is a fiddly/hard problem ?
<enyc> yes do that, stop the 64bit machine (obviously leave the 32bit machine compiling away =) )
<DocScrutinizer05> in which case the window with the VB menus disappears
<enyc> restart virtualbox gui ?
<enyc> you should get a list of virtual machines ? right click on one and say 'settings' etc
<enyc> if this approach doesn't work... dont panic, we use any other method available to us to copy iso in there (including http transfer) and loopback mount to access its contents instead
Pali has joined #neo900
<DocScrutinizer05> https://www.virtualbox.org/manual/ch04.html https://www.vagrantup.com/docs/virtualbox/boxes.html >>VirtualBox Guest Additions must be installed so that things such as shared folders can function. Installing guest additions also usually improves performance since the guest OS can make some optimizations by knowing it is running within VirtualBox.<<
<enyc> yes
<DocScrutinizer05> sudo apt-get install linux-headers-$(uname -r) build-essential dkms
<enyc> yes
<DocScrutinizer05> gonna fire that now
<enyc> but have you attached the iso image to the vm somehow????
<enyc> if not can do loopback mount approach having copied it in there
<enyc> To install via the GUI:
<enyc> Next, make sure that the guest additions image is available by using the GUI and clicking on "Devices" followed by "Install Guest Additions". Then mount the CD-ROM to some locatio
<enyc> yes, which you said gave error no cd drive
<enyc> did you succeed in adding cd drive, and then doing "install guest additions" ????
<DocScrutinizer05> just about to follow the instructions
<enyc> yes, it tells you to do the same thing i already pointed at -- click the install guest additions button
<DocScrutinizer05> >> Before installing the guest additions, you will need the linux kernel headers and the basic developer tools. On Ubuntu, you can easily install these like so: $ sudo apt-get install linux-headers-$(uname -r) build-essential dkms<< which is still running
<enyc> yes that will also need to happen before we can actually do the ./run part
<enyc> but in any case can attach the cdrom image to that vm, which needs adding a cd drive to that vm, (when shut down) with any luck
<DocScrutinizer05> >> To install via the command line: You can find the appropriate guest additions version to match your VirtualBox version by selecting the appropriate version here. The examples below use 4.3.8, which was...<<
<enyc> yes you can go wget it if plan a doesnt work
<enyc> it should already be provided in your system
<enyc> that commandline example is doing loopback-mount, as i was also suggeshing
<enyc> what virtualbox version do you have on your opensuse // vagrant setup ?
<DocScrutinizer05> cat .vbox_version
<DocScrutinizer05> 5.0.18
<enyc> oooh good recent ish
<enyc> well anyway... you have 2 paths you can try to get the iso in there
herpderphurr has quit [Ping timeout: 264 seconds]
<enyc> that approach hopefully will work =)
<enyc> easier
<enyc> loopback mount
<enyc> ....
<enyc> then install, then you *may* need to reboot the vm, and then can mount your shared folder =)
<enyc> interesting they are using a virtualbox-specific hypervisor style virtual file access system (but thats good//efficient)
<DocScrutinizer05> ==> default: Mounting shared folders...
<DocScrutinizer05> default: /vagrant => /home/jr/vagrant-test/kicad-devuan-amd64
<DocScrutinizer05> default: /home/compile/kicad => /home/jr/vagrant-test/kicad-devuan-amd64/tmp
<enyc> yay
<enyc> so... :- apt-get build-dep kicad (gets a lot of dependencies against the debian jessie version of kicad)
<DocScrutinizer05> root@devuan:~# df -h /home/compile/kicad/
<DocScrutinizer05> Filesystem Size Used Avail Use% Mounted on
<DocScrutinizer05> home_compile_kicad 1.6T 793G 847G 49% /home/compile/kicad
<enyc> also install "dpkg-dev fakeroot" anyway (includes building and source-extracting tools)
<enyc> thats a way to do it ;p
<enyc> apt-get update apt-get dist-upgrade, shutdown, make backup copy of VM first ???
<enyc> up to you etc
<DocScrutinizer05> apt-get update was already necessary
<enyc> okies -- ready to just install everything build dependencies ?
<DocScrutinizer05> I'll do a apt-get dist-upgrade now, I think. Sounds reasonable
<enyc> yes
<enyc> get all 'jessie' updates
<enyc> checking what devuan put in their /etc/apt/sources.list may be sensible
<enyc> at least when creating debootstrap chroots' you don't always get security-updates etc by default
<DocScrutinizer05> hmm, maybe I consider that step not safe, for now. See #devuan /topic
<enyc> ok
<enyc> so don't for now
<DocScrutinizer05> :nod:
<DocScrutinizer05> so next: adduser
<DocScrutinizer05> ?
<enyc> just "apt-get build-dep kicad" (to get bulk of build-deps according to debian )
xes has quit [Ping timeout: 260 seconds]
<enyc> adduser when you like too good step
<enyc> "apt-get install fakeroot dpkg-dev" <- debian building / source extracting tools
xes has joined #neo900
<DocScrutinizer05> fakeroot is already the newest version.
<DocScrutinizer05> fakeroot set to manually installed.
<DocScrutinizer05> :-)
<enyc> add the sources.list.d entry same as other m
<enyc> vm
<DocScrutinizer05> aah yep
<enyc> apt-get update
<enyc> it will complain about key
<enyc> then, as the user, change to the special /home/compile/kicad directory
<enyc> iirc something like "apt-get --allow-unauthenticated source kicad"
<enyc> then... hopefully you can ...cd into source ... run the dpkg-buildpackage directed to logfile... and watch it fail but tell you what you need to install ...
<enyc> then start build directed to logfile again ....
<DocScrutinizer05> o.O http://termbin.com/gofu
<DocScrutinizer05> wait, maybe I mustn't write to that dir?
<DocScrutinizer05> also wrong dir to start with
<DocScrutinizer05> damn! I guess wrong mount options, eh?
<DocScrutinizer05> root@devuan:/home/compile# ls -ld *
<DocScrutinizer05> drwxr-xr-x 1 root root 0 Jul 13 15:19 kicad
<DocScrutinizer05> home_compile_kicad on /home/compile/kicad type vboxsf (rw,nodev,relatime)
<DocScrutinizer05> (mount)
<DocScrutinizer05> afk, need some chilling
<DocScrutinizer05> meanwhile: http://paste.opensuse.org/50601713
<DocScrutinizer05> root@devuan:/home/compile# mount -t vboxsf -o rw,nodev,uid=1001,gid=1001 home_compile_kicad /home/compile/kicad
<DocScrutinizer05> \o/
<enyc> DocScrutinizer05: so...
<enyc> DocScrutinizer05: see above group of comments
<enyc> dpkg-buildpackage -rfakeroot -b 2>&1 |tee -a ../kicad_4.0.2+e4-6225~38~ubuntu16.04.1.binary-build.log
<enyc> it should stop and complain about deps... which you can fix... then run again which will then restart log and hopefully work =)
<DocScrutinizer05> yes
<DocScrutinizer05> already there
<enyc> yay useful
<enyc> also -- apt-get clean at some point not then a bad idea just for vm cleanliness
<enyc> (but should have enough space)
<enyc> is the 32bit vm//build still going?
<enyc> ooooooh tee -a would mean append.. you woul get that first failed run in top of log (not a big problem tho)
<DocScrutinizer05> dpkg-buildpackage -rfakeroot -b 2>&1 |grep 'dpkg-checkbuilddeps: Unmet build dependencies: '|sed 's/dpkg-checkbuilddeps: Unmet build dependencies: \(.*\)/\1/'
<enyc> have to get rid of those () sections in there but ready to put on apt-get install
* DocScrutinizer05 idly wonders if apt-get will chocke on the 'garbage' like (>= 2.6.0) in there
<DocScrutinizer05> :-D
<enyc> yes it will
<DocScrutinizer05> ok, so let's kill them
<enyc> but no matrter easy tofix manually for this case
<enyc> NB: check no build log, or take the "-a" out of the tee command, before starting for real
<enyc> so we just get one, clean, build log, none of the 'failed fist go'
<DocScrutinizer05> dpkg-buildpackage -rfakeroot -b 2>&1 |grep 'dpkg-checkbuilddeps: Unmet build dependencies: '|sed 's/dpkg-checkbuilddeps: Unmet build dependencies: \(.*\)/\1/; s/(.*)//g'
<DocScrutinizer05> debhelper doxygen libbz2-dev libcairo2-dev libglu1-mesa-dev libgl1-mesa-dev libglew-dev libx11-dev libwxbase3.0-dev libwxgtk3.0-dev mesa-common-dev pkg-config libssl-dev bzrtools cmake-curses-gui python-wxgtk3.0 python-dev swig python-wxgtk3.0-dev libwxgtk-webview3.0-dev dblatex po4a asciidoc source-highlight libboost-all-dev
<enyc> apt-get install ;p
<enyc> dont ned to tell me all just get it going
<enyc> not sure if you saw about log appending
<DocScrutinizer05> apt-get install `dpkg-buildpackage -rfakeroot -b 2>&1 |grep 'dpkg-checkbuilddeps: Unmet build dependencies: '|sed 's/dpkg-checkbuilddeps: Unmet build dependencies: \(.*\)/\1/; s/(.*)//g'`
<enyc> yes you get idea...
<DocScrutinizer05> yes, seen it
<enyc> trouble is that won't work because you'd need sudo or something -- need to do the apt-get bit as root
<enyc> just copy the packagelist to install manually, its only a once-off, not part of repeated builds
<enyc> is it building away now?
<DocScrutinizer05> dang! I fail to run apt-get install under root while getting correct output from dpkg-buildpackage under user:compile
<DocScrutinizer05> for sudo compile isn't in sudoers, with su no dice, I'm too tired, should have a break
<enyc> there are special tools like dpkg-checkbuilddeps and things to do clever stuff
<enyc> BUT
<DocScrutinizer05> ooh you already noticed that too
<enyc> DONT BOTHER -- just run apt-get as root now
<enyc> and then get it building away while you break
<DocScrutinizer05> I need to write a script in parallel, for next time
<enyc> i wouldn't *try* to automated it like that... there are pbuilders and allsorts for this that have lal that sorted already
<enyc> if you want to write a completed scrpt you'd investigate dpkg-checkbuilddeps and pbuilder tools that create the build chroots automatically etc etc
<DocScrutinizer05> this can't be that hard to fix this silly little troule
<enyc> yes you could execute as root a command that does "su - compile" or similar
<enyc> but it really will be a timesink fiddle if brain not clear now
<enyc> whereas you can just apt-get install ... and run the build and leave it going
<DocScrutinizer05> ooh, you got a point in it being a one-off
<enyc> put a comment in scrept
<enyc> yes indeed
<DocScrutinizer05> already did (put comment in script)
<enyc> yes so...
<enyc> did you install the packages now?
<DocScrutinizer05> 2 upgraded, 493 newly installed, 0 to remove and 23 not upgraded.
<DocScrutinizer05> Need to get 936 MB of archives.
<DocScrutinizer05> After this operation, 1,997 MB of additional disk space will be used.
<DocScrutinizer05> Do you want to continue? [Y/n]
<DocScrutinizer05> this will take a while
<enyc> so... get another login as compile user ready
<DocScrutinizer05> already got that
<enyc> just do a sleep 25m; dpkg-buildpackage -rfakeroot -b 2>&1 |tee ../kicad_4.0.2+e4-6225~38~ubuntu16.04.1.binary-build.log
<DocScrutinizer05> as simple as vagrant ssh
<enyc> then it will start in 25mins when download hopefully done ;p
<enyc> or wait for it asnd start it, or something
<enyc> anyway
<enyc> s the 32bit vm // builder going ok still without runnig out of space too ?
<DocScrutinizer05> compile@devuan:~$ sleep 25m && dpkg-buildpackage -rfakeroot -b 2>&1 |tee -a ../kicad_4.0.2+e4-6225~38~ubuntu16.04.1.binary-build.log
<enyc> err you've still got -a
<DocScrutinizer05> [2016-07-13 Wed 18:34:01] <DocScrutinizer05> meanwhile: http://paste.opensuse.org/50601713
<enyc> append to partial build log not good idea would rather have one clean log
<DocScrutinizer05> I'll cut it for you
<enyc> ok so 32bit got fucrther but still ran out of space? oh well
<DocScrutinizer05> yep
<enyc> ;p
<enyc> matters less now anyway, only need 64bit build
<enyc> useful learning for you
<enyc> can you upload/paste the 32bit build log (not just the end of it) ?
<enyc> curious to see beginnning bits
<DocScrutinizer05> sure thing
<DocScrutinizer05> compile@devuan:~/kicad-4.0.2+e4$ cat ../kicad*log|nc termbin.com 9999
<DocScrutinizer05> http://termbin.com/z2dw
<enyc> hrrrrrrrrrrrrrrrm
<enyc> doesn't show an obvois ./configure per-se
<enyc> but uses debhelper's dh_auto_configure
<DocScrutinizer05> sorry, time to really have a break now
<enyc> in ANY case -- I suspect the completed build-tree is usable as something you can just re-run "make" from
<enyc> yes
<enyc> you will have workable 64bit build when you finally get back hopefully =)
<DocScrutinizer05> :-)
<DocScrutinizer05> ack
<enyc> hope you eventually benefitted from apt//dpkg fun learning eventually
<enyc> very useful
<DocScrutinizer05> yes, a lot
<DocScrutinizer05> many thanks
<DocScrutinizer05> never made it beyond apt-cache search so far
<DocScrutinizer05> I gonna stop the 32b VM, eats 2GB of valuable RAM, makes kswapd of host go bonkers
<DocScrutinizer05> RAM usage of host sudden drop 87% to 60%
<DocScrutinizer05> apt-get install finished
<DocScrutinizer05> starting build manually now
<DocScrutinizer05> and off we go
<DocScrutinizer05> /home/compile/kicad/kicad-4.0.2+e4/kicad/polygon/clipper.cpp:3680:13: warning: unused variable ‘firstLeft’ [-Wunused-variable]
<DocScrutinizer05> OutRec* firstLeft = ParseFirstLeft(outRec->FirstLeft);
<DocScrutinizer05> ^
xes has quit [Ping timeout: 240 seconds]
xman has quit [Remote host closed the connection]
<DocScrutinizer05> 71%
xes has joined #neo900
R0b0t1 has joined #neo900
<R0b0t1> Wizzup, did I show you pics of my s4 with hacked baseband
<R0b0t1> Rizon klines me on join from this IP
<DocScrutinizer05> [ 89%] this VM builds slower than the 32bit VM?
wpwrak has joined #neo900
<DocScrutinizer05> WOW!
<DocScrutinizer05> wpwrak: welcome back! I already worried
<DocScrutinizer05> /dev/dm-0 7.2G 4.2G 2.7G 61% / ;; apt-get clean ;; /dev/dm-0 7.2G 3.2G 3.7G 47% /
<DocScrutinizer05> 90%
<wpwrak> yeah, decided i needed to cool off a bit when i found myself hitting the screen with the keyboard :)
<DocScrutinizer05> hey, you been inspired by a viral YT video
<wpwrak> ah yes, there's a nice one, too :)
<DocScrutinizer05> with a tad of luck we'll have a freshly build KiCAD in a devuan environment, in 60 min
<wpwrak> hehe, devuan even. nice :)
<DocScrutinizer05> thanks to awesome incredible help by enyc
<wpwrak> how bad is dependency hell these days ?
<DocScrutinizer05> manageable
<DocScrutinizer05> apt-get install `dpkg-buildpackage -rfakeroot -b 2>&1 |grep 'dpkg-checkbuilddeps: Unmet build dependencies: '|sed 's/dpkg-checkbuilddeps: Unmet build dependencies: \(.*\)/\1/; s/(.*)//g'`
<DocScrutinizer05> [2016-07-13 Wed 19:18:24] <DocScrutinizer05> 2 upgraded, 493 newly installed, 0 to remove and 23 not upgraded.
<DocScrutinizer05> [2016-07-13 Wed 19:18:24] <DocScrutinizer05> Need to get 936 MB of archives.
<DocScrutinizer05> [2016-07-13 Wed 19:18:24] <DocScrutinizer05> After this operation, 1,997 MB of additional disk space will be used.
<wpwrak> whoa ! 2 GB. someone has found a cheap source for disks ;)
<DocScrutinizer05> so yes, you wouldn't want to install those deps manually ;-D
<wpwrak> ah yes, "493 newly installed" :)
<DocScrutinizer05> I got an appointment with a "Schäuffele" in 30min, off to shower
<enyc> wpwrak: to be specific' the xenial version from the ppa you pointed out
<DocScrutinizer05> BBL
<enyc> wpwrak: which happily compiles against jessie version of everything, apparently
<wpwrak> in my (old, 2014-ish) notes for building kicad, i have "apt-get build-dep kicad". guess that's similar to what your command line does
<enyc> wpwrak: kindof, but that only gets the deps for deian repo version it authenticates properly...[3~
<R0b0t1> you have an appointment with a piece of meat?
<enyc> wpwrak: hence having to fiddle to get the extra deps for that ubuntu-xenial-ppa-repo variant of the source'
<R0b0t1> ...?
<R0b0t1> oh wit
<enyc> wpwrak: are you using amd64 arch xenial 16.04 ????
<wpwrak> (schaeuffele) google finds this: https://twitter.com/ceo_schaeuffele/status/641281722315853824
<wpwrak> enyc: yes
<enyc> wpwrak: ok well have to see if doc's built debs on devuan jessie work equivalently, at least
<enyc> the key thing is it has a configured build-tree, so is possible to fiddle/recompile kicad as desired, if required
<enyc> wpwrak: personally i didn't think a whole VM was needed, a chroot would do to avoid packaging systems getting confused/mixed, but anyay doc happily got a vagrant vm with virtualbox based shared folder ....
<wpwrak> yeah, i'd be a bit worried about gfx performance in a VM. you can quickly end up with a lot of things that need drawing, and performance issues that may not be noticeable on a native install (thus, nobody else even sees them) could be disastrous
<wpwrak> but let's see
<enyc> can always copy it out to chroot ... its all there, built, etc etc
<R0b0t1> if you emulate the processor it ends up being fine, if slow
<R0b0t1> iOS has problems as Apple opted to "simulate" the phone OS
<enyc> R0b0t1: =) using virtualbox doesnt simulate processor, will typically use virtualization extenisons etooo ... but otherwise paravirtualized pagetables andall that, but normal 'usermode code' is running natively
<R0b0t1> oh I thought this was of the phone
<enyc> R0b0t1: this is just about eda tools ;p
<R0b0t1> oh huh
<enyc> R0b0t1: or whatever the right wording is
<R0b0t1> should switch to gentoo
<R0b0t1> DocScrutinizer05: ^
<enyc> R0b0t1: some fun over linux distro versions and being able to compile//recompile//use consistent kicad version
<R0b0t1> yeagh
<enyc> R0b0t1: gentoo good and bad in all its' own ways too =)
<R0b0t1> I hate it. The least. :D
<enyc> R0b0t1: gentoo chroots' can be really handy for building latest stuff / nonstandard use flags etc... but generally a paint to maintain for security updates etc -- you ned up making your own rolling release
<enyc> R0b0t1: then thats fine for you
<R0b0t1> :p
<enyc> hybrid systetms can be really handy of cours for these reasons
<R0b0t1> I just make a vm for everything
<R0b0t1> I use qemu though
<enyc> fine
<enyc> qemu-kvm uses cpu extensions and kernel based hypervisor...
<R0b0t1> my focus was mainly security research, not other kinds of development
<R0b0t1> but can also softemulate
<R0b0t1> I misread the convo, thought it was about doing device development
<enyc> R0b0t1: hopefully wpwrak//DocScrutinizer05 will sort out kicad usability soon
<enyc> R0b0t1: project could do with some help writing artices for site explaining these decisions and feasibilyt to complete etc....
<R0b0t1> I need to give it a look again
<R0b0t1> if I see anything I can help with I'll jot something down
<R0b0t1> recently started working again
<enyc> R0b0t1: a lot ridse of wpwrak//DocScrutinizer05 being able to do the layout themselves via kicad *hopeuflly* or others' help with some altium variant or something
<R0b0t1> kicad can handle it, it's just boring as all hell
<R0b0t1> do I need to find a russian guy with an altium key or
<R0b0t1> there is azonenberg who idles in ##electronics and ##embedded
<R0b0t1> he can answer questions, about autorouting and stuff
<R0b0t1> he has made boards with high pincount FPGAs on them
trx has quit [Ping timeout: 244 seconds]
<wpwrak> (8 copper layers)
<wpwrak> hmm, seems that CERN is about to unleash "an exiting new feature" for kicad "very soon". wonder what they've cooked up this time :)
trx has joined #neo900
<wpwrak> meanwhile, if we want to stay compatible with the kicad-library project (the "official" library), these rules will be useful: https://github.com/KiCad/kicad-library/wiki/Kicad-Library-Convention
<enyc> wpwrak: is there a texst project you can get doc tno load and run and experienment wiht... and convert, etc etc ... to get good idea kicad not misbehaving ??
<Wizzup> R0b0t1: nope, not yet
<enyc> R0b0t1: getting right people together at right time will be helpful
<Wizzup> R0b0t1: why are they low res and a screenshot
<Wizzup> link me better pic later ;)
<Wizzup> afk
<enyc> R0b0t1: but be careful of right time, see when wpwrak/doc ready etc etc
<R0b0t1> Wizzup: huh oh yeah
<R0b0t1> I got another phone, I'll record me coldbooting it to SIMless
<R0b0t1> I tweeted it at @NSAGov and @DoD, black helicopters showed up
<DocScrutinizer51> plus carajillo for the finish
<R0b0t1> sounds delicious
<DocScrutinizer51> was delicius
<R0b0t1> Wizzup: there's a vid of me booting it on my yt but I cba to go find it
<wpwrak> enyc: i basically use whatever i worked on last as "test project". these days it's anelok. which needs a new layout anyway. so that's my test case for the push router and the "new" workflow. ("new" because some things are different in legacy and opengl mode)
<wpwrak> DocScrutinizer51: grmbl. food pictures are evil.
<enyc> hrrm some new fuss abotu autodesk buying eagle ! https://www.youtube.com/watch?v=FfsPL0pIpxw maybe no rlevant to you
<DocScrutinizer51> not that new?
<enyc> Published on 12 Jul 2016 on eevblapb anyway
<wpwrak> aah, thought it might be another "der untergang" variant :)
<DocScrutinizer51> we seen something on that havker site already? some 5 dats ago
<enyc> ok
<enyc> nomatter
<R0b0t1> I'd run it in a VM but yeah
<wpwrak> so there's a battle eagle vs. circuit studio aka altium "light" coming. ah well :)
<wpwrak> ah, and "circuit maker" is another altium clone. we need a map :)
<R0b0t1> lol
<DocScrutinizer51> not really, just 'don't go there'
<wpwrak> yeah :)
<enyc> ok
* enyc bouncies around and wants to know if kical compiled finally ;p
* DocScrutinizer51 tempted to ssh into home workstation to see result of kicad build
<DocScrutinizer51> well, I can't stand the suspense any longer....
<R0b0t1> ...
<DocScrutinizer05> and AFK again
<DocScrutinizer51> enyc: see above
pagurus has quit [Remote host closed the connection]
<DocScrutinizer51> ~ping
<infobot> 1 packet transmitted, 1 packet received, 0.0% packet loss
<enyc> DocScrutinizer51: hoooooooray
<DocScrutinizer51> vagrant ssh -X kicad ?
<enyc> DocScrutinizer51: could try, i dont know how slow that will be
Pangolin has quit [Ping timeout: 258 seconds]
<DocScrutinizer51> not that slow, it's all local
<enyc> DocScrutinizer51: may be Xvnc better or copy to more minimal (not for building) chroot or whatever in host system later ... all sorts of options
<enyc> DocScrutinizer51: yes, but it tends to bypass shared memory iirc
<enyc> DocScrutinizer51: experiment =)
<enyc> DocScrutinizer51: you would need to install deb package(s)
<enyc> dpkg -i kicad[......].deb
<enyc> which may well want some apt-get -f install to install some of the runtime dependencies
<DocScrutinizer51> ok
<enyc> you have *just* complied the standard deb packages thats' it
Pangolin has joined #neo900
<enyc> they could go in apt repos for others or ..etc... but you can just dpkg -i manually
<DocScrutinizer51> ack
<enyc> if thasts' usable, then that whole sourcetree is ideal for making changes / manual compiles of different binaries for the program in future // etc
<enyc> if really_weird consitency / threading sorts of problems happen may need to try a xenial chroot to compare with, but hopefully not =)
<DocScrutinizer51> sorry, got DC
paulk-collins has quit [Quit: Leaving]
<DocScrutinizer05> dang, lost sent and RX posts
<DocScrutinizer05> gotta fix my ZNC
<DocScrutinizer05> now... let's find(1) that .deb
<DocScrutinizer05> hmph... dpkg-deb: building package `kicad' in `../kicad_4.0.2+e4-6225~38~ubuntu16.04.1_amd64.deb'.
<DocScrutinizer05> WTF?! kicad-demo_4.0.2+e4-6225~38~ubuntu16.04.1_all.deb
<DocScrutinizer05> anyway http://paste.opensuse.org/398949
<DocScrutinizer05> root@devuan:~# kicad --version
<DocScrutinizer05> 22:35:39: Error: Unable to initialize GTK+, is DISPLAY set properly?
<wpwrak> shared-mime-info always takes forever
<wpwrak> XAUTHORITY can also cause problems. (if you're su'ing.)
* DocScrutinizer05 headdesks
<DocScrutinizer05> jr@saturn:~/vagrant-test/kicad-devuan-amd64> vagrant ssh -c kicad -- -X
<DocScrutinizer05> Using `vagrant ssh -c` requires key-based SSH authentication, but your
<DocScrutinizer05> Vagrant environment is configured to use only password-based authentication.
<DocScrutinizer05> wpwrak: without any xserver running on the system, it's hardly going to init GTK
<wpwrak> well yes, i don't think kicad will be much use without X :)
<DocScrutinizer05> hehe, indeed
<DocScrutinizer05> however nobody said X needs to run on the same system like kicad
<wpwrak> at least until someone writes a kicad-curses version, with ASCII art :) ====()===o== ... (o = microvia)
<DocScrutinizer05> hmm
<DocScrutinizer05> sounds like real fun ;-)
<wpwrak> i hope i didn't give you an idea ;-)
<DocScrutinizer05> hehehe too late
<wpwrak> don't forget the vi keybindings. very important ;)
<DocScrutinizer05> joke aside, what does this rant about >>Vagrant environment is configured to use only password-based authentication.<< mean?
<wpwrak> sounds like some build config that was not chosen ?
<DocScrutinizer05> nfc
<DocScrutinizer05> there must be a way to use plain ssh login to the VM
<DocScrutinizer05> hmmm (netstat) tcp 0 0 127.0.0.1:37394 127.0.0.1:2200 VERBUNDEN 920/ssh
<DocScrutinizer05> DRATS! http://paste.opensuse.org/59426182
<DocScrutinizer05> wasn't ssh -X supposed to set $DISPLAY accordingly?
<DocScrutinizer05> ohmy, missed >>X11 forwarding request failed on channel 0<<
<wpwrak> "X11 forwarding request failed on channel 0" suggests that the unde...
<wpwrak> yup
<DocScrutinizer05> why?
<wpwrak> dunno :)
<DocScrutinizer05> freaking crap. So back to [2016-07-13 Wed 15:56:26] <DocScrutinizer05> anybody fluent with vagrant/virtualbox around to help me out? I want to configure the VM display to be native screen resolution (1960*1024) and grant the VM 4 CPU cores, how to say that in lingua Vagrantfile?
<zakx> not sure about the resolution
<wpwrak> but ... i don't think you'll be happy with kicad over SSH
<zakx> cores is easy though
<zakx> config.vm.provider "virtualbox" do |v|
<zakx> v.cpus = 4
<zakx> end
<wpwrak> heh, that's actually a way to crash it :)
<DocScrutinizer05> zakx: 1000 TA
<zakx> DocScrutinizer05: if you know the VBoxManage argument to archieve the screen resolution, you can pass it with v.customize ["modifyvm", :id, "--arg", "value"]
<DocScrutinizer05> TATATA
<DocScrutinizer05> :-)
<wpwrak> (crash) at least pcbnew. (in the opengl canvas)
<DocScrutinizer05> shall be easy enough: https://www.virtualbox.org/manual/
<zakx> i guess you found out about v.gui = true if you are asking for resolution already
<DocScrutinizer05> yes
<DocScrutinizer05> the 'hard' way
<DocScrutinizer05> found it in a vagrantfile wpwrak pointed me at
<zakx> v.customize 'post-boot', ["controlvm", :id, "setvideomodehint", "1960", "1024", "24"]
<zakx> try that
<zakx> also you'd need to have the virtualbox guest tools installed in the VMs
<DocScrutinizer05> \o/
<DocScrutinizer05> that damn suse pastebin!!!
Pali has quit [Remote host closed the connection]
<zakx> there's also --vram <MB> and --accelerate3d on if you need that too
<zakx> (use it with the modifyvm command)
<DocScrutinizer05> http://termbin.com/ccav
<wpwrak> rest of kicad seems to be reasonably remote-x-friendly, according to a quick test (not only in terms of working at all, but in terms of responsiveness. at least for simple stuff, like anelok.)
<DocScrutinizer05> wpwrak: stuff is always as simple as "what needs to get displayed"
<zakx> for RAM there's also the shortcut "v.memory = 1024"
<zakx> (just as a side note)
<DocScrutinizer05> vb.customize ["modifyvm", :id, "--memory", "2048"] ?
<wpwrak> DocScrutinizer05: yes, but lag can get a bit annoying when editing :)
<zakx> yeah that works too
<DocScrutinizer05> now let's test that other stuff
<DocScrutinizer05> zakx: how would I use https://www.vagrantup.com/docs/synced-folders/basic_usage.html#group for config.vm.synced_folder "./tmp", "/home/compile/kicad", disabled: false ?
<DocScrutinizer05> config.vm.synced_folder "./tmp", "/home/compile/kicad", disabled: false, group: 1001, user: 1001 ??
<zakx> syntactically, yes. but: group is type string and most likely expects the name of the remote group
<zakx> also, there is no "user" parameter, but an "owner" parameter. also string
<DocScrutinizer05> ooh, even better
<DocScrutinizer05> ok, thanks
<DocScrutinizer05> string in " " ?
<zakx> yeah, like this: owner: "root", group: "root"
<DocScrutinizer05> config.vm.synced_folder "./tmp", "/home/compile/kicad", disabled: false, group: "compile", owner: "compile", create: true ?
<zakx> looks fine. I guess there's no need for "disabled: false" as that's the default but it should work anyway
<DocScrutinizer05> vb.gui = true
<DocScrutinizer05> vb.customize 'post-boot', ["controlvm", :id, "setvideomodehint", "1920", "1080", "24"]
<zakx> looks fine too
<DocScrutinizer05> so let's boogy
<DocScrutinizer05> hmmmmm at least no red in http://wstaw.org/m/2016/07/14/plasma-desktopBN2277.png
<DocScrutinizer05> but the resulting window still doesn't look like 1920*1080
<DocScrutinizer05> prolly needs support from inside VM too
<DocScrutinizer05> ok, let's install X11
<DocScrutinizer05> also MEH!!!
<DocScrutinizer05> default: Guest Additions Version: 5.0.18
<DocScrutinizer05> default: VirtualBox Version: 4.2
<zakx> try updating your virtualbox
<DocScrutinizer05> root@devuan:~# cat .vbox_version
<DocScrutinizer05> 5.0.18root@devuan:~#
<DocScrutinizer05> yeah, I guess my local host vbox is older than the vbox inside VM
<zakx> jup
<DocScrutinizer05> I'll dilligently ignore that for now
<DocScrutinizer05> updating stuff in this Suse 13.1 is a PITA
<DocScrutinizer05> shared folders worked
<zakx> .oO(suse is PITA)
<DocScrutinizer05> meanwhile yes
<DocScrutinizer05> thanks systemd
* DocScrutinizer05 suse user since 2000
<DocScrutinizer05> causes some mental inertia ;-)
<DocScrutinizer05> anyway, devuanb(/devian) X11 setup
<zakx> that's about the time i started using it too (it was on CD with some magazine)
<DocScrutinizer05> x11-common - X Window System (X.Org) infrastructure
<DocScrutinizer05> ?
<zakx> i got annoyed by RPM pretty quickly though and after a brief period of apt-rpm i moved to debian
<zakx> (and, of course, YaST)
<DocScrutinizer05> YaST was a royal pain in the 2000-2009 times
<DocScrutinizer05> since then it improved drastically, now even YaST haters start to love it
<DocScrutinizer05> it no longer messes with core files in /etc
<DocScrutinizer05> everything pretty cool about /etc management at large
<DocScrutinizer05> should I apt-get install x11-common?
<DocScrutinizer05> given my goal is to start kicad as sole X11 app
Kabouik has joined #neo900
<zakx> does it hurt? i mean, you can trivially recreate the VM :)
<DocScrutinizer05> can I?
<DocScrutinizer05> I prolly should do a vagrant save
<Kabouik> I did not follow apkenv, so sorry if my question is silly. Is it like Alien dalvik, and if so, can we hope running Android applications on Neo900?
<Kabouik> Or is it just a proof of concept?
<zakx> DocScrutinizer05: why would you be using vagrant if you couldn't?
<DocScrutinizer05> apkenv is prolly just a chroot. There's however some other stuff I forgot the name of, which is supposed to support android
<DocScrutinizer05> zakx: sorry?
<zakx> AFAIK the whole point of vagrant is to have a sane way to provide receipes that recreate VMs as intended by their creators
<zakx> you take a base box and some provisioning files and vagrant puts it together
<zakx> for example, to have a development environment with all necessary dependencies etc.
<DocScrutinizer05> I didn't do provisioning, I built kicad inside the box
<zakx> instead of setting a linux VM up and manually installing packages off a list, you just checkout the vagrantfile + provisioning files and `vagrant up`
<DocScrutinizer05> which took like 3h for compiling, plus another 2h for mountig an extended shared storage to make enough space for compiler
<zakx> so what advantage do you gain by using vagrant as opposed to just creating a VM using the virtualbox gui? :)
<DocScrutinizer05> I'm planning to use provisioning eventually
<Kabouik> But is it actually reasonable to hope running apks on Neo900 DocScrutinizer05, or will it never be ported/developped, even if not theoretically impossible?
<DocScrutinizer05> for now vargant was the already established and working way to get a devuan VM
<zakx> ah, i see. well you could've just used the image they provide to import it into virtualbox
<DocScrutinizer05> Kabouik: how could I tell?
<zakx> saves you the hassle of configuring virtualbox through vagrant
<Kabouik> You have all the answers!
<DocScrutinizer05> I wish I had :-)
<DocScrutinizer05> anyway, vagrant push I found, vagrant save I didn't
<Kabouik> You have the leadership and good knowledge of which developpers are doing what on TMO, plus who's going to buy a Neo900, might help figuring whether this would be reasonable to hope for apks on Neo900 :p
<DocScrutinizer05> *I* hope for them
<DocScrutinizer05> but that doesn't mean a thing
<DocScrutinizer05> check out pyra
<Kabouik> Reasonable was the keyword, not hope :]
<Kabouik> No, Pyra is too big for me
<DocScrutinizer05> they gave me tjhe idea of that tool I forgot the name of
<DocScrutinizer05> for apkg running
<DocScrutinizer05> meh! vagrant snapshot save
<DocScrutinizer05> FFS, doesn't work
<Kabouik> Also, I noticed that *all* my N900 batteries are dead. How are the batteries you got with those new N900 you sourced recently?
<DocScrutinizer05> didn't test them yet
<DocScrutinizer05> I assume they should be decent
<DocScrutinizer05> now what the heck?
<DocScrutinizer05> SNAPSHOT SAVE
<DocScrutinizer05> Command: vagrant snapshot save NAME
<DocScrutinizer05> This command saves a new named snapshot. If this command is used, the push and pop subcommands cannot be safely used.
<Kabouik> There are no "new" batteries in this format being built, right? I'm afraid even compatible batteries bought "brand new" on the internet would be bad because actually old and not stored with storage charge
<DocScrutinizer05> vs:
<DocScrutinizer05> jr@saturn:~/vagrant-test/kicad-devuan-amd64> vagrant snapshot save with-kicad
<DocScrutinizer05> Usage: vagrant [options] <command> [<args>]
<DocScrutinizer05> Kabouik: they are still built, BL-5J is a very common battery
<DocScrutinizer05> n8
<Kabouik> Ok. I knew they were common, but thought only for old devices, and hence that there were only old stocks with "never used" batteries, but still with bad health
<Kabouik> Good to know they are still built.
SylvieLorxu has quit [Quit: ZNC - http://znc.in]