DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
pagurus` has joined #neo900
pagurus` has quit [Remote host closed the connection]
pagurus` has joined #neo900
pagurus` has quit [Remote host closed the connection]
pagurus has quit [Ping timeout: 276 seconds]
pagurus` has joined #neo900
deafboy_ is now known as deafboy
announ has quit [Quit: announ]
louisdk has joined #neo900
paulk-aldrin has joined #neo900
xman has quit [Quit: Leaving.]
jonsger has joined #neo900
SylvieLorxu has joined #neo900
louisdk has quit [Ping timeout: 258 seconds]
Pali has joined #neo900
galiven has joined #neo900
galiven__ has quit [Ping timeout: 244 seconds]
saper_ has joined #neo900
saper has quit [Remote host closed the connection]
galiven has quit [Ping timeout: 244 seconds]
<chomwitt>
i was reading in meamo forum about the petition to ms-nokia for openening maemo and i wonder if running maemo on neo900 would help in case some hardware is replaced by hardware which has open drivers. (well i assume that drivers are part a maemo distribution)
<DocScrutinizer05>
I can't really parse the question ("running maemo on neo900 would help" with what particularly?), but generally the "openening maemo" is probably a dead and rotten topic, pointless and everything said about it. Rather see:
<chomwitt>
DocScrutinizer05: maybe your right...some times meamo's forum are little hard to grasp, i mean there are some foggy issues. like a member has made a distribution which has among other things the maemo5 sdk.
<chomwitt>
does that resonate with fptf?
<DocScrutinizer05>
Nokia maemo department did everything possible to slice out all maemo related IP and assets form Nokia mobile, prior to Nokia mobile getting sold to MS, and hand it over to Hildon Foundation. Stuff that couldn't get hand over was mostly the same stuff that already been rejected to open up in former requests similar to the petition you mention, and found to be impossible to open up mostly due to Nokia not possessing the complete copyright
<DocScrutinizer05>
due to employing subcontractors like Collabora
<DocScrutinizer05>
I'm aware maemo at large is hard to get an idea of the whole
<DocScrutinizer05>
yes, looks like endsormeans probably did a great job polishing the official SDK integration a little
xman has joined #neo900
<DocScrutinizer05>
anyway "app for fptf" is a fuzzy term. Let me explain: maemo (on Neo900) is supposed to be able to run closed apps like calendar, microB browser etc. What's needed are not re-implementations of kernel drivers (we will provide any such drivers that are not already available from upstream, for new hardware. This will be hardly more than one or though, since everything hw we use is already open hardware - we don't have any secret sources of
<DocScrutinizer05>
datasheets etc) What's needed is a adaption/reimplementation of *middleware* like CSD, MCE, the closed bits in DSME, OHM, PulseAudio and whatnot else
<DocScrutinizer05>
one or 2*
<DocScrutinizer05>
timed
<enyc>
DocScrutinizer05: have you cot pa-st all sticking points with your virtual machine development setup as far as neo900 board development needs are concerned ?
<DocScrutinizer05>
yes
<DocScrutinizer05>
thanks
<DocScrutinizer05>
what would be highly welcome is a genuine xfce (or even generic X11) hotkey kbd macro daemon
<DocScrutinizer05>
I can't use the one on host side since the VM seems to grab raw keycodes, particularly if I send Alt+$key, only $key arrives inside VM
<enyc>
DocScrutinizer05: hrrm i'm not sure about any of that -- never needed to!
<enyc>
DocScrutinizer05: i've only experienced virtualbox grabbing Right-Ctrl ....
* DocScrutinizer05
ponders to finally kill that recurring issue once and for good, by adding hw macro capabilities to the physical kbd
<DocScrutinizer05>
even patching the low-level kernel driver for kbd seems no sustainable approach
<enyc>
DocScrutinizer05: silly question but do you really know that the application works directly without the vm , e.g. just loop-bmount raw fcopy of image and chroot into it an d run it ?
<DocScrutinizer05>
no
<DocScrutinizer05>
didn't try
<enyc>
I'd try that... =)
<DocScrutinizer05>
yeah, possibly worth a shot, now that I got the devuan VM kicad running
xman has quit [Quit: Leaving.]
<DocScrutinizer05>
might also fix the window deco which sort of sucks under xfce
<DocScrutinizer05>
I doubt it will pan out, but... worth a try anyway
<DocScrutinizer05>
enyc: do you have a template how to tackle that?
lkcl has joined #neo900
<chomwitt>
DocScrutinizer05: with that middleware reimplementation i guess all userland apps will be able to run , both maemo old closed ones (like calendar you mentioned) and new ones could be made
<DocScrutinizer05>
yes
<DocScrutinizer05>
that's the rationale behind the aproach taken
<DocScrutinizer05>
enyc: >>e.g. just loop-bmount raw fcopy of image and chroot into it<< sounds pretty easy but doesn't really resolve
<enyc>
can you see ip addreses in use betewen host and vm or not ???
<DocScrutinizer05>
remote X opened kicad
<enyc>
dont do that
<enyc>
can you see ip addreses in use betewen host and vm or not ??? <-- see if can get this figured out quickly and efficiently
<DocScrutinizer05>
which side?
<enyc>
check "netstat -tnW" inside the vm - look for that ssh connection
<enyc>
you now know addresses used ?????
<DocScrutinizer05>
hmm 10.0.2.15:22
<enyc>
ok so 10.0.2.15 is the VM
<enyc>
thats *probably* sufficient alone, can connect in that direction
<enyc>
though, worth noticing the other end of that conenction ??
<DocScrutinizer05>
-p2222 root@127.0.0.1 ??
<enyc>
10.0.2.15:22 connected to 10.0.2.??:[1024-65535] or similar ?
<enyc>
no, just look at the rest of that line in netstat -tnV
<enyc>
no, just look at the rest of that line in netstat -tnW
<DocScrutinizer05>
Proto Recv-Q Send-Q Local Address Foreign Address State
<DocScrutinizer05>
tcp 0 0 10.0.2.15:22 10.0.2.2:39870 ESTABLISHED
<DocScrutinizer05>
tcp 0 0 10.0.2.15:22 10.0.2.2:50326 ESTABLISHED
<enyc>
right so 10.0.2.15 is the VM and 10.0.2.2 is the host, apparently
<enyc>
now you/we know, finally !!!!!
<DocScrutinizer05>
it would help to know what we're after
<enyc>
unless they are doing any superweird translation thing that is what need to know for tar // netcat copy technique =)
<enyc>
right... (a) create a directory for chroot in the host
<DocScrutinizer05>
why not use scp?
<DocScrutinizer05>
or ssh tar
<enyc>
DocScrutinizer05: possible too, if you can make it do the right thing wrt permissions and one-filesystem-only and all that
<enyc>
DocScrutinizer05: IME ssh piping data much slower than direct socket
<DocScrutinizer05>
well, let's try it your way
<enyc>
DocScrutinizer05: but indeed you may be able to do that if you know what you are doing
<enyc>
DocScrutinizer05: i've had nonsense with all the mounted 'virtual filesystems' and bind mount seems to deal with it most effectively
<enyc>
DocScrutinizer05: ok
<enyc>
right... (a) create a directory for chroot in the host
<enyc>
right... (b) in the VM, "mkdir /bind" and "mount / /bind -o bind"
<enyc>
this will give a /bind directory whose contents is *only* the ACTUALY rootfs without any 'complications'
<enyc>
INCLUDING being able to access the 'underlying' even when a virtual filessytem mounts over the top later in boot
<DocScrutinizer05>
done
<DocScrutinizer05>
please write commands without "" and ideally ; instead "and"
<DocScrutinizer05>
wasier to c&p ;-)
<enyc>
i see
<enyc>
in the VM, cd /bind
<enyc>
in the host, cd into the chroot directory
<DocScrutinizer05>
done
<enyc>
... must be root in both cases, which sets lots of defaults in tar anyway ...
<DocScrutinizer05>
done
<enyc>
in the VM, tar --numeric-owner -cvS * | nc -lp 9999
<DocScrutinizer05>
been there already
<enyc>
if needbe will need to install netcat package ... hopefully that will 'sit there waiting'
<enyc>
then in the host, nc 10.0.2.15 9999 | tar --numeric-owner -xvS
<DocScrutinizer05>
we should have addad a -v somewhere
<enyc>
the numeric-owner stuffs is especially important because debian//suse may have different uid/gid for core things, and we want the debian chroot to copy properly
<enyc>
there is a -v in there both ways round
<enyc>
should be listing the files being copied in both ends
<DocScrutinizer05>
I don't think port 9999 is exported
<DocScrutinizer05>
by NAT
<enyc>
this shouldn't be using the nat
<enyc>
it should be just conecting between the host and the vm directly
<enyc>
i.e. host just directly connects to the guest
<DocScrutinizer05>
nothing going on
<enyc>
check netstat -tnW in host
<DocScrutinizer05>
host and guest separated by VBox NAT
<enyc>
no, the NAT is used when VM talks 'outside' to other machines
<enyc>
not needed when host talks to guest directly
<DocScrutinizer05>
saturn:/home/jr/vagrant-test/kicad-devuan-amd64/chrootdir # nc 10.0.2.15 9999 | tar --numeric-owner -xvS
<DocScrutinizer05>
tar: This does not look like a tar archive
<DocScrutinizer05>
tar: Exiting with failure status due to previous errors
<enyc>
yes so it just can't connect to that guest in that manner , ok maybe virtualbox networking is more fiddly ... could indeed pipe it over ssh or try connecting the other wayround
<enyc>
other way round may be best
<enyc>
get host to nc -lp | tar --numeric-owner -xvS
<enyc>
errrrrrrrror
<enyc>
get host to nc -lp 9999 | tar --numeric-owner -xvS
heinrich5991 has quit [Ping timeout: 240 seconds]
<enyc>
and guest to tar --numeric-owner -cvS * | nc 10.0.2.2 9999
<DocScrutinizer05>
and I hope you're not going to nuke my host with this
<enyc>
(it may be, the guest needs to refer to the host by some different ip address of the host, rather than some weird vbox-nat-address-thing)
<enyc>
DocScrutinizer05: indeed !! you need to run tar in the correct (empty) directory so all it does iss extract files in that directory!
<DocScrutinizer05>
I really don't like to run tar as root on host
<enyc>
DocScrutinizer05: all i can say is i've done this (with care) many times, though not specifically using virtualbox, but many virtualizer setups / linux systems
<DocScrutinizer05>
or let's postpone a little until this issue vanished
<enyc>
DocScrutinizer05: so its quite clear your machine is 192.168.4.21 on some other lan it uses ...
<DocScrutinizer05>
so?
<enyc>
DocScrutinizer05: so, that may be a workable way to refer to machine from guest
<DocScrutinizer05>
VBox uses some NAT
<enyc>
DocScrutinizer05: e.g. to feed in a tarpipe of filessytem quickly and easily =)
<enyc>
DocScrutinizer05: yes, so outgoing connection from VM should always work however they implemented it
<enyc>
DocScrutinizer05: hence... telling yu tow to connect the other way round
<DocScrutinizer05>
maybe tunneling thoough ssh is easier?
<enyc>
DocScrutinizer05: Host can ... nc -lp 9999 | tar --numeric-owner -xvS ... and guest can ... tar --numeric-owner -cvS * | nc 192.168.4.21 9999 ...
<DocScrutinizer05>
instead nc
jonsger has quit [Quit: jonsger]
<enyc>
possibly so, the above worth a go. also could be confusion with minorly different netcat viariants -- some need nc -l 9999 others need nc -lp 9999 !!
<enyc>
i think outgoing nc connection (as above) likely to work
<enyc>
unless opensuse does some weird firewall-nonsense of its own =)
<DocScrutinizer05>
(UNKNOWN) [192.168.4.21] 9999 (?) : Connection timed out
<enyc>
DocScrutinizer05: this is exactly the case about port 9999 error
<enyc>
DocScrutinizer05: err
<enyc>
DocScrutinizer05: nc variant
<enyc>
needs nc -l 9999 rather than nc -lp 9999
<DocScrutinizer05>
sorry, afk, need to regain clear vision
<enyc>
also, the timeout, suggests iptables -I INPUT -p tcp --dport 9999 -j ACCEPT due to opensuse firewall ... THEN it should work =)))
<enyc>
ok
<enyc>
later
<enyc>
it really is that >< close to working =)
heinrich5991 has joined #neo900
<DocScrutinizer05>
dang, did an oopsie deleting a dir. Shouldn't try working when vision issue. Thanks btrfs and snapper, I'll recover in 15 min
<DocScrutinizer05>
pro tip: try to keep your snapper volumes as small as possible, it takes ages to calculate the diffs between a 800GB snapshot and recent volume
<DocScrutinizer05>
AAAAAAAAGES
<DocScrutinizer05>
annoying: it been the VM's shared host dir, so the VM went 100PU and I had to stop it
<DocScrutinizer05>
100% CPU
<DocScrutinizer05>
now no use really to start it again until snapper -c home undochange 832..835 /home/jr/vagrant-test/kicad-devuan-amd64/tmp/; finally completes
<DocScrutinizer05>
and it seems snapper is a PoS that does a complete diff on the whole volume to finally look into that to decide the files to undochange
<DocScrutinizer05>
instead of limiting the diff to only the path provided as argument
<wpwrak>
the next version will do better: it'll upload the volume over a poorly encrypted connection to some cloud service that will then do the diff. naturally, this service will shut down the day before you need some major recovery.
<DocScrutinizer05>
maybe starting the cmdline version in parallel due to lack of patience didn't help either
<wpwrak>
murphy's rule of backup tools: even if they work, it takes longer to restore a file than to recreate it
<wpwrak>
(in parallel) ah, listen to the disk then. maybe it's thrashing
<DocScrutinizer05>
then I SIGSTPed the GUI version and finally though "well, who knows, maybe snapperd is waiting forever to receive a modal respnse from that stopped thing and the cmdline can't continue until that transaction completed" and SIGCONT it, to close the window. In which moment the content popped up ;-P
<DocScrutinizer05>
the dis is busy all the time, even with one snapper instance
<wpwrak>
hellekin: btw, how about a little news snippet about our transition to kicad ? that would not only quench people's thirst for news, but it would also have our news start with something more upbeat than "PayPal trouble" (resolved, but still)
<DocScrutinizer05>
enyc: running a saturn:/home/jr/vagrant-test/kicad-devuan-amd64/chrootdir # ssh -p2222 root@127.0.0.1 'cd /bind; tar --numeric-owner -cvS *'| tar --numeric-owner -xvS ;# now
<DocScrutinizer05>
seems to work
<DocScrutinizer05>
since CPUs are not maxed out neither host nor VM, I guess the bottleneck is iowait anyway
<DocScrutinizer05>
so the ssh encryption overhead is irrelevant
<DocScrutinizer05>
and done
herpderphurr has quit [Ping timeout: 260 seconds]
AndrewX192 has quit [Quit: CM-189: Xenial Upgrade: wlnet-chat]
<DocScrutinizer05>
while still listening to remote commands, to recording GPS fixes and days of audio, for later download - NSA will do a dance of joy when journalists actually think such a "shell hardened" iPhone would be secure to take to a conspirator meeting
jonsger has joined #neo900
<DocScrutinizer05>
when even Snowden doesn't see this, it's quite sad
<DocScrutinizer05>
then otoh nobody certified Snowden as an expert for decure hw design, right?
<DocScrutinizer05>
secure even
<DocScrutinizer05>
Snowden had access to lots of secret documents and did the right thing, that doesn't make him an expert for secure hw design
<DocScrutinizer05>
considering this, it's a pretty flawed plan - Bunnie rather should have contacted e.g. snoopsnitch's SRlabs / the Cryptophone guys, or (duh!) Neo900 crew
xes_ has joined #neo900
xes has quit [Ping timeout: 276 seconds]
<DocScrutinizer05>
ummm aha! >>It is no surprise that complex systems such as the Apple iPhone 6 would have test points baked into the circuit board design to assist with debugging. These are an essential part of yield and customer experience improvement; defective units from the factory and the field are sent back to the headquarters, and engineers rely on these testpoints to determine the root cause of the device’s failure.<<
<DocScrutinizer05>
hmmm >>It is hypothesized that an attempt to even passively scan for base stations without transmitting will require traffic on this bus; at the very least, the antenna switches must be powered on and configured to receive<< well a hypothesis is a tad 'weak' to build a security solution on that
<enyc>
DocScrutinizer05: okies i here now
<enyc>
DocScrutinizer05: ok we need to rbind mount /dev into chroot and bind mount proc and sys.... i think... one moment i check commands
<enyc>
DocScrutinizer05: in the VM, you can umount /bind and rmdir /bind to clean up, though not important per-se
<enyc>
DocScrutinizer05: i think, mount /dev /home/jr/vagrant-test/kicad-devuan-amd64/chrootdir/dev -o rbind
<enyc>
DocScrutinizer05: then, mount /proc /home/jr/vagrant-test/kicad-devuan-amd64/chrootdir/proc -o bind
<enyc>
DocScrutinizer05: then, mount /sys /home/jr/vagrant-test/kicad-devuan-amd64/chrootdir/sys -o bind
<enyc>
then should have functional chroot special directories =)
<DocScrutinizer05>
done
<DocScrutinizer05>
saturn:/home/jr/vagrant-test/kicad-devuan-amd64/chrootdir # cd /home/jr/vagrant-test/kicad-devuan-amd64/chrootdir; mount -o rbind /dev ./dev/; mount -o bind /proc/ ./proc/; mount -o bind /sys/ ./sys/
<DocScrutinizer05>
saturn:/home/jr/vagrant-test/kicad-devuan-amd64/chrootdir # echo -e '#!/bin/sh\ncd /home/jr/vagrant-test/kicad-devuan-amd64/chrootdir; mount -o rbind /dev ./dev/; mount -o bind /proc/ ./proc/; mount -o bind /sys/ ./sys/' >/usr/local/bin/kicad-chroot
<enyc>
yes...
<enyc>
now try just "chroot chrootdir" ...
<enyc>
su - compile
<enyc>
you (may) be able to then execute kicad.. but I suspect some copying of x11 cookies / .Xauthority will be needed for x11 box to wkr
<enyc>
DocScrutinizer05: rather, i wonder why the virtualization // x11 in virtualbox // xfce session // messes up alt somewhere
<enyc>
DocScrutinizer05: do you see, that chroot works, truly keeping the rpm-instlaled and chroot deb-installed files separate?
<enyc>
DocScrutinizer05: note, some bind mounting or smb mounting or similar, of the data directories would be needed, if you are to use the chroot 'seriously' ...
<DocScrutinizer05>
I understand the data dir issue
fling has joined #neo900
<enyc>
ok
<enyc>
of course you might not have matching UIDs for the data dir...!
<DocScrutinizer05>
I don't understand >>do you see, that chroot works, truly keeping...<<
lkcl has joined #neo900
<enyc>
DocScrutinizer05: err... think history... you originally said... you didn't want to use chroot, because mix rpm and deb
<DocScrutinizer05>
I don't know how to check for what you asked
<DocScrutinizer05>
actually I don't understand what you asked#
<enyc>
DocScrutinizer05: think back for a bit....
<enyc>
DocScrutinizer05: some days ago -- you originally said... you didn't want to use chroot, because mix rpm and deb
<DocScrutinizer05>
did I?
<enyc>
yes
<DocScrutinizer05>
sounds strange since that statement makes no sense to me today, so how would it make sense a few days ago?
<DocScrutinizer05>
I guess this was a misconception or bad wording or whatever
<DocScrutinizer05>
I still don't know what to check to answer your question
<DocScrutinizer05>
which rpm installed files could the chroot possibly access?
<DocScrutinizer05>
except of those that are bindmounts
<DocScrutinizer05>
and those are not rpm installed
<enyc>
00:47 <+DocScrutinizer05> a chroot is more complex to manage than a VM
<enyc>
00:47 <+DocScrutinizer05> particularly when you want to create a different OS environment inside the chroot
<DocScrutinizer05>
hmm, ok, that was an incorrect estimation
<DocScrutinizer05>
so would you need a lsof now, to check for any rpm files accessed from chroot?
<enyc>
thrrm i'm sure you sai somethnig about rpm mibx but cant easily gfind it now
<DocScrutinizer05>
btw OpenGL canvas in chroot causes immediate quit of kicad now
<enyc>
DocScrutinizer05: it couldn't... soits fine
<enyc>
DocScrutinizer05: so... opengl won't (easily) owrk in that config
<DocScrutinizer05>
compile@saturn:~$ kicad
<enyc>
DocScrutinizer05: MAYBE some messing with Xauthority and so on will allow some shard memory or similar
<DocScrutinizer05>
Segmentation fault
<enyc>
DocScrutinizer05: maybe it won't ;p
<enyc>
DocScrutinizer05: or you could get another disk and install devuan directly on that =) then you can just install/run the debs' directly on that =)
<enyc>
no more opensuse =)
<DocScrutinizer05>
please, we been at this point in several discussions with wpwrak during the last days. I need a productive environment, not a clean empty devuan install that's not linked to anything at all, like email, irc, whatnot else
<enyc>
have you ? ok
<enyc>
i didn't know =)
<DocScrutinizer05>
yep, just he suggested ubuntu
<enyc>
ubuntu-MATE variant or Mint-MATE or devuan or debian would work imho!
<enyc>
but there you go
<DocScrutinizer05>
I rather wonder what this OpenGL actually involves on my system. I don't think I got any of that installed in the host
<enyc>
just be aware if you have _Problematic_ older system it may sink more and more time 'fiddling' ...
<enyc>
DocScrutinizer05: i wnoder too -- can you try running a different glx program in chroot
<DocScrutinizer05>
been there
<DocScrutinizer05>
2 days ago
<enyc>
DocScrutinizer05: glxgears or similar ?
<DocScrutinizer05>
let's start with "can I run a opengl program in host?"
<DocScrutinizer05>
ok that works
<DocScrutinizer05>
no glxgears in chroot
<DocScrutinizer05>
so more likely than not, the needed opengl libs etc are missing in the devuan chroot rather than on my host
<Defiant>
apt-get install mesa-utils
<Defiant>
for glxgears
sn0wmonster has joined #neo900
<enyc>
DocScrutinizer05: package should install/require the nedede 'dependencies' ....
<DocScrutinizer05>
hmm, the connectivity in chroot is... not really working
<Wizzup>
/etc/resolv.conf set?
<DocScrutinizer05>
nope, of course not
<enyc>
=)
<DocScrutinizer05>
Setting up mesa-utils (8.2.0-1) ...
<DocScrutinizer05>
I guess that's what I meant with "a chroot might now work in an environment that doesn't have same architecture )and libs and whatnot)"
<enyc>
hrrrrm
<enyc>
enyc@sparkie:~$ glxinfo
<enyc>
name of display: :0.0
<enyc>
display: :0 screen: 0
<enyc>
direct rendering: Yes
<enyc>
server glx vendor string: SGI
<DocScrutinizer05>
s/now/not/
<enyc>
server glx version string: 1.4
<enyc>
hrrrm.... can you get 'glxinfo' up in suse outside the chroot ??
<wpwrak>
can you start an xterm, xeyes, xclock, or anything else that's simple ?
<wpwrak>
the key things: copy .Xauthority from the account that "owns" the session; in the su/chroot/etc. session, unset XAUTHORITY; set DISPLAY to something that's accessible. in a chroot without further ado, that would be localhost:...